コンテナオーケストレーション環境がヘルスモニタリングに与える影響

可用性の中心となるのは監視です。 すべてのロード バランサは、ターゲット リソースを選択する前に、そのリソースが実際に利用可能かどうかを知る必要があります。 そうでなければ、何の意味があるのでしょうか?

リソースの有効期間が数時間や数日ではなく数分で測定される環境では、リクエストを送信するかどうかを決定する前にリソースの状態を把握することがさらに重要になります。

ヘルスモニタリングは、ロードバランサーとプロキシの不可欠な部分です。 コンテナ化された環境内でもそれは当てはまります（または当てはまるはずです）。 これらの環境が（急速に）成熟し続けるにつれて、非常に不安定な分散システムに関連するやや特異な課題に対処するための新しい監視モデルが登場しつつあります。

従来のヘルス モニタリングは確かに方程式の一部ですが、コンテナー環境内の可用性とスケールの一部のモデルは、従来のヘルス モニタリングに負担をかけるため、対処する必要があります。 たとえば、フォワード プロキシ モデルに展開されたプロキシは、すべての可能なサービスにわたって正常な (利用可能な)ターゲットを選択できることが期待されます。 リバース プロキシ (従来のロード バランサーとも言う) は、単一のアプリケーションの非常に特定のサービス セットの状態を追跡する役割のみを担いますが、フォワード プロキシは、環境内のすべてのアプリケーションのすべてのサービスの状態を把握する役割を担います。 すでにサービス停止中のコンテナにリクエストを送信するのは良くないですからね。

従来の健康モニタリング

従来、ヘルス モニタリングはプロキシによって次の 2 つの方法で実行されます。

• アクティブモニタリング: コンテナにプローブまたはヘルスチェック要求を送信し、その応答を評価します。
• パッシブモニタリング: 自然なクライアントの要求とその応答を観察します。

すべてのサービスのすべてのフォワード プロキシによるアクティブな監視により、ローカル ネットワーク上のトラフィックが大幅に増加し、リソースが不必要に消費されることが想像できます。 有効な監視は、少なくとも TCP レイヤーで行われ、理想的には HTTP レイヤーで行われます。 結局のところ、ネットワーク接続はサービスの健全性や可用性を示す指標ではありません。 TCP 接続を消費し、HTTP 処理が必要になると、ノード数 (およびフォワード プロキシ数) が増加するにつれて、コンテナーにすぐに負荷がかかります。 コンテナが監視によって過負荷になるため、スケールアップする必要はなくなります。

この場合、パッシブ監視は監視対象のシステムに負担をかけない点でより適切なオプションですが、一部のコンテナ環境では制限があります。 多くはオーバーレイ ネットワークの原則に基づいて構築されており、すべてのプロキシがすべてのサービス応答を確認して追跡できるようにするのは困難です。 不可能ではありませんが、ネットワーク層では困難です。

どちらのモデルもプロキシ自体に負担をかけるため、プロキシが実行すべきタスク (サービスのスケーリング) ではなく、環境の監視のみにリソースを割り当てる必要があります。

コンテナ化されたヘルスモニタリング 

コンテナ環境もこれらの課題を無視しているわけではありません。 これに応じて、可用性とスケールのためにフォワード プロキシを採用するアーキテクチャで可用性を確保するのに確実に役立つ 2 つの新しいモデルが登場しています。

その 2 つのモデルは次のとおりです。

• 環境モニタリング: プロキシは、コンテナ オーケストレーション環境 (COE) からのコンテナの健全性に関する情報により、健全性/可用性を認識します。
• 共有監視: 環境内には多くのプロキシが存在する可能性が高いため、監視作業をプロキシ間で分割し、結果を共有することができます。

環境監視は、コンテナがシステムに出入りするときにそれを追跡するサービス レジストリに関連付けられることがよくあります。 つまり、システム内のコンテナの可用性に関する最も信頼できる情報源となることがよくあります。 プロキシは、コンテナの作成と破棄によってトリガーされるイベントをサブスクライブして、それらのリソース自体を追跡することもできます (実質的には、プロキシ自体がレジストリとして機能します)。

たとえば、Marathon のアプリでヘルス モニタリングが有効になっている場合、プロキシは「healthCheckResults」フィールドを利用できます。 Kubernetes では、プロキシは活性チェックや準備チェックを使用できます。 環境ヘルス チェックにより、オーケストレーション システムが不健全なエンドポイントを再起動する前に、プロキシはより健全なエンドポイントの選択を開始できます。

共有モニタリングは、フォワード プロキシ モデルを採用しているシステム、特にIstioのようなサービス メッシュ基盤を持つシステムでは非常に有効です。 ノードに関連付けられたプロキシは、リクエストを転送しているコンテナの状態と可用性を確実に監視できます (リバース プロキシ モデルでサービスを追跡するのとほぼ同じ方法です)。 しかし、そのようなシステムでは、すべてのプロキシがすべてのエンドポイントを積極的に調査することは望ましくありません。 したがって、ローカルのヘルス情報を他のプロキシ (または環境と共有するとさらに良い) と共有することで、すべてのサービスで過度なヘルス チェックを実行することなく、システムの既知の状態全体をすべてのプロキシで取得できるようになります。

「ネットワーク」では、負荷分散などのアプリ サービスと、コンテナ化などの新しいモデルのニーズや要件を満たすためにそれらのサービスがどのように相互作用するかに関して、多くの変化が起こっています。 これらの要件により、プロキシには常に適応するプレッシャーがかかります。 これは、プロキシが過去 20 年間に開発された最も柔軟なテクノロジーの 1 つであり、アプリ サービスの設計、開発、展開の重要な基盤であり続けるためです。