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

pixivを支える技術 2014

pixivを支える技術 2014

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

Atsushi Takayama

September 04, 2014
Tweet

More Decks by Atsushi Takayama

Other Decks in Programming

Transcript

  1. pixivを支える技術
    2014

    View Slide

  2. 自己紹介
    ● 高山温
    ○ @edvakf
    ● 2012年の3月に入社しました
    ● pixivチームのリーダーをしています
    ● 最近はグロースチームでpixivのプレミアムやア
    クティブユーザーまわりの数字を追いかける
    他、難しい事をプラットフォームチームにお願い
    するお仕事をしています

    View Slide

  3. pixivという会社
    の事業の1つとしてpixivという
    ウェブサービスがある
    他にはピクシブ百科事典、pixiv comic、BOOTH、
    Cure、World Cosplayなど

    View Slide

  4. ウェブサービスとは
    HTTPを通じて
    ● 情報を格納したり
    ● 情報を取り出すこと
    を特定のロジックに基づいて行うシステムのこと

    View Slide

  5. ウェブサービスに必要なもの
    ● 情報の格納場所
    ● 情報を格納したり取り出すロジック
    ● HTTPでやりとりする仕組み

    View Slide

  6. つまりウェブサービスは
    ● ストレージ
    ● アプリケーション
    ● HTTPサーバー
    で成り立っている

    View Slide

  7. pixivというウェブサービス
    ● ストレージ
    ○ MySQL
    ○ KyotoTycoon
    ○ WebDav (ファイルシステム)
    ○ Apache Solr
    ○ Apache Traffic Server
    ○ (Redis)
    ○ (MongoDB)
    ● HTTPサーバー
    ○ Apache
    ○ nginx
    ● サーバーサイドアプリケーション
    ○ PHP
    ○ (Go)
    ● クライアントサイドアプリケーション
    ○ HTML+JavaScript
    ○ iOSアプリ
    ○ Androidアプリ
    ● バッチ
    ○ PHP
    ○ (C++)
    ○ (Scala)

    View Slide

  8. pixivというアプリケーション
    には
    1. サーバーサイドウェブアプリケーション
    2. クライアントサイドアプリケーション
    3. バッチ
    があり、1と3はほぼすべてPHP
    「バッチもpixivというアプリケーションの重要な一
    部」

    View Slide

  9. ここまでで質問?

    View Slide

  10. Question:
    ● pixivの平均レスポンスタイムは?
    ● MySQLの1 SELECTの時間は?
    ● 1ページにMySQLのクエリは何個?
    ● 100ms
    ● 5ms
    ● 20個

    View Slide

  11. コネクションの確立の時間
    MySQLへのリクエスト1回だけなら5msぐらいだ
    が、同じコネクションで10回リクエストすれば2回目
    からは1〜2msぐらいになる
    →TCPコネクションは少ないほどよい

    View Slide

  12. Question:
    ● 1リクエスト内でCPUを一番使う処理は
    何?
    ● それはどのぐらい時間がかかってる?
    ● テンプレートエン
    ジン
    ● レスポンスタイ
    ムの30%〜40%

    View Slide

  13. つまり
    pixivのサーバーサイドウェブアプリケーションは
    ● MySQLが50%
    ● テンプレートエンジンが40%
    ● KTが5%
    ● その他のCPU処理が5%

    View Slide

  14. フレームワークは?
    pixivはPHPのフレーワークを採用していない。
    最大の理由は、最初に作られたときに
    フレームワークを使ってなかったから。
    フレームワークを使ったらあと50msぐらい
    は増えるし、今からの全面導入は微妙かも。

    View Slide

  15. Aside: DRYにするべきところ
    ● DRY(don't repeat yourself)するかしないか、
    その判断基準について
    ● DRYにしない選択肢もあることを意識している
    ○ DRYにするべきところがDRYになっていないこともある
    のが課題

    View Slide

  16. ここまでで質問?

    View Slide

  17. Question:
    ウェブアプリケーションのレスポンスを
    速く返すのに最も効果的な方法は?

    View Slide

  18. Question:
    ウェブアプリケーションのレスポンスを
    速く返すのに最も効果的な方法は?
    ● インデックスの使われないクエリをなくす
    ● キャッシュする

    View Slide

  19. ウェブアプリのキャッシュ戦略
    キャッシュと言ってもレイヤーも方法も色々
    ● 304 Not Modified
    ● LocalStorage (JavaScript)
    ● KVS (memcached / redis)
    ● Shared Memory Cache
    ● Fragment Cache (Rails)
    ● Proxy Cache (Apache, nginx)

    View Slide

  20. pixivのキャッシュ戦略
    サーバーサイドウェブアプリのレイヤーでは
    ● KyotoTycoon (KT)
    ○ memcachedプロトコルのキャッシュサーバー
    ● APC
    ○ PHPのShared Memory Cache
    ○ アプリケーションサーバーのローカルキャッシュ
    pixiv engineering blog: pixivのデータストア/キャッシュ戦略

    View Slide

  21. その他のpixivのキャッシュ
    ● 304はPHPのリクエストでは返していない
    ○ 投稿画像やCSSなどの静的ファイルには多用
    ● AjaxリクエストをLocalStorageにキャッシュ
    ○ pixivポップボードのキャッシュの仕組みとFacebookのUIの話
    ● MySQLのクエリキャッシュ
    ○ テーブルに更新クエリがあるたびに破棄される
    ○ 更新の多いテーブルでは意図的にオフにしてる
    ● Solrへのリクエストをnginxでキャッシュ

    View Slide

  22. Aside: Solrについて
    ● オープンソースの検索エンジン
    ● MySQLからバッチでSolrに流し込んでいる
    ○ pixivでは唯一Scalaで書かれたコード
    ● PHPからはHTTPで通信
    ○ HTTPはインターネットとのやりとりの他にもミドルウェア
    とのやりとりにも使われる
    ○ HTTPであることで、nginxのような普通のプロキシが使
    える

    View Slide

  23. Question:
    pixivというサービスがキャッシュと相性が悪い理由
    は何?

    View Slide

  24. Question:
    pixivというサービスがキャッシュと相性が悪い理由
    は何?
    ● ロングテールなアクセス
    ● R18見る設定やマイピク限定画像など、1つの
    ビューでも出る要素の組み合わせが複雑
    ● アクセスが多すぎてキャッシュが無くなると一気
    にMySQL(など)にクエリが流れる

    View Slide

  25. ロングテール(80:20の法則)
    全データの20%が80%のアクセスを占める
    →キャッシュのヒット率がとても悪い
    pixivではロングテールなデータは最小限しか
    キャッシュせずにMySQLを直接参照する
    キャッシュしてもKTだけで、APCは使わない

    View Slide

  26. バッチによるキャッシュ(?)生成
    バッチで生成してKTに入れてるデータがある
    ランキング, レコメンデーション, BloomFilter, コンテストデータ, 人気タグ, etc.
    計算量が多い場合や、pixiv本体とは疎結合にした
    い別アプリケーションで、KTのデータだけでpixivと
    つながっているなど
    KTはあくまでもキャッシュなので、いつ消えても全
    部作り直せることに気をつけている

    View Slide

  27. ここまでで質問?

    View Slide

  28. バッチについて
    「バッチもpixivというアプリケーションの重要な一
    部」
    一般に:
    ● 定期的に実行される (cron job)
    ● 無限ループで常に動いている (daemon)
    がある

    View Slide

  29. Question:
    cronの問題点は?

    View Slide

  30. Question:
    cronの問題点は?
    ● rootでないと更新できない
    ● コマンドが失敗したかわかりにくい
    ● コマンドのログが見れない
    ● コマンドの実行履歴が見れない
    ● とにかく面倒!!
    ○ /etc/cron.d/ 以下のファイル名に制約があるとか
    ○ パーミッションに制約があるとか

    View Slide

  31. Jenkins
    元は継続的インテグレーションのためのツールだ
    が、cronの代替としてとても優秀
    ● 登録されているジョブが一覧できる
    ● 現在走っているジョブが一覧できる
    ● ジョブの実行中の標準出力が見られる
    ● ジョブの過去の失敗履歴やログが見られる
    ● ウェブ画面ですべて操作できる

    View Slide

  32. pixivでのJenkins
    CI用途でしか使ってなかったが、今年からcronの
    代替として全面導入
    daemon的な処理もJenkinsで1分おきに実行
    ● 1分したらwhileループを抜ける
    ● デーモンの管理にJenkinsほどの良いツールが
    無いのが理由(の1つ)

    View Slide

  33. ここまでで質問?

    View Slide

  34. MySQL
    サイトの規模が大きくなると必ず行わなければい
    けないこと、それは
    「データベースの系統を分ける」
    ユーザーIDで分割したりデータの日付で分けたり
    することもあるが、pixivではテーブルのアクセス頻
    度や機能ごとに分割している

    View Slide

  35. データベース系統
    ● ユーザー、イラストデータ
    ● 小説
    ● プレミアム関係
    ● ブックマーク
    ● グループ機能
    ● プレミアム向けアクセス解析
    などなど、それぞれにMasterが1台とSlaveが複数
    ある

    View Slide

  36. Question:
    サービスのデータベースが1系統のみであることが
    望ましい理由は?

    View Slide

  37. Question:
    サービスのデータベースが1系統のみであることが
    望ましい理由は?
    ● JOINが使える
    ● トランザクションが使える
    ● ウェブアプリケーションから複数のDBに接続し
    なくてよい

    View Slide

  38. DBまわりで特に意識していること
    ● 最近はJOINはあまりしない方針
    ○ アプリケーションレベルのJOINを多用
    ● ORMは使わない
    ○ 流れるクエリを意識するためにSQLを手書き
    ○ ガチガチにチューニングしたクエリがたくさん
    ● MySQLにアクセスする層とアプリケーションロ
    ジックの層を分離

    View Slide

  39. Aside: pixiv最大のデータベース
    ブックマーク
    ● 12億レコード
    ○ uint32max = 42億
    ● 1年で倍増弱ぐらい
    今後、市販のメモリで収まりきらなくなれば、期間
    で分割なども考える必要があり、更にカオスに…

    View Slide

  40. ここまでで質問?

    View Slide

  41. Question:
    pixivではほぼすべてのユーザーデータはMySQL
    に入れているが、MySQLに入っていないデータは
    何?

    View Slide

  42. Question:
    pixivではほぼすべてのユーザーデータはMySQL
    に入れているが、MySQLに入っていないデータは
    何?
    投稿された画像

    View Slide

  43. 画像ストレージ
    リレーショナルデータベースに入らないファイル
    は、どのサービスもそれぞれの要件に合わせて頭
    をひねる部分
    pixivではWebDAVを採用している
    ● HTTPのGETやPOSTでファイルシステムにア
    クセスするプロトコル
    ● Apacheやnginxのプラグインとして使える

    View Slide

  44. Question:
    画像をMySQLに保存しない理由は?

    View Slide

  45. Question:
    画像をMySQLに保存しない理由は?
    ● ファイルあたりのサイズが大きい
    ● 総容量も多い(40TB)
    ● 配信するときにApacheやnginxが直接読める
    ファイル単位としてある方が便利
    ● 管理上もファイルとしてあるほうがSQLを書いて
    取り出すよりラク

    View Slide

  46. pixivの画像の特徴
    ● 1つ1つが手作りなので写真と違って増えるスピードは速くな

    ● PC、スマホ、ガラケーなどがあり、生成するサムネイルの種
    類が多い
    ● 漫画の枠や、正方形クロップ時の特殊な変換
    ● 変換後も同じファイルフォーマット
    ○ なんでそうしてしまったのか…
    ● 数々の歴史的経緯…
    ● 最近ではうごイラも

    View Slide

  47. pixivの画像変換
    ● 昔はすべてのサムネイルを投稿時に変換して保存
    ● 非同期アップロード化(2009)
    ○ pixivの画像アップロードシステム
    ● mod_small_lightで配信時に動的変換
    ○ ただしリクエストの多いサムネイルは静的サムネイルのまま
    ○ YAPC::Asia 2012「pixivのサムネイル事情」
    ● サムネイルマスター(2014)
    ○ サムネイル生成元となる大きめのサムネイルをJPEGで用意
    ● サムネイル変換クラスター (2014)
    ○ https://github.com/pixiv/go-thumber
    ○ 近日稼働予定!

    View Slide

  48. 画像配信
    pixivというウェブアプリケーションと
    pixivの画像ストレージ、配信はまあまあ疎結合
    →今後はもっと疎結合にしていきたい
    理想はAmazon S3のように、ファイルをPOSTする
    とURLが返ってくるぐらいのブラックボックスにして
    いきたい
    詳しくはインフラのところで話されるかも?

    View Slide

  49. ここまでで質問?

    View Slide

  50. そろそろまとめ
    主にpixivのサーバーサイドアプリケーションを、ス
    トレージとキャッシュに注目して見ていきました。
    pixivならではのパフォーマンス上の問題や
    アプリケーションの制約について
    いくつか紹介しました。

    View Slide

  51. 今日話さなかったこと
    ● 個別機能にまつわる話
    ● クライアントサイドの話
    ● デプロイの話
    ● テストの話
    ● グロースチームのエンジニアとしての話
    その他いっぱい
    →興味があればあとで質問歓迎

    View Slide