Read the Metrics

サーバーメトリクスは奥が深い。

とあるプロジェクトでのこと。APIが間欠的に応答が遅くなる問題を検知した。ランダムではない。かといって負荷に比例しているわけでもない。一定の周期で、数秒間だけレイテンシが跳ね上がる。

長い時間をかけて調査した。アプリケーション層は問題ない。ネットワークも正常。たどり着いたのはMySQLのbinlogだった。レイテンシの周期と、binlogファイルのスイッチタイミングが一致していた。

そこからは早かった。binlogの削除に伴うext3のファイルシステムフリーズが原因だった。ext3はファイル削除時にジャーナリングの関係でI/Oがブロックされることがある。本番のトラフィックを捌いている最中に、裏でファイルシステムが数秒固まっていた。

解決はできた。でもふと思う。これがECS/FargateとAuroraの構成だったら、どう調査しただろう。Auroraの中身はストレージがKVSライクな分散設計なのでこの問題自体は起きないかもしれない。でも別の、マネージドサービスが隠蔽した何かが原因だったとしたら。CloudWatchのメトリクスから、ファイルシステムのフリーズにたどり着けるだろうか。

フルマネージドは便利だ。運用コストは下がるし、面倒な作業から解放される。でも最後の最後、原因を特定するのは泥臭い低レイヤーの調査だ。そしてマネージドサービスは、その低レイヤーを触らせてくれない。

便利になるほど、問題が起きたときの最後の一歩が遠くなる。それでも楽さには勝てない。