Cloud NDB に移行する

App Engine のロケーション

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

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

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

注: App Engine コマンドと Google Cloud コンソールで europe-west および us-central と呼ばれる 2 つのロケーションは、Google ドキュメントの他の箇所では、それぞれ europe-west1、us-central1 と呼ばれています。

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

• gcloud app describe コマンドを実行します。

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

OK

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 の次のページをご覧ください。

• Cloud NDB ドキュメント

• 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 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 を使用した基本的なデータベース オペレーション

移行を開始する前に

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

1. まだ設定済みでない場合は、Google Cloud と互換性のある Python バージョンを使用するよう Python 開発環境を設定して、独立した Python を作成するためのテストツールをインストールします。

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

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

4. Datastore モードの権限を確認します。

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

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

一般的に:

• アプリが同じデータを頻繁に読み取る場合、キャッシュ保存によってレイテンシが短縮される可能性があります。

• アプリが処理するリクエストが多いほど、キャッシュ保存に大きな影響を与える可能性があります。

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

App Engine Memcache に移動

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

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

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

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

   App Engine に移動

   リージョンは、ページの上部近くの、アプリの URL のすぐ下に表示されます。

2. アプリが、サーバーレス VPC アクセスでサポートされているリージョンにあることを確認します。

3. [コネクタの作成] ページにアクセスし、[リージョン] リストのリージョンを表示して、アプリが Memorystore for Redis のサポート対象リージョンにあることを確認します。

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

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

1. Google Cloud プロジェクトを作成します。

2. プロジェクト内に新しい App Engine アプリを作成し、サポートされているリージョンを選択します。

3. 新しいプロジェクトでアプリが使用する Google Cloud サービスを作成します。

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

4. アプリを新しいプロジェクトにデプロイします。

Datastore モードの権限について

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

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

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

• アプリと Datastore モードのデータベースが異なる Google Cloud プロジェクトに属する。

• デフォルトの App Engine サービス アカウントに割り当てられているロールを変更した。

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

移行プロセスの概要

Cloud NDB に移行するには:

1. Python アプリを更新します。

   1. Cloud NDB クライアント ライブラリをインストールします。

   2. Cloud NDB からモジュールをインポートするように import ステートメントを更新します。

   3. Cloud NDB クライアントを作成するコードを追加します。クライアントは、アプリの環境変数を読み取り、そのデータを Datastore モードで認証に使用できます。

   4. クライアントのランタイム コンテキストを使用するコードを追加して、スレッド間でキャッシュとトランザクションを分離します。

   5. サポートが終了したメソッドとプロパティを使用するコードを削除または更新します。

2. キャッシュ保存を有効化します。

3. 更新をテストします。

4. App Engine にアプリをデプロイします。

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

Python アプリの更新

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

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

1. 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 ファイルをそのままにしてください。

2. 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 フォルダが存在する場合はそれを削除します。

3. 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）をアプリで使用した場合は、次の手順でアプリをアップデートします。

1. 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
   
   

2. 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	置換
以下から 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 を使用してデータをキャッシュに保存する方法について説明します。

1. サーバーレス VPC アクセスを設定します。

2. Memorystore for Redis を設定します。

3. Redis 接続 URL をアプリに追加します。

4. RedisCache オブジェクトを作成します。

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

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

1. サーバーレス VPC アクセス コネクタを作成します。

2. そのコネクタを使用するようにアプリを構成します。

Memorystore for Redis のセットアップ

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

1. Memorystore で Redis インスタンスを作成します。インスタンスを作成する場合は、次のようにします。

   • [リージョン] で、App Engine アプリが配置されているリージョンと同じリージョンを選択します。

   • [承認済みネットワーク] で、サーバーレス VPC アクセス コネクタが使用しているものと同じネットワークを選択します。

2. 作成する 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 にアプリをデプロイする前に、テスト データベースを設定してローカルで実行するには:

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

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

   また、データベースにプリロードされたデータを使ってテストを開始したい場合は、データをエミュレータにインポートすることもできます。

2. ローカル開発用サーバーを使用してアプリを実行します。

   ローカル開発中に GOOGLE_CLOUD_PROJECT 環境変数が正しく設定されるようにするには、次のパラメータを使用して dev_appserver を初期化します。

   --application=PROJECT_ID

   PROJECT_ID は、Google Cloud プロジェクト ID に置き換えます。プロジェクト ID を確認するには、gcloud config list project コマンドを実行するか Google Cloud コンソールのプロジェクト ページにアクセスします。

アプリのデプロイ

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

1. App Engine でアプリをテストします。

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

次のステップ

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