これからやるかもの案件でECS FargateのCPUがサチってるとのことなので、改めて勉強。
浅いけど今は、少なくとも以下は確認したいという結論
- サチっているのが、サービス使用率なのかタスク使用率なのか（多分サービス使用率）
- タスク定義におけるリソース定義（CPU、Memory）はどの組み合わせか（なんとなく最大にしてそう）
- サービス定義のdesiredCount（タスクを実行状態に保つ数）
どういうチューニングができるのかはこれから詳細を追っていくので楽しみである。
可能性ありそうなのは以下かなあ。
- ベースイメージやコンテナイメージがでかくなってしまってて、起動時点ですでにCPUを食っている
- これってどうやって確認したらいいのだろうか。
- 単純にCPU効率が悪いソース
- 1タスクあたりの割当が小さすぎる
Fargateとは
- ECSでコンテナを実行する際の起動タイプのうちの1つ
- EC2起動タイプかFargate
- EC2起動タイプではオーケストレーション（どのホストマシンで、どのコンテナを、いくつ起動するかなど）はされるが、各ホストマシンの管理/運用業務は依然として残る
- Fargateではホストマシン抽象化され、ホストマシンを意識することなくコンテナを実行可能
- ホストマシンの管理・運用が不要
リソースの指定方法
- タスクにvCPUとメモリで組み合わせを指定して割り当てる
メリット
クラスタの管理が不要
- コンテナ実行時に必要なCPU、メモリの組み合わせを選択するだけ
- ホストマシンのリソースの見積もり不要
シームレスなスケーリング
- ホストマシン意識しないので、シームレスにスケーリング可能
- 通常はコンテナのスケーリングに合わせてホストマシンを適宜スケーリングさせつつるという必要があり、余裕を持たせる、か、しきい値を設定し必要に応じてスケールさせるという選択を迫られる
どういった監視ができるのか
CloudWatchメトリクス
サービス使用率
- CPUUtilization
- サービスに属するタスクで使用されているCPUユニット数を、サービスに属するタスクで予約されているCPUユニット数で割った値
- 有効な統計はAverage
- MemoryUtilization
- サービスに付属するタスク数をサービスに属するタスクのためのメモリ総数で割った数で使用中の合計メモリを測定。
- 有効な統計はAverage
- サービスのタスク定義で指定されたCPUおよびメモリに対して、どれくらいタスクが実際に使っているか
(Total CPU units used by tasks in service) x 100
Service CPU utilization = ----------------------------------------------------------------------------
(Total CPU units specified in task definition) x (number of tasks in service)
(Total MiB of memory used by tasks in service) x 100
Service memory utilization = --------------------------------------------------------------------------------
(Total MiB of memory specified in task definition) x (number of tasks in service)
Container Insights
- コンテナ化されたアプリケーションとマイクロサービスのメトリクスとログを収集、集計、要約
- このメトリクスには、CPU、メモリ、ディスク、ネットワークなどのリソース使用率が含まれる
以下メトリクスが表示されるダッシュボードが自動でできるっぽい
- CPU Utilization
- Memory Utilization
- Network
- Container Instance Count
- Task Count
- Service Count
タスク定義、サービス単位で見れるのが利点
所感
- Container Insightsでタスク定義ごとのCPU/メモリ使用率まで見れるようになったことは利点と言える
- サービス使用率はサチってないけど、タスク定義単位ではサチっているとかありそう
- 一方で、タスク定義内のタスク全体のサマリ、サービス内のタスク全体のサマリになっているので、各タスク（要はコンテナ）についての動き自体は見れないので、個々のコンテナ単位でのリソース使用の時系列変動は見れない
- 別にこういった情報はいつも見れる必要はないし、逆に粒度が細かすぎて見ずらいとは思うのだが、問題が起こった時にサービス/タスク定義ないのサマリだけだと事象がわかりにくくなってしまうのではないかという懸念をいだいた。
- Prometheusみたいに柔軟にサマったり、個々を見たりできるようにしておくほうが良さそうな気がしている
ECSの概念
- ECSはクラスター（複数EC2）の上で
- Dockerコンテナを使って
- Serviceを動作させる
Service
| 管理する情報 | 指定する方法 |
|---|---|
| どんなコンテナを起動するのか | どのTask Definitionを使うか指定する |
| 何個起動するのか | Number of Tasksとして常時起動しておきたい個数をしていする |
| リクエスト分散するのか | コンテナとELBの紐付けを指定する |
- Serviceは複数個のDodkerコンテナの集合体
- MicroServiceの粒度？
Task
- Dockerコンテナを束ねるのがTask
- Taskの定義はTask Definition（Docker Composeのcompose.ymlと大体同じ）
