インフラストラクチャ アーキテクチャ: コンテナが第 4 プレーンを作成
従来のネットワーク インフラストラクチャでは、通常、データ、制御、管理という 3 つのアーキテクチャ プレーンがネットワーク インフラストラクチャに関連付けられています。
これらの正確な定義は、インフラストラクチャのジャンルや具体的な実装によって異なる場合がありますが、ほとんどのネットワーク インフラストラクチャでは、アーキタイプはほぼ正確です。
- データプレーン
- データ プレーンは、現代の専門用語ではデータ パスと呼ばれることもあり、パケット (データ) が渡されるパスです。 データ プレーンは、パケットを受け入れて適切な宛先に転送する役割を担います。
- コントロールプレーン
- 一般的に、コントロール プレーンはデータが転送される場所を決定します。 ルーティング プロトコルは、コントロール プレーン機能の良い例です。今日ではより動的になる可能性のある高次の意思決定も同様です。 具体的な実装はさまざまですが、データ プレーンが決定のためにコントロール プレーンにデータを渡すものから、コントロール プレーンがデータを透過的に監視し、特定のトリガーに基づいて動作するものまで多岐にわたります。 コントロール プレーンは、多くの場合、デバイスの健全性の監視と統計の収集も担当します。
- 管理プレーン
- 管理プレーンは、制御プレーンと対話する場所であるため、3 つのプレーンの中で最も目立ちます。 従来の管理プレーンでは CLI (コマンド ライン インターフェイス) が使用されますが、最新の管理プレーンでは API (アプリケーション プログラミング インターフェイス) が好まれます。 使用される方法に関係なく、管理プレーンにより、オペレーターは制御プレーンによって適用されるポリシーを設定できます。 これには、IP アドレスやデバイス タイプなどの特性に基づいた負荷分散アルゴリズムや許可/拒否ポリシーなどの構成オプションが含まれます。
しかし、裏側では、オペレーターにはほとんど見えない別の種類のオーケストレーションが機能しています。 これは、人間のオペレーターから一部の責任を引き継ぐという点を除けば、管理とは何の関係もありません。
ここでの違いは、アクションがデプロイメント イベントとしてではなく、実行中の環境の変更によって自動的にトリガーされることです。 しかし、何が変わったかに関する情報は非常に重要であり、どこかで入手する必要があります。
従来の運用モデルでは、その情報は通常、変更チケットまたはリクエストから取得されます。 最新の運用モデル、特にコンテナの場合、この情報は検出メカニズムを介してサービス レジストリから取得されます。
サービスレジストリと検出
コンテナ環境の性質上、IP アドレスはアプリケーション環境にとって実質的に重要ではないという前提が含まれます。 しかし、クライアントとアプリケーション間のパスを通過するために、データは依然としてデバイス間でルーティングおよび転送される必要があるため、インフラストラクチャにとっては重要です。 最近の環境では、これらの IP アドレスは短期間 (コンテナ/サービスの有効期間) 存在することがよくあります。
DataDogの次の調査結果を検討してください (強調追加):
オーケストレーターの急速な導入 (事実 4 を参照) により、コンテナの自動起動と停止によって解約率が上昇し、コンテナの寿命がさらに短くなると思われます。 オーケストレーターを実行している組織では、コンテナーの一般的な有効期間は約 12 時間です。 オーケストレーションのない組織では、コンテナの平均寿命は 6 日間です。
< https://www.datadoghq.com/docker-adoption > より
オペレーターとして、12 時間ごとどころか 6 日ごとにルーティング テーブルまたは負荷分散プールを更新しなければならないとしたらどうなるか想像してみてください。 他にはほとんど何もしないだろう。 コンテナ クラスターの変更を管理するために手動モードで操作しなければならない時間が長くなるほど、構成ミスの可能性は大きくなり、その可能性も高まる可能性があります。
Consulのようなサービス レジストリは、コンテナーのデプロイメントの重要なコンポーネントになります。 サービス レジストリは、インスタンスとサービス、およびそれらに関連付けられた IP アドレスを追跡します。 この点では、「コンテナとサービスのための DNS」に例えることができます。
したがって、サービス レジストリはクラスター内のコンテナーの現在の特性を追跡します。 検出とは、インスタンスを IP アドレスに一致させるサービス レジストリ (API 経由またはメッセージ キューへのサブスクライブによって) に接続するプロセスです。
つまり、コンテナ クラスター内の特定のサービスまたはインスタンスにトラフィックをルーティングする必要があるインフラストラクチャでは、IP アドレスを取得できる必要があります。 コンテナはアプリケーションからネットワークを隠しますが、データをある場所から別の場所に移動するには依然としてネットワークに依存しています。
第四の次元: オーケストレーション
これにより、コンテナ オーケストレーション環境と対話するインフラストラクチャに新しいアーキテクチャ レイヤーが導入されます。 このレイヤー (オーケストレーション レイヤー) は、コンテナー環境と統合され、サービス検出などの機能を利用して、サービスとインスタンスの検出を自動化します。 つまり、ロード バランサーはプールのメンバーを自動的に検出し、環境の変化に基づいて継続的に更新することができます。 これにより、負荷分散プールを手動で更新する操作の負担が軽減されます。コンテナの平均寿命が 1 週間未満の場合、この作業はますます面倒になります。
この飛行機はオペレーターとのやり取りを目的としたものではありません。 構成、監視、操作は引き続き管理プレーンを介して実行されます。 サービス レジストリの場所は管理プレーンを介して構成されますが、オーケストレーション プレーンによって制御プレーンへの接続と変更の伝達に使用されます。
オーケストレーション プレーンは次のように定義できます。
- オーケストレーション プレーンは、インフラストラクチャ アーキテクチャの中で最も目立たないプレーンの 1 つです。 管理プレーンとのやり取りは管理プレーンを介して行われ、管理プレーンは主に、オーケストレーション プレーンを適切なサービス レジストリに向ける役割を担います。 その役割は、コントロール プレーン内の動的コンポーネントを更新して、コンテナ化されたリソースの適切な転送と可用性を確保することです。
このプレーンをコントロール プレーンやデータ プレーンとともにデバイスに統合する必要があるのか、それとも単に管理プレーンのベニヤ板にするのか (これにより図が若干変わりますが、プレーンとコンポーネント間の相互作用には影響しません) という疑問がまだ残っています。 多くの従来のデバイスは、コンテナ環境と統合し、管理プレーンを介して変更を加える拡張機能を提供することで、この新しいプレーンをすでにサポートしています。 これは、従来のアーキテクチャをリファクタリングして機能を最新の環境に拡張する良い例です。 しかし、結局のところ、それは理想的な解決策ではないかもしれません。
なぜそれが重要なのか?
一見すると、インフラ用の第 4 機の導入は重要ではないと思われるかもしれません。 結局のところ、その機能は、オペレーターの面倒な作業の責任の一部を軽減することです。 それは悪いことではないはずだ。
これは悪いことではありませんが、静的構成から動的構成への移行は、コントロール プレーンの最も重要な機能の一部に影響を与えることを理解することが重要です。 サービス検出の重要性は高まり、その可用性とセキュリティは必須となります。 事実上、これはアプリケーション インフラストラクチャ全体の基盤となる単一障害点になります。
サービス レジストリは、ほとんどの最新アプリケーションと同じ前提に基づいて構築されており、障害を処理するために構築されています。 トラフィックをそのインスタンスに転送する前に、発見した IP アドレスが消えてしまうという状況に陥る可能性があります。 ほとんどのインフラストラクチャはその時点で再送信が可能ですが、そのプロセスには時間がかかります。 デジタル経済ではマイクロ秒が重要なので、タイムアウトや検出間隔などの従来のオプションは、検出に依存する最新のアーキテクチャでは違いを生み出します。 健全性と可用性をできるだけ早く判断できるかどうかが、ユーザーの満足度と離脱率の違いを生む可能性があるため、監視もさらに重要になります。 どちらも、現代の組織の全員が認識し、独自の指標と期待に組み込む必要があるビジネス レベルの懸念事項です。
インフラストラクチャにおけるオーケストレーション プレーンの実装とサービス レジストリの選択は、使用するテクノロジに関する意思決定プロセスにおいて重要な要素になります。 コンテナベースのアーキテクチャを介して配信されるアプリケーションの可用性とパフォーマンスの両方に影響するため、選択を慎重に検討してください。