デプロイ後に確認すべき5つのシグナル：新バージョンの健全性を判断する指標
新しいバージョンをデプロイしました。パイプラインは成功を示しています。チームはダッシュボードを監視しています。しかし、アプリケーションは実際にユーザーにとって正常に動作しているでしょうか？
具体的なシグナルがなければ、推測に頼ることになります。自分だけが使うアプリケーションなら推測でも構いません。しかし、他の人が依存しているシステムではデータが必要です。新しいバージョンが健全かどうかを数分以内に判断できなければなりません。
ここでは、すべてのチームがデプロイ後に監視すべき5つの基本シグナルを紹介します。まずは1つか2つから始めて、徐々に追加していきましょう。
可用性：ユーザーはアプリケーションにアクセスできるか？
デプロイ後に最も基本的な質問はシンプルです：アプリケーションにアクセスできるか？サーバーがダウンしている、起動時にクラッシュした、ポートが開いていない——いずれの場合も可用性はゼロになります。
通常、チームはヘルスチェックエンドポイントでこれを監視します。これはアプリケーションが「自分は生きているか？」に答えるために公開する特別なURLです。監視ツールが定期的にこのエンドポイントにアクセスし、応答がなければ何か問題が発生しています。
可用性は通常パーセンテージで測定されます：99%、99.9%、99.99%など。目標が高いほど、中断に対する許容度は低くなります。99%の目標なら月に約7時間のダウンタイムが許容されますが、99.99%なら月に約4分しか許容されません。
デプロイ直後に可用性を確認するには、ヘルスエンドポイントに対してシンプルなcurlコマンドを実行します：
curl -f http://localhost:8080/health && echo "OK" || echo "FAIL"
-fフラグは、HTTPレスポンスがエラー（4xxまたは5xx）の場合にcurlが非ゼロの終了コードを返すようにします。ゼロ終了コードはエンドポイントが到達可能で健全であることを意味します。デプロイスクリプトでこれを使えば、続行するかロールバックするかを自動的に判断できます。
デプロイ後はまず可用性を確認してください。アプリケーションにアクセスできなければ、他のシグナルは意味をなしません。
エラー率：リクエストのうち何パーセントが失敗しているか？
アプリケーションは生きていても壊れている可能性があります。すべてのリクエストが失敗するかもしれません。エラー率は、HTTP 500やタイムアウトなどのエラーコードで終了するリクエストの割合を測定します。
デプロイ前にベースラインのエラー率を把握しておく必要があります。たとえば全リクエストの0.5%だとします。デプロイ後にその数値が5%に跳ね上がったら、新しいバージョンが何か問題を引き起こしています。
エラー率の急上昇は、何かがおかしいことを示す最初のアラームです。発見しやすく、たいていは実際の問題を示しています。エラー率の急増は「様子を見よう」ではなく、即座に調査を開始すべきです。
レイテンシ：アプリケーションの応答速度は？
ユーザーは待つのが嫌いです。1秒で読み込めていたページが5秒かかるようになれば、ユーザーは離れていきます。レイテンシは、アプリケーションがリクエストに応答する速さを測定します。
レイテンシが増加する理由はさまざまです。新しいコードが遅い、データベースのコネクションプールが満杯、サーバーがトラフィックに圧倒されている——原因は何であれ、レイテンシの増加は直接ユーザー体験を損なわせます。
デプロイ前に通常のレイテンシ範囲を知っておく必要があります。デプロイ後に数値を比較します。平均応答時間が2倍になったら、何かが変わった証拠です。わずかなレイテンシの増加でも、負荷が高まったときに悪化する問題を示している可能性があります。
飽和度：リソースはどの程度使い切られているか？
すべてのシステムには限界があります。CPU、メモリ、ディスク容量、データベース接続、スレッドプール、ネットワーク帯域幅——すべてに上限があります。飽和度は、それらの限界にどれだけ近づいているかを測定します。
デプロイ後はリソース使用量を監視します。CPU使用率が40%から90%に上昇した場合、新しいバージョンがより多くのリソースを消費しています。予備容量があれば問題ないかもしれません。しかし、後でトラフィックが増加すると、その90%は100%になり、アプリケーションは遅くなるかクラッシュします。
飽和度はキャパシティプランニングにも役立ちます。サーバーが常に80%使用されているなら、次のトラフィックスパイクの前に別のサーバーを追加する必要があるでしょう。デプロイ後に飽和度を監視することで、新しいバージョンがアプリケーションのリソースプロファイルを変えたかどうかがわかります。
ログ：内部で実際に何が起きたか？
すべてを数値で捉えられるわけではありません。エラー率が急上昇したとき、その理由を知る必要があります。そこでログの出番です。ログはアプリケーションの実行中に書き込まれるイベントの記録です。
優れたログにはレベルがあります：通常動作のinfo、重要ではないが異常なイベントのwarning、障害のerror。また、コンテキスト（タイムスタンプ、リクエストID、関数名、関連データ）も含まれます。コンテキストがなければ、ログは単なるノイズです。
デプロイ後に問題が発生した場合、最初に確認すべきはログです。特定の例外が発生したか？特定の入力がクラッシュを引き起こしたか？データベースが応答していないか？ログは数値だけでは語れないストーリーを教えてくれます。
小さく始めて、一貫性を保つ
最初から5つすべてのシグナルを監視する必要はありません。可用性とエラー率から始めましょう。この2つでほとんどの問題を捉えられます。パフォーマンスを理解する必要が出てきたらレイテンシを追加します。キャパシティプランニングを始めたら飽和度を追加します。より深いデバッグが必要になったらログを追加します。
重要なのは一貫性です。すべてのデプロイを同じ方法で測定する必要があります。同じヘルスチェックエンドポイントを使用し、同じソースからエラー率を収集し、同じツールでレイテンシを測定します。そうして初めて、新旧バージョンを正直に比較できます：新しいバージョンは古いものより優れているか、劣っているか？
これらの5つのシグナルは、感覚ではなくデータを提供します。データがあれば、続行するか、ロールバックするか、さらに調査するかを判断できます。
デプロイ後モニタリングのクイックチェックリスト
- ヘルスチェックエンドポイントが応答している
- エラー率がベースラインから大幅に上昇していない
- 平均レイテンシが通常範囲内にある
- CPU、メモリ、ディスク使用量が容量に近づいていない
- ログに予期しないエラーや例外が記録されていない
次のステップ
これらのシグナルはアプリケーションが健全かどうかを教えてくれますが、新しい機能が期待通りに動作しているかは教えてくれません。可用性が完璧で、エラー率が低く、レイテンシが速くても、間違った結果を返すバージョンはあり得ます。そこで検証が必要になります。
しかしその前に、これらの5つのシグナルを整えてください。これらがなければ、手探りで進むことになります。これらがあれば、デプロイ後に何が起きているかを把握する基盤ができます。