Meesho がダウンタイムなしでペタバイト規模のデータを Cloud CDN に移行した方法

※この投稿は米国時間 2023 年 2 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

Meesho は、毎日数百万人のお客様にサービスを提供しているインドのオンライン マーケットプレイスです。最近、同社はマルチクラウド戦略を採用し、Google Cloud のスケーラブルで信頼性の高いインフラストラクチャを活用して、業務効率の改善、モダナイズ、成長に向けた拡大を進めることにしました。その際、ウェブアプリとモバイルアプリに提供する静的コンテンツをレンダリングするために、数十億もの静的ファイルと画像を Google Cloud に移行する必要がありました。しかし、同社のオブジェクト ストレージ システムにはペタバイト規模のデータがあり、リクエストは 1 日あたり 100 億件にのぼるなか、この巨大な移行をダウンタイムなしで徐々に行う必要がありました。大変な課題です。

このブログ投稿では、Meesho が Storage Transfer Service、Cloud Storage、Cloud CDN を使用して、どのようにこれを成し遂げたのかを見ていきます。また、Cloud Run を使用して、その場で必要に応じて静止画像をサイズ変更することでストレージ容量を節約した方法も紹介します。

CDN の移行要件

クラウド間の移行は、簡単ではありません。それを成し遂げるために、Meesho は以下の要件を割り出しました。

• ペタバイト規模のデータ移行: Meesho は、既存のオブジェクト ストレージ サーバーから Cloud Storage に数十億もの画像ファイルを移行する必要がありました。

• 画像の動的なサイズ変更: ストレージの費用を抑えるために、Meesho はエンドユーザー プラットフォームに応じて画像を動的にサイズ変更し、小さくした画像を Cloud CDN キャッシュに保存する機能を必要としていました。

• 高スループットのデータ移行: ユーザーの要求に応えるために、Meesho は 1 秒あたり数千リクエストのスループットで画像を提供する必要がありました。

• ダウンタイムなし: ダウンタイムが発生すると収益が減る可能性があるため、Meesho はシステムを停止させずに移行を行う必要がありました。

移行アーキテクチャ

上図は、Meesho に実装された CDN 移行アーキテクチャを表しています。この実装では、データ移行が重み付けに基づいて分散され、既存の DNS サーバーからソース ロードバランサと Google 外部 HTTP ロードバランサの両方に向かいます。ソース ロードバランサからはソース オブジェクト ストレージに向かいます。画像はソース オブジェクト ストレージから Google Cloud Storage に転送されています。

CDN キャッシュに保存されている静止画像をユーザーに提供するために、Google 外部 HTTP ロードバランサが Cloud CDN とともにデプロイされました。Google ロードバランサのパブリック IP は、既存の DNS サーバーのエンドポイントとして構成されています。ロードバランサは Cloud Run に接続され、Cloud Storage バケットと通信します。リクエストがエッジのロードバランサに達すると、まずコンテンツが Cloud CDN にあるかどうかをチェックし、最も近いエッジ ネットワークからオブジェクトを返します。画像が Cloud CDN キャッシュにない場合、リクエストは Cloud Run に送られ、Cloud Storage バケットから画像を取得し、必要に応じて画像の動的なサイズ変更を行います。

データ移行

Meesho は Google Cloud の Storage Transfer Service を使用して、利用中のオブジェクト ストレージから Cloud ストレージ バケットにインターネット経由でデータを転送しました。転送するデータのファイル数と合計サイズが膨大だったため、Meesho は Storage Transfer Service ジョブでフォルダやサブフォルダをプレフィックスとして指定し、並列転送を複数回実施しました。

画像の動的なサイズ変更

