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
Pinia Colada が実現するスマートな非同期処理
naokihaba
4
230
광고 소재 심사 과정에 AI를 도입하여 광고 서비스 생산성 향상시키기
kakao
PRO
0
170
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
260
as(型アサーション)を書く前にできること
marokanatani
10
2.7k
ヤプリ新卒SREの オンボーディング
masaki12
0
130
C++でシェーダを書く
fadis
6
4.1k
ActiveSupport::Notifications supporting instrumentation of Rails apps with OpenTelemetry
ymtdzzz
1
250
みんなでプロポーザルを書いてみた
yuriko1211
0
280
TypeScript Graph でコードレビューの心理的障壁を乗り越える
ysk8hori
2
1.1k
最新TCAキャッチアップ
0si43
0
190
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
100
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
120
Featured
See All Featured
A Philosophy of Restraint
colly
203
16k
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
100
A Modern Web Designer's Workflow
chriscoyier
693
190k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Building Adaptive Systems
keathley
38
2.3k
Building Applications with DynamoDB
mza
90
6.1k
A better future with KSS
kneath
238
17k
Facilitating Awesome Meetings
lara
50
6.1k
Typedesign – Prime Four
hannesfritz
40
2.4k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
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ならではのパフォーマンス上の問題や アプリケーションの制約について いくつか紹介しました。
今日話さなかったこと • 個別機能にまつわる話 • クライアントサイドの話 • デプロイの話 • テストの話 •
グロースチームのエンジニアとしての話 その他いっぱい →興味があればあとで質問歓迎