クラウドネイティブアプリケーションの開発は急速に進んでいます。まだアプリケーションポートフォリオの主流にはなっていませんが、その数は増加しています。クラウドネイティブ（マイクロサービスベース）アーキテクチャでは、通信とスケーリングをインフラストラクチャに依存するという特性があるため、コンテナへの関心と密接に関連しています。
通常、マイクロサービスのスケーリングは、水平方向に複製することで実現します。つまり、特定のサービスのインスタンスを増やす必要がある場合は、そのサービスを複製し、ロードバランサーがリクエストへの応答に使用するインスタンスを選択できるプールに追加するだけです。実に簡単です。こうしたマイクロサービスが機能要素と密接に対応している場合、このモデルはさらに効果的に機能します。
このロードバランサーは、多くの場合、コンテナオーケストレーターのコンポーネントであり、デフォルトでは業界標準のTCPベースのラウンドロビンアルゴリズムを使用します。つまり、リクエストを受信すると、ロードバランサーが「次の順番」のリソースを応答先として選択します。
この方式は、銀行やDMV（車両管理局）の窓口で順番を待つ列に例えられることがよくあります。しかし、これは必ずしも正確ではありません。真のラウンドロビン方式では、「次に空いた」リソースではなく、たとえ処理中であっても「順番が次の」リソースに振り分けられます。皮肉なことに、DMVや地域の銀行で採用されている振り分け方式のほうが、真のラウンドロビンアルゴリズムよりも効率的です。
そう思いますよね？
これはアプリケーションにも当てはまります。同じ一連のリクエストを処理するため、機能レベルで同一のサービスが複製されることもあります。しかし、データが異なれば、各リクエストの実行負荷が常に同じになるとは限りません。そう、データです。同じ機能リクエスト、つまりAPI呼び出しでも、送信または要求されるデータによって実行時間は変わります。1件の顧客レコードを取得してシリアライズする方が、10件や100件の顧客レコードを取得してシリアライズするよりも短時間で済むのは当然です。
ここでラウンドロビンの弱点が表れ、パフォーマンスに影響し得るばらつきが生じます。運用上の公理#2は、クラウドネイティブおよびマイクロサービスベースのアーキテクチャにも当てはまります。つまり、負荷が増加すると、パフォーマンスは低下するということです。
ラウンドロビンはラーテルのようなものです。大量のデータセットを返すリクエストによってリソースに過剰な負荷がかかっていても、気にしません。準備ができているかどうかにかかわらず、ラウンドロビンは「次はあなたです」と割り当てます。その結果、負荷が増し続けるリソースのキューにリクエストが入ったユーザーは、パフォーマンスが不安定になる可能性があります。
パフォーマンスを重視するのであれば（当然、重視すべきです）、最小接続数や最速応答時間など、ほかの標準アルゴリズムのほぼどれを選んでも、より適切な選択肢となります。要するに、最適とは限らないリソースへ無条件にリクエストを振り分けるのではなく、負荷や速度、またはその両方を考慮するアルゴリズムを選ぶことが重要です。
ロードバランシングの未来
TCPからHTTP、さらにHTTP+へとスタックの上位層に移行すれば、この問題は自然に解消されると考える方もいるかもしれません。しかし、決してそうではありません。どのレイヤーを基盤とする場合でも、分散方式、つまりロードバランシングアルゴリズムは依然として重要です。ラウンドロビンはアーキテクチャではなくリソースに着目し、利用可能なプールに基づいて判断します。そのプールが単一のAPI呼び出しをスケールさせるためのものか、モノリス全体をスケールさせるためのものかは、アルゴリズムにとって違いはありません。
そのため、クエリの実行結果が「平均を上回る」データ量になることを、ロードバランサーが実行前に認識できるほどインテリジェントであれば理想的です。F5 WAFのようなWebアプリケーションファイアウォールは、通常とは異なる結果を認識できます。ただし、これはレスポンスに対するものであり、主にアプリケーションセキュリティの強化に役立ちます。必要なのは、正当なレスポンスが「特大」になることを予測できるほど、ロードバランサーをインテリジェントにすることです。
ロードバランサーにそのような判断能力があれば、その点を考慮して、利用可能なリソース全体にリクエストをより均等に分散できます。本当に必要なのは、意思決定の基準となる固定的なアルゴリズムを指定せずに済むことです。ロードバランサーが、レスポンスタイム、予想実行時間、返されるデータのサイズ、各リソースの現在の負荷といった技術的特性やビジネス上のしきい値に基づいて判断できれば、より望ましいでしょう。
最終的に、このようなインテリジェンスは、可視性の向上と機械学習によって初めて実現できます。ロードバランサーが経験から学習し、ほかのクエリよりも時間がかかるクエリを識別できれば、その知識を活用してリクエストをより適切に分散し、一貫性のある予測可能な応答時間を実現できます。
ロードバランシングがなくなることはありません。ネットワークからアプリケーションに至るまで、あらゆるものをスケーリングするための最も有効な技術的手段です。しかし、より動的かつ自律的でインテリジェントなものになるには、インフラストラクチャの他の部分とともに進化する必要があります。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。