GCPのDatastoreの利用に関するTipsです。

おしながき

• プロジェクト間でのデータ移行.
• 不要な複合インデックスの削除.

プロジェクト間でのデータ移行.2016/11/21

データ移行が必要になるケース.

　以下のようなケースで、データ移行が必要になります。

• いままで東京以外のリージョンでプロジェクトを運用していたけど、このプロジェクトは日本でしかサービス提供しないのだから、東京リージョンに移してレイテンシを改善したい。
• データをサーバのトラブルから守りたいので、複数リージョンにまたがって保存したい。

　これから作り始めるプロジェクトなら、移行は必要ありません。

概要.

　Datastoreに関しては移行の必要なデータが少なければ、GCPコンソールのDatastore管理ページでバックアップを取ってリストアするのが簡単です。その方法は公式ドキュメント「Restoring data tor another application」に記載されています。この方法ではバックアップ先にGCSを利用します。

手順.

　実際にやってみたのですが、ちょっとつまずいたりしたので、移行の手順を説明します。手順で数値の番号のは、0を除いて、上記の公式ドキュメントと対応させてあります。

0. 前準備を行います。
   1. 移行元のプロジェクトでGCSのバケットを生成しておく。フリーのデフォルトバケットでも十分です。
   2. 移行元プロジェクトのデータストアへの書き込みを無効にする。アプリ本来の機能からの書き込みでコンフリクトが起きるのを防止するためです。
1. バックアップ先バケットに、移行先プロジェクトに読み込み権限を与える。まずはバケットACL。
   1. GCPのコンソールのStorageブラウザでバックアップ先バケットの行の右端の「…」をクリックし、ポップアップメニューから「バケットの権限を編集」をクリック。
   2. ダイアログの「項目を追加」をクリック。
   3. 追加された行で、エンティティは「ユーザー」を選択。
   4. 名前には「移行先プロジェクトID@appspot.gserviceaccount.com」を入力。
   5. アクセス権には「リーダー」を選択。
   6. ダイアログ右下の「保存」をクリック。
2. 同様にデフォルトオブジェクトACLも設定。
   1. バックアップ先バケットの行の右端の「…」をクリックし、ポップアップメニューから「デフォルトのオブジェクトの権限を編集」をクリック。
   2. 上記手順1-2.〜1-6.を同様に繰り返す。
3. データストアの管理ページに移動し、「データストア管理を開く」をクリックし、開いた「Datastore Admin」ウィンドウ(orタブ)でバックアップを作成します。
   1. バックアップしたいカインドを選択。
   2. 「Backup Entities」をクリック。
   3. 確認画面に遷移するので、「Backup Entities」をクリック。

　以上でバックアップの作成はおしまいです。
　ここからは移行先のプロジェクトでのリストア作業です。

4. ここで公式ドキュメントには『データストアへの書き込みを無効にする』旨の記載がありますが、書き込みを無効にすると、リストアによる書込みまで失敗したと判断され、いつまでたってもリストアが終わりません。実際にはリストアしたデータはちゃんと書き込まれているのですが、ログには「書込みが無効になってるから書き込めない」とまで出ています。結果の判断だけが間違っているようなのでデータストアへの書き込みは有効のまま、何もしなくていいようです。ただし書き込み有効でも時々ログにはデータストアアクセス失敗らしいものが出ますし、結構時間がかかります。移行先のプロジェクトはまだ稼動していないなら、だれも書き込む人はいないので、書き込み有効にするしかないと思います。
6. データストア管理ページの「データストア管理を開く」をクリック。
7. 開いた「Datastore Admin」ウィンドウ(orタブ)の中段「Backup」の一番下のテキストに、移行元プロジェクトのバックアップを作成したバケット名を入力する。
8. 「Import Backup Information」をクリックし遷移先のページで、
   1. リストアしたいバックアップを選択。
   2. 「Restore from backup」をクリック。
