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. 今日話さなかったこと • 個別機能にまつわる話 • クライアントサイドの話 • デプロイの話 • テストの話 •

    グロースチームのエンジニアとしての話 その他いっぱい →興味があればあとで質問歓迎