Cloud Functions で Cloud Firestore のバックアップREST APIを定期実行
こちらの記事で、なんとか gcloud コマンドを実行しようとしてGoogle Cloud Buildに手を出してしまいましたが、FirestoreのREST APIのexportDocuments をGoogle Cloud Functionsから直接叩いた方が簡単ということに後から気づきました。本記事ではそのやり方を説明します。
[2018/11/14 追記] 公式ドキュメントにも本記事と同様の情報が掲載されました
今回はGoogle Cloud Build周りの作業が完全に無駄な労力になってしまいましたが、知見は今後に活かします 🐶
また、 gcloud コマンドの使い方については次の記事をご覧ください。バックアップをリストアするときに使うことになるはずです。
今回紹介するシンプルなやり方では、以下の手順だけで済みます。
- GAE CronなどからPub/Subのメッセージを定期発行
- Google Cloud FunctionsのPub/Subトリガーから、Cloud FirestoreのバックアップREST APIを実行
- 古いバックアップが削除されるように設定
1. GAE CronなどからPub/Subのメッセージを定期発行
以下の3つ目の手順をご覧ください。
2. Google Cloud FunctionsのPub/Subトリガーから、Cloud FirestoreのバックアップREST APIを実行
次のようなPub/Subトリガー関数を定義して、Cloud FirestoreのバックアップREST APIを叩きます。
次のパッケージのインストールが必要です。
また、最低限次の2つの権限を持ったサービスアカウントのプライベートキーからアクセストークンを生成するのがポイントです。
Cloud Datastore Import Export AdminStorage Object Admin
これも詳しくはこちらの1つ目の手順の中に書きました:
現時点で、Firestore SDKとしてエクスポートメソッドが用意されていないようですが、用意されたらREST APIではなくそれを使った方が良いです。
3. 古いバックアップが削除されるように設定
最後の仕上げに、古いバックアップを削除されるように設定します(もちろん残しておきたい事情があればスキップしてください)。
どのくらい残しておくかですが、Realtime Databaseにならって30日間程度がちょうど良いのではないでしょうか。
30 日のストレージ ライフサイクル
Google Cloud Storage バケットのデフォルトの 30 日オブジェクト ライフサイクル ポリシーを簡単に有効にする構成スイッチをご利用いただけます。有効になっている場合は、バケット内のファイルが 30 日後に自動的に削除されます。これにより、不要になった古いバックアップが削減されるため、ストレージ コストが節約され、バケット ディレクトリが整頓された状態に維持されます。他のファイルを自動バックアップ バケットに配置すると、それらも同じポリシーを使って削除されます。
この30 日オブジェクト ライフサイクル ポリシーをオンにした状態でGCS(Google Cloud Stoage)の [PROJECT_ID]-backups Bucket(Realtime Databaseのバックアップ先)の設定を覗くと、次のようになっています。これをそのまま真似るか、必要に応じてアレンジすれば古いバックアップは消えてくれるようになります。
設定の仕方は、Bucket一覧のLifecycleのデフォルトでNoneとなっている部分を押すと上の編集画面に飛びます。
というわけで、Cloud Functions上でFirestoreバックアップを定期実行したい場合、 gcloud コマンドではなくREST APIを使えば簡単に構築できました 🐶
