Home 技術記事 大規模なサーバ最適化:パケットドロップの排除と容量の向上
Applications

大規模なサーバ最適化:パケットドロップの排除と容量の向上

About The Author

Outline

お客様とその視聴者の利益のために当社の技術のパフォーマンスを向上させることは、Verizon Media (現Edgio )の継続的な行動である。 たとえば、過去2年間で、当社のパフォーマンスエンジニアとカーネルエンジニアは、事実上すべてのパケットドロップを排除し(98%以上除去)、エッジサーバーのパフォーマンスヘルスチェックを50%改善し、サーバー容量を最大40%増加させた。

また、ネットワークの自動化と有機的なネットワーク拡張(現在250 Tbps以上)を組み合わせて、ユーザーエクスペリエンスを向上させた。 数百万台のゲーム機にソフトウェアアップデートを配信したり、主要なスポーツイベントに向けてライブビデオストリームを配信したり、マルチCDNロードバランサーがネットワークに負荷を移動するときに、私たちのパフォーマンスを慎重に調整することは、急速に変化し、時には予測不可能なネットワークサージをサポートする能力において大きな役割を果たしてきた。

品質を大規模に維持するには、Edgio Media Platformの技術スタックのすべての部分でパフォーマンスを最適化する必要がある。つまり、下位レイヤーからCPUとNIC、OSとアプリケーションに至るまで。 究極的には、私たちの目標は常に同じであり、優れたパフォーマンスである。 そのために、データドリブン分析を行い、測定可能なパフォーマンスの変化に基づいて意思決定を検証する。

CPUキャッシュの最適化

世界中で20,000台のサーバーを稼働しており、その大部分はBroadwellとHaswellチップセットで、通常は32から40コアである。 過去3年間だけで12,000台のサーバを追加 しかし、ほとんどのサーバーは、すぐに使用できるワークロードに合わせて拡張できるように最適化されていない。 サーバを追加するだけでは、運用効率が向上せず、課題が増える可能性がある。 効果的なスケーリングには、既存の構成要素の慎重な最適化が必要である。 1台のサーバを最適化して、デフォルト設定よりも2倍または3倍(またはそれ以上)の要求を処理できるようにすることは、ネットワーク全体のパフォーマンスに大きな違いをもたらす。

早期のスヌープから自宅のスヌープへの切り替え

最近のCPUはスヌーププロトコルを採用しており、ローカルCPUのキャッシュがメモリと一貫性を持つことを保証している。 これにより、キャッシュは任意のCPU上の変数の変更を待ち受け、それに応じてそれらの変数のバージョンを更新することができる。 驚くことではないが、使用される特定の技術はメモリ性能に大きな影響を与える可能性がある。

デフォルトでは、弊社のハードウェアベンダーはEarly Snoopと呼ばれるプロトコルを使用している。 全てのコアが同時にキャッシュコヒーレンシー要求を行い、ブロードキャストを送信することができるため、キャッシュコヒーレンシーを解決するレイテンシが低い。 我々のシステムは、ピーク負荷シナリオ中に大量のディスクとNICアクティビティを同時に生成することがわかった。 これらの活動は、高スヌープブロードキャストをもたらし、通信のボトルネックにつながる。 これによりIOデバイスの動作が遅くなり、最終的には処理が完全に停止する。

スヌープ要求をまとめるホームスヌープモードに切り替えることで、ブロードキャストトラフィックが大幅に減少した。 プロセッサのQuick Path Interconnect(QPI)は、ディスクとネットワークIOが同時に処理される間に飢えることがなくなった。さらに、Early Snoopで見たパケットドロップの数が大幅に減少した。

スヌーププロトコルの変更はBIOS設定の変更に依存する。 しかし、顧客を混乱させずに20,000台のサーバを再起動するには、自動化が必要である。 StackStormベースのIT自動化プラットフォームであるCrayfishのおかげで、このような大規模な展開変更を実稼働環境で実行できるようになった。

予期しないフェイルオーバーイベント

Home Snoopへの切り替えをテストしているときに、フェイルオーバーが発生した。マルチCDN展開を行っている当社の大手メディア顧客の1社が、別のベンダーで問題を起こし、トラフィックの大部分を当社のCDNに移動した。 これは、非常に影響力のある大規模なホームスヌープの改善をテストする機会を提供した。

上記の図は変更の効果を示している。 まだEarly Snoopを使用しているグループでは13.75倍(1日あたり55Kパケットドロップ)のドロップが増加したが、Home Snoopに切り替えたグループでは4.23倍(1日あたり27Kパケットドロップ)にとどまった。 Home Snoopはフェイルオーバーイベント中にすぐにその値を証明した。

ネットワークインターフェイスの最適化とドライバの調整

