注: Python 2.7 は、2024 年 1 月 31 日にサポートが終了しました。既存の Python 2.7 アプリケーションは引き続き実行され、トラフィックを受信します。ただし、サポート終了日を過ぎると、ランタイムを使用するアプリケーションの再デプロイが App Engine によってブロックされることがあります。サポートされている最新バージョンの Python に移行することをおすすめします。

Cloud NDB への移行

App Engine のロケーション

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

レイテンシ、可用性、耐久性の要件を満たすことが、アプリを実行するリージョンを選択する際の主な要素になります。一般的には、アプリのユーザーに最も近いリージョンを選択できますが、App Engine が使用可能なロケーションと、アプリが使用するその他の Google Cloud プロダクトおよびサービスのロケーションを考慮する必要があります。使用するサービスが複数のロケーションにまたがっていると、アプリのレイテンシだけでなく、料金にも影響する可能性があります。

設定したアプリのリージョンは変更できません。

すでに App Engine アプリケーションを作成している場合は、次のいずれかの方法でそのリージョンを表示できます。

gcloud app describe コマンドを実行します。
Google Cloud コンソールの App Engine ダッシュボードを開きます。ページの上部にリージョンが表示されます。

Cloud NDB は、App Engine NDB に代わる Python 用のクライアントライブラリです。

App Engine NDB を使用すると、Python 2 アプリで Datastore モードの Firestore（Datastore）データベースにデータを保存し、クエリを実行できます。Cloud NDB では Python 3 アプリで同じデータベースにデータを保存してクエリを実行できます。さらに、そのデータベースを管理するプロダクトとして Datastore を使用します。Cloud NDB ライブラリは App Engine NDB で作成されたデータにアクセスできますが、Cloud NDB を使用して格納された一部の構造化データタイプは App Engine NDB ではアクセスできません。そのため、Cloud NDB への移行は元に戻せないとみなす必要があります。

新しいバージョンの Cloud NDB は Python 3 のみをサポートしています。以前のバージョンは Python 2 と Python 3 の両方をサポートしていました。Python 2 アプリケーションを Python 3 に移行するには、次のことをおすすめします。

Cloud NDB バージョン 1.11.2 に移行します。これは、Python 2 をサポートする最終リリースです。
アプリケーションを Python 3 にアップグレードします。
Cloud NDB の最新の安定版にアップグレードします。

この段階的な移行アプローチにより、移行プロセス全体を通じてアプリが常に機能し、テストが可能となります。

Cloud NDB は、App Engine NDB に精通しており、アプリケーションをモダナイズする Python デベロッパーを対象としています。Cloud NDB に移行すると、Python 3 用の Python 2 アプリの準備に役立ち、必要に応じて後で App Engine から移動できます。

Cloud NDB の詳細については、次のページをご覧ください。

App Engine NDB と Cloud NDB の比較

類似点:

メソッド構文のわずかな違いだけを除いて、Cloud NDB は App Engine NDB でサポートされているほぼすべての機能をサポートします。

相違点:

App Engine Python 2.7 ランタイム固有のサービスに依存する App Engine NDB API は、Cloud NDB から更新または削除されています。
Python 3 と Django の新機能により、google.appengine.ext.ndb.django_middleware は不要になりました。代わりに、数行のコードで独自のミドルウェアを簡単に作成できます。
App Engine NDB では、アプリと Datastore データベースが同じ Google Cloud プロジェクト内に存在している必要があり、App Engine が自動的に認証情報を提供します。Cloud NDB は、クライアントを適切に認証する限り、どのプロジェクトでも Datastore モードのデータベースにアクセスできます。これは他の Google Cloud API やクライアントライブラリと整合しています。
Cloud NDB は、App Engine Memcache サービスを使用してデータをキャッシュに保存しません。

代わりに、Cloud NDB では Memorystore、Redis Labs、またはその他のシステムによって管理される Redis インメモリデータストアにデータをキャッシュ保存できます。現在サポートされているのは Redis データストアのみですが、Cloud NDB は抽象 GlobalCache インターフェースでキャッシュ保存の一般化と定義をしており、追加の具象実装をサポートできます。

Memorystore for Redis にアクセスするには、アプリでサーバーレス VPC アクセスを使用する必要があります。

