AWSで以下のような構成のアプリを運用しています。

クライアント → NLB → ALB → ECS

その際に「リクエストが来てからレスポンスが返るまで遅い気がするけど、どこが遅いのか分からない」という問題にぶつかりました。

やりたかったこと

• NLBに到達してからレスポンスが返るまでの時間を知りたい
• どのAPIが遅いのかを特定したい

結論

NLB単体では厳しいので、ALBアクセスログをAthenaで分析するのが現実解でした。

ALBログには以下の3つの時間が含まれています。

• request_processing_time
  → ALBがリクエストを受け取ってから、ターゲット（ECS）に転送するまでの時間
• target_processing_time
  → ターゲット（ECS / アプリ）が処理して、レスポンスを返し始めるまでの時間
• response_processing_time
  → ALBがターゲットからのレスポンスを受け取って、クライアントへ返し始めるまでの時間

これを合計すると、

ALBに到達してからレスポンスを返すまでの時間

が分かります。

手順

1. ALBアクセスログをS3に出力

ALBの設定からアクセスログを有効化し、S3に出力します。

2. Athenaのクエリ結果出力先を設定

Athenaはデフォルトではクエリを実行できないため、S3に出力先を設定します。

• Athena コンソール → Settings
• 「Query result location」にS3パスを設定

例:

s3://your-bucket/athena-results/

3. Athenaでテーブル作成

S3上のログ（gz形式）をそのままクエリできます。

CREATE DATABASE IF NOT EXISTS alb_log_db;

（※CREATE TABLEは公式の定義を使用）

4. レスポンス時間をクエリ

SELECT
  request_url,
  count(*) AS req_count,
  avg(request_processing_time + target_processing_time + response_processing_time) AS avg_total_time,
  max(request_processing_time + target_processing_time + response_processing_time) AS max_total_time
FROM alb_log_db.alb_access_logs
WHERE time >= '2026-03-23T00:00:00'
  AND time <  '2026-03-24T00:00:00'
GROUP BY request_url
ORDER BY avg_total_time DESC
LIMIT 50;

結果

実際に分析してみると、

• 最大でも 約70ms
• 多くは 5〜30ms

で、サーバ側は特に遅くないことが分かりました。

まとめ

今回はAthenaを使用したALBログの調査方法をまとめました。

実際にやってみると簡単かつ短時間でログの解析ができたのでぜひ試してみてください。

おまけ：遅いリクエストを直接見る

SELECT
  time,
  request_url,
  request_processing_time,
  target_processing_time,
  response_processing_time,
  request_processing_time + target_processing_time + response_processing_time AS total_time
FROM alb_log_db.alb_access_logs
ORDER BY total_time DESC
LIMIT 100;

このあたりを整備しておくと、パフォーマンス調査がかなり楽になります。