AWS Black Belt Tech シリーズ 2015 - Amazon EC2 スポットインスタンス & Auto Scaling

Amazon EC2スポットインスタンス

Auto ScalingAmazon Web Service Japan K.K.

Solutions ArchitectAkihiro Tsukada

AWSでの担当スタートアップのお客様モバイル系ソリューション

AWS Mobile HubAmazon Cognito

サーバレスアーキテクチャ低コストアーキテクチャ

エンジニア的な属性Ruby, iOSOOP, SOLID, KISS

好きジャッキーチェン妻と娘

塚田朗弘 @akitsukada

はじめに

スポットインスタンスとAuto Scaling は“新サービス”？

「新サービス紹介月間」？

A歴史は古いが、

今なお新機能のリリースが多く、改めてご紹介したいサービス

スポットインスタンスに関するアップデート@2015

(参考情報)2015.03.25

リザーブドインスタンス&スポットインスタンスBlack Belt Webinar〜〜

2009.12 2015.12

2015.05スポットフリートAPI

リリース

2015.01ターミネート通知機能

リリース

2015.08スポット

入札アドバイザーリリース

2015.08スポットフリート拡張リソース指向入札機能

リリース

2015.10管理コンソールと

CloudFormationがスポットフリートに対応し、

実行中フリートのサイズ変更機能リリース

2015.10スポットブロック

リリース

アジェンダ

Amazon EC2

EC2 スポットインスタンス

Auto Scaling

Amazon EC2

Amazon Elastic Compute Cloud (EC2)

