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
990
ピクシブ社内のImageFlux利用事例紹介
edvakf
1
2.6k
学びの文化を育む社内読書会のススメ
edvakf
0
200
フルCDNアーキテクチャでサービス設計した話
edvakf
5
3.7k
Goでバイナリを読む+α
edvakf
1
870
お前はこれまでに作ったAPIの数を覚えているのか?
edvakf
0
2.4k
「ふつうのRailsアプリケーション」についての考え方
edvakf
2
740
Other Decks in Programming
See All in Programming
Importmapを使ったJavaScriptの 読み込みとブラウザアドオンの影響
swamp09
4
1.2k
僕がつくった48個のWebサービス達
yusukebe
18
17k
レガシーな Android アプリのリアーキテクチャ戦略
oidy
1
170
CSC305 Lecture 13
javiergs
PRO
0
130
役立つログに取り組もう
irof
26
8.6k
Outline View in SwiftUI
1024jp
1
110
AWS IaCの注目アップデート 2024年10月版
konokenj
3
3.1k
ECSのサービス間通信 4つの方法を比較する 〜Canary,Blue/Greenも添えて〜
tkikuc
11
2.3k
Go言語でターミナルフレンドリーなAIコマンド、afaを作った/fukuokago20_afa
monochromegane
2
140
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
52
32k
offers_20241022_imakiire.pdf
imakurusu
2
360
WEBエンジニア向けAI活用入門
sutetotanuki
0
300
Featured
See All Featured
Speed Design
sergeychernyshev
24
570
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Writing Fast Ruby
sferik
626
61k
Code Review Best Practice
trishagee
64
17k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
A designer walks into a library…
pauljervisheath
202
24k
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ならではのパフォーマンス上の問題や アプリケーションの制約について いくつか紹介しました。
今日話さなかったこと • 個別機能にまつわる話 • クライアントサイドの話 • デプロイの話 • テストの話 •
グロースチームのエンジニアとしての話 その他いっぱい →興味があればあとで質問歓迎