数千億アクセスをさばくための考え方についてまとめました。

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/