pixivというシステムはどんな形をしているのか、それはなぜか。

こんにちは。pixivのnamazuです。

先日開催されたPIXIV DEV MEETUP 2024にて、『pixivというシステムはどんな形をしているのか、それはなぜか。』というテーマで発表をさせていただきました。当日、セッションにご参加いただいた皆さま、そしてフィードバックをいただいた方々に、改めて感謝申し上げます。

Webサービス開発において面白い点の一つは、どのサービスもその要件や状況に応じて異なる選択がなされることです。結果として、類似点がある場合もありますが、細部において同じものはなく、すべてがユニークです。弊社内でもさまざまな違いが見られますが、業界全体を見渡すとさらに多様性が広がっていることでしょう。

今回の発表では、pixivのシステムに関する重要な要件や状況をいくつか取り上げ、現時点でどのような構造になっているかを、インフラストラクチャ、バックエンドアプリケーション、開発文化といった観点から説明しました。

この記事では、発表で使用したスライドと原稿を基に、17周年を迎えた今のpixivの形について紹介します。

お断り

本記事の内容は、説明のために大きく意味が変わらない範囲で省略・簡略化されています。ここで取り上げるのはpixivに関するものですが、弊社には多数のサービスがあり、中には全く異なるサービスも多数存在することをご承知おきください。

pixivのインフラについて

まず、pixivのインフラ構成について説明します。pixivは基本的にオンプレミス環境を基盤としたインフラで運用されているサービスです。

以下の図は、ユーザがpixivにアクセスする際の大まかなネットワーク経路を示したものです。（※弊社管理外のネットワークに関しては、正確性を保証するものではなく、説明は一般的な理解に基づいています。）

ユーザがブラウザでpixivを表示する際に関わる主なドメインは2つです。1つはpixivのメインドメインである「www.pixiv.net」、もう1つはイラストなどの画像配信が行われる「pximg.net」です。DNSを引くと「pixiv.net」はCloudflareのIPアドレスを返し、「pximg.net」はIDCフロンティアの管理するAS（自律システム）のIPアドレスが返されます。

pixivは基本的にオンプレミス環境でホスティングされており、IDCフロンティア様のハウジングサービスを利用しています。
サーバーは地理的には福島県白河市に設置されています（詳細はこちら）。

「pximg.net」ドメインのIPアドレスがIDCフロンティアのものであることからも明らかですが、pixivは現在、インターネット接続もIDCフロンティアから提供を受けています。そのため、典型的な経路では、ユーザのリクエストはインターネットを経由し、東京の大手町などを通ってIDCフロンティアのネットワークに入り、福島にあるpixivのサーバに到達します。

上図のpixivとインターネットをつなぐ部分、つまりpixivの対外ネットワークについて見ていきます。

pixivは動画コンテンツを扱わないものの、大量のイラストを扱うtoC向けのサービスであるため、画像配信によって生じるトラフィックが多いことは容易に想像できるかと思います。実際にpixiv内を一定時間回遊すると、HTMLやWeb API(JSON)、JavaScript・CSSといったアセットに加えて、イラストなどの画像データがダウンロードされますが、容量ベースで見ると、全体の9割以上はイラスト等の画像データが占めています。

現在、pixivをはじめとするオンプレミス環境における対外送信トラフィックは、ピーク時には100Gbpsを超えています。pixivのトラフィック変動は、日本のインターネット利用状況とほぼ一致しており、日本時間の朝6時頃が最小、24時頃が最大となっています。最小と最大のトラフィック差はおよそ3倍程度に収まっています。

かつては、海外ユーザの利用が少なかったため、トラフィックは日本のタイムゾーンに強く依存し、大きく変動していました。しかし、現在では海外ユーザの増加により、1日のトラフィック変動は年を追う毎になだらかになっています。

また、休日やゴールデンウィーク、お盆、年末年始といった要素によって全体的なトラフィック量に多少の増減が見られるものの、数倍になるといったことはありません。

pixivのコストと収益、オンプレミスの選択

インフラを設計・運用する上で、非常に重要な要素がコストです。

大規模なトラフィックを発生させるtoCサービスでは、一般的に人件費を除くと、ネットワーク転送量が主要なコストとなります。pixivにおいても同様で、SaaSの利用料やサーバ購入費なども当然発生しますが、100Gbps規模のトラフィックを処理するためには、ネットワーク転送コストが大きな部分を占めます。

pixivの収益源は、主にWeb広告と有料サブスクリプションサービス「pixivプレミアム」です。コストと収益の関係について考えると、あまり良いものではないということがわかります。
pixivで扱われるイラストは、記事などのコンテンツと比較すると、1PVあたりの閲覧時間が短いため、記事などと比較すると広告収益が低くなりがちです。またサブスクリプションに関してもPV数と直接の関係があるものではありません。