Memorystore for Redis とサーバーレス VPC アクセスのどちらも無料枠を提供していないため、これらのプロダクトはアプリのリージョンで利用できない場合があります。詳細については、移行を開始する前にをご覧ください。

違いの完全なリストについては、Cloud NDB GitHub プロジェクトの移行メモをご覧ください。

コードサンプル

Cloud NDB を使用した基本的なデータベースオペレーション
App Engine NDB を使用する基本的なデータベースオペレーション

移行を開始する前に

移行を開始する前に、次のことを行います。

データをキャッシュに保存する必要があるかどうかを見極めます。
データをキャッシュに保存する必要がある場合は、サーバーレス VPC アクセスと Memorystore for Redis によってアプリのリージョンがサポートされていることを確認してください。
Datastore モードの権限を確認します。

データをキャッシュに保存する必要があるかどうかを見極める

Memorystore for Redis とサーバーレス VPC アクセスには無料枠がなく、すべての Google Cloud リージョンをサポートしているとは限らないため、アプリでキャッシュに保存する必要があります。

全般:

アプリが同じデータを頻繁に読み取る場合、キャッシュ保存によってレイテンシが短縮される可能性があります。
アプリが処理するリクエストが多いほど、キャッシュ保存に大きな影響を与える可能性があります。

キャッシュに保存されたデータに現在どの程度依存しているかを確認するには、Memcache のダッシュボードで、キャッシュのヒット数とミスヒット数の比率を確認します。比率が高い場合、データキャッシュを使用すると、アプリのレイテンシを大幅に短縮できる可能性があります。

Memcache ダッシュボードを表示する

料金については、Memorysotre の料金とサーバーレス VPC アクセスの料金をご覧ください。

アプリのリージョンの確認

データをキャッシュに保存する必要がある場合は、アプリのリージョンが Memorystore for Redis およびサーバーレス VPC アクセスでサポートされていることを確認します。

Google Cloud コンソールの App Engine ダッシュボードの上部に表示されるアプリのリージョンを確認します。

ダッシュボードを開く

リージョンは、ページの上部近くの、アプリの URL のすぐ下に表示されます。
アプリが、サーバーレス VPC アクセスでサポートされているリージョンにあることを確認します。
[コネクタの作成] ページにアクセスし、[リージョン] リストのリージョンを表示して、アプリが Memorystore for Redis でサポートされているリージョンにあることを確認します。

[コネクタの作成] ページを表示する

Memorystore for Redis およびサーバーレス VPC アクセスでサポートされているリージョンにアプリがない場合は、次のようにします。

Google Cloud プロジェクトを作成します。
プロジェクトに新しい App Engine アプリを作成し、サポートされているリージョンを選択します。
アプリが新しいプロジェクトで使用する Google Cloud サービスを作成します。

また、古いプロジェクトの既存のサービスを使用するようにアプリを更新することもできますが、別のプロジェクトやリージョンでサービスを使用すると料金やリソース使用量が異なることがあります。詳細については、各サービスのドキュメントをご覧ください。
アプリを新しいプロジェクトにデプロイします。

Datastore モードの権限について

Google Cloud サービスでのすべての操作について承認を得る必要があります。たとえば、Datastore モードのデータベースにデータを保存またはクエリするには、データベースへのアクセスが承認されたアカウントの認証情報をアプリで提供する必要があります。

デフォルトでは、App Engine のデフォルトのサービスアカウントの認証情報が提供されます。このアカウントには、アプリと同じプロジェクトのデータベースにアクセスする権限が付与されます。

次の条件のいずれかに該当する場合、認証情報を明示的に指定する別の認証方法を使用する必要があります。

アプリと Datastore モードのデータベースが異なる Google Cloud プロジェクトに属する。
デフォルトの App Engine サービスアカウントに割り当てられているロールが変更されている。

代替認証の方法については、サーバー間の本番環境アプリケーションの認証の設定をご覧ください。

移行プロセスの概要

App Engine NDB から Cloud NDB に移行するには:

