Dry Run

友人がJMeterと格闘しているのを横で見ていたことがある。大規模アップデートのリリース前で、本番と同じ構成で負荷検証をやっていた。

大規模アップデートの負荷検証は厄介だ。本番と同じデータ量、同じトラフィックパターン、同じミドルウェア構成をまるごと再現しなければ意味がない。データが数TBあればコピーだけで半日かかる。バッチの再現、外部APIとの結合、キャッシュのヒット率。全部揃えても「本番と同じ」にはならない。

当時はIaCなど導入されていなかった。本番と同じ構成をクラウド上にもうひとつ作る。誰かがハンドメイドで構築したのだと思う。手順書を見ながらひとつずつサーバーを立て、ミドルウェアを入れ、設定を合わせる。本番との差分がどこかに紛れ込んでいても気づけない。

本番データを検証環境に持ち込むなら、個人情報のマスキングも必要になる。名前、メールアドレス、電話番号、住所。地味だが手を抜けない。マスキングが甘ければ事故になるし、やりすぎればデータの分布が変わって検証の意味が薄れる。

クラウドにはもうひとつ厄介な問題がある。同じスペックのインスタンスでも、性能がブレる。クラウドのインスタンスは物理サーバーを複数のテナントで共有している。隣のテナントがCPUやディスクI/Oを食えば、自分のインスタンスも影響を受ける。いわゆるnoisy neighbor問題だ。昨日のベンチマークでは問題なかったのに今日は遅い。再現性がない性能劣化ほど厄介なものはない。ベアメタルインスタンスという選択肢は一応あるが、そこまでコストをかけるならオンプレのままでいい。使っているところを見たことがない。

結局、本番と同じ負荷は本番でしか再現できない。メンテナンス窓を取って、一気に切り替えて、祈る。負荷検証はその祈りの根拠を少しでも積み上げる作業だ。

あの友人はいつしか負荷検証の仕事はお断りにしていた。気持ちはわかる。横で見ている分には面白かったが、自分でやりたいかと言われると、遠慮する。