月間 250 億 imps 配信するために

fluct が考えていること！@jewel_x12

誰？• @jewel_x12

• 株式会社 fluct に新卒から入って 3 年目

• 主にプログラマをやっている

• 最近はウルトラストリートファイターⅣにハマってます（めっちゃ弱い）

• 大学時代は自然言語処理をやってました

• 月間 250 億 imps 捌く広告配信サービスで必要なことを主にアプリケーションプログラマ目線で紹介

• 1人で喋ってるのは寂しいので随時質問ください！

is 何？• Web広告を配信するプラットフォームの中でも、特に SSP と呼ばれるもの

• 広告枠の販売やメディアの広告収益最大化を支援

• 国内 SSP 売上シェアではナンバーワン

• RTB 取引も取り扱っている

用語

• impression (インプレッション)

• 広告が表示された回数のこと

• 20 回表示されると 20 imps とか言ったりする

SSPとかRTBってなんじゃ• SSP (Supply Side Platform)

• 広告枠の販売やメディアの広告収益最大化を支援

• RTB (Real Time Bidding)

• ある広告インプレッションに対してオークションを行い、インプレッションと広告主のマッチングを行う

「アドテク勉強会」スライドを借りて説明（13ページ以降） http://www.slideshare.net/shoho/ss-36728773

fluct では月間 250 億 imps 取り扱っている！

RTB 配信ではリクエストの裏側で複数DSPに 対してオークションのリクエストが行われる！

主な登場人物

主な登場人物管理画面

案件を入稿したり運用を支援したり 配信実績レポート表示

レポートのための各種バッチ

主な登場人物

配信アプリケーション 広告リクエストを捌く RTB を実施する

主な登場人物広告 DB

管理画面から入力された案件に関する 各種情報や現在配信している imp 数

などが入る

主な登場人物配信 DB / Push サーバ

配信に必要なDB(Berkeley DB) 各配信サーバに配布される

各配信サーバへ配布する理由はいくつかあるが、 データに関するサーバが一時的に落ちても

スタンドアロンで配信サーバが動く状況を作りたい

主な登場人物

ログ収集・解析 配信実績を取得、その結果を 配信DBへフィードバックする

レポート作成 配信の最適化

主な登場人物

その他登場人物 純広告は CDN 経由で配信 管理・監視ツール ネットワーク機器

広告配信システムには全部大切！ !

今回は広告リクエストを捌く 配信部分を中心に話します

fluct の配信システムで 満たすべきどんな要件は何？

サービスにはいろいろな要件があり 要件に基いてシステムを構築していく

• たとえば

• ちょっぱやなレスポンスがないと価値を届けられないと思う

• 信頼できる EC サイトじゃないと買い物したくないよね

• ロードでブチブチ切れる動画配信サービスにしたくない

• これくらいの 💴 でやっていきたい！

RTB を行う 広告配信システムへの要件

• 広告リクエストに対し高速に応答する

• 広告が出ないということを防ぐ

• 集計漏れを防ぐ

• （+α）成長のための柔軟さ

RTB を行う 広告配信システムへの要件

• 広告リクエストに対し高速に応答する

• 広告が表示される前に別ページに移動したりするなどの機会損失がある

• DSP への RTB リクエストは並列に処理する。直列に処理した場合だと応答に時間がかかりすぎる

• 広告が出ないということを防ぐ

• ダウンタイムを無くす

• せっかくメディアを訪れたユーザが広告を見ないまま終わり、メディアや SSP の収入に繋がらない

RTB を行う 広告配信システムへの要件

• 集計漏れを防ぐ

• ログが収集できなかったなどで集計漏れ(imps, click, etc…)が起きると、これもメディアや SSP の収入に繋がらない

• （+α）成長のための柔軟さ

• 業界の状況はめまぐるしく変わる。それに追随し追い越すため、頑健かつ柔軟なサービスを継続的に提供する必要がある

• 要件を満たすためには柔軟さのある設計やスケーラビリティが必要だが、何よりもこれらを実現するために優秀なチームメンバー・挑戦できる環境が必要（1人で全部やるのは大変）

どんな人が システム構築に 関わっているの？

チームメンバーを ざっと分ける

• 相談に乗ってくれたり人・いい話を持ってくる人

• 営業さん

• 運用さん

• インフラさん

• DevOps を進める人

• アプリケーション開発者さん

• 雑用さん（色々できる人）

• 分ける必要はないけど、各々がチームの為に必要だと思うことをやっている

要件は簡単に満たせる？

250億 imps / mon の状況になると何が起こるか

• リクエスト処理が詰まる

• サーバが増える

