Python 2 App Engine Cloud NDB およびCloud Tasks アプリから Python 3 および Cloud Datastore へ（モジュール 9）

1. 概要

サーバーレス移行ステーション シリーズの Codelab（ご自分のペースで進められる実践型のチュートリアル）と関連動画は、主にレガシー サービスからの移行を 1 つ以上行うことで、Google Cloud サーバーレスのデベロッパーがアプリケーションをモダナイズできるよう支援することを目的としています。これにより、アプリの移植性が向上し、オプションと柔軟性が高まるため、幅広い Cloud プロダクトとの統合やアクセスが可能になり、新しい言語リリースへのアップグレードが容易になります。このシリーズは、当初は初期の Cloud ユーザー、主に App Engine（標準環境）のデベロッパーを対象としていましたが、Cloud Functions や Cloud Run などの他のサーバーレス プラットフォームや、該当する場合は他のプラットフォームも対象とするほど幅広くなっています。

この Codelab の目的は、Module 8 のサンプルアプリを Python 3 に移植し、Datastore（Datastore モードの Cloud Firestore）アクセスを Cloud NDB からネイティブの Cloud Datastore クライアント ライブラリに切り替え、Cloud Tasks クライアント ライブラリの最新バージョンにアップグレードすることです。

モジュール 7 で push タスクに Task Queue の使用を追加し、モジュール 8 でその使用を Cloud Tasks に移行しました。モジュール 9 では、Python 3 と Cloud Datastore に進みます。pull タスクにタスクキューを使用している場合は、Cloud Pub/Sub に移行します。代わりにモジュール 18 ～ 19 を参照してください。

Task Queue を使用していない場合

アプリで App Engine タスクキュー サービスを使用していない場合は、モジュール 7 ～ 9（push タスク）と 18 ～ 19（pull タスク）をスキップするか、タスクキューの移行に慣れるための演習としてこれらの Codelab を実行してください。

GCP コンソールの

• モジュール 8 のサンプルアプリを Python 3 に移植する
• Cloud NDB から Cloud Datastore クライアント ライブラリに Datastore アクセスを切り替える
• 最新バージョンの Cloud Tasks クライアント ライブラリにアップグレードする

必要なもの

• 有効な GCP 請求先アカウントを持つ Google Cloud Platform プロジェクト
• 基本的な Python スキル
• 一般的な Linux コマンドに関する実践的な知識
• App Engine アプリの開発とデプロイに関する基礎知識
• 正常に機能するモジュール 8 App Engine アプリ: モジュール 8 Codelab を完了する（推奨）か、リポジトリからモジュール 8 アプリをコピーする

アンケート

このチュートリアルの利用方法をお選びください。

全体を通して読むだけ 内容を読んで演習をやり遂げる

Python のご利用経験はどの程度ありますか？

初心者 中級者 上級者

Google Cloud サービスの使用経験はどの程度ありますか？

初心者 中級者 上級者

2. 背景情報

モジュール 7 では、Python 2 Flask App Engine アプリで App Engine Task Queue push タスクを使用する方法について説明します。モジュール 8 では、そのアプリを Task Queue から Cloud Tasks に移行します。モジュール 9 では、その移行を継続し、アプリを Python 3 に移植するとともに、Datastore アクセスを Cloud NDB の使用からネイティブの Cloud Datastore クライアント ライブラリに切り替えます。

Cloud NDB は Python 2 と 3 の両方で動作するため、App Engine ユーザーがアプリを Python 2 から 3 に移植するのに十分です。クライアント ライブラリを Cloud Datastore に移行することは完全に任意です。検討すべき理由は 1 つだけです。Cloud Datastore クライアント ライブラリをすでに使用している App Engine 以外のアプリ（および/または Python 3 App Engine アプリ）があり、1 つのクライアント ライブラリで Datastore にアクセスするようにコードベースを統合したい場合です。Cloud NDB は、Python 2 App Engine デベロッパー向けに Python 3 移行ツールとして作成されたため、Cloud Datastore クライアント ライブラリを使用するコードがまだない場合は、この移行を検討する必要はありません。

最後に、Cloud Tasks クライアント ライブラリの開発は Python 3 でのみ継続されるため、最終版の Python 2 バージョンの 1 つから Python 3 の同等バージョンに「移行」します。幸いなことに、Python 2 からの破壊的変更はないため、ここで他に何も行う必要はありません。

このチュートリアルでは、次の手順について説明します。

