ZOZOテクノロジーズ　柴田 翔氏

　ZOZOTOWNに掲載される商品画像には、オリジナルサイズの画像とそれをサムネイル用に縮小したリサイズ画像の2種類がある。S3への移行前、ZOZOテクノロジーズはこれらの画像を全10台以上のオンプレミスサーバで管理していた。移行前のシステムは、オリジナルサイズの画像をリサイズする際、処理前のデータを一時的にためるスプールに蓄積。その後、画像リサイズ処理用サーバに転送してリサイズし、オリジナルサイズの画像とリサイズ画像をそれぞれの専用サーバに分けて格納していた。

　オンプレミスのシステムの運用で課題となったのが、サーバの容量不足だ。ZOZOTOWNの取り扱いショップやブランド数は年々増加しており、それに伴い商品画像も増えてきた。加えて同様のシステムで画像を管理してきたZOZOの古着売買サービス「ZOZOUSED」では、古着の一着一着の状態が異なるという特性から、一着ごとに画像を用意する必要があり、商品画像が増えやすい傾向があった。同社は今までに販売したほぼ全商品の画像を保持しており、移行の時点で保存していた商品画像は、オリジナル画像とリサイズ画像合わせて数億ファイルで、約60TBに上っていた。商品画像は毎日数十万ファイルの規模でアップロードされるが、サーバはスケールアウトできない仕組みになっており、スケーラビリティに欠ける状況だった。画像アップロード数の増加に耐えられるインフラの必要性が高まっていたのだ。

　保守管理の面でも困難が生じていた。故障したディスクの修理やディスクのリプレースの負担が大きく、夜間帯のアラートの60％は画像関連だった。システムの保守期限も近づいていた。

　S3への移行理由は、容量制限がないため画像データの容量を気にしなくていい点と、複数のデバイスに冗長にデータを保存する仕組みで耐久性を高めている点、AWSのソリューションアーキテクトから技術的なサポートが受けられる点だ。「オンプレミス一筋」でクラウドの運用経験がなかった柴田氏にとって、公開ナレッジが多く、運用のノウハウが共有されていることもメリットだった。

　ZOZOテクノロジーズは画像の移行に当たって3つの方法を検討した。1つ目は大量データ転送用ハードウェアの「AWS Snowball」を使って全画像を転送する方法、2つ目はS3に直接全画像を転送する方法、3つ目はS3にオリジナルサイズの画像のみ転送する方法だ。

　当初はSnowballを使った方法を検討していた。Snowballは大量の小容量ファイルをバッチ処理で圧縮せずに転送すると、オーバーヘッドが増加して転送速度が遅くなる特性がある。今回転送する一枚一枚の画像データは、平均128KBと小さい。この場合の転送速度は毎秒10MBになり、転送時間が72.8日かかることが判明した。柴田氏は「データを圧縮処理すれば転送速度は速くなるものの、圧縮処理にも時間がかかる」と説明する。さらにSnowballでの移行には暗号化処理のために、専用クライアントツールの「Snowball クライアント」をインストールしたデバイスが必要で、暗号化処理とそのためのデバイスの準備、Snowball自体の手配など、転送以外にも準備時間がかかるのが難点だった。「Snowballを使うときは、ファイルサイズと内容について考慮する必要がある」（柴田氏）

　オリジナル画像とリサイズ画像を含む60TB分の全画像を、直接S3に転送する方法はどうか。オンプレミスサーバからS3への転送処理には、AWSサービスの統合管理ツール「AWS Command Line Interface」（CLI）と構成管理／変更管理サービスの「AWS Config」を使用する。転送速度の実測値は毎秒42MBと、Snowballを利用したときの約4倍になり、推定転送時間は17.3日になった。新しくハードウェアを用意する必要がないため、予想準備時間もSnowballを使う方法より短縮された。

　さらなる転送時間の短縮のために検討したのが、全画像データの総容量の半分であるオリジナル画像のみS3に転送し、その後サーバレスコンピューティングツール「AWS Lambda」を用いて非同期処理でリサイズする方法だ。転送する画像のデータサイズが約60TBから約30TBとおよそ半分になるため、推定転送時間も8.6日と約半分に短縮された。転送の際にリサイズ用オンプレミスサーバが不要なこともメリットだった。ZOZOが商品画像のオンプレミスサーバからS3への移行方法として最終的に選んだのは、この方法だった。

移行後もLambdaで運用　クラウド移行の効果は

写真2　移行後のシステム構成

　S3への移行後にアップロードされた新規画像のリサイズには、移行時に利用したのと同じLambdaを使用している。移行時に移行後と同じシステムを利用することで、膨大な画像の処理能力を事前に検証できるメリットを狙ったという。ユーザーが新規画像をS3の一次受けバケット（ファイルストレージ）にアップロードすると、Lambdaが画像をリサイズし、S3のオリジナル画像用バケットとリサイズ画像用バケットに分けて格納する（写真2）。

　導入を検証していた当時の課題に、S3のGETリクエストの制限があった。当時のS3には秒間800リクエストの制限があったが、オンプレミスのサーバへのリクエスト数を測ったところ秒間795リクエストと上限に迫っていた。オリジナル画像とリサイズ画像でS3バケットを分けるなど、S3の構成を工夫することで改善したが、万全とは言えなかった。結果的には2018年7月に発表されたS3の性能向上によって秒間5500リクエストまでできるようになり、ひとまず考慮する必要がなくなった。

　スケールアップの難しいオンプレミスサーバからS3へ移行したことで、増え続ける商品画像データの容量を気にせずシステムを運用できるようになった。バックアップサーバを含むオンプレミスサーバの管理からも解放された。画像関連のディスク修理やサーバのリプレース、夜間の保守作業がなくなったことで、保守管理コストを削減できたという。

　リサイズにLambdaを利用することで、画像リサイズ用のサーバを用意する必要がなくなり、リサイズシステムの運用で管理しなければいけないものがコードのみになった。また柴田氏は「従来ずっと同じリサイズシステムを利用していたことによる、メンテナンスやチューニングなどの保守管理の属人化が解消された」と話す。

　S3のGETリクエスト制限問題は解消されたものの、ZOZOTOWNのビジネス規模が急拡大した際には、同様の問題に直面する可能性はゼロではない。クラウドサービスは常に、個別のユーザー企業の要求を全て満たすわけではないからだ。それでも膨大なWebコンテンツのデータ管理について考えるとき、ZOZOTOWNのようなクラウドの導入は一つの選択肢となるのではないだろうか。