POPに到着した要求は、要求URIに基づいて異なるサーバにロードバランシングされます。
要求がPOPに到着すると、フロントエンドサーバーは要求を処理し、要求されたURIに基づいて要求をキャッシュサーバーにマッピングします。 コンシステントハッシュ(正確にはCarp-Cache Array Routing Protocolを使用したランデブーハッシュ)により、サーバーが正常である限り、同じリソースが常に同じキャッシュサーバーにマッピングされることが保証されます。 この一貫したマッピングは、パフォーマンスにとって重要です。 リクエストされたリソースがキャッシュにないサーバーにリクエストを送ると、別のサーバーからリソースをフェッチする必要があり、レスポンスレイテンシーが増加します。 重要なのは、一貫性のあるハッシュにより、POP内のすべてのキャッシュサーバーにリソースを均等に分散できるため、ワークロードの分散に役立ちます。
ただし、リソースの人気はさまざまであり、人気のあるリソースを提供するサーバーは、POP内の他のリソースよりもはるかに多くのトラフィックを提供することになります。 そのため、リソースが急速に普及し、サーバーのネットワークまたはCPUリソースのかなりの部分を消費し始めると、ホットファイリングと呼ばれるメカニズムが働きます。 ホット・ファイリングは’このリソースを1台以上の追加サーバにすばやくレプリケートします レプリカが存在するサーバをフロントエンドに通知することで’リソースによって生成される負荷の分散が大きくなります
改善の余地がある
今日ホット・ファイリングをトリガーするロジックは’固定しきい値に基づいていますこのしきい値によって’サーバが処理する要求またはバイトの事前に定義されたレートを超える処理を単一のリソースが処理しないことが保証されます リソース負荷がそのしきい値を超えると、さらに分散されます。 ただし、しきい値が固定されている場合の課題は、サーバーの負荷のかなりの部分が、そのしきい値をわずかに下回るリソースによって生成された場合、それらのリソースはHotファイルされないことです。 そのため、それぞれのリクエストロードは分散されません。
このため、リソースベースのロードバランシングとホットファイリングを組み合わせても、POP内のサーバー間の負荷分散が不均一になることがよくあり、一部のサーバーでは中央値の2 ~ 3倍以上の負荷が発生します。
ネットワーク負荷分散の不均一性は、多くのPOPで常に一般的であり、一部のサーバでは中央値よりも最大2倍多くのトラフィックを配信しています。
サーバが容量に達していない限りパフォーマンスを維持できるため、この不均一性は必ずしも問題になるとは限りません。 ただし、極端な場合には、影響が非常に明白になる可能性があります。 次の図は、この効果の実際の例を示しています。
2台のサーバがネットワーク容量に達しているか、それを超えている一方、残りのPOPサーバはトラフィック量が少なくなります。 異常値のサーバは、ヘルスチェック(応答時間)で明らかにインフレに苦しんでいます。
この特定のPOPにおけるネットワーク負荷分散のスナップショットでは、ほとんどのサーバが低ボリュームのトラフィックを送信していますが、2つのサーバが中央値の2倍以上の負荷を処理しており、1つまたは少数の非常に人気のあるリソースによって容量に達しています。 これは、最小応答時間の代理であるヘルスチェックメトリックに観察可能な影響を与えます。 通常、このメトリックの正常値は1 ms未満であり、10 msを超えるとアラートが生成されます。 この例では、ヘルスチェックは100ミリ秒を超える値に増加し、少なくとも1時間持続しました。この間、過負荷のサーバのパフォーマンスが低下した可能性があります。
また、いくつかのサーバーが、最大数日間、残りのPOPよりも永続的に多くロードされている場合も観察されています。 このような期間中、これらのロードされたサーバは、一般に、POP内の他のサーバよりも着信トラフィックスパイクに対する復元力が低くなります。 これは、POPの残りの部分には利用可能な容量があるが、負荷が容量に達するかそれを超える可能性があるため、ピーク時に悪化する。
アダプティブ要求ロードバランシングシステム
これらの観察に基づいて、動的しきい値を使用したホットファイリングのアイデアを研究しています。 このアプローチでは、任意の時点でのサーバ間の負荷分散と、各サーバがその分散内のどこにあるかを考慮します 。 これらの条件に基づいて、負荷分散におけるサーバの位置に応じて、サーバ固有のしきい値が計算されます。 負荷が中央値より高いサーバには、負荷が低いサーバよりも低いしきい値が割り当てられ、分散の末尾にあるサーバのオフロードが高くなります。
サーバしきい値は、各サーバの現在の負荷分散場所に基づいて生成されます。 負荷が中央値より高いサーバには、負荷が低いサーバより低いしきい値が割り当てられます。
具体的には、ホットファイルのレベルを制御する2つのパラメータを定義します。
- BaseThresh は、各サーバのしきい値のベースライン値を制御します。 この値からサーバー固有のしきい値が導出され、現在の負荷に応じてサーバー用に調整されます。
- α ∈(0, 2)は、アルゴリズムがオフロードを必要とするサーバーのウェイトをどの程度積極的に調整するかを制御します。
次に、POP内の各サーバについて、次の式を使用して、サーバの現在の負荷に反比例する重みW(s)∈(0, 2)を生成します 。
ここで、α∈(0, 1) BW(s) は現在のサーバー負荷です。 BWmin は最も負荷の低いサーバーの負荷です。BWminは最も負荷の高いサーバーの負荷 です。次に、各サーバーのしきい値 Tは 次のように計算されます。
この実装では、BaseThreshをワークロードに適合する値に設定します。 αの値をアルゴリズムに動的に選択させます。これにより、負荷の点で中央値から非常に離れている場合に、よりアグレッシブなオフロードが外れた(負荷の高い)サーバに適用されます。
CDN本番ワークロードを使用した評価
本番ワークロードのスナップショットを使用して、シミュレーションでのアプローチを評価します。 POP内のサーバ間の負荷分散における歪み(変化)を測定するには、「歪み係数」を定義します。
つまり、Sは、最も負荷の高いサーバーが中央値からどれだけ離れているかを測定します。 たとえば、S=2は、最も負荷の高いサーバーが中央値の2倍の負荷を提供することを意味します。 理想的には、すべてのサーバーを中央値に近づけるため、Sの値が低い方が優れています(理論上の最適値はS=1です)。 次の図は、動的しきい値、各イテレーションで生成される新しいホットファイルの数、各イテレーションでピックされたαの値に基づいて、ホットファイリングプロセスの複数のイテレーションでSがどのように変化するかを示しています。
アルゴリズムを何度か繰り返した後の負荷分散。 最も負荷の高いサーバの負荷は、中央値の1.42倍の2.73倍から減少し、POP内のトラフィックはより均等に分散されます。
青い線(「開始」)は開始状態を示し、POPでの負荷分散の実際のスナップショットを表します。 ホットファイル(HF)が生成されないポイントに達するまで、各反復後にSが減少していることに注意してください。 各反復でテールがトリミングされると、分散はより均一になり、中央値の負荷に近いサーバが増えます。
次に、同じ実験10 Timesを6 different popに対して繰り返します。
6 Popの歪み係数(S)の変更。 Sは5反復で収束し、平均で92%減少します。
図の各バーのグループは異なるポップを表し、グループ内の各バーは後続の反復を表します。 各グループの最初のバーは、本番ワークロードのスナップショットから取得された開始状態を表します。 各バーは10ランの値を表します。 すべての場合において、Sの減少は、Sがより許容可能な値に達している次のどの反復よりも、最初の反復ではるかに劇的であることがわかりました。 重要なのは、分布の広がり(ウィスカーによって示されている)と外れ値(ダイヤモンド)も同様に減少することです。 ロードバランシングメカニズムは、少数の反復の後に収束し、新しいアンバランストラフィックによってSがハイになったときにのみトリガーする必要があることがわかりました。
次のステップ
POP内のサーバ間で負荷を分散することは、パフォーマンスにとって重要です。 急速に普及しているリソースのためにある程度の不均一性が予想されますが、POPの残りの部分で使用可能な容量にもかかわらず、サーバーの過負荷が持続すると、より多くの着信トラフィックスパイクに対するパフォーマンスと復元力に影響を与える可能性があります。 本研究では、このような負荷の不均一性を軽減するために、既存の負荷分散メカニズムの強化を検討しました。
シミュレーション結果は有望であったため、この変更を既存のメカニズムに組み込み、生産の結果をモニタリングしています。 この製造方法をテストすることで、より現実的な結果を得て、シミュレーションで定量化が困難な追加の要因を評価することができます。 このような要因には、高度に動的なワークロードに対する復元力、時間帯の影響、リソースレプリケーションの変更、関連するオーバーヘッドなどがあります。
当社のWebサイトでは、コンテンツ配信ネットワークがどのようにパフォーマンス、セキュリティ、信頼性を向上させるかについて詳しく説明してい ます。