Netflixによるインスタンス負荷改善のための解析事例

LinkedInの記事をめぐっているうちに見つけた、マイクロアーキテクチャに関する面白い事例。 CPUのマイクロアーキテクチャのさらに奥深くまで理解が必要な問題を解決するために、どのようなツールをつかってどのように解決したかの話。

Netflix内でのワークロード最適化のため、AWSのインスタンスサイズを移行(16 vCPUから48 vCPU)し、CPUがボトルネックとなるワークロードの性能向上を図った。このインスタンスの移行により、性能をほぼ直線的に増加させることを想定し、スループットがおよそ3倍になると予想した。

しかし、結果としてこの移行で想定する性能は達成できなかった。

https://netflixtechblog.com/seeing-through-hardware-counters-a-journey-to-threefold-performance-increase-2721924a2822 より引用

目標としているCPUの使用率55％に到達してもスループットは平均25％しか増加せず、平均レイテンシは50％以上低下した。ノード間のばらつきはないものの、CPUとレイテンシのパタンが両方とも大きくぶれるようなグラフになっている。

そこで、ノード毎のCPUとレイテンシの内訳を調べてみると、面白いことが分かってきたらしい。グラフに示すように、CPU負荷とレイテンシについて、大きく2種類の特性が現れた。 1つ目が、CPUとレイテンシが非常に低く、ばらつきがほとんどない"Lower band"のパタンと、2つ目がCPUとレイテンシのばらつきが非常に大きい"Upper band"が存在するということである。

まずはフレームグラフを確認して、プログラム全体の分布は問題なかった。

そこで、次にインスタンスのパフォーマンス・カウンタを使用してベースラインの情報を集めることから始めた。

"Upper band(Slow node)" と "Lower band(Fast node)"の大きな違いは、CPIが大きく異なっている、そして、MACHINE_CLEARSカウンタにより非常に大きなL1キャッシュのアクティビティがみられる。このキャッシュライン・アクティビティの大きな違いの主な要因は、False Sharingと呼ばれる本来は必要のないデータをコア館で共有してしまうことによるキャッシュラインの移動によるものである。

この想定のもの、Intel vTuneを使用してマイクロアーキテクチャのプロファイリングを行ったところ、一部の命令で100CPIを超えるコードブロックが見つかった。

このコードによると、複数のスレッドがフィールド①とフィールド⑥の更新を行い、これらが同じキャッシュラインに入った場合、False Sharingが発生することになる。

これが上記の"Upper band"と"Lower band"の比率12.5%に相当する。つまり、キャッシュラインのサイズは64バイトで、ポインタのサイズは8バイトなので、別々のキャッシュラインに入るのは1/8であり、キャッシュ・ラインを共有してしまう確率は7/8なので、ちょうとこの分布と一致する、ということだ。

解決策としては、上記の2つのフィールドの間にパディングを挿入し、この2つのフィールドが同じキャッシュラインに入らないようにすることだった。これにより、CPUとレイテンシのグラフが以下の図のように変化し、"Upper band" と "Lower band"の大きな違いはなくなった。

しかしこれでは、まだ目標の性能に到達しないため、再度似たような部分を掘り下げたところ、今度はFalse SharingではなくTrue Sharingの問題が発生していることが分かった。これは同じ変数が複数のスレッド・コアによって読み書きされることであり、これを回避するためには、JVMのスーパークラスーキャッシュのコア・スレッド間での共有を避けるためのパッチを追加することになる。

これらの修正により、AWSインスタンスの移行により性能は目標とした3.5倍の改善を達成した。