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

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

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

リソースの存続期間が数時間や数日ではなく、数分単位となる可能性がある環境では、リクエストの送信先を決定する前にリソースの状態を把握することが、さらに重要になります。

ヘルスモニタリングは、ロードバランサーやプロキシに不可欠な機能です。コンテナ化された環境でも同様です（少なくとも、そうあるべきです）。こうした環境が急速に成熟するにつれ、変動が激しい分散システムに特有の課題に対処するため、新たなモニタリングモデルが登場しています。

従来のヘルスモニタリングも確かに必要ですが、コンテナ環境内の一部の可用性とスケーリングのモデルは、従来のヘルスモニタリングに対処すべき負荷をもたらします。たとえば、フォワードプロキシモデルで導入されたプロキシには、考えられる正常な（利用可能な）ターゲットをすべてのサービスから選択できることが求められます。リバースプロキシ（いわゆる従来型のロードバランサー）が、単一のアプリケーションに属するごく限定的なサービス群の状態だけを追跡すればよいのに対し、フォワードプロキシは、環境内のすべてのアプリケーションについて、あらゆるサービスの状態を把握する必要があります。すでに停止しているコンテナにリクエストを送信するのは、当然避けるべきですからね。

従来型のヘルスモニタリング

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

• アクティブ監視： コンテナにプローブまたはヘルスチェックリクエストを送信し、その応答を評価します。
• パッシブ監視： 通常のクライアントリクエストとそのレスポンスを観察します。

すべてのサービスを各フォワードプロキシがアクティブに監視すると、ローカルネットワークのトラフィックが大幅に増加し、リソースが不必要に消費されることは容易に想像できます。有用な監視を行うには、少なくともTCPレイヤー、理想的にはHTTPレイヤーで実施する必要があります。ネットワークに接続できることは、サービスの正常性や可用性を示すものではないためです。ノード数、ひいてはフォワードプロキシ数が増えるにつれて、TCP接続の消費とHTTP処理の負荷により、コンテナには急速に負担がかかります。監視によってコンテナが過負荷になり、スケールアップが必要になる事態は避けるべきです。

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

どちらのモデルもプロキシ自体に負荷をかけます。そのため、本来の役割であるサービスのスケーリングではなく、環境の監視だけにリソースを割く必要があります。

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

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

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

• 環境モニタリング： プロキシは、コンテナオーケストレーション環境（COE）から提供されるコンテナの健全性情報に基づいて、健全性と可用性を把握します。
• 共有監視： 環境内には多数のプロキシが存在する可能性が高いため、監視作業を各プロキシに分散し、その結果を共有できます。

環境監視は、多くの場合、システムに出入りするコンテナを追跡するサービスレジストリと連携しています。そのため、サービスレジストリは、システム内のコンテナの可用性について最も信頼できる情報源となることがよくあります。また、プロキシはコンテナの作成時と破棄時に発生するイベントをサブスクライブし、それらのリソースを自ら追跡することもできます（実質的に、プロキシ自体がレジストリとして機能します）。

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

共有監視は、フォワードプロキシモデルを採用するシステム、特にIstioのようなサービスメッシュを基盤とするシステムで非常に有効です。ノードに関連付けられたプロキシは、リクエストの転送先となるコンテナの健全性と可用性を監視できます（リバースプロキシモデルでサービスの状態を追跡する場合とほぼ同様です）。ただし、このようなシステムで、すべてのプロキシがすべてのエンドポイントを能動的にプローブすることは望ましくありません。そこで、ローカルの健全性情報を他のプロキシ（さらに望ましくは環境）と共有すれば、各サービスに過剰なヘルスチェックを実行することなく、すべてのプロキシがシステム全体の既知の状態を把握できます。

ロードバランシングなどのアプリケーションサービスや、コンテナ化のような新しいモデルのニーズと要件を満たすためのサービス間連携という観点から、「ネットワーク」では多くの変化が起きています。こうした要件により、プロキシには絶えず適応が求められています。プロキシは、過去20年間に開発されたテクノロジーの中でも特に柔軟性が高く、現在もアプリケーションサービスの設計、開発、デプロイを支える重要な基盤であるためです。

著者について

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

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

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