• 特徴 (http://aws.amazon.com/jp/ec2/)

– 必要な時に必要なだけ1時間単位の従量課金で利用できる仮想サーバリソース

– 世界11箇所のリージョンで利用可能

– 様々なスペック・OSを選択可能

• 価格体系 (http://aws.amazon.com/jp/ec2/pricing/)

– インスタンス利用料($0.02/hour 〜)

– データ転送量(OUT $0.14/GB )

仮想クラウドサーバ

Amazon EC2 購入オプション

オンデマンドインスタンススタンダードな時間課金型インスタンス

リザーブドインスタンス1年間または3年間の予約をすることで最大75%の割引

スポットインスタンス使われていないEC2インスタンスに入札して格安利用

最大90%以上の大幅割引

Dedicated Hostsお客様専用の物理サーバーを確保

Auto Scaling

• 特徴 (http://aws.amazon.com/jp/autoscaling/)

– Amazon EC2インスタンス群を自動的にスケール

– 耐障害性の向上（インスタンスの異常を検知して、新しいインスタンスを起動）

– EC2インスタンスの起動料金の最適化

• 価格体系 (http://aws.amazon.com/jp/autoscaling/pricing/)

– Auto Scaling自体の利用は無料

– Auto Scalingによって起動されるEC2インスタンスの起動料金

• Spotインスタンスとしても起動可能

EC2インスタンスを負荷またはスケジュールに応じて自動増減

Desired Capacity

必要に応じて追加されるCapacity

起動設定• インスタンスタイプ• AMI• Spot入札価格など

Auto Scaling @

Request

Instances

大幅なコストカットサーバーリソース節約急な負荷増加に対応巨大な計算能力の確保

…etc13

EC2 スポットインスタンス

Amazon EC2 スポットインスタンス

余っているEC2インスタンスを低価格で有効活用していただく仕組み

最大90%以上の割引価格でEC2インスタンスを使用可能

スポット入札アドバイザー、Spot Fleet、Spot Blockなどの強力な周辺ツール/機能

分散処理、Workerが典型的なユースケース

…だったが、新しい動きも出てきている

Amazon EMR、Auto Scalingとの併用が容易

$1 $15

この資料において単に「スポットインスタンス」という場合、特に断りがなければ従来のスポットインスタンスを指します。

スポットブロック機能およびそのインスタンスを指す場合は明示的に「スポットブロック」「スポットブロックのインスタンス」と呼びます。

スポットインスタンス関連概念の整理

スポットプール

スポット価格

入札価格

落札

インスタンスの中断

ap-northeast-1a

(Tokyo Region)

m4.large

m4.xlarge

スポット関連概念の整理

c4.large

ap-northeast-1c

m4.large

m4.xlarge c4.large

ap-northeast-1a

(Tokyo Region)

m4.large

m4.xlarge

スポット関連概念の整理

c4.large

ap-northeast-1c

m4.large

m4.xlarge c4.large

使用中使用中

使用中

使用中使用中

ap-northeast-1a

(Tokyo Region)

m4.large

m4.xlarge

スポット関連概念の整理 - スポットプール

c4.large

ap-northeast-1c

m4.large

m4.xlarge c4.large

使用中使用中

使用中

使用中使用中

Availability Zone（以下AZ）、OS、インスタンスタイプごとの使われていないEC2インスタンスたち

ap-northeast-1a

(Tokyo Region)

m4.large

m4.xlarge

スポット関連概念の整理 - スポット価格

c4.large

ap-northeast-1c

m4.large

m4.xlarge c4.large

使用中使用中

使用中

使用中使用中

$0.0384 $0.0346$0.0346

$0.0530$0.0209

スポットプール毎に需要と共有のバランスで変動する、その時点でのスポットインスタンス課金額

同じインスタンスタイプでもAZで異なる価格

ap-northeast-1a

(Tokyo Region)

m4.large

m4.xlarge

スポット関連概念の整理 - 入札価格

c4.large

ap-northeast-1c

m4.large

m4.xlarge c4.large

使用中使用中

使用中

通常使用中

$0.0384 $0.0346$0.0346

$0.0530$0.0209

「最大でここまでなら支払ってもよい」という価格

実際に課金されるのはスポット価格

管理コンソールまたはRequestSpotInstances APIからリクエスト可能

$3.66「東京リージョンの

1aにあるc4.largeを

最大$0.05で使いたい！」

ap-northeast-1a

(Tokyo Region)

m4.large

m4.xlarge

スポット関連概念の整理 - 落札

c4.large

ap-northeast-1c

m4.large

m4.xlarge c4.large

使用中使用中

使用中

通常使用中

$0.0384 $0.0346$0.0346

$0.0530$0.0209

入札価格がスポット価格を上回り、スポットプールに空きがあった場合※、希望したスポットインスタンスを使いはじめることができる※詳しくは「スポットインスタンスのしくみ」を参照のことhttp://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/how-spot-instances-work.html

$3.66「東京リージョンの1aにあるc4.largeは現在$0.0346なので、$0.05入札で起動できた！」

ap-northeast-1a

(Tokyo Region)

m4.large

m4.xlarge

スポット関連概念の整理 - インスタンスの中断

c4.large

ap-northeast-1c

m4.large

m4.xlarge c4.large

使用中使用中

使用中

通常使用中

$0.0384 $0.0346$0.051

$0.0530$0.0209

スポット価格が変動し入札価格を上回ったとき、スポットインスタンスはターミネートされる。インスタンスから以下のURLをGETすると、2分前から通知を取得できる。5秒ごとのポーリングを推奨。http://169.254.169.254/latest/meta-data/spot/termination-time

$3.66「スポット価格が変動して入札価格$0.05を上回ってしまった。ターミネート前に終了処理をしよう」

スポットリクエストと課金チャート

単価

時間

スポット価格

入札額

課金額

①ワンタイムリクエスト投入(type=one-time)

③1時間単位の課金

④入札額＜スポット価格

になったのでインスタンス終了

ワンタイムスポットリクエスト(デフォルト)と課金

②入札額>スポット価格

になったのでインスタンス起動

⑤強制終了時の1時間未満の利用分は非課金

⑥ワンタイムリクエストは自動キャンセルされるのでインスタンスは起動しない 26

単価

時間

スポット価格

入札額

課金額

①永続リクエスト投入(type=persistent)

③1時間単位の課金

④入札額＜スポット価格

になったのでインスタンス終了

永続スポットリクエスト(オプション)と課金

②入札額>スポット価格

になったのでインスタンス起動

⑤強制終了時の1時間未満の利用分は非課金

⑥永続スポットリクエストはキャンセルするまで有効

なので再度インスタンス起動 27

入札戦略（旧）

スポットフリート（後述）の登場以前は、以下の様な意図と要領で入札価格を決定するノウハウがあった1. コスト最小型

ターゲットスポットプールの最低価格で入札

2. 価格履歴順応型

直近のスポット価格等をプログラムで監視して入札額を調整（≒手動スポットフリート！）

3. オンデマンドキャップ型

オンデマンド料金付近で入札し、オンデマンドより高い課金はさせない

4. 割り込みリスク最小型

オンデマンドよりも高く入札し、ターミネートのリスクを軽減する

現在はスポットフリートを使うことで基本的にこれらをカバーできるため、スポットフリートの活用がオススメ！

価格高騰しにくいスポットプールを選ぶには

スポット入札アドバイザー（2015.08〜）

リージョン、OS、入札価格(25%, 50%, 100%)を選ぶと、各スポットプールの過去データ（先週、先月）と照合して、価格高騰の可能性を表示してくれる。

vCPUやメモリ、EMRサポート有無でフィルタリングも可能。

https://aws.amazon.com/jp/ec2/spot/bid-advisor/29

スポットインスタンスここまでのまとめ

EC2購入オプションの一つで、各スポット関連サービスの基本となる考え方

管理コンソールおよびRequestSpotInstances APIで利用

機能連携されているAutoScaling、EMRからも利用可能

スポット価格が入札価格を上回るとターミネートされる

通知をチェックし、終了処理を仕込んでおく必要がある

対策としていくつかのアプローチがあり、それぞれ考慮しておくべきことがある（次ページ参照）

スポット入札アドバイザーで価格変動しにくいスポットプールを見つけることができる

スポットインスタンス利用時の考慮点

スポットインスタンス利用時に考慮しておくべきこと

1. ターミネート時の後処理

2. 突然のターミネートが許容されるワークロードか？

Webのフロントサーバなどユーザインパクトに直結する箇所や、遅延が許されないタスクでの使用はNG…だった

今なら、そういうときはスポットフリートを検討すべし

3. いかにターミネートの頻度、リスクを軽減するか

複数のスポットプールに分散し、スポット価格高騰時のリスクを軽減するスポットフリートを利用する

スポット価格の変動に関わらず、一度落札できさえすれば指定時間内は落ちないスポットブロックを利用する

4. とはいえ、それでも必要なインスタンスが確保できなかったら？

スポットフリート

スポットフリート（2015.05〜）

EC2スポットインスタンスを効率よく利用するためのユーザー支援＆スポット管理機能

管理コンソールおよびRequestSpotFleet APIから利用

複数のスポットプールにそれぞれ異なる価格を入札したり、各プールのスポット価格が変動した際の処理を自動化したりできる

必要な台数またはリソースをフリート全体で確保する

インスタンスの配置戦略として、最も低価格なスポットプールを優先して使う、極力多くのスポットプールに分散して利用するといった戦略が選択できる 34

つまりスポットフリートとは

1. 複数のスポットプールを効率的に使う• より安価なスポットプールを選択• より安全に複数のスポットプールを選択

2. 大量のコンピューティングリソースをスポットインスタンスで維持しやすくする

というスポットユーザ支援機能

《事例紹介》Webアプリケーション with スポットフリート

Elastic Load

Balancing

Stateless

Web Servers

(Spot)

Stateless

Web Servers

(Spot)

Session

State Data

Spot fleet

Availability Zone A

Availability Zone B

Stateless

Web Servers

(Spot)

Stateless

Web Servers

(Spot)

ステートレスなWebサーバ群

スポットフリートによるDiversification

複数のスポットプールを選択

似た性能/指向を持つインスタンスタイプを選択

c3.large, m3.large, m4.large, r3.large, c4.large

30日間以上で約50台のスポットインスタンスがリクエストされた

- 45台を下回ることはなかった

- 50台必要な箇所で45台に落ちることを許容したことで、85%のコストカットに

Instances Average Price Per Instance

- 50台を45台にして試算しても、やはり83%のコストカットに

スポットフリート＠Webアプリの結果

Whodunit?

スポットブロック

スポットブロック（2015.10〜）

スポットインスタンスのオプションではあるが、指定した時間中（1〜6時間）はターミネートされないという機能

スポットインスタンスをAPIでリクエストする際、blockDurationMinutesパラメータを指定するとスポットブロックとしてのリクエストになる

管理コンソールは未対応（2015年12月16日現在）

スポット価格とは別系統で変動するスポットブロック専用の価格（以下、ブロック価格）は存在する

課金額としては落札時のブロック価格が維持される

指定時間内でも、使用を中止すればその時点までの課金しか発生しない

~ 21% 1時間以内

~ 35% 2時間以内

~ 40% 3時間以内

およそ50%のインスタンスが6時間以内にターミネートされている

6時間は妥当か？

EC2 各購入オプション料金比較例2015年12月16日現在/東京リージョン/Linuxインスタンス。()内はOn-Demandからの節約比率

On Demand

Reserved Instances for 1 year Spot Instance

Spot Block

All Upfront

Partial Upfront

No Upfront 1h 6h

c4.large $0.14$0.0935

$0.095

$0.106

$0.0265

$0.077

$0.098

m4.large $0.183$0.0961

$0.098

$0.115

$0.0206

$0.101

$0.128

r3.large $0.21$0.1339

$0.1367

$0.157

$0.0202

$0.116

$0.147

オフピーク時間の定義は2015年12月16日現在の情報

Spot Block

c4.large$0.070

$0.091

m4.large$0.093

$0.118

r3.large$0.107

$0.136

リージョンオフピーク時間 (UTC)

米国東部 (バージニア北部) 土曜日 0:00〜月曜日 0:00

米国西部 (北カリフォルニア) 土曜日 12:00〜月曜日 12:00

米国西部 (オレゴン) 土曜日 12:00〜月曜日 12:00

欧州 (アイルランド) 土曜日 9:00〜月曜日 9:00

欧州 (フランクフルト) 土曜日 10:00〜月曜日 10:00

アジアパシフィック (シンガポール) 土曜日 8:00〜月曜日 8:00

アジアパシフィック (東京) 土曜日 9:00〜月曜日 9:00

アジアパシフィック (シドニー) 土曜日 10:00〜月曜日 10:00

南米 (サンパウロ) 金曜日 19:00〜日曜日 19:00

オフピーク時間はさらに5%引き（スポットブロックのみ）

https://aws.amazon.com/jp/ec2/spot/pricing/

スポットブロックと課金（時間経過パターン）

単価

時間

ブロック価格

入札額

課金額

①リクエスト投入

--block-duration-minutes 360

②落札後は課金額固定

③指定した時間が経過した

スポットブロックと課金（手動終了パターン）

単価

時間

ブロック価格

入札額

課金額

③手動でリクエストを終了した

①リクエスト投入

--block-duration-minutes 360

②落札後は課金額固定

つまりスポットブロックとは

1. 最初に落札さえできれば、ブロック価格が高騰しても課金額維持＆指定時間内は終了されない

2. 1〜6時間の短期間を前払いなしで割安利用できるリザーブドインスタンスに近いもの• 途中で終了すれば課金も停止(期間縛りなし)• 価格はオンデマンドより安くスポットより高い

というスポットインスタンスの拡張機能

Qそれでも必要なインスタンスを

確保できなかったら？そもそも落札できなかったら？

A（解答例）

オンデマンドインスタンスの予備系を用意しておく

前提

1. スポットは落ちるもの。

2. スポットが落ちた時、ある程度の遅延を許容できる設計になっていること。

構成

スポットなサーバ群とオンデマンドなサーバ群を用意

オンデマンドなサーバ群は最低台数のみ立てておく

二つのサーバ群に同じ処理をさせる(例:同じジョブを捌くWorkerなど)

スポットサーバ群が突然全てターミネートしても、オンデマンドサーバ群がスケールアウトするよう Auto Scaling Group※

(以下ASG)を設定しておく。あるいは、スポットの終了処理中にオンデマンドサーバ台数を変更するなど。

※Auto Scalingについては後ほど詳しく解説

オンデマンド予備軍の作り方(ASGで実現する場合)

Super Hard Task

Spot ASG On-Demand ASG

When CPU > 60% Then Add

2When CPU < 20% Then Rem

1. ASGの準備

同じタスクを与えつつ、Scaling PolicyのThresholdに差をつけ、

Spot ASGはOn-Demand ASGよりスケールアウトしやすくスケールインしにくい

設定にしておく

Super Hard Task

2. 普段はSpot ASGで捌く

普段はSpot ASGだけインスタンスが増減し、On-Demand ASGは常に1台だけになっていることを確認する

Super Hard Task

3. スポット価格高騰！

Spot ASGのインスタンスが終了し、On-Demand ASGの1台のみが残る

Super Hard Task

4. On-Demandがスケール

On-Demand ASGがAuto Scalingによってスケールアウトし、Spot ASGの代わりに頑張る

Auto Scaling

オンとオフ予測可能なピーク

無駄なサーバーは落としておきたい

負荷に応じて必要最小限の台数を立てておきたい

余剰キャパシティ

立ちっぱなしのEC2

予測可能なピークオンとオフ

Auto Scaling

需要に応じて自動的にサーバが増減しコストカット

スケーリングのポリシーやインスタンスは柔軟に設定可能

UnhealthyなインスタンスやAZを自動で排除して高可用性

サービスが成長してきたら最大台数を増やして対応

すっきり！

Auto Scaling @

Request

Instances

代表的なユースケース 1/2 – ELB配下のWebサーバ

EC2 EC2Auto Scaling

AZ-1 AZ-2

スケーリングトリガーの例

ELBのRequest数

Auto Scaling Group内EC2のCPU使用率など

EC2は複数AZに分散して高可用性

代表的なユースケース 2/2 – SQSのジョブを処理するWorker

EC2 EC2Auto Scaling

AZ-1 AZ-2

スケーリングトリガーの例

SQSのキューに溜まったメッセージ（ジョブ）数

Auto Scaling Group内EC2のCPU使用率など

EC2は複数AZに分散して高可用性

大量のスポットインスタンスを併用しやすいパターン

コストカットチャンス！

1. CloudWatchアラームによるスケーリング

負荷や各種イベントに応じて増減させる

CPU使用率、ELB Laytency、SQSのメッセージ数 etc…

2. Scheduled Actionによるスケーリング（管理コンソール未対応）

特定日時指定実行

「2015/12/31 22:45 JST にインスタンスを30台にする」

繰り返し実行

cronライクな定義方法

「毎週水曜日17:50にスポットインスタンスを100台にして19:10に10台に戻す」など

3. 手動スケーリング

管理コンソール/CLIから手動で操作可能

スケーリングの種類

1. Auto Scaling Group (以下ASG)

Auto Scalingの全体的な情報管理単位ASG名、最小/最大台数、ヘルスチェック方法、AZ/VPC、ターミネートポリシー、ELB、Instance Tags、Launch Configurationなど

2. Launch ConfigurationASG内でEC2インスタンスを起動する際に必要な情報

通常のEC2インスタンスを起動する際の入力情報とほぼ同じ

Launch Configuration名、AMI、インスタンスタイプ、Security Group(s)、Key Pair、IAM role、user-data、Storage、CloudWatch Detailed Monitoring、Spot priceなど

3. Auto Scaling PolicyASG内でいつどのようにスケールイン/アウトを実行するかASG一つにつき複数のポリシーを設定できる

Policy名、トリガーとするAlarm、Action内容

Auto Scalingの設定

Auto Scaling図解

Auto Scaling Group

AZ-1:VPC1:Subnet1 Scaling Policy 2 (simple policy)

Min:2, Max:6

AZ, VPC/Subnet, ELB, Tags

AZ-2:VPC2:Subnet2

Scaling Policy 1 (with steps)

Alarm: HighCPUUtilizationActions(Steps): 60 < value → add 2 Instances80 < value → add 10% of group30 > value → remove 2 Instances

warm up: 300 seconds

Alarm: HighLaytency

Action(only one): 300 < value → add 2 Instances

cool down: 300 seconds

Launch ConfigurationLaunch Configuration

Launch Configuration

AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price

Associate

Auto Scaling図解

Auto Scaling Group

Min:2, Max:6

AZ-2:VPC2:Subnet2

Alarm: HighLaytency

Associate

Alarm!!

CloudWatch

①CloudWatchから、CPU使用率60%超のAlarm!

Auto Scaling図解

Auto Scaling Group

Min:2, Max:6

AZ-2:VPC2:Subnet2

Alarm: HighLaytency

Associate

②Min-Max:2-6で現在4台なのであと2台増やせる

Auto Scaling図解

Auto Scaling Group

Min:2, Max:6

AZ-2:VPC2:Subnet2

Alarm: HighLaytency

Associate

③Launch Configurationに従いインスタンス起動

Auto Scaling図解

Auto Scaling Group

Min:2, Max:6

AZ-2:VPC2:Subnet2

Alarm: HighLaytency

Associate

④インスタンスの初期化、Health Checkを実行

Auto Scaling図解

Auto Scaling Group

Min:2, Max:6

AZ-2:VPC2:Subnet2

Alarm: HighLaytency

Associate

⑤Health Checkに問題なければELB配下に追加

Auto Scaling図解

Auto Scaling Group

Min:2, Max:6

AZ-2:VPC2:Subnet2

Alarm: HighLaytency

Associate

⑥Warm up期間はASGのメトリクスに含まれない

Auto Scaling図解

Auto Scaling Group

Min:2, Max:6

AZ-2:VPC2:Subnet2

Alarm: HighLaytency

Associate

⑦Auto ScalingのAction完了！

スケールイン/アウト時の考慮点

1. 設定済みのAMI

（ゴールデンイメージ）を用いる

スケールアウト時の初期化処理（組み合わせて使うのが現実的）

すべてインストール＆構成済みのAMI

2. user-dataで

初期化スクリプトを実行する

3. Life Cycle Hooksを利用して初期化する

#!/bin/bash

cd /home/ec2-user;

aws s3 cp s3://aws-install-sh/install

chmod +x ./install;

./install auto;

pending

1. ターミネートに備える

スケールインのActionが走ったらいずれかのインスタンスはターミネートする

2. サーバーをステートレスにしておく

セッション情報はDynamoDBやElastiCache等に外出しする

ログファイルはS3にアップロードするなどの実装をする

WebSocketのようなコネクション維持系プロトコルを使う場合は工夫が必要

スケールイン時の後処理

Auto Scalingライフサイクルとターミネート

1. Auto ScalingによるEC2起動/終了処理を待機させ、SNS/SQSに通知させる

Pending(待機)→Running→Terminating(待機)→Terminated

デフォルト60分の待機時間にカスタムアクション（初期化/終了処理）を行う

2. ライフサイクルアクション以下の操作時は、SNS/SQSへの通知に含まれていたLifecycleActionTokenをパラメータとして指定する

1. 待機時間の延長

recordLifecycleActionHeartbeatコマンドを1度叩くと60分ずつ延長でき、最大48時間まで待機させられる

2. カスタムアクションの完了

completeLifecycleActionコマンドを叩く

Auto Scaling Life Cycle Hooks

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

スケールイン時、どのインスタンスから削除するか※

① OldestLaunchConfiguration

最も古いLaunch Configurationにより起動しているインスタンス

② OldestInstance/NewestInstance

最も古い/新しい起動時刻のインスタンス

③ ClosestToNextInstanceHour

次の課金が始まるタイミングが最も近いインスタンス

④ Default

①③の順に適用し、複数インスタンスが残ればランダム

複数ポリシー指定時は指定順に適用

全ポリシー適用後も複数インスタンスが存在する場合はランダム

※ただしインスタンス保護（次ページ）されているインスタンスは除く 77

インスタンス保護（2015.12.07〜）

スケールイン時、任意のインスタンスを削除されないよう保護できる

長時間かかるタスクを実行中のインスタンス、Hadoopクラスタのマスターノードなど

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

2. Auto Scaling Policyの調整方法

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

4. スポットプールとAuto Scalingの設定は常に見なおそう

5. スポットフリートAPIのJSONパラメータを生成

6. 各種上限に注意

7. Serverless Architectureのコスト効率

Auto ScalingをAuto Healingとして使う

Tips [1/7]

Auto Healing

サーバに障害が発生したとき自動的にネットワークから切り離し、健全なサーバをサービスインさせる

方法

Auto Scaling Group の Min を任意の数に設定する

Min-Max=1-1 にすれば「常に1台起動。増えも減りもしない」

Min-Max=2-N にすれば「常に2台起動。片方に障害があっても1台は耐える」

…など

Auto ScalingをAuto Healingとして使う

Auto Scaling Policyの調整方法

Tips [2/7]

Auto Scaling Policyのパラメータチューニング

前提として、そのまま使える公式な算出法などはない

以下の考え方を元にやってみて細かく調整1. Max Instances = ピーク時の必要インスタンス数

2. Min Instances = Max * (アイドルタイムReq数 / ピーク時Req数) + α

3. Threshold

High = ピーク時の平均CPU使用率

Low = 最初低めに設定して少しずつ上げてみる（10%→5%ずつ上げて50%、など）

4. Cool down, Warm up period等

アプリやサーバ、初期化処理等の性質によるため一般化は難しい

インスタンスが起動と終了を短時間で繰り返してしまわないよう注意

無用な課金が発生してしまうかも

これらは経験則であり、絶対的な解ではありません

Auto Scaling Policyのパラメータチューニング※CPU使用率を使うとして

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

より突発的な

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

例: テレビ放送等

AutoScalingやELBは

突発的なピーク向き

ではない87

AutoScaling

こういうのが得意

スパイクアクセスの対応方法

1. ELB…Pre-Warmingビジネスサポートにご加入いただくと申請可能です

2. Webサーバ…増設（スケールアウト）

3. DBサーバ…増強（スケールアップ）

RDSAZ1 AZ2RDS

ELB Pre-Warming

RDSAZ1 AZ2RDS

ELB Pre-Warming

… … EC2スケールアウト

RDSAZ1 AZ2 RDS

… …

ELB Pre-Warming

EC2スケールアウト

RDSスケールアップ

RDSAZ1 AZ2RDS

終わったら、戻せる。クラウドのいいところ。

スパイクアクセスの予測ができない場合

1. ランディングページをS3でホスティングする

2. CloudFrontから配信する…etc

スポットプールとAuto Scalingの設定は常に見なおそう

スポットプール

スポットプールに対する需要は徐々に変わっていく

Auto Scaling

サービスのユーザー数、機能、アーキテクチャ等々、様々な要因によって、徐々に適切なポリシーやMax台数は変わっていく

スポットプールとAuto Scalingの設定は常に見なおそう

スポットフリートAPIのJSONパラメータを管理コンソールで生成

request-spot-fleet APIのパラメータaws ec2 request-spot-fleet --spot-fleet-request-config { "IamFleetRole":

"arn:aws:iam::781603563322:role/fleet-role", "TargetCapacity": "100",

"SpotPrice": "0.03", "ValidFrom": "2015-09-15T00:56:19Z", "ValidUntil": "2016-

09-14T07:00:00Z", "TerminateInstancesWithExpiration": true,

"LaunchSpecifications": [ { "ImageId": "ami-0d4cfd66", "InstanceType":

"c3.large", "WeightedCapacity": 2, "SubnetId": "subnet-d0dc51fb" }, {

"ImageId": "ami-0d4cfd66", "InstanceType": "c3.large", "WeightedCapacity": 2,

"SubnetId": "subnet-64531413" }, { "ImageId": "ami-0d4cfd66", "InstanceType":

"c3.large", "WeightedCapacity": 2, "SubnetId": "subnet-0b1b8052" }, {

"ImageId": "ami-0d4cfd66", "InstanceType": "c3.xlarge", "WeightedCapacity": 4,

"SubnetId": "subnet-d0dc51fb" }, { "ImageId": "ami-0d4cfd66", "InstanceType":

"c3.xlarge", "WeightedCapacity": 4, "SubnetId": "subnet-64531413" }, {

"ImageId": "ami-0d4cfd66", "InstanceType": "c3.xlarge", "WeightedCapacity": 4,

"SubnetId": "subnet-0b1b8052" }, { "ImageId": "ami-0d4cfd66", "InstanceType":

"c3.4xlarge", "WeightedCapacity": 16, "SubnetId": "subnet-d0dc51fb" }, {

"ImageId": "ami-0d4cfd66", "InstanceType": "c3.4xlarge", "WeightedCapacity":

16, "SubnetId": "subnet-64531413" }, { "ImageId": "ami-0d4cfd66",

"InstanceType": "c3.4xlarge", "WeightedCapacity": 16, "SubnetId": "subnet-

0b1b8052" }, { "ImageId": "ami-0d4cfd66", "InstanceType": "c3.8xlarge",

"WeightedCapacity": 32, "SubnetId": "subnet-d0dc51fb" }, { "ImageId": "ami-

0d4cfd66", "InstanceType": "c3.8xlarge", "WeightedCapacity": 32, "SubnetId":

"subnet-64531413" }, { "ImageId": "ami-0d4cfd66", "InstanceType":

"c3.8xlarge", "WeightedCapacity": 32, "SubnetId": "subnet-0b1b8052" }, {

"ImageId": "ami-0d4cfd66", "InstanceType": "c3.2xlarge", "WeightedCapacity":

8, "SubnetId": "subnet-d0dc51fb" }, { "ImageId": "ami-0d4cfd66",

"InstanceType": "c3.2xlarge", "WeightedCapacity": 8, "SubnetId": "subnet-

64531413" }, { "ImageId": "ami-0d4cfd66", "InstanceType": "c3.2xlarge",

"WeightedCapacity": 8, "SubnetId": "subnet-0b1b8052" } ] }99

スポットフリートtips - 新コンソールでJSONを生成

① ②

1. スポットインスタンス管理画面を開く2. 画面右上部分の青い吹き出しをクリック3. Try it out. をクリック

スポットフリートtips - 新コンソールでJSONを生成

画面を進めてJSON configをクリックすると選択した値がJSONで出力され、API利用時の雛形ができる 101

各種上限の確認と緩和申請方法

各種上限の確認と緩和申請方法 – EC2関連

管理コンソール > EC2 > Limits

※今日お話した関連のものはだいたいここにある 103

各種上限の確認と緩和申請方法 – 利用状況確認

管理コンソール > Trusted Advisor > Performance > Service Limits

各種上限の確認と緩和申請方法 – 利用状況確認

上限値の80%以上使用中のサービスを示してくれたりする

Serverless Architectureのコスト効率

アプリはS3から配信されるHTML/JS、またはネイティブ実装

ELB/EC2を使わずAPI GatewayとLambdaで応答

運用/構築/開発からの解放

ランニングコスト効率が高く、多くの

場合コスト減に

Lambda

Other Services

API Gateway CognitoCloudFront

サーバレスアーキテクチャ例

次回Webinarのお申し込みhttp://aws.amazon.com/jp/event_schedule/

Webinar資料の配置場所

• AWS クラウドサービス活用資料集– http://aws.amazon.com/jp/aws-jp-introduction/

公式Twitter/FacebookAWSの最新情報をお届けします

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

AWS Black Belt Tech シリーズ 2015 - Amazon EC2 スポットインスタンス & Auto Scaling

Technology

Transcript of AWS Black Belt Tech シリーズ 2015 - Amazon EC2 スポットインスタンス & Auto Scaling

Symbole EC2

Cloud Taekwon 2015 - Amazon EC2 & Auto Scaling 제대로 활용하기

scaling manual

Amimoto auto scaling

Scaling silverlight

DÉTARTRAGE SCALING

Structural Space Scaling

0808 jawsug-kobe | スポットインスタンスを使ったEC2でのスケーラブル負荷検証

Multidimensional Scaling

Amazon Ec2

Scaling Apache Presentation

Amazon EC2 Auto Scaling · 2020-03-20 · Amazon EC2 Auto Scaling 사용 설명서 Auto Scaling 구성 요소 Amazon EC2 Auto Scaling이란 무엇 입니까? Amazon EC2 Auto Scaling를

Dynamic Speed Scaling

Scaling Tableau

AWS Black Belt Techシリーズ リザーブドインスタンス & スポットインスタンス

Amazon EC2 Auto Scaling (日本語) - ユーザーガイド · Amazon EC2 Auto Scaling (日本語) ユーザーガイド Amazon EC2 Auto Scaling とは

AWS Black Belt Online Seminar 2016 Amazon EC2 Spot Instances（スポットインスタンス）

EC2 Avanzado

Measurement and Scaling

Scaling eBay Kleinanzeigen

AWS Black Belt Techシリーズリザーブドインスタンス & スポットインスタンス