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

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サーバー負荷軽減の為

Scaduled Scale Out http://aws.clouddesignpattern.org/index.php/CDP:Scheduled_Autoscaling %E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

リクエスト数のパターンは一週間ほぼ同じ。! さすがに深夜帯のアクセス数は少ない。とを同じ台数にしておくのはもったいなーいの時間はインスタンスを減らしている

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でサーバー構築コストがほぼ０ ! 手を触れずにサービスインまでいけるようにAMI+仕組みを作ろう

spot priceの価格上昇に gumiは関与していない！ ※多分一時期設定した価格が上限値となってpriceが変動していたのは偶然です…

ご清聴ありがとうございました

http://d.hatena.ne.jp	616
http://dev.classmethod.jp	71
http://feedly.com	10
https://twitter.com	5
https://www.chatwork.com	2
http://cache.yahoofs.jp	1

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

by Yu Nishimura, Working at Applibot Inc

on Feb 26, 2014

Statistics

Views

Actions

6 Embeds 705

Accessibility

Categories

Upload Details

Usage Rights

Report content

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