責任分界を意識してEC2からECSへ移行する

ツール導入前の課題

• アプリケーションレイヤーで1つのアプリケーションが複数の役割を持っていた
  • これを一定の役割ごとに分割することにした

どのような状態を目指していたか

• 当時EC2上で稼働していたが、状態管理が適切に行われていなかった
  • そこで、適切に状態管理を行いやすい、またはそもそもその必要のないサービス上に展開することを目指した

• EC2
• Lambda

• 重い処理を含むスケジュールバッチおよびapiサーバを同様の仕組みで管理できること
• サーバ管理コストができるだけかからないこと

• EventBridgeルール/スケジューラやStepFunctionsと組み合わせて使うことでバッチ管理しやすい
• アプリケーションとインフラストラクチャの責任分界がはっきりしていること
  • アプリケーション：イメージビルド、タスク定義管理
  • インフラストラクチャ：ECSクラスタ/サービス管理、ドメイン設定 etc

上記の条件はLambdaも満たしているが、以下の点からECSを選択

• 複雑なアプリケーションであり、コードサイズの制限にかかった
• 長時間バッチの実行に耐えられない
• サーバ接続してコマンド実行したいユースケースが存在した
• ローカル実行環境を利用するのにクセがある
  • DockerImageを利用したLambdaを利用すればおそらく解決される

FargateとしたケースではAnsibleによる状態管理が不要となり、インフラ管理ツールをTerraformに統一することができました。

1. 責任分界点を意識したCDパイプラインの作成

• 開発チーム：タスク定義
• インフラチーム：ECSクラスタ、サービス

というように責務を分解し、タスク定義は開発リポジトリで管理することとしました。 CircleCIでデプロイパイプラインを作成していましたが、当時はaws-ecsOrbをそのまま用いるだけではうまく想定するタスク定義が作成できなかったため、

• タスク定義をjsonで作成 -> タスク定義の登録 -> サービスの更新

という一連の流れを自前で実装しました。（おそらく記載時点ではもっとラクにできるはず）

2. 基盤の選択（EC2 or Fargate）

それぞれにメリット・デメリットがあるため、サービスによって使い分けています。一例は以下です。

• EC2
  • メリット
    • コストコントロールがしやすい
    • 細かなチューニングを行いやすい
      • Fargateの場合は制約が多い
  • デメリット
    • 状態を持つことになるためその管理・運用が必須となる
• Fargate
  • メリット
    • サーバ運用管理コストがゼロ
      • 気にしなくてもセキュリティパッチが自動で適用されるetc
    • （バッチ稼働において）稼働した分だけリソースが使用される
  • デメリット
    • 従量課金のため、コストコントロールがしにくい
    • EC2に比べるとやや割高

3. ブルーグリーンデプロイメントによる切り替え

もともとEC2サーバで稼働中のものをダウンタイムをとることなく、かつ不備があった場合にすぐ戻せるようにブルーグリーンデプロイ方式で移行を行いました。

4. 稼働しているFargateサーバ上への接続設定

当時は情報が少なく苦労した点の1つです。 ECSExecをサービス（タスク）側で有効にし、execute-commandコマンドによって接続することが可能です。

Lambdaのほうがより手軽に解決することが可能ですが、制約事項も多く、のちにパフォーマンス等の最適化を行いたくなったときに苦労します。一方でECSを選択しておくと細かな実行環境設定がしたくなった場合は、基盤をFargateからEC2に変更するだけで他の設定を変更することなく実現できます。 また、近年のクラウドネイティブといえばKubernetesが筆頭ですが、学習コストおよび運用コストが非常に高く、最初のコンテナ環境として利用するにはある程度の覚悟が必要となります。

上記より、もっともバランスのとれたサービスがECSであると感じています。