もう一つの重要な性能調整には、ネットワークインターフェイスとドライバが含まれていた。 ここでは、通常バーストトラフィックで発生するパケットドロップをダウンさせることに焦点を当てた。 大規模なイベントでは、受信トラフィックが非常に重く、NICが追いつくことができず、パケットのドロップが予想よりも早く発生した。 その理由を掘り下げていくと、キューの数、キューのサイズ、割り込みスケジューリングなど、NIC自体のいくつかのパラメータを調整する必要があることがわかった。 我々の特定のワークロードとハードウェア構成に対してこれらの仕様を最適化するために、我々は受信側スケーリング(RSS)の調整に集中し、受信キューを長くし、全体の数を減らし、NUMAノード間の割り込みのバランスをとる。

上のグラフは、北米で実施したテストを示しており、各PoPはコントロールグループ(すなわち、調整されていない)とテストグループ(すなわち、調整されている)に分割されている。 ここでは、1週間に1日に合計されたドロップ数を提示する。 調整後、我々のテストグループでは、制御グループに比べてパケットドロップが約95%減少し、処理されるリクエスト数が大幅に増加した。 これはまた、サージ時にネットワークの健全性を手動で管理するために必要なアクションが少なくなり、エンジニアが他の分野に集中できるようになることを意味する。

CPUスケジューリングチューニング

NICとドライバレベルのチューニングは、提供可能な総容量の向上に集中していたが、CPUスケジューリングのチューニングは、コンテンツを一貫して提供できる方法を強化することに集中していた。

これらの調整がなければ、受信メッセージと送信メッセージはリソースを競わなければならない。 根本的な原因を調査し始めたとき、リソースの競合はカーネルがこれらのメッセージの処理をどのようにスケジューリングしていたかに起因していることがわかった。 これは、問題のCPUが飽和するまで、トラフィックのピーク時に負荷が移行されないことを意味している。 この問題を解決するために、ウェブサーバプロセスのCPUアフィニティを設定して、受信ネットワークトラフィックの処理専用CPUを除外した。

上記のグラフは、3月21日から22日にかけてCDN全体でCPUスケジューリング調整をグローバルに有効にした場合の影響を示している。 パフォーマンスヘルスチェックメトリックの95パーセンタイルと中央値に基づいて影響を評価する。パフォーマンスヘルスチェックメトリックは、サーバーの相対的な応答時間を示す複合メトリックである。 予想されていたように、交通量の少ない谷は大幅に減少しなかったが、ピークは、着信トラフィックと発信トラフィックの間の競合が大幅に減少したことを明らかにしている。 これは、特にピーク負荷時の外れ値と中央値の両方に大きな改善を意味する。 トラフィックの急増に対応し、ビデオストリームの再バッファや全ユーザーに対するサーバーの全体的な応答性など、高い外れ値の動作に関連する問題を解決できるようになった。

カーネルパフォーマンスの更新

TECHスタックの上層を最適化することは、下層の要素を調整することと同じくらい重要である。 最近OSをアップグレードする過程で、Linuxカーネルコミュニティから上流のエンジニアリング作業を利用するために、Linuxカーネルもアップグレードした。 新しいカーネルは、メモリ管理システムの改善を含む、以前のバージョンよりも約4年間の開発期間を経て、ページのブロック割り当てを減らし、epoll APIとソケットシャーディングを使用する際の負荷分散とパフォーマンスを改善した。

上のグラフでは、11月下旬から1月上旬にかけてのアップグレードプロセスの影響が、99パーセンタイルパフォーマンスヘルスチェックの低下として見られる。 基盤となるカーネルの改良により、ウェブサーバのリクエストプロセッサ全体でより均等な負荷分散が実現した。 その結果、これらの外れ値が大幅に減少し、すべてのお客様の要求がより信頼できるものになった。

パフォーマンスのチューニングは大きな効果をもたらす

過去2年間で、パフォーマンスとカーネルエンジニアリングが展開した広範囲にわたるシステムチューニングにより、事実上すべてのパケットドロップが排除され(98%以上除去された)、エッジサーバーでのパフォーマンスヘルスチェックが半減した。 サーバー容量が10~40%増加したため(正確な量はお客様のプロファイルやイベントによって異なる)、より多くのトラフィックをより迅速に配信できるようになった。 外れ値の挙動は大幅に改善され、より一貫したエクスペリエンスを実現しており、特にピーク負荷時の中央値に良好な改善が見られた。 要約すると、TECHスタック全体へのパフォーマンスチューニングにより、予期しないトラフィックスパイク(ゲーム機のアップデートや人気のあるストリーミングビデオのライブイベントなど)をより適切に処理し、すべてのユーザーに一貫したパフォーマンスを提供できるようになった。