最初に少し背景を説明します。
- App Engineは、分散インフラストラクチャでアプリケーションを実行します。アプリが受信するトラフィックが多いほど、常にコードを実行するインスタンス（アプリサーバー）が多くなります。
- スケーラビリティ/シンプルさおよびその他の多くの理由により、AppEngineはクライアント<->appserverスティッキネスを実装していません。その結果、デフォルトのアプリバージョンへのリクエストはすべてのappserverで処理される可能性があります
管理コンソールを使用してデフォルトとしてマークされているバージョンを変更するか、現在のデフォルトと同じメジャーバージョンをデプロイすることにより、アプリケーションのデフォルトバージョンを変更した後、この変更に関する情報はAppEngineインフラストラクチャを介して伝達されます。アプリサーバーは新しいバージョンに気付くと、アプリケーションコードの新しいバージョンの読み込みを開始します。特定のアプリサーバーの準備が整うと、新しいバージョンのコードの提供が開始されます。
一部のアプリサーバーが以前のデフォルトバージョンを提供し、他のアプリサーバーがすでに新しいデフォルトバージョンを提供している期間があります。したがって、トラフィック量が重要なアプリでは、説明した動作が見られることが予想されます。
これらのバージョン変更にかかる時間を短縮する方法に常に取り組んでいますが、私たちの最大の関心事は、移行がスムーズに行われるようにすることです。アプリケーションに以前のバージョンを提供するインスタンスが多数ある場合、App Engineは、現在のすべてのトラフィックを提供するのに十分な容量（古いアプリサーバーと新しいアプリサーバーを組み合わせる）が常にあることを確認する必要があります。以前のバージョンと新しいバージョンのアプリでは、（バージョン間のパフォーマンスの違いにより）異なる数のアプリサーバーが必要になる場合があります。これが、移行を「即座に」安全に実行できないもう1つの理由です。
プロセスをより細かく制御したい場合は、AppEngineのトラフィック分割機能を使用できます。段階的に、新しいバージョンに誘導したいユーザートラフィックの割合を増やすことができます。App Engineは、クライアントIPアドレスまたはCookie（Webアプリの場合）のいずれかに基づいてバージョンスティッキネスを提供します。トラフィック分割を使用して、クライアントの一部（たとえば、1％）でアプリケーションの新しいバージョンを「カナリア」にすることもできます。