Pocket

今回初ECS/FargateでAuto Scalingの設定を試してみました。FargateとEC2のAuto Scaling設定違いといえば、インスタンスの縛りがないことで、ECS Cluster内でtaskを自在に配置と管理ができます。なのでデプロイ周りの実装などは考えずに設定が楽になります。また、Auto Scalingの設定はサービスから設定できますが、実際には別リソースということもあり、テストとしてTerraformCloudWatch Alermと連携してCPUメトリクスでスケールイン/アウトを実装してみました。

※ちなみにEC2のオートスケールはデプロイ含めて手間がかかる。。

[AWS]EC2オートスケール時のデプロイ実装手順と運用について


オートスケールの概要と設定の流れ

https://aws.amazon.com/jp/blogs/news/automatic-scaling-with-amazon-ecs/

・来ているアプリケーションの負荷にキャパシティを対応させる: ECS ServiceとECS ClusterのAuto Scaling Groupを両方にScaling Policyを使います。必要に応じて、Cluster InstanceとService Taskをスケールアウトさせ、需要が落ち着いたら安全にスケールインさせることで、キャパシティの推測ゲームから抜け出せます。これによって、ロングランな環境で低コストな高可用性を実現できます。

・複数AZのClusterでECSの基盤に高い可用性を持たせる: Zone障害という可能性から守ることができます。Availability Zoneを考慮しているECS SchedulerはCluster上のTaskを管理し、スケールし、分散してくれるので、アーキテクチャは高い可用性を持ちます。

  • CloudWatch Alarm設定(CPU 60%でタスク増加)
  • ECS/Service AutoScaling 設定 (タスクの最大数2)
  • Auto Scaling Policy設定
  • 負荷テスト

Terraform

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_target

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudwatch_metric_alarm

  • autoscale.tf

テストとして、WordPressコンテナでCPU 60%以上負荷がかかったらコンテナ数(タスク)2台にしてCPU 30%以下コンテナ数(タスク)1台にするよう作ってみました。使用するResourceは aws_appautoscaling_targetaws_cloudwatch_metric_alarm になります。実際に動作確認してみましょう。

  • iam.tf

  • files/assume_role_policy/autoscale.json

  • files/assume_role_policy/autoacaling-ecservice.json

他にもTerraformのバグなのかわかりませんが、IAMでService Auto Scaling用のIAM ロールを指定すると、以下のエラーが出てしまった場合は独自のロールを作成して適用すればいいんですが、なぜかデフォルトの AWSServiceRoleForApplicationAutoScaling_ECSService のロールが新規できてしまい、サービスから独自のロールに更新してもデフォのロールに戻ってしまうので、一旦独自ロールを作成して適用してから AWSServiceRoleForApplicationAutoScaling_ECSService に戻すようにしました。これはハマった…

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/service-auto-scaling.html#auto-scaling-IAM

補足としてはECS サービスの自動スケーリングを有効にすると、サービスにリンクされたロールが AWSServiceRoleForApplicationAutoScaling_ECSService という名前で作成されます。なので手動で作る場合はIAMロールを独自で作成する必要はないので、Terraformだと上記のように対応しないとダメそうですね。ここらへん分かる方連絡おねしゃす。

※追記

https://docs.aws.amazon.com/ja_jp/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/appautoscaling_target#role_arn

サービスリンクロールを手動で作成する必要はありません。Application Auto Scaling は、ユーザーが RegisterScalableTarget を呼び出す時に、適切なサービスリンクロールを作成します。例えば、Amazon ECS サービスのオートスケーリングをセットアップする場合は、Application Auto Scaling が AWSServiceRoleForApplicationAutoScaling_ECSService ロールを作成します。

そもそもオートスケール用のIAM Roleは自動作成されるので、指定しなくてもいいことが分かった…なので以下先頭に追加するだけで問題ないです。


負荷テスト

Totalリクエスト数100000000、同時アクセス数10000てabテストします。これは相当な負荷だ…AWSに上限申請しないと。

  • CPU 60%超える

  • タスクが2台になる

  • CPU 30%になる

  • タスクが1台になる


まとめ

特にハマることなくTerraformでサクッと実装することができました。簡単にオートスケーリングの設定が可能なので、Fargateの良さをさらに発見することができました。本番はもろもろ調整する必要があるので設定せねば!ちなみに60%だとECSの立ち上がりが遅いので20%の方がベストですね。

Pocket


adachin

1989年生まれのSRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWS/Azureでのインフラ構築、Docker開発環境の提供、Kubernetes保守、インフラコード化、新技術の検証、リファクタリング、セキュリティ強化などを担当している。個人事業主では数社サーバー保守とベンチャー企業のSREインフラコンサルティングやMENTAで未経験者にインフラのコーチング/コミュニティの運用を実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください