はじめに
GoogleCloudで、静的ウェブサイトをホスティングする方法が大きく分けて2つあります。
それぞれについてメリット・デメリットは何か、どういう状況でどちらを採択すべきか、について検討してみました。
前提整理
- ロードバランサのバックエンドとして、ウェブサイトコンテンツを配置したGCSバケットを指定する
- ウェブサイトコンテンツを配置したGCSバケットを作成し、CloudDNSのCNAMEにてCloudStorageにリクエストを向ける。
それぞれの方法については公式ドキュメントに公開されている通りです
-
1の方法
https://cloud.google.com/storage/docs/hosting-static-website?hl=ja -
2の方法
https://cloud.google.com/storage/docs/hosting-static-website-http?hl=ja
※ 1の方法に関して、コンテンツ配信のためにCloudCDNを使う/使わないで若干の構成差分はありますが、大きな差分ではないため同一とみなして取り扱います。
細かい手順は公式ドキュメントに譲りますが、以下を実施しています
共通
- コンテンツを配置したGCSを公開し、パブリックからアクセス可能にする
- バケットの設定で、Webサイトとしての構成を可能にする
1.の方法
- 外部ロードバランサを作成し、バックエンドとしてバケットを指定する。
2.の方法
- コンテンツを格納するGCSバケット名は、ドメイン名と一致させる(サブドメインも可)
- CloudDNSで、GCSバケット名のレコードとして、CNAMEレコード
c.storage.googleapis.com.を設定する
メリット・デメリット
1の場合
メリット
- CloudLoadBalancingを使っており、SSL証明書によるHTTPS通信のサポートが容易です。
- CoudCDNを用いた構成にすると、キャッシュの制御もすることができます。
デメリット
- 外部IPの予約、グローバルロードバランサの作成などでコストが2の場合よりも高くなります。
- 外部グローバルロードバランサを必要とするため、構築したい環境・GCP組織上の制約に引っかかる可能性があります。
2の場合
メリット
- GCSとDNSだけで完結するため、コストがかからずシンプルな構成にできます。
デメリット
- ロードバランサが無いため、負荷分散は出来ません。
- HTTPSでの接続がサポートされていません。
採択基準
前の章でのデメリットの通り、コストや動きの優劣ではなく機能としての可否で明確な差異があります。
これらを踏まえていくつかのケースでどちらを採択するか考えてみます。
ケースa HTTPS通信が必須の場合
必然的に1を採択することになります。
ケースb リソースをグローバルに配置してはならない(国内のみに限定する)場合
必然的に2を採択することになります。
ケースc 大量のトラフィックが予想される場合
ロードバランサによる負荷分散ができる1を採択するのが望ましいです。
ケースd GCPの内部ネットワーク内向けにホスティングが必要な場合
1の場合には外部ロードバランサを必要としますので、内部ネットワークで配信したいとしたら合致しません。
2の方法で、かつ限定公開DNSゾーンにてCNAMEレコードの設定をすれば、外部から名前解決されることもなく安全に使えます。