- Auto ScalingについてはMin-Maxの振り幅感覚
- Spot&Reserved Instancesについては使いドコロと倹約の規模感
-
Twitterらいくな成長中の自社サービス
- ユーザ間コミュニケーションが多い
- push通知、メールの一斉配信を週に数回
- サービス開始から2年経過
-
ユーザ数：100万人〜
- アクティブ率:30%〜50%
-
システム構成
- WebAPIサーバ on EC2
- Worker on EC2
-
ユーザAがユーザBにmentionを送る
-
ユーザBに通知メールを送る
-
負荷傾向
- 600req/min〜24000req/min
- インスタンスは常時8台
- オフピーク時のリソースが無駄になる、高い
-
WebAPI
- リクエスト数に応じてAuto Scaling
- Spot Instancesは基本的には使わない
-
Worker
- Job数に応じてAuto Scaling
- Spot Instancesはかなり使う
- オンデマンド/ReservedよりSpot Instanceを少し早くスケールアウトさせ、より遅くスケール飲させる
- これにより、spotが帰る限りspotのみが増減する状況を作る
- 価格高騰してSpotInstancesが全部落ちたらどうするか
- 最低1台は立っているReservedが問題ない規模までスケールアウトしてくれる。その所要時間は許容する
- 処理中にSpotが落ちてStuckしたJobを定期的に改修、リトライするJobを書いておけば無問題
-
共通
- Spot Instancesを使わない場合も極力オンデマンドではなくReservedInstancesを使う
- 小さめのインスタンスタイプを使って細かく増減させて節約
- m3.2xlarge => m3.large x 4
- 予定されたアクセス増にはScaduled Actionで対応
- 予測不可能なスパイクアクセスは今日は考えない
-
WebAPI
- スティッキーにしない
- ELBもアプリもステートレス
- 急なアクセス増の準備時にはインスタンス数ではなくELBのスケールにも注意
- スティッキーにしない
-
Worker
- 仮にSpotが全く買えなくてもオンデマンド／Reservedで捌けるようアプリを設計する
- ELBのHealth Checkにたよれないので 自前監視、自殺帰航が必須
-
共通
- スケールアウトのトリガーからサービス員までを極力短く（2〜５分）する
- 時間がかかる初期化処理はAMIに入れておく。全部をchefで頑張ったりしない。
- 適切なhtresholdはサービスの仕様・規模・ユーザ層の変化によって少しずつ変わっていく。
- 定期的に設定を見直し、ピークなのに増えないという自体を避ける。
- インスタンス数、Spot Request数の上限に注意する。
-
WebAPI
- リクエスト数に応じたインスタンス数の立ち上げができる
-
パラメータチューニング要領
- Max = ピーク時のインスタンス数
- Min = Max * (アイドルReq数 / ピークReq数) + α
- Threshold
- 月113万 -> 月27万
- イニシャルコストは191万かかる
- 書くサービスの購入オプションも考える
- RDS(Reserved Instances), Elasticache, Cloudfront, Dynamo DBなど
- 高騰しにくいタイプのSpot Instancesを使うと安心かもしれない
- 旧世代のc1.mediumとかは狙い目
- Workerに食わせていたような処理をLambdaでさばくとかなり安くなる
- アプリケーションのチューニングもオススメ
- Lambdaをフルに使ったさらなる倹約アーキテクチャ
- HTTP/2時代にステートレスを前提にしていたScale戦略はどうするか