なるほどわかった！EC2 Auto Scaling

不破 崇行 (Takayuki Fuwa)

自己紹介不破 崇行 ( ふわ たかゆき )

• 札幌出身、函館育ち• 小学校から大学まで、函館で育つ

• 好きな AWS プロダクトは「 CloudWatch 」と「 CloudTrail 」

• 好きな食べ物は稲荷寿司と歌舞伎揚げ

• 好きな言語は PHP とアイヌ語 ( ユーカラ )• 好きなテレビ番組は「笑点」と「アタック 25 」

本日のおはなし

• Auto Scaling の概要• Auto Scaling のメリット• ユースケース• 使い方・設定方法• ハマりポイント• Auto Scaling の勘所

Auto Scaling の概要

Auto Scaling とは

• EC2 の機能の 1 つ• 「設定したタイミング」 ( トリガー ) に応じて EC2 インスタンスを　増やしたり減らしたり出来る機能

• 増やす：スケールアウト• 減らす：スケールイン

• クラウドサービスの真骨頂とも言える便利な機能

Auto Scaling のイメージ (Web サーバ )

この部分で、インスタンス数が増えたり減ったりする

Auto Scaling の仕組み

• AMI からインスタンスを ELB 配下に自動生成

• グループ内のインスタンス数を 事前に指定することで、 ELB 内の Healthy なインスタンス数 を維持させる

Availability Zoneap-northeast-1c

Auto scaling Group

Instance

Auto Scaling

Instance Instance Instance

Auto Scaling Group• スケールイン、スケールアウト する部分をグループ化するという概念• 「伸縮するカタマリ」とイメージ

してください

Availability Zoneap-northeast-1c

Auto scaling Group

Instance

Auto Scaling

Instance Instance Instance

Auto Scaling の利点は主に 3 つ

• アクセス数が増えて来た時だけインスタンス数を一時的に増やすことが出来るため、コストを抑えることが出来る

• 不測の事態が発生した場合 ( スパイク発生など ) に、ダウンタイムを可能な限り減らすことが出来る

• 事前に構成設定 (AMI や登録する ELB) を設定出来るため、スケールアウト時の設定が非常にスムーズ

• インスタンス数を設定するだけで AWS 側でインスタンス生成から ELB 登録まで自動でやってくれる

コストを抑えることが出来る

• ピーク時だけインスタンス数を増やせばいいので、コストを抑えることが出来る

• 予めピーク時を予測できれば、タイムスケジュールによるスケールアウトも出来る。

ELB 上のインスタンス維持にも使える

• ELB 上の AP サーバ台数が減少 ( 高負荷で死んでしまった等 ) の場合でも作動する。

• ELB によるヘルスチェックに失敗した場合、 terminate した上で作り直してくれる

実際の活用例：１社内システムの場合• グループウェアの場合、営業時間帯 ( 平日 ) のみアクセスが多い傾向に ある

• 夜間や休日もアクセスがあるので、インスタンスを止めることは出来ない

• この場合、「営業時間帯だけインスタンス数を増やし、それ以外の時間帯は最小限に抑える」を Auto Scaling で実現出来る

• コストカットに繋がる

0:00 24:009:00 18:00この時間帯だけ、インスタンス数を2 台にする

実際の活用例：２ニュースサイトの場合• ニュースサイトは急なアクセス ( スパイ

ク ) が発生した場合、インスタンス数を増やさないと対応出来ない

• Yahoo! ニュースなどに転載された場合、一気に 5 倍ぐらいアクセス数が増える場合がある

• スパイクの発生タイミングは予測が出来ないため、ロードアベレージや Nginx Active connections などの数値からスケールアウトさせる

Auto Scaling の使い方

今回想定するケース

• WordPress で構築したブログサイト• 通常は 1 日アクセス 30,000PV• たまに記事がヒットして 100,000PV ぐらいになる

• アフィリエイト収入に直結するので、「絶対に止めたくない」

Auto Scaling のイメージ (Web サーバ )

構成

• AP サーバ /NFS サーバを構成する EC2 は t2.nano• 最低 1 台は ELB 上にインスタンスが存在するようにする• CPU 使用率が 80% を超えたら最大 3 台までスケールアウトする

• 今回は WordPress サイトを KUSANAGI で構築

設定に先だって考えるポイント

スケールアウト、スケールインの条件・タイミングシステム維持に必要な最低台数現時点で、「どれぐらいアクセスが来るのか」を予測おさいふの中身

スケールアウト、スケールインの条件・タイミング• CloudWatch からの アラート• 時間帯による条件設定

CloudWatch を使用したスケールアウト / イン• アラートドリブンな設定が

出来るため、「 CPU 利用率が 80% を超えた場合」などで設定出来る

• カスタムスクリプトを組めば Nginx の active connections 数で決めることも出来る

CloudWatch Auto Scaling

Instance

Instance

InstanceAuto scaling

Group

CloudWatch からのアラート発令がトリガーとなり、

スケールアウト開始

起動設定に従い、インスタンスを生成する。

自動的に ELB にも登録してくれる

