Tweet
Tweet

Slide 1

Slide 1 text

© pixiv Inc. 世界から使われるサービスのつくりかた pixiv を⽀える技術 技育 CAMP アカデミア 2024-07-04 pixiv Inc. Harukasan / Michii Shunsuke

Slide 2

Slide 2 text

© pixiv Inc. 2 Harukasan 道井 俊介 福岡県 久留⽶市 ⽣まれ イラストSNS pixiv がサービス開始 ピクシブ株式会社 ⼊社 ● 新卒でインフラエンジニアとして⼊社 ● 画像配信やデータ基盤の構築を担当 画像変換クラウドサービス ImageFlux リリース ピクシブ株式会社 執⾏役員 CTO (現任) 1988 2007 2012 2016 2020

Slide 3

Slide 3 text

© pixiv Inc. ピクシブ株式会社 設⽴    2005年7⽉ 従業員数  585名 (正社員: 367名) (2024年6⽉現在) うちエンジニアがだいたい150⼈くらい 所在地 東京オフィス (東京都渋⾕区千駄ヶ⾕) 福岡オフィス (福岡県福岡市博多区) 3

Slide 4

Slide 4 text

© pixiv Inc. 4 “好き”に出会えるイラスト‧マンガ‧⼩説 作品の投稿プラットフォーム サービス開設⽇ 2007年 9⽉10⽇ 登録ユーザー数 約1億ユーザー 累計投稿作品数 約1億3000万作品

Slide 5

Slide 5 text

© pixiv Inc. 5 ⽇本 中国⼤陸 アメリカ 韓国 台湾‧マカオ ‧⾹港 その他 利⽤ユーザーの割合 主な国‧地域 アジア 84% ヨーロッパ 4% その他 1% 北⽶中南⽶ 11% 52% 8% 出典：pixiv ユーザー情報⾃社調べ（2023年5⽉） 8% 7% 6% 18% 世界で愛されるサービスへ

Slide 6

Slide 6 text

© pixiv Inc. 世界から使われるサービスをつくるには たとえば…… ● Clodflare Workers を使うと最速なのでは ● なんか Rust ってやつで書くと速そう ● なんとなく AWS や Google Cloud をつかってつくればいいのでは？ 6

Slide 7

Slide 7 text

© pixiv Inc. いかにして世界から使われるサービスをつくるか 7

Slide 8

Slide 8 text

© pixiv Inc. 基本的な Web サービスの構造 8 Users Frontend Internet Application Database

Slide 9

Slide 9 text

© pixiv Inc. いかにして世界から使われるサービスをつくるか 結局のところそれぞれのサービスの性質に依る ● pixiv と Amazon と NETFLIX ではおなじ Web サービスでも根本から異なる ● それぞれのサービスの特徴を把握して、サービスを成⻑させていくしかない ● 重要になるのはサービスをどう拡張していくか、拡張できるようにするか ● 基本を抑えつつ、 pixiv の特に特徴的な部分について紹介 9

Slide 10

Slide 10 text

© pixiv Inc. 今⽇のアジェンダ 1. Web サービスにおける拡張性 (Scalability) の考え⽅ 2. pixiv のアーキテクチャとスケーラビリティ ● データベース ● コンテンツ配信 3. pixiv のインフラストラクチャ 10

Slide 11

Slide 11 text

© pixiv Inc. Scalability スケーラビリティ 11

Slide 12

Slide 12 text

© pixiv Inc. Scalability スケーラビリティ システムの拡張性の⾼さを表現したいとき、ウリにしたいときに なにかと便利に使われている⽤語のひとつ ● システムの能⼒を測る基準のひとつ ● 負荷にあわせてリソースを増やしたり減らしたりできること (Load Scalability) ● システムを作ったあとに変更できること ● お⾦をかければどうにかできる、どうにかなること 12

Slide 13

Slide 13 text