Python アプリを更新します。
1. Cloud NDB クライアントライブラリをインストールします。
2. Cloud NDB からモジュールをインポートするように import ステートメントを更新します。
3. Cloud NDB クライアントを作成するコードを追加します。クライアントは、アプリの環境変数を読み取り、そのデータを Datastore モードで認証に使用できます。
4. クライアントのランタイムコンテキストを使用するコードを追加して、スレッド間でキャッシュとトランザクションを分離します。
5. サポートが終了したメソッドとプロパティを使用するコードを削除または更新します。
キャッシュ保存を有効化します。
更新をテストします。
App Engine にアプリをデプロイします。

アプリに変更を加える場合と同様に、トラフィック分割を使用してトラフィックを徐々に増やすことをご検討ください。更新したアプリへのトラフィックを増やす前に、データベースの問題が発生していないか細かくモニタリングして確認してください。

Python アプリの更新

Python 2 アプリ用 Cloud NDB ライブラリのインストール

サードパーティライブラリの保存先ディレクトリ（例: lib/）を作成します。
app.yaml ファイルと同じフォルダに requirements.txt ファイルを作成し、クライアントライブラリの名前を追加します。
```
google-cloud-ndb==1.11.2
```
pip（バージョン 6 以降）と -t <directory> フラグを使用して、前の手順で作成したフォルダにライブラリをインストールします。例:
```
pip install -t lib -r requirements.txt
```
app.yaml ファイルの libraries セクションで RPC ライブラリと setuptools ライブラリを指定します。
```
libraries:
- name: grpcio
  version: 1.0.0
- name: setuptools
  version: 36.6.0
```
まだ作成されていない場合は、app.yaml ファイルと同じフォルダに appengine_config.py ファイルを作成します。次のコードを appengine_config.py ファイルに追加します。
```
# appengine_config.py
import pkg_resources
from google.appengine.ext import vendor

# Set path to your libraries folder.
path = 'lib'
# Add libraries installed in the path folder.
vendor.add(path)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(path)
```
必ず pkg_resources モジュールを使用して、アプリがクライアントライブラリの適切なディストリビューションを使用するようにしてください。

上記の例の appengine_config.py ファイルは、lib フォルダが現在の作業ディレクトリにあることを前提としています。lib が常に現在の作業ディレクトリにあることを保証できない場合は、lib フォルダのフルパスを指定します。例:
```
import os
path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
```

App Engine は、アプリをデプロイするときに、appengine_config.py ファイルで指定されたディレクトリ内のすべてのライブラリをアップロードします。

Python 3 アプリ用 Cloud NDB ライブラリのインストール

App Engine の Python 3 ランタイムは、アプリの requirements.txt ファイルを使用して、アプリにインストールするパッケージとバージョンを決定します。Python 3 ランタイムで Cloud NDB ライブラリをインストールするには、アプリの requirements.txt ファイルに次の行を追加します。

google-cloud-ndb

App Engine は、アプリをデプロイするときに、アプリの requirements.txt ファイルのすべてのライブラリを自動的にアップロードします。

依存関係をローカルにインストールする

アプリをローカルで開発してテストする場合、仮想環境を使用してアプリの依存関係をシステムパッケージから分離することを強くおすすめします。これによりアプリは、アプリの requirements.txt ファイルで宣言した依存関係のみを読み込み、ローカル環境と本番環境の間で依存関係のバージョンを同期します。

Python 2 では、virtualenv を使用して仮想環境を作成できます。

Python 3 では、venv を使用して仮想環境を作成することをおすすめします。

import ステートメントの更新

NDB モジュールの場所は google.cloud.ndb に移動されました。次の表に示すように、アプリの import ステートメントを更新します。

削除	次に変更
`from google.appengine.ext import ndb`	`from google.cloud import ndb`

Cloud NDB クライアントの作成

Google Cloud APIs に基づく他のクライアントライブラリと同様に、Cloud NDB を使用する最初のステップは、Client オブジェクトを作成することです。クライアントには、Datastore モードへの接続に必要な認証情報やその他のデータが含まれています。例:

from google.cloud import ndb

client = ndb.Client()

前述のデフォルトの認可シナリオでは、Cloud NDB クライアントに、Datastore モードの操作が認可された App Engine のデフォルトサービスアカウントの認証情報が含まれています。このデフォルトのシナリオで作業していない場合は、アプリケーションのデフォルト認証情報（ADC）をご覧ください。

