YAPC::Asia 2008 Tokyo - Pathtraq - building a computation-centric web service

Slide 1: Pathtraq Building a computation-centric web service Cybozu Labs Kazuho Oku

Slide 2: Self Introduction ( 自己紹介 ) Name: Kazuho Oku  名前 : 奥 一穂 Joined Cybozu Labs in 2005  2005 年からサイボウズ・ラボ勤務 R&D of web-related technologies  Web 関連技術の研究開発が仕事 Developer of Xiino (Palmscape), Japanize  Xiino (Palmscape), Japanize の開発者 2008年5月16日 Pathtraq - building a computation-centric web service 2

Slide 3: The Long Tail of the Internet インターネットのロングテール 2008年5月16日 Pathtraq - building a computation-centric web service 3

Slide 4: The Long Tail of the Internet (cont.) 1000000 100000 10000 1000 ﾃqﾃbﾃgﾐﾔ 100 10 1 1 10 100 1000 10000 100000 1000000 10000000 URLﾐﾔ 2008年5月16日 Pathtraq - building a computation-centric web service 4

Slide 5: The Long Tail of the Internet (cont.) -0.44 y=C ・ x Number of pages with 1/10 hits: ×2.75  ヒット数が 1/10 のページは 2.75 倍存在 2008年5月16日 Pathtraq - building a computation-centric web service 5

Slide 6: Introduction of Pathtraq (Pathtraq の紹介 ) Alexa-like web access stats service  Alexa のようなウェブアクセス統計サービス Per-page, realtime stats ページ単位のリアルタイム統計 Extracts and displays what is hot ホットな情報を抽出して表示 2008年5月16日 Pathtraq - building a computation-centric web service 6

Slide 7: Introduction of Pathtraq (cont.) Demo 2008年5月16日 Pathtraq - building a computation-centric web service 7

Slide 8: Introduction of Pathtraq (cont.) Active sample users: 6,300  サンプルユーザー数 : 6,300 # of accesses collected: 100M (1M/day)  アクセスの収集数 : 1 億件 (100 万件 / 日 ) # of URLs stored: >40M  保存されている URL の個数 : 4000 万以上 Data Size: 100GB  データサイズ : 100GB 2008年5月16日 Pathtraq - building a computation-centric web service 8

Slide 9: To Scale Out or Not ( スケールアウトの是非 ) Depends on CPU / storage cost  CPU やストレージのコストに依存する Overhead of scaling out depends on app. アプリケーションによってはスケールアウトによ るオーバーヘッドが発生 32GB-64GB per server is today’s sweet spot for memory intensive services メモリインテンシヴなサービスではサーバあたり 32GB-64GB のメモリ容量が最安 2008年5月16日 Pathtraq - building a computation-centric web service 9

Slide 10: Data Size vs. Moore’s Law Data Size Moore's Law 1 2 3 4 5 6 7 8 9 10 Year 2008年5月16日 Pathtraq - building a computation-centric web service 10

Slide 11: Data Size vs. Moore’s Law (cont.) Data Size Moore's Law System Cost 1 2 3 4 5 6 7 8 9 10 Year 2008年5月16日 Pathtraq - building a computation-centric web service 11

Slide 12: Data Size vs. Moore’s Law (cont.) Assume data size is proportional to years of operation データサイズが運用年数に比例する場合 Software-based optimization is only necessary for first three years 最適化は最初の３年間だけ考えればいい After then, Moore’s Law becomes dominant その後はムーアの法則が支配的になる 2008年5月16日 Pathtraq - building a computation-centric web service 12

Slide 13: Scaling: Our Choice Requirement of first year: 24GB mem.  初年度の必要メモリ量 : 24GB Overhead expected if scaled out ↓ No distributed database データベースの分割は行わない Export some tasks to other servers タスク単位で別サーバへ移動 2008年5月16日 Pathtraq - building a computation-centric web service 13

Slide 14: Hardware of Pathtraq Main Server (1U)  Opteron 2218 x2, 32GB Mem, 500GB HDD  MySQL 5.1, Apache, etc. Helper Servers  Web Content Analysis (Web コンテンツの分析 )  Full-text Search ( 全文検索 ) 2008年5月16日 Pathtraq - building a computation-centric web service 14

Slide 15: Technical Problems of Pathtraq Compression for size & speed 圧縮による省メモリ化と高速化  Log analysis requires fast random access 高速なランダムアクセスが必要  HDD is toooooo slow ( 〜 3MB/sec.) HDD はランダムアクセスが遅すぎる  Main tables need to be on memory 主要テーブルはオンメモリが MUST 2008年5月16日 Pathtraq - building a computation-centric web service 15

Slide 16: Technical Problems of Pathtraq (cont.) Query caching  Log analysis is heavy task ログ分析は重たい  Need for sophisticated cache control 高度なキャッシュコントロールが必要 Fast and trustable message queues 高速で信頼できるメッセージキュー 2008年5月16日 Pathtraq - building a computation-centric web service 16