1. セットアップ / 事前作業
2. 構成の更新
3. アプリケーション コードを変更する

3. セットアップ/事前作業

このセクションでは、次の方法を説明します。

1. Cloud プロジェクトを設定する
2. ベースライン サンプルアプリを入手する
3. ベースライン アプリを（再）デプロイして検証する

これらの手順により、動作するコードから開始し、Cloud サービスへの移行の準備が整います。

1. プロジェクトのセットアップ

モジュール 8 Codelab を完了している場合は、同じプロジェクト（とコード）を再利用します。または、新しいプロジェクトを作成するか、別の既存のプロジェクトを再利用することもできます。プロジェクトにアクティブな請求先アカウントがあり、App Engine アプリが有効になっていることを確認します。この Codelab では、PROJECT_ID 変数が表示されるたびにプロジェクト ID を使用するため、プロジェクト ID を確認しておきます。

2. ベースライン サンプルアプリを入手する

前提条件の 1 つは、機能するモジュール 8 の App Engine アプリを用意することです。モジュール 8 の Codelab を完了するか（推奨）、リポジトリからモジュール 8 のアプリをコピーします。ご自身のサンプルアプリか当社のものかを問わず、モジュール 8 コードが出発点（「START」）になります。この Codelab では、移行の手順を説明します。最後に、モジュール 9 のリポジトリ フォルダ（「FINISH」）の内容に似たコードが完成します。

• 開始: モジュール 8 リポジトリ
• FINISH: モジュール 9 リポジトリ
• リポジトリ全体（クローン作成または ZIP をダウンロード）

どのモジュール 7 アプリを使用する場合でも、フォルダは次のようになります。lib フォルダも含まれている可能性があります。

$ ls
README.md               appengine_config.py     requirements.txt
app.yaml                main.py                 templates

3. ベースライン アプリを（再）デプロイして検証する

モジュール 8 のアプリをデプロイする手順は次のとおりです。

1. lib フォルダが存在する場合は削除し、pip install -t lib -r requirements.txt を実行して lib を再作成します。開発マシンに Python 2 と 3 の両方がインストールされている場合は、代わりに pip2 を使用する必要があるかもしれません。
2. gcloud コマンドライン ツールをインストールして初期化し、その使用方法を確認してください。
3. （省略可）発行する gcloud コマンドごとに PROJECT_ID を入力したくない場合は、gcloud config set project PROJECT_ID を使用して Cloud プロジェクトを設定します。
4. gcloud app deploy を使用してサンプルアプリをデプロイする
5. アプリが問題なく想定どおりに動作することを確認します。モジュール 8 の Codelab を完了している場合は、アプリに上位の訪問者と最新の訪問が表示されます（下図を参照）。下部には、削除される古いタスクが表示されます。

4. 構成を更新する

requirements.txt

新しい requirements.txt は、モジュール 8 のものとほぼ同じですが、google-cloud-ndb を google-cloud-datastore に置き換えるという大きな変更が 1 つあります。requirements.txt ファイルが次のようになるように変更します。

flask
google-cloud-datastore
google-cloud-tasks

この requirements.txt ファイルにはバージョン番号が含まれていないため、最新バージョンが選択されます。互換性の問題が発生した場合は、バージョン番号を使用してアプリの動作バージョンをロックインするのが一般的です。

app.yaml

第 2 世代の App Engine ランタイムは、2.x のような組み込みのサードパーティ ライブラリをサポートしていません。また、組み込みでないライブラリのコピーもサポートしていません。サードパーティ パッケージの要件は、requirements.txt にリストすることだけです。その結果、app.yaml の libraries セクション全体を削除できます。

もう 1 つの更新は、Python 3 ランタイムでは独自のルーティングを行うウェブ フレームワークを使用する必要があることです。そのため、すべてのスクリプト ハンドラを auto に変更する必要があります。ただし、すべてのルートを auto に変更する必要があり、このサンプルアプリから提供される静的ファイルはないため、ハンドラは不要です。したがって、handlers セクション全体を削除します。

app.yaml で必要なのは、ランタイムをサポートされている Python 3 のバージョン（3.10 など）に設定することだけです。この変更により、新しい短縮形の app.yaml は次の 1 行になります。

runtime: python310

appengine_config.py と lib を削除する

次世代の App Engine ランタイムでは、サードパーティ パッケージの使用方法が変更されます。

