【要約】AWS Cloud Mapを使って低コストでECSサービス間通信を実現しよう🔎 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が、ECS Fargate上のコンテナ間で通信を行う際、接続先の特定とコスト抑制の両立という課題に直面した。具体的には、以下の問題が発生していた。
- ・コンテナのデプロイごとにIPアドレスが変動するため、接続先を静的に指定できない。
- ・既存の外部公開用ALBを経由すると、内部APIまで外部に公開されてしまう。
- ・内部ALBの追加やService Connectの導入は、インフラコストを増大させる。
// Approach
開発者は、機能の過剰な導入を避け、コストを最小化するためにAWS Cloud Mapを採用した。以下の手順で実装を進めている。
- ・セキュリティグループの設定：WebサーバからAPIサーバへの通信（ポート8080）を許可する。
- ・Cloud Mapの構築：VPC内限定のプライベートDNS名前空間と、API用のサービスを作成する。
- ・ECSへの登録：ECSサービスの定義にservice_registriesブロックを追加し、タスクをCloud Mapへ紐付ける。
// Result
開発者は、Cloud Mapの導入により、低コストで名前解決が可能な通信環境を実現した。
- ・Webサーバがbackend.example.localという名前でAPIサーバを呼び出せるようになった。
- ・追加コストを月額$0.5程度に抑え、経済的なサービス間通信を実現した。
- ・既存のALB構成を変更せず、内部通信のみを完結させた。
Senior Engineer Insight
> 本構成は、コスト効率を最優先する開発環境や小規模なマイクロサービスには極めて有効だ。しかし、Cloud MapはDNSベースの名前解決に特化しており、L7レベルの負荷分散やリトライ制御を持たない。本番環境で高い可用性を求めるなら、Service Connectの採用か、アプリケーション層でのリトライ実装が必須となる。設計時に「機能の過剰さ」を排除する姿勢は評価できるが、運用フェーズでのエラーハンドリングコストとのトレードオフを常に意識すべきである。