クライアントのランタイムコンテキストを使用する

Datastore モードの操作に必要な認証情報のほか、Cloud NDB クライアントには、ランタイムコンテキストを返す context() メソッドが含まれます。ランタイムコンテキストでは、キャッシュとトランザクションのリクエストを他の同時に実行される Datastore モードの操作から分離します。

Datastore モードの操作はすべて、NDB ランタイムコンテキスト内で行う必要があります。モデル定義の作成では Datastore モードを操作しないため、モデルクラスを定義してから、Cloud NDB クライアントを作成してランタイムコンテキストを取得し、リクエストハンドラでランタイムコンテキストを使用してデータベースからデータを取得できます。

例:

datastore/cloud-ndb/quickstart.py

GitHub で表示

from google.cloud import ndb

class Book(ndb.Model):
    title = ndb.StringProperty()

client = ndb.Client()

def list_books():
    with client.context():
        books = Book.query()
        for book in books:
            print(book.to_dict())

マルチスレッド型アプリ

Cloud NDB クライアントが返すランタイムコンテキストは、単一のスレッドにのみ適用されます。アプリが 1 つのリクエストに対して複数のスレッドを使用する場合は、Cloud NDB ライブラリを使用するスレッドごとに個別のランタイムコンテキストを取得する必要があります。

WSGI フレームワークでのランタイムコンテキストの使用

ウェブアプリが WSGI フレームワークを使用する場合、ランタイムコンテキストを取得するミドルウェアオブジェクトを作成してからアプリをミドルウェアオブジェクトにラップすることで、リクエストごとに新しいランタイムコンテキストを自動的に作成できます。

Flask でミドルウェアを使用する下記の例で、

middleware メソッドは、NDB クライアントのランタイムコンテキスト内に WSGI ミドルウェアオブジェクトを作成します。
Flask アプリはミドルウェアオブジェクトにラップされます。
Flask はその後、リクエストごとに新しい NDB ランタイムコンテキストを取得するミドルウェアオブジェクトを介して各リクエストを渡します。

datastore/cloud-ndb/flask_app.py

GitHub で表示

from flask import Flask

from google.cloud import ndb

client = ndb.Client()

def ndb_wsgi_middleware(wsgi_app):
    def middleware(environ, start_response):
        with client.context():
            return wsgi_app(environ, start_response)

    return middleware

app = Flask(__name__)
app.wsgi_app = ndb_wsgi_middleware(app.wsgi_app)  # Wrap the app in middleware.

class Book(ndb.Model):
    title = ndb.StringProperty()

@app.route('/')
def list_books():
    books = Book.query()
    return str([book.to_dict() for book in books])

Django でのランタイムコンテキストの使用

App Engine NDB ライブラリによって提供される Django ミドルウェアは Cloud NDB ライブラリでサポートされていません。このミドルウェア（google.appengine.ext.ndb.django_middleware）をアプリで使用した場合は、次の手順でアプリをアップデートします。

Django のミドルウェアシステムを使用して、リクエストごとに新しいランタイムコンテキストを作成します。

下記の例で、
- ndb_django_middleware メソッドは Cloud NDB クライアントを作成します。
- middleware メソッドは、NDB クライアントのランタイムコンテキスト内にミドルウェアオブジェクトを作成します。
datastore/cloud-ndb/django_middleware.py

GitHub で表示
```
from google.cloud import ndb

# Once this middleware is activated in Django settings, NDB calls inside Django
# views will be executed in context, with a separate context for each request.
def ndb_django_middleware(get_response):
    client = ndb.Client()

    def middleware(request):
        with client.context():
            return get_response(request)

    return middleware
```
Django settings.py ファイルで、google.appengine.ext.ndb.NdbDjangoMiddleware ではなく、作成した新しいミドルウェアをリストするように MIDDLEWARE 設定を更新します。

これで、Django は MIDDLEWARE 設定にリストされたミドルウェアオブジェクトを介して各リクエストを渡し、このオブジェクトはリクエストごとに新しい NDB ランタイムコンテキストを取得します。

削除または変更された NDB API のコードの更新

App Engine 固有の API とサービスに依存する NDB API は、Cloud NDB ライブラリから更新または削除されています。

