ZOZOTOWN、画像データを Amazon S3 に移行

ZOZOTOWN、画像データを Amazon S3 に移行

販売商品数：常時65万点以上
日平均新着商品：3100点以上
ZOZOTOWNに掲載される商品画像：オリジナルサイズの画像とそのサムネイル画像の2種類
これらの画像を全10台以上のオンプレミスサーバで管理していた
移行の時点で保存していた商品画像は、オリジナル画像とリサイズ画像合わせて数億ファイルで、約60TB
商品画像は毎日数十万ファイルの規模でアップロード

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

ZOZOTOWNが「Amazon S3」「AWS Lambda」で数億枚の商品画像を管理
その効果は：60TB以上の画像データをいかに管理するか - TechTargetジャパン クラウド
http://techtarget.itmedia.co.jp/tt/news/1812/26/news02.html#utm_medium=email&utm_source=tt-kn-friday&utm_campaign=20190201&utm_content=AL4

当初は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で運用　クラウド移行の効果は

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

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

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

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

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