インフラストラクチャアーキテクチャ：コンテナが生み出す第4のプレーン

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

従来のネットワークインフラストラクチャには、一般にデータ、制御、管理という3つのアーキテクチャプレーンがあります。

これらの厳密な定義は、インフラストラクチャの種類や具体的な実装によって異なる場合がありますが、この基本的な分類は、ほとんどのネットワークインフラストラクチャにおおむね当てはまります。

• データプレーン
  
  • 現代の用語ではデータパスとも呼ばれるデータプレーンは、パケット（データ）が通過する経路です。データプレーンは、パケットを受け入れ、適切な宛先に転送する役割を担います。
• コントロールプレーン
  
  • 一般に、コントロールプレーンはデータの転送先を決定します。ルーティングプロトコルはコントロールプレーン機能の代表例であり、現在ではより動的になり得る高度な意思決定もこれに該当します。具体的な実装はさまざまで、データプレーンが判断を仰ぐためにデータをコントロールプレーンへ渡す方式から、コントロールプレーンがデータを透過的に監視し、特定のトリガーに応じて動作する方式まであります。また、コントロールプレーンは多くの場合、デバイスの健全性の監視と統計情報の収集も担います。
• 管理プレーン
  
  • 管理プレーンは、コントロールプレーンを操作する場所であるため、3つのプレーンの中で最も目に触れやすいプレーンです。従来の管理プレーンではCLI（コマンドラインインターフェース）が使用されますが、最新の管理プレーンではAPI（アプリケーションプログラミングインターフェース）が好まれます。使用する方法にかかわらず、管理プレーンでは、コントロールプレーンによって適用されるポリシーをオペレーターが設定できます。これには、負荷分散アルゴリズムや、IPアドレスやデバイスタイプなどの特性に基づく許可／拒否ポリシーといった設定オプションが含まれます。

しかし、内部では別の種類のオーケストレーションが機能しており、運用担当者からはほとんど見えません。これは管理とは無関係ですが、人間の運用担当者が担ってきた一部の役割を引き継いでいます。

ここでの違いは、デプロイ時のイベントとしてではなく、実行中の環境の変化によってアクションが自動的にトリガーされる点です。ただし、何が変化したかという情報は不可欠であり、どこかから取得する必要があります。

従来の運用モデルでは、通常、この情報は変更チケットや変更リクエストから得られます。一方、最新の運用モデル、特にコンテナの場合は、ディスカバリーメカニズムを介してサービスレジストリから得られます。

サービスレジストリとサービスディスカバリ

コンテナ環境では、アプリケーション環境にとってIPアドレスは実質的に重要ではないという前提があります。しかし、クライアントとアプリケーション間の経路を通過するには、データをデバイス間でルーティングおよび転送する必要があるため、インフラストラクチャにとってIPアドレスは重要です。最新の環境では、こうしたIPアドレスの存続期間は、多くの場合、コンテナ／サービスの存続期間に相当する短いものです。

以下のDataDogの調査結果をご覧ください（強調は引用者によるものです）。

オーケストレーターの急速な導入（事実4を参照）により、コンテナの起動と停止が自動化され、入れ替わりがさらに激しくなるため、コンテナのライフサイクルは一層短くなっていると考えられます。オーケストレーターを運用している組織では、一般的なコンテナのライフサイクルは約12時間です。オーケストレーションを導入していない組織では、コンテナの平均ライフサイクルは6日間です。