次のいずれかの NDB API を使用している場合は、コードを更新する必要があります。

google.appengine.ext.ndb.Model とモデルプロパティ
google.appengine.ext.ndb.Key
google.appengine.ext.ndb.query.QueryOptions と PropertyOrder
google.appengine.ext.ndb.utils
google.appengine.api.namespacemanager
google.appengine.api.ext.ndb.tasklets
google.appengine.api.datastore_errors

モデルとモデルプロパティ

google.appengine.ext.ndb.Model の次のメソッドは、利用できなくなった App Engine 固有の API を使用しているため、Cloud NDB ライブラリでは利用できません。

削除された API	置換
`Model.get_indexes` と `Model.get_indexes_async`	なし
`Model._deserialize` と `Model._serialize`	なし
`Model.make_connection`	なし

次の表に、Cloud NDB ライブラリで変更された具体的な google.appengine.ext.ndb.Model プロパティを示します。

プロパティ	変更
`TextProperty`	`google.cloud.ndb.TextProperty` はインデックスに登録できません。`google.cloud.ndb.TextProperty.indexed` を設定しようとすると、`NotImplementedError` が発生します。
`StringProperty`	`StringProperty` は常にインデックスに登録されます。`google.cloud.ndb.StringProperty.indexed` を設定しようとすると、`NotImplementedError` が発生します。
コンストラクタで `name` 引数または `kind` 引数を指定したすべてのプロパティ。	`name` または `kind` は、Python 3 で `unicode` が `str` に置き換えられているため、`str` データ型でなければなりません。

次の表のクラスとメソッドは、利用できなくなった App Engine 固有のリソースを使用しているため、利用できなくなりました。

削除された API	置換
`google.appengine.ext.ndb.msgprop.MessageProperty` と `google.appengine.ext.ndb.msgprop.EnumProperty`	なしこれらのオブジェクトを作成しようとすると、`NotImplementedError` が発生します。
以下から `google.appengine.ext.ndb.model.Property`: `_db_get_value` `_db_set_value` `_db_set_compressed_meaning` `_db_set_uncompressed_meaning` `__creation_counter_global`	なしこれらのメソッドは、変更された Datastore モードのプロトコルバッファに依存します。
`Model.make_connection`	なし

キー

google.appengine.ext.ndb.Key の次のメソッドは、Cloud NDB ライブラリで利用できません。このようなメソッドは、DB Datastore API との間でキーの受け渡しに使用されていましたが、サポートされなくなりました（DB は App Engine NDB の前身です）。

削除された API	置換
`Key.from_old_key` と `Key.to_old_key`	なし

また、次の変更点にもご注意ください。

App Engine NDB	Cloud NDB
種類と文字列 ID は 500 バイト未満である必要があります。	種類と文字列 ID は 1,500 バイト未満である必要があります。
`Key.app()` は、キーの作成時に指定したプロジェクト ID を返します。	`google.cloud.ndb.Key.app()` で返される値は、コンストラクタに渡された元の ID とは異なる場合があります。これは、s~example のような接頭辞付きのアプリ ID は、App Engine の以前の識別子であるためです。example のような同等のプロジェクト ID に置き換えられました。

クエリ

App Engine NDB と同様に、Cloud NDB には QueryOptions クラス（google.cloud.ndb.query.QueryOptions）が用意されており、クエリごとに再定義するのではなく、特定のクエリオプションセットを再利用できます。しかし、Cloud NDB の QueryOptions は google.appengine.datastore.datastore_rpc.Configuration を継承せず、したがって ...datastore_rpc.Configuration メソッドをサポートしません。

さらに、google.appengine.datastore.datastore_query.Order は google.cloud.ndb.query.PropertyOrder に置き換えられました。Order と同様に、PropertyOrder クラスを使用すると、複数のクエリで並べ替え順序を指定できます。PropertyOrder コンストラクタは Order のコンストラクタと同じです。クラスの名前のみが変更されました。

削除された API 置換

