Amazon Web Services ブログ
新機能 – AWS ECS Cluster Auto ScalingによるECSクラスターの自動スケーリング
本日、AWS ECS Cluster Auto Scalingを発表します。この機能は、スケールアウトを高速化し信頼性を向上させる、クラスター内の空きキャパシティ管理の提供と、スケールイン時に終了されるインスタンスの自動管理を提供し、クラスターの自動スケーリングをより使いやすいものにします。
ECS Cluster Auto Scalingを有効にするには、Capacity Providerと呼ばれる新たな項目を設定する必要があります。1つのCapacity Providerは1つのEC2 Auto Scaling Groupに関連づきます。あるAuto Scaling GroupにECS Capacity Providerを関連付け、ECSクラスターにCapacity Providerを追加すると、ECSの次の2つの新機能を用いてクラスターを自動スケールできるようになります。
- 管理されたスケーリング。Capacity Provider Reservationという新しいメトリックに対応するスケーリングポリシーが自動的に生成され、Auto Scaling Groupにアタッチされます。
- 管理されたインスタンス保護。スケールイン時にコンテナーからインスタンス終了を把握できるようになります。
これらの新機能により、ECSクラスターのスケールイン・スケールアウト時の制御が可能になります。
Capacity Provier Reservation
Capacity Provider Reservationと呼ばれる新しいメトリックを導入します。クラスター内のすべてのECSワークロード、つまり既存のもの、新規のもの、変更になるもの、これらすべてが必要とする、クラスターリソースの割合(パーセンテージ)が計測されます。このメトリックはCPUやメモリ使用率を用いるよりも確度の高い、素早いスケールアウトを実現するために用いられ、またクラスター内の空きキャパシティを把握することもできるようになります。また、インスタンスを新規起動せず追加のコンテナーを素早く起動できるか、といった判断も可能になります。
管理されたインスタンス保護
インスタンス保護機能により、スケールインに際してどのインスタンスを削除できるかをECSに知らせることができます。これにより稼働中のコンテナーの中断を最小限に抑えられるようになります。運用コストの最適化、またECSで稼働するコンテナーワークロードの可用性向上に役立つ機能です。
ユーザーの利点
これまで、自動スケールするコンテナーワークロードを運用していたユーザーは、多くの場合、メトリックベースのスケーリングを使っていました。メトリックの例にはCPU使用率やメモリ使用率といったものがあり、この変化に基づいてクラスターインスタンスを追加、あるいは削除するべきかを判断するスケーリングポリシーを定義していました。
単一のワークロード、もしくは穏やかに負荷が上昇するワークロード群であれば、この方式でもうまくいく場合が多かったと考えます。しかし同一クラスター上で複数種類のワークロードを稼働させるケース、また急激な負荷上昇が見込まれるワークロードに対しては、スケーリングの問題が頻発していました。理想的には、その時点のクラスターサイズで収容しきれないようなワークロードの増加に対しては、クラスターサイズをスケールアウトさせるようなスケーリングポリシーが必要です。
既存のメトリクスがコンテナー全体を対象にしたものではなく、またその時点で使用中のリソースのみを表現するものである以上、スケールアウトが緩慢に、また不安定になってしまうことは避けられませんでした。加えて、クラスター内のどこでコンテナが稼働しているのかをスケーリングポリシーが把握できないため、スケールインに際して不用意にコンテナーを終了させてしまう場合もありました。この問題はコンテナーワークロードの可用性を低下させる要因になっていました。コンテナーインスタンスの追加台数の準備、追加のスクリプト開発、あるいは手動運用などでの回避は、すべて運用コストの増大を招いていたと言えます。
スケールしてみよう！
この機能をよく理解するには手を動かしてみるのが一番だと思います。
Amazon ECS Cluster Auto Scalingは、マネジメントコンソール、AWS CLI, Amazon ECS APIのいずれからも操作可能です。この例ではAWS CLIを用い、ターミナルからクラスターを作成する流れを見ていきます。
まず2つのファイルを作成します。ひとつ目はdemo-launchconfig.jsonで、EC2 Auto Scaling Groupに起動するAmazon Elastic Compute Cloud (EC2)インスタンスの起動構成(Launch Configuration)を定義します。リージョンに応じたECS-optimized AMIを選択するのを忘れないようにしてください。
{
"LaunchConfigurationName": "demo-launchconfig",
"ImageId": "ami-01f07b3fa86406c96",
"SecurityGroups": [
"sg-0fa5be8c3749f3aa0"
],
"InstanceType": "t2.micro",
"BlockDeviceMappings": [
{
"DeviceName": "/dev/xvdcz",
"Ebs": {
"VolumeSize": 22,
"VolumeType": "gp2",
"DeleteOnTermination": true,
"Encrypted": true
}
}
],
"InstanceMonitoring": {
"Enabled": false
},
"IamInstanceProfile": "arn:aws:iam::111122223333:role/ecsInstanceRole",
"AssociatePublicIpAddress": true
}
2番目のファイルはdemo-userdata.txtです。EC2インスタンスのユーザーデータを記述し、起動したEC2インスタンスがECSクラスタの一部であることをコンテナーエージェントに伝えるようにします。ECS_CLUSTERに格納する値はECSクラスタ名と一致しなければなりません。ここではdemo-news-blog-scaleとしました。
#!/bin/bash
echo ECS_CLUSTER=demo-news-blog-scale >> /etc/ecs/ecs.config次に、EC2 Auto Scalingのcreate-launch-configurationコマンドにより、EC2 Auto Scalingの起動構成(Launch Configuration)を作成します。
aws autoscaling create-launch-configuration --cli-input-json file://demo-launchconfig.json --user-data file://demo-userdata.txt次に、Auto Scaling Groupのための構成ファイル、demo-asgconfig.jsonを作成します。
{
"LaunchConfigurationName": "demo-launchconfig",
"MinSize": 0,
"MaxSize": 100,
"DesiredCapacity": 0,
"DefaultCooldown": 300,
"AvailabilityZones": [
"ap-southeast-1c" ],
"HealthCheckType": "EC2",
"HealthCheckGracePeriod": 300,
"VPCZoneIdentifier": "subnet-abcd1234",
"TerminationPolicies": [
"DEFAULT"
],
"NewInstancesProtectedFromScaleIn": true,
"ServiceLinkedRoleARN": "arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
} 次にこのjsonファイルを用いて、EC2 Auto Scalingのcreate-auto-scaling-groupコマンドにより、demo-asgという名前のAuto Scaling Groupを作成します。
aws autoscaling create-auto-scaling-group --auto-scaling-group-name demo-asg --cli-input-json file://demo-asgconfig.jsonさて、ここまでの作業でCapacity Providerを作成する準備が整いました。次のファイルdemo-capacityprovider.jsonではmanagedTerminationProtection属性にENABLEDをセットする点に着目してください。
{
"name": "demo-capacityprovider", "autoScalingGroupProvider": {
"autoScalingGroupArn": "arn:aws:autoscaling:ap-southeast-1:111122223333:autoScalingGroup:e9c2f0c4-9a4c-428e-b81e-b22411a52954:autoScalingGroupName/demo-asg",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 100
},
"managedTerminationProtection": "ENABLED"
}
}Capacity Providerの作成にはECSの新しいコマンド、create-capacity-providerを呼び出します。
aws ecs create-capacity-provider --cli-input-json file://demo-capacityprovider.jsonここまでの作業でようやくクラスターの作成準備が整いました。新規作成するクラスターのデフォルトCapacity Providerに、先ほど作成したdemo-capacityproviderを指定します。
aws ecs create-cluster --cluster-name demo-news-blog-scale --capacity-providers demo-capacityprovider --default-capacity-provider-strategy capacityProvider=demo-capacityprovider,weight=1クラスターのステータスがACTIVEになるまで待ちます。次のコマンドで状況が確認できます。
aws ecs describe-clusters --clusters demo-news-blog-scale --include ATTACHMENTSクラスターの準備が終わったところで、タスク定義を作成し、タスクが稼働できるようにしましょう。次のdemo-sleep-taskdef.jsonというファイルでは、無限にsleepするタスクを定義しています。
{
"family": "demo-sleep-taskdef",
"containerDefinitions": [
{
"name": "sleep",
"image": "amazonlinux:2",
"memory": 20,
"essential": true,
"command": [
"sh",
"-c",
"sleep infinity"]
}],
"requiresCompatibilities": [
"EC2"]
} このjsonファイルをregister-task-definitionコマンドに渡してタスク定義を作成します。
aws ecs register-task-definition --cli-input-json file://demo-sleep-taskdef.jsonそして最後に、5つのタスクを起動します。
aws ecs run-task --cluster demo-news-blog-scale --count 5 --task-definition demo-sleep-taskdef:1この時点ではタスクが起動できるコンテナーインスタンスが一台も存在しないため、タスクのステータスはPROVISIONINGとなり、キャパシティが準備されるのを待ちます。Capacity Provider Reservationを通じてCapacity ProviderがAuto Scaling Groupをスケールアウトし、起動されたインスタンスがECSクラスターに参加したタイミングで、タスクがコンテナーインスタンスに配置されるようになります。これはまさに「ゼロからのスケール」であり、これまで実現できなかった動作でした。
終わりに
AWS ECS Cluster Auto Scalingは、Amazon ECSとAWS Auto Scalingの両方が利用可能なすべてのリージョンでお使いいただくことができます。こちらのリージョン表を参考にしてください。AWS Auto ScalingとEC2 Auto Scalingの位置付けはこちらのBlackbeltセミナーの資料を参照してください。
よいスケーリングライフを！
— Martin
この記事はソリューションアーキテクト滝口が翻訳しました。原文はこちら。