こんにちは、こんばんは。
バックエンドチームの青木です。
最近休みの日にData Centerというゲームでデータセンターの運用シミュレーションをするのにハマってます。
ちゃんと故障要素があって交換計画を立てる必要があったりと凝られたゲームなのでおすすめです。
https://store.steampowered.com/app/4170200/Data_Center/?l=japanese

ゲームの中では設備運用を考えるのですが、仕事でもちゃんとインフラ構成や運用を考えています。
最近、0→1で開発する機会があり、そのシステムをAWS上にリリースするところまで一通り触ることがありました。

これまで弊社では、サーバーを構築する場合、だいたいEC2を使ってました。
ただ、今回の新規開発をきっかけに、ECSという選択肢を採用してみることになりました。

そこで今回は、EC2での構築が一般的だった中で、ECSに挑戦してみた話をまとめてみようと思います。

なぜ今回ECSを検討したのか

今回ECSを検討した理由はいくつかありますが、大きかったのは次の2点です。

• 可用性を強く意識したい仕組みだった
• サーバー運用の責任範囲をなるべく減らしたかった

可用性を強く意識したい仕組みだった

今回のシステムはユーザー影響がかなり大きいです。
売上に直結し、システムが止まることでの損害は計り知れません。
多少止まってもいい社内ツールとは重みが違いました。

※社内ツールを軽視しているわけではない

サーバー運用の責任範囲をなるべく減らしたかった

今回のシステムでは、EC2上でOSやサーバーを細かくチューニングしたい要件があったわけではありませんでした。
むしろ、OSのパッチ適用やホスト管理、OSライフサイクルへの追従といったサーバー運用を強く意識するよりも、アプリケーションをどう安定して動かし、どうデプロイしやすくするかに意識を寄せたい気持ちがありました。

たとえばEC2では、Amazon Linux 2のサポート終了（2026年6月予定）のように、ホストOSの更新や移行も運用上の考慮事項になります。
その点、ECS、特にFargateはサーバーやEC2クラスターの管理を強く意識せずにコンテナを動かせるため、今回のシステムとは相性がいいと思いました。

きれいに言うと「運用責任の範囲を減らしたかった」ですが、正直に言うと、ホストOSの更新や移行まで常に気にし続ける運用を、なるべく避けたいというのが本音

ECS導入はゴールではなくスタートだった

ECSで新しい構成を作ったから終わり、というわけではなく、ここから考えていくことはまだまだあります。

たとえば、

• TerraformとCI/CDの責務分離をどう整理するか
• ECSの知見をチームにどう広げるか
• 監視や障害対応をどう整理するか

などぱっと思いつくだけでも宿題は山積みです。

自分は新しいことにチャレンジすると、「全部それで作りたくなる」「今あるものも作り直したくなる」症候群がたまに出てきます。
この記事を書くまではそうでした。
ただ今回は得た経験、知見をもとに冷静に使い分けれるエンジニアを引き続き目指します。

さようなら