デプロイ後に確認すべきことは、何をデプロイしたかで決まる
新しいバージョンを本番環境にプッシュした。パイプラインはグリーン。デプロイはエラーなく完了した。さて、次は何を確認すべきか？
多くのチームはダッシュボードを眺めて、何も壊れていないことを願うだけだ。しかし、本当に注目すべきシグナルは、何をデプロイしたかに完全に依存する。アプリケーション、データベース、インフラストラクチャの変更に対して同じ指標を確認しても、本当の問題を見逃してしまう。デプロイの種類ごとに障害モードは異なり、それぞれに適したシグナルを監視する必要がある。
アプリケーション：リクエストの処理状況を監視する
アプリケーションの新しいバージョンをデプロイしたとき、最も重要なのはユーザーリクエストを適切に処理できているかどうかだ。この答えを最も早く教えてくれるのが、エラーレートとレイテンシの2つの指標である。
エラーレートは、リクエストのうち何パーセントが失敗しているかを示す。デプロイ直後にエラーレートが急上昇したら、何かがおかしい。新しいコードのバグ、設定ミス、本番環境との非互換性などが考えられる。原因は何であれ、ユーザーが障害に直面しているため、即座に把握する必要がある。
レイテンシは、アプリケーションがリクエストに応答するまでにかかる時間を示す。レイテンシが突然増加した場合、新しいバージョンが遅くなっていることを意味する。リソース消費の増加、ボトルネックの発生、ダウンストリームサービスへの非効率な呼び出しなどが原因かもしれない。ユーザーにはエラーは見えなくても、遅さを感じさせることになり、それは同様に深刻な問題だ。
スループットも有用なシグナルである。特に多くのユーザーにサービスを提供するアプリケーションでは重要だ。スループットは、アプリケーションが単位時間あたりに処理できるリクエスト数を測定する。ユーザー数が変わらないのにスループットが低下した場合、新しいバージョンの効率が悪くなっている。エラーレートやレイテンシが正常に見えても、コードのどこかで処理が遅くなっている。
これら3つのシグナルは、アプリケーションデプロイ後に最初に確認すべき項目である。これらはユーザーが実際に体験する内容を反映している。プロセスが動いているか、コンテナが起動しているかだけに頼ってはいけない。それらはアプリケーションが生きていることを示すが、正しく動作しているかどうかは教えてくれない。
以下のフローチャートは、デプロイ対象に応じて最初に確認すべき指標をまとめたものです：
データベース：レプリケーション、クエリ、コネクションを確認する
データベースはアプリケーションのように直接リクエストを処理するわけではない。データをアプリケーションに提供するのが役割だ。そのため、監視すべきシグナルも異なる。
レプリケーションの状態は極めて重要だ。ほとんどの本番データベースは、読み取り用にレプリカを使用している。デプロイ後にレプリケーションが遅延したり停止したりすると、アプリケーションが古いデータや不整合なデータを読み取る可能性がある。これはスキーマ変更やデータマイグレーションの後で特に危険だ。数秒のレプリケーションラグは許容できるかもしれないが、数分のラグは何かがおかしいことを示している。
次に監視すべきはクエリパフォーマンスだ。スキーマを変更したり、インデックスを追加したり、アプリケーションのデータ書き込み方法を変更するデプロイの後では、一部のクエリが突然遅くなることがある。通常より時間がかかるクエリや、タイムアウトし始めるクエリに注目しよう。1つの遅いクエリがアプリケーション全体を引きずり下ろす可能性がある。
コネクション数も重要だ。データベースには利用可能なコネクション数に制限がある。デプロイによってコネクションが滞留したりハングしたりすると、データベースのコネクションが枯渇する可能性がある。新しいリクエストは失敗し、データベース自体は正常でもアプリケーションが壊れたように見える。
トランザクションログのサイズは、あまり知られていないが重要なシグナルだ。データベースはすべての変更に対してログを書き込む。デプロイによってアプリケーションのデータ書き込み方法が変わると、ログの増加速度が通常より速くなることがある。適切にクリーンアップしないと、ログがディスクを埋め尽くし、データベースを停止に追い込む。データベースチームは通常、ログサイズの安全なしきい値を設定している。そのしきい値を超えた場合は、対応が必要だ。
インフラストラクチャ：ノード健全性から始める
インフラストラクチャのデプロイには、サーバー、コンテナ、ネットワーク、クラウドリソースの変更が含まれる。最初に確認すべきシグナルはノード健全性だ。サーバーやコンテナはまだ生きているか？CPUとメモリの使用率は正常範囲内か？ディスクは満杯になっていないか？
健全なインフラは、アプリケーションとデータベースが正しく動作するための前提条件である。ノードが再起動を繰り返したり、リソースが不足したりすると、その上で動作するすべてのものが影響を受ける。ノード健全性は基本中の基本だ。これが壊れていれば、他の何も意味をなさない。
ネットワークのシグナルも重要だ。特にファイアウォールルール、ロードバランサー、サービスメッシュを変更した後は注意が必要だ。ノード間のレイテンシ増加、パケットロス、コネクション切断などを監視しよう。これらの問題はアプリケーションメトリクスに直接現れないことが多く、デバッグが難しい謎の障害を引き起こす。
シグナルは相互に関連しているが、まずは一つに集中する
アプリケーション、データベース、インフラストラクチャのシグナルは独立して存在するわけではない。アプリケーションの遅さは、データベースの遅さが原因かもしれない。データベースの遅さは、インフラノードのメモリ不足が原因かもしれない。全体像を把握するには、3つのレイヤーすべてのシグナルを組み合わせて読む必要がある。
しかし、デプロイ後に迅速な判断を下す必要がある場合、各チームは通常、一つだけ主要なシグナルに注目する。アプリケーションチームはエラーレートとレイテンシを監視する。データベースチームはレプリケーションとクエリパフォーマンスを監視する。インフラチームはノード健全性を監視する。まずはそこから始めよう。何かおかしいと思ったら、他のレイヤーを掘り下げて根本原因を特定する。
デプロイ後確認の実践的チェックリスト
- アプリケーションデプロイの場合：最初の5分以内にエラーレート、レイテンシ、スループットを確認する。
- データベースデプロイの場合：レプリケーションラグ、スロークエリ、コネクション数、トランザクションログサイズを確認する。
- インフラストラクチャデプロイの場合：ノード健全性、CPUとメモリ使用率、ディスク容量、ネットワークレイテンシを確認する。
- 一つのシグナルが異常を示した場合、他のレイヤーの関連シグナルを確認して真の原因を突き止める。
まとめ
すべてのデプロイに同じダッシュボードを使うべきではない。注目すべきシグナルは、何を変更したかによって決まる。アプリケーションにはリクエストレベルのメトリクスが必要だ。データベースにはデータレイヤーのメトリクスが必要だ。インフラストラクチャにはリソースとネットワークのメトリクスが必要だ。デプロイの種類ごとにどのシグナルを監視すべきかを理解していれば、ユーザーが気づく前に問題を発見できる。