Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
スケールアウト再考
Search
Daisuke Yamazaki
February 28, 2016
Technology
410
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
スケールアウト再考
Scaleout手法とは何かを再考します。
Daisuke Yamazaki
February 28, 2016
More Decks by Daisuke Yamazaki
See All by Daisuke Yamazaki
ゼロトラブルへの道
yamaz
23
9.2k
RWC2019 rubyによる超大量データ配信
yamaz
1
230
学び実践してきたこと
yamaz
1
440
RTB 30 min
yamaz
0
130
RailsとCで広告システムを作って起業した話
yamaz
1
390
robust logprocessing
yamaz
1
110
adserver 30min
yamaz
0
140
Other Decks in Technology
See All in Technology
[FECONF-2026] 신대륙을 향한 카카오페이증권 프론트엔드 항해기 (이주승)
l1ghthouse
0
370
AIに任せられるFlutterコードベースを作る 〜仕様をコードで表し、ハーネスで守る〜
myohei
1
630
[re:Invent2026事前勉強会(有志開催)]続きは、ラスベガスの廊下で / continue-in-the-vegas-hallway
sh_fk2
0
490
"AWSはちょっと苦手"でも大丈夫。AWS Blocks で手軽に作る Flutter のバックエンド #FlutterKaigi
tacck
PRO
0
130
Flutter Widget Previewerで始めるUIプレビューとVRTの自動化
sakusaku3939
0
200
渡米前の準備を制す!re:Invent 2026徹底準備術 / The Ultimate Preparation Guide for re:Invent 2026
yuj1osm
1
510
Lint の層を組み直した話
bengo4com
2
300
バックオフィスに染み出すTypeScript ── clasp で安全に仕組みを作る
nealle
1
170
新卒エンジニア、 介護士になる
ryu1013
1
670
Vue で書く 空間コンピューティング、TresJS と WebXR を使ったXR デバイスのフロントエンド開発
hiranuma
0
150
あなたのDartコードは丸見えかもしれない ~reFlutterで暴くFlutterアプリの中身と多層防御~
zozotech
PRO
0
750
[General] 개발자로 해외 기업에서 일하기
skydoves
1
260
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
273
28k
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
820
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
650
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
380
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.9k
We Have a Design System, Now What?
morganepeng
55
8.4k
Tell your own story through comics
letsgokoyo
1
1.1k
Deep Space Network (abreviated)
tonyrice
0
400
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.6k
Prompt Engineering for Job Search
mfonobong
0
570
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Transcript
スケールアウト再考 〜数千億アクセスへの道〜 Supership 山崎大輔(@yamaz)
山崎大輔(@yamaz) Supership 取締役 (旧Scaleout代表) Scaleoutはnanapi, Bitcellerと合併して Supershipになりました。 広告システムと検索システム作ってます。
広告システムについて システム : インターネット広告システム アクセス : 月間数千億〜 サーバ台数: 1000台程度 レスポンス
: 〜100msec ユーザ数 : 数億UU〜 上記のシステムを安定運用するための考え方 について話したいと思います。
現在のインターネット 広告配信の仕組み 4 DSP メディア側広告サーバ(SSP) DSP DSP ③ビッディング ①広告Request ②オークション
開催 ブラウザ ④広告Result 広告1配信(1imp)ごとにオークションを行う
(参考)弊社採用のソフトウェア群 配信系: nginx, apache, 独自エンジン(C++) KVS: memcached, 独自KVS(tokyocabinetベース) 集計: hadoop,
hive, spark, vertica 管理画面: Ruby On Rails DB : PostgreSQL ほぼオンプレ
いきなりですが、質問です。
いつも10人並んでるATMが1台があります. ここで新たにATMを1台足すと行列の数はどうな るでしょう? ATM ATM ATM
答え だいたい0人に近づいていく
いつも10人並んでるATMとは → 単位時間に到着する人数とATMが 処理できる人数が釣り合ってるということ いつも10人 ATM
ATMが1台増えると? → ATMが処理できる人数の方が多くなる → 行列の数がどんどん減っていく → 最終的に0人になる ATM ATM
ATMの処理性能 < 到着数の時 処理が間に合ってないってことな ので、行列がどんどん増えて 最終的にめちゃくちゃ遅くなる
ATMの処理性能 > 到着数の時 処理が間に合ってるってことなの で、行列がどんどん減って最終的 には0に近づく
リトルの公式(Little’s formula) 平均の待ち行列の数 L = λ * W L: システムの平均待ち行列数
λ: システムの平均到着率 W: システムの平均待ち時間
ここまでのまとめ イイネ! システムの処理性能 > アクセス ヨクナイネ! システムの処理性能 < アクセス
スケールアップとスケールアウト
スケールアップとスケールアウト どちらも システムの処理性能 > アクセス を維持するための手法
スケールアップとスケールアウト スケールアップ: システムの処理性能 > アクセス になるまでサーバをパワーアップ スケールアウト: システムの処理性能 > アクセス
になるまでサーバを増やす
スケールアウトという手法 システムの処理性能 > アクセス になるまでサーバを増やす ではなく システムの処理性能 > アクセス になるまで1台あたりのアクセスとデータ量を減らす
と考えてみる
(おさらい)システムの処理性能 < アクセス → 待ち行列がどんどん増えていく → システムはどんどん遅くなる ATM
システムの処理性能 < アクセス 1%しか超えてなくても、この状態が ずーっと続く限りは待ち行列は永遠に 増える →システムは無限に遅くなる
スケールアウトあるある 応答速度が10倍遅くなった! えぇっ?10倍サーバを足す必要があるの?? →必要ありません システムの処理性能 > アクセス を満たせばいいので、大抵の場合数割の増強で 事足りるはず
逆を言うと? 1台あたり数割の性能劣化が10倍以上の速度 低下をもたらす可能性がある!!
ミドルウェアの選定基準 ピーク性能ではなく、性能の安定度(分散の小 ささ)に着目する パフォーマンスが不安定なものはピーク性能が 良くても良くないものだと考える
性能の分散が小さい =制御しやすい ソフトA ソフトB 性能高 性能低 品質工学の考え方: ソフトBのほうがよいと考える
ミドルウェアの選定基準 1. 複雑な機構を持ったものを避け、単純なもの を採用する 2. GCやデータリバランスなどコントロールしにく い挙動のものを避ける 「やかんは壊れない」の心意気
スケールアウトあるある システムは設計を端折ったところからほころび 始める。 あらゆる箇所が現在の100倍になっても大丈夫 か確認しましょう。
スケールアウトあるある 処理能力を超えると一気にダメになる 対策: - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
スケールアウトあるある 処理能力を超えると一気にダメになる 対策: - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
スケールアウトあるある 処理能力を超えると一気にダメになる 対策: - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
スケールアウトあるある 処理能力を超えると一気にダメになる 対策: - ピークアクセス時の予兆を見逃さない - カナリアサーバの準備 - アクセスの強制的な平滑化
それでもダメなら スケールアップも積極的に検討しましょう。 SSDには随分と助けられました。 なおネットワーク帯域はスケールアップしにくい 領域なので、極力ネットワーク負荷の低いシス テム設計にしましょう。
最後に 1. 「システムの処理性能 > アクセス」の維持を強く意識 しましょう 2. 普通をきちんと積み重ねるだけで数1000億のアクセ スは十分対応可能 3.
とはいえ、大量アクセスを浴び続けることで養われる ものもある そんなシステムを取り回してみたい方はぜひ弊社に! http://recruit.supership.jp/