EC2 Auto Scaling Groups と 起動テンプレートを駆使した EC2 インスタンスのコスト戦略

はじめに

SRE 推進部インフラストラクチャーグループの間山です．

弊社では大量の EC2 インスタンスを起動しており， コスト削減できないかという課題から一部のシステムにスポットインスタンスを導入しました． しかし，導入したシステムのスポットインスタンスが AWS 側により全台 Terminate されシステムに遅延が生じました． スポットインスタンスのみの Auto Scaling Groups を使用していたため， EC2 インスタンスが Terminate された数分後には新しい EC2 インスタンスが起動されましたが， 再度全台 Terminate される状況でした． そこで，Terminate されないオンデマンドインスタンスとスポットインスタンスを組み合わせることができる EC2 Auto Scaling Gourps という機能を使用したことにより可用性の担保を実施いたしました．

EC2 インスタンスの購入方法

EC2 の購入方法は以下の 4 つの購入方法が存在します． 購入方法は異なりますが作成されたインスタンスの性能は同じですので適切な選択をしましょう．

  • オンデマンドインスタンス

    • EC2 インスタンスの定価の購入方法
    • 使用した時間のみ課金されていく

  • スポットインスタンス

    • オンデマンドインスタンスの単位時間あたりの価格より割引される
    • AZ (アベイラビリティゾーン)にて EC2 のキャパシティがない場合は Terminate される

  • RI (リザーブドインスタンス)

    • EC2 インスタンスを長期間使用する場合に割引が実施される
    • 購入したインスタンスタイプを起動した際にオンデマンドではなく RI として適用される
  • Savings Plans
    • 1 年もしくは 3 年の期間において，コミットメント値を指定する
    • コミットメント値は，1 時間あたりに使用する料金である
    • コミットした値に対して割引が発生する

スポットインスタンスについて

概要

同一のインスタンスタイプ内にて起動できるインスタンス数の枠（スポットインスタンスプール）が空いている場合， AWS 側は オンデマンドインスタンスより割引をされたインスタンスを提供をします． スポットインスタンスの価格は，スポットインスタンスプールの空き状況によって変動します． 空きが無い場合にはスポットインスタンスの価格が上昇し，逆に空きが多い場合には価格が下降いたします． スポットインスタンスを起動する場合には予め上限価格を設定しておき， それよりも現在の価格が上回った場合にはインスタンスが Terminate されてしまいます． なお，上限価格のデフォルト設定はオンデマンド価格になっております． 以下のコンソール画面より，スポットインスタンスの価格の変動について調べることも可能です．

EC2 ダッシュボード内の，インスタンス -> スポットリクエスト -> 価格設定履歴より確認できます．

デメリット

スポットインスタンスは，オンデマンドよりも価格が低くよりコスト削減に向いております． しかし，以下の条件に達するとインスタンスは中断の後，Terminate されます．

  • スポットインスタンスの料金が設定した上限価格より上回る
  • スポットインスタンスプールの空き容量が無くなった

中断通知を受け取った後は，2分間与えられるため，その間にインスタンス内の Draining 処理が必要になります． ここでは詳しく説明は致しませんが，スポットフリートを使用することで中断テストが可能なので事前に試すことも可能です． よって，スポットインスタンスを使用する際には，データを特定のインスタンスに持たせないアプリケーション設計が必須です．

EC2 Auto Scaling Gourps と起動設定，起動テンプレートについて

スポットインスタンス単体での起動も可能ですが，Terminate されてしまいインスタンスが存在しない状態になります． また，システムの柔軟性に欠けてしまいスケーリング，オートヒーリングをしたい場合には向いておりません． そこで，EC2 Auto Scaling Gourps という機能を使用することで， 起動したいインスタンスタイプの組み合わせや常に起動したいインスタンスの台数， スケーリングする条件を設定できます．

EC2 Auto Scaling Gourps では，AMI，キーペアなどの インスタンスの起動に関する設定が必要となり以下の機能を使用しなければなりません．

  • 起動設定(Launch Configuration)
  • 起動テンプレート(Launch Template)