_{出典：<https://www.datadoghq.com/docker-adoption>}

運用担当者が、6日ごと、ましてや12時間ごとにルーティングテーブルやロードバランシングプールを更新しなければならない状況を想像してみてください。ほかの作業をする余裕はほとんどありません。コンテナクラスターの変更に対応するために手動運用を続けざるを得ない期間が長くなるほど、設定ミスが発生する可能性は高まり、重大な問題となるでしょう。

サービスレジストリ（Consulなど）は、コンテナ環境のデプロイに不可欠なコンポーネントとなります。サービスレジストリは、インスタンスとサービス、およびそれらに関連付けられたIPアドレスを追跡します。この点では、「コンテナとサービスのためのDNS」に相当します。

このように、サービスレジストリは、クラスター内のコンテナの現在の特性を追跡します。ディスカバリとは、API経由またはメッセージキューへのサブスクライブによってサービスレジストリに接続し、該当するインスタンスをIPアドレスに対応付けるプロセスです。

つまり、コンテナクラスター内の特定のサービスまたはインスタンスにトラフィックをルーティングする必要があるインフラストラクチャは、IPアドレスを取得できなければなりません。コンテナはアプリケーションからネットワークを隠蔽しますが、ある場所から別の場所へデータを転送する際には、依然としてネットワークに依存しているためです。

第4のプレーン：オーケストレーション

これにより、コンテナオーケストレーション環境と連携する新たなアーキテクチャレイヤーがインフラストラクチャに導入されます。このオーケストレーションレイヤーはコンテナ環境と統合され、サービスディスカバリなどの機能を利用して、サービスやインスタンスの検出を自動化します。そのため、ロードバランサーはプールメンバーを自動的に検出し、環境の変化に応じて継続的に更新できます。コンテナの平均稼働期間が1週間未満となる中、ますます煩雑になるロードバランシングプールの手動更新作業を軽減できます。

このプレーンは、オペレーターが操作するためのものではありません。構成、監視、運用は、引き続き管理プレーンを介して行います。サービスレジストリの場所は管理プレーンで構成しますが、オーケストレーションプレーンがその情報を使用してコントロールプレーンに接続し、変更を伝達します。

We can define the オーケストレーションプレーンは、次のように定義できます。

• オーケストレーションプレーンは、インフラストラクチャアーキテクチャにおいて最も目に触れにくいプレーンの1つです。オーケストレーションプレーンとのやり取りは管理プレーンを介して行われます。管理プレーンは主に、オーケストレーションプレーンが適切なサービスレジストリを参照するように設定します。オーケストレーションプレーンは、コンテナ化されたリソースが適切に転送され、可用性が確保されるよう、コントロールプレーンの動的コンポーネントを更新します。

このプレーンをコントロールプレーンやデータプレーンとともにデバイスに統合すべきか、それとも単に管理プレーンの上に重なる層にすぎないのかという疑問は、依然として残っています（後者の場合、図は若干変わりますが、プレーンとコンポーネント間の連携にはそれ以外の影響はありません）。従来型デバイスの多くは、コンテナ環境と統合し、管理プレーンを介して変更を行う拡張機能を提供することで、この新たなプレーンをすでにサポートしています。これは、従来型アーキテクチャをリファクタリングし、最新の環境へと機能を拡張する好例です。しかし、最終的には理想的なソリューションではない可能性があります。

なぜ重要なのか

インフラストラクチャに第4のプレーンを導入しても、当初は大した意味がないように思えるかもしれません。結局のところ、その役割は、煩雑な作業に対するオペレーターの責任の一部を軽減することです。それ自体は悪いことではありません。

これは悪いことではありませんが、静的構成から動的構成への移行が、コントロールプレーンの特に重要な機能の一部に影響を及ぼすことを理解しておく必要があります。サービスディスカバリの重要性が高まるため、その可用性とセキュリティの確保は必須となります。実質的に、アプリケーションインフラストラクチャ全体を支える単一障害点になるからです。

サービスレジストリは、現代の多くのアプリケーションと同じ前提、つまり障害に対処できるように構築されています。検出したばかりのIPアドレスが、そのインスタンスにトラフィックを転送する前に消失することもあります。ほとんどのインフラストラクチャはその時点で再送できますが、処理には時間がかかります。デジタル経済ではマイクロ秒単位の差が重要になるため、サービスディスカバリに依存する現代のアーキテクチャでは、タイムアウトや検出間隔といった従来の設定が大きな違いをもたらします。また、健全性と可用性を可能な限り迅速に判断できるかどうかが、ユーザーの満足と離脱を分ける可能性があるため、監視もはるかに重要になります。いずれもビジネス上の懸念事項であり、現代の組織に属するすべての人が認識し、それぞれの指標や期待値に組み込む必要があります。

インフラストラクチャにおけるオーケストレーションプレーンの実装方法とサービスレジストリの選択は、採用するテクノロジーを決定するうえで重要な要素となります。これらの選択は、コンテナベースのアーキテクチャで提供されるアプリケーションの可用性とパフォーマンスの両方に影響するため、慎重に検討してください。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事