分散アプリケーションのトラブルシューティング: トレースとログを組み合わせて根本原因分析を実行する
Google Cloud Japan Team
※この投稿は米国時間 2024 年 1 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。
多数のサービスから構成される分散アプリケーションのトラブルシューティングを行う際は、トレースを使用すると問題の発生源を特定し、被害を最小にとどめるためにロールバックなどの対策をすばやく実施することができます。しかし、ロールバックによってすべてのアプリケーションの問題に対応できるとは限らず、根本原因分析を行う必要があります。サービス呼び出しの実行時に異常が発生したときのコードパスを把握するために必要な詳細情報は、アプリケーション ログに含まれていることが多々あります。そこで、開発者にとっては、適切なログを見つけることが課題となります。
では、Google Cloud の分散トレースツール Cloud Trace と Cloud Logging を組み合わせて、根本原因分析を行う方法を見ていきましょう。
あなたが、小売ウェブストア アプリの一部である顧客管理サービス（CRM）に携わっている開発者だとしましょう。このウェブストア アプリで問題が発生し、CRM サービスのエラー率が急増したため、呼び出しを受けました。Cloud Trace で CRM サービスのエラー率ダッシュボードを見ると、トレース エグザンプラが表示されています。
Cloud Trace のトレースの詳細の画面には、update_user と update_product の 2 つのエラーのスパンが表示されています。そこで、このどちらかの呼び出しが問題に関係するのではないかと推測しました。update_product の呼び出しは CRM サービスの一部です。次に、CRM サービスの最近のアップデート後にこれらのエラーが発生し始めたかどうかを確認することにしました。サービスのアップデートとエラーに相関があるようなら、サービスをロールバックすることで問題を緩和できる可能性があります。
ここでは、CRM サービスのアップデートとこれらのエラーの間に相関がなかったとします。この場合、ロールバックは有効ではなく、問題についてさらに詳しく調査する必要があります。次のステップとして、サービスのログを見ることができます。
Cloud Trace のトレースの詳細の画面では、トレースのログを別の形式で表示するオプションを選択できます。[展開して表示] を選択すると、それぞれのスパンの下に、関連ログがすべて表示されます。
この例では、update_product のスパンの下にデータベース関連の 3 つのログが表示されています。CRM サービスからデータベースへの接続を数回試行したあと、エラーが発生していることがわかります。
上記の操作の背後では、Cloud Trace が Cloud Logging にクエリを送信し、このトレースと同じタイムフレーム内の、問題の traceID と spanID を参照するログを取得しています。こうして取得したログが、Cloud Trace 側で該当スパンの下に子ノードとして表示されます。これにより、サービスの呼び出しと、そのサービスの実行中に生成されたログとの相関が明確になります。
他のサービスはデータベースに正常に接続できているため、構成エラーの可能性が高そうです。そこで、CRM サービスからデータベースへの接続の構成アップデートがあったかどうかを確認したところ、最近、アップデートが 1 回あったことがわかりました。この構成アップデートの pull リクエストを確認し、構成エラーが問題の原因であることを確信しました。そこで、構成を手早くアップデートして本番環境にデプロイし、問題を解決しました。
この例では、ロールバックなどの方法で問題を解決できない場合に、Cloud Trace と Cloud Logging のトレースとログを組み合わせることが、根本原因解析を実行するために大変効果的であることがわかります。
ログとトレースの相関を正しく計測可能にする方法にご興味がおありでしたら、以下の例をご覧ください。
Cloud Trace で OpenTelemetry を使って計測可能にするには、こちらの Codelab またはウェビナーをご覧ください。
-Google Cloud、プロダクト マネージャー Sujay Solomon
