Firebase CLI コマンドを使用するか、関数のソース コードでランタイム オプションを設定することにより、関数をデプロイ、削除、および変更できます。
関数をデプロイする
関数をデプロイするには、次の Firebase CLI コマンドを実行します。
firebase deploy --only functions
デフォルトでは、Firebase CLI はindex.js
内のすべての関数を同時にデプロイします。プロジェクトに 5 つ以上の関数が含まれている場合は、特定の関数名で--only
フラグを使用して、編集した関数のみをデプロイすることをお勧めします。この方法で特定の機能をデプロイすると、デプロイ プロセスが高速化され、デプロイ クォータに達するのを回避するのに役立ちます。例えば:
firebase deploy --only functions:addMessage,functions:makeUppercase
多数の関数をデプロイすると、標準のクォータを超えて、HTTP 429 または 500 エラー メッセージが表示される場合があります。これを解決するには、関数を 10 個以下のグループでデプロイします。
使用可能なコマンドの完全なリストについては、 Firebase CLI リファレンスを参照してください。
デフォルトでは、Firebase CLI はfunctions/
フォルダーでソース コードを探します。必要に応じて、コードベースまたは複数のファイル セットで関数を整理できます。
関数の削除
次の方法で、以前にデプロイされた関数を削除できます。
- 関数を使用して Firebase CLI で明示的に
functions:delete
- Google Cloud Consoleで明示的に。
- 展開前に
index.js
から関数を削除することにより、暗黙的に。
すべての削除操作では、本番環境から関数を削除する前に確認を求めるプロンプトが表示されます。
Firebase CLI での明示的な関数の削除は、複数の引数と関数グループをサポートし、特定のリージョンで実行されている関数を指定できるようにします。また、確認プロンプトを上書きすることもできます。
# Delete all functions that match the specified name in all regions. firebase functions:delete myFunction
# Delete a specified function running in a specific region. firebase functions:delete myFunction --region us-east-1
# Delete more than one function firebase functions:delete myFunction myOtherFunction
# Delete a specified functions group. firebase functions:delete groupA
# Bypass the confirmation prompt. firebase functions:delete myFunction --force
暗黙的な関数の削除により、 firebase deploy
はindex.js
を解析し、ファイルから削除されたすべての関数を本番環境から削除します。
関数の名前、リージョン、またはトリガーを変更する
本番トラフィックを処理している関数のリージョンまたはトリガーの名前を変更または変更する場合は、このセクションの手順に従って、変更中にイベントが失われないようにしてください。これらの手順を実行する前に、まず関数がべき等であることを確認してください。これは、関数の新しいバージョンと古いバージョンの両方が変更中に同時に実行されるためです。
関数の名前を変更する
関数の名前を変更するには、名前を変更した関数の新しいバージョンをindex.js
で作成し、2 つの個別のデプロイ コマンドを実行します。最初のコマンドは、新しく名前が付けられた関数をデプロイし、2 番目のコマンドは、以前にデプロイされたバージョンを削除します。たとえば、 webhookNew
に変更したいwebhook
という関数がある場合は、次のようにコードを修正します。
// before
const functions = require('firebase-functions');
exports.webhook = functions.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions');
exports.webhookNew = functions.https.onRequest((req, res) => {
res.send("Hello");
});
次に、次のコマンドを実行して、新しい関数をデプロイします。
# Deploy new function called webhookNew firebase deploy --only functions:webhookNew # Wait until deployment is done; now both webhookNew and webhook are running # Delete webhook firebase functions:delete webhook
関数のリージョンを変更する
本番トラフィックを処理する関数の指定されたリージョンを変更する場合は、次の手順を順番に実行することでイベントの損失を防ぐことができます。
- 関数の名前を変更し、必要に応じてその領域を変更します。
- 名前を変更した関数をデプロイします。これにより、両方のリージョン セットで同じコードが一時的に実行されます。
- 前の関数を削除します。
たとえば、現在us-central1
のデフォルト関数リージョンにあるwebhook
という関数があり、それをasia-northeast1
に移行する場合、まずソース コードを変更して関数の名前を変更し、リージョンを修正する必要があります。 .
// before
const functions = require('firebase-functions');
exports.webhook = functions
.https.onRequest((req, res) => {
res.send("Hello");
});
// after
const functions = require('firebase-functions');
exports.webhookAsia = functions
.region('asia-northeast1')
.https.onRequest((req, res) => {
res.send("Hello");
});
次に、次を実行してデプロイします。
firebase deploy --only functions:webhookAsia
現在、2 つの同一の関数が実行されていますwebhook
はus-central1
で実行され、 webhookAsia
はasia-northeast1
で実行されています。
次に、 webhook
を削除します。
firebase functions:delete webhook
現在、 asia-northeast1
で実行されているwebhookAsia
という関数が 1 つだけあります。
関数のトリガー タイプを変更する
時間をかけて Cloud Functions for Firebase デプロイメントを開発すると、さまざまな理由で関数のトリガー タイプの変更が必要になる場合があります。たとえば、あるタイプの Firebase Realtime Database または Cloud Firestore イベントを、一般的なonWrite
イベントからより詳細なonCreate
イベントに変更するなど、別のタイプに変更したい場合があります。
ソース コードを変更してfirebase deploy
を実行するだけでは、関数のイベント タイプを変更することはできません。エラーを回避するには、次の手順で関数のトリガー タイプを変更します。
- ソース コードを変更して、目的のトリガー タイプを持つ新しい関数を含めます。
- 関数をデプロイします。これにより、古い関数と新しい関数の両方が一時的に実行されます。
- Firebase CLI を使用して、本番環境から古い関数を明示的に削除します。
たとえば、従来のonChange
イベント タイプを持つ関数objectChanged
があり、それをonFinalize
に変更したい場合は、最初に関数の名前を変更し、編集してonFinalize
イベント タイプを持つようにします。
// before
const functions = require('firebase-functions');
exports.objectChanged = functions.storage.object().onChange((object) => {
return console.log('File name is: ', object.name);
});
// after
const functions = require('firebase-functions');
exports.objectFinalized = functions.storage.object().onFinalize((object) => {
return console.log('File name is: ', object.name);
});
次に、古い関数を削除する前に、まず次のコマンドを実行して新しい関数を作成します。
# Create new function objectFinalized firebase deploy --only functions:objectFinalized # Wait until deployment is done; now both objectChanged and objectFinalized are running # Delete objectChanged firebase functions:delete objectChanged
ランタイム オプションの設定
Cloud Functions for Firebase では、Node.js ランタイム バージョン、関数ごとのタイムアウト、メモリ割り当て、最小/最大関数インスタンスなどのランタイム オプションを選択できます。
ベスト プラクティスとして、これらのオプション (Node.js バージョンを除く) は、関数コード内の構成オブジェクトで設定する必要があります。このRuntimeOptions
オブジェクトは、関数のランタイム オプションの信頼できる情報源であり、他の方法 (Google Cloud コンソールや gcloud CLI など) で設定されたオプションをオーバーライドします。
開発ワークフローで、Google Cloud コンソールまたは gcloud CLI を使用してランタイム オプションを手動で設定する必要があり、デプロイごとにこれらの値をオーバーライドしたくない場合は、 preserveExternalChanges
オプションをtrue
に設定します。このオプションをtrue
に設定すると、Firebase は、コードに設定されたランタイム オプションを、現在デプロイされている関数のバージョンの設定と次の優先度でマージします。
- オプションは関数コードで設定されます: 外部の変更をオーバーライドします。
- 関数コードでオプションが
RESET_VALUE
に設定されています。外部の変更をデフォルト値で上書きします。 - オプションは関数コードでは設定されていませんが、現在デプロイされている関数で設定されています: デプロイされた関数で指定されたオプションを使用してください。
preserveExternalChanges: true
オプションを使用することは、ほとんどのシナリオでは推奨されません。これは、コードが関数のランタイム オプションの完全な情報源でなくなるためです。使用する場合は、Google Cloud コンソールを確認するか、gcloud CLI を使用して関数の完全な構成を表示します。
Node.js のバージョンを設定する
Firebase SDK for Cloud Functions 2.0.0 以降では、Node.js ランタイムを選択できます。サポートされている Node.js バージョンのいずれかに対応するランタイム環境で、プロジェクト内のすべての関数を排他的に実行することを選択できます。
- Node.js 18
- Node.js 16
- Node.js 14
Node.js のバージョンを設定するには:
初期化中にfunctions/
ディレクトリに作成されたpackage.json
ファイルのengines
フィールドにバージョンを設定します。たとえば、バージョン 18 のみを使用するには、 package.json
で次の行を編集します。
"engines": {"node": "18"}
engines
フィールドは必須です。関数をデプロイして実行するには、サポートされている Node.js バージョンのいずれかを指定する必要があります。
Node.js ランタイムをアップグレードする
Node.js ランタイムをアップグレードするには:
- プロジェクトがBlaze 料金プランに含まれていることを確認してください。
- Firebase CLI v9.17.0 以降を使用していることを確認してください。
- 初期化中に
functions/
ディレクトリに作成されたpackage.json
ファイルのengines
値を変更します。たとえば、バージョン 16 からバージョン 18 にアップグレードする場合、エントリは次のようになります:"engines": {"node": "18"}
- 必要に応じて、 Firebase Local Emulator Suiteを使用して変更をテストします。
- Firebase CLI v11.18.0 以降を使用して関数を再デプロイします。
スケーリング動作の制御
デフォルトでは、Cloud Functions for Firebase は受信リクエストの数に基づいて実行中のインスタンスの数をスケーリングし、トラフィックが減少したときにゼロ インスタンスにスケールダウンする可能性があります。ただし、アプリで待機時間を短縮する必要があり、コールド スタートの回数を制限したい場合は、コンテナー インスタンスの最小数を指定してウォーム状態を維持し、要求を処理する準備を整えることで、この既定の動作を変更できます。
同様に、受信リクエストに応じてインスタンスのスケーリングを制限する最大数を設定できます。この設定を使用して、コストを制御したり、データベースなどのバッキング サービスへの接続数を制限したりします。
コールドスタートの回数を減らす
ソース コードで関数のインスタンスの最小数を設定するには、 runWith
メソッドを使用します。このメソッドは、 minInstances
の値を定義するRuntimeOptions
インターフェースに準拠する JSON オブジェクトを受け入れます。たとえば、次の関数は最低 5 つのインスタンスを保温に設定します。
exports.getAutocompleteResponse = functions
.runWith({
// Keep 5 instances warm for this latency-critical function
minInstances: 5,
})
.https.onCall((data, context) => {
// Autocomplete a user's search term
});
minInstances
の値を設定する際には、次の点を考慮してください。
- Cloud Functions for Firebase が
minInstances
設定を超えてアプリをスケーリングすると、そのしきい値を超えるインスタンスごとにコールド スタートが発生します。 - コールド スタートは、トラフィックが急増するアプリに最も深刻な影響を与えます。アプリにスパイク トラフィックがあり、トラフィックが増加するたびにコールド スタートが減少するように
minInstances
値を十分に高く設定すると、レイテンシが大幅に短縮されます。トラフィックが一定しているアプリの場合、コールド スタートがパフォーマンスに深刻な影響を与える可能性はほとんどありません。 最小限のインスタンスを設定することは、本番環境では意味がありますが、通常、テスト環境では避けるべきです。テスト プロジェクトでゼロにスケールし、本番プロジェクトでのコールド スタートを減らすには、
FIREBASE_CONFIG
環境変数に基づいてminInstances
を設定できます。// Get Firebase project id from `FIREBASE_CONFIG` environment variable const envProjectId = JSON.parse(process.env.FIREBASE_CONFIG).projectId; exports.renderProfilePage = functions .runWith({ // Keep 5 instances warm for this latency-critical function // in production only. Default to 0 for test projects. minInstances: envProjectId === "my-production-project" ? 5 : 0, }) .https.onRequest((req, res) => { // render some html });
関数のインスタンスの最大数を制限する
関数のソース コードで最大インスタンスを設定するには、 runWith
メソッドを使用します。このメソッドは、 maxInstances
の値を定義するRuntimeOptions
インターフェースに準拠する JSON オブジェクトを受け入れます。たとえば、次の関数は、仮想のレガシー データベースを圧倒しないように、100 インスタンスの制限を設定します。
exports.mirrorOrdersToLegacyDatabase = functions
.runWith({
// Legacy database only supports 100 simultaneous connections
maxInstances: 100,
})
.firestore.document("orders/{orderId}")
.onWrite((change, context) => {
// Connect to legacy database
});
HTTP 関数がmaxInstances
制限までスケールアップされた場合、新しいリクエストは 30 秒間キューに入れられ、それまでに使用可能なインスタンスがない場合、 429 Too Many Requests
の応答コードで拒否されます。
最大インスタンス設定を使用するためのベスト プラクティスの詳細については、 maxInstances
を使用するためのこれらのベスト プラクティスを確認してください。
タイムアウトとメモリ割り当てを設定する
場合によっては、関数に長いタイムアウト値または大規模なメモリ割り当てに関する特別な要件がある場合があります。これらの値は、Google Cloud Console または関数のソース コード (Firebase のみ) で設定できます。
関数のソース コードでメモリ割り当てとタイムアウトを設定するには、Firebase SDK for Cloud Functions 2.0.0 で導入されたrunWith
パラメータを使用します。このランタイム オプションは、 timeoutSeconds
およびmemory
の値を定義するRuntimeOptions
インターフェースに準拠する JSON オブジェクトを受け入れます。たとえば、次のストレージ関数は 1GB のメモリを使用し、300 秒後にタイムアウトします。
exports.convertLargeFile = functions
.runWith({
// Ensure the function has enough memory and time
// to process large files
timeoutSeconds: 300,
memory: "1GB",
})
.storage.object()
.onFinalize((object) => {
// Do some complicated things that take a lot of memory and time
});
timeoutSeconds
の最大値は540
または 9 分です。関数に割り当てられるメモリの量は、関数に割り当てられた CPU に対応します。詳細は、次のmemory
の有効な値のリストを参照してください。
-
128MB
— 200MHz -
256MB
— 400MHz -
512MB
— 800MHz -
1GB
— 1.4GHz -
2GB
— 2.4GHz -
4GB
— 4.8GHz -
8GB
— 4.8GHz
Google Cloud Console でメモリ割り当てとタイムアウトを設定するには:
- Google Google Cloud Console で、左側のメニューから [ Cloud Functions ] を選択します。
- 関数リストで名前をクリックして、関数を選択します。
- トップメニューの編集アイコンをクリックします。
- [割り当てられたメモリ] というラベルの付いたドロップダウン メニューからメモリ割り当てを選択します。
- [詳細] をクリックして詳細オプションを表示し、[タイムアウト]テキスト ボックスに秒数を入力します。
- [保存]をクリックして関数を更新します。