このページは Cloud Translation API によって翻訳されました。

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

アプリを Python 3 にアップグレードする前に、Cloud NDB に移行することをおすすめします。この段階的な移行アプローチにより、移行プロセス全体を通してアプリを機能させ、テスト可能な状態を維持できます。

Cloud NDB は App Engine NDB の機能に代わるものであるため、Datastore モードの Firestore の新機能はサポートされません。新しい Python 3 アプリでは、Cloud NDB ではなく Datastore モードのクライアントライブラリを使用することをおすすめします。

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

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 APIs やクライアントライブラリと整合しています。
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 プロジェクトの移行メモをご覧ください。

コードサンプル

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

移行を開始する前に

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

まだ設定済みでない場合は、Google Cloud と互換性のある Python バージョンを使用するよう Python 開発環境を設定して、独立した Python を作成するためのテストツールをインストールします。
データをキャッシュに保存する必要があるかどうかを判断します。
データをキャッシュに保存する必要がある場合は、サーバーレス VPC アクセスと Memorystore for Redis によってアプリのリージョンがサポートされていることを確認してください。
Datastore モードの権限を確認します。

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

アプリでデータをキャッシュする必要がある場合は、Memorystore for Redis とサーバーレス VPC アクセスには無料枠がないこと、またすべての Google Cloud リージョンをサポートしているとは限らないことをご理解ください。

一般的に:

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

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

App Engine Memcache に移動

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

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

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

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

App Engine に移動

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

サーバーレス VPC アクセスに移動

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

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

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

Datastore モードの権限について

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

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

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

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

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

移行プロセスの概要

Cloud NDB に移行するには:

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

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

Python アプリの更新

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

App Engine Python アプリに Cloud NDB クライアントライブラリをインストールするには:

app.yaml ファイルを更新します。 Python のバージョンに応じた手順に沿って操作します。
Python 2
Python 2 アプリの場合は、grpcio ライブラリと setuptools ライブラリの最新バージョンを追加します。

app.yaml ファイルの例を次に示します。
```
runtime: python27
threadsafe: yes
api_version: 1

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest
```
Python 3
Python 3 アプリの場合は、サポートされている Python 3 バージョンを runtime 要素で指定し、不要な行を削除します。たとえば、app.yaml ファイルは次のようになります。
```
runtime: python310 # or another support version
```
Python 3 ランタイムではライブラリが自動的にインストールされますから、以前の Python 2 ランタイムの組み込みライブラリを指定する必要はありません。移行時に Python 3 アプリが他の以前のバンドルサービスを使用している場合は、app.yaml ファイルをそのままにしてください。
requirements.txt ファイルを更新します。Python のバージョンに応じた手順に沿って操作します。
Python 2
Cloud NDB 用の Cloud クライアントライブラリを、requirements.txt ファイル内の依存関係のリストに追加します。
```
google-cloud-ndb
```
次に pip install -t lib -r requirements.txt を実行して、アプリで使用可能なライブラリのリストを更新します。
Python 3
Cloud NDB 用の Cloud クライアントライブラリを、 requirements.txt ファイル内の依存関係のリストに追加します。
```
google-cloud-ndb
```
Python 3 ランタイムにアプリをデプロイするときに、App Engine によってこれらの依存関係が自動的にインストールされますから、lib フォルダが存在する場合はそれを削除します。
Python 2 アプリでは、lib ディレクトリで指定された組み込みライブラリまたはコピーされたライブラリをアプリで使用している場合、それらのパスを 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 ファイルで指定されたディレクトリ内のすべてのライブラリをアップロードします。

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()

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

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

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

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

次に例を示します。

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 ランタイムコンテキストを取得するミドルウェアオブジェクトを介して各リクエストを渡します。

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 クライアントのランタイムコンテキスト内でミドルウェアオブジェクトを作成します。
```
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 置換

削除された 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` メソッド	なし

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 コンソールのプロジェクトページにアクセスします。

アプリのデプロイ

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

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

次のステップ

実践的なチュートリアルについては、App Engine NDB から Cloud NDB への Codelab の移行をご覧ください。
詳細については、Cloud NDB のドキュメントをご覧ください。