App Engine バンドル サービスのサポートの拡張: パート 1（モジュール 17）

1. 概要

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

以前は、言語バージョンをアップグレードする前に、デベロッパーは Datastore や Memcache などの App Engine の以前の「バンドル サービス」から移行する必要がありました。これは、2 つの難しい作業を連続して行う必要がありました。第 2 世代の App Engine サービスで多くの主要なバンドル サービスを利用できるようにすることで、デベロッパーはバンドル サービス（のほとんど）を引き続き使用しながら、アプリを最新のランタイムに移植できるようになりました。この Codelab では、Datastore バンドル サービス（App Engine NDB ライブラリ経由）の使用を維持しながら、サンプルアプリを Python 2 から 3 にアップグレードする手順について説明します。このチュートリアルで説明するように、ほとんどのバンドル サービスを使用するには、コードの軽微な更新のみが必要です。ただし、より大規模な変更が必要なものもあります。これについては、フォローアップ モジュールと Codelab である「パート 2」で説明します。

GCP コンソールの

  • サンプル App Engine アプリを Python 2 から 3 に移植する
  • App Engine SDK を含めるようにアプリの構成を更新する
  • Python 3 などの第 2 世代ランタイムでバンドル サービスをサポートするアプリに SDK コードを追加する

必要なもの

アンケート

このチュートリアルをどのように使用されますか？

通読のみ 通読して演習を行う

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

初心者 中級者 上級者

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

初心者 中級者 上級者

2. 背景情報

元の App Engine サービスは 2008 年にリリースされ、デベロッパーがアプリケーションをグローバルにビルドしてデプロイするのに便利な一連の以前の API（現在はバンドル サービスと呼ばれています）が付属していました。これらのサービスには、Datastore、Memcache、Task Queue があります。便利な一方で、ユーザーは App Engine に関連付けられた独自の API を使用するとアプリの移植性が低下することを懸念し、アプリの移植性を高めることを望んでいました。こうしたバンドル サービスの多くが独立してスタンドアロンの Cloud プロダクトとなったこともあり、App Engine チームは 2018 年に次世代プラットフォームをリリースしました。

Python 2 デベロッパーは Python 3 へのアップグレードを熱望しています。バンドル サービスを使用する 2.x アプリは、アプリを 3.x に移植する前に、これらのサービスから移行する必要がありました。これは、連続して強制移行を行うことを意味し、困難な移行になる可能性がありました。この移行を支援するため、App Engine チームは 2021 年秋に過去への「ワームホール」を導入しました。これにより、次世代ランタイムで実行されているアプリは、これらのバンドル サービスの多くにアクセスできます。このリリースには、元のランタイムで利用可能なすべてのサービスが含まれているわけではありませんが、Datastore、Task Queue、Memcache などの主要なサービスは利用できます。

この Codelab では、バンドルされたサービスの使用を維持しながらアプリを Python 3 にアップグレードするために必要な変更について説明します。目標は、アプリを最新のランタイムで実行できるようにすることです。これにより、3.x へのアップグレードの妨げになるのではなく、バンドル サービスから Cloud のスタンドアロンの同等サービスまたはサードパーティの代替サービスに独自のタイムラインで移行できるようになります。バンドル サービスからの移行は必須ではなくなりましたが、移行することで、ワークロードに適したプラットフォームに移行したり、前述のように最新の言語リリースにアップグレードしながら App Engine を使い続けたりするなど、アプリをホストできる場所の移植性と柔軟性が向上します。

モジュール 1 の Python 2 サンプルアプリは、App Engine NDB を介して Datastore バンドル サービスを利用します。アプリは、モジュール 1 の Codelab で完了した webapp2 から Flask へのフレームワークの移行をすでに完了していますが、Datastore の使用はそのままです。

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

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

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

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

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

これらの手順により、動作するコードから開始できます。

1. プロジェクトをセットアップする

モジュール 1 の Codelab を完了している場合は、同じプロジェクト（とコード）を再利用することをおすすめします。または、新しい Cloud プロジェクトを作成するか、別の既存のプロジェクトを再利用します。プロジェクトに App Engine サービスが有効になっているアクティブな請求先アカウントがあることを確認します。

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

この Codelab の前提条件の 1 つは、機能するモジュール 1 App Engine アプリを用意することです。モジュール 1 Codelab を完了する（推奨）か、リポジトリからモジュール 1 アプリをコピーします。ご自分のコードと Google で用意したコードのいずれを使用される場合も、モジュール 1 のコードから開始します。この Codelab では、各ステップを順を追って説明します。最後に、モジュール 7 のリポジトリ フォルダ「FINISH」にあるコードに似たコードが完成します。

モジュール 1 のどのアプリを使用しても、フォルダは次のようになります（lib フォルダも含まれる場合があります）。

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

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

Module 1 アプリを（再）デプロイする手順は次のとおりです。

  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. モジュール 1 アプリが期待どおりに動作し、最新のアクセスが問題なく表示されることを確認します（下図を参照）。

a7a9d2b80d706a2b.png

4. 構成を更新する

各手順を正常に実行して、ウェブアプリが動作することを確認したら、このアプリを Python 3 に移植する準備が整いました。構成から開始します。

requirements.txt に SDK を追加する

App Engine Python 3 ランタイムでは、サードパーティ ライブラリを使用する際のオーバーヘッドが大幅に削減されます。必要なのは、それらを requirements.txt に記載することだけです。Python 3 でバンドル サービスを使用するには、App Engine SDK パッケージ appengine-python-standard を追加します。SDK パッケージは、モジュール 1 の Flask に参加します。

