- Cloud Runを活用した静的ファイルの提供 - 1
- Google Cloud Runを使用して静的ファイルを提供する方法に関するブログ記事です。リダイレクトとパフォーマンスの向上に重点を置いています。
AIが翻訳した投稿です。
durumis AIが要約した投稿
- Google Cloud Storage(GCS)とCloud Runを連携させて、画像およびWebリソースを効率的に管理し、Webブラウザ環境に合わせて最適化されたファイルを提供するCDNシステムを構築しました。
- アップロードされた画像は、webp、avifなどさまざまな形式に変換および保存され、テキストファイルはgzip、brなどで圧縮することで、ユーザーに最適化されたコンテンツを提供します。
- 世界8つのリージョンにCloud StorageとCloud Runを配置することで、ユーザーの位置に応じて最も近いリージョンからリソースを配信し、レイテンシを最小限に抑え、ユーザーエクスペリエンスを向上させました
前の記事では、ドゥルミスが活用しているCloud Runを使用した静的ファイルの配信について説明しました。
しかし、robots.txtやfavicon.icoなどのファイルとは異なり、ブログにアップロードされる画像ファイルやWebページ自体のリソースは、単純な静的ファイルとして処理することはできません。
そのため、これらのファイルにはGoogle Cloud Storage(以下GCS)と連携するCloud Runを使用する必要があります。
基本的な概念は単純です。リアルタイムにアップロードされる画像ファイルやサイトが更新されたときに新たにアップロードされるリソースはGCSにアップロードし、外部からリクエストが来るとCloud RunはGCSにファイルがあるか確認し、あればファイルを転送する仕組みです。
ただし、実際に動作する仕組みはこれよりもはるかに複雑です。
ドゥルミスでは、画像をGCSにアップロードする際に、基本的に3つの形式で画像ファイルを変換します。
アップロード時にjpegまたはpngの場合、その画像ファイルは基本的にwebpとavifに変換され、同時に保存されます。
すべての画像ファイルは拡張子なしの形式でURLでリクエストされ、リクエストされるとCloud RunはリクエストしているWebブラウザのヘッダーを確認し、avif、webpの順にWebブラウザが受け取ることができる画像ファイルを確認し、2つのファイルを受け取ることができない場合はjpegまたはpngで配信します。 また、単純にフォーマットを変更するだけでなく、Webページで必要なサイズに合わせてリサイズも事前に行って保管/配信します。
ダイアグラム
テキストファイルの場合も同じです。
Webサイトでは、多くのリソースとして画像だけでなく、jsやcssなどのテキストファイルがあります。
jsやcssファイルも画像と同様に、アップロード時にgzipとbrで圧縮して保管し、リクエスト時にWebブラウザがサポートしているファイルをそのまま転送します。
CDNの役割は、コンテンツをキャッシュするだけではありません。 Google Cloud Platform(GCP)の場合、Google Cloud Load Balancer(GCLB)にCloud CDN機能を直接接続できるため、より強力な機能を提供します。
Cloud CDNは、Backend Serviceからデータを受け取って保存し、クライアントに配信します。 このプロセスにおいて、Cloud CDNはクライアントのリクエストヘッダーに応じて最適化されたファイルを配信できます。 これにより、同じURLに対してさまざまな形式のコンテンツを提供できます。
たとえば、'/image/tempImage'という同じURLに対しても
- 画像ファイルの場合
- ブラウザの「Accept」ヘッダーに応じて、異なる形式の画像を配信します。
- Chromeブラウザは一般的に「image/avif,image/webp,image/apng」の順で優先順位を表示します。
- CDNは、この順序に従って可能な形式の画像を提供し、サポートされていない場合はjpegまたはpng形式で置き換えます。
- 同様に、テキストファイルの場合も
- 圧縮方法の優先順位も考慮されます。
- Chromeブラウザは「gzip、deflate、br、zstd」などの圧縮方法をサポートしています。
- たとえば、ドゥルミスサービスの場合、現在gzipとbrをサポートしているため、br圧縮ファイルを優先的に配信します。
これらのCDNの高度な機能により、ユーザーの環境に最適化されたコンテンツを提供でき、これはWebサイトのパフォーマンスとユーザーエクスペリエンスを大幅に向上させることができます。
Cloud CDNであっても、基本的にはCDNからもCloud Runにファイルリクエストが必要になるため、ドゥルミスは世界中の8つのリージョンに事前にCloud StorageとCloud Runを配置し、事前にリソースを配置してそのリソースを配信する方式を採用しています。 したがって、多少のコスト増加と作業量はあるものの、ユーザーははるかに改善されたレイテンシを体験できます。
Cloud CDNを使用しても、基本的には元のサーバー(この場合はCloud Run)からファイルを取得する必要があります。 ドゥルミスは、この構造を最適化して、世界中のユーザーに優れたサービスを提供しています。
ドゥルミスのグローバル最適化戦略:
- 世界中の8つのリージョンにCloud StorageとCloud Runを事前に配置する
- 各リージョンに必要なリソースを事前にデプロイする
- ユーザーリクエスト時に、最も近いリージョンからリソースを配信する
この方式は、多少のコスト増加と追加作業が必要ですが、ユーザーに次のような利点をもたらします。
- 大幅に改善されたレイテンシ
- より高速なコンテンツローディング時間
- 全体的なユーザーエクスペリエンスの向上
この構造を視覚化すると、次のようになります。
この構造により、ドゥルミスは世界中のユーザーに一貫して高速なサービスを提供できます。 ユーザーの位置にかかわらず、最も近いリージョンからコンテンツを取得するため、世界中のどこからでも低レイテンシでサービスを利用できます。
このアプローチは、初期設定とメンテナンスに多くの労力を必要としますが、最終的なユーザーエクスペリエンスを大幅に向上させる利点があります。 特に、グローバルサービスを提供する企業にとって、この構造は競争力のあるサービスを提供する上で大きな助けになります。
今日のCDNのストーリーでは、基本的な概念のみを説明しました。
実際には、詳細な設定部分について説明することもできましたが、クラウドベンダー(GCP、Azure、AWS)によって異なり、さらに...面白くないので、概念の説明を説明しました。
機会があれば、より詳細な部分も説明したいと思います。
次回のストーリーでは、複数のリージョンのCloud Storage(当社はなんと8つ!)はどのように同期されるのかについて説明します。
ありがとうございました。