削除された API	置換
以下から `google.appengine.datastore.datastore_rpc.Configuration`: `deadline(value)` `on_completion(value)` `read_policy(value)` `force_writes(value)` `max_entity_groups_per_rpc(value)` `max_allocate_ids_keys(value)` `max_rpc_bytes(value)` `max_get_keys(value)` `max_put_entities(value)` `max_delete_keys(value)` これらのメソッドの説明については、ソースコードをご覧ください。	なし
`google.appengine.ext.ndb.Order` 例: `order=Order(-Account.birthday, Account.name)`	`google.cloud.ndb.PropertyOrder` 例: `google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name)`

以下から google.appengine.datastore.datastore_rpc.Configuration:
deadline(value)
on_completion(value)
read_policy(value)
force_writes(value)
max_entity_groups_per_rpc(value)
max_allocate_ids_keys(value)
max_rpc_bytes(value)
max_get_keys(value)
max_put_entities(value)
max_delete_keys(value)

これらのメソッドの説明については、ソースコードをご覧ください。

なし

google.appengine.ext.ndb.Order
例:
order=Order(-Account.birthday, Account.name) google.cloud.ndb.PropertyOrder
例:
google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name)

utils

ndb.utils モジュール（google.appengine.ext.ndb.utils）は利用できなくなりました。このモジュールのほとんどのメソッドは App Engine NDB の内部にあり、新しい ndb の実装の違いにより破棄されたものと、Python 3 の新機能によって廃止されたものがあります。移行のサポートに利用できるメソッドは引き続き少数です。

たとえば、古い utils モジュールの位置デコレータでは、関数またはメソッドの最初の n 個の引数のみを定位置と宣言します。しかし Python 3 では、キーワードのみの引数を使用してこれを行えます。以前は次のように記述していました。

@utils.positional(2)
def function1(arg1, arg2, arg3=None, arg4=None)
  pass

Python 3 では次のように記述できます。

def function1(arg1, arg2, *, arg3=None, arg4=None)
  pass

名前空間

名前空間を使用すると、マルチテナントアプリケーションは、同じ Datastore モードのデータベースを使用しながら各テナントに対応した個別のデータサイロを使用できます。つまり、各テナントは独自の名前空間にデータを保存します。

App Engine 固有の google.appengine.api.namespacemanager を使用する代わりに、Cloud NDB クライアントの作成時にデフォルトの名前空間を指定し、クライアントのランタイムコンテキストで Cloud NDB メソッドを呼び出すことでデフォルトの名前空間を使用します。これは、名前空間をサポートするほかの Google Cloud APIs と同じパターンに従います。

削除された API	置換
`google.appengine.api.namespace_manager.namespace_manager.set_namespace(str)` と `google.appengine.api.namespacemanager.getnamespace()`	client=google.cloud.ndb.Client(namespace="my namespace") with client.context() as context: key = ndb.Key("SomeKind", "SomeId") または key-non-default-namespace=ndb.Key("SomeKind," "AnotherId", namespace="non-default-nspace")
その他すべての `google.appengine.api.namespacemanager` メソッド	なし

tasklets

tasklets で、Return 例外を発生させるのではなく、標準の return ステートメントを使用して結果を返せるようになりました。例:

App Engine NDB ライブラリ	Cloud NDB ライブラリ
@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() raise Return(cart)	@ndb.tasklet def get_cart(): cart = yield CartItem.query().fetch_async() return cart

Cloud NDB では依然として Return 例外を発生させることで結果を返すことはできますが、おすすめしません。

また、次の Tasklets メソッドとサブクラスは、主に Cloud NDB ライブラリでの NDB コンテキストの作成方法と使用方法の変更により使用できなくなりました。

削除された API	置換
以下から `google.appengine.api.ext.ndb.tasklets`: `add_flow_exception` `make_context` `make_default_context` `set_context`	なし
以下から `google.appengine.api.ext.ndb.tasklets`: `QueueFuture` `ReducedFuture` `SerialQueueFuture`	なし

例外

Cloud NDB ライブラリの google.cloud.ndb.exceptions モジュールには、App Engine NDB ライブラリと同じ例外の多くが含まれていますが、古い例外のすべてが新しいライブラリで使用できるわけではありません。次の表に、使用できなくなった例外を示します。

削除された API	置換
以下から `google.appengine.api.datastore_errors`: `BadKeyError` `BadPropertyError` `CommittedButStillApplying` `EntityNotFoundError` `InternalError` `NeedIndexError` `QueryNotFoundError` `ReferencePropertyResolveError` `Timeout` `TransactionFailedError` `TransactionNotFoundError`	`google.cloud.ndb.exceptions`

