ECS Service Discoveryを採用しようとして採用しなかった話

この記事は、Finatext Advent Calendar 2025 の1日目の記事です。

この記事の趣旨

AWSアーキテクチャ選定において、当初は「ECS Service Discovery」を採用しようとしましたが、ある指摘を受けて「ELB」の採用へと方針転換しました。
本記事は、その経緯と学びを振り返るものです。

与えられた要件と制約

今回のプロジェクトには、以下の要件と制約がありました。

• 要件
  • APIに対するレート制限
  • トランザクションデータの永続化
• 制約
  • プロジェクト期間が3ヶ月（実開発期間は1ヶ月）

これらに対応するため、主要なAWSサービスとして以下を選定しました。

• API Gateway
  • レート制限の要件に最も簡単に対応できるため。
  • ※最近 ALBでもレート制限に対応できるようになったようですが、プロジェクト開始時点では未公開の機能でした。
• Aurora
  • DynamoDBも候補でしたが、期間の短さを考慮し、RDBの知見を活かして学習コストを抑えられるAurora MySQLを選択。
• Fargate
  • Lambdaも候補でしたが、Aurora MySQLへのデータベース接続の安定性を考慮し、Fargateを選択。

これらのサービスを組み合わせる上で、アーキテクチャの選択肢は以下の2つとなりました。

アーキテクチャ1. ECS Service Discovery (Cloud Map) を採用

アーキテクチャ2. ELB を採用

なぜ当初、ECS Service Discoveryを採用しようとしたのか

理由は主に2つありました。

1. AWSインフラコストの削減

これまでの経験では、Webアプリケーションのバックエンド構成として CloudFront → ELB → Fargate を採用することが多く、FargateへのルーティングにはELBを使用していました。

しかし、ELBはコストが少々気になります。
リクエスト数に応じた従量課金を除いても、東京リージョンであれば時間あたり0.0243USD、月額で約17.5USDかかります。単一環境なら許容範囲ですが、環境が増えるにつれて無視できない金額になります。

今回、CloudFrontのオリジンにAPI Gatewayを使用しますが、API GatewayにはVPC内のリソースを呼び出せる「プライベート統合」という機能があります。
これとECS Service Discoveryを組み合わせれば、プライベートDNSでサービスエンドポイントを名前解決でき、ロードバランサー無しでルーティングが可能になります。

ECS Service DiscoveryであればコストはRoute53の料金のみ。多くても月額1USD程度で済み、ELB分のコストをまるっと削減できると考えました。

2. 使ったことがない技術への好奇心

正直に言えば、意思決定の比重はこちらの方が大きかったと思います。
2つのアーキテクチャが可能だと分かったとき、ECS Service Discoveryを使う「アーキテクチャ1」の方が魅力的に映りました。

今思えば、そこにはコスト削減だけでなく、「珍しいアーキテクチャを採用してシステムを作り切りたい」という好奇心や、「自分の技術力をアピールしたい・評価されたい」という自己顕示欲が潜んでいたと思います。

なぜECS Service Discoveryを採用しなかったのか

ECS Service Discoveryを用いた構成は、試行錯誤の末に開発環境で構築することには成功しました。しかし、タスクが切り替わるたびにIPアドレスが変わり、それに伴ってDNSレコードも変更されるため、Platform Teamが設定している自動アラートが頻繁に反応してしまう状態でした。

週次で社内の全エンジニアが集まるミーティングがあり、その後の余った時間でCTOの田島さんによもやまに質問ができる時間があるのですが、ある日そこで自動アラートの対象から除外することはできないかを聞いてみました。

その時、予想外の回答が返ってきました。
「そもそも、そのアプリケーションの目的に対して、本当にECS Service Discoveryを使う必要があるのか？」

この言葉で、自分がアーキテクチャの選択を誤っているかもしれないことに初めて気づきました。改めて検討し直した結果、以下の3点を考慮して方針転換を決断しました。

1. 運用の不確実性

ロードバランサー構成と比較した際、ECS Service Discovery構成には運用面での不確実性がありました。

• ヘルスチェックの信頼性:
  ECS Service Discoveryにはロードバランサーのようなヘルスチェック機能がなく、コンテナ独自のヘルスチェックに依存します。通信が無効でもコンテナ自体が生きていれば成功とみなされる場合があり、意図せずサービス利用不可の状態に陥るリスクがあります。
• トラブルシューティングの難易度:
  インターネット上の情報量がロードバランサー構成に比べて圧倒的に少ないです。トラブル発生時に解決まで時間がかかる恐れがあり、LLMに質問してもハルシネーション（誤った情報の生成）を起こす可能性が高まります。
• 機能制約:
  この構成ではAPI Gatewayとして「HTTP API」を使用する必要があります。「REST API」の一部機能が使えないことで、本来の要件であるレート制限を簡単には実装できない懸念がありました。

2. YAGNI (You Ain't Gonna Need It)

もしマイクロサービス化によってInternal ELBを何個も立てなければならない状況であれば、ECS Service Discoveryによるコスト削減効果は大きいでしょう。

しかし、本プロジェクトは現時点でマイクロサービスにする必要はありませんでした。
将来的にサービスが成長してマイクロサービス化する可能性はあるかもしれませんが、あくまで可能性です。
YAGNIの原則に従い、今ある要件を安全かつ確実に満たすことの方が優先順位が高いと判断しました。

3. サービス継続の不確実性

近年、AWSは利用頻度の低いサービスや機能をクローズさせるサイクルを早めています。
ECS Service Discoveryも例外ではないかもしれません。苦労して構築しても、AWSから終了宣言が出れば作り直しです。

要件を満たせるのであれば、世間で広く使われている「枯れた」サービスを採用した方が、サービス終了の憂き目に遭うリスクは低くなります。

そこから何を学んだのか

最終的にECS Service Discoveryをやめ、ELBを採用する「アーキテクチャ2」へ変更しました。
手戻り作業は発生しましたが、リリース後のシステムは非常に安定しており、不具合はほとんど発生していません。

もちろん、ECS Service Discoveryのままでも安定運用できていたかもしれません。しかし、「想定外の事態」が起こる確率は、現状のアーキテクチャよりも高かったはずです。安定性が最優先される今回のプロジェクトにおいて、不確実な要素を排除したことは、今振り返っても良い選択でした。

今回の出来事を通じて、私は以下のことを改めて学びました。

• プロジェクトの目的やリスク許容度に応じて、適切なアーキテクチャ選定を行うこと
• 「新しい技術を使ってみたい」という個人的な好奇心は、プロジェクトの優先順位より必ず下であること

当たり前のことではありますが、エンジニアとして大切な視点を実際の経験から得ることができました。