Link and Motivation Developers' Blog

リンクアンドモチベーションの開発者ブログです

ECS on EC2 から ECS on Fargate への移行で考慮した4つのポイント

こんにちは、リンクアンドモチベーション SREグループの久原です。今回はSREチーム内で取り組んでいるAmazon ECS on Amazon EC2(以下 ECS on EC2)構成からAmazon ECS on AWS Fargate(以下ECS on Fargate)構成への移行プロジェクトについて、特にEC2とFargateの差分を中心にお話しできればと思います。

背景

サーバーレスへの移行に関するメリットについてはここでは詳しくは触れませんが、一般的に言われているように サーバー管理等の運用コスト削減 が主な移行の背景となります。

弊社ではこちらの記事に記載のある通り、4Keys Metricsという指標をモニタリングし、開発組織の継続的な改善活動に取り組んでいます。 開発フローの細かな改善も重要ですが、より高いレベルに進化させるためには抜本的なアーキテクチャの見直しが必要となります。今回はその足がかりとなるべく、サーバーレス化を推進しました。

コンテナオーケストレーションサービスの選定についてもここでは詳細を記述しませんが、現状がECS on EC2 構成であるために、まずは移行ハードルの低いECS on Fargate の構成(=オーケストレーションサービスは変更しない)を選択しました。

構成の概要

ECSに関連するインフラ構成は以下のようになっています。

今回は、ECS Taskの実行環境をEC2からFargateに移行を検討しました。

ECS on EC2 から ECS on Fargate 移行での4つのポイント

実際にFargate移行を検討した際に大きく4つ、EC2と違うポイントがありました。

  1. タスクのスペック定義
  2. ネットワークモード
  3. タスクからのデータボリュームの使用
  4. ホストインスタンスにインストールしていたツール

以下で1つ1つ詳細を記載します。

①タスクのスペック定義

こちらは以下のオレンジで網掛けしたECS Task部分に関連する違いです。

公式ドキュメント(Fargate, EC2)に記載のある通り、以下のような違いがあります。

  • Fargate: CPUとメモリサイズを組み合わせて選ぶ
  • EC2: インスタンスタイプから選ぶ

Fargateに移行することで、EC2インスタンスタイプよりも柔軟にCPU, メモリサイズの選択ができました。これによって、タスクごとに最適なスペックを選択することができます。

②ネットワークモード

こちらは以下のオレンジで網掛けしたALBからECS Serviceへのアクセスに関連する違いです。

以下の引用画像のように、ECSにおけるネットワークモードは4種類あり、Fargateはそのうちのawsvpcモードのみをサポートしています。

出典: ECS での Fargate ⼊⾨, AWS Black Belt Online Seminar, Solutions Architect, Industry Solutions, Amazon Web Services Japan K.K., 杉本 晋吾 2021-Aug

弊社でECS on EC2 構成を取っていた際はhostモードを利用していたため、こちらの設定周りの変更が必要となりました。しかし、元々EC2側で設定していた内容をECS Service側に移行するだけだったので、そこまで移行のハードルは大きくありませんでした。

※Application Load Balancer のターゲットグループのTarget typeの設定について、FargateではIPアドレスのみ設定可能なので、ECS on EC2構成でinstanceを指定していた場合はこちらの変更も必要となります。

③タスクからのデータボリュームの使用

こちらは以下のオレンジで網掛けした複数コンテナ間通信に関連する違いです。

以下の引用画像のように、タスクからのデータボリュームの使用は4種類あり、Fargateはそのうちの2種類のみをサポートしています。

出典: ECS での Fargate ⼊⾨, AWS Black Belt Online Seminar, Solutions Architect, Industry Solutions, Amazon Web Services Japan K.K., 杉本 晋吾 2021-Aug

弊社ではPuma + nginx のコンテナ構成を取っており、2者のコンテナ間通信はUNIXドメインソケット通信を採用しています。その際、EC2でのバインドマウントを利用してコンテナ間通信を実現していました。 しかしFargateへの移行によってこちらの選択肢が取れなくなったため、新たに Fargateでのバインドマウント(Fargateタスクストレージ) を採用しました。

具体的な実現方法は、公式ドキュメントにあるように、PumaコンテナのDockerfile内に以下を追記するのみです。

~~
# fargate用にVolumeを作成
VOLUME /var/docker/nginx
~~

EC2の時はホストマシン側でVolumeを持って各コンテナにマウントしていましたが、Fargate移行に際してPumaコンテナ内でVolumeを持って各コンテナ内にマウントするように変更しました。

④ホストインスタンスにインストールしていたツール

こちらは以下のオレンジで網掛けしたEC2 が持つタスクインスタンスに関連する違いです。

ECS on EC2構成において、例えばDatadog等の外部ツールはEC2のホストインスタンスにインストールして利用していました。しかし、ホストインスタンスがなくなるため各サービス用のコンテナが必要となります。

例えばDatadog用コンテナ構築の具体的なやり方についてはDatadogの公式ドキュメントにある通りです。 以下のように、実際にDatadogのコンテナをサイドカーとして追加することができました。

終わりに

今回は ECS on EC2 構成から ECS on Fargate の構成への移行でしたが、サーバーレス化等のアーキテクチャ変更は開発者の事情だけでなく、事業フェーズ等のビジネス要件の変化によって最適解は変わると考えています。 今回記載したトピックが何かしら皆様の役に立っていれば幸いです。