時間帯によるスケールアウト / イン

• 予め時間帯を決めて、スケールイン / アウトを設定出来る

スケールアウトの考え方CloudWatch を使用した場合

• Nginx の Active connections 値を見て判断する場合

Active connections 数が 100 を超えたらスケールアウト発動

設定方法

• 設定するものは大きく分けて 2 つ• 起動設定• Auto Scaling グループ

• 事前に AMI が生成されていることが前提

起動設定を作成する

• 「起動設定」画面から、「起動設定の作成」を押下する

起動設定を作成する• 「マイ AMI 」から、自分で作成した AMI を選択する。

• ここで選択した AMI からインスタンスが生成される

起動設定を作成する• インスタンスサイズを指定する

起動設定を作成する•起動設定の名前や IAM ロールを設定

• この起動設定は、 AMI差し替えリリースをする際にコピーして使うので、名前に日付をつけると便利 ( 例： 20160620_jawsug-demo)

起動設定を作成する• EBS ストレージの設定をする

• 「合わせて削除」に必ずチェックを入れること• スケールインをする時に EBS だけ削除されずに残る場合がある

起動設定を作成する• セキュリティグループの設定をする

起動設定を作成する

• SSH ログインで使用する公開鍵を指定する• Ansible などで使うことを前提に考える

起動設定を作成する

• SSH ログインで使用する公開鍵を指定する• Ansible などで使うことを前提に考える

起動設定を作成する

• これで起動設定作成は完了。そのまま、「この起動設定を利用してAuto Scaling グループを作成する」で Auto Scaling グループを作成する

Auto Scaling グループを作成する

• 台数、所属させる VPC/ サブネット、 ELB を設定する

Auto Scaling グループを作成する

• 「高度な設定」を開き、登録する ELB を指定する。• ヘルスチェックのタイプを” ELB” にすること

Auto Scaling グループを作成する

• スケールアウト / インさせるタイミングを設定する

設定のポイント

AMI 作成時は「再起動しないで作成」でも場合によっては大丈夫DB や wp-content(共有ストレージ ) が別になっている場合、変動するファイ

ルはログデータ程度なので、問題ないログデータは CloudWatch Logs に入れると幸せになる

AMI を作成するインスタンスと Auto Scaling グループは別々のアベイラビリティゾーンにする

Auto Scaling のイメージ

ハマりポイント

ハマりポイント

•早めにスケールアウトさせる• 高負荷になってからスケールアウトしても手遅れになる場合がある• スケールアウト条件は厳しめ (早めに閾値を超えるように )• ELB のヘルスチェックをゆるめにする事

• 一度起動したインスタンスは、 1 時間は稼働させ続ける• すぐ終了させても、 1 時間単位での課金であるため、課金額は変わらない

ハマりポイント

• スケールアウト完了まで、 5 分〜 10 分ぐらいかかる• インスタンス生成から ELB ヘルスチェック通過まで待つ必要がある• このため、 5 分〜 10 分のこの間は高負荷で持ちこたえる必要がある

• 高負荷に耐えられず、 ELB 上のインスタンスが全滅した場合、サービス停止になる

ハマりポイント

•必ず成功するとは限らないので注意StatusCode: Failed

StatusMessage: We currently do not have sufficient m4.large capacity in the Availability Zone you requested (ap-northeast-1a). Our system will be working on provisioning additional capacity. You can currently get m4.large capacity by not specifying an Availability Zone in your request or choosing ap-northeast-1c. Launching EC2 instance failed.

( 現在、東京リージョンのアベイラビリティゾーンにキャパシティが無いため m4.large インスタンスを作ることが出来ませんでした )

　→ 要するに、インスタンスの売り切れ

インスタンスが売り切れた場合

• アベイラビリティーゾーンを変える• インスタンスサイズを変える

• 「起動設定」を作り直し、 Auto Scaling グループに再設定する。

Auto Scaling が向かない場合

•完全に傾向が掴めず、スパイクが激しい場合• この場合、ゆとりを持って ELB 上のインスタンス数を確保する• ELB はスパイクに結構弱い。

まとめ

•オートスケールは何かと便利• スケールアウトする予定が無くても、不測の事態に備えて AMI

を用意しておくこと。• スケールアウト基準は厳しく

• 利用状況を考え、ある程度予測することが大事

Auto Scaling とは

• EC2 の機能の 1 つ• 「設定したタイミング」 ( トリガー ) に応じて EC2 インスタンスを　増やしたり減らしたり出来る機能

• 増やす：スケール＿＿＿• 減らす：スケール＿＿＿

• クラウドサービスの真骨頂とも言える便利な機能

Auto Scaling とは

• EC2 の機能の 1 つ• 「設定したタイミング」 ( トリガー ) に応じて EC2 インスタンスを　増やしたり減らしたり出来る機能

• 増やす：スケールアウト• 減らす：スケールイン

• クラウドサービスの真骨頂とも言える便利な機能

質問あれば

•懇親会にいますので、その時に捕まえて下さい。• Facebook で適当に質問投げてもらってもいいです