Download as PDF, PPTX
![[AC07] 米国マイクロソフト本社で体験したノウハウを伝授！マイクロサービス実行基盤Azure Service Fabricの勘所](https://cdn.slidesharecdn.com/ss_thumbnails/ac07-170602093741-thumbnail.jpg?width=640&height=640&fit=bounds)
月間 250 億 imps 配信するために fluct が考えていること！
- 1. 月間 250 億imps 配信するために fluct が考えていること！ @jewel_x12
- 2. 誰？ • @jewel_x12 • 株式会社fluct に新卒から入って 3 年目 • 主にプログラマをやっている • 最近はウルトラストリートファイターⅣにハマって ます（めっちゃ弱い） • 大学時代は自然言語処理をやってました
- 3. • 月間 250億 imps 捌く広告配信サービスで必要 なことを主にアプリケーションプログラマ目線で紹 介 • 1人で喋ってるのは寂しいので随時質問ください！
- 4. is 何？ • Web広告を配信するプラットフォームの中でも、 特にSSP と呼ばれるもの • 広告枠の販売やメディアの広告収益最大化を支援 • 国内 SSP 売上シェアではナンバーワン • RTB 取引も取り扱っている
- 5. 用語 • impression (インプレッション) •広告が表示された回数のこと • 20 回表示されると 20 imps とか言ったりす る
- 6. SSPとかRTBってなんじゃ • SSP (SupplySide Platform) • 広告枠の販売やメディアの広告収益最大化を支援 • RTB (Real Time Bidding) • ある広告インプレッションに対してオークションを行い、 インプレッションと広告主のマッチングを行う 「アドテク勉強会」スライドを借りて説明（13ページ以降） http://www.slideshare.net/shoho/ss-36728773
- 7. fluct では月間 250億 imps 取り扱っている！ RTB 配信ではリクエストの裏側で複数DSPに 対してオークションのリクエストが行われる！
- 8.
- 9.
- 10.
- 11.
- 12. 主な登場人物 配信 DB /Push サーバ 配信に必要なDB(Berkeley DB) 各配信サーバに配布される 各配信サーバへ配布する理由はいくつかあるが、 データに関するサーバが一時的に落ちても スタンドアロンで配信サーバが動く状況を作りたい
- 13.
- 14.
- 15.
- 16. fluct の配信システムで 満たすべきどんな要件は何？ サービスにはいろいろな要件があり 要件に基いてシステムを構築していく • たとえば •ちょっぱやなレスポンスがないと価値を届けられないと思う • 信頼できる EC サイトじゃないと買い物したくないよね • ロードでブチブチ切れる動画配信サービスにしたくない • これくらいの 💴 でやっていきたい！
- 17. RTB を行う 広告配信システムへの要件 • 広告リクエストに対し高速に応答する •広告が出ないということを防ぐ • 集計漏れを防ぐ • （+α）成長のための柔軟さ
- 18. RTB を行う 広告配信システムへの要件 • 広告リクエストに対し高速に応答する •広告が表示される前に別ページに移動したりするなどの機会損失が ある • DSP への RTB リクエストは並列に処理する。直列に処理した場 合だと応答に時間がかかりすぎる • 広告が出ないということを防ぐ • ダウンタイムを無くす • せっかくメディアを訪れたユーザが広告を見ないまま終わり、メディ アや SSP の収入に繋がらない
- 19. RTB を行う 広告配信システムへの要件 • 集計漏れを防ぐ •ログが収集できなかったなどで集計漏れ(imps, click, etc…) が起きると、これもメディアや SSP の収入に繋がらない • （+α）成長のための柔軟さ • 業界の状況はめまぐるしく変わる。それに追随し追い越すた め、頑健かつ柔軟なサービスを継続的に提供する必要がある • 要件を満たすためには柔軟さのある設計やスケーラビリティが必要 だが、何よりもこれらを実現するために優秀なチームメンバー・挑 戦できる環境が必要（1人で全部やるのは大変）
- 20.
- 21. チームメンバーを ざっと分ける • 相談に乗ってくれたり人・いい話を持ってくる人 • 営業さん •運用さん • インフラさん • DevOps を進める人 • アプリケーション開発者さん • 雑用さん（色々できる人） • 分ける必要はないけど、各々がチームの為に必要だと思うことをやっている
- 22.
- 23. 250億 imps /mon の状況になると何が起こるか • リクエスト処理が詰まる • サーバが増える • サービスが大きいので最悪時の障害も大きい • サービスがもっと成長する可能性がある
- 24. 250億 imps /mon の状況になると何が起こるか • リクエスト処理が詰まる • 普通にレスポンスを返すだけでも多い。RTB が設定されているとすると、1 imp 毎に複数 DSP へ RTB リクエストを送ることになる • I/O 等の処理待ちによりいろんなものが枯渇し、リクエストが捌けなくなる • メモリ・スレッド・ネットワーク帯域・etc... • 解決策 1: スイッチングハブを置いて複数のサーバにリクエストを分散させ る • 解決策 2: プログラムをもっと速くする・I/O 多重化等の工夫を頑張る • いろんな策があっていろんな限界があるのでお金とか色んなものと相談
- 25. 250億 imps /mon の状況になると何が起こるか • サーバが増える • HDD が壊れたり色々な愉快なことが起こる可能性がアップ↑↑ • 継続して様子を見ていかないといけない • アプリケーションやサーバー設定のリリースに時間がかかる • サービスが大きいので最悪時の障害も大きい • これも様子を見ていかないといけない • 障害の影響を抑えていきたい
- 26. 250億 imps /mon の状況になると何が起こるか サービスがもっと成長する可能性がある
- 27.
- 28. 250億 imps /mon の状況になると何が起こるか • サービスがもっと成長する可能性がある • まだまだ成長盛り • スケールのしやすさを考える必要がある • システムはいろんな所で限界に来る • 異常に優秀な営業問題 • もっとリクエストが少なかった頃は⃝⃝砲が怖かった
- 29. 月間 250 億imps の状態で要件を どう満たせばいいのか
- 30.
- 31. 多量の imp を安定して捌くことと これからのために考えていること •スケールのしやすさ • 疎結合なアプリケーション構成 • オンプレとクラウドの使い分け • 障害影響範囲を狭める • 障害を減らすためのデプロイフロー • クラウドの有効活用 • 監視 • これらの項目は色々考えていることの一部。他にも案件DB や計測系の冗長性確保等がある
- 32. 疎結合な アプリケーション構成 • 配信アプリケーション・計測・集計の分離 • サーバーレベルで分離 •負荷高騰等の要因で他のアプリケーションが動 かなくなるようなことをできるだけ防ぐ • 各アプリケーション単位でスケールしやすい
- 33. 疎結合な アプリケーション構成 • 配信アプリケーション • リクエスト処理・案件選択（PHP,Perl） • もっと速い言語じゃなくても今のところ大丈夫 • もちろん可能な限り速い方がいいが、言語を使える人やメンテナンス性とのバラ ンスもある • RTB アプリケーション（Erlang） • 軽量プロセス・並列処理が得意 • 「Erlang による SSP 側 RTB」スライド ( http://www.slideshare.net/ajiyoshi/ad-tech- 20121030-14943813 ) • どこかがボトルネックになったらそこを取り替えていく • 例えば案件選択(Perl)がボトルネックになったら、そこだけ Golang 製に取り替え ていくとか • ボトルネック自体はどっかに移るので、全体の様子を見ていかないといけない
- 34.
- 35.
- 36. オンプレミスと クラウドの良い所 • オンプレミスの良い所 • インフラ・ネットワークの構成をハードウェアレベルで自分たちで組め る（ブラックボックスが少なく、コントローラビリティがある） •制限が少なく、できることが増える • 買い切りのハードウェアを資産として見ることができる • 色々なサービスを（これからも）運営するので、そちらへまわすこと も可能 • (fluct では) 安い • いろんな観点がある。オンプレミスは初期費用やハードウェア保守な どのコストも掛かるし、マシンリソースに余裕がありすぎると高いし、 n 年後も使い物になるようなマシンが n 年後もちゃんと使用されて いるとかの前提のもとで安い
- 37. オンプレミスと クラウドの良い所 • クラウドの良い所 • スケーラビリティ& サービスリリースのスピード • しっかり用意してあれば急なアクセス数増加にも耐えられる • オートスケールができるような設計が必要 • 予測は難しい。見通しがそんなに立っていなくても、オンデ マンドでスケールアップ・アウトさせながら動き始めること ができるというのは、スピード重視の場合に大事 • 立てたり潰したりを気軽にできるからこそのデプロイフローや 検証環境構築 • インフラ専任のエンジニアがいなくてもいける
- 38.
- 39.
- 40. fluct がハイブリッドに なってる経緯 • 2010年、DC のラックで産声をあげる • 順調に成長（サーバーが増えてくる） • 営業さん < imp ドゾー ( ^^) _旦 • 2013 年、imp が捌ききれなくなってくる • 営業さん優秀過ぎ問題 • 次の増設について考え始める
- 41. fluct がハイブリッドに なってる経緯 • 増設サーバーを置けるところの空きが無い •クラウドかぁ… プロビジョニングスクリプトが今の環境向けに書 かれていたりするしコントローラビリティも不安だし、安定して配 信するならやっぱりオンプレミスでやりたいなぁ（別 DC で次の 増設へ動き出す） • 営業さん > imp ドゾー ( ^^) _旦 • 開発 > ちょwww（嬉しい悲鳴） • DC だと次の増設間に合わない → 2013, クラウドへ頑張って移 行（リードタイム短くて◎）
- 42. fluct がハイブリッドに なってる経緯 • クラウド使っているとよく分からないところがたまにあるし （暖機運転が必要だったり）、外部サービスにロックインさ れるリスクもあるなぁ •2014, 別 DC で増設完了 • クラウド環境は緊急避難弁として使用 • デプロイ環境・開発や検証のための便利な環境をクラウドに 作りはじめる（クラウドならではの柔軟性◎） • その後も色々あり現在（2015）へ
- 43.
- 44.
- 45. デプロイによる障害の影響範囲を 小さくしていきたい • デプロイフローを安全安心に • 1台だけデプロイして様子見 with 監視 • 何かあっても影響範囲は小さい • リリース内容やアプリケーション構成による • すぐに前の状態に戻せること • Git 等の VCS による運用（テストの通った revert commit が便利） • Blue-Green デプロイメント • これらの機能があるとリリース時に安心感を与えてくれるが、リリー スする側もどう戻せるかなどの影響範囲を考えていけると良い
- 46. 本番に近い状態で開発を • 想定していないリクエストだった（泣）とか開発環境では動いてたの に∼∼∼とかを減らす • 本番と同様なリクエストでテスト •本番環境のインスタンス1台だけ開発ブランチに切り替え、少量の 本番リクエストを流して試すとか • 最新状態の構成が反映された開発環境で開発 • クラウド上にオンデマンドで構築できる仕組みがあって、負荷試 験とかできる • ネットワークレベルで本番とは分離されているので安心 • クラウドで本番稼働していたり構成管理をしっかりしているおかげで もある
- 47. 監視をしよう • デプロイ時以外でも障害はもちろん起きる • ピーク時、配信サーバがリクエストを処理しきらな くなる •ハードウェア障害・クラウドサービスの障害 • たくさんサーバがあるので自動監視をしないと、やば そうになることは気付きにくい • グラフ化されていたり、定期的に見る機会があった りするといい
- 48. 監視をしよう • 主に何を見ているの • load,memory, traffic, response time, HDD etc… • リクエストが多いとログに項目足すだけでヤバイデータサイズ になる • imp ごとのログで1文字 (1 byte) 足しても、1日 0.8 GB 増える計算 • 気がついたら HDD 容量が足りなくなったり • もちろんアプリケーションエラーログも見る • たまたまや想定外で監視していなかった部分が問題になること もある。できるだけ E2E でもやって、サービスを正しく提供 できているか見ることが大切 • 応答速度とかもサービスのクオリティに関連する
- 49. まとめ • fluct には月間250 億の impression リクエストがやって来る • 広告配信ならではの要件がいくつかある • 要件達成とこれからの成長のために「障害影響範囲を狭める」と「ス ケールのしやすさ」を念頭に置くことが大事 • 障害影響範囲を狭める • 冗長性の確保 • デプロイフローの改善 • 監視 • スケールのしやすさ • アプリケーションの手の入れやすさ • オンプレミスとクラウドのハイブリッド運用