flask
appengine-python-standard

app.yaml を更新する

次の手順に沿って、構成の変更を app.yaml ファイルに適用します。

  1. runtime ディレクティブをサポートされている Python 3 リリースに置き換えます。たとえば、Python 3.10 の場合は python310 を指定します。
  2. Python 3 ではどちらのディレクティブも使用されないため、threadsafe ディレクティブと api_version ディレクティブの両方を削除します。
  3. このアプリにはスクリプト ハンドラのみがあるため、handlers セクションを完全に削除します。アプリに静的ファイル ハンドラがある場合は、handlers でそのままにします。
  4. Python 3 ランタイムは、Python 2 ランタイムのように組み込みのサードパーティ ライブラリをサポートしていません。アプリの app.yaml に libraries セクションがある場合は、そのセクション全体を削除します。（必要なパッケージは、組み込みでないライブラリと同様に requirements.txt に記載するだけで済みます）。このサンプルアプリには libraries セクションがないため、次のステップに進みます。
  5. true に設定された app_engine_apis ディレクティブを作成して使用します。これは、上記の requirements.txt に App Engine SDK パッケージを追加することに対応しています。

app.yaml に必要な変更の概要:

変更前:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

変更後:

runtime: python310
app_engine_apis: true

その他の構成ファイル

すべてのサードパーティ パッケージは requirements.txt にのみ記載すればよいので、appengine_config.py に特別なものがない限り、appengine_config.py は不要です。削除してください。同様に、すべてのサードパーティ ライブラリはビルドプロセス中に自動的にインストールされるため、コピーやベンダー化は不要です。つまり、pip install コマンドも lib フォルダも不要になるため、削除します。要約:

  • appengine_config.py 個のファイルを削除
  • lib 個のフォルダを削除しますか？

これで、必要な構成変更はすべて完了しました。

5. アプリケーション コードを変更する

Python 3 ランタイム環境で利用可能なバンドル サービスの大部分にアクセスするには、ウェブサーバー ゲートウェイ インターフェース（WSGI）アプリケーション オブジェクトを main.py でラップする短いコードが必要です。ラッパー関数は google.appengine.api.wrap_wsgi_app() です。これを使用するには、インポートして WSGI オブジェクトをラップします。main.py で Flask の必要な更新を反映するために、以下の変更を行います。

変更前:

from flask import Flask, render_template, request
from google.appengine.ext import ndb

app = Flask(__name__)

変更後:

from flask import Flask, render_template, request
from google.appengine.api import wrap_wsgi_app
from google.appengine.ext import ndb

app = Flask(__name__)
app.wsgi_app = wrap_wsgi_app(app.wsgi_app)

他の Python フレームワークの WSGI ラッピングの例については、ドキュメントをご覧ください。

この例は、Python 3 のほとんどのバンドル サービスにアプリがアクセスできるようにするうえで有効ですが、Blobstore や Mail などのサービスでは追加のコードが必要です。これらのサンプルについては、別の移行モジュールで説明します。

これで、App Engine バンドル サービスの使用をモジュール 1 サンプルアプリに追加するために必要な変更はすべて完了しました。アプリケーションはすでに Python 2 と 3 と互換性があるため、構成ですでに行った変更以外に、Python 3 に移植するための追加の変更はありません。最後のステップ: この変更されたアプリを次世代の App Engine Python 3 ランタイムにデプロイし、更新が成功したことを確認します。

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

このセクションでは、アプリをデプロイし、意図したとおりに動作することと、出力に反映されることを確認して、この Codelab を終了します。アプリの検証が完了したら、クリーンアップを行い、次のステップを検討します。

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

gcloud app deploy を使用して Python 3 アプリをデプロイし、アプリが Python 2 と同じように動作することを確認します。機能に変更はないため、出力はモジュール 1 のアプリと同じになります。

a7a9d2b80d706a2b.png

最後に

このたびは、Python 2 App Engine アプリを Python 3 に移植し、バンドル サービスの使用を維持するための第一歩を踏み出されたことをお祝い申し上げます。

クリーンアップ

全般

現時点で完了した場合は、課金が発生しないように 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 固有のものです。詳細については、各プロダクトのドキュメントをご覧ください。

次のステップ

ここからいくつかの方向に進むことができます。

  1. バンドル サービスを使用するコードを更新する（より多くのコード変更が必要）
  2. バンドル サービスから Cloud スタンドアロン プロダクトに移行する
  3. App Engine から別の Cloud サーバーレス プラットフォームに移行する

Blobstore、Mail、Deferred などの他のバンドル サービスにアクセスするには、さらにコードの変更が必要です。App Engine の以前のバンドル サービスからの移行に焦点を当てた移行モジュールには、次のものがあります。

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

移行に関するリソース

モジュール 1（開始）とモジュール 1b（終了）のリポジトリ フォルダへのリンクを以下の表に示します。これらのフォルダには、すべての App Engine Codelab 移行のリポジトリからアクセスすることもできます。

Codelab

Python 2

Python 3

モジュール 1

コード

なし

モジュール 17（この Codelab）

なし

コード（mod1b-flask）

オンライン リソース

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

App Engine のバンドル サービス

App Engine の一般的なドキュメント

その他のクラウド情報

動画

ライセンス

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