Auto scalingを
一年間運用してみた

株式会社gumi!
西村 遊
自己紹介
❖

西村 遊!

❖

gumi入社してもうすぐ2年!

❖

sysopチーム サーバ構築・運用!

❖

好きなAWSサービス:AutoScaling
AutoScaling
実運用で使ってますか?
gumiで1年間利用してみた結果
※構想期間含む
導入したアプリでの
サーバー構築コストはほぼ0
!

障害時の再作成コストも0
同じ構成のサーバーを作成する
仕事がなくなる!!!
でも
大切なのはAutoScalingの
設定ではない
起動したAMIを
どう使える状態にするか
AutoScalingでサーバー構築コストが
ほぼ0
!

手を触れずにサービスインまで
いけるように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の変動は激しい
どんどん激しくなっている
※EC2 Classicでc1.xlargeインスタンスの場合

このときのスパイクは$1.5ぐらい
launch configを書き換えて
上限を上げても
※書き換えできないので正確には入れ替え
c1.xlargeの通常価格 $0.74/h!

!
spot priceスパイク最大値 $1.5/h!
約2倍で設定している人が多そう。

さすがに3倍なら大丈夫だろう。!
$2.3 で設定
さらに激しく
※EC2 Classicでc1.xlargeインスタンスの場合

11月後半からボーダーは$2.3へ

gumiがボーダーを上げてしまった!?
頻度も価格も高くなってく
※EC2 Classicでc1.xlargeインスタンスの場合

一ヶ月の間に20回以上落ちた…!
Maxが$2.9の時代到来
その度にAuto Healing
新たなインスタンスが起動

spotpriceが同額or以下に戻ったら!
リクエストが受け付けられ
内部的にはこんな処理が走る
zone 1cを避ければなんとか
※EC2 Classicでc1.xlargeインスタンスの場合

大きく変動があるのは!
zone 1cのみ
ならなかった
※EC2 Classicでc1.xlargeインスタンスの場合

zone 1cは!
更なる高みへ
zone 1bも安心できない時代へ
spotインスタンス運用の
限界を感じた
※EC2 Classicでc1.xlargeインスタンスの場合

通常の3倍の!
価格がかかる

priceが戻っては上がりの!
繰り返しが発生

入札価格はいたちごっこ
❖

スポットインスタンス + AutoScaling構成はやめた!

!
❖

コストメリットは大きいが、肝心のピーク時に死んでいると困る!

!
❖

現在は時間単位のスケーリング(Scaduled Scale Out)のみ

まだまだ価格遷移激しいのでボーダー上げたの
は!
gumiではなかった
まとめ
AutoScalingでサーバー構築コストが
ほぼ0
!

手を触れずにサービスインまで
いけるようにAMI+仕組みを作ろう
spot priceの価格上昇に
gumiは関与していない!
※多分
一時期設定した価格が上限値となってpriceが変動していたのは偶然です…
ご清聴ありがとうございました

Auto Scalingを一年間運用してみた