デプロイが失敗したとき、なぜオブザーバビリティが復旧ツールになるのか
新しいバージョンをデプロイした直後、ユーザーからエラー報告が相次ぐ。サポートチャンネルはスクリーンショットで埋め尽くされ、誰かが「ページが永遠に読み込まれない」と言い、別の誰かが「真っ白な画面が出た」と訴える。
最初に誰もが問う質問は「実際に何が起きたのか？」だ。
データがなければ、チームは推測を始める。データベースマイグレーションの問題かもしれない。メモリリークかもしれない。単なるトラフィックの急増かもしれない。推測ごとに異なる復旧アクションが必要になる。間違った推測をすれば、状況を悪化させる。
ここでオブザーバビリティは、単なる監視の贅沢品ではなく、主要な復旧ツールとなる。
危機的状況におけるオブザーバビリティの真の意味
オブザーバビリティとは、サーバーに一つずつログインしたり、経験則で推測したりせずに、システム内部で何が起きているかを理解する能力だ。インシデント発生時に、以下の3つの実用的な質問に答える。
- 何が壊れたのか？
- どこで壊れたのか？
- どうやって直すのか？
これらの答えを提供するデータは3種類ある：ログ、メトリクス、トレースだ。それぞれが、悪いデプロイからの復旧を試みる際に異なる役割を果たす。
ログ：最初に確認する場所
ユーザーがエラーを報告したとき、ログが最初の手がかりとなる。構造化されたログエントリは、データベース接続が切断されたのか、新しいコードで未処理の例外が発生したのか、サードパーティAPIが予期しない応答を返したのかを教えてくれる。
適切なログがなければ、問題が新しいバージョンにあるのか、デプロイ前から存在していたのかを判断できない。幽霊を追いかけるように時間を無駄にする。適切に構造化され検索可能なログがあれば、リクエストID、エラータイプ、タイムスタンプでフィルタリングし、数分で問題を絞り込める。
鍵は構造化だ。「エラーが発生しました」のようなログ行は役に立たない。{"timestamp":"2024-11-20T14:32:01Z","level":"ERROR","service":"payment","trace_id":"abc123","message":"connection refused to database replica-2"} のようなログ行は、どこを見るべきかを正確に示してくれる。
インシデント発生時にログをクエリする実用的な例を以下に示す。
# 'my-app' サービスの全Podから最新100行のログを取得し、ERRORエントリをフィルタリング
kubectl logs -l app=my-app --tail=100 | grep 'ERROR'
# より多くのコンテキストが必要な場合は、jqを使った構造化クエリを実行
kubectl logs -l app=my-app --tail=500 | \
grep 'ERROR' | \
jq '{timestamp, service, trace_id, message}'
メトリクス：早期警告システム
メトリクスはシステムの数値的な健全性を提供する。デプロイ後には、以下の点を把握したい。
- CPU使用率が急上昇したか？
- エラー率が増加したか？
- 応答時間が遅くなったか？
- スループットが低下したか？
これらの数値は復旧時だけでなく、ユーザーが苦情を言う前に警告を発する。エラー率やレイテンシに対する適切に設定されたアラートは、最初のサポートチケットが届く前に、悪いデプロイを数秒以内にチームに通知できる。
復旧中、メトリクスは修正が機能しているかどうかを教えてくれる。ロールバックした場合、エラー率はベースラインに戻ったか？ロールフォワードした場合、レイテンシは安定したか？メトリクスがなければ、手探りで進むしかない。
トレース：リクエスト経路を追跡する
ユーザーが「ページが遅い」と言ったとき、どこで遅延が発生しているかを知る必要がある。アプリケーションコードか？データベースクエリか？サードパーティAPI呼び出しか？
トレーシングは、1つのリクエストをフロントドアから、それが触れるすべてのサービスまで追跡する。各コンポーネントで費やされた時間を示す。これは復旧戦略を決定する際に極めて重要だ。
トレースがデータベースをボトルネックと示した場合、アプリケーションをロールバックしても問題は解決しない。データベースマイグレーションもロールバックするか、ホットフィックスを適用する必要がある。トレースが遅延の原因をサードパーティの決済ゲートウェイと示した場合、ロールバックは不要かもしれない。タイムアウトやフォールバックを追加するだけで済む可能性がある。
データに基づいた復旧判断
優れたオブザーバビリティはパニックをプロセスに変える。推測する代わりに、データ駆動の道筋をたどる。
- エラー率がしきい値を超えたためアラートが発報する。
- メトリクスダッシュボードを確認し、デプロイ時刻と同時にスパイクが始まったことを確認する。
- ログを確認し、新しいコードに特定の例外パターンがあることを見つける。
- トレースを確認し、新しい決済モジュールでエラーが発生していることを確認する。
- 判断する：決済モジュールのみをロールバックするか、フィーチャーフラグで無効化する。
データがロールバックすべきでないと示すこともある。メトリクスが1つのエンドポイントでのみエラーを示す場合、その機能をフラグで無効化できる。トレースがデータベースは正常だがアプリケーションコードにメモリリークがあると示す場合、データベースに触れずにアプリケーションのみをロールバックできる。
オブザーバビリティがなければ、これらの区別はできない。すべてをロールバックするか、まったくロールバックしないかの二択になる。どちらの選択も不必要なリスクを伴う。
復旧後：健全性の証明
ロールバックが完了しても、オブザーバビリティの有用性は終わらない。システムが実際に再び健全であることを確認する必要がある。「ページが読み込まれる」だけでなく、以下の点を確認する。
- エラー率がベースラインに戻っている。
- レイテンシが正常範囲内にある。
- ログに新しい例外が表示されていない。
- スループットが回復している。
これらのシグナルが復旧成功の証拠となる。これらがなければ、問題が消えたことを願うだけだ。これらがあれば、自信を持ってインシデントをクローズできる。
落とし穴：オブザーバビリティを将来のプロジェクトと見なすこと
多くのチームはオブザーバビリティを後回しにする。ログエージェントをインストールし、いくつかのメトリクスを追加して完了とする。実際のインシデントが発生したとき、ログが非構造化で、メトリクスが適切なシグナルをカバーしておらず、トレーシングがまったくないことに気づく。
オブザーバビリティのない復旧計画は、単なる文書に過ぎない。「エラー率が増加したらロールバックする」と書くことはできるが、通常のエラー率がわからなければ、あるいはリアルタイムで測定できなければ、その指示は無意味だ。
オブザーバビリティは監視プロジェクトではない。それは復旧ツールだ。何かがうまくいかないときに、チームに「見て、理解し、迅速に行動する」能力を与える。それがなければ、暗闇の中を歩いているようなものだ。何かが間違っていることはわかっているが、どこで、どうやって直せばいいのかわからない。
復旧対応可能なオブザーバビリティのための実践的チェックリスト
- すべてのサービスが、タイムスタンプ、レベル、サービス名、トレースIDを含む構造化JSONログを出力する。
- 主要メトリクス（エラー率、レイテンシ、スループット）に定義されたベースラインとアラートがある。
- 分散トレーシングがすべてのクリティカルなリクエストパスで有効化されている。
- デプロイの異常が発生してから数秒以内に発報するアラートが設定されている。
- チームがシミュレートされたインシデント中にログ、メトリクス、トレースを使用する訓練を行っている。
具体的な教訓
次回デプロイを計画するとき、チームに1つの質問をしよう。「このデプロイが失敗した場合、5分以内に何が起きたかわかるだろうか？」答えが「いいえ」なら、デプロイする前にオブザーバビリティを修正しよう。今日収集するデータだけが、明日の推測からあなたを救う唯一のものだ。