Slide 17: Compression for Size and Speed サイズと速度のための圧縮 2008年5月16日 Pathtraq - building a computation-centric web service 17

Slide 18: Facts re Compression ( 圧縮関連の現状） # of access logs stored: 100M  保存されているアクセスログ : 約１億件 A single access log: (url,referer,when)  アクセスログ : (url,referer, 日時 ) Average length of URL: 70byes  URL の平均バイト数 : 70 バイト 2008年5月16日 Pathtraq - building a computation-centric web service 18

Slide 19: URL Compression (URL の圧縮 ) URLs can be compressed  URL は圧縮可能  http://www.example.com/foobar.html But too short for gzip (deflate)  gzip (deflate) には短すぎる Need for a compression algorithm using prior knowledge 事前知識を使用した圧縮アルゴリズムが必要 2008年5月16日 Pathtraq - building a computation-centric web service 19

Slide 20: URL Compression (cont.) Should be searchable in compressed- form, or we cannot use indexes 圧縮状態のまま、インデックスを利用して検索で きる必要がある 2008年5月16日 Pathtraq - building a computation-centric web service 20

Slide 21: URL Compression: Static PPM PPM: Prediction by Partial Matching  Used by 7-zip, etc. (7-zip 等で使用 ) Use range coder as backend  Original collation order can be preserved レンジコーダと組み合わせることで文字集合の順 序を保ったまま圧縮できる 2008年5月16日 Pathtraq - building a computation-centric web service 21

Slide 22: URL Compression in Pathtraq Impl. as MySQL UDFs  MySQL UDF として実装 Original Query: url like “http://example.com/%” Query for compressed URL: compress(“http://…/”)<=curl and curl<compress(“http://…0”) Search in compressed form is faster  圧縮版の方が高速に検索可能 2008年5月16日 Pathtraq - building a computation-centric web service 22

Slide 23: URL Compression in Pathtraq (cont.) Size of prior knowledge: 4MB  事前知識のサイズ : 4MB Compression ratio: 37%  圧縮率 : 37% Compression speed: 40MB/sec. Decompression speed: 19.3MB/sec.  Optimized using SSE (SSE で最適化 ) 2008年5月16日 Pathtraq - building a computation-centric web service 23

Slide 24: Using Together with InnoDB Plugin InnoDB Plugin  released May 2008 (2008 年 5 月リリース )  supports per-page compression using deflate Deflate を使用した DB のページ単位圧縮を実現  mainly for optimizing disk-based databases ディスクベースのデータベース最適化に好適 2008年5月16日 Pathtraq - building a computation-centric web service 24

Slide 25: Using Together with InnoDB Plugin (cont.) Table size becomes smallest when both compressions are applied 両者の併用で高率の圧縮が可能 Compression Ratio N/A 100% URL compression 57% InnoDB compression 50% using both 33% 2008年5月16日 Pathtraq - building a computation-centric web service 25

Slide 26: Counter Compression ( カウンタの圧縮 ) Counter is a list of (hit_count,time)  カウンタは ( ヒット数 , 日時 ) のリスト Time granularity is 1 hour 日時の分解能は１時間 Compressed as a sparse array, stored as a blob in DB  スパースアレイとして圧縮し、 blob として DB に保存 2008年5月16日 Pathtraq - building a computation-centric web service 26

Slide 27: Counter Compression (cont.) Accessors impl. as MySQL UDFs  MySQL UDF としてアクセサを実装 Accessors decompress sparse arrays and perform vector operations within MySQL  アクセサは粗行列を展開して MySQL 内でベクタ 演算を実行 Fewer rows lead to smaller footprint and faster speed 行数の減少による省メモリ化と高速化 2008年5月16日 Pathtraq - building a computation-centric web service 27

Slide 28: Query Caching クエリキャッシュ 2008年5月16日 Pathtraq - building a computation-centric web service 28

Slide 29: Facts re Query Caching Log analysis is aggregation ログ分析は集約演算 Aggregation is heavy task 集約演算は重たい Some queries are repeated very often 一部のクエリが頻発 2008年5月16日 Pathtraq - building a computation-centric web service 29

Slide 30: KeyedMutex An interprocess mutex impl’ed as a tiny server/client system  プロセス間 Mutex を実現するサーバ Used to prevent equiv. queries from being sent to MySQL at the same time  MySQL へ同時に同一クエリを行わないために利 用 Query results shared using Cache::Swifty  クエリ結果は Cache::Swifty で共有 2008年5月16日 Pathtraq - building a computation-centric web service 30

Slide 31: Cache::Swifty  A very fast cache using mmap’ed files, optimized for read performance  mmap されたファイル群を利用する高速キャッシュ、特 に read が速い  Lock-free reads, flock’ed writes  lock-free の読み込みと flock を利用した書き込み  Robust futexes might be usable to optimize write performance on recent linux kernels  Robust futexes を使えば書込パフォーマンスも上がるか も 2008年5月16日 Pathtraq - building a computation-centric web service 31

Slide 32: Cache::Swifty (cont.) 70 times faster for 16 bytes reads than Cache::Memcached  16 バイトの読込だと Cache::Memcached の 70 倍速 Suitable for caching data on a single server without re-designing the app. 単一サーバ上でデータをキャッシュする際に簡単 に利用できる（透過的に追加できる ) 2008年5月16日 Pathtraq - building a computation-centric web service 32

