SPECIALIST

多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。

BACK

EC2 AutoScaling WarmPool速度検証

こんにちは、NRIデジタルの島です。

EC2のAutoScalingに「Warm Pool」機能が追加されました。
通常のAutoScalingと比べ、どの程度スケーリングの速度にメリットがあるのか確認してみました。

Amazon EC2 AutoScaling

「Amazon EC2 AutoScaling(以下AutoScaling)」は、アプリケーション等のワークロードを稼働させているEC2の負荷状況や設定したスケジュールに基づいて、EC2インスタンスを適切な数に調整してくれる機能です。
What is Amazon EC2 Auto Scaling? – Amazon EC2 Auto Scaling

利用するには「AutoScalingグループ」と呼ばれるEC2インスタンスのグループを作成し、「スケーリングポリシー」を指定します。
「スケーリングポリシー」とは、EC2インスタンスの最小・最大数やスケーリング発動の条件(CPU使用率等)のことです。

・最小1、最大5で設定した場合のイメージ

スケーリング条件をCPU使用率「40%」と定義し、稼働中のEC2インスタンスが「60%」のCPU使用率になった場合は、下図の通りインスタンスのCPU使用率が「40%」以内になるよう自動的にEC2インスタンスを増やしてくれます。

非常に便利な機能ですが、スケーリングする際は指定したAMIからEC2インスタンスを作成し起動する為、実際にワークロードを実行できるようになるまでに時間を要するという課題があります。

この速度的な課題を解決するのが「Warm Pool」で、事前に起動済み、初期化済みのEC2インスタンスを設定数分Poolに保持しておき、迅速にスケーリングを完了することができます。
Warm pools for Amazon EC2 Auto Scaling – Amazon EC2 Auto Scaling

では、通常のスケーリングと実際にどのくらい差があるか確認してみたいと思います。

スケールアウト速度検証

下記のスケーリングポリシーで、稼働中のインスタンスに対し、手動でCPU負荷をかけることで検証しました。(yes > /dev/null)

インスタンス最小数 1インスタンス
インスタンス最大数 5インスタンス
スケール条件 CPU使用率 > 40%
※ターゲット追跡スケーリング
WarmPool内に保持するインスタンス数
※WarmPool検証時のみ
2インスタンス
稼働中のインスタンス数 1インスタンス

 

まず、通常(WarmPoolを使用しない)のスケーリング時間の結果です。

30~40秒程度の時間がかかります。

次にWarmPoolを利用した場合です。
WarmPoolにプールしておくインスタンスについては下記の2つの状態を選択できます。
 
・Running(起動状態)
・Stopped(停止状態)

また、プールしておくインスタンスの数も定義します。
※今回はプール内のインスタンス数を「2」にして実施します

WarmPool内の状況はAWS管理コンソールの画面上で確認できます。
下記は2インスタンス中1インスタンス登録済み、1インスタンス登録中という状況です。

 

最初にRunning(起動状態)でのスケーリング時間の結果です。

7秒程度でスケーリングが完了しました。

上記結果の処理の流れは下記の通りです。

① スケーリングがトリガーされ(1→2)WarmPoolからEC2インスタンスを取得
② ①で1インスタンス減った為、WarmPoolへ追加(1→2)
③ スケーリングがトリガーされ(2→3)WarmPoolからEC2インスタンスを取得
④ ③で1インスタンス減った為、WarmPoolへ追加(1→2)

Running(起動状態)のインスタンスを取得している為、スケーリング時間もかなり短く実行できました。

ただ、Pool内とはいえ起動中の為、そのインスタンス数分(今回は2インスタンス分)のコストがかかりますので注意してください。
1台目のスケーリングを早くするだけでも十分メリットがあるので、プールには1インスタンスのみ保持するのがコストとのバランスを考慮した良い選択肢かもしれません。

次にStopped(停止状態)で実施してみます。

 

スケーリング時間の結果です。

30~40秒と通常のスケールと差は出ませんでした。
AMIからの復元時間やディスクの初期化(1stタッチペナルティやディスク同期等)等で速度差が出るかと思ってましたが、特に大きな差はなさそうです。

上記結果より、インスタンス起動後即リクエストを受信可能な構成の場合は速度的なメリットはなさそうです。
ユーザガイドの下記にもある通り、このような場合は逆にコストがかかってしまうので、Stopped状態のWarmPool利用は不要です。


重要

不要な場合にウォームプールを作成すると、不要なコストが発生する可能性があります。
初めて起動してもアプリケーションに重要なレイテンシー問題が発生しない場合は、ウォームプールを使用する必要がないと考えられます。

