アプリケーションが正しく動作しているかを確認する方法

新しいバージョンをデプロイしました。パイプラインはグリーン。アーティファクトは本番環境に配置されました。さて、次はどうする？

アプリケーションのユーザーが数人しかいないうちは、ブラウザを開いて少しクリックして回れば、すべてが正常に動作していることを確認できます。しかし、アプリケーションが数十人、数百人、数千人ものユーザーを同時にさばくようになると、手動での確認は通用しなくなります。テストすべきコードパスが多すぎ、さまざまな機能を使うユーザーが多すぎ、ひとつひとつを手作業で確認する時間が足りません。

核心となる質問はシンプルです。デプロイ後、新しいバージョンが期待通りに動作していることを、どうやって確認するのでしょうか？

ヘルスシグナルが教えてくれること

動作中のすべてのアプリケーションは、正常かどうかを示す兆候を発しています。これをバイタルサインと考えてください。医者が患者の状態を診断するために脈拍や体温をチェックするように、アプリケーションが生きているか、正しく応答しているか、許容範囲内に収まっているかを教えてくれるシグナルが必要です。

これらのシグナルをヘルスシグナルと呼びます。これは、デプロイ後、そしてアプリケーションが稼働し続けている間、アプリケーションが正常に機能しているかどうかを判断するためのデータポイントです。

デプロイ直後に、最も一般的な2つのヘルスシグナルを手動で確認する簡単な方法を以下に示します。

# アプリケーションのヘルスエンドポイントが応答するか確認
curl http://localhost:8080/health

# 期待される出力（例）:
# {"status":"ok","uptime":"2m34s"}

# アプリケーションログから最近のエラーを検索
grep 'ERROR' /var/log/app.log | tail -20

ヘルスシグナルはいくつかのソースから得られ、それぞれ異なる目的を果たします。

ログ：何が起こったかの生の記録

ログは最も基本的なヘルスシグナルです。アプリケーションがリクエストを受信するたび、データベースへの接続に失敗するたび、ジョブの処理を完了するたびに、何が起こったかを説明する1行のログを書き出すことができます。ログはイベントの時系列記録を提供します。

ユーザーがエラーを報告し始めたとき、ログは最初に確認する場所であることが多いです。ログファイルや検索ツールを開き、問題が発生した時間帯でフィルタリングし、何が問題だったのかを遡って調べます。ログは「このエラーの直前に何が起こったのか？」という問いに答えてくれます。

しかし、ログには限界があります。すべてが正常であることを確認するためだけに、毎分数千行ものログを読むことを想像してみてください。それは現実的ではありません。ログはデバッグには優れていますが、継続的なヘルス評価には効率的ではありません。

メトリクス：傾向を示す数値

メトリクスは、ログが生み出す量の問題を解決します。個々のイベントを読む代わりに、定期的に数値測定値を収集します。一般的なメトリクスは次のとおりです。

  • 1秒あたりのリクエスト数
  • 平均応答時間
  • エラーを返すリクエストの割合
  • メモリ使用量
  • CPU使用率

メトリクスを使うと、時間の経過に伴う傾向を確認できます。応答時間が突然2倍になった場合、まだエラーが発生していなくても警告サインです。メモリ使用量が数日かけて着実に増加している場合、最終的にアプリケーションをクラッシュさせるメモリリークが発生している可能性があります。

メトリクスは、問題がユーザーに顕在化する前に検出することを可能にします。数千のイベントを単一の数値に圧縮し、追跡とアラート設定ができるようにします。

監視：収集、表示、アラート

ログとメトリクスは、継続的に監視できる場所に収集され、表示される必要があります。このプロセスを監視と呼びます。監視とは、単にデータを集めることだけではありません。データを有用なものにすることです。

優れた監視設定は、次の3つのことを行います。

  1. 収集: アプリケーションとインフラストラクチャからログとメトリクスを収集します。
  2. 表示: ダッシュボードに表示し、現在のステータスを一目で確認できるようにします。
  3. アラート: 何かが正常範囲を超えた場合に通知します。

たとえば、「5分間のウィンドウ内でリクエストの5%以上が失敗した場合に通知を送信する」というルールを設定できます。そのアラートは、電話通知、メール、チームチャットへのメッセージなどで届きます。目標は、ユーザーから知らされる前に問題を把握することです。

ヘルスシグナルが早期に重要な理由

問題を早期に検出できればできるほど、迅速に対応できます。ユーザーがソーシャルメディアに苦情を殺到して初めてアプリケーションが壊れていることに気づいたのでは、問題はすでにしばらく続いています。CI/CDの文脈では、ヘルスシグナルはデプロイ後の検証ステップとして機能します。「このリリースは本番環境で実際に機能したのか？」という問いに答えます。

ヘルスシグナルがなければ、手探りでデプロイしていることになります。新しいバージョンをプッシュし、うまくいくことを願い、誰かが苦情を言うのを待つだけです。ヘルスシグナルがあれば、リリースが安定しているか、ロールバックが必要かを数分以内に把握できます。

ヘルスシグナルは、徐々に現れる問題も捉えます。メモリリークは、目に見える問題を引き起こすまでに数時間から数日かかる場合があります。応答時間の緩やかな低下は、しきい値を超えるまでユーザーに気づかれないかもしれません。ヘルスシグナルを継続的に監視することで、これらのゆっくりと進行する問題を、ユーザーに影響が出る前に発見できます。

実践的なヘルスシグナルチェックリスト

初めてヘルスシグナルを設定する場合、開始するための最小限のチェックリストを以下に示します。

  • まず3つのメトリクスを選ぶ: リクエスト成功率、平均応答時間、エラー数。これらは最も一般的な障害モードをカバーします。
  • 1つのアラートを設定する: エラー率が5分間連続で5%を超えた場合にチームに通知する。
  • デプロイ後は毎回ログを確認する: メトリクスが問題なくても、リリース後最初の10分間はログをスキャンして予期しないエラーがないか確認する。
  • ヘルスエンドポイントを追加する: アプリケーションのステータスを返すシンプルなURLを作成する。監視ツールはこのエンドポイントを数秒ごとに叩いて、アプリが生きていることを確認できる。

これは包括的ではありませんが、デプロイ後に発生するほとんどの問題を捕捉するには十分です。

まとめ

ヘルスシグナルは、デプロイを手探りの作業から検証可能なプロセスへと変えます。ログは何が起こったかのストーリーを提供します。メトリクスは時間の経過に伴う傾向を示します。監視はすべてを結びつけ、何か問題があるときにアラートを送信します。基本から始めましょう。いくつかのメトリクス、1つのアラート、そしてデプロイ後に毎回確認する習慣です。これだけで、ほとんどの問題をユーザーよりも先に発見できます。