スケールアウト再考

Slide 1

Slide 1 text

スケールアウト再考〜数千億アクセスへの道〜 Supership 山崎大輔(@yamaz)

Slide 2

Slide 2 text

山崎大輔(@yamaz) Supership 取締役（旧Scaleout代表） Scaleoutはnanapi, Bitcellerと合併して Supershipになりました。広告システムと検索システム作ってます。

Slide 3

Slide 3 text

広告システムについてシステム：インターネット広告システムアクセス：月間数千億〜サーバ台数： 1000台程度レスポンス：〜100msec ユーザ数：数億UU〜上記のシステムを安定運用するための考え方について話したいと思います。

Slide 4

Slide 4 text

現在のインターネット広告配信の仕組み 4 DSP メディア側広告サーバ(SSP) DSP DSP ③ビッディング ①広告Request ②オークション開催ブラウザ ④広告Result 広告１配信(1imp)ごとにオークションを行う

Slide 5

Slide 5 text

（参考）弊社採用のソフトウェア群配信系： nginx, apache, 独自エンジン(C++) KVS: memcached, 独自KVS(tokyocabinetベース）集計： hadoop, hive, spark, vertica 管理画面： Ruby On Rails DB ： PostgreSQL ほぼオンプレ

Slide 6

Slide 6 text

いきなりですが、質問です。

Slide 7

Slide 7 text

いつも１0人並んでるATMが1台があります. ここで新たにATMを1台足すと行列の数はどうなるでしょう? ATM ATM ATM

Slide 8

Slide 8 text

答えだいたい0人に近づいていく

Slide 9

Slide 9 text

いつも１0人並んでるATMとは → 単位時間に到着する人数とATMが処理できる人数が釣り合ってるということいつも10人 ATM

Slide 10

Slide 10 text

ATMが1台増えると？ → ATMが処理できる人数の方が多くなる → 行列の数がどんどん減っていく → 最終的に0人になる ATM ATM

Slide 11

Slide 11 text

ATMの処理性能＜到着数の時処理が間に合ってないってことなので、行列がどんどん増えて最終的にめちゃくちゃ遅くなる

Slide 12

Slide 12 text

ATMの処理性能 > 到着数の時処理が間に合ってるってことなので、行列がどんどん減って最終的には0に近づく

Slide 13

Slide 13 text

リトルの公式(Little’s formula) 平均の待ち行列の数 L = λ * W L: システムの平均待ち行列数 λ：システムの平均到着率 W: システムの平均待ち時間

Slide 14

Slide 14 text

ここまでのまとめイイネ！システムの処理性能 > アクセスヨクナイネ！システムの処理性能 < アクセス

Slide 15

Slide 15 text

スケールアップとスケールアウト

Slide 16

Slide 16 text

スケールアップとスケールアウトどちらもシステムの処理性能 > アクセスを維持するための手法

Slide 17

Slide 17 text

スケールアップとスケールアウトスケールアップ：システムの処理性能 > アクセスになるまでサーバをパワーアップスケールアウト：システムの処理性能 > アクセスになるまでサーバを増やす

Slide 18

Slide 18 text

スケールアウトという手法システムの処理性能 > アクセスになるまでサーバを増やすではなくシステムの処理性能 > アクセスになるまで1台あたりのアクセスとデータ量を減らすと考えてみる

Slide 19

Slide 19 text

（おさらい）システムの処理性能 < アクセス → 待ち行列がどんどん増えていく → システムはどんどん遅くなる ATM

Slide 20

Slide 20 text

システムの処理性能 < アクセス 1%しか超えてなくても、この状態がずーっと続く限りは待ち行列は永遠に増える →システムは無限に遅くなる

Slide 21

Slide 21 text

スケールアウトあるある応答速度が10倍遅くなった！えぇっ？10倍サーバを足す必要があるの？？ →必要ありませんシステムの処理性能＞アクセスを満たせばいいので、大抵の場合数割の増強で事足りるはず

Slide 22

Slide 22 text

逆を言うと？ 1台あたり数割の性能劣化が10倍以上の速度低下をもたらす可能性がある！！

Slide 23

Slide 23 text

ミドルウェアの選定基準ピーク性能ではなく、性能の安定度（分散の小ささ）に着目するパフォーマンスが不安定なものはピーク性能が良くても良くないものだと考える

Slide 24

Slide 24 text

性能の分散が小さい＝制御しやすいソフトA ソフトB 性能高性能低品質工学の考え方：ソフトBのほうがよいと考える

Slide 25

Slide 25 text

ミドルウェアの選定基準 1. 複雑な機構を持ったものを避け、単純なものを採用する 2. GCやデータリバランスなどコントロールしにくい挙動のものを避ける「やかんは壊れない」の心意気

Slide 26

Slide 26 text

スケールアウトあるあるシステムは設計を端折ったところからほころび始める。あらゆる箇所が現在の100倍になっても大丈夫か確認しましょう。

Slide 27

Slide 27 text

スケールアウトあるある処理能力を超えると一気にダメになる対策： - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

それでもダメならスケールアップも積極的に検討しましょう。 SSDには随分と助けられました。なおネットワーク帯域はスケールアップしにくい領域なので、極力ネットワーク負荷の低いシステム設計にしましょう。

Slide 32

Slide 32 text

最後に 1. 「システムの処理性能 > アクセス」の維持を強く意識しましょう 2. 普通をきちんと積み重ねるだけで数1000億のアクセスは十分対応可能 3. とはいえ、大量アクセスを浴び続けることで養われるものもあるそんなシステムを取り回してみたい方はぜひ弊社に！ http://recruit.supership.jp/