コンテナのスケーリングの技術: 発見

コンテナのスケーリングは、サービスの前にプロキシを配置してそのまま放置するだけではありません。 スケーリングには配布以上のものが必要であり、コンテナのペースの速い世界では、再試行、サーキット ブレーカー、検出、配布、監視という 5 つの異なる機能がスケーリングの確保に必要です。

コンテナのスケーリングの技術に関するこの投稿では、発見について詳しく説明します。

発見

従来のスケールモデルは構成が比較的固定されています。 負荷分散プロキシは、アルゴリズムを使用して、かなり静的なリソース プールからリソースを選択します。 リソース (配布) の選択はリアルタイムのイベントであり、負荷や応答時間などのジャストインタイム変数を考慮する場合もありますが、全体的な環境はそうではありません。 オペレーターは、容量の増減を管理する企業定義のプロセスに基づいてリソースを追加および削除します。

現代のスケールモデルは、本質的に不安定かつ動的です。 現代のシステムにおけるスケールの前提は、すべてが「自動」であることに基づいています。 クラウドによって具体化された概念である自動スケールは、需要に基づいてリソース プールを拡大および縮小するという概念を強制します。ただし、これは従来のモデルから半歩進んだにすぎません。 負荷分散アルゴリズムが選択を行うリソースの「コア」プールの概念は依然として存在します。 そのプールは動的に拡大または縮小される可能性がありますが、依然として、それが動作するかなり伝統的なモデルによって制約されています。

コンテナ、特にコンテナ オーケストレーション環境は、その型から完全に抜け出します。 エンドポイント(イングレス) の概念は、コンテナベースのスケールにおける数少ない「固定」要素の 1 つであり、ルーティング ルールからサポート プールを構成するリソースまで、その他すべては非常に可変的であると考えられます。 理論上、コンテナは数秒しか存続できません。 しかし、実際の応用では、それらは通常数日間生存する傾向があります。 リソースが数か月（場合によっては数年）存続する従来のモデルと比較すると、この寿命は自動化なしでは耐えられないほどのプレッシャーをオペレーターにかけます。

したがって、検出はコンテナをスケーリングするための重要なコンポーネントです。 負荷分散プロキシは、1 分前と同じかどうかわからないリソース プールからリソースを選択できる必要があります。 そのため、ほとんどのコンテナ オーケストレーション環境には、プロキシがスケールを確保するためにリソースをリアルタイムで検出するのに役立つリソースの「レジストリ」が含まれています。

このプロセスでは、プロキシをコンテナ オーケストレーション エコシステムに統合するだけでなく、これらの環境の共通言語を話す必要があります。つまり、コンテナ オーケストレーション環境内では宣言型構成ファイル (リソース ファイル) とメタデータが使用され、プロキシがスケーリングするサービスに接続されているリソースを識別できるようになります。 これにより、プロキシはリソースの「プール」をリアルタイムで自動的に調整し、残念ながらすでにシャットダウンされているリソースを選択するという恥ずかしい事態を回避できます。

検出がなければ、負荷分散プロキシがコンテナ環境内のアプリケーションとサービスを効率的に拡張する方法はありません。 手動による構成方法では、このような環境の変化に対応することは不可能です。 どのリソースがアクティブで、特定のサービスに接続されているかを追跡するだけでも、ほとんどの時間が消費され、必要な変更を実際に行う時間がほとんどなくなります。

検出は、コンテナ オーケストレーション環境内のコンポーネントがリアルタイムで動作できる手段を提供し、オンデマンドでリソースを選択するために必要な情報を確保することで、負荷分散プロキシがアプリやサービスを拡張できるようにします。