デプロイ成功後に何が起きるのか

デプロイログはすべて成功を示している。サーバーはエラーなく起動した。アーティファクトは正常にインストールされた。パイプラインは全ステージでグリーンだ。

しかし、それらの情報は新しいバージョンが実際にユーザーにとって機能しているかどうかを教えてくれない。

クリーンなデプロイは単なるインストールフェーズに過ぎない。本当の問いは、トラフィックが新しいコードに到達した後に始まる。アプリケーションは期待通りに動作しているか？ユーザーは意図した体験を得られているか？その答えはデプロイログには書かれていない。

デプロイと正常運用のギャップ

チームがバックエンドサービスの新バージョンをプッシュしたとき、デプロイ後の最初の数分間が最も多くの情報をもたらす。この瞬間、新しいコードが本番トラフィック、本番データ、本番依存関係と初めて出会う。ステージングでは決して現れなかった問題が、ここで表面化する。

よくある間違いは、パイプラインがグリーンになった時点でデプロイが完了したと見なすことだ。実際には、新しいバージョンが本番条件下で正常に動作しているという十分な証拠が得られて初めて、デプロイは完了する。

デプロイ後に確認すべき5つの指標

エラー率

エラー率は、何かがおかしいことを示す最も直接的なシグナルだ。APIサービスの通常の障害率が0.1%なのに、デプロイ後に突然5%に跳ね上がったら、問題が発生している。

デプロイ直後にエラー率を確認するには、メトリクスエンドポイントに問い合わせる。例えばPrometheusの場合：

curl -s 'http://localhost:9090/api/v1/query?query=rate(http_requests_total{status=~"5.."}[5m])'

このクエリは過去5分間の5xxエラーのレートを返す。結果をデプロイ前のベースラインと比較し、ロールバックが必要か判断する。

ただし、エラー率だけでは十分ではない。スパイクが自社のコードではなく、下流の依存関係に起因する場合もある。データベースの応答が遅くなれば、データベースにアクセスするすべてのリクエストが失敗する。つまり、エラー率を他の指標と組み合わせて読み解き、真の問題の所在を特定する必要がある。

レイテンシ

新しいバージョンがエラーを一切出さないにもかかわらず、すべての応答が遅くなることがある。ユーザーはアプリケーションを使えるが、体験は低下する。レイテンシの増加は、非効率なコード、変更されたデータベースクエリ、サーバーリソースの限界到達などが原因で発生する。

デプロイ後にレイテンシが着実に上昇し、元に戻らない場合、新しいバージョンの何かがリクエストあたりの処理時間を必要以上に消費している。

飽和度

これはサーバーリソースがどの程度埋まっているかを示す指標だ。CPU、メモリ、データベース接続、ディスクI/O。新しいバージョンがリソースを大量に消費しても、テスト中には誰も気づかないことがある。

例えば、リクエストのたびに新しいデータベース接続を開いて閉じないコード。あるいは、すべてのAPI呼び出しで実行される不要なループ。飽和度はトラフィックが増加するまで見えず、エラー率やレイテンシが正常に見えているにもかかわらず、突然サーバーが追加負荷を処理できなくなる。

依存関係の健全性

バックエンドサービスが単独で動作することはほとんどない。APIサービスはデータベース、キャッシュ、他のサービスに依存する。ワーカーはメッセージブローカーに依存する。新しいバージョンが依存関係を異なる方法で呼び出し始めると、それらの依存関係が期待通りに応答しない可能性がある。

問題が自サービスにまったくなく、呼び出し先のサービスにある場合もある。新しいバージョンが、その依存関係を本番条件下で初めて実行するタイミングになる。

ビジネスシグナル

これは最もアプリケーション固有の指標だ。登録APIであれば、ビジネスシグナルは1分あたりの完了登録数。決済処理ワーカーであれば、正常に処理されたトランザクション数。

デプロイ後に登録数が急激に減少したのに、技術的なエラー率が低いままなら、依然として深刻な問題がある。ビジネスシグナルは、サービスが何を提供すべきかを理解しているチームが定義する必要がある。これらのシグナルは、アプリケーションが単に動作しているかどうかではなく、その役割を果たしているかどうかを教えてくれる。

問題が発生した場合の対処法

指標が新しいバージョンの正常動作を示さない場合、最も安全な対応はロールバックだ。安定していることが確認されている以前のバージョンに戻す。

以下のフローチャートは、デプロイ後の監視プロセスとロールバックまたは継続の判断を示している：

flowchart TD A[デプロイ成功] --> B{エラー率を確認} B -- OK --> C{レイテンシを確認} B -- アラート --> R[ロールバック] C -- OK --> D{飽和度を確認} C -- アラート --> R D -- OK --> E{依存関係の健全性を確認} D -- アラート --> R E -- OK --> F{ビジネスシグナルを確認} E -- アラート --> R F -- OK --> G[監視継続] F -- アラート --> R

ロールバックは自動化されていなければならない。サーバーにログインして手動でファイルを入れ替えるのは、ユーザーがすでに影響を受けている状況では遅すぎるし、エラーが発生しやすい。

ロールバックの自動化方法はデプロイ戦略によって異なる：

  • ローリングアップデート：エラー率がしきい値を超えた場合に以前のバージョンに戻すようパイプラインを設定する。
  • ブルー/グリーン：トラフィックを古い環境に戻す。
  • カナリア：カナリアを停止し、すべてのトラフィックを安定版に戻す。

重要なのは、ロールバックのしきい値をインシデント発生時ではなく、デプロイ前に決定しておくことだ。例えば「エラー率が2分間1%を超えたら自動ロールバック」や「平均レイテンシがベースラインから50%増加したらロールバック」など。

各サービスに固有のしきい値が必要だ。ユーザーが直接依存する重要なAPIは、バッチジョブを処理するバックグラウンドワーカーよりも厳格なしきい値を設定すべきである。

実践的なデプロイ後チェックリスト

すべてのデプロイ後に、新しいバージョンが正常に動作していることを確認するためにこのチェックリストを使用する：

  • エラー率が期待範囲内である（デプロイ前のベースラインと比較）
  • レイテンシが大幅に増加していない
  • サーバーリソース使用量（CPU、メモリ、接続数）が安定している
  • すべての重要な依存関係が正常に応答している
  • ビジネスシグナル（登録数、トランザクション数など）が期待パターンと一致している
  • ロールバックのしきい値が定義され、自動化されている

デプロイの本当の終わり

デプロイはパイプラインがグリーンになった時点で終了しない。新しいバージョンが本番条件下で正常に動作していることを確認した時点で終了する。トラフィックが新しいコードに到達した後の最初の数分間が最も重要だ。そこで問題を捉え、全ユーザーに影響が及ぶ前に対処する。

しきい値を設定し、指標を監視し、ロールバックを自動化しよう。セーフティネットは、必要になる前に準備されていてこそ機能する。