はじめに
AWS Fargateを使用している際に、ECSクラスターをECSサービスごとやECSタスクごとにどのように分けるかに迷うことがありました。
そこで、個人的に複数の観点からクラスターの効果的な分け方を考えてみました。
なお、この記事ではECS on EC2ではなく、ECS on Fargateのみに焦点を当てています。
ECSについて
ECSの構成について簡単に説明しますと以下の3つに分かれます
- クラスター
- タスクとサービスを実行する基盤です
- サービス
- ECSクラスター内で、タスクを実行し管理します
- タスク
- タスク定義に基づいてコンテナを起動します
今回は、タスクとサービスを実行する基盤であるクラスターをどのような単位で分けるべきかを考えてみました。
一般的
一般的には、システムや環境ごとにクラスターを作成すると良いでしょう。
理由としては、２点あります。
1. リソース作成の簡易化
クラスターを作成する際には、コンソール上のネットワーキングという項目でVPCとサブネットを指定して作成します。
これにより、コンソール上でサービスやタスクを作成する際、下記のように指定したVPCが自動的に選択され、作成が容易になります。
クラスター作成時
ECSサービス作成時
システムや環境別にVPCが分けられていることが多いため、システムや環境ごとにクラスターを分けると、サービスやタスクの作成がしやすくなります。
2 リソースの役割の理解
AWSリソースの命名規則は、「システム名」「環境名」を含めていることが多いです。
そのため、命名規則に合わせて、クラスターの名前も例えば{システム名}-{環境名}-clusterとすることで、各クラスター内のリソースの役割が分かりやすくなります。
以上の２点の理由から、一般的には、システムや環境ごとにクラスターを作成すると良いと考えます
セキュリティの観点
セキュリティの観点ではクラスターを分けることで、特定のユーザーに対して詳細な権限制御が可能になります。
外部の開発ベンダーの方が特定のクラスターのみを利用する場合などに利用されます。
ECSのAPIであるCreateService、UpdateService、DeleteService、RunTask、StartTask APIなどは、AWS IAMのポリシー内のConditionキーを使用して操作可能なクラスターを指定できます。
Conditionキーを活用することで、「特定のユーザーは、Bシステムのクラスターでサービスやタスクを作成・更新できるが、Aシステムのクラスターではできない」といった詳細な権限制御を行うことができます。
サービスのクォータ (制限) の観点
次に、サービスクォータの観点です。
サービスクォータとは、あらかじめ設定されたデフォルトの上限値のことを指します。
ECSのサービスクォータは、下記のドキュメントにまとめられておりますが、その中でもクラスターを分ける観点になりえる項目を表形式でピックアップします
| 項目 | 各リージョンのデフォルト | 調整 |
|---|---|---|
| クラスターに関連付けるキャパシティプロバイダー数 | 20 | 不可 |
| クラスター数 | 10,000 | 可能 |
| クラスターあたりのコンテナインスタンスの数 | 5,000 | 不可 |
| クラスターあたりのサービスの数 | 5,000 | 可能 |
これらのサービスクォータが問題になる場合は、クラスターを分けることでクォータの制限を回避できる場合があります。
コストの観点
コストの観点では、２点ございます。
Container Insights
ECSクラスターは、Container Insightsというモニタリング機能を有効にすることができます。
この機能により、クラスター、サービス、タスクのパフォーマンスメトリクスを確認できますが、有効化するとCloudWatchのカスタムメトリクスが自動的に作成されます。
Container Insightsの詳細は下記記事をご参照ください
CloudWatchのカスタムメトリクスの料金は、東京リージョンの場合、1メトリクスにつき0.30 USD/月かかります。
そのため、モニタリング機能が不要なタスクと必要なタスクをクラスター単位で分けることで、不要なコストを削減できます。
タスク停止理由のログ保存
通常、AWS FargateのECSタスクが停止した場合、タスクの停止理由の確認は、コンソール上で確認できますが、1時間を過ぎると削除されます。
過去にさかのぼって確認したい場合、CloudWatch Logsに保存する必要があります。
ログの保存方法は、下記の記事をご参照ください
上記の方法ですと、基本的にクラスター単位でCloudWatch Logsにタスク停止のログが出力されます。（厳密には、タスク定義のリビジョンごとに絞ることもできますが、リビジョンが変わるとログが保存されなくなるため、現実的ではありません。）
クラスター内では、タスク停止のログが必要のないタスクも保存されてしまうため、CloudWatch Logsの保管料金や分析時にノイズになる可能性があります。
これを防ぐためにも、タスク停止のログが必要なタスクのみをクラスター単位で分けるとよいでしょう。
最後に
今回は、ECS on Fargateを利用する際のクラスターの分け方について考えてみました。
適切なクラスターの設計は、コストやセキュリティを含めた効率的な運用に重要です。
他にも色々な考え方でクラスターを分けることがあると思いますが、一例として参考にして頂ければ幸いです。
3