© pixiv Inc. Scalability におけるポイント ● スループット (Throughput) ● 帯域幅 (Bandwidth) ● レイテンシー (Latency) ● 拡張 (Scaling) 13

Slide 14

Slide 14 text

© pixiv Inc. Throughput スループット 単位時間あたりにどれだけ処理できるかを⽰す量 たとえば、1つの箱を運ぶ場合: 14 source destination 1 hour elapsed Throughput: 1 box / hour

Slide 15

Slide 15 text

© pixiv Inc. Bandwidth 帯域幅 1つの回線あたりの理論上の最⼤スループット 15 1 hour Bandwidth: 10 boxes / hour

Slide 16

Slide 16 text

© pixiv Inc. 並列数を増やすことでスループットを⼤きくすることができる 16 1 hour 30 boxes / hour

Slide 17

Slide 17 text

© pixiv Inc. Processing Time / Latency 処理時間 / レイテンシー 単⼀の処理にかかる時間、転送にかかる時間 ● 並列数をいくら増やしても遅延は⼩さくならない ● 遅延を解消するには処理速度をはやくするしかない たとえば⾶⾏機で運ぶ 17 5 min elapsed Throughput: 12 box / hour

Slide 18

Slide 18 text

© pixiv Inc. Throughput / Latency の計測 実際に⾶⾏機でものを運ぶにはさまざまな待ち時間が発⽣する 場合によってはトラックで運んだ⽅がはやいこともよくある 遅延とスループットを考えるとき最⼤値なのか理論値なのかよく検討する 18

Slide 19

Slide 19 text

© pixiv Inc. Scaling システムのスループットを⾼めるには: ● 並列数を⼤きくする ● 処理時間を短くし、遅延を⼩さくする そのためには ● スケールアップ/スケールアウトする ● 処理を最適化する、設定をチューニングする 19

Slide 20

Slide 20 text

© pixiv Inc. — Rob Pike, 1989, "Notes on Programming in C". http://www.literateprogramming.com/pikestyle.pdf 20 Rule 1. プログラムがどこで時間を消費することになるかはわからない。ボトルネッ クは思いがけない場所でおきる。したがって、どこがボトルネックかわかるまで、 推測したり、スピードハックを⾏ってはならない。 Rule 2. 計測せよ。計測するまで⾼速化のためにチューニングしてはいけない。コー ドの⼀部が他を圧倒していないのであればなおさらしてはいけない。 “

Slide 21

Slide 21 text

© pixiv Inc. 複雑性 (Complexity) と拡張性 (Scalability) ● プログラムやアーキテクチャが複雑になって良いことはなにもない ● Web サービスのどこにボトルネックがあるか簡単にわかる⽅法はない ● スケーラビリティを⾼めようとしてシステムを容易に変更できなくなって しまっては本末転倒 ● そのためにはどこを改善すべきか計測すること。システムのメトリクスは継 続的に計測する。最適化する前にはより詳細なプロファイルを取得する 21

Slide 22

Slide 22 text

© pixiv Inc. 世界から使われるサービスをつくるには Web サービスは⽣まれた瞬間から世界中から使われることはない ● スケールアップ‧スケールアウトが必要になるまでシステムを複雑にしすぎ てはいけない。複雑であるほどスケーラビリティは低下する ● どのように動いているか計測し、拡張し続けられるように改善し続けなけれ ばスケールアップ‧スケールアウトすることは難しくなってしまう ● 無駄な処理を省くことはもっとも簡単なスケールアップのひとつ。システム を分散させて複雑になる前に、プログラムに改善することはないか⼗分に検 討する 22

Slide 23

Slide 23 text

© pixiv Inc. pixiv のアーキテクチャ 23

Slide 24

Slide 24 text

© pixiv Inc. 24 PHP PXIMG Cloudflare Node.js MySQL Redis Solr Storage

Slide 25

Slide 25 text

