現状とやりたいこと

Google App Engine Pythonで作成された、古いアプリケーションがあります。
これがRESTとかも何も知らない頃に、独自に考えてAPIを作ったので、クライアント側などで無理が出てきました。（レスポンスがJSONじゃないのでパースし辛いなど）

この際にAPIを一新し、Webフロントエンド・iOS・Androidのそれぞれからのリクエストもそちらに切り替えたくなりました。
ただ、アプリ側には強制バージョンアップ機能などもなく、並行動作させる期間を設けたいと考えました。¹
（数ヶ月ぐらい並行稼動してれば、それなりにアクティブなユーザはアプリを更新してくれるだろう、と割り切ります。）

Google App Engineと同一プロジェクト内のCloud Datastoreを利用しており、そこは引き続き利用したいと思います。

手順イメージ

Google App Engineのserviceを新規に作成することとしました。

既存のプロジェクト内に、新規サービスとして v2 を作成し、そこに既存と同等の機能を持つAPIを実装。
既存サービスとv2を並行稼動させ、 /v2 以下のリクエストについては、v2サービス側に流す。
iOS・Androidのクライアントからは、v2を利用するように変更、リリースする。

この状態でのイメージ図

そのあと、

v2上で新しいフロントエンドを作成。（APIリクエストもv2に向ける）
すべてのリクエストがv2サービスに流れるように変更。（古いアプリからはアクセス不可になる）
既存サービスを停止する。

この状態でのイメージ図

具体的な要素技術

複数のサービスを共存させる

app.yaml に service を指定することで、別サービスとして並行稼動させることができます。

ドキュメント： https://cloud.google.com/appengine/docs/standard/python/config/appref?hl=ja

何も指定していないと、 default というサービスで起動されます。

サービスごとに全く別のコードベース・Runtimeを利用することもできます。
（今回も、既存はPythonですが、新規APIはGoで実装中です）

URLを振り分ける

iOS/Androidアプリからの利用を想定すると、ドメイン・パスの変更回数は減らしたいです。
既存サービスの有無に関わらず、同一ドメイン・パスでアクセスし続けられれば良さそうです。

そこで、新しいAPIは /v2 以下のパスに作成し、既存のドメインでも /v2 以下のリクエストはv2サービスに振り分けます。

そのため、まずは dispatch.yaml というファイルを新たに下記のように作成しました。

dispatch:
  - url: "*/v2/*"
    service: v2

次に、これをデプロイします。

gcloud app deploy dispatch.yaml

これにより、既存ドメインの /v2 以下にアクセスすると、v2サービスが実行されることになります。

ドキュメント: https://cloud.google.com/appengine/docs/standard/go/reference/dispatch-yaml?hl=ja

強制バージョンアップがあったとしても、開発側からのアプリ公開してから、全ユーザが新しいアプリを利用可能になるまでのラグがあり、それを開発側からはコントロールできないので、長時間のサービス停止が必要になってしまいます。 ↩