意図しない結果: 負荷がかかっているプロキシ

スケーラビリティの必要性は、今日では疑問の余地さえありません。 答えは常に「はい、必要です」です。 ビジネスの成長は、結局のところ、業界を問わず今日のビジネス モデルに不可欠なアプリケーションの運用の成長に依存します。 そのため、システムは一般的に、必要になったときに（必要かどうかではなく）その規模を達成するために必要なものとともに導入されます。 それは通常プロキシを意味します。 したがって、スケールを担当するプロキシ (通常はロード バランサ) は、あらゆる最新アーキテクチャにおいて非常に重要なコンポーネントです。

これらのプロキシはスケーリングのメカニズムとして機能するだけでなく、自動スケールの驚異的な機能を通じて、自動的にスケーリングを行うように要求されることが増えています。 このシンプルなハイフンでつながれた単語には、多くの意味が含まれています。たとえば、プログラムによってシステムに指示して、追加容量を起動するだけでなく、スケーラビリティを担当するプロキシがその存在を認識し、リクエストを送信できるようにする機能などです。

価値のあるプロキシであれば、必要なプログラム インターフェイスを備えていると想定されます。 API エコノミーは、アプリと人々の間での共有だけではありません。結局のところ、オンプレミスとクラウド内のシステム間での共有も意味します。 しかし、負荷分散プロキシに新しいリソースを追加するタスクは、データ プレーンではなく、管理プレーンまたは制御プレーンで実行されることに気付いていないことがよくあります。

それは理にかなっています。 統計情報を収集したり、構成を操作したりしている間は、システムの実行に干渉したくありません。 特に、システムがフル稼働して熱心なユーザーにアプリを配信しているために容量を追加しようとしている状況では、これは絶対に避けるべきことです。

しかし、逆のことが起こったらどうなるでしょうか? システムの実行がシステム管理能力に干渉する場合はどうなりますか?

自動スケーリング（または手動スケーリング）は失敗します。 つまり、アプリの容量は増加せず、ビジネスに悪影響が出ることになります。

それは悪いことだ、私にそんなことを言われる必要があるかのように。

これが起こる理由は、多くのプロキシ (このパラドックスを考慮して構築されていない) が、コントロール プレーンとデータ プレーンの両方でシステム リソースを共有しているためです。 彼らの間には孤立はありません。 プロキシの管理には、アプリを配信するのと同じネットワークが使用されます。 アプリを配信するために割り当てられたものと同じ RAM とコンピューティングがプロキシの管理に割り当てられます。 負荷がかかっている場合、これら 2 つのうち 1 つだけがリソースを取得します。 スケーリングのためにプロキシにアプリ リソースを追加しようとしていて、そのためにシステムにアクセスできない場合は、かなり困ったことになります。

そのため、管理性を考慮してプロキシの選択を評価することが重要です。 管理のしやすさだけではありません。 API とスクリプト機能だけでなく、負荷がかかった状態での管理性も優れています。 大規模なスケール向けに特別に設計されたプロキシには、「管理」リソースとして指定された別のリソース セットが必要です。これにより、配信アプリによってデータ プレーンにどれだけ負荷がかかっても、管理と監視が継続されます。

ネットワークの世界では、これはデータ パス (プライマリ パス、クリティカル パス) の外部で行われるため、アウトオブバンド管理と呼ばれます。

負荷がかかった状態で帯域外でプロキシを管理する機能は、アプリと、それを通じてビジネスを自動または手動で拡張する全体的な機能において重要です。