© pixiv Inc. pixiv におけるデータストレージ ● RDB: MySQL ● KVS: Redis ● Search Engine: Solr ● Object Storage: Ceph, Amazon S3, GCS ● Image Storage: Infinity Store ● DWH: Google BigQuery 25

Slide 26

Slide 26 text

© pixiv Inc. pixiv における RDB 役割毎に複数のデータベースに分割 ● イラスト、ユーザー情報 ● ⼩説 ● 評価履歴、過去ランキング ● 作品のブックマーク、ユーザーのフォロー情報 ● ブックマーク統計情報 ● ユーザー向けアクセス解析⽤閲覧履歴 ● などなど…… 26

Slide 27

Slide 27 text

© pixiv Inc. なぜ複数のデータベースに分割するか データ構造によって性質が異なるので分割したほうが最適化しやすい ● データベースによってデータ増加速度にばらつきがある ● データの性質によってアクセスパターンが異なる ○ イラストや⼩説の本⽂: 更新より参照が圧倒的に多い ○ ブックマーク: 更新が⾮常に多く、テーブルの⾏数も多い ○ 閲覧履歴: 追記しか発⽣しない ● 同時に更新する必要がなければ同時にロックをとる必要がない 27

Slide 28

Slide 28 text

© pixiv Inc. リードレプリカによる参照処理の分散 RDBのレプリケーション機能とロードバランサーを⽤いて、参照処理を分散する ● ⼀般的な Web サービスでは更新に⽐べて参照の頻度が圧倒的に多い ● リードレプリカの台数を増やすことで参照のスループットを増加できる 28

Slide 29

Slide 29 text

© pixiv Inc. ロードバランサー クライアントとサーバーの間で処理を分散するためのミドルウェア ● TCP/UDPを分散するL4ロードバランサーとアプリケーションプロトコル (HTTPやMySQLプロトコル)を分散するL7ロードバランサーがある ● pixiv ではデータベースのロードバランシングに LVS を⽤いている 29

Slide 30

Slide 30 text

© pixiv Inc. 垂直分割と⽔平分割 ● pixiv では Sharding によるデータベースの分割をしていない ● 現代においては TiDB や CockroachDB といった選択肢がある ● AWSのAmazon AuroraやGoogle CloudのAlloyDBも選択肢になる 30

Slide 31

Slide 31 text

© pixiv Inc. 適切なインデックスを張る スケールアウトだけで性能を改善するには限界がある ● CPUやメモリのアクセス速度は大幅に改善していない ● たくさんのデータを処理すればそれだけ時間がかかる ● 計算時間を小さくするにはデータ量を少なくするのが手っ取り早い 適切なインデックスをはることでスキャンするデータ量を小さくできる 31

Slide 32

Slide 32 text

© pixiv Inc. 検索エンジンを活用する Elasticsearch や Solr といった検索エンジンは全文検索に特化したインデックスを分散 処理できる。 ● ピクシブでは N-gram や Unigram のインデックスも活用している ● 一般的な自然文検索では新しく登場するキャラクターには対応できない ● Unigramがないと1文字キャラクターを検索できない ● ユーザーの検索クエリにあわせてインデックスを使い分ける ● 巨大な検索には Google BigQuery を用いる 32

Slide 33

Slide 33 text

© pixiv Inc. DWHを活⽤する 複数のサービスから⽬的ごとに統合して時系列ごとに保存した構造化データを溜 め込む先を DWH と呼ぶ。現代では⼤量の時系列データを格納して SQL でクエリ を書けるところ、ぐらいのイメージで捉えられている ピクシブでは全社のDWHとして Google BigQuery を採⽤している ● RDB では複数の DB やサービスを横断するクエリを書くのが難しい ● 例えば、 pixiv と BOOTH と pixivFANBOX を横断して使っているユーザーの数 を数えるには……？ 33

Slide 34

Slide 34 text

