Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
pixivを支える技術 2014
Search
Atsushi Takayama
September 04, 2014
Programming
17
9.7k
pixivを支える技術 2014
インターンシップの学生向けの講義資料です。
Atsushi Takayama
September 04, 2014
Tweet
Share
More Decks by Atsushi Takayama
See All by Atsushi Takayama
最高の開発者体験の追求が開発生産性を改善し続ける文化を生み出した話
edvakf
3
1k
NeurIPS 2021 論文読み会: How Modular should Neural Module Networks Be for Systematic Generalization?
edvakf
0
120
8年物のJavaのシステムをKotlinに変えていく選択に至るまで
edvakf
2
1k
ピクシブ社内のImageFlux利用事例紹介
edvakf
1
2.7k
学びの文化を育む社内読書会のススメ
edvakf
0
210
フルCDNアーキテクチャでサービス設計した話
edvakf
5
3.7k
Goでバイナリを読む+α
edvakf
1
880
お前はこれまでに作ったAPIの数を覚えているのか?
edvakf
0
2.4k
「ふつうのRailsアプリケーション」についての考え方
edvakf
2
750
Other Decks in Programming
See All in Programming
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
6
1.7k
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
1k
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.4k
RubyLSPのマルチバイト文字対応
notfounds
0
120
What’s New in Compose Multiplatform - A Live Tour (droidcon London 2024)
zsmb
1
470
macOS でできる リアルタイム動画像処理
biacco42
9
2.4k
Laravel や Symfony で手っ取り早く OpenAPI のドキュメントを作成する
azuki
2
110
弊社の「意識チョット低いアーキテクチャ」10選
texmeijin
5
24k
イベント駆動で成長して委員会
happymana
1
320
距離関数を極める! / SESSIONS 2024
gam0022
0
280
Jakarta Concurrencyによる並行処理プログラミングの始め方 (JJUG CCC 2024 Fall)
tnagao7
1
290
OSSで起業してもうすぐ10年 / Open Source Conference 2024 Shimane
furukawayasuto
0
100
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Code Reviewing Like a Champion
maltzj
520
39k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Making the Leap to Tech Lead
cromwellryan
133
8.9k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
How GitHub (no longer) Works
holman
310
140k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
How STYLIGHT went responsive
nonsquared
95
5.2k
Transcript
pixivを支える技術 2014
自己紹介 • 高山温 ◦ @edvakf • 2012年の3月に入社しました • pixivチームのリーダーをしています •
最近はグロースチームでpixivのプレミアムやア クティブユーザーまわりの数字を追いかける 他、難しい事をプラットフォームチームにお願い するお仕事をしています
pixivという会社 の事業の1つとしてpixivという ウェブサービスがある 他にはピクシブ百科事典、pixiv comic、BOOTH、 Cure、World Cosplayなど
ウェブサービスとは HTTPを通じて • 情報を格納したり • 情報を取り出すこと を特定のロジックに基づいて行うシステムのこと
ウェブサービスに必要なもの • 情報の格納場所 • 情報を格納したり取り出すロジック • HTTPでやりとりする仕組み
つまりウェブサービスは • ストレージ • アプリケーション • HTTPサーバー で成り立っている
pixivというウェブサービス • ストレージ ◦ MySQL ◦ KyotoTycoon ◦ WebDav (ファイルシステム)
◦ Apache Solr ◦ Apache Traffic Server ◦ (Redis) ◦ (MongoDB) • HTTPサーバー ◦ Apache ◦ nginx • サーバーサイドアプリケーション ◦ PHP ◦ (Go) • クライアントサイドアプリケーション ◦ HTML+JavaScript ◦ iOSアプリ ◦ Androidアプリ • バッチ ◦ PHP ◦ (C++) ◦ (Scala)
pixivというアプリケーション には 1. サーバーサイドウェブアプリケーション 2. クライアントサイドアプリケーション 3. バッチ があり、1と3はほぼすべてPHP 「バッチもpixivというアプリケーションの重要な一
部」
ここまでで質問?
Question: • pixivの平均レスポンスタイムは? • MySQLの1 SELECTの時間は? • 1ページにMySQLのクエリは何個? • 100ms
• 5ms • 20個
コネクションの確立の時間 MySQLへのリクエスト1回だけなら5msぐらいだ が、同じコネクションで10回リクエストすれば2回目 からは1〜2msぐらいになる →TCPコネクションは少ないほどよい
Question: • 1リクエスト内でCPUを一番使う処理は 何? • それはどのぐらい時間がかかってる? • テンプレートエン ジン •
レスポンスタイ ムの30%〜40%
つまり pixivのサーバーサイドウェブアプリケーションは • MySQLが50% • テンプレートエンジンが40% • KTが5% • その他のCPU処理が5%
フレームワークは? pixivはPHPのフレーワークを採用していない。 最大の理由は、最初に作られたときに フレームワークを使ってなかったから。 フレームワークを使ったらあと50msぐらい は増えるし、今からの全面導入は微妙かも。
Aside: DRYにするべきところ • DRY(don't repeat yourself)するかしないか、 その判断基準について • DRYにしない選択肢もあることを意識している ◦
DRYにするべきところがDRYになっていないこともある のが課題
ここまでで質問?
Question: ウェブアプリケーションのレスポンスを 速く返すのに最も効果的な方法は?
Question: ウェブアプリケーションのレスポンスを 速く返すのに最も効果的な方法は? • インデックスの使われないクエリをなくす • キャッシュする
ウェブアプリのキャッシュ戦略 キャッシュと言ってもレイヤーも方法も色々 • 304 Not Modified • LocalStorage (JavaScript) •
KVS (memcached / redis) • Shared Memory Cache • Fragment Cache (Rails) • Proxy Cache (Apache, nginx)
pixivのキャッシュ戦略 サーバーサイドウェブアプリのレイヤーでは • KyotoTycoon (KT) ◦ memcachedプロトコルのキャッシュサーバー • APC ◦
PHPのShared Memory Cache ◦ アプリケーションサーバーのローカルキャッシュ pixiv engineering blog: pixivのデータストア/キャッシュ戦略
その他のpixivのキャッシュ • 304はPHPのリクエストでは返していない ◦ 投稿画像やCSSなどの静的ファイルには多用 • AjaxリクエストをLocalStorageにキャッシュ ◦ pixivポップボードのキャッシュの仕組みとFacebookのUIの話 •
MySQLのクエリキャッシュ ◦ テーブルに更新クエリがあるたびに破棄される ◦ 更新の多いテーブルでは意図的にオフにしてる • Solrへのリクエストをnginxでキャッシュ
Aside: Solrについて • オープンソースの検索エンジン • MySQLからバッチでSolrに流し込んでいる ◦ pixivでは唯一Scalaで書かれたコード • PHPからはHTTPで通信
◦ HTTPはインターネットとのやりとりの他にもミドルウェア とのやりとりにも使われる ◦ HTTPであることで、nginxのような普通のプロキシが使 える
Question: pixivというサービスがキャッシュと相性が悪い理由 は何?
Question: pixivというサービスがキャッシュと相性が悪い理由 は何? • ロングテールなアクセス • R18見る設定やマイピク限定画像など、1つの ビューでも出る要素の組み合わせが複雑 • アクセスが多すぎてキャッシュが無くなると一気
にMySQL(など)にクエリが流れる
ロングテール(80:20の法則) 全データの20%が80%のアクセスを占める →キャッシュのヒット率がとても悪い pixivではロングテールなデータは最小限しか キャッシュせずにMySQLを直接参照する キャッシュしてもKTだけで、APCは使わない
バッチによるキャッシュ(?)生成 バッチで生成してKTに入れてるデータがある ランキング, レコメンデーション, BloomFilter, コンテストデータ, 人気タグ, etc. 計算量が多い場合や、pixiv本体とは疎結合にした い別アプリケーションで、KTのデータだけでpixivと
つながっているなど KTはあくまでもキャッシュなので、いつ消えても全 部作り直せることに気をつけている
ここまでで質問?
バッチについて 「バッチもpixivというアプリケーションの重要な一 部」 一般に: • 定期的に実行される (cron job) • 無限ループで常に動いている
(daemon) がある
Question: cronの問題点は?
Question: cronの問題点は? • rootでないと更新できない • コマンドが失敗したかわかりにくい • コマンドのログが見れない • コマンドの実行履歴が見れない
• とにかく面倒!! ◦ /etc/cron.d/ 以下のファイル名に制約があるとか ◦ パーミッションに制約があるとか
Jenkins 元は継続的インテグレーションのためのツールだ が、cronの代替としてとても優秀 • 登録されているジョブが一覧できる • 現在走っているジョブが一覧できる • ジョブの実行中の標準出力が見られる •
ジョブの過去の失敗履歴やログが見られる • ウェブ画面ですべて操作できる
pixivでのJenkins CI用途でしか使ってなかったが、今年からcronの 代替として全面導入 daemon的な処理もJenkinsで1分おきに実行 • 1分したらwhileループを抜ける • デーモンの管理にJenkinsほどの良いツールが 無いのが理由(の1つ)
ここまでで質問?
MySQL サイトの規模が大きくなると必ず行わなければい けないこと、それは 「データベースの系統を分ける」 ユーザーIDで分割したりデータの日付で分けたり することもあるが、pixivではテーブルのアクセス頻 度や機能ごとに分割している
データベース系統 • ユーザー、イラストデータ • 小説 • プレミアム関係 • ブックマーク •
グループ機能 • プレミアム向けアクセス解析 などなど、それぞれにMasterが1台とSlaveが複数 ある
Question: サービスのデータベースが1系統のみであることが 望ましい理由は?
Question: サービスのデータベースが1系統のみであることが 望ましい理由は? • JOINが使える • トランザクションが使える • ウェブアプリケーションから複数のDBに接続し なくてよい
DBまわりで特に意識していること • 最近はJOINはあまりしない方針 ◦ アプリケーションレベルのJOINを多用 • ORMは使わない ◦ 流れるクエリを意識するためにSQLを手書き ◦
ガチガチにチューニングしたクエリがたくさん • MySQLにアクセスする層とアプリケーションロ ジックの層を分離
Aside: pixiv最大のデータベース ブックマーク • 12億レコード ◦ uint32max = 42億 •
1年で倍増弱ぐらい 今後、市販のメモリで収まりきらなくなれば、期間 で分割なども考える必要があり、更にカオスに…
ここまでで質問?
Question: pixivではほぼすべてのユーザーデータはMySQL に入れているが、MySQLに入っていないデータは 何?
Question: pixivではほぼすべてのユーザーデータはMySQL に入れているが、MySQLに入っていないデータは 何? 投稿された画像
画像ストレージ リレーショナルデータベースに入らないファイル は、どのサービスもそれぞれの要件に合わせて頭 をひねる部分 pixivではWebDAVを採用している • HTTPのGETやPOSTでファイルシステムにア クセスするプロトコル • Apacheやnginxのプラグインとして使える
Question: 画像をMySQLに保存しない理由は?
Question: 画像をMySQLに保存しない理由は? • ファイルあたりのサイズが大きい • 総容量も多い(40TB) • 配信するときにApacheやnginxが直接読める ファイル単位としてある方が便利 •
管理上もファイルとしてあるほうがSQLを書いて 取り出すよりラク
pixivの画像の特徴 • 1つ1つが手作りなので写真と違って増えるスピードは速くな い • PC、スマホ、ガラケーなどがあり、生成するサムネイルの種 類が多い • 漫画の枠や、正方形クロップ時の特殊な変換 •
変換後も同じファイルフォーマット ◦ なんでそうしてしまったのか… • 数々の歴史的経緯… • 最近ではうごイラも
pixivの画像変換 • 昔はすべてのサムネイルを投稿時に変換して保存 • 非同期アップロード化(2009) ◦ pixivの画像アップロードシステム • mod_small_lightで配信時に動的変換 ◦
ただしリクエストの多いサムネイルは静的サムネイルのまま ◦ YAPC::Asia 2012「pixivのサムネイル事情」 • サムネイルマスター(2014) ◦ サムネイル生成元となる大きめのサムネイルをJPEGで用意 • サムネイル変換クラスター (2014) ◦ https://github.com/pixiv/go-thumber ◦ 近日稼働予定!
画像配信 pixivというウェブアプリケーションと pixivの画像ストレージ、配信はまあまあ疎結合 →今後はもっと疎結合にしていきたい 理想はAmazon S3のように、ファイルをPOSTする とURLが返ってくるぐらいのブラックボックスにして いきたい 詳しくはインフラのところで話されるかも?
ここまでで質問?
そろそろまとめ 主にpixivのサーバーサイドアプリケーションを、ス トレージとキャッシュに注目して見ていきました。 pixivならではのパフォーマンス上の問題や アプリケーションの制約について いくつか紹介しました。
今日話さなかったこと • 個別機能にまつわる話 • クライアントサイドの話 • デプロイの話 • テストの話 •
グロースチームのエンジニアとしての話 その他いっぱい →興味があればあとで質問歓迎