負荷分散の未来はデータにかかっています

クラウドネイティブapplicationsは急速に構築されています。 まだアプリポートフォリオの大部分を占めているわけではありませんが、その数は増加しています。 コンテナへの関心は、通信とスケールのインフラストラクチャへの本質的な依存性のため、クラウド ネイティブ (マイクロサービス ベース) アーキテクチャと密接に関連しています。

通常、マイクロサービスのスケーリングは水平クローンによって実現されます。 つまり、特定のサービスのインスタンスをさらに必要とする場合は、そのサービスを複製し、ロード バランサーがリクエストに応答するために選択する利用可能なプールに追加するだけです。 簡単だよ。 これらのマイクロサービスが機能要素を厳密に表す場合、このモデルはさらに効果的に機能します。

問題のロード バランサは、多くの場合、コンテナ オーケストレータのコンポーネントであり、デフォルトでは業界標準のラウンド ロビン TCP ベースのアルゴリズムが使用されます。 つまり、リクエストが到着すると、ロード バランサーは応答するために「次の」リソースを選択します。

この方法は、銀行や DMV の行列に例えられることが多いですが、それは完全に正確ではありません。 真のラウンドロビン シナリオでは、「次に利用可能な」リソースに誘導されることはありません。 そのリソースがビジー状態であっても、「次の順番」のリソースに誘導されます。 皮肉なことに、DMV と地元の銀行での配布方法は、真のラウンドロビン アルゴリズムよりも効率的です。

私は当然知っている？

これはapplicationsにも当てはまります。 同じサービスは、機能レベルであっても、同じリクエスト セットを処理するため、複製される可能性があります。 しかし、データが原因で、これらのリクエストは実行の点では必ずしも同等ではありません。 そうです、データです。 同じ機能リクエスト (または API 呼び出し) でも、送信またはリクエストされるデータによっては、実行に多少時間がかかる場合があります。 結局のところ、10 または 100 の顧客レコードを取得してシリアル化するよりも、1 つの顧客レコードを取得してシリアル化する方が時間がかかりません。

ここでラウンドロビンが少し崩れ、パフォーマンスに影響を与える可能性のある変動性が生じます。 運用上の原則 2 は、クラウド ネイティブおよびマイクロサービス ベースのアーキテクチャにも適用されます。つまり、負荷が増加すると、パフォーマンスが低下します。

ラウンドロビンはハニーバジャーのようなものです。 応答として大量のデータ セットを含む要求によってリソースが過負荷になっても問題ありません。 ラウンドロビンでは、準備ができているかどうかに関係なく、「次はあなたです」と言われます。 その結果、リソースの負荷が増大するキューにリクエストが投入されるユーザーに対して、パフォーマンスの不均一が生じる可能性があります。

パフォーマンスを気にしているなら (気にするべきですが)、より良い代替案は、最小接続数や最速応答時間など、他の標準的なアルゴリズムのいずれかを使用することです。 基本的に、アルゴリズムでは、最適ではない可能性のあるリソースに単に盲目的にリクエストを押し付けるのではなく、負荷や速度を考慮する必要があります。

負荷分散の未来

TCP から HTTP、そして HTTP+ へとスタックが上がっていくにつれて、この問題は自然に解決されるだろうと考える人もいるかもしれません。 それは全く違います。 分散方法 (負荷分散アルゴリズム) は、どのレイヤーを基盤としているかに関係なく、依然として重要です。 ラウンドロビンはアーキテクチャを考慮せず、リソースを考慮し、利用可能なプールに基づいて決定を下します。 そのプールが単一の API 呼び出しをスケーリングするためのものか、モノリス全体をスケーリングするためのものかは、アルゴリズムに違いをもたらしません。

したがって、クエリが実行される前に、クエリの結果が「平均を超える」データになるかどうかをロード バランサーが認識できるほどスマートであれば便利です。 F5 WAFなどの Webapplicationファイアウォールは、結果が異常であるかどうかを認識できますが、これは応答に関するものであり、主にapplicationのセキュリティの向上に役立ちます。 必要なのは、ロード バランサーが「非常に大きな」正当な応答を予測できるほど賢くなることです。

ロード バランサがそのような識別能力を持っていれば、それを意思決定に考慮し、利用可能なリソース間でリクエストをより均等に分散することができます。 私たちが本当に望んでいるのは、決定を下すための厳格なアルゴリズムを指定することを強制されないことです。 ロード バランサーが、応答時間、予測される実行時間、返されるデータのサイズ、各リソースの現在の負荷などのビジネスしきい値と技術的特性に基づいて決定を下すことができれば、より効果的です。

結局のところ、これは、より優れた可視性と機械学習を通じてのみ実現できる種類のインテリジェンスです。 ロード バランサが経験を通じて、どのクエリが他のクエリよりも時間がかかるかを認識できるようになると、その知識を適用してリクエストをより適切に分散し、一貫性のある予測可能な応答時間を実現できるようになります。

負荷分散はなくなることはありません。 これは、ネットワークからapplicationsまですべてを拡張するための当社の最善の技術的対応です。 しかし、より動的、自律的、インテリジェントになるためには、インフラストラクチャの他の部分とともに進化する必要があります。