ただ、インスタンス起動後に下記のような初期化処理が必要な構成の場合には、WarmPoolにより事前に初期化して保持しておくことにより、スケールアウト後にアプリケーションが処理可能な状態となるまでの時間を短縮することが可能になるので大きなメリットになると考えられます。

・OS 最新化 (パッチ適用/パッケージ更新 等)
・OS 環境設定 (時刻同期 等)
・ミドルウェアのインストール/設定
・アプリケーションの環境設定
・アプリケーションのビルド/デプロイ (またはその最新化)
・アプリケーションの動作に必要なデータの準備

例えばStopped状態のWarmPool利用が有効なケースとしては、AutoScalingのインスタンスの初回起動時に下記のような時間のかかる処理を行っている場合です。

・外部Gitリポジトリとの同期
・アプリケーションのビルド・デプロイ
・S3からの画像ファイル一括ダウンロード

このような場合は一度起動してから停止状態でWarmPoolに待機することで、初回起動時の処理を省略してスケールアウトすることが可能となります。
(起動ライフサイクルフック等に登録するスクリプトで2回目以降の処理をスキップするといった工夫は必要です。)

なお、WarmPoolを利用した場合もスケールインの際は通常のAutoScalingと同様、対象のインスタンスは削除されます(再利用はしない)。
→ 新たなインスタンスを生成し、プール内に設定数分保持するように動作します。

 

利用シーンの考察

ところで、前述した通りWarmPool (runnning) に入っているインスタンスは課金対象です。どうせ課金対象なのであれば使いたい! というのが心情ではないでしょうか。AutoScaling の最小数を引き上げた方がよい、という考え方ですね。しかし、それでも Warm pool を使った方が良い、というケースについて、いくつか想定してみました。

どんどんスケールアウトしていきたい
AutoScalingの最小数を引き上げると、当然ながら今までより大量のアクセスをデフォルトで捌くことができます。一方で、それでも足りなくなったというケースでは、追加でスケールする必要があります。この際、立ち上がりは当然ながら遅いです。
ではそういうことにならないように事前にCPU利用率をチェックして最小数を引き上げて……となると、これはそもそもAutoScalingを使っている意味がありません。そういったチューニングをお任せしたいから使用しているわけですので。
なので、どんどんスケールアウトをしていったり、逆にスケールダウンしたり、ということをスピーディに行いたいのであれば、やはり事前に最小数を上げるより、Warm pool を利用する方が得策と言えます。

ホットスタンバイとして使う
スケールアウトすることはできないけれども冗長化はしたい、というケースもあります。アプリケーション制約により、並列処理ができないというケースです。この場合、最大1台しか立ち上げることはできません。ここで障害時にスタンバイ機を立ち上げて処理を切り替える、というのはそれほど簡単ではなく、作りこむ必要があります。
さらにホットスタンバイしたい、となると、そういうクラスタウェアを導入することが常でした。
Warm pool を使用することで、ホットスタンバイ機を用意して切り替わった際に短時間で処理を引き継ぐことが可能になりそうです。

ELB Pre-Warming(暖気申請)との使い分け

一方、類似の機能ではElastic Load BalancingのPre-Warming(暖気申請)があります。簡単に言うと、事前に指定した時間帯で指定した量までスケーリングしておいてもらう、というものです。クラスメソッド様のブログに詳細があるので、ご興味がある方はご参照ください。

これらは同じような機能を提供しているように見えますが、実際に行っていることは全然異なります。ELB + EC2 でAuto Scalingする際には、実際は EC2 のスケールだけではなく、 ELB のスケールもAWSの内部で行われます。ELBのスケール速度は、通常は問題になりませんが、バースト性のあるアクセスの場合は間に合わない場合があります。ELBのPre-WarmingはEC2だけでなくELBのスケールも同時に行うため、そのような問題も起きません。

一方で、 暖気申請の名の通り、事前に申請する必要性があります。つまり、バースト性のあるアクセスが来そうだ、ということを先に理解しておく必要があります。例えば、タイムセールや、証券の売買開始タイミングなど、時刻契機で大量のアクセスが発生することがあらかじめわかっている場合は Pre-Warming の方が有用でしょう。

しかし、当然ながら、バースト性は予測可能とは限りません。例えば、LINE配信したマーケティング施策がたまたまインフルエンサーに取り上げられて爆発的にアクセスが増加するかもしれません。こういった場合にはELBの拡張まで用意しておくことはできませんが、Warm pool を利用することでバースト性に追いつけなくなるリスクを下げることは可能になります。

さいごに

今回はAutoScalingの新機能「WarmPool」について、速度的な観点での結果を共有させていただきました。
もし、現状のスケーリングに対して速度的な課題を抱えている方がいらっしゃいましたら、是非採用のご検討をいただければと思います。

以上