• サービスが大きいので最悪時の障害も大きい

• サービスがもっと成長する可能性がある

250億 imps / mon の状況になると何が起こるか• リクエスト処理が詰まる

• 普通にレスポンスを返すだけでも多い。RTB が設定されているとすると、1 imp 毎に複数 DSP へ RTB リクエストを送ることになる

• I/O 等の処理待ちによりいろんなものが枯渇し、リクエストが捌けなくなる

• メモリ・スレッド・ネットワーク帯域・etc...

• 解決策 1: スイッチングハブを置いて複数のサーバにリクエストを分散させる

• 解決策 2: プログラムをもっと速くする・I/O 多重化等の工夫を頑張る

• いろんな策があっていろんな限界があるのでお金とか色んなものと相談

250億 imps / mon の状況になると何が起こるか• サーバが増える

• HDD が壊れたり色々な愉快なことが起こる可能性がアップ↑↑

• 継続して様子を見ていかないといけない

• アプリケーションやサーバー設定のリリースに時間がかかる

• サービスが大きいので最悪時の障害も大きい

• これも様子を見ていかないといけない

• 障害の影響を抑えていきたい

250億 imps / mon の状況になると何が起こるか

サービスがもっと成長する可能性がある

事業はスケールさせていきたい！💰💰💰💰💰💰💰💰💰💰💰💰

💰💰💰💰💰💰💰💰💰💰💰💰

250億 imps / mon の状況になると何が起こるか• サービスがもっと成長する可能性がある

• まだまだ成長盛り

• スケールのしやすさを考える必要がある

• システムはいろんな所で限界に来る

• 異常に優秀な営業問題

• もっとリクエストが少なかった頃は◯◯砲が怖かった

月間 250 億 imps の状態で要件を

どう満たせばいいのか

多量の imp を安定して捌くことと これからのために考えていること

おもに

「障害影響範囲を狭める」

「スケールのしやすさ」

多量の imp を安定して捌くことと これからのために考えていること

• スケールのしやすさ • 疎結合なアプリケーション構成 • オンプレとクラウドの使い分け

• 障害影響範囲を狭める • 障害を減らすためのデプロイフロー • クラウドの有効活用 • 監視

• これらの項目は色々考えていることの一部。他にも案件DBや計測系の冗長性確保等がある

疎結合な アプリケーション構成

• 配信アプリケーション・計測・集計の分離

• サーバーレベルで分離

• 負荷高騰等の要因で他のアプリケーションが動かなくなるようなことをできるだけ防ぐ

• 各アプリケーション単位でスケールしやすい

疎結合な アプリケーション構成

• 配信アプリケーション • リクエスト処理・案件選択（PHP, Perl）

• もっと速い言語じゃなくても今のところ大丈夫 • もちろん可能な限り速い方がいいが、言語を使える人やメンテナンス性とのバランスもある

