Embed Size (px)
DESCRIPTION
gumi study#18
Citation preview
Auto scalingを 一年間運用してみた
株式会社gumi!
西村 遊
自己紹介
❖ 西村 遊!
❖ gumi入社してもうすぐ2年!
❖ sysopチーム サーバ構築・運用!
❖ 好きなAWSサービス：AutoScaling
AutoScaling 実運用で使ってますか？
gumiで1年間利用してみた結果※構想期間含む
導入したアプリでの サーバー構築コストはほぼ0
!
障害時の再作成コストも0
同じ構成のサーバーを作成する 仕事がなくなる！！！
でも
大切なのはAutoScalingの 設定ではない
起動したAMIを どう使える状態にするか
AutoScalingでサーバー構築コストが
ほぼ０ !
手を触れずにサービスインまで いけるようにAMI+仕組みを作ろう
!
というお話
目次
❖ 起動からサービスインまでの作り込み!
❖ gumiで運用中の2パターン!
Scaduled Scale Out!
Auto Healing!
❖ 実際に運用してみて
起動からサービスインまでの作り込み
❖ AutoScalingはAMIベース!
!
❖ AMIは取得時点のスナップショットなので、!
更新分をどう持ってくるかを考える!
!
❖ ここを考えないとアプリケーション側で不整合が起こる
AutoScalingGroupの設定に!ELBを指定しなければ接続されないが、!
急な削除時に上手く外れてから削除されなかった為、!設定している。
AMIには!gitからリポジトリ取得!スクリプト起動!までの処理を入れておく
gitサーバー負荷軽減の為
目次
❖ 起動からサービスインまでの作り込み!
❖ gumiで運用中の2パターン!
Scaduled Scale Out!
Auto Healing!
❖ 実際に運用してみて
Scaduled Scale Out
http://aws.clouddesignpattern.org/index.php/CDP:Scheduled_Autoscaling%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
リクエスト数のパターンは一週間ほぼ同じ。!さすがに深夜帯のアクセス数は少ない。
と を同じ台数にしておくのはもったいなーい
の時間はインスタンスを減らしている
目次
❖ 起動からサービスインまでの作り込み!
❖ gumiで運用中の2パターン!
Scaduled Scale Out!
Auto Healing!
❖ 実際に運用してみて
Auto healing
❖ AutoScalingGroupではdesired-capacityの数に!
インスタンス台数が調整される。!※desired-capacityは以下の範囲内で設定!
min size =< desired-capacity =< max size
❖ 突然の死があってもインスタンスが再作成される!
❖ spotインスタンスと組み合わせれば、spot価格高騰で削除されても、再作成される
Auto Healing
ELB配下の一部をspotインスタンスで用意し、Auto scaling Groupは分ける!!spotインスタンスが全滅してもアプリケーション的には耐えられる台数にしておく!!※c1.xlargeをspotインスタンスでたてると$0.192/hなので! オンデマンド価格$0.740/hと比べて3分の1以下
Auto Healing
spotpriceの高騰で!＿人人人人人人＿!＞ 突然の死 ＜!‾Y^Y^Y^Y^Y‾
Auto Healing
spotpriceが同額or以下に戻ったら!リクエストが受け付けられ
新たなインスタンスが起動
Auto Healingもとどおり
Auto Healing
こっちのグループでも、何らかの理由で!インスタンスが削除されたら同じことが起きる
!
再作成コスト0
目次
❖ gumiで運用中の2パターン!
Scaduled Scale Out!
Auto Healing!
❖ AMIの作り込み!
❖ 実際に運用してみて
spot priceの変動は激しい
どんどん激しくなっている
このときのスパイクは$1.5ぐらい
※EC2 Classicでc1.xlargeインスタンスの場合
launch configを書き換えて 上限を上げても
※書き換えできないので正確には入れ替え
c1.xlargeの通常価格 $0.74/h!
!spot priceスパイク最大値 $1.5/h!
約2倍で設定している人が多そう。
さすがに3倍なら大丈夫だろう。!$2.3 で設定
さらに激しく
11月後半からボーダーは$2.3へ
※EC2 Classicでc1.xlargeインスタンスの場合
gumiがボーダーを上げてしまった！？
頻度も価格も高くなってく※EC2 Classicでc1.xlargeインスタンスの場合
一ヶ月の間に20回以上落ちた…!
Maxが$2.9の時代到来
その度にAuto Healing
spotpriceが同額or以下に戻ったら!リクエストが受け付けられ
新たなインスタンスが起動
内部的にはこんな処理が走る
zone 1cを避ければなんとか
大きく変動があるのは!zone 1cのみ
※EC2 Classicでc1.xlargeインスタンスの場合
ならなかった
zone 1bも安心できない時代へ
※EC2 Classicでc1.xlargeインスタンスの場合
zone 1cは!更なる高みへ
spotインスタンス運用の 限界を感じた
priceが戻っては上がりの!繰り返しが発生
※EC2 Classicでc1.xlargeインスタンスの場合
通常の3倍の!価格がかかる
入札価格はいたちごっこ
❖ スポットインスタンス + AutoScaling構成はやめた!!❖ コストメリットは大きいが、肝心のピーク時に死んでいると困る!!❖ 現在は時間単位のスケーリング（Scaduled Scale Out）のみ
まだまだ価格遷移激しいのでボーダー上げたのは!
gumiではなかった
まとめ
AutoScalingでサーバー構築コストが
ほぼ０ !
手を触れずにサービスインまで いけるようにAMI+仕組みを作ろう
spot priceの価格上昇に
gumiは関与していない！ ※多分
一時期設定した価格が上限値となってpriceが変動していたのは偶然です…
ご清聴ありがとうございました
