Pro Yearly is on sale from $80 to $50! »

pixivを支える技術 2014

pixivを支える技術 2014

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

003f59d1b2e3b864c744f8eb21f68e82?s=128

Atsushi Takayama

September 04, 2014
Tweet

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

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