Meesho は、モバイルやノートパソコンなど複数のエンドユーザー プラットフォームに、複数の解像度で静止画像を配信しています。そこで、各画像を複数の画像解像度で保存するのではなく、1 つの高解像度メザニン画像を保存することにしました。そして、Cloud Run をサーバーレス ネットワーク エンドポイント グループとして Cloud ロードバランサに接続しました。アプリケーションによる画像のリクエストでは、オブジェクトの名前、画像の形式、解像度（解像度 750*450 の abc.jpeg など）を指定します。リクエストした解像度で特定の画像が存在すれば、Cloud Storage バケットからエンドユーザーに返され、Cloud CDN に保存されます。指定した解像度や形式の画像がない場合は、メザニン画像（この例では abc.jpeg）が指定の解像度と形式にサイズ変更されて、Cloud Storage バケットに保存され、エンドユーザーに返されます。動的なサイズ変更と形式設定は、特定の解像度について初回のみ実施されます。

このアーキテクチャでは、「CDN キャッシュミス」のリクエストを大量に処理するため、適切にスケーリングするよう Cloud Run を構成することが重要です。Meesho は次の構成手順を実施しました。

• Cloud Run の 1 つのインスタンスが処理できる同時リクエストの数を構成

• コールド スタート レイテンシを避けるために、ユーザー トラフィックを十分に処理できる最小限の Cloud Run インスタンスを確保

• リージョンの Cloud Run 最大インスタンス サイズの上限を見直し、ピークロードを処理するために必要であれば上限を増加

• アプリケーションがトラフィックの急増を処理するためにすばやく自動スケーリングできるよう、Cloud Run コンテナの起動時間を短くセットアップ

• 処理要件に対応するようにメモリと CPU の構成を最適化

CDN の構成

Cloud CDN は、99% を超える高いキャッシュ ヒット率を確保するよう構成されました。これにより、画像のレンダリングが高速化しただけでなく、Cloud Run の負荷が減り、コストの削減とパフォーマンスの改善につながりました。

ダウンタイム ゼロの実現

Meesho は、確立されている DevOps の原則に沿って、ダウンタイム ゼロの移行を実現しました。

• ロードバランサを監視するために、Cloud Monitoring で指標とアラートを構成しました。

• ステータス アセットを提供する現在のロードバランサに加えて、Cloud ロードバランサの IP アドレスも指すように DNS サーバーを構成しました。

• アプリケーションのパフォーマンスと HTTP レスポンス コードをモニタリングしながら、重み付けに基づく DNS ロード バランシングを採用してトラフィックを徐々に Google Cloud へ移行しました。

• 最初の移行プロセスでは、ピークでない時間帯にトラフィックの 0.1% が分散されました。 指標、エンドユーザー パフォーマンス、レスポンス コードを継続的にモニタリングしました。

• DNS の Google Cloud ロードバランサの重みを増やすことで、2 週間かけて徐々にトラフィックを増加させました。トラフィックを徐々に移すことで、Meesho は健全なキャッシュ ヒット率を確保し、Cloud Run でトラフィック パターンを徐々に学習してシームレスにスケーリングできるようになりました。

Meesho はこの経験から多くのことを学び、同様の移行を行う人に向けて次のようなアドバイスをしています。

• Google Cloud の Storage Transfer Service を使用してデータを転送する際は、転送プロセスを複数回に分割する。

• Google Cloud の新しい証明書に移行する際に問題が生じないようにするため、アプリケーションが証明書を固定しないようにする。

• 段階的な移行プロセスを計画して、Google Cloud へのトラフィックを徐々に増加させる。

まとめ

結果として、Meesho にとって Google Cloud への移行は大成功でした。静止画像を Cloud CDN に移行した後、Meesho は通常の 3 倍のピーク トラフィックが発生する大きなセールを 2 回開催しましたが、まったく問題ありませんでした。CDN への移行により、Meesho は費用を削減し、パフォーマンスを向上させ、静止画像を取得する際のロードバランサのエラーを減らすことができました。Cloud CDN の詳細とご自身の環境での使用方法については、ドキュメントをご覧ください。