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.9k
pixivを支える技術 2014
インターンシップの学生向けの講義資料です。
Atsushi Takayama
September 04, 2014
Tweet
Share
More Decks by Atsushi Takayama
See All by Atsushi Takayama
最高の開発者体験の追求が開発生産性を改善し続ける文化を生み出した話
edvakf
3
1.3k
NeurIPS 2021 論文読み会: How Modular should Neural Module Networks Be for Systematic Generalization?
edvakf
0
170
8年物のJavaのシステムをKotlinに変えていく選択に至るまで
edvakf
2
1.1k
ピクシブ社内のImageFlux利用事例紹介
edvakf
1
2.8k
学びの文化を育む社内読書会のススメ
edvakf
0
270
フルCDNアーキテクチャでサービス設計した話
edvakf
5
3.9k
Goでバイナリを読む+α
edvakf
1
950
お前はこれまでに作ったAPIの数を覚えているのか?
edvakf
0
2.5k
「ふつうのRailsアプリケーション」についての考え方
edvakf
2
850
Other Decks in Programming
See All in Programming
可変変数との向き合い方 $$変数名が踊り出す$$ / php conference Variable variables
gunji
0
210
Porting a visionOS App to Android XR
akkeylab
0
890
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
9.1k
NEWT Backend Evolution
xpromx
1
140
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
26
7.7k
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
16
5.9k
なぜあなたのオブザーバビリティ導入は頓挫するのか
ryota_hnk
0
210
Workers を定期実行する方法は一つじゃない
rokuosan
0
120
Rails Frontend Evolution: It Was a Setup All Along
skryukov
0
310
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
280
リッチエディターを安全に開発・運用するために
unachang113
1
230
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
540
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
Fireside Chat
paigeccino
37
3.5k
Producing Creativity
orderedlist
PRO
346
40k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Side Projects
sachag
455
43k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
GraphQLとの向き合い方2022年版
quramy
49
14k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Visualization
eitanlees
146
16k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
The Cult of Friendly URLs
andyhume
79
6.5k
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ならではのパフォーマンス上の問題や アプリケーションの制約について いくつか紹介しました。
今日話さなかったこと • 個別機能にまつわる話 • クライアントサイドの話 • デプロイの話 • テストの話 •
グロースチームのエンジニアとしての話 その他いっぱい →興味があればあとで質問歓迎