スケールアウト再考

Scaleout手法とは何かを再考します。

Transcript

1. スケールアウト再考 〜数千億アクセスへの道〜 Supership 山崎大輔(@yamaz)
2. 山崎大輔(@yamaz) Supership 取締役 （旧Scaleout代表） Scaleoutはnanapi, Bitcellerと合併して Supershipになりました。 広告システムと検索システム作ってます。
3. 広告システムについて システム ： インターネット広告システム アクセス ： 月間数千億〜 サーバ台数： 1000台程度 レスポンス ： 〜100msec ユーザ数 ： 数億UU〜 上記のシステムを安定運用するための考え方 について話したいと思います。
4. 現在のインターネット 広告配信の仕組み 4 DSP メディア側広告サーバ(SSP) DSP DSP ③ビッディング ①広告Request ②オークション 開催 ブラウザ ④広告Result 広告１配信(1imp)ごとにオークションを行う
5. （参考）弊社採用のソフトウェア群 配信系： nginx, apache, 独自エンジン(C++) KVS: memcached, 独自KVS(tokyocabinetベース） 集計： hadoop, hive, spark, vertica 管理画面： Ruby On Rails DB ： PostgreSQL ほぼオンプレ
6. いきなりですが、質問です。
7. いつも１0人並んでるATMが1台があります. ここで新たにATMを1台足すと行列の数はどうな るでしょう? ATM ATM ATM
8. 答え だいたい0人に近づいていく
9. いつも１0人並んでるATMとは → 単位時間に到着する人数とATMが 処理できる人数が釣り合ってるということ いつも10人 ATM
10. ATMが1台増えると？ → ATMが処理できる人数の方が多くなる → 行列の数がどんどん減っていく → 最終的に0人になる ATM ATM
11. ATMの処理性能 ＜ 到着数の時 処理が間に合ってないってことな ので、行列がどんどん増えて 最終的にめちゃくちゃ遅くなる
12. ATMの処理性能 > 到着数の時 処理が間に合ってるってことなの で、行列がどんどん減って最終的 には0に近づく
13. リトルの公式(Little’s formula) 平均の待ち行列の数 L = λ * W L: システムの平均待ち行列数 λ： システムの平均到着率 W: システムの平均待ち時間
14. ここまでのまとめ イイネ！ システムの処理性能 > アクセス ヨクナイネ！ システムの処理性能 < アクセス
15. スケールアップとスケールアウト
16. スケールアップとスケールアウト どちらも システムの処理性能 > アクセス を維持するための手法
17. スケールアップとスケールアウト スケールアップ： システムの処理性能 > アクセス になるまでサーバをパワーアップ スケールアウト： システムの処理性能 > アクセス になるまでサーバを増やす
18. スケールアウトという手法 システムの処理性能 > アクセス になるまでサーバを増やす ではなく システムの処理性能 > アクセス になるまで1台あたりのアクセスとデータ量を減らす と考えてみる
19. （おさらい）システムの処理性能 < アクセス → 待ち行列がどんどん増えていく → システムはどんどん遅くなる ATM
20. システムの処理性能 < アクセス 1%しか超えてなくても、この状態が ずーっと続く限りは待ち行列は永遠に 増える →システムは無限に遅くなる
21. スケールアウトあるある 応答速度が10倍遅くなった！ えぇっ？10倍サーバを足す必要があるの？？ →必要ありません システムの処理性能 ＞ アクセス を満たせばいいので、大抵の場合数割の増強で 事足りるはず
22. 逆を言うと？ 1台あたり数割の性能劣化が10倍以上の速度 低下をもたらす可能性がある！！
23. ミドルウェアの選定基準 ピーク性能ではなく、性能の安定度（分散の小 ささ）に着目する パフォーマンスが不安定なものはピーク性能が 良くても良くないものだと考える
24. 性能の分散が小さい ＝制御しやすい ソフトA ソフトB 性能高 性能低 品質工学の考え方： ソフトBのほうがよいと考える
25. ミドルウェアの選定基準 1. 複雑な機構を持ったものを避け、単純なもの を採用する 2. GCやデータリバランスなどコントロールしにく い挙動のものを避ける 「やかんは壊れない」の心意気
26. スケールアウトあるある システムは設計を端折ったところからほころび 始める。 あらゆる箇所が現在の100倍になっても大丈夫 か確認しましょう。
27. スケールアウトあるある 処理能力を超えると一気にダメになる 対策： - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
28. スケールアウトあるある 処理能力を超えると一気にダメになる 対策： - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
29. スケールアウトあるある 処理能力を超えると一気にダメになる 対策： - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
30. スケールアウトあるある 処理能力を超えると一気にダメになる 対策： - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
31. それでもダメなら スケールアップも積極的に検討しましょう。 SSDには随分と助けられました。 なおネットワーク帯域はスケールアップしにくい 領域なので、極力ネットワーク負荷の低いシス テム設計にしましょう。
32. 最後に 1. 「システムの処理性能 > アクセス」の維持を強く意識 しましょう 2. 普通をきちんと積み重ねるだけで数1000億のアクセ スは十分対応可能 3. とはいえ、大量アクセスを浴び続けることで養われる ものもある そんなシステムを取り回してみたい方はぜひ弊社に！ http://recruit.supership.jp/