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

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

1. 1. & Amazon EC2 スポットインスタンス Auto Scaling Amazon Web Service Japan K.K. Solutions Architect Akihiro Tsukada
2. 2. AWSでの担当 スタートアップのお客様 モバイル系ソリューション AWS Mobile Hub Amazon Cognito サーバレスアーキテクチャ 低コストアーキテクチャ エンジニア的な属性 Ruby, iOS OOP, SOLID, KISS 好き ジャッキーチェン 妻と娘 塚田 朗弘 @akitsukada 2
3. 3. はじめに
4. 4. Q スポットインスタンス と Auto Scaling は “新サービス”？ 4
5. 5. A 歴史は古いが、 今なお新機能のリリースが多く、 改めてご紹介したいサービス 5
6. 6. スポットインスタンスに関するアップデート@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 スポットブロック リリース 6
7. 7. アジェンダ Amazon EC2 EC2 スポットインスタンス Auto Scaling Tips Q & A 7
8. 8. Amazon EC2
9. 9. 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 ) 仮想クラウドサーバ 9
10. 10. Amazon EC2 購入オプション オンデマンドインスタンス スタンダードな時間課金型インスタンス リザーブドインスタンス 1年間または3年間の予約をすることで最大75%の割引 スポットインスタンス 使われていないEC2インスタンスに入札して格安利用 最大90%以上の大幅割引 Dedicated Hosts お客様専用の物理サーバーを確保 10
11. 11. 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入札価格 など 11
12. 12. Auto Scaling @ Request Instances 12
13. 13. 大幅なコストカット サーバーリソース節約 急な負荷増加に対応 巨大な計算能力の確保 …etc 13
14. 14. EC2 スポットインスタンス
15. 15. Amazon EC2 スポットインスタンス 余っているEC2インスタンスを低価格で有効活用していただく仕組み 最大90%以上の割引価格でEC2インスタンスを使用可能 スポット入札アドバイザー、Spot Fleet、Spot Blockなどの 強力な周辺ツール/機能 分散処理、Workerが典型的なユースケース …だったが、新しい動きも出てきている Amazon EMR、Auto Scalingとの併用が容易 $1 $ 15
16. 16. この資料において単に「スポットインスタンス」という場合、 特に断りがなければ従来のスポットインスタンスを指します。 スポットブロック機能およびそのインスタンスを指す場合は明示的に 「スポットブロック」「スポットブロックのインスタンス」と呼びます。 注 16
17. 17. スポットインスタンス関連概念の整理 スポットプール スポット価格 入札価格 落札 インスタンスの中断 17
18. 18. ap-northeast-1a (Tokyo Region) m4.large … m4.xlarge スポット関連概念の整理 c4.large ap-northeast-1c m4.large … m4.xlarge c4.large 18
19. 19. ap-northeast-1a (Tokyo Region) m4.large … m4.xlarge スポット関連概念の整理 c4.large ap-northeast-1c m4.large … m4.xlarge c4.large 使用中 使用中 使用中 使用中 使用中 使用中 19
20. 20. 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インスタンスたち 20
21. 21. ap-northeast-1a (Tokyo Region) m4.large … m4.xlarge スポット関連概念の整理 - スポット価格 c4.large ap-northeast-1c m4.large … m4.xlarge c4.large 使用中 使用中 使用中 使用中 使用中 使用中 $0.038 4 $0.034 6 $0.034 6 $0.053 0 $0.020 9 スポットプール毎に需要と共有のバランスで変動する、 その時点でのスポットインスタンス課金額 同じインスタンスタイプでもAZで異なる価格 $3.66 21
22. 22. ap-northeast-1a (Tokyo Region) m4.large … m4.xlarge スポット関連概念の整理 - 入札価格 c4.large ap-northeast-1c m4.large … m4.xlarge c4.large 使用中 使用中 使用中 通常 使用中 通常 使用中 通常 使用中 $0.038 4 $0.034 6 $0.034 6 $0.053 0 $0.020 9 「最大でここまでなら支払ってもよい」という価格 実際に課金されるのはスポット価格 管理コンソールまたはRequestSpotInstances APIから リクエスト可能 $3.66 「東京リージョンの 1aにあるc4.largeを 最大$0.05で使いたい！」 22
23. 23. ap-northeast-1a (Tokyo Region) m4.large … m4.xlarge スポット関連概念の整理 - 落札 c4.large ap-northeast-1c m4.large … m4.xlarge c4.large 使用中 使用中 使用中 通常 使用中 通常 使用中 通常 使用中 $0.038 4 $0.034 6 $0.034 6 $0.053 0 $0.020 9 入札価格がスポット価格を上回り、スポットプールに空きがあった場合※、 希望したスポットインスタンスを使いはじめることができる ※詳しくは「スポットインスタンスのしくみ」を参照のこと http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/how-spot-instances-work.html $3.66「東京リージョンの 1aにあるc4.largeは 現在$0.0346なので、 $0.05入札で起動できた！」 23
24. 24. ap-northeast-1a (Tokyo Region) m4.large … m4.xlarge スポット関連概念の整理 - インスタンスの中断 c4.large ap-northeast-1c m4.large … m4.xlarge c4.large 使用中 使用中 使用中 通常 使用中 通常 使用中 通常 使用中 $0.038 4 $0.034 6 $0.051 $0.053 0 $0.020 9 スポット価格が変動し入札価格を上回ったとき、スポットインスタンス はターミネートされる。インスタンスから以下のURLをGETすると、 2分前から通知を取得できる。5秒ごとのポーリングを推奨。 http://169.254.169.254/latest/meta-data/spot/termination-time $3.66「スポット価格が変動して 入札価格$0.05を上回って しまった。ターミネート前 に終了処理をしよう」 24
25. 25. スポットリクエストと課金チャート
26. 26. 単価 時間 スポット価格 入札額 課金額 ①リクエスト 投入 $0.01 $0.24 $0.30 1h 1h ③1時間 単位の課金 ④ 入札額＜スポット価格 になったので インスタンス終了 スポットリクエストと課金 ② 入札額>スポット価格 になったので インスタンス起動 <1h ⑤強制終了時の1時間 未満の利用分は非課金 ⑥スポットリクエストは キャンセルするまで有効 なので再度インスタンス起動 26
27. 27. 入札戦略（旧） スポットフリート（後述）の登場以前は、以下の様な 意図と要領で入札価格を決定するノウハウがあった 1. コスト最小型 ターゲットスポットプールの最低価格で入札 2. 価格履歴順応型 直近のスポット価格等をプログラムで監視して入札額を調整 （≒手動スポットフリート！） 3. オンデマンドキャップ型 オンデマンド料金付近で入札し、オンデマンドより高い課金はさせない 4. 割り込みリスク最小型 オンデマンドよりも高く入札し、ターミネートのリスクを軽減する 現在はスポットフリートを使うことで基本的にこれらを カバーできるため、スポットフリートの活用がオススメ！ 27
28. 28. 価格高騰しにくいスポットプールを選ぶには スポット入札アドバイザー（2015.08〜） リージョン、OS、 入札価格 (25%, 50%, 100%) を選ぶと、各スポット プールの過去データ（先 週、先月）と照合して、 価格高騰の可能性を表示 してくれる。 vCPUやメモリ、EMRサ ポート有無でフィルタリ ングも可能。 https://aws.amazon.com/jp/ec2/spot/bid-advisor/ 28
29. 29. スポットインスタンス ここまでのまとめ EC2購入オプションの一つで、各スポット関連サービスの 基本となる考え方 管理コンソールおよびRequestSpotInstances APIで利用 機能連携されているAutoScaling、EMRからも利用可能 スポット価格が入札価格を上回るとターミネートされる 通知をチェックし、終了処理を仕込んでおく必要がある 対策としていくつかのアプローチがあり、それぞれ考慮 しておくべきことがある（次ページ参照） スポット入札アドバイザーで価格変動しにくいスポットプー ルを見つけることができる 29
30. 30. スポットインスタンス利用時の考慮点
31. 31. スポットインスタンス 利用時に考慮しておくべきこと 1. ターミネート時の後処理 2. 突然のターミネートが許容されるワークロードか？ Webのフロントサーバなどユーザインパクトに直結する箇所や、 遅延が許されないタスクでの使用はNG…だった 今なら、そういうときはスポットフリートを検討すべし 3. いかにターミネートの頻度、リスクを軽減するか 複数のスポットプールに分散し、スポット価格高騰時のリスクを 軽減するスポットフリートを利用する スポット価格の変動に関わらず、一度落札できさえすれば 指定時間内は落ちないスポットブロックを利用する 4. とはいえ、それでも必要なインスタンスが確保できなかったら？ 31
32. 32. スポットフリート
33. 33. スポットフリート（2015.05〜） EC2スポットインスタンスを効率よく利用するための ユーザー支援＆スポット管理機能 管理コンソールおよびRequestSpotFleet APIから利用 複数のスポットプールにそれぞれ異なる価格を入札した り、各プールのスポット価格が変動した際の処理を自動 化したりできる 必要な台数またはリソースをフリート全体で確保する インスタンスの配置戦略として、最も低価格なスポット プールを優先して使う、極力多くのスポットプールに分 散して利用するといった戦略が選択できる 33
34. 34. つまりスポットフリートとは 1. 複数のスポットプールを効率的に使う • より安価なスポットプールを選択 • より安全に複数のスポットプールを選択 2. 大量のコンピューティングリソースを スポットインスタンスで維持しやすくする というスポットユーザ支援機能 34
35. 35. 《事例紹介》 Webアプリケーション with スポットフリート
36. 36. 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サーバ群 36
37. 37. スポットフリートによるDiversification 複数のスポットプールを選択 似た性能/指向を持つ インスタンスタイプを選択 c3.large, m3.large, m4.large, r3.large, c4.large 37
38. 38. 30日間以上で約50台の スポットインスタンスが リクエストされた - 45台を下回ることは なかった - 50台必要な箇所で 45台に落ちること を許容したことで、 85%のコストカットに 0 0.02 0.04 0.06 0.08 0.1 0.12 30 35 40 45 50 55 Instances Average Price Per Instance - 50台を45台にして 試算しても、やはり 83%のコストカットに スポットフリート＠Webアプリ の結果 38
39. 39. Whodunit? 39
40. 40. スポットブロック
41. 41. スポットブロック（2015.10〜） スポットインスタンスのオプションではあるが、指定した 時間中（1〜6時間）はターミネートされないという機能 スポットインスタンスをAPIでリクエストする際、 blockDurationMinutesパラメータを指定すると スポットブロックとしてのリクエストになる 管理コンソールは未対応（2015年12月16日現在） スポット価格とは別系統で変動するスポットブロック専用の 価格（以下、ブロック価格）は存在する 課金額としては落札時のブロック価格が維持される 指定時間内でも、使用を中止すればその時点までの 課金しか発生しない 41
42. 42. ~ 21% 1時間以内 ~ 35% 2時間以内 ~ 40% 3時間以内 およそ50%のインスタンスが 6時間以内にターミネートされている 6時間は妥当か？ 42
43. 43. EC2 各購入オプション料金比較例 2015年12月16日現在/東京リージョン/Linuxインスタンス。()内はOn-Demandからの節約比率 On Demand Reserved Instances for 1 year Spot Instance s Spot Block All Upfront Partial Upfront No Upfront 1h 6h c4.large $0.14 $0.0935 (33%) $0.095 (32%) $0.106 (24%) $0.0265 (81%) $0.077 (45%) $0.098 (30%) m4.large $0.183 $0.0961 (47%) $0.098 (46%) $0.115 (37%) $0.0206 (88%) $0.101 (44%) $0.128 (30%) r3.large $0.21 $0.1339 (36%) $0.1367 (35%) $0.157 (25%) $0.0202 (90%) $0.116 (44%) $0.147 (30%) 43
44. 44. スポットブロックと課金（時間経過パターン） 単価 時間 ブロック価格 入札額 課金額 $0.24 $0.30 6h ①リクエスト 投入 --block-duration-minutes 360 ②落札後は 課金額固定 ③指定した時間が経過した 44
45. 45. スポットブロックと課金（手動終了パターン） 単価 時間 ブロック価格 入札額 課金額 $0.24 $0.30 ③手動でリクエストを 終了した 6h ①リクエスト 投入 --block-duration-minutes 360 ②落札後は 課金額固定 45
46. 46. つまりスポットブロックとは 1. 最初に落札さえできれば、ブロック価格が高騰 しても課金額維持＆指定時間内は終了されない 2. 1〜6時間の短期間を前払いなしで割安利用でき るリザーブドインスタンスに近いもの • 途中で終了すれば課金も停止(期間縛りなし) • 価格はオンデマンドより安くスポットより高い というスポットインスタンスの拡張機能 46
47. 47. Q それでも必要なインスタンスを 確保できなかったら？ そもそも落札できなかったら？ 47
48. 48. A （解答例） オンデマンドインスタンスの 予備系を用意しておく 48
49. 49. 前提 1. スポットは落ちるもの。 2. スポットが落ちた時、ある程度の遅延を許容できる 設計になっていること。 構成 スポットなサーバ群とオンデマンドなサーバ群を用意 オンデマンドなサーバ群は最低台数のみ立てておく 二つのサーバ群に同じ処理をさせる (例:同じジョブを捌くWorkerなど) スポットサーバ群が突然全てターミネートしても、 オンデマンドサーバ群がスケールアウトするよう ASGを設定しておく。あるいは、スポットの終了処理中に オンデマンドサーバ群ASGの設定を変更するなど。 オンデマンド予備軍の作り方 49
50. 50. オンデマンド予備軍の作り方(ASGで実現する場合) Super Hard Task Spot ASG On-Demand ASG When CPU > 60% Then Add 2 When CPU < 20% Then Rem 2 When CPU > 75% Then Add 2 When CPU < 35% Then Rem 2 1. ASGの準備 同じタスクを与えつつ、 Scaling PolicyのThresholdに 差をつけ、 Spot ASGは On-Demand ASGより スケールアウトしやすく スケールインしにくい 設定にしておく 50
51. 51. オンデマンド予備軍の作り方(ASGで実現する場合) Super Hard Task Spot ASG On-Demand ASG When CPU > 60% Then Add 2 When CPU < 20% Then Rem 2 When CPU > 75% Then Add 2 When CPU < 35% Then Rem 2 2. 動作を確認 普段はSpot ASGだけインスタ ンスが増減し、On-Demand ASGは常に1台だけになってい ることを確認する 51
52. 52. オンデマンド予備軍の作り方(ASGで実現する場合) Super Hard Task Spot ASG On-Demand ASG When CPU > 60% Then Add 2 When CPU < 20% Then Rem 2 When CPU > 75% Then Add 2 When CPU < 35% Then Rem 2 3. スポット価格高騰！ Spot ASGのインスタンスが 終了し、On-Demand ASGの 1台のみが残る 52
53. 53. オンデマンド予備軍の作り方(ASGで実現する場合) Super Hard Task Spot ASG On-Demand ASG When CPU > 60% Then Add 2 When CPU < 20% Then Rem 2 When CPU > 75% Then Add 2 When CPU < 35% Then Rem 2 4. On-Demandがスケール On-Demand ASGが Auto Scalingによって スケールアウトし、 Spot ASGの代わりに頑張る 53
54. 54. Auto Scaling
55. 55. Auto Scaling オンとオフ 予測可能なピーク 無駄なサーバーは落としておきたい 負荷に応じて必要最小限の台数を立てておきたい 余剰キャパシティ 立ちっぱなしのEC2 55
56. 56. 予測可能なピークオンとオフ Auto Scaling 需要に応じて自動的にサーバが増減しコストカット スケーリングのポリシーやインスタンスは柔軟に設定可能 UnhealthyなインスタンスやAZを自動で排除して高可用性 サービスが成長してきたら最大台数を増やして対応 すっきり！ 56
57. 57. Auto Scaling @ Request Instances 57
58. 58. 代表的なユースケース 1/2 – ELB配下のWebサーバ EC2 EC2Auto Scaling AZ-1 AZ-2 スケーリングトリガーの例 ELBのLatency Auto Scaling Group内EC2の CPU使用率など EC2は複数AZに分散して高可用性 ELB 58
59. 59. 代表的なユースケース 2/2 – SQSのジョブを処理するWorker EC2 EC2Auto Scaling AZ-1 AZ-2 スケーリングトリガーの例 SQSのキューに溜まった メッセージ（ジョブ）数 Auto Scaling Group内EC2の CPU使用率など EC2は複数AZに分散して高可用性 大量のスポットインスタンスを 併用しやすいパターン コストカットチャンス！ SQS 59
60. 60. 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から手動で操作可能 スケーリングの種類 60
61. 61. 1. Auto Scaling Group (以下ASG) Auto Scalingの全体的な情報管理単位 ASG名、最小/最大台数、ヘルスチェック方法、AZ/VPC、ターミネート ポリシー、ELB、Instance Tags、Launch Configurationなど 2. Launch Configuration ASG内でEC2インスタンスを起動する際に必要な情報 通常のEC2インスタンスを起動する際の入力情報とほぼ同じ Launch Configuration名、AMI、インスタンスタイプ、 Security Group(s)、Key Pair、IAM role、user-data、 Storage、CloudWatch Detailed Monitoring、Spot priceなど 3. Auto Scaling Policy ASG内でいつどのようにスケールイン/アウトを実行するか ASG一つにつき複数のポリシーを設定できる Policy名、トリガーとするAlarm、Action内容 Auto Scalingの設定 61
62. 62. Auto Scaling図解 Auto Scaling Group AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds Launch Configuration Launch Configuration Launch Configuration AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate 62
63. 63. Auto Scaling図解 Auto Scaling Group Launch Configuration Launch Configuration Launch Configuration AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate Alarm!! CloudWatch ①CloudWatchから、CPU使用率60%超のAlarm! 63
64. 64. Auto Scaling図解 Auto Scaling Group Launch Configuration Launch Configuration Launch Configuration AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate ②Min-Max:2-6で現在4台なのであと2台増やせる 64
65. 65. Auto Scaling図解 Auto Scaling Group Launch Configuration Launch Configuration Launch Configuration AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate ③Launch Configurationに従いインスタンス起動 65
66. 66. Auto Scaling図解 Auto Scaling Group Launch Configuration Launch Configuration Launch Configuration AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate ④インスタンスの初期化、Health Checkを実行 66
67. 67. Auto Scaling図解 Auto Scaling Group Launch Configuration Launch Configuration Launch Configuration AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate ⑤Health Checkに問題なければELB配下に追加 67
68. 68. Auto Scaling図解 Auto Scaling Group Launch Configuration Launch Configuration Launch Configuration AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate ⑥Warm up期間はASGのメトリクスに含まれない 68
69. 69. Auto Scaling図解 Auto Scaling Group Launch Configuration Launch Configuration Launch Configuration AZ-1:VPC1:Subnet1Scaling Policy 2 (simple policy) Min:2, Max:6 AZ, VPC/Subnet, ELB, Tags AZ-2:VPC2:Subnet2 Scaling Policy 1 (with steps) Alarm: HighCPUUtilization Actions(Steps): 60 < value → add 2 Instances 80 < value → add 10% of group 30 > value → remove 2 Instances warm up: 300 seconds Alarm: HighLaytency Action(only one): 300 < value → add 2 Instances cool down: 300 seconds AMI, Instance Type, IAM Role, Security Group, Key Pair, user-data, Storage, Spot Price Associate ⑦Auto ScalingのAction完了！ 69
70. 70. スケールイン/アウト時の考慮点
71. 71. 1. 設定済みのAMI （ゴールデンイメージ）を用いる スケールアウト時の初期化処理 すべてインストール ＆構成済みのAMI 2. user-dataで 初期化スクリプトを実行する 3. Life Cycle Hookを利用して初期化する #!/bin/bash cd /home/ec2-user; aws s3 cp s3://aws-install-sh/install chmod +x ./install; ./install auto; pending SQS SNS 71
72. 72. 1. ターミネートに備える スケールインのActionが走ったらいずれかのインスタンスは ターミネートする 2. サーバーをステートレスにしておく セッション情報はDynamoDBやElastiCache等に外出しする ログファイルはS3にアップロードするなどの実装をする WebSocketのようなコネクション維持系プロトコルを使う 場合は工夫が必要 スケールイン時の後処理 72
73. 73. Auto Scaling ライフサイクルとターミネート
74. 74. 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 74
75. 75. ターミネーションポリシー スケールイン時、どのインスタンスから削除するか※ ① OldestLaunchConfiguration 最も古いLaunch Configurationにより起動している インスタンス ② OldestInstance/NewestInstance 最も古い/新しい起動時刻のインスタンス ③ ClosestToNextInstanceHour 次の課金が始まるタイミングが最も近いインスタンス ④ Default ①③の順に適用し、複数インスタンスが残ればランダム 複数ポリシー指定時は指定順に適用 全ポリシー適用後も複数インスタンスが存在する場合はランダム ※ただしインスタンス保護（次ページ）されているインスタンスは除く 75
76. 76. インスタンス保護 （2015.12.07〜） スケールイン時、任意のインスタンスを削除されないよう保護できる 長時間かかるタスクを実行中のインスタンス、Hadoopクラスタのマス ターノードなど 76
77. 77. Tips 1. Auto Scaling を Auto Healingとして使う 2. Auto Scaling Policyの調整方法 3. スパイクアクセスに立ち向かう 4. スポットプールとAuto Scalingの設定は常に見なおそう 5. スポットフリートAPIのJSONパラメータを生成 6. 各種上限に注意 7. Serverless Architectureのコスト効率
78. 78. Auto ScalingをAuto Healingとして使う Tips[1/7]
79. 79. Auto Healing サーバに障害が発生したとき自動的にネットワークから切 り離し、健全なサーバをサービスインさせる 方法 Auto Scaling Group の Min を任意の数に設定する Min-Max=1-1 にすれば 「常に1台起動。増えも減りもしない」 Min-Max=2-N にすれば 「常に2台起動。片方に障害があっても1台は耐える」 …など Auto ScalingをAuto Healingとして使う 79
80. 80. Auto Scaling Policyの調整方法 Tips[2/7]
81. 81. Auto Scaling Policyのパラメータチューニング 前提として、 そのまま使える公式な算出法などはない 81
82. 82. 以下の考え方を元にやってみて細かく調整 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使用率を使うとして 82
83. 83. Tips スパイクアクセスに立ち向かう [3/7]
84. 84. より突発的な スパイクアクセス に立ち向かうには 例: テレビ放送等 84
85. 85. AutoScalingや ELBは 突発的なピーク向き ではない 85
86. 86. ELB Auto Scaling こういうのが 得意
87. 87. スパイクアクセスの対応方法 1. ELB…Pre-Warming ビジネスサポートにご加入いただくと申請可能です 2. Webサーバ…増設（スケールアウト） 3. DBサーバ…増強（スケールアップ） 87
88. 88. RDSAZ1 AZ2RDS スパイクアクセスの対応方法 88
89. 89. RDSAZ1 AZ2RDS スパイクアクセスの対応方法 ELB Pre-Warming 89
90. 90. RDSAZ1 AZ2RDS スパイクアクセスの対応方法 ELB Pre-Warming … … EC2 スケールアウト 90
91. 91. RDSAZ1 AZ2 RDS スパイクアクセスの対応方法 … … ELB Pre-Warming EC2 スケールアウト RDS スケールアップ 91
92. 92. RDSAZ1 AZ2RDS スパイクアクセスの対応方法 92
93. 93. スパイクアクセスの予測ができない場合 1. ランディングページをS3でホスティングする 2. CloudFrontから配信する …etc 93
94. 94. Tips スポットプールとAuto Scalingの設定は 常に見なおそう [4/7]
95. 95. スポットプール スポットプールに対する需要は徐々に変わっていく Auto Scaling サービスのユーザー数、機能、アーキテクチャ等々、 様々な要因によって、徐々に適切なポリシーやMax台 数は変わっていく スポットプールとAuto Scalingの設定は常に見なおそう 95
96. 96. Tips スポットフリートAPIのJSONパラメータを 管理コンソールで生成 [5/7]
97. 97. 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" } ] } 97
98. 98. スポットフリートtips - 新コンソールでJSONを生成 ① ② ③ 1. スポットインスタンス管理画面を開く 2. 画面右上部分の青い吹き出しをクリック 3. Try it out. をクリック 98
99. 99. スポットフリートtips - 新コンソールでJSONを生成 画面を進めて JSON configを クリックすると選択した値がJSONで出力され、API利用時の雛形ができる 99
100. 100. Tips 各種上限の確認と緩和申請方法 [6/7]
101. 101. 各種上限の確認と緩和申請方法 – EC2関連 管理コンソール > EC2 > Limits ※今日お話した関連のものはだいたいここにある 101
102. 102. 各種上限の確認と緩和申請方法 – 利用状況確認 管理コンソール > Trusted Advisor > Performance > Service Limits ① ② ③ 102
103. 103. 各種上限の確認と緩和申請方法 – 利用状況確認 上限値の80%以上使用中のサービスを示してくれたりする 103
104. 104. Tips Serverless Architecture のコスト効率 [7/7]
105. 105. S3 アプリはS3から配信 されるHTML/JS、 またはネイティブ実装 ELB/EC2を使わず API Gatewayと Lambdaで応答 運用/構築/開発から の解放 ランニングコスト 効率が高く、多くの 場合 コスト減 に Lambda Other Services API Gateway Cognito CloudFront サーバレスアーキテクチャ例 105
106. 106. Q&A 次回Webinarのお申し込み http://aws.amazon.com/jp/event_schedule/ 106
107. 107. Webinar資料の配置場所 • AWS クラウドサービス活用資料集 – http://aws.amazon.com/jp/aws-jp-introduction/ 107
108. 108. 公式Twitter/Facebook AWSの最新情報をお届けします @awscloud_jp 検索 最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを 日々更新しています！ もしくは http://on.fb.me/1vR8yWm 108