Cloud Functions のロケーション

Cloud Functions はリージョナルです。つまり、Cloud Functions の関数を実行するインフラストラクチャは特定のリージョンに配置され、そのリージョン内のすべてのゾーンで冗長的に利用できるように Google によって管理されます。

関数を実行するリージョンを選択するときは、レイテンシと可用性を第一に考慮してください。一般的には、ユーザーに近いリージョンを選択しますが、アプリで使用されている他のプロダクトやサービスのロケーションも考慮する必要があります。使用するサービスが複数のリージョンにまたがっていると、アプリのレイテンシだけでなく、料金にも影響します。

サポートされるリージョン

このセクションのリストで、energy_savings_leaf アイコンは、このリージョンの発電では二酸化炭素排出量が少ないことを示しています。詳しくは、Google Cloud の各リージョンにおけるカーボンフリー エネルギーの利用状況をご覧ください。

次のリージョンでは、Cloud Functions を Tier 1 の料金設定で利用できます。

• asia-east1（台湾）
• asia-east2（香港）第 1 世代のみ
• asia-northeast1（東京）
• asia-northeast2（大阪）
• europe-north1（フィンランド） energy_savings_leaf 第 2 世代のみ
• europe-west1（ベルギー） energy_savings_leaf
• europe-west2（ロンドン）第 1 世代のみ
• us-central1（アイオワ） energy_savings_leaf
• us-east1（サウスカロライナ）
• us-east4（北バージニア）
• us-west1（オレゴン） energy_savings_leaf

次のリージョンでは、Cloud Functions を Tier 2 の料金設定で利用できます。

• asia-east2（香港）第 2 世代のみ
• asia-northeast3（ソウル）
• asia-southeast1（シンガポール）
• asia-southeast2（ジャカルタ）
• asia-south1（ムンバイ）第 2 世代のみ
• australia-southeast1（シドニー）
• australia-southeast2（メルボルン）第 2 世代のみ
• europe-central2（ワルシャワ）
• europe-west2（ロンドン）第 2 世代のみ
• europe-west3（フランクフルト）
• europe-west6（チューリッヒ） energy_savings_leaf
• northamerica-northeast1（モントリオール） energy_savings_leaf
• northamerica-northeast2（トロント） energy_savings_leaf 第 2 世代のみ
• southamerica-east1（サンパウロ） energy_savings_leaf
• southamerica-west1（サンティアゴ、チリ）第 2 世代のみ
• us-west2（ロサンゼルス）
• us-west3（ソルトレイクシティ）
• us-west4（ラスベガス）

特定のプロジェクトの特定のリージョンで使用する関数には一意の名前を付ける必要があります（大文字小文字は区別されません）。リージョンまたはプロジェクトが異なる場合、関数には同じ名前を使用できます。

リージョン変更のベスト プラクティス

デフォルトでは、関数は us-central1 リージョンで実行されます。これは、Cloud Storage バケットなどのイベントソースのリージョンとは異なる場合があるので注意してください。関数の実行リージョンを変更する場合は、このセクションに記載されている関数トリガーのタイプごとの推奨事項に従ってください。

関数の実行リージョンを設定するには、次に示すように、関数定義で region パラメータを設定します。

exports.myStorageFunction = functions
    .region('europe-west1')
    .storage
    .object()
    .onFinalize((object) => {
      // ...
    });

functions.region() でカンマ区切りの複数のリージョン文字列を渡すことで、複数のリージョンを指定できます。推奨手順の詳細については、関数のリージョンを変更するをご覧ください。

HTTP とクライアント呼び出し可能関数

HTTP と呼び出し可能関数に関しては、最初に関数を目的のリージョンまたは最も多くの見込み顧客がいる場所に一番近いリージョンに設定してから、HTTP リクエストを新しい関数にリダイレクトするように元の関数を変更することをおすすめします（元の関数と新しい関数は同じ名前にできます）。HTTP 関数のクライアントがリダイレクトをサポートしている場合は、HTTP リダイレクト ステータス（301）と新しい関数の URL を返すように元の関数を変更します。リダイレクトにうまく対応できないクライアントの場合は、元の関数から新しい関数へリクエストをプロキシするという方法があります。これを行うには、元の関数から新しい関数に対して新しいリクエストを開始します。最終的には、すべてのクライアントが新しい関数を呼び出すようにします。

クライアントサイドでの呼び出し可能関数のロケーション選択

呼び出し可能関数については、HTTP 関数と同じガイドラインに従って、クライアントサイドの呼び出し可能関数の設定を行う必要があります。クライアントサイドでもリージョンを指定できます。us-central1 以外のリージョンで関数を実行する場合は、リージョンを指定する必要があります。

クライアントサイドでリージョンを設定するには、初期化時に目的のリージョンを指定します。

lazy var functions = Functions.functions(region:"europe-west1")

@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];

var functions = firebase.app().functions('europe-west1');

private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");

firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");

firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");

バックグラウンド関数

バックグラウンド関数では、at-least-once（少なくとも 1 回）のイベント配信セマンティックを採用しています。つまり、状況によってはイベントを重複して受け取る可能性があります。そのため、関数の実装は必ずべき等にする必要があります。関数がすでにべき等になっている場合は、同じイベント トリガーを使用して新しいリージョンに関数を再デプロイし、新しい関数がトラフィックを正しく受け取っていることを確認してから古い関数を削除します。この移行中は、どちらの関数もイベントを受信します。関数のリージョンを変更するための推奨のコマンド シーケンスについては、関数のリージョンを変更するをご覧ください。

関数がべき等になっていない場合や、べき等性がリージョンを超えて拡張できない場合は、最初にべき等性を実装してから関数を移動してください。

最適なリージョンに関する推奨事項は、イベント トリガーの種類によって異なります。

Cloud Firestore と Cloud Storage のロケーションに基づくリージョンの選択

関数で使用可能なリージョンは、Cloud Firestore データベースと Cloud Storage バケットで利用可能なリージョンと常に一致するわけではありません。

関数とリソース（データベース インスタンスまたは Cloud Storage バケット）が異なる場所にある場合は、レイテンシと請求額が増加する可能性があります。

同じリージョンがサポートされていない場合の、Cloud Firestore と Cloud Storage で関数がサポートされる最も近いリージョンの対応表を次に示します。