「AWS Black Belt Tech Webinar 2015 〜スポットインスタンス & Auto Scaling〜」レポート

平田です。

今回は、12月16日(水)に開催された、AWS Black Belt Tech Webinarのレポートです。テーマは「スポットインスタンス & Auto Scaling」です。講師は、アマゾン ウェブ サービスの塚田さんでした。

AWS Black Belt Tech Webinarは、オンラインで受講できる無償のセミナーです。今後の予定は、国内のクラウドセミナー・イベントのスケジュール | アマゾン ウェブ サービス（AWS 日本語）のオンラインセミナーの項で確認できます。

また、今回のWebinarで使われた資料は、slideshare に公開されています。合わせてご覧下さい。

はじめに

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

Spot Instance 自体は歴史の古いサービスだが、実は機能の更新が頻繁に行われている。

この1年間だけでも上図のように様々な機能が追加されている。

今回のWebinarでは2015年3月のBlackbelt Webinarから、新たに追加された機能を中心に紹介する。

スポットインスタンスの復習

EC2のインスタンス購入オプションは4つ。

• オンデマンド
• リザーブド
• スポット
• Dedicated Hosts

スポットインスタンスを選択することで、使われていないインスタンスを大幅値引きで利用できる。

Auto Scalingの復習

Auto Scalingは、事前に起動設定を行っておくことでスケジュールや負荷に合わせてインスタンスを自動的に増減させることができるサービス。

増減させるインスタンスとしてスポットインスタンスを選択することができる。

AutoScalingとスポットインスタンス

Auto Scalingとスポットインスタンスによって、以下のメリットが実現できます。

• 大幅なコストカット
• サーバリソースの節約
• 急な負荷増大への対応
• 巨大な計算リソースの確保
• etc...

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

• AWS上の余ったEC2インスタンスを有効活用するための仕組み
• 最近は入札アドバイザ、Spot Fleetなど支援ツールが充実
• 当初は分散処理、Workerとしての利用を想定
  • 近年は別の形での利用も
• EMRやAuto Scalingとの相性が良い

スポットインスタンスの仕組み

スポットプール

AWS上では、各AZ、OS、インスタンスタイプごとに一定数のEC2用のインスタンスが用意されている。
このリソースの中から、利用者の要求に応じてEC2インスタンスが作られ、利用される。
このとき、まだユーザに利用されていないインスタンスをスポットプールと呼ぶ。

スポットインスタンスは、このスポットプールの中から作成される。

スポット価格

スポットインスタンスの値段(スポット価格)は、その時点でのスポットプールごとの需要と供給によって変動する。
同一のインスタンスタイプでも、AZによって値段が異なる。

入札価格

スポットインスタンスを購入する際は事前に「ここまでなら支払っても良い」という入札価格を提示する。
実際のスポットインスタンスの利用料は、入札価格ではなくスポット価格が基準となる。

落札

入札価格がスポット価格を上回り、スポットプールに空きがあれば落札が完了し、希望したスポットインスタンスを利用できるようになる。

インスタンスの中断

スポット価格が変動し、入札価格を上回った場合には、インスタンスが中断される。
中断される2分前から通知を受け取ることが可能

入札戦略

• コスト最小型
  • スポット価格そのままの価格で入札。いつ中断してもいいのでとにかく安く。
• 価格履歴順応型
  • 過去の価格変動から入札価格を決定する。
• オンデマンドキャップ型
  • スポット価格がオンデマンドの価格を越えれば、オンデマンドに切り替え
    • 切り替え時にターミネートが発生する
• 割り込みリスク最小型
  • オンデマンドの価格以上を入札価格に設定
  • とにかくターミネートしたくないという場合の戦略

これらの戦略は、Spot Freet(新機能)を使うことで基本的にカバーできるようになった。

スポット入札アドバイザー

リージョン、OS、入札価格を選ぶと、スポットプールの過去データと照合して、価格高騰の可能性などを提示してくれる。
スポットインスタンス利用時にはチェックすることをおすすめ。

スポットインスタンス利用時に考慮する点

1. ターミネート時の後処理
2. 突然のターミネートが許されるワークフローか
3. ターミネートの頻度、リスクをいかに減らすか
4. 最悪、必要なインスタンスが確保できなかった場合にどうするか

Spot Fleet

• スポットインスタンスを効率良く利用するための支援&スポット管理ツール
• 全体で利用するインスタンス数などの情報を設定すれば、自動的に確保してくれる
• 入札戦略にも対応

複数のスポットプールを使い、目的のリソースを効率良く、安定して確保するための支援ツール

Spot Block

• 落札時点から、一定時間(1~6時間)の利用が保証されるオプション
• 価格体系はスポット価格とは別系統 (スポット価格 < ブロック価格 < オンデマンド価格)
• 落札時点のブロック価格がそのまま維持される
• 途中で利用を中断しても課金は発生しない

ターミネートを避けたいワークフローの場合に適したオプションであり、また短期間で割安にインスタンスを利用するためのオプションでもある。

オンデマント予備軍

スポットインスタンスが高騰し、確保できなかった場合でもオンデマンドでなんとかするという戦略。

• スポットとオンデマンドで2つのAuto Scaling Groupをつくる
  • スポットのほうがスケールアウトしやすく、スケールインしにくく設定しておく