一般論的には、Web事業においてインフラのランニングコストと収益は直接的に結びついていた方が望ましく、コストに対する収益の比率が大きいほど好ましいです。
ここを改善するため、pixivの場合、大規模なトラフィックに伴うコストをいかに抑えるかが重要な課題となります。

このような背景から、pixivのインフラは現在のオンプレミス主体の形に至っています。
オンプレミス環境では、パブリッククラウドと比べ、利用状況次第ですがより安価なネットワークが利用できることがあります。リソース需要が大きく変動しない場合には、初期投資こそ必要ですが、一定規模のサーバ機器を長期間にわたり運用することで、サーバコストを抑えることが可能です。

このようなオンプレミスの特性を活用することで、pixivを収支的に成り立たせることが可能になります。

これが、pixivのインフラ構成における最大の要因となっています。

pixivの画像配信

pixivのインフラで特徴的な部分として、画像配信の仕組みを紹介します。

pixivの画像配信インフラは、ロングテールの特性からキャッシュが難しく、さらにCDNを利用するとトラフィックコストが増加してしまうため、現状自社でオンプレミス環境に構築されています。

pixivの画像配信クラスタは「pximg」と呼ばれており、この名前はドメインにも使われています。主に以下の構成要素から成り立っています。

nginx
Apache Traffic Server
thumberd（自社開発の画像動的変換モジュール）
画像ストレージクラスタ

nginxで受けたリクエストをConsistentHashアルゴリズムに基づいてリクエストを分散した上で、ApacheTrafficServerにてSSDを用いた100TiBを超える大容量のキャッシュ空間を挟んでいます。
このキャッシュにより、Cache Hit Rateを一定の水準に保つことができ、後段にある画像の動的変換によるCPUコストや、画像ストレージからの読み出しに伴うIOコストを削減しています。

実現にノウハウが必要な、画像変換モジュールであるthumberdは内製しており、このソリューションは「ImageFlux」というSaaS製品として販売しています。

pixivのバックエンド構成

pixivのバックエンドインフラは、LAMPスタックを基盤とした典型的なWebアプリケーションとなっています。

まず、前段にはDDoS攻撃対策やBot対策を目的としたCloudflare CDNが配置されています。高度に複雑化した執拗なDDoS攻撃には簡単に対抗することはできません。コストはある程度掛かってしまいますが、できる限りユーザへの影響を最小限にし、サービスの安定性を保つためにCloudflareを用いてプロキシ処理を行っています。

Cloudflareからのリクエストは、pixivのオンプレミス環境にあるnginxで受け、その後、アプリケーションサーバであるApacheにリバースプロキシされます。Apacheはmod_phpを利用してPHPアプリケーションコードを実行します。

バッチ処理はArtCronとして用いるJenkinsから実行します。

ミドルウェアとして主要なものにMySQL・Redis・Elasticsearch・Cephなどがあります。各種ログ転送と集計処理にはFluentdが用いられます。

pixivとLAMP

前述の図からもわかるように、pixivのインフラはLAMPスタックで構成されています。LAMPというのは、OSをLinuxとし、Apache httpdをWebApplicationServerとして使い、MySQLをRDBとして採用し、アプリケーションの言語はPHPということです。

そもそも、なぜLAMPスタックなのでしょうか。

その理由は、非常にシンプルです。2007年の創業時、当時のメンバーが最も使い慣れていたスタックがLAMPだったためです。ピクシブ株式会社の前身では、LAMPスタックとオープンソース技術を活用してWeb制作の請負を行っていました。この頃の日本のWebサービスでは、PHPで作られたものが多くあります。
この選択は、当時の状況を考えると納得のいくものだと思います。

もしpixivが少し後に制作されていたら、Railsで構築されていた可能性もあります。実際、弊社で後に作られた他のサービスは、Railsを採用しているケースが増えています。

しかし、17年経った現在、なぜpixivは依然としてLAMPスタックを採用しているのでしょうか？

当然、時折「別の言語で作り直したらどうか」という意見が出ることもあります。
pixivは当面の間、PHPをベースとした現行の構成を維持する予定です。

PHP言語は現存人員等の資本や、日本における採用市場で安定しており、実行効率もpixivの現状のユースケースであれば十分です。生産性に関しても大きな問題はないでしょう。 pixivは現状最新のPHP8.3に追従し、PHPStan等の静的解析ツールを活用しています。 MySQLに関してもpixivはワークロードがReadManyなため対処できています。

pixivの開発(pixiv.git)

LAMPスタックの上で動作する、プログラムについてです。

pixivのバックエンドは社内ではpixiv.gitと呼ばれるモノリポジトリで取り扱われます。pixiv.gitはpixivだけではなく、社内でPHPで作られているサービスを概ね収容しています。該当のサービスはpixiv・pixivFANBOX・pixivision・pixivアカウントサービスなどです。このリポジトリは月60〜70人程度で開発されています。

pixiv.gitの特徴として、高頻度なデプロイが挙げられます。直近1年間のデータによると、営業日あたり平均19回程度のデプロイが行われており、高い頻度でリリースが行われていることがわかります。（※金曜日など、休日の前日はデプロイが禁止されるため、日ごとのデプロイ数には若干の変動があります。）

