博士

ロボ子、今日のITニュースはConvivaのレイテンシ問題じゃ。ストリーミング分析プラットフォームでP99レイテンシが急上昇したそうじゃぞ。

ロボ子

P99レイテンシの急上昇ですか。それは大変ですね。原因は何だったのでしょう？

博士

なんと、アトミックカウンターがボトルネックになっていたらしいのじゃ！共有型レジストリ内の、無害に見えるカウンターが犯人だとは。

ロボ子

アトミックカウンターですか。Convivaのプラットフォームは1日に5兆件ものイベントを処理すると聞きますから、些細なことでも影響が出るのですね。

博士

そうじゃ、Convivaの分析エンジンはDAGベースじゃから、当初はTokioランタイムやHDFS書き込みが疑われたらしい。でも、perf環境で再現したら、DAGコンパイラ/エンジンの問題だと判明したのじゃ。

ロボ子

flamegraph分析で`AtomicUsize::fetch_sub`がボトルネックだと特定されたのですね。`flashmap`の`ReadGuard`の作成と削除に関連する呼び出しパスに負荷がかかっていたとのことですが、`flashmap`は具体的に何に使われていたのですか？

博士

`flashmap`は同時実行ハッシュマップとして使われていて、型レジストリとしてシステム全体で共有されていたのじゃ。それが原因で、同時実行ハッシュマップのカウンター更新時にキャッシュコヒーレンスの問題が発生したみたいじゃな。

ロボ子

キャッシュコヒーレンスですか。カウンターをインクリメントまたはデクリメントするすべてのCPUコアがキャッシュの無効化を引き起こし、パフォーマンスが低下するのですね。

博士

その通り！そこで、`ArcSwap`ベースのソリューションを試したところ、CPU負荷が40%も低下したのじゃ！

ロボ子

`ArcSwap`ですか。RCU（read-copy-update）手法に従い、リーダーはロックなしでデータにアクセスし、ライターはデータの新しいコピーを作成してアトミックにスワップインするのですね。

博士

`ArcSwap`はデータ全体をスワップアウトする必要があるけど、読み取りが非常に安価なのじゃ。Convivaのケースでは、ほぼ読み取り専用でデータセットが小さいから、`ArcSwap`が適していたというわけじゃ。

ロボ子

なるほど。同時実行ハッシュマップの置き換えとして、`dashmap`ではなく`ArcSwap`が選ばれたのは、データ特性に合わせた賢明な判断だったのですね。

博士

そうじゃ！まさに、適材適所じゃな。しかし、アトミックカウンターがこんな大問題を引き起こすとは、油断も隙もないのじゃ。

ロボ子

本当にそうですね。今回の事例から、共有リソースの利用には細心の注意が必要だと学びました。

博士

ところでロボ子、アトミックカウンターって、原子レベルで数えてると思う？

ロボ子

まさか！