我々が最初に使用したのは起動設定であったため， オンデマンドインスタンスとスポットインスタンスの組み合わせを使用することが出来ませんでした． 一方，起動テンプレートは多くの設定項目が存在し，なおかつテンプレートのバージョン管理も できるので間違ってデプロイした際にはロールバックもできます． よって EC2 Auto Scaling Gourps との組み合わせには， 起動テンプレートを使用することで柔軟に変更しやすいと考えられます．

検証実験

起動テンプレート と EC2 Auto Scaling Groups には多くの組み合わせ設定があるため， 各パラメータの変更することで，起動される EC2 インスタンスについて検証を実施します． 今回は特にスポットインスタンスとオンデマンドインスタンスの起動配分について焦点を当てていきます．

設定内容

環境

  • インスタンスタイプ: m5.large
  • インスタンス数: 20 台

起動テンプレート

EC2 ダッシュボード内の，インスタンス -> 起動テンプレート -> 起動テンプレートの作成 へ移動します． 基本的な起動テンプレートの設定については起動設定(Launch Configuration)と同じになりますが， インスタンスタイプを EC2 Auto Scaling Groups にて変更できるようにするため， 起動テンプレートには含めないを選択いたします．

下へスクロールすると，高度な詳細を設定できるようになり以下の部分を編集しました．

  • 購入のオプション: チェックボックスにマークしない
  • IAM インスタンスプロフィール: セッションマネージャーを使用するために適切なプロフィールを選択

EC2 Auto Scaling Groups

EC2 ダッシュボード内の，Auto Scaling -> Auto Scaling グループ へ移動します． Auto Scaling グループの作成画面では，起動テンプレートにチェックを入れ， 先程作成した起動テンプレート名を選択します．

フリートの構築にて，購入オプションとインスタンスを組み合わせる に チェックを入れることで詳細な設定が可能になります． インスタンスタイプは２つのインスタンスタイプが推奨されておりますが， 検証目的のために，m5.large のみを使用しております． 商用で使用する際は他のスポットインスタンスプールへのリクエストが 通りやすくするために，複数のインスタンスタイプを指定するのが良いでしょう．

インスタタイプの分散 のチェックを外すことでインスタンスの配置方法を詳細に設定できます． 今回は以下のパラメータを操作した場合に，オンデマンドとスポットの配分を検証します．

  • オプションのオンデマンドベース
  • ベースを超えるオンデマンド割合

Auto Scaling Groups の設定後も，操作 -> 編集 より インスタンス数やスポットとオンデマンドの配分を変更できます．

結果

20 台のインスタンスを起動した場合のスポットとオンデマンドの配分結果は以下の表になります． 結果については，オンデマンドインスタンスの起動台数 : スポットインスタンスの起動台数 です．

オプションのオンデマンドベースのインスタンスが起動したのち， 残りのインスタンスについては割合で計算されるようです．

コスト戦略

上の表から，1 ヶ月間(30 日間)起動していた場合の価格を計算します． m5.large のオンデマンド価格は，$0.124/時間とします． スポットインスタンスの価格は，スポットインスタンスの概要に貼り付けた以下の価格とします． 時間ごとの価格の変化については考慮しておりません．

  • ap-northeast-1a: $0.0350/時間
  • ap-northeast-1c: $0.0350/時間

なお，検証ではインスタンスは，アベイラビリティゾーンに均等に配置されておりましたので， 各 AZ のスポットインスタンスの価格も均等にいたします．

以下の表は各インスタンスの配分のコストを計算した結果になります． 1 ヶ月の料金が$1000 以下にしたい場合には，20%:80%の割合が良さそうです．

まとめ

スポットインスタンス導入時の失敗から，いかに可用性を高めコスト削減できるかという課題を解決するために， 起動テンプレートと Auto Scaling Groups 利用し， スポットインスタンス，オンデマンドインスタンスを起動しました． 今回は EC2 インスタンスのみに焦点を置きましたが，ECS のインスタンスや EKS のクラスタにも応用が可能です．

インスタンス性能は変化せず，コストが削減できるのはとても有意義であり， 他のサービスリソースへ投資する余裕が出てきます． ぜひとも積極的にスポットインスタンスと Auto Scaling Groups を活用していきましょう．

最後に mediba では，より良い環境を作っていきたいエンジニアを随時募集中です．

採用ページはこちら