AWS FargateにおけるAmazon ECS クラスターの効果的な分け方を様々な観点で考えてみた

AWS FargateにおけるAmazon ECS クラスターの効果的な分け方を様々な観点で考えてみた

Clock Icon2023.08.03

はじめに

AWS Fargateを使用している際に、ECSクラスターをECSサービスごとやECSタスクごとにどのように分けるかに迷うことがありました。

そこで、個人的に複数の観点からクラスターの効果的な分け方を考えてみました。

なお、この記事ではECS on EC2ではなく、ECS on Fargateのみに焦点を当てています。

ECSについて

ECSの構成について簡単に説明しますと以下の3つに分かれます

  • クラスター
    • タスクとサービスを実行する基盤です
  • サービス
    • ECSクラスター内で、タスクを実行し管理します
  • タスク
    • タスク定義に基づいてコンテナを起動します

今回は、タスクとサービスを実行する基盤であるクラスターをどのような単位で分けるべきかを考えてみました。

一般的

一般的には、システムや環境ごとにクラスターを作成すると良いでしょう。

理由としては、2点あります。

1. リソース作成の簡易化

クラスターを作成する際には、コンソール上のネットワーキングという項目でVPCとサブネットを指定して作成します。

これにより、コンソール上でサービスやタスクを作成する際、下記のように指定したVPCが自動的に選択され、作成が容易になります。

クラスター作成時

ECSサービス作成時

システムや環境別にVPCが分けられていることが多いため、システムや環境ごとにクラスターを分けると、サービスやタスクの作成がしやすくなります。

2 リソースの役割の理解

AWSリソースの命名規則は、「システム名」「環境名」を含めていることが多いです。

そのため、命名規則に合わせて、クラスターの名前も例えば{システム名}-{環境名}-clusterとすることで、各クラスター内のリソースの役割が分かりやすくなります。

以上の2点の理由から、一般的には、システムや環境ごとにクラスターを作成すると良いと考えます

セキュリティの観点

セキュリティの観点ではクラスターを分けることで、特定のユーザーに対して詳細な権限制御が可能になります。

外部の開発ベンダーの方が特定のクラスターのみを利用する場合などに利用されます。

ECSのAPIであるCreateService、UpdateService、DeleteService、RunTask、StartTask APIなどは、AWS IAMのポリシー内のConditionキーを使用して操作可能なクラスターを指定できます。

Conditionキーを活用することで、「特定のユーザーは、Bシステムのクラスターでサービスやタスクを作成・更新できるが、Aシステムのクラスターではできない」といった詳細な権限制御を行うことができます。

サービスのクォータ (制限) の観点

次に、サービスクォータの観点です。

サービスクォータとは、あらかじめ設定されたデフォルトの上限値のことを指します。

ECSのサービスクォータは、下記のドキュメントにまとめられておりますが、その中でもクラスターを分ける観点になりえる項目を表形式でピックアップします

項目 各リージョンのデフォルト 調整
クラスターに関連付けるキャパシティプロバイダー数 20 不可
クラスター数 10,000 可能
クラスターあたりのコンテナインスタンスの数 5,000 不可
クラスターあたりのサービスの数 5,000 可能

これらのサービスクォータが問題になる場合は、クラスターを分けることでクォータの制限を回避できる場合があります。

コストの観点

コストの観点では、2点ございます。

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を利用する際のクラスターの分け方について考えてみました。

適切なクラスターの設計は、コストやセキュリティを含めた効率的な運用に重要です。

他にも色々な考え方でクラスターを分けることがあると思いますが、一例として参考にして頂ければ幸いです。

参考

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.