福岡2017年3月3日、ピクシブ福岡オフィスにて「福岡オフィスオープン記念祭」が開催されました。福岡在住のエンジニアと共に、オフィスの完成を祝いました。CTOの高山からは、福岡のエンジニアに向けてピクシブの技術の全体像がわかる「ピクシブのサービスと技術」という発表がされました。同セッションの内容について紹介します。巨大な80万行のPHPアプリケーションピクシブはこれまで、クリエイターに向けてさまざまなサービスを提供してきました。これらは、サービスごとに独立したリポジトリで運用されているものもあれば、連携しやすくするために、複数のサービスを一つのリポジトリに相乗りさせて運用しているものもあります。後者のリポジトリを、僕らは「pixiv.git」と呼んでいます。pixiv.gitには、イラストコミュニケーションサービス「pixiv」をはじめとして、「pixivision」という創作活動に関わるメディアであったり。クリエイター支援サービスである「pixivFANBOX」や、イラストが学べるサービス「sensei」など、pixivと連動した様々なサービスのソースコードが、この一つのリポジトリで管理されています。pixiv.gitは、2007年から稼働しはじめて、現在では80万行を超える巨大なPHPアプリケーションになりました。10年も運用しているので、レガシー資産だと捉えられがちですが、僕らはそういう風に考えていません。PHPは徐々に5.2から7へと移行を進め、コードベース全体に関わるリファクタリングも頻繁にやっています。担当する人が変わっても読めるとか、一貫した思想に基づいて書かれているとか、理想を追い求めて改善を進めています。フロントエンド技術については、かつてはprototype.jsが使われていた時期もありました。僕が入社した2012年にはjQueryを活用していたのですが、最近はプリコンパイル環境が充実し、webpackなどを使ってES2017やReactといった最近の技術を活用しています。世界有数のトラフィックを捌くインフラpixivは、大量のアクセスがあるサービスです。全世界からやってくる毎分30万リクエストのトラフィックを、自前で構築したインフラで捌いています。pixivがオープンしてしばらくは、頻繁にサービスがダウンしたり、サーバー台数をとことん減らさなければいけない事情があり、インフラやアプリケーションの改善によるパフォーマンスチューニングを繰り返していた時期がありました。努力の甲斐もあって、余裕がある今は安定して運用できています。インフラでは、特に画像配信が大変でして。一つのページ内に、ユーザーが投稿したイラストなどの画像が20枚ほどでてきます。ユーザーからのアクセス数に対し、単純計算で20倍のリクエストを捌かなくてはいけません。pixivの画像配信インフラは、恐らく日本で一番のトラフィック量を捌いています。世界でも有数のトラフィック量ではないでしょうか。ロングテールなアクセス傾向にある上に、一つの画像に対して10パターン以上のサムネイルを生成することが求められています。それに最適化するため、OSSを組み合わせて独自のキャッシング機構を構築したり、自前の画像変換の仕組みをGoで開発したり、日々改善を繰り返し運用しています。した取り組みの中で鍛えられた画像変換や配信などの技術を、さくらインターネットさんの協力の下、クラウドサービスとして公開しています。「ImageFlux」として、ピクシブ外のサービスでも活用できるようにしました。ImageFluxは、C言語を使ったアセンブラレベルの技術を使って画像変換処理をしていたり、Goを使ってネットワーク周りを最適化したりと、低レイヤーでの改善が繰り返されています。最高の画像変換技術を求めて、研究が進められています。実は今回のイベントでも、一緒にImageFluxを運用しているさくらインターネットさんから、福岡オフィスオープンのお祝いの花を贈っていただいてます。広告配信システムの話をします。ピクシブでは、広告配信のための仕組みをフルスクラッチで開発し、広告の運用に活用しています。Railsですが、広告を配信するサーバーは、大量のトラフィックを捌くためにGoで開発しています。そのGoの配信サーバーに関してですが。広告配信サーバーの実装方法に関する情報は、他社さんだと外には公開しない傾向にあります。それ自体が会社のビジネスとして重要になることがあるからです。僕らは広告配信そのものをコアビジネスにしたり、ダイレクトに収益を得るための手段にしません。僕らが考えて作った広告配信の技術が、会社の外の人に知られても、失うものはないんです。僕らは、広告配信サーバーの情報を外に公開しています。「参考にしました!」とか「あのGoの広告サーバー、ウチも同じような感じでやっています!」なんてコメントを頂くようになりました。色んな企業さんで、広告配信サーバーを作る上での参考にされているようです。Railsを使っています。Railsで開発されています。エンジニアはプロダクトに長く関わるほど、暗黙知が増え、属人性が増すものです。エンジニアがチームに移ってすぐに、高いパフォーマンスを発揮できないという問題は、ピクシブに限った話ではないはずです。Wayに従うことで、技術的な面での属人性を排除できると考えてます。Wayな部分の知識は共通しているので、チームを超えてノウハウをスケールできるんですね。Railsのアップデートのノウハウもその一つです。最近なんですけど、違うチームにいるRailsエンジニアが集まって、pixivコミックで使ってるRailsを3.2から5.0にアップデートしました。Railsエンジニアは、チームを横断して活躍できるんです。Wayに従って、普通のことを普通にやる。普通にやれないときこそ、エンジニアは頭を使う「普通のことを普通にやる」とはいいましたが、プロダクトの特性上、普通に作れないモノもあります。イラスト一枚からグッズを作れるサービスであるpixivFACTORYでは、サーバー内でBlenderやImageMagickを外部コマンドとして使ってイラスト画像を処理し、グッズの完成予想写真(商品プレビュー)を表示しています。汎用のOSSライブラリでは解決出来ない場合もありまして。最近では、自前でGoの画像処理ツールを開発したり、画像フォーマットを直接解釈してバリデーションさせるような仕組みを作るなど、低級なことにも踏み込んでいます。サーバ内でBlenderを動かしてみたら意外にもイケていたという話pixivSketchでは、Web版とiOS版とAndroid版を提供しています。Railsなのですが、Viewを持っておらず、JSONを返すAPIサーバーとして機能しています。Web版はViewがリッチでJSも多いので、Viewの部分をNode.jsを使ってisomorphicな実装にしています。Node.jsからアプリと同じAPIを呼び出せるようにすることで、バックエンドからフロントエンドに至るまでさまざまな処理を共通化しています。Sketchのフロントアーキテクチャピクシブが運営しているサービスには、決済が絡むものもあります。これを共通に扱えるようにした、全サービス横断型の決済基盤システムがありまして、僕らはそれを「pixivPay」と呼んでいます。社内で課金を扱うサービスが古くなってきたので、一昨年ぐらいから開発をはじめました。Railsで扱うには、複雑過ぎるビジネスロジックがありまして、これを安全に記述するためにScalaを使っています。このように、普通にやるべきところは普通にやって、普通じゃないところはエンジニアが頭を使って解決する。僕らはそういう技術選択をして、サービスづくりをしています。チャレンジしていくことを大切にするサービスづくりですが。ビジネス職が1人ぐらいいて、エンジニアが2人〜5人ぐらいいるような小さなチームで、サービスづくりをすすめています。自分たちがちゃんと見られる範囲でチームに分かれて、担当するという体制で進めています。僕らの第一目標は、クリエイターに支持されるプロダクトを作っていくことです。その前提があって、新卒であっても中堅どころであっても、役割に関係なく、ガンガン意見を言える環境であるべきだと考えています。サービスを作っていく上で必要となる技術は「できそうだから勉強してやろうぜ」と受け入れていく、チャレンジ精神を大切にしています。技術的な選択に関しては、トップダウンでやるというよりは、各チームに任せて、そのかわりノウハウだけは社内で共有しようという進め方です。失敗もあるけれども、小さなチャレンジを繰り返していく。して新しいことにチャレンジすることが大切です。ピクシブでは、僕らと一緒にクリエイターに支持されるプロダクトを作りたいエンジニアを募集しています。ここで語った話は、今まで東京だけでやっていたことでした。今は、福岡でも一緒にエンジニアとして働いてもらえるようになりました。ご応募、お待ちしてます!ありがとうございました。edvakf2016年12月から2019年12月までCTOとして全社のシステム設計と組織設計をしていました。»common.min.js.html。