デプロイ済みアプリケーションのトラブルシューティング

AWS へのアプリケーションデプロイ

Dunieski Otano

Amazon Web Services Solutions Architect

タスクのタイムアウト

  • 関数が断続的に失敗する
  • ログに「Task timed out」と表示される
  • エラーの特徴から真の原因を特定する

タイムアウトしたLambdaタスクのエラーログとストップウォッチ

AWS へのアプリケーションデプロイ

Lambdaの主なエラーパターン

Lambdaの障害パターン2x2グリッド：タイムアウト（task-timed-outログ）、スロットル（TooManyRequestsException）、アクセス拒否（AccessDeniedException）、メモリ不足（signal-killedエラー）

  • タイムアウト：「Task timed out after N seconds」
  • スロットル：TooManyRequestsException
  • IAM拒否：AccessDenied、権限なし
  • メモリ不足：実行中にランタイムが強制終了
AWS へのアプリケーションデプロイ

関数障害への最初の対応

  • 何かを変更する前にエラーメッセージを読む
  • 既知のパターンと照合する
  • タイムアウトの場合はダウンストリーム呼び出しのレイテンシを確認する
  • 1つだけ変更して再テストする

トラブルシューティングのループ：エラーメッセージを読む、既知パターンと照合、ダウンストリームレイテンシを確認、1つ変更して再テスト

AWS へのアプリケーションデプロイ

CloudWatch Logs Insights

Logs Insightsのクエリでは、filterで絞り込み、statsで集計します。以下はエラーを1分ごとにカウントする例です。

fields @timestamp, @message
| filter level = "ERROR"
| stats count() as errors by bin(1m)
| sort errors desc
AWS へのアプリケーションデプロイ

両側からの統合障害デバッグ

  • 障害はサービス間に潜むことが多い
  • 呼び出し元と呼び出し先の両方のログを読む
  • リクエストIDまたはトレースIDで照合する
  • ログ間のギャップが障害箇所を示す

リクエストIDで横並びに整列した呼び出し元と呼び出し先のログ。リクエストが途絶える統合の障害箇所がギャップとして示されている

AWS へのアプリケーションデプロイ

ヘルスチェックとレディネスプローブ

ロードバランサーが正常なターゲットにトラフィックを振り分け、ヘルスチェック失敗が続いたターゲットをローテーションから除外する様子

  • ヘルスチェック：インスタンスが稼働しリクエストを処理できるか
  • ロードバランサーは正常なターゲットにのみルーティングする
  • レディネス：トラフィックを受け入れる準備ができているか
  • チェック失敗でターゲットはローテーションから除外される
AWS へのアプリケーションデプロイ

トラブルシューティングのプレイブック

  • エラーを読みパターンと照合する
  • Logs Insightsでログをクエリして範囲を絞る
  • リクエストまたはトレースIDで両側を相関付ける
  • 1つだけ変更して検証する

4ステップのトラブルシューティングプレイブック：エラーを読みパターン照合、Insightsでログをクエリ、トレースIDで両側を相関付け、1つ変更して検証

AWS へのアプリケーションデプロイ

練習しましょう！

AWS へのアプリケーションデプロイ

Preparing Video For Download...