9. バックアップ内容の確認ページに移動するので、リストアしたくないカインドがあればチェックを外す。
10. リストアにはタスクキューを使用するので、キュー名を確認。そのままでOk。
11. 「Restore」をクリック。
12. (手順4.で書き込みを無効にしていないので、何もすることはありません)

　リストアが完了したかどうかを知る手段が用意されていません。バックアップリストアもGAEのタスクキューを使って実装されていますので、GCPのコンソールてタスクキューを監視するくらいでしょうか。

雑感.

　実際にやってみると、バックアップを生成するのは意外と短時間でできます。しかしリストアは時間がかかります。Datastoreの管理ページから見るとリストアが終わったように見えても、タスクはまだ動き続けていたりとか、Datastoreのインデックス作成が完了するまでが長かったりします。

　移行させたいデータが多ければ、データ移行の機能を新しいプロジェクトのアプリ内に作りこむほうが楽かもしれません。稼働中のプロジェクトを止められないケースでも、データ移行の機能を新しいプロジェクトのアプリ内に作りこむほうがよいでしょう。

不要な複合インデックスの削除.2016/12/01

動機.

　Datastoreの複合インデックス(Composite index)は、datastore-indexes.xmlに定義されます。このファイルを更新してデプロイすれば、新しいインデックスが必要なら自動的に生成されます。
　しかし、過去定義されていた複合インデックスを削除してデプロイしても、Datastore上の複合インデックスは削除されません。これはDatastoreの仕様です。複合インデックスの設計や実装にミスがあれば、いらない複合インデックスがたまってしまうことがあります。

　Datastoreの制限で複合インデックスの上限は、プロジェクトあたり200までです。これはユーザの操作では拡張できません。この上限を超えて複合インデックスを作ろうとすると例外が発生します。そのため不要になった複合インデックスを削除する必要が出てきます。
　またDatastoreは保存した量による課金が行われますが、これにはインデックスも含まれます。無駄にインデックスがあるとそれだけ課金されたり、無料枠が圧迫されたりします。

手順.

　公式ドキュメント「Deleting unused indexes」に記載があります。GAE SDKのコマンドラインツール「appcfg」を使用します。
　GAE SDKをインストールしただけではappcfgにはパスは通っていないので、フルパスで打つなり環境変数pathを編集するなりしてください。appcfgはGAE SDKをインストールしたディレクトリ直下のbinの中にあります。
　公式ドキュメントのappcfg.shはシェルスクリプト版と思われます。Windows版SDKをインストールしているならappcfg.cmdがいるので、代わりにこちらを使います。pathが通っているなら、下記ですね。

appcfg.cmd vacuum_indexes アプリの開発ディレクトリ/war

　実行すると、デフォルトブラウザが起動してプロジェクト管理者でのログインを要求されます。その後必要な機能を実行していいか確認を求められるので応じてください。
　さらにコマンドのほうに戻って、不要と検出されたインデックス1つ1つについて削除確認が行われます。すべての不要インデックスについての確認が完了すると、インデックスの削除が行われます。ここでGCPのコンソールからデータストア-インデックスのページを表示すると、削除中のインデックスを確認できます。

追記.

　datastore-indexed.xmlからは削除したはずなのに、vacuum_indexesコマンドの削除対象にならなかったインデックスがありました。datastore-indexes-auto.xmlに書かれているインデックスは削除対象にならない仕様のようです。datastore-indexes-auto.xmlを手作業で編集して再実行すると、削除できました。

　また複合インテックスの上限はプロジェクトあたり200で、プロジェクト管理者であってもこの上限を変更できませんが、Googleにお願いすると拡張できたりします。ただし拡張しなければならないケースは、大規模なプロジェクトであってもまれで、たいていは複合インデックス(あるいはDatastoreに保存しているデータそのもの)の設計がおかしいので、Googleさんは簡単には応じてくれません。複合インデックスを増やすとパフォーマンスが低下するそうなので、これが理由でしょう。