pixivを支える技術 2014

インターンシップの学生向けの講義資料です。

Transcript

1. pixivを支える技術 2014
2. 自己紹介 • 高山温 ◦ @edvakf • 2012年の3月に入社しました • pixivチームのリーダーをしています • 最近はグロースチームでpixivのプレミアムやア クティブユーザーまわりの数字を追いかける 他、難しい事をプラットフォームチームにお願い するお仕事をしています
3. pixivという会社 の事業の1つとしてpixivという ウェブサービスがある 他にはピクシブ百科事典、pixiv comic、BOOTH、 Cure、World Cosplayなど
4. ウェブサービスとは HTTPを通じて • 情報を格納したり • 情報を取り出すこと を特定のロジックに基づいて行うシステムのこと
5. ウェブサービスに必要なもの • 情報の格納場所 • 情報を格納したり取り出すロジック • HTTPでやりとりする仕組み
6. つまりウェブサービスは • ストレージ • アプリケーション • HTTPサーバー で成り立っている
7. pixivというウェブサービス • ストレージ ◦ MySQL ◦ KyotoTycoon ◦ WebDav (ファイルシステム) ◦ Apache Solr ◦ Apache Traffic Server ◦ (Redis) ◦ (MongoDB) • HTTPサーバー ◦ Apache ◦ nginx • サーバーサイドアプリケーション ◦ PHP ◦ (Go) • クライアントサイドアプリケーション ◦ HTML+JavaScript ◦ iOSアプリ ◦ Androidアプリ • バッチ ◦ PHP ◦ (C++) ◦ (Scala)
8. pixivというアプリケーション には 1. サーバーサイドウェブアプリケーション 2. クライアントサイドアプリケーション 3. バッチ があり、1と3はほぼすべてPHP 「バッチもpixivというアプリケーションの重要な一 部」
9. ここまでで質問？
10. Question: • pixivの平均レスポンスタイムは？ • MySQLの1 SELECTの時間は？ • 1ページにMySQLのクエリは何個？ • 100ms • 5ms • 20個
11. コネクションの確立の時間 MySQLへのリクエスト1回だけなら5msぐらいだ が、同じコネクションで10回リクエストすれば2回目 からは1〜2msぐらいになる →TCPコネクションは少ないほどよい
12. Question: • 1リクエスト内でCPUを一番使う処理は 何？ • それはどのぐらい時間がかかってる？ • テンプレートエン ジン • レスポンスタイ ムの30%〜40%
13. つまり pixivのサーバーサイドウェブアプリケーションは • MySQLが50% • テンプレートエンジンが40% • KTが5% • その他のCPU処理が5%
14. フレームワークは？ pixivはPHPのフレーワークを採用していない。 最大の理由は、最初に作られたときに フレームワークを使ってなかったから。 フレームワークを使ったらあと50msぐらい は増えるし、今からの全面導入は微妙かも。
15. Aside: DRYにするべきところ • DRY(don't repeat yourself)するかしないか、 その判断基準について • DRYにしない選択肢もあることを意識している ◦ DRYにするべきところがDRYになっていないこともある のが課題
16. ここまでで質問？
17. Question: ウェブアプリケーションのレスポンスを 速く返すのに最も効果的な方法は？
18. Question: ウェブアプリケーションのレスポンスを 速く返すのに最も効果的な方法は？ • インデックスの使われないクエリをなくす • キャッシュする
19. ウェブアプリのキャッシュ戦略 キャッシュと言ってもレイヤーも方法も色々 • 304 Not Modified • LocalStorage (JavaScript) • KVS (memcached / redis) • Shared Memory Cache • Fragment Cache (Rails) • Proxy Cache (Apache, nginx)
20. pixivのキャッシュ戦略 サーバーサイドウェブアプリのレイヤーでは • KyotoTycoon (KT) ◦ memcachedプロトコルのキャッシュサーバー • APC ◦ PHPのShared Memory Cache ◦ アプリケーションサーバーのローカルキャッシュ pixiv engineering blog: pixivのデータストア/キャッシュ戦略
21. その他のpixivのキャッシュ • 304はPHPのリクエストでは返していない ◦ 投稿画像やCSSなどの静的ファイルには多用 • AjaxリクエストをLocalStorageにキャッシュ ◦ pixivポップボードのキャッシュの仕組みとFacebookのUIの話 • MySQLのクエリキャッシュ ◦ テーブルに更新クエリがあるたびに破棄される ◦ 更新の多いテーブルでは意図的にオフにしてる • Solrへのリクエストをnginxでキャッシュ
22. Aside: Solrについて • オープンソースの検索エンジン • MySQLからバッチでSolrに流し込んでいる ◦ pixivでは唯一Scalaで書かれたコード • PHPからはHTTPで通信 ◦ HTTPはインターネットとのやりとりの他にもミドルウェア とのやりとりにも使われる ◦ HTTPであることで、nginxのような普通のプロキシが使 える
23. Question: pixivというサービスがキャッシュと相性が悪い理由 は何？
24. Question: pixivというサービスがキャッシュと相性が悪い理由 は何？ • ロングテールなアクセス • R18見る設定やマイピク限定画像など、1つの ビューでも出る要素の組み合わせが複雑 • アクセスが多すぎてキャッシュが無くなると一気 にMySQL（など）にクエリが流れる
25. ロングテール（80:20の法則） 全データの20%が80%のアクセスを占める →キャッシュのヒット率がとても悪い pixivではロングテールなデータは最小限しか キャッシュせずにMySQLを直接参照する キャッシュしてもKTだけで、APCは使わない
26. バッチによるキャッシュ(?)生成 バッチで生成してKTに入れてるデータがある ランキング, レコメンデーション, BloomFilter, コンテストデータ, 人気タグ, etc. 計算量が多い場合や、pixiv本体とは疎結合にした い別アプリケーションで、KTのデータだけでpixivと つながっているなど KTはあくまでもキャッシュなので、いつ消えても全 部作り直せることに気をつけている
27. ここまでで質問？
28. バッチについて 「バッチもpixivというアプリケーションの重要な一 部」 一般に: • 定期的に実行される (cron job) • 無限ループで常に動いている (daemon) がある
29. Question: cronの問題点は？
30. Question: cronの問題点は？ • rootでないと更新できない • コマンドが失敗したかわかりにくい • コマンドのログが見れない • コマンドの実行履歴が見れない • とにかく面倒！！ ◦ /etc/cron.d/ 以下のファイル名に制約があるとか ◦ パーミッションに制約があるとか
31. Jenkins 元は継続的インテグレーションのためのツールだ が、cronの代替としてとても優秀 • 登録されているジョブが一覧できる • 現在走っているジョブが一覧できる • ジョブの実行中の標準出力が見られる • ジョブの過去の失敗履歴やログが見られる • ウェブ画面ですべて操作できる
32. pixivでのJenkins CI用途でしか使ってなかったが、今年からcronの 代替として全面導入 daemon的な処理もJenkinsで1分おきに実行 • 1分したらwhileループを抜ける • デーモンの管理にJenkinsほどの良いツールが 無いのが理由（の1つ）
33. ここまでで質問？
34. MySQL サイトの規模が大きくなると必ず行わなければい けないこと、それは 「データベースの系統を分ける」 ユーザーIDで分割したりデータの日付で分けたり することもあるが、pixivではテーブルのアクセス頻 度や機能ごとに分割している
35. データベース系統 • ユーザー、イラストデータ • 小説 • プレミアム関係 • ブックマーク • グループ機能 • プレミアム向けアクセス解析 などなど、それぞれにMasterが1台とSlaveが複数 ある
36. Question: サービスのデータベースが1系統のみであることが 望ましい理由は？
37. Question: サービスのデータベースが1系統のみであることが 望ましい理由は？ • JOINが使える • トランザクションが使える • ウェブアプリケーションから複数のDBに接続し なくてよい
38. DBまわりで特に意識していること • 最近はJOINはあまりしない方針 ◦ アプリケーションレベルのJOINを多用 • ORMは使わない ◦ 流れるクエリを意識するためにSQLを手書き ◦ ガチガチにチューニングしたクエリがたくさん • MySQLにアクセスする層とアプリケーションロ ジックの層を分離
39. Aside: pixiv最大のデータベース ブックマーク • 12億レコード ◦ uint32max = 42億 • 1年で倍増弱ぐらい 今後、市販のメモリで収まりきらなくなれば、期間 で分割なども考える必要があり、更にカオスに…
40. ここまでで質問？
41. Question: pixivではほぼすべてのユーザーデータはMySQL に入れているが、MySQLに入っていないデータは 何？
42. Question: pixivではほぼすべてのユーザーデータはMySQL に入れているが、MySQLに入っていないデータは 何？ 投稿された画像
43. 画像ストレージ リレーショナルデータベースに入らないファイル は、どのサービスもそれぞれの要件に合わせて頭 をひねる部分 pixivではWebDAVを採用している • HTTPのGETやPOSTでファイルシステムにア クセスするプロトコル • Apacheやnginxのプラグインとして使える
44. Question: 画像をMySQLに保存しない理由は？
45. Question: 画像をMySQLに保存しない理由は？ • ファイルあたりのサイズが大きい • 総容量も多い（40TB） • 配信するときにApacheやnginxが直接読める ファイル単位としてある方が便利 • 管理上もファイルとしてあるほうがSQLを書いて 取り出すよりラク
46. pixivの画像の特徴 • 1つ1つが手作りなので写真と違って増えるスピードは速くな い • PC、スマホ、ガラケーなどがあり、生成するサムネイルの種 類が多い • 漫画の枠や、正方形クロップ時の特殊な変換 • 変換後も同じファイルフォーマット ◦ なんでそうしてしまったのか… • 数々の歴史的経緯… • 最近ではうごイラも
47. pixivの画像変換 • 昔はすべてのサムネイルを投稿時に変換して保存 • 非同期アップロード化（2009） ◦ pixivの画像アップロードシステム • mod_small_lightで配信時に動的変換 ◦ ただしリクエストの多いサムネイルは静的サムネイルのまま ◦ YAPC::Asia 2012「pixivのサムネイル事情」 • サムネイルマスター（2014） ◦ サムネイル生成元となる大きめのサムネイルをJPEGで用意 • サムネイル変換クラスター (2014) ◦ https://github.com/pixiv/go-thumber ◦ 近日稼働予定！
48. 画像配信 pixivというウェブアプリケーションと pixivの画像ストレージ、配信はまあまあ疎結合 →今後はもっと疎結合にしていきたい 理想はAmazon S3のように、ファイルをPOSTする とURLが返ってくるぐらいのブラックボックスにして いきたい 詳しくはインフラのところで話されるかも？
49. ここまでで質問？
50. そろそろまとめ 主にpixivのサーバーサイドアプリケーションを、ス トレージとキャッシュに注目して見ていきました。 pixivならではのパフォーマンス上の問題や アプリケーションの制約について いくつか紹介しました。
51. 今日話さなかったこと • 個別機能にまつわる話 • クライアントサイドの話 • デプロイの話 • テストの話 • グロースチームのエンジニアとしての話 その他いっぱい →興味があればあとで質問歓迎