概要
プロジェクトを作り直すなんて状況によってはできない話ですが、プロジェクト作成時にリージョン設定を適切な値に変更しなかったためにやるためになった記録です(;´д｀)トホホ
読者対象
- これからFirebaseのプロジェクトを作成する方で、ドキュメントを読まずにサクサク進める性格の方（あの時の自分）
いきなり理由
画像の赤線を見てもらえば一目瞭然です。
要するにFireStoreのリージョンを後から変更できないため、プロジェクト作成時にデフォルトのまま進んでしまっているとアメリカにデータを置くことになるからです。
既存プロジェクトだとFireStoreの利用開始時に設定するかもしれませんが、現在は新規プロジェクト作成時に設定するようです。
実際はFireStore内に変更設定の項目あるんじゃない？と思われる方にドキュメントから引用です。
https://firebase.google.com/docs/firestore/locations
警告: プロジェクトのロケーションを選択した後は、ロケーションを変更できません。 プロジェクトのロケーションの設定は複数のプロダクトに適用されます。
一つ希望を持つとするなら、FireStoreはβ版のためGAの際に変更可能になる可能性もあります。
ただし、変更可能になってもリージョン間のデータ移行で料金が発生すると考えられますので、プロジェクト作成時に確定しておいたほうがいい項目であることに変わりはないかと思います。
この後は東京リージョン(ASIA-NORTHEAST1)が妥当という結論に至った経緯をおまけでまとめておきました。
Firebaseのリージョンは東京でいいか検討
リージョンを決定するのに見るべきポイント
リージョンはアプリのレスポンスに直結してくるため、1つのリージョンで展開する場合、最もユーザーの多い地域に一番近いリージョンを選択するのがセオリー。
（コンテンツはCDNを使うという話でOKですがここでは特定の製品に限定しないため除外）
各クラウドベンダーの共通事項として、リージョン内のデータ移動は無料ということもあり、同じリージョンに配置を固めることがコスト的にもベストである。
同じ AWS リージョン内での S3 バケット間または Amazon S3 から他のサービスへの転送は無料です。
インターネットから Amazon S3 へのデータ転送受信 (イン)
すべてのデータ転送受信 (イン) 0.00USD/GB
- Azure
Azureは明瞭な一律料金。
https://azure.microsoft.com/ja-jp/pricing/details/bandwidth/
同じリージョン内での Azure サービス間のデータ転送は課金されますか?
いいえ。たとえば、同じリージョン内の Azure SQL Database の場合、追加のデータ転送費用はかかりません
受信データ転送
(Azure データ センターに入ってくるデータ): 無料
- GCP
CloudStorageの料金。
https://cloud.google.com/storage/pricing?hl=ja#network-egress
月間使用量 同じロケーション内
0～1 TB 無料
1～10 TB 無料
10 TB～ 無料
月間使用量 上り
0～1 TB 無料
1～10 TB 無料
10 TB～ 無料
Firebaseの主力製品は東京リージョンにそろっているか？
Functionsのリージョンは下記のページから東京リージョンが使えることが判明。
https://firebase.google.com/docs/functions/locations?hl=ja
しかし、Functionsは東京でもFireStoreやStorageがアメリカならFunctionsもデータ転送料の観点からアメリカの方がいい場合もある。
・・・と思ってページを見ていたら次の項目にベストな記述があった(;^_^A
Firestore / Storage リージョン / マルチリージョン 最も近い関数リージョン asia-northeast1（東京） asia-northeast1
Functions、Firestore、Storageが東京にまとまっているなら、基本は東京以外の選択肢はない(；ﾟдﾟ)ゴクリ...
Functionsは各製品のトリガーになるから理解できる部分もあるが、Functions内ではなく外にあるべきではないかと思っていたら、似たようなページが外にあったのでぺたり。
https://firebase.google.com/support/guides/locations?hl=ja#set_a_project_location
今のところ東京リージョン以外にする必要がありそうなのは以下。
- Functionsを使用してホスティングで動的コンテンツを提供する場合
上記のページに以下の記述あり。
重要: HTTP 関数を使用してホスティングで動的コンテンツを提供するには、us-central1 を使用する必要があります。
Hostingを使って、特定のパスにアクセスされた際にFunctionsを使って動的にHTMLを返す場合らしい。
Functionsはサーバーレスによるコールドスタートの発生があるため、ページ表示に数秒かかる可能性があることから使うケースは限定的のはず。
- RealtimeDatabaseのトリガーを使用する場合
RealtimeDatabaseは下記のURLからus-central1のみのため、Functionsでトリガーする場合には同一リージョンに配置したほうがレイテンシの観点から好ましい。
必要であれば検証すべきであるが、私は使用予定がないのでしない(;^_^A
https://firebase.google.com/docs/functions/locations?hl=ja#background_functions
トリガーのタイプ リージョンの推奨事項 Realtime Database 常に us-central1。
まとめ
主力のFunctions、Firestore、Storageが東京にそろっているので、特に理由がない限りプロジェクト作成時に東京(ASIA-NORTHEAST1)に変更することと結論付けます。
新製品が出た際は東京に展開されるまでタイムラグが生じますが、通常時のレスポンスを犠牲にする理由にはならないかなと。
・・・もう失敗することはないけど、それでもFireStoreのリージョンがデータ削除されて構わないので変更可能に早くならないかと願う( ´Д｀)=3 ﾌｩ
<2020/02/10追加>
大阪(asia-northeast2)が追加されています。
ただし、執筆時点ではFunctionsが使用できないため、ちょっと使いにくい状況です。
他の地域を見る限り、Functionsが実行可能なリージョンは少ないので、そのうち来るという楽観視は少し危険かもしれません。