少しでも早く、ストレスなくサービスを利用したい。こうしたユーザーニーズに応えるサービスを構築するには、“画像”の適切な処理・配信が非常に重要な要素です。
本稿で紹介する「ImageFlux」は、Webページに表示する画像のサイズやフォーマットなどを変換するサービスですが、変換に必要な作業はURLにパラメーターを指定するだけと、非常に簡単です。加えて、画像変換・画像配信ともに非常に高速であることも特徴です。同サービスは、イラストコミュニケーション・サービス「pixiv」の運営で知られるピクシブが開発し、さくらインターネット（以下、さくら）がB2B向けに販売していますが、開発の背景には「別の会社とは思えない」ほどの両社の密な協力体制がありました。「ImageFlux」をどのようなチームが作り上げたのか。サービスとしての強みは何か。ピクシブ、さくら両社のキーマン3人に話を聞きました。
ピクシブ株式会社 道井俊介さん（左）、さくらインターネット株式会社 山本真史さん（中央）、さくらインターネット株式会社 秋元任泰さん（右）
※この記事は、さくらインターネット株式会社提供によるPR記事です。
■ 持続的に改善していくために、サービスとして商品化
──どのような経緯でImageFluxを開発したのでしょうか。
道井 ピクシブでは、歴代のエンジニアが独自に画像変換サーバーを作っていました。成果の一部は画像変換プロキシgo-thumberとしてオープンソースで公開しています。そうした取り組みの中で、私自身が画像に向き合って思ったことは、JPEG形式のサムネイル画像を動的に生成するニーズは非常に大きいのですが、一方でエンジニアが画像変換のプログラムをメンテナンスするコストは高くつく、ということです。汎用的に使えるサービスとして提供されている方が便利なのでは、と考えました。
Webサービスを開発するエンジニアで、画像変換や配信“だけ”をしたい人はいないと思います。商品を売りたい、コミュニケーションを作り出したい、創作活動を楽しくしたい。そういった目的が先にあり、目的を実現するために画像変換が必要になります。こうした仕組みは、インフラが備えていた方がいいと考えたのです。
道井俊介さん
ピクシブ株式会社 ImageFlux事業部 部長／ピクシブテクノロジーズ株式会社 執行役員
──なぜ、このサービスをビジネスにしようと考えたのでしょうか。
道井 汎用のいい仕組みができたとしても、インフラのひとつの機能として開発と運用をしていく限り、それはコストになります。ソフトウェアを継続的に開発して良くしていくには持続可能なビジネスプランが必要だと考え、有料サービスとして提供する形を選びました。
──当初はピクシブ社内で開発していたものを、さくらインターネットと共同でサービスとして商品化したのですね。両社の最初の出会いはどのようなものだったのですか。
道井 ImageFluxを作り始めたのが2015年の半ば頃。当時のチームは2人だけでした。サービスを売るにしても営業組織が必要になりますが、僕らは創作活動を支援するためのサービスを運営する企業なので、クラウドサービスをどう売っていけばいいのか見当がつかなかったんです。どうしようかと考えていると、2015年の年末にピクシブとさくらさんがコミュニケーションする機会があり、「一緒にやりたいですね」という話になりました。2016年早々には両社でミーティングを開いています。
秋元 最初の話をしたのがクリスマスで、第1回目のキックオフミーティングが年明けでしたね。
山本 その裏側では、メルカリさんからある要望をいただき、さくらではソリューションを提供するべく、ネットワーク機材の準備を始めていたところでした。
──始まり方がすでに「爆速」な感じですね。メルカリさんの「ある要望」とはどのようなものだったのでしょうか。
秋元 私は以前から営業としてメルカリさんを担当していたのですが、Akamaiのキャッシュヒット率が低下し、Amazon S3のアウトバウンドトラフィックが増加して課金が増大してしまう、という課題を聞いていたんです。そこで中間にキャッシュサーバーを置くソリューションを提案しようとしていました。ただし、キャッシュサーバーがSPOF（単一障害点）になるのはまずい。どういうやり方がいいのか検討している最中でした。
秋元任泰さん
さくらインターネット株式会社 セールスマーケティング本部 営業部マネージャー
山本 その時点ではさくら内部の技術をベースに提案するつもりだったのですが、そこにちょうどImageFluxの話が入ってきました。だったら、これを提供した方がお客様のためになると考えたのです。
──その後、プロジェクトはどのように進んだのでしょうか。
道井 私もメルカリさんに一緒に行ったんです。ほとんど時間がない状況で、なんとか仕様を作って持って行った記憶があります（笑）。
秋元 この段階では、画像変換よりキャッシュサーバーがメインの機能でした。
道井 一方で、もともと画像変換のニーズもあるだろうと思っていました。最近のWebサービスは開発サイクルが早くなっていて、デザインを頻繁に変更する必要があります。半年も経てばトレンドが変わってしまい、「画像サイズを変えて欲しい」という要望が出てきます。さまざまな企業がこうした状況にあり、画像変換は必要とされるサービスだと考えていたのです。
ImageFluxの利用イメージ。ピクシブ株式会社のプレスリリースより。
■ ピクシブ、さくらインターネットが得意技を持ち寄る
──ImageFluxは画像変換だけでなくキャッシュによる高速化も特徴です。速くする仕組みはどのようなものだったのですか。
道井 ひとつはキャッシュサーバーの分散です。画像変換サーバーに関しても内部的な最適化は行っていますが、一番効果的なのはキャッシュサーバーと一緒になっていることです。画像変換には時間がかかりますが、キャッシュに乗っていればオーバヘッドなく配信できます。
──サービス提供にあたり、さくらにとってどのようなチャレンジがありましたか。
山本 とにかく時間がなかったので、自分たちが得意な部分をしっかりやろうと考えました。ものすごいトラフィックが発生するサービスなので、ネットワークもしっかりとしたシステムを組む必要がありましたね。転用可能な既存のラックやサーバーをうまく活用して、スピーディに用意できるように取り組んだんです。ラック、ネットワークについても、弊社サービスの「コンテンツ配信」と「Webアクセラレータ」の隣に置く、という方向性で確保しました。
サーバー環境としては、OSインストールと初期構築まではさくら側でやって、細かな部分はピクシブさんにやってもらっています。デプロイのため、AnsibleのPlaybookを両社共同で作成しています。
山本真史さん
さくらインターネット株式会社 技術本部 コンテンツ配信チーム シニアプロデューサー
道井 両社で「やれるところ」を補いながら進めました。当時のSlackのやりとりを見ると、別の会社が進めていたとは思えない感じです。
秋元 こちらも、ピクシブさんを別会社だと思っていなかったかもしれません（笑）。
山本 判断に悩む部分があったら、「Slackで道井さんに聞けば大丈夫だ」と（笑）。
秋元 「償却が終わったサーバーならすぐ用意できる」とか、スピード感がある中で始められました。
山本 多少古いサーバーでも、台数を並べて分散すれば十分に機能します。工夫してやりくりして、素早いスタートを大事にしたんです。
■ 地理的に離れていても、密に連携するチームができた
──お話を聞くと、ピクシブ、さくらの2社に分かれているとは思えない勢いですね。
道井 オフィスの場所は違っていても、Slackで連絡していると距離感がありません。
山本 開発チームはピクシブさんのオフィスにいます。さくら側の営業やビジネス企画推進は東京にいます。一方で、インフラを管理している弊社メンバーは大阪です。さくら社内だけでも、そもそも地理的に一緒ではありません。
道井 自宅からもけっこうSlackを使っていました。
──密な連携ぶりが伝わってきますね。ところでサービスのマイルストンはどんな形で達成していったのですか。
道井 最初にメルカリさんにサービスを提供したのが2016年のゴールデンウィーク前後でした。その後、同年10月末の「クラウドコンピューティングEXPO」でサービスとしてプレ公開しています。
──プロジェクトが始まって、5ヶ月ほどで形ができていたということですか。
道井 改めて振り返ってみると突貫ですね（笑）。ピクシブ社内で使っていたソフトウェアに加えて、サービスとして提供するために管理画面や課金システムなどはかなり急いで準備した記憶があります。
──10月末にプレ公開ですが、その前後はどんな感じでした。
道井 クラウドコンピューティングEXPOの直前に、当初考えていたサービス名では商標が取れないことが判明してしまったことをよく覚えています（笑）。
秋元 そうでしたね。せっかく印刷したパンフレットが使えない（笑）。
──ピクシブ社内でも共通の画像変換サーバーを使っていたと思いますが、サービス展開でなにか問題はありましたか。
道井 社内では気づかないバグがユーザー企業さんからのフィードバックで見つかることもあり、むしろプラスの部分が大きいと感じています。
山本 バグといえば「金の時計問題」というのがありました。
道井 銀色の時計の商品画像が金の時計に見えるという問題が見つかったんです。ほんのわずかに黄色の発色が勝っていて、そう見えてしまったんです。原因はPNG形式の画像に埋め込まれていたカラープロファイルでした。JPEG形式の画像ではカラープロファイル埋め込みに対応していましたが、PNGにプロファイルが付く例があまりなかったので見落とされていたのです。
──サービス化でバグも顕在化して、それを修正することでより価値が上がっていく、というわけですね。サービス化のプロジェクトを振り返って、感想はいかがですか。
秋元 うまくいったと思っています。さくら社内でも成功事例と位置づけています。お客さまから見てシンプルで分かりやすいサービスだったことが勝因だと考えています。
道井 開発面では、2社で責任範囲をがっちり分けなかったのが、良い影響を与えたと思っています。
秋元 そうですね。開発に参加した全員がそういう考え方でした。
山本 「そっちでやる余裕がない？ ならこっちでやります」という雰囲気です。さくら側にはPaaS的なノウハウがあまりなくて、こちらが全然知らないレイヤーのトピックがぽろっと出てきたり。定例の技術ミーティングを開いているのですが、面白いことを交換する場になっていてメンバーは楽しそうでしたね。
秋元 最初にメルカリさんというビッグユーザーがいたことも良かったかもしれません。
山本 開発側も、「使ってくれるユーザーさんがいる」と分かっていると作りやすいですからね。実は、初期のサーバーは転用で調達していますが、スイッチはぜんぶ10Gのものを新規購入しているんです。大きなコストですが、初期にビッグユーザーが存在してくれていたことで、調達の判断もしやすかったと思います。
秋元 画像変換というニーズは潜在的には大きな需要がありますが、実はニーズが顕在化されていないこともあります。ImageFluxを提案しに行くと、いろんな企業さんが「どストライクのサービスです。こんなサービスが欲しかった！」と言ってくれたりしますから。
■ テック系だけでなく、あらゆるCGMとECサイトが潜在ユーザーに
──ImageFluxのユーザーとなっているのは、どんな企業なのでしょうか。
道井 事例として公表させていただいているお客さまとして、メルカリさん、BASEさん、STORES.JPさんがあります。最近では資生堂さんが採用してくれました。
さくらインターネットのWebサイトには、ImageFluxの導入事例が詳しく紹介されている。
──考えてみると、あらゆるECサイトで画像変換のニーズがありますからね。加えて、いまや多くの企業が自社ECサイトを整備しようとしています。
道井 はい。大手企業のお客さまも今後は出てくると思います。さらに電子コミックにも需要があると考えています。電子書籍のコミックではなく、自社サーバーでマンガを配信するサービスの方ですね。
秋元 ImageFluxのユーザーは大きく2つに分かれています。一つはCGM（SNSなど）。pixivもそうです。写真の投稿機能があるようなサービスの運営会社さんは、ぜひImageFluxに興味を持っていただきたいと思います。もう一つはECサイトです。最初のユーザーのメルカリさんもそうでした。
ECサイトの場合は画像そのものではなく、商品の売買が成立することが目的です。一方、イラスト、コミックでは画像そのものに価値があります。そこで画像にウォーターマーク（電子透かし）を入れたり、画像サイズを勝手に変更できないようにする、という機能も実装しています。
現段階では主に技術へのアンテナが高い会社さんがImageFluxを使ってくださっている傾向がありますが、今後はもっと広いお客さまに使ってもらいたいです。
──市場からの期待も大きそうですね。さらなる取り組みはあるのでしょうか。新プロトコルへの対応ですとか。
道井 HTTP/2には対応しています。今後はQUICがきたりして、Webをひとかたまりで送るような仕組みが出てくる可能性があります。そうした中で、いろいろなコンポーネントを使えるエッジサーバーがあると面白いと思っています。もうひとつ、iOSの新しい画像形式HEIFへの対応も研究しています。新しい画像フォーマットへの対応は通常はコスト要因になりますが、私たちの場合は対応することでサービスの価値を高めることになりますから。
──その他、ImageFlux関連の最新の情報はありますか。
道井 はい。ごく最近リリースした大規模ライブ動画配信サービスの「Image Flux Live Streaming」はぜひご紹介したいですね。簡単に説明すると、配信者からWebRTCストリームで受け取った動画をリアルタイムでHLS（HTTP Live Streaming）に変換し、視聴者に配信するサービスです。
Image Flux Live Streamingの概念図。
WebRTCは非常に遅延の少ないプロトコルですが、反面、大規模な配信には向きません。一方でHLSは、遅延は大きいけれど、大規模配信に適したプロトコルです。つまり、「Image Flux Live Streaming」を介することで、両プロトコルのいいどこどりをして、低遅延かつ大規模な動画配信が可能になるんです。また、配信者は動画の解像度や品質を自由に設定できます。
──配信者はどのような作業をする必要があるのでしょうか。
道井 「Image Flux Live Streaming」に対して配信チャンネル作成APIを実行し、配信管理用URLとチャンネルID、さらに視聴用URLを取得するだけです。本家の「ImageFlux」同様、簡単な操作にはこだわっています。
──画像だけでなく、動画配信もスコープに入っていたのですね。
道井 動画配信が非常に盛り上がっていることは、多くの方が実感しているところだと思います。「Image Flux Live Streaming」が動画配信におけるインフラになってくれることを、僕たちも期待しているんです。
──ありがとうございました。