静的サイトホスティングの為のGCS/GAE/Firebase Hosting比較
各サービスの長所と短所
TL;DR
目次
- 概要
- Google Cloud Storage
- Google App Engine
- Firebase Hosting
- 転送料金面でのサービス比較
- 利用できるリージョンでの比較
- まとめ
1. 概要
HugoやGatsbyなどの静的サイトジェネレータ(Static Site Generator)を使って作成したサイトが増えてきているように感じます。
そこで、そのような静的サイトをホスティングする上で、
- Google Cloud Storage(GCS)のWebサイトホスティング機能
- Google App Engine(GAE)のスタンダード環境
- Firebase Hosting(Blazeプラン)
の3つのサービスについてPros(長所)、Cons(短所)を比較してみたいと思います。
なお、GAEであればプログラム言語ランタイムを利用することで、Firebase HostingであればCloud Functionを利用することで、それぞれの短所を補うことも可能です。
ただ、今回は静的サイトのホスティングが主旨なので、考慮外としています。
2. Google Cloud Storage
pros:
- ストレージ(5GB/month)の無料利用枠(ただしRegional)。
- コンソール画面/gsutilでコンテンツの格納状況の確認が可能。
- コンソール画面/gsutilからコンテンツの追加・削除が可能。
- リクエストURLが“/”で終わってる際のhtmlや、無効なURLをリクエストされた時のhtmlの指定が可能。
cons:
- HTTPS接続をサポートしていない。
- IP制限ができない。
- インターネットへの転送料の無料利用枠がない。
- リライトやリダイレクトの処理ができない
<雑感>
コンソールの画面やgsutilコマンドなどで、直感的にコンテンツを操作できるのは魅力的です。
ただ、HTTPS接続のサポートがないのは、HTTPS接続のサイトが当たり前になっている昨今では少々厳しい感が否めないところです。
3. Google App Engine
pros:
- ストレージ(5GB/month)の無料利用枠。
- HTTPS接続をサポートしている。
- ファイアウォールルールでIP制限が可能。
- インターネットへの転送料に1GB/dayの無料利用枠がある。
cons:
- リクエストURLが“/”で終わってる際のhtmlや、無効なURLをリクエストされた時のhtmlの指定ができない。
- リダイレクトの処理ができない(“常にHTTP -> HTTPS”のリダイレクトは可能)
- ファイル数は10000個まで。
- 1ファイルあたりのサイズは32MBまで。
<雑感>
GAEは非常に優れたスケール性を持つアプリケーション実行環境ですが、静的サイトのホスティング先としても使用できます。
https://cloud.google.com/appengine/docs/standard/php/getting-started/hosting-a-static-website?hl=ja
比較対象の2サービスではIPアドレスでの制限ができないのに対しGAEはファイアウォールルールによってIPアドレスでの制限ができます。
また、インターネットへの転送量に1GB/dayの無料利用枠があります。つまり、1日あたり1GBの転送量が発生しているとすると、月間で約30GBまでの転送量を無料利用枠で利用することが可能です。
ただ、URLが”xxx/”で終わっている際に、”xxx/index.html”の内容を表示する、あるいは無効なリクエストURLだった場合に”/404.html”を表示するような設定はできません。
一応、static_filesの設定を利用すれば、”xxx/”で終わっている際に”xxx/index.html”の内容を表示する、といったことも可能ではありますが、設定が複雑化してしまいます。
runtime: php55
api_version: 1
threadsafe: truehandlers:
- url: /
static_files: index.html
upload: index.html- url: /(.*)/
static_files: \1/index.html
upload: (.*)/index.html- url: /(.*)
static_files: \1
upload: (.*)
これで、xxx/のケースはカバーできますが、xxxで終わるケースはカバーができません。
（そのケースをカバーしようとすると、cssやjsなどの拡張子のときはそのままで、それ以外の時は/index.htmlを表示などの考慮が必要になり、一気に複雑化してしまいます。）
また、ファイル数の上限が10000個までというのと、ファイルサイズは32MBまでというのは場合によっては注意が必要かもしれません。
index.htmlや404時のカスタムエラーレスポンスの問題を除けば、GAEは静的サイトのホスティング先として非常に優れているかと思います。
4. Firebase Hosting
pros:
- ストレージ(1GB/month)の無料利用枠。
- インターネットへの転送料に10GB/monthの無料利用枠がある。
- HTTPS接続をサポートしている。
- 特に設定しなくてもリクエストURLが“/”で終わってる際に、あるいは”/”が省略されても、”index.html”にアクセスできる。
- 無効なURLをリクエストされた時のhtmlの指定が可能。
- リダイレクトや、リライトの設定が可能。
cons:
- IP制限ができない。
- ホストするリージョンがアメリカ、ヨーロッパに限られる。
- (GCSやGAEのリージョンによっては)他の2サービスに比べると転送料金が少し高い。
<雑感>
Firebase Hostingは静的サイトをホスティングする上で非常にバランスの良いサービスかと思います。
リダイレクトやリライト、デフォルトでindex.htmlの省略への対応、無効なURLの際に表示する404ページの設定など、静的サイトをホストティングする上で欲しい機能は一通り揃っています。
IP制限ができないという短所はありますが、モバイルのバックエンド(MBaaS)として発展してきているFirebaseの背景を考えれば、IP制限はあまり需要がないのかとも思います。
5. 転送料金面でのサービス比較
転送料金について比較してみたいと思います。
先述した通り、無料利用枠としては、
- GCSは無料利用枠なし。
- GAEは1GB/dayの無料利用枠がある。
- Firebase Hostingは10GB/monthの無料利用枠がある。
となります。一見、GCSが一番不利なようですが、従量課金の額として見た場合はどうでしょうか。話を単純化するため、GCS、GAEのリージョンはアイオワとします。Firebaseはどこのリージョンでも料金は変わりません。
- GCSは1TBまでは$0.12ですが、1TB～10 TBで$0.11、10 TB～で$0.08（ただし、中国、オーストラリア宛を除く）
- GAEは$0.12/GB
- Firebase Hostingは$0.15/GB
つまり、大量の転送量が発生する場合、一番安くなるのはGCS、次点でGAE、最後にFirebase Hostingとなります。
無料利用枠付近の転送量で済むのならば、GAEかFirebase Hostingが一番安くなるかと思いますが、どちらが安くなるかはケースバイケースです。
日毎のアクセスが平均的であればGAE、月内でアクセス量の変動が多ければFirebase Hostingに軍配があがりそうです。ただ、アクセス量が多くなれば多くなるほどGAEのほうがコストメリットは大きくなっていきます。
6. 利用できるリージョンでの比較
GCSもGAEもFirebase Hostingもキャッシュを利用することで、非常に高速にコンテンツを配信できます。
内容を動的に変える必要がない静的サイトの場合、キャッシュを利用しやすく、キャッシュを利用することで、サイトがホストされている場所がどこであれ、非常に高速に配信できます。
ただ、キャッシュ動作はベストエフォートなので、キャッシングが保証されているわけではありません。また、max-ageを長く指定すれば、それだけキャッシュヒット率も上がるのですが、内容を変更したい場合に、不都合があるので、あまり長い時間を指定するのも得策ではありません。
そうなってくると、サイトをホストするリージョンは、なるべくユーザ側に近い地域にしたいところです。
その観点で見た場合、
- GCSは東京リージョンがある。
- GAEは東京リージョンがある。
- Firebase Hostingは東京リージョンがない。
といった感じになります。
ただ、注意点として、東京リージョンでGCSやGAEを利用した場合の転送料は、
- GCSは1TBまでは$0.14、1TB～10 TBで$0.14、10 TB～で$0.12（ただし、中国、オーストラリア宛を除く）
- GAEは$0.156/GB
となります。つまり、GCSとFirebase Hostingとの差は縮まり、東京リージョンのGAEはFirebase Hostingの転送料を地味に上回ります。
とはいえ、キャッシュ動作は非常に優れているように思えますし、キャッシュにヒットしなかった場合の多少のレイテンシに目を瞑れるのであれば、アイオワなどの通信料が安いリージョンを利用する形で問題ないのではないかと思います。
参考までに手元の環境(東京都)で試してみたところ、以下のようなWaiting(TTFB)の値となりました。
- 東京リージョンのGCSキャッシュmiss時 約60ms、キャッシュhit時 約4ms
- 東京リージョンのGAEキャッシュmiss時 約80ms、キャッシュhit時 約3ms
- アイオワリージョンのGAEキャッシュmiss時 約140ms、キャッシュhit時 約3ms
- Firebase Hosting キャッシュmiss 約190ms、キャッシュhit時 約3ms
いずれのサービスもキャッシュに乗せてしまえば、数msでレスポンスが返ります。ですが、キャッシュにhitしなかった時のレスポンスは、オリジンのリージョンに取得しにいくので、リージョンの位置の差が如実にでました(100ms前後)。
7. まとめ
3サービスの選択基準としては、
- HTTPS接続の要否
- IP制限の要否
- 転送料のコスト
- index.htmlが省略されたURLの処理要否
- 404時のカスタムエラーレスポンスの要否
- リダイレクトやリライトの処理の要否
が判断基準となるのではないかと思います。
大雑把に言えば、
- HTTPでもいいので、大量の転送量のコストを抑えたいのであればGCS(ただし、中国やオーストラリアからのアクセスを除く)
- index.htmlの省略時の厳密な補完、404時のカスタムエラーレスポンスの指定、リダイレクトを使いたければFirebase Hosting
- それ以外のケース、あるいはIP制限を行いたい場合はGAE
といった感じになるのではないでしょうか。
いずれのサービスにも優れた点があるので、要件に合わせて最適なサービスを選択、あるいは組み合わせて利用したいところです。
