2012年入社。ピクシブでインフラエンジニアとして活動している道井俊介。ニックネームは、はるかさん(@harukasan)。入社以来、彼は画像配信インフラに関わり続けています。

サービス開始当初はよく障害を起こしていたpixivの画像配信インフラも、対策を重ね、今では安定した配信を実現しています。2014年には、画像変換のためのGo製プロキシ「go-thumber」をオープンソースとして公開。メルカリの久保達彦氏と共著した技術評論社「nginx実践入門」などの執筆にも関わりました。現在は、さくらインターネットと提携し、メルカリなどで活用されている画像変換のクラウドサービス「ImageFlux」の開発リーダーとして活動しています。

まさに、画像変換の世界で最前線に立っているはるかさん。今回彼に、世界最大規模のイラスト画像配信インフラの中でやってきた取り組みを語っていただきながら、同技術の今とこれからについてお話いただきます。

ユーザーは、画像をテキストと同じように扱う。なのに、画像を扱う技術は未成熟なまま

── はるかさん。まず、サービスが扱っている画像に、どういう問題があるのか？という話を聞かせてもらっていいですか

背景として、Webサービスやアプリのほとんどで、画像を扱わないってことは考えられないですよね。例えばSNSの投稿でも、テキストと同じぐらいの感覚で画像を投稿していると思います。

技術的な面で言えば、テキストについてはそれなりに扱いやすい環境があると思うんですね。Unicode周りはまだまだ課題ありますけど…、普通にデータとして、僕らが扱えるような環境が揃っている。

一方で画像はまだそういうノウハウが蓄積されている段階にない。たとえば、画像の処理で一番多く使われているのはImageMagickですが、毎回どのオプションを利用して、どういう結果が返ってくるか試行錯誤でやっていて、みんな手探りでやり方を探して、実装をしざる得ない状態なんですよ。

── たしかに。SQLのエコシステムみたいなわかりやすいのはないですね

ひとつの解決方法として、ImageMagickをアプリケーション上で直接操作して画像を扱うのではなく、外部のサービスとして切り離して扱うというアプローチがあります。

(※ サムネイルマスタとgo-thumber / Use thumbnail master with go-thumber)

画像をサーバーやストレージに配置し、HTTPプロキシを通して配信するようにする。その際、プロキシで画像変換を行ってしまう方法です。こうすることで、アプリケーション側のソースコードに、画像を変換するための処理を書く必要がなくなります。

アプリケーション側は、画像変換に関わるパラメータを埋め込んだURLを呼び出すだけ。たったそれだけで、変換画像を扱うことができます。

画像変換はどういうアプローチが一般的なのか？

── それって、具体的にどういうOSSを使って対応するものなんです？

ライブドアで公開されていたApacheモジュールの「mod_small_light」が一番有名ですね。

smallightの他にはnginxのimage filter module、nginxにポートされたngx_small_lightなどがあり、そういうものがよく使われるようになってきました。

── 世界的にそんな感じなんですか？

国外では、SaaS (Software as a Service) として提供されているものもあります。

たとえばメジャーなサービスにはCloudinaryやimgixといったものがあります。Cloudinaryは、プロキシというより、画像の管理サービスです。だから、Cloudinaryに画像をアップロードして、そこで変換をするみたいな感じで使うことになるんですね。

SaaSだけで何か作ろうと思うと、Cloudinaryみたいにストレージも込みでやってくれる、みたいなサービスの方が楽なんですよね。画像の検索とかもできますし。CDNで提供している例だとAkamaiも同じような機能を提供していますね。

pixivへ画像変換システムを入れるのは簡単じゃなかった

── イラストSNS「pixiv」に、画像変換システムを導入した話がききたいです

pixivでは最近まで動的に画像を変換するという仕組みを使っていませんでした。さきほど説明したsmalllightのようなものをそのまま入れてしまうとCPUリソースが全然足りないんですね。

サーバーリソース的に厳しく、コスト的に見合わないという問題がありまして、画像変換プロキシはごく一部の画像配信にだけ使っていました。基本的には、イラスト画像のアップロード時に、PHPスクリプトをキューイングして、ImageMagickを使ってサムネイル画像を作る、というレガシーな仕組みで動いてたんですね。

── 具体的に、いつから画像変換の仕組みを作り始めたんですか

画像変換システムをpixiv全体で利用しようという話になったのは2014年になってからです。いくつかのプロダクトを試してはいたんですが「もう自分たちで作ったほうがうまくいくよね」という話になって、ImageMagickを使わず独自で変換のための仕組みを作ることにしました。

ImageMagickは画像ファイルを読み込むと、内部空間用のフォーマットに変換してから画像処理を行います。どんな画像フォーマットであっても一度は内部空間用の共通フォーマットに変換して、また出力用のフォーマットに変換して、みたいな動きになる。ここで無駄が多いんです。

ImageMagickは、レントゲンとか天文とかで使われるようなフォーマットにも対応してて、どんなものでも変換してしまうというのがウリです。しかしpixivはJPEGさえ変換できればよかった。JPEGではY'CbCrという色空間が利用されていて、その色空間のまま変換してしまえば、比較的低コストで処理することができるんです。

それを自分たちで実装したのが「go-thumber」です。go-thumberでは、Y'CbCrの色空間のまま、FFmpegの機能を使って画像の縮小処理を行うんです。これが、pixiv最初の画像変換システムとして使われることになりました。

pixivは、アップロード時に、GIFとかPNGとかを一度JPEGの画像に変換して、サムネイル用のマスターとなるJPEG画像だけを作る。あとは、go-thumberでアプリケーション側からのリクエストに応じて、マスター画像を変換し配信する。という仕組みです。

OSSでは、画像変換の悩みを十分には解決してくれない

── そういえば、なんでgo-thumberってOSS化したんですか？

そもそもpixivは、画像変換に対する要求が高い。サムネイル画像ひとつとっても、JPEG圧縮率をほんの少しいじっただけで、ユーザーさんからネガティブな反応が返ってきたりするんですね。

イラストがビジネスのコアで、これだけの数のイラスト画像を扱う僕たちとしては、他のサービスに比べてもずっと高い、最高の画像変換技術が求められているわけでして。go-thumberをOSS化した理由の１つは、自分たちのサービスだけじゃなく、他のサービスでも使ってもらって、そこでノウハウを得て吸収していくことだったんです。

けど、このアプローチでは上手くいかないかな、と思い始めたんですよ。

── そうなんですか？

go-thumberって、結局はサービスとかに強く依存していて、使おうと思うと、JPEGについての高度な知識が求められているんですね。go-thumberを使った画像変換システムを、どうやってスケールするのか、というノウハウも必要だし、構築と運用は自分たちでやらなきゃいけない以上、それを扱うだけのスキルを持つことが求められるんですよ。

従来の画像変換ソフトウェアにも同じ問題があると思います。いいOSSがあったとしても、構築と運用をしなくちゃいけないから、面倒なことをいっぱい考えなくちゃいけない。本当は、そういう面倒なところもひっくるめて、解決されなくてはいけないはずなのに。