© pixiv Inc. pixiv の Google BigQuery 全社のさまざまな機能、BIの基盤として BigQuery を活⽤している ● 2013年頃から全社の基盤として採⽤ ● データ量: 約 7.8PiB ● アップロード: 約 6.9TiB / day ● テーブル数: 約 180,000 テーブル ● ジョブ数: 約 52,000 件 / day 参考: 【PIXIV MEETUP 2023】ピクシブのデータインフラと組織構造 https://speakerdeck.com/kashira/pixiv-meetup-2023-pikusibunodeta-inhuratozu-zhi-gou-zao 34

Slide 35

Slide 35 text

© pixiv Inc. pixiv のデータベース: まとめ ● 適切なサイズにデータベースを分割する ● 分割するほど複雑性が⾼まるので分割しすぎない ● 適切にインデックスをはり、適切にクエリをチューニングする ● クエリをチューニングしすぎて複雑にしない ● 検索エンジンを活⽤する ● Google BigQuery を活⽤して横断的な分析を実現する 35

Slide 36

Slide 36 text

© pixiv Inc. pixiv におけるコンテンツ配信 36

Slide 37

Slide 37 text

© pixiv Inc. 37 PHP PXIMG Cloudflare Node.js MySQL Redis Solr Storage

Slide 38

Slide 38 text

© pixiv Inc. 配信するコンテンツの種類 pixivのネットワークを通る主なコンテンツの種類 ● 動的に⽣成するHTML、JSON ● フロントエンドでの処理に⽤いる静的ファイル (Assets) ● イラスト画像、アイコンをメインとしたユーザーが投稿した画像 (UGC) 38

Slide 39

Slide 39 text

© pixiv Inc. 光は遅い ⽇本からアメリカの⻄海岸 (ロサンゼルス) までだいたい 8,800km 光の速度は真空中で約 300,000 km/s 、光ファイバーだと 200,000km/s ぐらい ∴ 理論上のレイテンシーは 44ms TCPでは3回のRTTが必要なので⽇本とアメリカで通信すると 264ms 以降のパケットも 44ms 遅れて届く 60fps のゲームだと2.5フレームぐらい遅れてしまう 39

Slide 40

Slide 40 text

© pixiv Inc. CDNを活用する 光より速く通信することは現代ではまだ難しいので、コンテンツを物理的に ユーザーの近くに配置するしかない CDN は事業者によってそれぞれアーキテクチャが異なる ● POPの数と配置のしかた ● キャッシュ容量と機能 ● セキュリティ機能 (DDoS Protection、WAF、Bot protection) の有無 ● エッジコンピューティング pixiv では CDN として Cloudflare Enterprise を選択 40

Slide 41

Slide 41 text

© pixiv Inc. エッジコンピューティングの活⽤ pixiv ではいまのところエッジコンピューティングをうまく活⽤できていない ● SSR を⾏うにはコンテンツやユーザーの情報が必要になる ● DB に保存されているコンテンツ/ユーザー情報はリージョン分散が難しい ● データが遠い場所にあるとエッジで処理しても応答時間は短くならない 41 PHP Cloudflare Node.js MySQL Redis

Slide 42

Slide 42 text

© pixiv Inc. pixiv における画像配信 pixiv のメインコンテンツは画像なので、画像が表⽰されないとユーザー体験が ⼤きく低下する pixiv における画像配信の特徴: ● ⼤量の画像ファイル ● 1枚ごとのサイズのばらつき: 平均60KB 最⼤15MB (95%tileで 300KB) ● ⼤量のリクエストと転送量 42

Slide 43

Slide 43 text

© pixiv Inc. pixiv の画像配信クラスタ 国内の画像配信にはCDNではなく独⾃のコンテンツ配信クラスターをオンプレミ スに構築している ● ネットワーク費⽤はクラウドよりもオンプレミスの⽅が圧倒的に安い → 100Gbpsの回線を複数本利⽤し帯域コストを削減 ● CDNでは⼤量の画像ファイルをキャッシュ出来ずキャッシュヒット率が低い → SSDを⼤量に搭載したキャッシュクラスタを構築し運⽤ そのためには今のところ地理的なスケーラビリティを諦めている 43

