API Gateway × ECS の実務設計
目次
導入
API Gateway と ECS を組み合わせた構成は、マイクロサービスを構築する上で非常に一般的です。しかし、実務では「タイムアウト」「VPC Link」「ログ設計」「スロットリング」など、設計時に注意すべきポイントが多く存在します。これらを正しく理解していないと、パフォーマンス低下や障害時の原因特定の遅れにつながり、運用コストが増大してしまいます。
本記事では、API Gateway と ECS を組み合わせた際に押さえておくべき 実務的な設計ポイント を整理し、現場で役立つベストプラクティスをご紹介いたします。
API Gateway × ECS の基本構成
API Gateway から ECS のサービスへ接続する場合、一般的には VPC Link → NLB → ECS（Fargate） という構成を取ります。VPC Link を利用することで、ECS を Public Subnet に置く必要がなく、Private Subnet 内で安全に運用できます。
API Gateway には REST API と HTTP API の2種類があります。
- REST API：機能が豊富だが料金が高い
- HTTP API：軽量・低コスト・高速
ECS との連携だけであれば HTTP API で十分なケースが多く、コスト面でもメリットがあります。
タイムアウト設計のベストプラクティス
対策のポイント
- ECS 側の処理時間を短縮する
- → 重い処理は API で直接実行しない
- 非同期化（SQS / EventBridge）
- → 即時レスポンスを返し、裏で処理を進める
- アプリ側のタイムアウトを短めに設定
- → httpx や RestTemplate の timeout を適切に設定
- リトライ戦略を明確にする
- → 外部API呼び出しはリトライ回数・間隔を定義
特に「重い処理を API で直接叩く」設計は避けるべきです。非同期化することで、API Gateway の制限を回避できます。
VPC Link の使いどころ
VPC Link は、API Gateway から VPC 内のリソースへ安全に接続するための仕組みです。
ECS を Private Subnet に配置する場合、VPC Link はほぼ必須となります。
① NLB を使う理由
- L4 レベルで高速
- 固定 IP を持てる
- VPC Link と相性が良い
逆に ALB は VPC Link と組み合わせるメリットが薄く、API Gateway → VPC Link → NLB → ECS が最も安定した構成です。
② 注意点
- 作成に時間がかかる（数分〜十数分）
- 利用料金が発生する
- NLB のヘルスチェック設定が重要
ログ・可観測性の設計
API Gateway と ECS の組み合わせでは、ログとトレースの設計が非常に重要です。
① API Gateway のログ
- アクセスログ（CloudWatch Logs）
- リクエスト/レスポンスの詳細ログ
- ステージ変数でログレベルを制御
② ECS のログ
- awslogs で CloudWatch Logs に集約
- FireLens（Fluent Bit）で外部転送
- JSON 形式で構造化ログを出力するのがベスト
③ X-Ray による可視化
API Gateway と ECS の両方で X-Ray を有効化することで、遅延の原因が API Gateway 側なのか ECS 側なのか を可視化できます。
特に、外部API呼び出しやDBアクセスがボトルネックになっている場合、X-Ray のトレースが非常に役立ちます。
スロットリングとエラーハンドリング
API Gateway にはレート制限があり、過剰なリクエストを自動的に制御できます。一方、ECS 側はスケールアウトに時間がかかるため、API Gateway のスロットリング設定と ECS のスケール戦略を合わせる ことが重要です。
- API Gateway：Burst / Rate を設定
- ECS：CPU/メモリ使用率でスケール
- NLB：ヘルスチェックで不健康タスクを除外
これにより、負荷が高い状況でも安定したサービス提供が可能になります。
まとめ
API Gateway × ECS の構成はシンプルに見えて、実務では多くの設計ポイントがあります。
特に、タイムアウト・VPC Link・ログ設計・スロットリングは品質に直結する重要な要素です。
これらを正しく設計することで、安定したマイクロサービス基盤を構築でき、運用コストの削減にもつながります。