pixiv.gitでは、このような小規模で高頻度なリリースを積極的に行う文化が根付いており、これをサポートするために高速なデプロイが実現されています。現状では、バックエンドのデプロイのみであれば30秒程度で完了します。pixivのバックエンドはApache上で動作するPHPプログラムなので、デプロイ手順はWebサーバにソースコードをrsyncで同期するというシンプルな処理で完結するため、短時間で実施できる仕組みとなっています。

この高速なデプロイの利点は、仮に問題が発生しても、迅速にロールバックできる点です。pixivはミッションクリティカルなサービスではないため、デプロイ中に発生する短時間の障害は、ユーザへの影響が比較的小さいという特徴があります。開発したものをすぐレビューして、すぐにデプロイできる。そういったスムーズさを大事にしています。

開発の快適さに大きく影響する要素の一つが、リポジトリにpushされたコードを検証する自動テスト、CIの所要時間です。

pixiv.gitはある程度のコード規模を持っていますが、バックエンドのPHPの変更であれば1分、フロントエンドのTypeScriptの変更であれば3分程度でCIが完了するようになっています。

もしCIが長時間かかる場合、「あともう少し修正したいけれど、CIに時間がかかるからまたにしよう」と作業を見送ってしまうこともあるかもしれません。こうした遅延が品質に影響するため、pixivではCIの所要時間を短縮することを重要視しています。

pixiv.gitのCIは基本的な並列化などは行っていますが、差分に基づくテスト範囲の限定などを行うような工夫はしていません。それでも、CIの所要時間を短縮できている理由の一つは、pixivが保有するオンプレミスの資産にあります。

オンプレミスではクラウドと比較して、スケールアップによる問題解決が比較的容易です。一般にスケールアウトはイメージの転送やキャッシュの転送といったオーバーヘッドが増加しますが、スケールアップであれば抑えられます。
pixiv.gitではCIの実行に64C128T 3.25GHzのベースクロックを持つCPU、512GBのDDR5メモリ、1TBのNVMeディスクを複数といったノードを利用しています。
こういった専有型を必要とするような高性能ノードは実行時間課金のクラウドでは、処理が行われない夜間や休日は縮小することが好ましいですが、オンプレミスは基本つけっぱなしでも費用は嵩みません。
常にテスト実行可能な環境をスタンバイさせることができます。

pixivでは、デプロイやCIの改善に多少の人員を割り当てて取り組んでいます。これらを日々の業務の傍らで改善するのは困難ですが、pixiv.gitのように60〜70人の開発者が関わる規模の大きなリポジトリでは、開発体験の改善において規模の経済が働き、積極的に取り組む理由となります。

pixivではモノレポの集約と一括管理を活用し、PHPのバージョンアップやPHPStanなどの静的解析ツールの充実、CI/CDの改善に力を入れています。これにより、開発者の生産性と作業のスムーズさを維持しながら、継続的な改善が可能となっています。

pixiv.gitが苦手なこと

pixiv.gitのインフラや開発体制には苦手とする分野もいくつか存在します。代表的な例として以下のような点が挙げられます。

MySQLやPHPが向かない用途（WriteHeavyなMySQLが一般に苦手とする要件や機械学習・低レイヤーなどPHPと親和性が高くない領域での利用)
簡単にセルフホストできないソリューション（複雑な分散DBや、オンデマンドに大量のリソースを一時的に利用する計算など）
インフラからアプリケーション全体まで一貫したオーナーシップを持つこと

こういったpixiv.gitが苦手とする点については、様々な方法で補ってpixivを実現しています。

まず、オンプレミスで難しい要件はパブリッククラウドを活用し解決しています。
例えばBigQueryにデータを全社的に蓄積し、大規模な集計処理を委譲することで、多様な変数を用いたランキング等を実現しています。
またワイドカラムストアとしてBigtableを利用したりすることで、MySQLでは実現が難しい要件にも対処しています。

需要が大きく変動するプロジェクトや、短期間のみ運用される企画の専用モジュールなど、実行環境としてクラウドが適するものについては、モジュール自体をクラウド環境でホスティングし、pixivから利用しています。
代表的な例として専門のチームを割り当て運用している、機械学習基盤等があります。

本年、こういったオンプレミスとクラウド間の柔軟な結びつきを強化するため、GoogleCloud及びAWSについてオンプレミスとの閉域網接続も実現しています。

オンプレミス環境でも、PHP以外の実行環境が適するアプリケーションについては、Kubernetes (k8s) クラスタを利用して分離・運用しています。pixivでは、フロントエンドのNext.jsのサーバサイドレンダリング環境として、このk8sクラスタを活用しています。Kubernetesを使用することで、開発者がDocker Imageファイルやマニフェストファイルを直接変更できるため、インフラまでを一貫して管理することが可能です。