2025.04.03
こんにちは。ES/1 Shelty担当の遠藤です。
どちらかというと犬のほうが好きでしたが、最近は猫の良さがわかってきました。
さて、今回はV2.9.0より対応が始まるAWS ECSのパフォーマンス情報の分析についてご紹介します。
AWSが提供するコンテナサービスは２つあります
AWS関連のコンテナサービスは複数あり、それが理解を難しくしています。
ひとつずつ見ていきましょう。
AWSが提供するコンテナサービスは大別してEKS（Elastic Kubernetes Service）とECS（Elastic Container Service）があります。
それぞれには下表に示すような特徴があり、ECSは利用者がKubernetesを構築する作業に関与する必要がない分、気軽にコンテナ環境を利用し始めることができる製品となっています。
| EKS |
ECS |
|
|
ECSのサービスは3種類あります
さて、ECSの話になったところで、ECSには3種類のサービスがあることを説明します。
「前より種類が増えちゃった」なんて焦らないでくださいね。
ゆっくり説明します。
ECSの構成は、実際の業務を実行する基盤となるデータプレーンと、コンテナの起動／停止やIAM認証などの管理に関する処理を担う基盤であるコントロールプレーンに大別されます。
ECSの種類を見分けるポイントは前者のデータプレーンの違いにあります。
いわば、どこのサーバーで業務を実行させるか？によって種類が分かれています。
ECSは次の3種類に分けられ、データプレーンがどこにあるかが異なっています。
今回の2.9.0では、データプレーンとしてAWSのサービスを利用する「ECS on EC2」と「ECS on Fargate」の２つに対応しました。
①ECS on EC2（下図 左側）
EC2インスタンスの上でECSタスクが稼働する構成です
ユーザーがEC2インスタンスを管理する点で、ハードウェアリソースの割り当てや、ネットワークを柔軟に設定できます
②ECS on Fargate（下図 右側）
AWS Fargateサービスの上でECSタスクが稼働する構成です
サーバーレスな構成であり、インフラ管理の手間を省くことができます
③ECS Anywhere
オンプレミスのハードウェア上で動作するデータプレーンです（コントロールプレーンはAWS上でマネージドで動作します）
統制上の要件によりAWS上のリソースを利用できない場合等に利用されることがあります
ECSのデータプレーン
ECSの構成要素
「ECS on EC2」、「ECS on Fargate」どちらにせよ、ECSには下図のような構成要素から成り立っています。
ポイントは、ユーザーがコンテナを直接起動するのではなく、タスク定義にサーバーの状態を定義してから起動する点です。
例えば、「耐障害性を高めるためにWebサーバを２つ並列して起動する」とタスクに定義しておけば、あとはECSがその状態を維持しようとし、片方のWebサーバーが停止しても、新たなWebサーバーをタスク定義に従って起動してくれます。
以下、整理の意味で用語の意味を説明しています。
知ってるよ！という方は読み飛ばしてください。
ECSの構成要素
タスク
実際の業務を実行するアプリケーションの実行単位です。
データプレーン上のコンテナでタスクが実行されます。
コンテナ
タスク実行するためのリソースの集合であり、JSON形式のタスク定義を使って使用するコンテナイメージやCPUやメモリの量、環境変数などのタスクの設定を記述します。
タスク定義には複数のコンテナを指定することができ、1つのタスクとして複数のコンテナを稼働させることも可能です。
サービス
タスクが失敗または停止した場合、サービスは新たにタスクを起動し、指定された必要数を維持します。
タスクの負荷分散・スケーリングを行うことも可能となります。
クラスタ
クラスタ内では、並列化したDBのサービスと、冗長化したWebAPサービスを稼動させるといったような複数のサービスやタスクを実行できます。
ECSにおけるCPU、メモリ割り当て
ECSでは、タスク定義でCPUとメモリの割り当てをタスクレベル、コンテナレベルで指定可能です。
タスク定義
ECS種別によるリソース計画の違い
ECS on EC2と、ECS on Fargeteの違いは、リソース計画においては大きく影響します。
ECS on EC2の場合、指定なしでも起動することができます。
その場合、利用できる最大の処理能力はデータプレーンとして使っているEC2インスタンスのCPU処理能力、メモリ容量と等しくなります。
一方、ECS on Fargateでは、タスクサイズの割り当て指定が必須となります。
また、タスクレベル CPU およびメモリのパラメータは Windows コンテナでは無視されます。
Windows コンテナではコンテナレベルリソースを指定することが推奨されています。
CPU、メモリ割り当てすぎるとどうなるの？
ECS on EC2では、EC2に割り当てられている能力が上限となります。
CPU、メモリの予約値を大きく設定すると、スケーリングするときに、予約量を確保できないために、コンテナを起動できなくなることがあります。
ECS on Fargateでは、割り当て量によって料金が変わるため、大きすぎる能力を定義すると、不要な料金がかかってしまう可能性があります。
収集データ項目
ES/1 Sheltyは、ECSのパフォーマンス情報をCloud Watch、Container Insightsから取得しています。
レイヤーごとの取得データは下表の通りです。
出力される項目はECS on EC2におけるリソース割り当てのあり／なし、設定、環境によって変化します。
- クラスターレベルのメトリクスは、Amazon EC2でホストされているタスクについて報告されます
- サービスレベルのメトリクスは、Amazon EC2 インスタンスと Fargate でホストされているタスクについて報告されます
また、項目の中でよく出てくる用語を整理しておきます。
- 予約数（量）
予約されている CPU ユニット数またはメモリ容量
- 使用数（量）
実際に消費されたCPU ユニット数またはメモリ容量 - 使用率
タスクによって使用されている総数を予約されている総数割った値
- 予約率
ECS on EC2の場合のみ、クラスターレベルで報告される。クラスタに登録されているすべてのインスタンスの CPU ユニットの総数で割った数で測定される。
| データ項目／レイヤー | クラスター | サービス | タスク | コンテナ |
実行数 |
||||
コンテナ再起動回数 |
○ | ○ | ○ | |
タスク数 |
○ | |||
タスク状態（RUNNING、PENDING） |
○ | |||
必要タスク数、タスクセット数、デプロイ数 |
○ | |||
EC2インスタンス数、サービス数 |
○ | |||
CPU、メモリ |
||||
CPUユニット予約数、使用数 |
○ | ○ | ○ | ○ |
CPUユニット使用率 |
○ | ○ | ||
CPUユニット予約率、CPU予約率 |
○ | |||
メモリ予約量、使用量 |
○ | ○ | ○ | ○ |
メモリ使用率 |
○ | ○ | ||
メモリ予約率 |
○ | |||
ストレージ |
||||
エフェメラルストレージ予約量、使用量 |
○ | ○ | ○ | ○ |
エフェメラルストレージ使用率 |
○ | |||
EBSファイル容量、使用量 |
○ | |||
ネットワーク |
||||
ネットワーク送信量、受信量 |
○ | ○ | ○ | ○ |
読み取り量、書き込み量 |
||||
ストレージ読み取り量、書き込み量 |
○ | ○ | ○ | ○ |
タスク |
||||
タスク CPU使用率 |
○ | ○ | ○ | |
タスク エフェメラルストレージ使用率 |
○ | ○ | ○ | |
タスク メモリ使用率 |
○ | ○ | ○ | ○ |
コンテナ |
||||
コンテナ CPU使用率 |
○ | ○ | ○ | |
コンテナ CPUユニット予約数、使用数 |
○ | ○ | ||
コンテナ メモリ使用率 |
○ | ○ | ||
コンテナ メモリ予約量、使用量 |
○ | ○ | ||
コンテナ ネットワーク送信量、受信量 |
○ | ○ | ○ | ○ |
コンテナ 読み取り量、書き込み量 |
○ | ○ | ○ | ○ |
統合ダッシュボードを使った分析
蓄積されたデータを使って分析するために、統合ダッシュボードを使ってダッシュボードを構成します。
実行数の確認
ECSで消費されるリソースは、当然ながら、実行されている処理の数、処理の種類によって変化します。
このため、実行されているタスクの種類やその数を可視化することが重要になります。
左はクラスター配下の数値を示しています。
右はサービス配下のタスク実行状況を示しています。
タスク数
予約数（量）と使用数（量）、使用率
統計情報を蓄積することにより、過去実績に基づいて、予約数を決定できるようになります。
以下は、CPU、メモリの予約数（量）の最大値に対して、実績としてCPU、メモリの使用数（量）の最大値を示しています。
このようなグラフを長期間データに対して作成することにより、予約数（量）を下げても問題がないかどうかを判断できるようになります。
CPUユニット、メモリの予約数（量）と予約数（量）
導入要件
ES/1 SheltyでECS情報を取得分析するための前提条件は次の通りです。
-
ES/1 Shelty ManagerがV2.9.0以上であること
-
Amazon ECS CloudWatch メトリクス、Container Insightsの参照権限のあるIAMユーザーの準備
-
統合ダッシュボードでのダッシュレット追加をすること
以上、AWS ECSのパフォーマンス情報に対応する機能についてご紹介させていただきました。
この機会にぜひ、新機能をあわせてご利用されることをご検討いただければ幸いです。
ご不明な点等ございましたら、担当SEへご連絡いただければと思います。
執筆者
A.E.
営業技術本部 技術統括部 顧客サポート部
