このページの本文へ

さくらの熱量チャレンジ 第35回

サービス規模拡大で画像レスポンスに遅延発生、CDNでは解決できなかった悩みを解決した背景を聞く

映画/ドラマ情報の「Filmarks」、画像配信の悩みをImageFluxで解決

2019年09月19日 08時00分更新

文● 大塚昭彦/TECH.ASCII.jp 写真● 曽根田元

提供: さくらインターネット

  • この記事をはてなブックマークに追加
  • 本文印刷

サービスの拡大で画像配信レスポンスに問題、チューニングの手間も

 こうして順調に規模を拡大してきたFilmarksだが、サービスが成長するにつれてシステム側ではしばしば問題が生じるようになっていたと、SREエンジニアの久松氏は振り返る。画像配信にまつわる問題だ。

アニメ好きである久松氏のイチオシ映画作品は「ノーゲーム・ノーライフ ゼロ」。「公開時に相当ハマってしまい、映画館にはリピートで10回も観に行きました。10回観て、結局は10回とも泣きました(笑)」

 Filmarksはモバイルアプリ版からサービスをスタートした。このアプリ開発において、ユーザーインタフェースの参考としたのはインスタグラムだった。一覧画面(トレンド画面)では文字要素を減らし、代わりに“映画の顔”であるポスター画像をタイル上に並べることで、1画面でより多くの作品が発見できるように工夫している。

 「ちょうどインスタグラムが出てきたころだったのですが、画像に特化して、画像を中心にコミュニケーションするというスタイルに新しさを感じました。Filmarksの場合、映画ポスターには映画のすべてが詰まっていますから、その画像を美しく並べてユーザーに見せるのがいいんじゃないかと考えたのです」(柏木氏)

 FilmarksのバックエンドシステムはAmazon Web Services(AWS)上に構築されており、ポスター画像のオリジナルファイル(元画像)はクラウドストレージの「Amazon S3」に格納している。ただし、たとえば「一覧画面」「詳細画面」など表示するページによって最適な画像サイズは異なるため、それぞれに合わせて元画像を動的にリサイズする処理を行っている。以前は「Amazon EC2」上のRailsアプリケーションが、画像処理ツールのImageMagickをリアルタイムに実行するかたちでリサイズ処理を行っていた。

 「Filmarksのシステムでは、映画情報の登録担当者が1点ずつオリジナルのポスター画像を登録しています。そして画像へのリクエストがあるとS3からオリジナル画像を読み出し、URLのパラメーターに含まれる画像サイズの指定に合わせてリサイズしたうえで、アプリに配信します」(久松氏)

以前のFilmarksバックエンドシステムの構成(概要)。Railsアプリケーション/ImageMagickで動的に画像リサイズ処理を実行しており、サーバー負荷が徐々に高まっていた

 実際にはCDNサービスの「Amazon CloudFront」も併用しているため、頻繁にリクエストのあるポスター画像に関してはCDNにキャッシュ済みの画像が配信される。ただし、サービスの拡大に伴って登録作品数、ユーザー数が増え、キャッシュされていない画像へのリクエストも徐々に増えていった。これによりリサイズ処理のためのサーバー負荷が高まり、画像のレスポンスが遅くなる現象が発生し始めた。最悪の場合は数十秒程度のレスポンス遅延も生じていたという。

 「ただし、画像配信の遅延はアクセス数とは連動しない、ランダムに発生するものでした。大半の画像はCDNキャッシュからレスポンスされますし、オリジナル画像のサイズによってCPU負荷が大きく違ったからです。CPU使用率のアラートが出たので確認するとすでに収まっている、そんな状態が頻発していました」(久松氏)

 大規模障害こそ発生していなかったものの、このままではサービスレベルの低下につながると考えたエンジニアチームは、2018年の2月ごろから対策の検討を始めた。だが、有効な対策はなかなか見つからなかった。

 「たとえばImageMagickのパラメーター調整もやってみましたが、根本的な改善には至りませんでした。われわれは画像の専門家でもなく、そうしたチューニングにエンジニアのリソースを割くよりは、新機能の開発にもっと注力したいというのが本音でした」(久松氏)

導入はシンプル、nginxで画像リクエストのURLを自動変換しただけ

 そんなとき、久松氏は前職の頃に紹介を受けていたImageFluxのことを思い出し、これを試してみてはどうかとエンジニアミーティングで提案した。社内での了解が得られたので、さっそくさくらの担当者に連絡を取り、2018年3月ごろから検証環境を使ってImageFluxのトライアルを開始した。

 ImageFluxを導入するうえでは、当時すでに公開されていたメルカリのユースケースを参考にした。メルカリもキャッシュ用のCDNをフロントに配置したシステム構成であり、Filmarksと構成が似ていたためだと久松氏は説明する。

 従来からリクエストURLのパラメーターに画像サイズの指定が含まれていたため、ImageFluxの組み込みはスムーズに進んだ。具体的には、以前から利用していたWebサーバー「nginx」の設定を変更して画像リクエストのURLを変換し、画像リクエストだけをImageFluxにルーティングする方法をとった。そのため、サーバー上のRailsアプリケーションやモバイルアプリは改修する必要がなかったという。

ImageFlux導入後のシステム構成。「CDNも含め、以前の構成と大きくは変わっていないので安心感があります」(久松氏)

 ImageFluxのトライアルはおおむね順調に進んだが、細かな問題も発覚した。登録されている一部のオリジナル画像で、ファイルの拡張子と実際の画像形式が異なる(たとえば拡張子が.jpg、実体はビットマップ画像のファイル)ため表示できなかったり、ファイルが指定する色空間の違いで変換時に色が変わったりするものがあった。これについてはシステム側で対処するよりもオリジナル画像を修正したほうが早いと判断し、該当する画像ファイルをスクリプトで洗い出したうえで登録しなおした。今後は同様のミスが起きないように、作品登録担当者向けの画像ツールやマニュアルも用意している。

 「画像の色が変わってしまう問題については、われわれでは原因がわからなかったので、さくらさん経由でピクシブさんに問い合わせました。さすがは画像のプロで、原因となった色空間の違いについて詳細に教えていただき助かりました」(久松氏)

 およそ半年間のトライアルと問題修正を終えた2018年10月、Filmarksでは本番システムにImageFluxを適用した。nginxの設定変更だけで済んだため、サービスを停止することなくスムーズに新環境へ移行できた。

カテゴリートップへ

この連載の記事

灯油タンクで残量検知を実現!北海道の生活を守るIoTとは【熱量IoT】#3

動画一覧はこちら!