• RTB アプリケーション（Erlang） • 軽量プロセス・並列処理が得意 • 「Erlang による SSP 側 RTB」スライド ( http://www.slideshare.net/ajiyoshi/ad-tech-20121030-14943813 )

• どこかがボトルネックになったらそこを取り替えていく • 例えば案件選択(Perl)がボトルネックになったら、そこだけ Golang 製に取り替えていくとか

• ボトルネック自体はどっかに移るので、全体の様子を見ていかないといけない

もう少し低レイヤーでの構成 !

fluct ではオンプレミスとクラウドの ハイブリッドになってる

ネットワーク構成概要

GSLB

エラスティックな ロードバランサ

L3SW L2SWLVS (DSR)

!(配信)

配信配信配信

(配!(配信)

!(配信)

クラウド

DC1

DC2

NIC 多重化等によるネットワーク冗長性確保やハードウェアレベルでの冗長性確保が考えられている （あんまり詳しくない）

オンプレミスと クラウドの良い所

• オンプレミスの良い所 • インフラ・ネットワークの構成をハードウェアレベルで自分たちで組める（ブラックボックスが少なく、コントローラビリティがある） • 制限が少なく、できることが増える

• 買い切りのハードウェアを資産として見ることができる • 色々なサービスを（これからも）運営するので、そちらへまわすことも可能

• (fluct では) 安い • いろんな観点がある。オンプレミスは初期費用やハードウェア保守などのコストも掛かるし、マシンリソースに余裕がありすぎると高いし、n 年後も使い物になるようなマシンが n 年後もちゃんと使用されているとかの前提のもとで安い

オンプレミスと クラウドの良い所

• クラウドの良い所 • スケーラビリティ & サービスリリースのスピード • しっかり用意してあれば急なアクセス数増加にも耐えられる • オートスケールができるような設計が必要

• 予測は難しい。見通しがそんなに立っていなくても、オンデマンドでスケールアップ・アウトさせながら動き始めることができるというのは、スピード重視の場合に大事

• 立てたり潰したりを気軽にできるからこそのデプロイフローや検証環境構築

• インフラ専任のエンジニアがいなくてもいける

fluct がハイブリッドに なってる経緯

サービスの成長によって 要件を満たすための

システム構成が変わってくる

fluct がハイブリッドに なってる経緯

• 2010 年、DC のラックで産声をあげる

• 順調に成長（サーバーが増えてくる）

• 営業さん < imp ドゾー ( ^^) _旦~~

• 2013 年、imp が捌ききれなくなってくる

• 営業さん優秀過ぎ問題

• 次の増設について考え始める

fluct がハイブリッドに なってる経緯

• 増設サーバーを置けるところの空きが無い

• クラウドかぁ… プロビジョニングスクリプトが今の環境向けに書かれていたりするしコントローラビリティも不安だし、安定して配信するならやっぱりオンプレミスでやりたいなぁ（別 DC で次の増設へ動き出す）

• 営業さん > imp ドゾー ( ^^) _旦~~

• 開発 > ちょwww（嬉しい悲鳴）

• DC だと次の増設間に合わない → 2013, クラウドへ頑張って移行（リードタイム短くて◎）

fluct がハイブリッドに なってる経緯

• クラウド使っているとよく分からないところがたまにあるし（暖機運転が必要だったり）、外部サービスにロックインされるリスクもあるなぁ

• 2014, 別 DC で増設完了

• クラウド環境は緊急避難弁として使用

• デプロイ環境・開発や検証のための便利な環境をクラウドに作りはじめる（クラウドならではの柔軟性◎）

• その後も色々あり現在（2015）へ

障害を減らす 影響範囲を小さくする

ための工夫ダウンタイムをなくしていこう

デプロイによる障害の影響範囲を 小さくしていきたい

• デプロイしたら問題が見つかった！による影響を減らしたい

• アプリケーション書く人としてはできるだけ影響範囲を小さくしていくような機能追加を心掛けたい

• といっても難しいし心配は無限

デプロイによる障害の影響範囲を 小さくしていきたい

• デプロイフローを安全安心に • 1 台だけデプロイして様子見 with 監視 • 何かあっても影響範囲は小さい • リリース内容やアプリケーション構成による

• すぐに前の状態に戻せること • Git 等の VCS による運用（テストの通った revert commit が便利）

• Blue-Green デプロイメント • これらの機能があるとリリース時に安心感を与えてくれるが、リリースする側もどう戻せるかなどの影響範囲を考えていけると良い

本番に近い状態で開発を• 想定していないリクエストだった（泣）とか開発環境では動いてたのに～～～とかを減らす

• 本番と同様なリクエストでテスト • 本番環境のインスタンス1台だけ開発ブランチに切り替え、少量の本番リクエストを流して試すとか

• 最新状態の構成が反映された開発環境で開発 • クラウド上にオンデマンドで構築できる仕組みがあって、負荷試験とかできる

• ネットワークレベルで本番とは分離されているので安心 • クラウドで本番稼働していたり構成管理をしっかりしているおかげでもある

監視をしよう• デプロイ時以外でも障害はもちろん起きる • ピーク時、配信サーバがリクエストを処理しきらなくなる

• ハードウェア障害・クラウドサービスの障害 • たくさんサーバがあるので自動監視をしないと、やばそうになることは気付きにくい • グラフ化されていたり、定期的に見る機会があったりするといい

監視をしよう• 主に何を見ているの • load, memory, traffic, response time, HDD etc… • リクエストが多いとログに項目足すだけでヤバイデータサイズになる • imp ごとのログで1文字 (1 byte) 足しても、1日 0.8 GB 増える計算

• 気がついたら HDD 容量が足りなくなったり • もちろんアプリケーションエラーログも見る • たまたまや想定外で監視していなかった部分が問題になることもある。できるだけ E2E でもやって、サービスを正しく提供できているか見ることが大切

• 応答速度とかもサービスのクオリティに関連する

まとめ• fluct には月間 250 億の impression リクエストがやって来る • 広告配信ならではの要件がいくつかある

• 要件達成とこれからの成長のために「障害影響範囲を狭める」と「スケールのしやすさ」を念頭に置くことが大事

• 障害影響範囲を狭める • 冗長性の確保 • デプロイフローの改善 • 監視

• スケールのしやすさ • アプリケーションの手の入れやすさ • オンプレミスとクラウドのハイブリッド運用