• スポット価格が圏内であれば、スポットインスタンスが優先してスケールアウトする
• スポット価格が高騰した場合、スポットインスタンンスにターミネートが発生する
• ターミネートされたインスタンスは、オンデマンドインスタンスをスケールアウトすることでカバーする

Auto Scalingについて

インスタンス増減の設定を行うことで、需要に応じて自動的にサーバの増減を行う仕組みである。

• 需要に応じたサーバの増減によるコストカット
• サービスの成長に合わせて台数設定が可能

ユースケース

ELB配下のwebサーバ

• ELBのレイテンシ、CPU使用率などをトリガにスケーリング
• AZを分散させることで可溶性を確保

SQSのジョブを処理するWorker

• SQSのキュー数(溜まったタスクの数)やCPU使用率をトリガにスケーリング
• 大量のスポットインスタンスを利用しやすいパターン

スケーリングの種類

• CloudWatchアラームによるスケーリング
  • 負荷の増大やイベントに応じて増減したい場合
• Scheduled Actionによるスケーリング
  • 指定時間に実行されるスケーリング
  • 繰り返し実行可能
  • 以外と知られていない (管理コンソール未対応)
• 手動スケーリング
  • 管理コンソールなどから操作

Auto Scalingの設定

• Auto Scaling Group
  • 全体的な情報管理単位
    • 最小/最大台数、ヘルスチェック方法、AZ/VPCなどの情報を管理する
• Launch Configuration
  • EC2 Instanceの起動に必要な情報
• Auto Scaling Policy
  • スケールイン/スケールアウトをどのようなタイミングで行うかの情報
  • ASGごとに複数設定することができる

スケールイン/スケールアウト時に考慮する点

スケールアウトの初期設定

スケールアウト時に展開するインスタンスは、以下の3通りの方法でセットアップされる。

• 設定済みAMIをつかう
• user-dataで初期化スクリプトを実行する
• life cycle hookの利用

スケールイン時の後処理

スケールインが発生した場合、必ずいずれかのインスタンスは停止する。
どのタイミングで停止が行われても、問題無いようにしておく必要がある。

• セッション情報はDynamoDBやElastiCacheに出しておく
• ログファイルをS3にアップロードするなどの対策をとっておく
• WebSocketのようなコネクション維持系のプロトコルの場合は、設計に工夫が必要

ライフサイクルとターミネーション

life cycle hooks

• 起動/終了時に一時的に待機させ、SNS/SQSに通知する
• デフォルト60分 + 最大48時間まで待機
• この間にカスタムアクション(初期化/終了処理)を行う

ターミネーションポリシー

どのインスタンスを優先してとめるかのポリシー

• OldestLaunchConfiguration
  • Launch Configurationで起動した最も古いインスタンス
• OldestInstance/NewestInstance
  • 最も古い/新しい起動時刻のインスタンス
• ClosestToNextInstanceHour
  • 次の課金が始まるタイミングが最も近いインスタンス

インスタンス保護

スケールイン時に、任意のインスタンスをターミネートから除外することができる。
長時間のタスクを実行しているインスタンスなどに有効

TIPS

1. Auto ScalingをAUto Healingとして使う

最小構成1,最大構成1のAuto Scaling Groupを作成すれば、常に1台を保ち続ける環境になる。
障害発生時に自動的にインスタンスを復帰することができる

2. Auto Scaling Policyの調整方法

そのまま使える一般的な算出方法はない。サービスによってそれぞれ最適なポリシーがある。
調整の叩き台となるポリシーの設定方法をWebinarで紹介(あくまで個人的な経験則として)

3. スパイクアクセスに立ち向かうには

Auto Scalingは、段階的な負荷増大には良く対処できるが、突発的なスパイクには不向きである。

• 予測可能なスパイクの場合
  • ELBの暖気
  • webサーバのスケールアウト
  • DBサーバのスケールアップ
• 予測不可能なスパイクの場合
  • ランディングページをS3で管理
  • CloudFrontの利用

4. スポットプールとAuto Scalingの設定見直し

• スポットプールの需要は時間とともに変化していく
• Auto Scalingの設定もその時々の要因で変化していく
• どちらも定期的に見直しが必要

5. Spot Fleet APIのJSONパラメータを 管理コンソールで生成

Spot Fleet のAPI パラメータ(JSON)は非常に複雑。
管理コンソールからJSONを出力する方法があるので、それを雛形にJSONを加工していくとパラメータの作成が楽にできる。

6. 各種上限の確認 / 緩和申請手順

資料に上限の確認方法や、緩和申請の手順が案内されている。

7. Serverless Archtectureのコスト効率

EC2を利用しないサーバレスアーキテクチャは、Spot Instance + Auto Scalingと同様にランニングコスト効率が高く、コスト減につながることが多い。

QA

Q. スポットインスタンスをAuto Scalingで保護することは可能か
A. 可能。スポットインスタンスはlife cycle hooksによる延長はできないので注意

Q. t2系はスポットインスタンスで使えるようになりませんか？
A. お答えできません...

骨太な質問が多いでの、後ほどブログで解答を行いますとのこと

終わりに

Auto Scaling やSpot Instanceは、クラウドサービス独自の「利用量に応じた課金」という特性を最も強く実感できる機能であると個人的に思います。

流動的にコストが変化し、突然ターミネートするリソースの中から、最適な形で自動的にシステムを維持していく仕組みに、何か生物に近いものを感じながらWebinarを聞いていました。

とても面白い内容でしたので、次の機会があれば是非聴講してみてください。