• 組み込みライブラリは、Google によって審査され、App Engine サーバーで利用可能になったライブラリです。これは、デベロッパーがクラウドにデプロイできない C/C++ コードが含まれているためです。これらのライブラリは、第 2 世代のランタイムでは利用できなくなりました。
• 第 2 世代ランタイムでは、組み込みでないライブラリのコピー（「ベンダーリング」または「セルフ バンドル」とも呼ばれます）は不要になりました。代わりに、requirements.txt にリストする必要があります。ビルドシステムは、デプロイ時に自動的にインストールします。

サードパーティ パッケージ管理の変更により、appengine_config.py ファイルも lib フォルダも不要になったため、削除します。第 2 世代のランタイムでは、App Engine は requirements.txt にリストされているサードパーティ パッケージを自動的にインストールします。要約:

1. セルフバンドルまたはコピーされたサードパーティ ライブラリがない。requirements.txt に記載されている
2. pip install が lib フォルダにない。つまり、lib フォルダ期間がない
3. app.yaml に組み込みのサードパーティ ライブラリが記載されていない（そのため libraries セクションがない）。requirements.txt に記載する
4. アプリから参照するサードパーティ ライブラリがない場合は、appengine_config.py ファイルもありません。

必要なサードパーティ ライブラリをすべて requirements.txt に記載することが、デベロッパーの唯一の要件です。

5. アプリケーション ファイルを更新する

アプリケーション ファイルは main.py の 1 つだけなので、このセクションの変更はすべてそのファイルにのみ影響します。以下は、既存のコードを新しいアプリにリファクタリングするために必要な全体的な変更の「差分」の図です。コードを 1 行ずつ読む必要はありません。このリファクタリングで必要なものを視覚的に把握することが目的です（必要に応じて、新しいタブで開いたり、ダウンロードして拡大したりしてください）。

インポートと初期化を更新する

モジュール 8 の main.py のインポート セクションでは、Cloud NDB と Cloud Tasks を使用します。次のようになります。

変更前:

from datetime import datetime
import json
import logging
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import ndb, tasks

app = Flask(__name__)
ds_client = ndb.Client()
ts_client = tasks.CloudTasksClient()

Python 3 などの第 2 世代のランタイムでは、ロギングが簡素化され、強化されています。

• 包括的なロギング エクスペリエンスを実現するには、Cloud Logging を使用します。
• シンプルなロギングの場合は、print() 経由で stdout（または stderr）に送信するだけです。
• Python logging モジュールを使用する必要がない（削除する）

そのため、logging のインポートを削除し、google.cloud.ndb を google.cloud.datastore に置き換えます。同様に、ds_client を NDB クライアントではなく Datastore クライアントを指すように変更します。これらの変更を行うと、新しいアプリの先頭は次のようになります。

変更後:

from datetime import datetime
import json
import time
from flask import Flask, render_template, request
import google.auth
from google.cloud import datastore, tasks

app = Flask(__name__)
ds_client = datastore.Client()
ts_client = tasks.CloudTasksClient()

Cloud Datastore に移行する

NDB クライアント ライブラリの使用を Datastore に置き換える時期が来ました。App Engine NDB と Cloud NDB のどちらもデータモデル（クラス）が必要です。このアプリでは Visit です。store_visit() 関数は、他のすべての移行モジュールでも同じように機能します。新しい Visit レコードを作成し、訪問したクライアントの IP アドレスとユーザー エージェント（ブラウザの種類）を保存して、アクセスを登録します。

変更前:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

ただし、Cloud Datastore はデータモデル クラスを使用しないため、クラスを削除します。また、Cloud Datastore ではレコードの作成時にタイムスタンプが自動的に作成されないため、手動で作成する必要があります。これは datetime.now() 呼び出しで行います。

データクラスがない場合、変更した store_visit() は次のようになります。

変更後:

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    entity = datastore.Entity(key=ds_client.key('Visit'))
    entity.update({
        'timestamp': datetime.now(),
        'visitor': '{}: {}'.format(remote_addr, user_agent),
    })
    ds_client.put(entity)

主な関数は fetch_visits() です。最新の Visit の元のクエリを実行するだけでなく、表示された最後の Visit のタイムスタンプを取得し、/trim（つまり trim()）を呼び出して古い Visit を一括削除する push タスクを作成します。Cloud NDB を使用した例を次に示します。