Slide 33: Cache::Swifty (cont.) Has a feature that notifies a single client to update requested cached data sometime before the cached entry actually expires キャッシュエントリがエクスパイヤする前に、ク ライアントのうちひとつだけに対して更新を推奨 できる Prevents thundering herd upon cache expiration エクスパイヤに伴うブロックを抑制 2008年5月16日 Pathtraq - building a computation-centric web service 33

Slide 34: Filter::SQL Pathtraq is heavily dependent on SQL  Pathtraq の開発においては SQL が中心 Perl code is basically a glue  Perl コードは glue としての役割が大きい DBI (and others) is too complicated for writing glue code  DBI その他はグルーコードを書くには複雑すぎる 2008年5月16日 Pathtraq - building a computation-centric web service 34

Slide 35: Filter::SQL (cont.) Embedded SQL in perl style  Perl で書きやすい形の埋め込み SQL EXEC INSERT INTO speakers (surname,firstname) VALUES (’oku’, ’kazuho’); $sn = ‘oku’; for my $r (SELECT firstname FROM speakers WHERE surname=$sn;) { print “$r->[0]n”; # kazuho } 2008年5月16日 Pathtraq - building a computation-centric web service 35

Slide 36: Fast and Trustable Message Queues 高速で信頼できるメッセージキュー 2008年5月16日 Pathtraq - building a computation-centric web service 36

Slide 37: Facts re Message Queues Used for transferring content analysis requests and responses コンテンツ解析処理を委譲するために使用 Polling a 40M row table is heavy  4000 万行のテーブルを poll するのは重たい Need for a proper message queue ちゃんとしたメッセージキューが必要 2008年5月16日 Pathtraq - building a computation-centric web service 37

Slide 38: Q4M A Pluggable Storage Engine for MySQL 5.1  MySQL 5.1 のプラガブルストレージエンジン Looks like an ordinal SQL table, has a special mode to operate as MQ  一見通常の SQL テーブルだが、 MQ として動作 するモードがある 2008年5月16日 Pathtraq - building a computation-centric web service 38

Slide 39: Features of Q4M Trustable ( 高信頼性 )  Every operation is fsync’ed to disk すべての操作がディスクへ fsync される Fast ( 高速性 )  >10,000 mess./sec. on Opteron 2218 x 2 Trustable forwarding between queues キュー間の信頼できる転送機能  no losses or duplicates on network failure ネットワーク障害時にもデータロスや複製が発生しな い 2008年5月16日 Pathtraq - building a computation-centric web service 39

Slide 40: Q4M: Sample Code Queue Submission: INSERT INTO mq (mess) VALUES (‘hello’); Queue Subscription: while (1) { next unless SELECT ROW queue_wait(‘mq’);; my $mess = SELECT ROW mess FROM mq;; …. SELECT ROW queue_end(‘mq’);; } 2008年5月16日 Pathtraq - building a computation-centric web service 40

Slide 41: Q4M: Sample Code (cont.) A wrapper module (Queue::Q4M) is available as well  ラッパーモジュール (Queue::Q4M) もあります 2008年5月16日 Pathtraq - building a computation-centric web service 41

Slide 42: Q4M in Pathtraq Used for transferring content analysis requests and responses コンテンツ解析処理を委譲するために使用 Exchanging data between servers located in different iDCs, over SSL-encrypted MySQL connection, between ruby and perl  異なる iDC 間でのデータ交換に、 SSL 暗号化さ れた MySQL 接続を使い、 ruby と perl 間でデ ータ交換 Pathtraq - building a computation-centric web service 42 2008年5月16日

Slide 43: Conclusion まとめ 2008年5月16日 Pathtraq - building a computation-centric web service 43

Slide 44: Keywords were… ( でてきたキーワード ) Data compression is important MySQL UDF Caching and Mutexes Embedded SQL in Perl Message Queues 2008年5月16日 Pathtraq - building a computation-centric web service 44

Slide 45: For More Information See http://labs.cybozu.co.jp/blog/kazuho/ 2008年5月16日 Pathtraq - building a computation-centric web service 45

Slide 46: Thanks to For all the code we use  CPAN modules authors and OSS developers  The Developers of Senna and Tritonn  Daisuke Maki-san (CPAN ID: dmaki) for Gungho and Queue::Q4M  Members of Cybozu Labs Others who gave us advises and lastly but mostly, to the users of Pathtraq (Pathtraq のユーザーのみなさん、ありがとうございます ) 2008年5月16日 Pathtraq - building a computation-centric web service 46