Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RailsとCで広告システムを作って起業した話

 RailsとCで広告システムを作って起業した話

Startup with Rails and C

Daisuke Yamazaki

April 10, 2011
Tweet

More Decks by Daisuke Yamazaki

Other Decks in Technology

Transcript

  1. © 2011 Scaleout Inc. All right reserved. 今日話すること 1. RailsとCで大量配信システムをつくりました。

    2. アーキテクチャさえしっかりしてればほとんどの部分 はrubyでいけるよ 3. 秘密はあんまりなくやってることは割と普通です 4. メンバー募集中です([email protected]まで!)
  2. © 2011 Scaleout Inc. All right reserved. 弊社について 株式会社スケールアウト 代表取締役

    山崎大輔(@yamaz) Blog: 最速配信研究会 http://d.hatena.ne.jp/yamaz/ • 2006年に門前仲町で起業 • 広告配信システム「ScaleAds」の提供及びWeb大量配信に関する コンサルティング • 主に億を超えるようなアクセスに対するシステム開発を得意として ます
  3. © 2011 Scaleout Inc. All right reserved. ScaleAdsとは 1. カジュアル(=安価)に数十億アクセス/dayを

    捌くことを目指して開発された純国産広告配 信管理システム 2. PCサーバ1台あたり5000万アクセス/day以 上な性能 3. 月間数千億アクセスも可
  4. © 2011 Scaleout Inc. All right reserved. アーキテクチャ概要 配信サーバ Delivery

    Engine Logs 広告案件データ(PostgreSQL) 配信管理 システム 集計管理 システム C+ruby+swig Rails
  5. © 2011 Scaleout Inc. All right reserved. 配信部分 • Apache+独自DB+Cモジュール

    • 複数プロセスがSharedMemoryを介してデー タをやりとり • SharedMemoryの管理はruby+swigで
  6. © 2011 Scaleout Inc. All right reserved. 配信システム概要図 配信サーバ Delivery

    Engine Logs 広告案件データ(PostgreSQL) 配信管理 システム Rails Apache モジュール
  7. © 2011 Scaleout Inc. All right reserved. Apache+独自DB+Cモジュール 配信サーバ Delivery

    Engine Logs 広告案件データ(PostgreSQL) 配信管理 システム Rails Apache モジュール RDB+LLな構成だと1桁以上速度が落ちるの で、ここだけはCで書かれています。
  8. © 2011 Scaleout Inc. All right reserved. 配信部分 • 複数プロセスがSharedMemoryを介してデー

    タをやりとり 広告案件データ(SharedMemory) apache ユーザからのアクセス 管理プログラム群 管理DB
  9. © 2011 Scaleout Inc. All right reserved. SharedMemoryの管理はruby+swigで 管理DBからDBアップデート用DSLで記述 されたrubyスクリプトを作成し、各ADSVRで

    実行することにより、Sharedメモリを書き換える 広告データ (SharedMemory) 管理プログラム群 管理DB Rubyスクリプトを生成+実行 C-API+Swig
  10. © 2011 Scaleout Inc. All right reserved. 集計部分 • 配信サーバ側で一次処理、集計サーバでマー

    ジ集計(プチmap/reduce) • 一次集計はapacheのログ形式を工夫すること で速度を稼ぐ • 分散処理な為、基本集計に関しては全部ruby でも間に合ってる
  11. © 2011 Scaleout Inc. All right reserved. 集計システム概要 配信サーバ Delivery

    Engine Logs 広告案件データ(PostgreSQL) 集計管理 システム Rails 各サーバで 一次集計(Ruby)
  12. © 2011 Scaleout Inc. All right reserved. 一次集計 配信サーバ Delivery

    Engine Logs 各サーバで 一次集計(Ruby) 配信サーバ側で一次処理を行い、データを圧縮(数 100MB→数KBに) またapacheのcombineログはパースが遅いので、 ログ形式を工夫することで速度を稼ぐ
  13. © 2011 Scaleout Inc. All right reserved. マージ集計 広告案件データ (PostgreSQL)

    集計管理 システム 各ADSVRで一次集計されたデータをrubyでマージ集計し、 DBに流し込み。 各ADSVRの一次集計後のデータは数10Kなため、 Rubyでも余裕。 Logs Logs Logs Logs Logs
  14. © 2011 Scaleout Inc. All right reserved. 管理DB、UI部分 • DBスキーマは数個のトランザクションテーブル

    と大量のマスタデータの構成 • 大量のマスタ管理画面はほぼ全部 ActiveScaffoldで構築
  15. © 2011 Scaleout Inc. All right reserved. ActiveScaffold++ http://activescaffold.com/ マスタ管理部はほぼ全部これ。

    関連テーブルのUIもコントローラ部を足す ことで勝手にUIを作ってくれる優れもの (ただしRails3には非対応)
  16. © 2011 Scaleout Inc. All right reserved. ActiveScaffold++ class UserController

    < ApplicationController active_scaffold :user do |config| end end これだけの記述で↓こんなのを作ってくれる
  17. © 2011 Scaleout Inc. All right reserved. なぜruby及びRailsを選んだか? 会社立ち上げ当時、開発機のOSはFreeBSDで、 言語はさておき、よいORMを探していた。

    • Catalystだ!→ CPAN地獄にはまり挫折 • PHPだ! → ORMがほぼなかった(当時) • Javaだ! → PHPと同様 • Rails? → インストール一発!AR最高! ということでRailsになりました ぶっちゃけたまたまですが、人にも異様に恵まれて とてもよい選択だったと思います。
  18. © 2011 Scaleout Inc. All right reserved. ご参考: 弊社とrubyistの関係 弊社がスタートアップにもかかわらず、

    いかに人に恵まれているかをご紹介します 今まで手伝ってくれたRubyistの方々 @shachi @maiha @genki @yugui 今手伝ってくれてる&今後手伝ってくれるRubyistの方々 @yuumi3 @a_matsuda @ukstudio
  19. © 2011 Scaleout Inc. All right reserved. まとめ 1. RailsとCで大量配信システムを作りました

    2. アーキテクチャさえしっかりしてればほとんどの部分 はrubyでいけるよ 3. 秘密はあんまりなくやってることは割と普通です
  20. © 2011 Scaleout Inc. All right reserved. メンバー募集中! 1. 大規模配信、大規模解析に興味ある方

    2. Ruby、デザパタが大好きな方 3. 東京の西側よりも東側の下町文化が好きな方 4. 興味ある方は[email protected]まで! 下町で働くのも悪くないですよ