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 広告1配信(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

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

いつも10人並んでる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/