AWS ECS Cluster Auto ScalingがGAになったのでやってみた #reinvent

2019.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、森です。

本日、AWS ECS Cluster Auto Scalingが一般公開となったので試してみます。

AWS ECS Cluster Auto Scaling is Now Generally Available

内容

キャパシティプロバイダー という新しいECSリソースタイプを作成する必要があり、ASGに関連付け、キャパシティプロバイダーをECSクラスターに追加すると、クラスターはECSの2つの新しい機能を使用してASGを自動的にスケーリングできるようになりました。

2つの新しい機能というのは、

  • Managed scaling(スケーリングを管理)
    • ASGで自動的に作成されたスケーリングポリシー、およびスケーリングポリシーが使用する新しいスケーリングメトリック(Capacity Provider Reservation)でスケーリングを管理
  • Managed instance termination protection(マネージドインスタンス終了保護)
    • スケールインが発生したときに、ASG内のインスタンスをコンテナ対応で終了できるように

スケールインとスケールアウトのタイミングと方法をより詳細に制御できるようになったとのことでした。

Capacity Provider Reservation(キャパシティ・プロバイダー予約)

ECSワークロードに必要なクラスターリソースの合計割合を測定するメトリックで、CPUまたはメモリ予約メトリックを使用する場合よりも迅速かつ確実にスケールアウトできるようになるものです。我々はクラスターの予備容量を予約することもできます。予備の容量を予約すると、新しいインスタンスの起動を待たずに、必要に応じてより多くのコンテナをすぐに実行できるようになる

Managed instance termination protection(マネージドインスタンス終了保護)

インスタンス終了保護を使用すると、ECSは、スケーリングインスタンスがスケールイン時に終了できるインスタンスを制御し、実行中のコンテナーの中断を最小限に抑えます。これらの改善により、顧客はECSで実行されるコンテナワークロードの運用コストを削減し、可用性を高めることができます。

やってみる

AWS ECS Cluster Auto Scaling is Now Generally Available

を参考にしてやっていきます。

事前に空のECSクラスターを作成しておきます

1. 起動設定の作成

t2.micro, ecsInstanceRoleロール、ユーザーデータに

#!/bin/bash
echo ECS_CLUSTER=demo-cluster >> /etc/ecs/ecs.config

を入れて作成します。他の項目は任意で入力します。

2. Auto Scaling グループの設定

キャパシティプロバイダーを使用するため、1で作成した起動設定を元にしてAuto Scaling グループの設定を作ります

  • 希望するキャパシティ: 0
  • 最小: 0
  • 最大: 100
  • ヘルスチェックの猶予期間: 300
  • インスタンスの保護: スケールインから保護
  • 終了ポリシー: Default

3.キャパシティプロバイダーの作成

作成したクラスターの詳細画面に行くと、 Capacity Providers というタブがあるのでクリックして作成していきます。

  • Auto Scaling groupにはクラスター作成時にできたオートスケーリンググループ
  • Managed scaling にはEnable
  • Target capacity % には 100(100の場合、スケーリングの際オートスケーリンググループ内のEC2インスタンスが完全に使用されます)
  • Managed termination protection には Enabled(有効になっている場合、Amazon ECSは、タスクを含み、Auto Scalingグループに属するAmazon EC2インスタンスがスケールインアクション中に終了するのを防ぎます)

を選択します。

There was an error creating the capacity provider. Fix the following error and try again. The managed termination protection setting for the capacity provider is invalid. To enable managed termination protection for a capacity provider, the Auto Scaling group must have instance protection from scale in enabled.

作成時に上記のエラーが出た場合は、 オートスケーリンググループでスケールインからのインスタンス保護を有効にしてから再度作成します。

Update Clusterのボタンを押し、Default capacity provider strategyに作成したキャパシティプロバイダーを追加して更新します。

4.タスクを作成

タスクを作成するため、まずタスク定義を作成します。

起動タイプの互換性の選択はEC2にします。

コンテナの定義には、

  • イメージ: amazonlinux:2
  • メモリ: 20MiB
  • コマンド: ["sh","-c","sleep infinity"]
  • 基本: true

としています。

最後にタスクを作成します。

タスク定義には作成したタスクを、クラスターには作成したからのクラスターを、タスクの数は5にしました。

5.確認

キャパシティプロバイダーに設定した通り、5 個の EC2を起動してクラスターに参加するようにスケールアウトされます。 この時点で、タスクはインスタンスに配置されます。

希望する容量を0にしてオートスケーリンググループを作成していましたが、自動で変更されていくようです。

これにより、以前は存在しなかった真の「ゼロからのスケール」機能が得られます。

まとめ

ブログに

今まではCPUやメモリ予約の割合などの一般的なメトリックを使用して、ポリシーがクラスターインスタンスを追加または削除するタイミングを決定してスケーリングさせていましたが、同じクラスター内で複数のワークロードを実行している、または急速にスケールアウトするワークロードでは、クラスターのスケーリングに関する問題が発生する可能性が高くなります。理想的には、現在のクラスターで対応できないワークロードサイズの増加は、クラスターをより大きなサイズにスケールアウトするポリシーをトリガーする必要があります。

と書かれていましたが、まさにその通りで、スケールイン時にコンテナが終了してしまって信頼性、可用性が落ちてしまう可能性があります。 今回の新機能はこういう問題を抱えているお客様にとても向いているとのことです。

予備の容量を予約することによる ゼロからのスケール、ぜひ検討してはいかがでしょうか?

以上、速報気味のやってみたでした