Slide 44

Slide 44 text

© pixiv Inc. 44 Webサービスの画像の悩みを解決する画像変換‧配信のクラウドサービス 開発した画像変換機能をサービスとして販売する ● pixivのサービスの中核は画像を中⼼としたUGCで⾼品質な画像配信は最重要機能のひとつ ● 画像変換⾃体をビジネスにすることで、画像変換技術⾃体に継続的に投資できる ● ピクシブだけだとノウハウがないので、⼀般向けのSaaSとしてさくらインターネットと共同開発 ● ⼀⾔に画像ファイルといってもUGCでは多数の種類があり、世の中にはこれまでに⾒たこともない (変な)画像ファイルがたくさんあるので、お客様が増えるほど画像変換の品質を改善できる ● 実際に ImageFlux のユーザー要望で実装した機能を取り込んだ例がいくつもある

Slide 45

Slide 45 text

© pixiv Inc. pixiv のコンテンツ配信: まとめ CDNを活⽤し世界中にコンテンツを配信できるようにする ● 光は遅いのでユーザーの近くからコンテンツを配信できるようにする ● サービスの性質にあわせたCDNを選択する 地理的に限定することで低コストかつ⾼速なコンテンツ配信を実現する ● 画像変換‧配信技術に投資し改善しつづける 45

Slide 46

Slide 46 text

© pixiv Inc. pixiv のインフラストラクチャ 46

Slide 47

Slide 47 text

© pixiv Inc. 47

Slide 48

Slide 48 text

© pixiv Inc. pixiv のインフラストラクチャ 社内の⼀⾓におかれたむき出しのマザーボードPC からはじまった ● 会社がはじまったのが 2005年、AWS が EC2 をリリースしたのが2006年 ● 現在では都内をはじめ複数のデータセンターにホスティングして運⽤ 48

Slide 49

Slide 49 text

© pixiv Inc. オンプレミスとクラウド pixiv ではインフラストラクチャの基盤としてオンプレミスを活⽤している パブリッククラウドとしては AWS と Google Cloud の両⽅を使える なぜいまだにオンプレミスを残しているのか: ● 規模が安定したプロダクトにおいてはネットワーク転送量、計算資源の両⽅ でオンプレミスの⽅がまだまだコストが低い ● すべてをオンプレミス、すべてをパブリッククラウドにする必然性はない ● システムの特徴に応じて最適なアーキテクチャを選択することが重要 49

Slide 50

Slide 50 text

© pixiv Inc. オンプレミスの良いところ/良くないところ 基本的にいまから採⽤するならパブリッククラウドを採⽤したほうが良い ● ピクシブでも新規サービスの多くにパブリッククラウドを採⽤している ● パブリッククラウドのほうが考えることが圧倒的に少ない ● パブリッククラウドとオンプレミスの違いは責任分界点の違い ● コンテンツ配信という領域に絞っていえばオンプレミスでやれることは多い ● これまでの資産を有効に活⽤するかどうか 50

Slide 51

Slide 51 text

© pixiv Inc. まとめ 51

Slide 52

Slide 52 text

© pixiv Inc. 世界から使われるサービスをつくるには Web サービスは⽣まれた瞬間から世界中から使われることはない ● サービスを拡張できるかどうか、やりすぎていないか意識する ● スループットとレイテンシーの両⽅を意識する ● 必要以上に複雑にしすぎないこと、サービスの性質を理解すること 52

Slide 53

Slide 53 text

© pixiv Inc. 一緒に pixiv を改善するエンジニアを募集しています！ 26年度新卒(エンジニア職) https://hrmos.co/pages/pixiv/jobs/1927700442953322534 25年度新卒(エンジニア職) https://hrmos.co/pages/pixiv/jobs/048 中途採⽤ https://www.pixiv.co.jp/mid-career/ 53