移行後に「遅くなった」と言われたら — 性能問題の切り分け手順書

移行プロジェクトの最終盤に必ず一度は聞くセリフが「オンプレのときより遅い」です。感覚論で押し問答になる前に、切り分けの順番を決めておきましょう。私たちが現場で使っている手順をそのまま書きます。

01ステップ0：「何が・どれだけ」を数値にする

最初にやるのは計測であって調査ではありません。「画面Aの表示が3秒→8秒」「夜間バッチが2時間→3.5時間」のように、対象と数字を特定します。「全体的に遅い」は調査対象にできません。この時点で、実は特定の1画面・1ジョブだけの問題だと判明することが半分くらいあります。

02象限①：レイテンシ — チャッティなアプリの宿命

オンプレのLAN内は往復1ms未満、拠点からAWSへは往復10〜20ms程度。1回の通信では知覚できない差が、1画面で数百回SQLを発行するようなチャッティなアプリでは数秒の差になります（200クエリ×15ms＝3秒）。

• 切り分け：AWS内のサーバから同じ処理を実行して速ければ、レイテンシ×通信回数が原因
• 対策：アプリとDBを同じVPCに揃える（片方だけ移行した「またぎ構成」の解消）、クエリ回数の削減、どうしても残るなら画面系をAWS側（WorkSpaces等）に置く

03象限②：ストレージ — ベースラインとバースト

「最初は速かったのに数十分で遅くなる」パターンはほぼこれです。gp2のバーストクレジット枯渇か、インスタンスのEBS帯域がバースト値からベースラインに落ちたか。CloudWatchのBurstBalanceとVolumeQueueLengthを確認してください。対処はEBS選定の記事にまとめた通り、gp3化とインスタンス帯域の確認です。

04象限③④：DNSと経路

• DNS — 名前解決のタイムアウト待ち（届かないオンプレDNSを数秒待ってから次を試す）は「時々引っかかる」症状になる。リゾルバ設定とRoute 53 Resolverの構成を確認
• 経路 — プロキシ強制経由、オンプレ折り返し（AWS→オンプレFW→AWS）、セキュリティ製品のインライン検査。tracerouteとVPCフローログで実際の経路を見る

05手順書として回す

①数値化 → ②AWS内から再現（レイテンシ切り分け）→ ③CloudWatchでストレージ確認 → ④DNS・経路確認。この順で見れば、大半の「遅い」は1〜2日で原因に到達します。重要なのは、移行前に基準値（オンプレでの処理時間）を計測しておくこと。比較対象のない性能問題は、永遠に終わりません。