データキャッシュの有効化

Cloud NDB では Memorystore、Redis Labs、またはその他のシステムによって管理される Redis インメモリデータストアにデータをキャッシュできます。このガイドでは、Memorystore for Redis を使用してデータをキャッシュに保存する方法について説明します。

サーバーレス VPC アクセスを設定します。
Memorystore for Redis を設定します。
Redis 接続 URL をアプリに追加します。
RedisCache オブジェクトを作成します。

サーバーレス VPC アクセスの設定

アプリは、サーバーレス VPC アクセスコネクタを介してのみ Memorystore と通信できます。サーバーレス VPC アクセスコネクタを設定するには:

Memorystore for Redis のセットアップ

Memorystore for Redis をセットアップするには:

Memorystore で Redis インスタンスを作成します。インスタンスを作成する場合は、次のようにします。
- [リージョン] で、App Engine アプリが配置されているリージョンと同じリージョンを選択します。
- [承認済みネットワーク] で、サーバーレス VPC アクセスコネクタが使用しているものと同じネットワークを選択します。
作成する Redis インスタンスの IP アドレスとポート番号をメモします。Cloud NDB のデータキャッシュを有効にするときに、この情報を使用します。

アプリのアップデートのデプロイには、必ず gcloud beta コマンドを使用します。VPC コネクタを使用するようにアプリをアップデートできるのは、beta コマンドだけです。

Redis 接続 URL の追加

Redis キャッシュに接続するには、アプリの app.yaml ファイルに REDIS_CACHE_URL 環境変数を追加します。REDIS_CACHE_URL の値は次の形式をとります。

redis://IP address for your instance:port

たとえば、アプリの app.yaml ファイルに次の行を追加できます。

     env_variables:
      REDIS_CACHE_URL: redis://10.0.0.3:6379

Redis キャッシュオブジェクトの作成と使用

REDIS_CACHE_URL を環境変数として設定した場合、ランタイムコンテキストを設定するときに、1 行のコードで RedisCache オブジェクトを作成し、Client.context() に渡すことでキャッシュを使用できます。

client = ndb.Client()
global_cache = ndb.RedisCache.from_environment()

with client.context(global_cache=global_cache):
  books = Book.query()
  for book in books:
      print(book.to_dict())

REDIS_CACHE_URL を環境変数として設定していない場合は、Redis クライアントを作成し、クライアントを ndb.RedisCache() コンストラクタに渡す必要があります。例:

global_cache = ndb.RedisCache(redis.StrictRedis(host=IP-address, port=redis_port))

Cloud NDB ライブラリはすでに Redis クライアントライブラリに依存しているため、Redis クライアントライブラリへの依存関係を宣言する必要はありません。

Redis クライアントの作成例については、Memorystore サンプルアプリケーションをご覧ください。

アップデートのテスト

App Engine にアプリをデプロイする前に、テストデータベースを設定してローカルで実行するには:

Datastore モードのローカルエミュレータを実行して、データの格納と取得を行います。

アプリが本番環境の Datastore モードではなくエミュレータに接続するように、環境変数の設定手順に従ってください。

データベースにプリロードされたデータでテストを開始する場合は、データをエミュレータにインポートすることもできます。
ローカル開発用サーバーを使用してアプリを実行します。

ローカル開発中に GOOGLE_CLOUD_PROJECT 環境変数が正しく設定されるようにするには、次のパラメータを使用して dev_appserver を初期化します。
```
--application=PROJECT_ID
```
PROJECT_ID は、Google Cloud プロジェクト ID です。プロジェクト ID は、gcloud config list project コマンドの実行または Google Cloud Console のプロジェクトページへのアクセスを行うことで確認できます。

アプリのデプロイ

アプリをローカル開発用サーバーでエラーなしで実行した場合は、次の手順を行います。

App Engine でアプリをテストします。
アプリがエラーなしで実行されている場合、トラフィック分割を使用して、更新したアプリのトラフィックを徐々に増やします。更新したアプリへのトラフィックを増やす前に、データベースの問題が発生していないか細かくモニタリングして確認してください。