コンテナのスケーリングの技術: 分布

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

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

分布

何かをスケーリングするための秘訣は、常に、リクエストが有限のリソースセット全体にどのように分散されるかに部分的に依存してきました。 クラウドとその無限とも思えるコンピューティングの供給でさえ、そのレシピを変えることはできません。 リクエストを受信した時点では、そのリクエストを受け入れて処理できるリソースのリストは有限です。 期間。

したがって、リクエストをどこに送信するかの決定は非常に重要になります。 間違ったリソースに送信すると、パフォーマンスが低下する可能性があります。 適切なリソースに送信すれば、消費者/従業員は結果に満足するでしょう。

スケールの初期の頃は、こうした決定はアルゴリズムのみに基づいていました。 ラウンドロビン。 接続が最も少ない。 最速の応答。 これらの強力なメカニズムは今日でも存在していますが、ゆっくりと確実に、意思決定プロセスにおける唯一の要素ではなく、単なるもう 1 つの要素になってきています。

これは、接続ベースの意思決定プロセス（別名「従来の単純な負荷分散」）のみに依存しなくなったためです。 負荷分散が主に TCP 接続の管理に関するものであったときは、接続に基づく分散スキームが理にかなっています。 しかし、スケールはアルゴリズムと同じくらいアーキテクチャに基づいており、リクエストの分散はレイヤー 4 プロトコルより上 (文字通り) およびそれを超える多くの変数を伴う複雑な計算になる可能性があります。

分散を複雑にしているのは、今日のアーキテクチャ自体がますます分散化しているという現実です。 クラウド間だけでなく、コンテナ間でも。 同じアプリ (または API) の複数のバージョンが同時にサービスされている場合があります。 リクエストの配布を担当するシステムは、それらを認識して区別し、適切なエンドポイントに配信できるようにする必要があります。

現在、決定は接続容量だけでなく、レイヤー 7 (HTTP) パラメータに基づいて行われることが多くなっています。 ホスト名。 API メソッド (別名、URI)。 API キー。 バージョン番号が埋め込まれたカスタム HTTP ヘッダー。 位置。 デバイス。 ユーザー。 リクエストは作成されたコンテキストで評価され、マイクロ秒単位で決定が下されます。

今日の配布には、階層化されたアーキテクチャアプローチが必要です。 アプリのアーキテクチャを深く掘り下げていくと、粒度は粗くなります。 プロキシが同じマイクロサービスの X 個のクローン間で負荷分散の決定を行う頃には、従来のアルゴリズム駆動の方程式のみを使用している可能性もあります。 一方、環境の外側では、イングレス コントローラーがHTTP レイヤー変数に基づいて複雑な決定を下すことがあります。

外部的には、配布はアーキテクチャによって推進されます。 内部ではアルゴリズムによって。

どちらもコンテナのスケーリングにとって重要なコンポーネントであり、おそらく最も重要なコンポーネントです。

どちらも、リクエストを配布する可能性のあるリソースの状態 (健全性) に関する正確なリアルタイム情報に依存します。 このシリーズの次の数回の記事では、監視について説明します。