変更前:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    with ds_client.context():
        data = Visit.query().order(-Visit.timestamp).fetch(limit)
    oldest = time.mktime(data[-1].timestamp.timetuple())
    oldest_str = time.ctime(oldest)
    logging.info('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return (v.to_dict() for v in data), oldest_str

主な変更点は次のとおりです。

1. Cloud NDB クエリを Cloud Datastore の同等のクエリに置き換えます。クエリのスタイルは若干異なります。
2. Datastore では、Cloud NDB のようにコンテキスト マネージャーを使用したり、データ（to_dict()）を抽出したりする必要はありません。
3. ロギング呼び出しを print() に置き換える

これらの変更後、fetch_visits() は次のようになります。

変更後:

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

通常はこれで十分です。ただし、1 つ大きな問題があります。

（必要に応じて）新しい（push）キューを作成する

モジュール 7 では、既存のモジュール 1 アプリに App Engine taskqueue の使用を追加しました。push タスクを以前の App Engine 機能として使用する主な利点の 1 つは、「デフォルト」キューが自動的に作成されることです。モジュール 8 でアプリを Cloud Tasks に移行したとき、デフォルト キューはすでに存在していたため、その時点でも気にする必要はありませんでした。モジュール 9 では、この点が変更されます。

考慮すべき重要な点の 1 つは、新しい App Engine アプリケーションでは App Engine サービスが使用されなくなったため、App Engine が別のプロダクト（Cloud Tasks）でタスクキューを自動的に作成することを前提にできなくなったことです。この記述では、fetch_visits() でタスクを作成しようとすると（存在しないキューの場合）、失敗します。（「default」）キューが存在するかどうかを確認し、存在しない場合は作成する新しい関数が必要です。

この関数に _create_queue_if() という名前を付け、呼び出される場所である fetch_visits() のすぐ上にあるアプリケーションに追加します。追加する関数の本体:

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

Cloud Tasks の create_queue() 関数には、キュー名の除くキューの完全なパス名が必要です。簡略化のため、QUEUE_PATH からキュー名（QUEUE_PATH.rsplit('/', 2)[0]）を引いた値を表す別の変数 PATH_PREFIX を作成します。その定義を上部近くに追加して、すべての定数割り当てを含むコードブロックが次のようになるようにします。

_, PROJECT_ID = google.auth.default()
REGION_ID = 'REGION_ID'    # replace w/your own
QUEUE_NAME = 'default'     # replace w/your own
QUEUE_PATH = ts_client.queue_path(PROJECT_ID, REGION_ID, QUEUE_NAME)
PATH_PREFIX = QUEUE_PATH.rsplit('/', 2)[0]

次に、fetch_visits() の最後の行を変更して _create_queue_if() を使用します。必要に応じてキューを作成し、タスクを作成します。

    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

_create_queue_if() と fetch_visits() は、集計すると次のようになります。

def _create_queue_if():
    'app-internal function creating default queue if it does not exist'
    try:
        ts_client.get_queue(name=QUEUE_PATH)
    except Exception as e:
        if 'does not exist' in str(e):
            ts_client.create_queue(parent=PATH_PREFIX,
                    queue={'name': QUEUE_PATH})
    return True

def fetch_visits(limit):
    'get most recent visits & add task to delete older visits'
    query = ds_client.query(kind='Visit')
    query.order = ['-timestamp']
    visits = list(query.fetch(limit=limit))
    oldest = time.mktime(visits[-1]['timestamp'].timetuple())
    oldest_str = time.ctime(oldest)
    print('Delete entities older than %s' % oldest_str)
    task = {
        'app_engine_http_request': {
            'relative_uri': '/trim',
            'body': json.dumps({'oldest': oldest}).encode(),
            'headers': {
                'Content-Type': 'application/json',
            },
        }
    }
    if _create_queue_if():
        ts_client.create_task(parent=QUEUE_PATH, task=task)
    return visits, oldest_str

この追加のコードを追加する必要がある以外は、Cloud Tasks のコードの残りの部分はモジュール 8 からほぼそのままです。最後に確認するコードはタスク ハンドラです。

タスク ハンドラを更新（push）する

タスク ハンドラ trim() で、Cloud NDB コードは表示されている最も古い訪問よりも古い訪問をクエリします。キーのみのクエリを使用して処理を高速化します。訪問 ID のみが必要な場合に、すべてのデータを取得する必要はありません。すべての訪問 ID を取得したら、Cloud NDB の delete_multi() 関数を使用して、それらを一括で削除します。

変更前:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    with ds_client.context():
        keys = Visit.query(
                Visit.timestamp < datetime.fromtimestamp(oldest)
        ).fetch(keys_only=True)
        nkeys = len(keys)
        if nkeys:
            logging.info('Deleting %d entities: %s' % (
                    nkeys, ', '.join(str(k.id()) for k in keys)))
            ndb.delete_multi(keys)
        else:
            logging.info(
                    'No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

fetch_visits() と同様に、変更の大部分は Cloud NDB コードを Cloud Datastore に置き換え、クエリ スタイルを調整し、コンテキスト マネージャーの使用を削除し、ロギング呼び出しを print() に変更することです。

変更後:

@app.route('/trim', methods=['POST'])
def trim():
    '(push) task queue handler to delete oldest visits'
    oldest = float(request.get_json().get('oldest'))
    query = ds_client.query(kind='Visit')
    query.add_filter('timestamp', '<', datetime.fromtimestamp(oldest))
    query.keys_only()
    keys = list(visit.key for visit in query.fetch())
    nkeys = len(keys)
    if nkeys:
        print('Deleting %d entities: %s' % (
                nkeys, ', '.join(str(k.id) for k in keys)))
        ds_client.delete_multi(keys)
    else:
        print('No entities older than: %s' % time.ctime(oldest))
    return ''   # need to return SOME string w/200

メイン アプリケーション ハンドラ root() に変更はありません。

Python 3 に移植する

このサンプルアプリは、Python 2 と 3 の両方で実行できるように設計されています。Python 3 固有の変更については、このチュートリアルの関連セクションで説明しました。追加の手順や互換性ライブラリは必要ありません。

Cloud Tasks の更新

Python 2 をサポートする Cloud Tasks クライアント ライブラリの最終バージョンは 1.5.0 です。このドキュメントの作成時点では、Python 3 用のクライアント ライブラリの最新バージョンは、そのバージョンと完全に互換性があるため、これ以上の更新は必要ありません。

HTML テンプレートの更新

HTML テンプレート ファイル templates/index.html も変更する必要はありません。これで、モジュール 9 のアプリに必要な変更はすべて完了です。

6. 概要/クリーンアップ

アプリケーションをデプロイして検証する

コードの更新（主に Python 3 への移植）が完了したら、gcloud app deploy を使用してアプリをデプロイします。出力は、データベース アクセスを Cloud Datastore クライアント ライブラリに移動し、Python 3 にアップグレードした点を除き、モジュール 7 と 8 のアプリと同じになります。

これで、この Codelab は完了です。コードをモジュール 9 フォルダの内容と比較してみてください。お疲れさまでした

クリーンアップ

全般

現時点で完了した場合は、課金が発生しないように App Engine アプリを無効にすることをおすすめします。ただし、さらにテストや実験を行う場合は、App Engine プラットフォームに無料割り当てがあります。この使用量枠を超えない限り、課金されることはありません。これはコンピューティングの料金ですが、関連する App Engine サービスの料金も発生する可能性があります。詳細については、料金ページをご覧ください。この移行に他の Cloud サービスが含まれる場合は、それらのサービスは別途請求されます。どちらの場合も、該当する場合は、以下の「この Codelab に固有」のセクションをご覧ください。

完全に開示すると、App Engine などの Google Cloud サーバーレス コンピューティング プラットフォームにデプロイすると、ビルドとストレージの費用がわずかに発生します。Cloud Build には独自の無料割り当てがあり、Cloud Storage にも独自の無料割り当てがあります。そのイメージの保存には、その割り当ての一部が使用されます。ただし、お住まいの地域でこのような無料枠が提供されていない可能性もあります。そのため、保存容量の使用状況を把握して、費用を最小限に抑えるようにしてください。確認する必要がある特定の Cloud Storage の「フォルダ」は次のとおりです。

• console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
• console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
• 上記のストレージ リンクは、PROJECT_ID と *LOC*ーションによって異なります。たとえば、アプリが米国でホストされている場合は「us」になります。

ただし、このアプリケーションや関連する移行 Codelab を続行せず、すべてを完全に削除する場合は、プロジェクトをシャットダウンしてください。

この Codelab に固有

以下のサービスは、この Codelab 固有のものです。詳細については、各プロダクトのドキュメントをご覧ください。

• Cloud Tasks には無料枠があります。詳細については、料金ページをご覧ください。
• App Engine Datastore サービスは Cloud Datastore（Datastore モードの Cloud Firestore）によって提供されます。これにも無料枠があります。詳細については、料金ページをご覧ください。

次のステップ

これで、App Engine Task Queue の push タスクから Cloud Tasks への移行は完了です。Cloud NDB から Cloud Datastore へのオプションの移行については、モジュール 3 で（Task Queue や Cloud Tasks を使用せずに）個別に説明しています。モジュール 3 に加えて、App Engine の以前のバンドル サービスからの移行に焦点を当てた他の移行モジュールも検討する必要があります。

• モジュール 2: App Engine NDB から Cloud NDB に移行する
• モジュール 3: Cloud NDB から Cloud Datastore への移行
• モジュール 12 ～ 13: App Engine Memcache から Cloud Memorystore への移行
• モジュール 15 ～ 16: App Engine Blobstore から Cloud Storage への移行
• モジュール 18 ～ 19: App Engine タスクキュー（pull タスク）から Cloud Pub/Sub

App Engine は、Google Cloud の唯一のサーバーレス プラットフォームではなくなりました。小規模な App Engine アプリや、機能が制限されているアプリをスタンドアロンのマイクロサービスに変換したい場合や、モノリシック アプリを複数の再利用可能なコンポーネントに分割したい場合は、Cloud Functions への移行を検討する理由として十分です。コンテナ化がアプリケーション開発ワークフローの一部になっている場合（特に CI/CD（継続的インテグレーション/継続的デリバリーまたはデプロイ）パイプラインで構成されている場合）は、Cloud Run への移行を検討してください。これらのシナリオは、次のモジュールで取り上げます。

• App Engine から Cloud Functions に移行する: モジュール 11 をご覧ください。
• App Engine から Cloud Run に移行する: モジュール 4 で Docker を使用してアプリをコンテナ化するか、モジュール 5 でコンテナ、Docker の知識、Dockerfile を使用せずにコンテナ化します。

別のサーバーレス プラットフォームへの切り替えは任意です。変更を行う前に、アプリとユースケースに最適なオプションを検討することをおすすめします。

次にどの移行モジュールを検討する場合でも、すべてのサーバーレス移行ステーションのコンテンツ（Codelab、動画、ソースコード [利用可能な場合]）は、オープンソース リポジトリからアクセスできます。リポジトリの README には、考慮すべき移行と、移行モジュールの関連する「順序」に関するガイダンスも記載されています。

7. 参考情報

Codelab に関する問題/フィードバック

この Codelab に問題が見つかった場合は、提出する前にまず問題を検索してください。新しい問題の検索と登録を行うためのリンク:

• 問題を検索する
• 新しい問題やフィードバックを提出する

移行に関するリソース

モジュール 8（開始）とモジュール 9（終了）のリポジトリ フォルダへのリンクを以下の表に示します。これらのフォルダには、すべての App Engine Codelab 移行のリポジトリからアクセスすることもでき、クローンを作成する、または ZIP ファイルをダウンロードすることができます。

Codelab	Python 2	Python 3
モジュール 8	コード	該当なし
モジュール 9	該当なし	コード

オンライン リソース

このチュートリアルに関連する可能性のあるオンライン リソースは次のとおりです。

App Engine

• App Engine のドキュメント
• Python 2 App Engine（標準環境）ランタイム
• Python 3 App Engine（スタンダード環境）ランタイム
• Python 2 と 3 の App Engine（スタンダード環境）ランタイムの違い
• Python 2 から 3 への App Engine（スタンダード環境）移行ガイド
• App Engine の料金と割り当てに関する情報

Cloud NDB

• Google Cloud NDB ドキュメント
• Google Cloud NDB リポジトリ
• Cloud Datastore の料金情報

Cloud Datastore

• Google Cloud Datastore のドキュメント
• Google Cloud Datastore リポジトリ
• Cloud Datastore の料金情報

Cloud Tasks

• Google Cloud Tasks のドキュメント
• Google Cloud Tasks リポジトリ
• Cloud Tasks の料金情報

その他のクラウド情報

• Google Cloud Platform での Python
• Google Cloud Python クライアント ライブラリ
• Google Cloud の「常時無料」枠
• Google Cloud SDK（gcloud コマンドライン ツール）
• Google Cloud に関するすべてのドキュメント

ライセンス

この作業はクリエイティブ・コモンズの表示 2.0 汎用ライセンスにより使用許諾されています。