Cloud Run で段階的なロールアウトとロールバックを支援

 ※この投稿は米国時間 2020 年 7 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

すべてのデベロッパーは、次のデプロイが成功するという確証を求めています。

しかし、急に 100% のトラフィックにデプロイしては、何か問題が発生したときにリスクが生じかねません。ベスト プラクティスは、変更を段階的にロールアウトして、新しいバージョンのコードで新たな不具合やエラーが発生しないかを確認することです。実際 Google では、4 日かけてコンポーネントの多くのロールアウトを行っています。

Google のフルマネージド コンテナ コンピューティング プラットフォームである Cloud Run を使用すれば、変更のロールアウトをより詳細に管理できます。Cloud Run サービスの構成を変更した場合は常に、新しいリビジョンが作成されます。デフォルトでは、Cloud Run は自動的に、新しく作成されたリビジョンに 100% 移行します。現在は、トラフィックをリビジョン間で手動で分割することによって、リビジョンを段階的にロールアウトしたり、古いリビジョンにロールバックしたりもできるようになりました。

段階的なロールアウト

Blue / Green デプロイと呼ばれる段階的なロールアウトの例を見てみましょう。現在のリビジョン（「blue」というタグが付いています）から新しいリビジョン（「green」というタグが付いています）に段階的に移行します。

git commit のハッシュ（この例では「f5bd774」）でタグ付けするコンテナ イメージに新しいコードをビルドします。

これで、このコンテナに対して統合テストを実施して、それをステージング環境（ステージング GCP プロジェクトなどの環境）にデプロイできるようになりました。このコンテナの検査が完了したら、これを本番環境に push します。

この新しいコンテナを本番環境サービスにデプロイして、新しいリビジョンを構成しますが、まだトラフィックは送信しません。また、このリビジョンに green というタグを付けます。

「green」タグを使用すれば、トラフィックを移行しなくても、特定の URL で新しいリビジョンを直接テストできます。

デベロッパーは、次の URL でタグが付いているリビジョンをテストできます。

新しいリビジョンが正しく動作することを確認したら、トラフィックの移行を開始できます。

1 日目は、1% のトラフィックを新しいリビジョンに移行することから始めます。

コマンドラインから実行するには、次のように入力します。

または、次のようにして Cloud Console から実行します。

これで、Cloud Monitoring、Logging、または Error Reporting をリビジョンで絞り込んで調べ、新しいエラーやレイテンシが発生するかどうかを確認できます。

2 日目は、10% のトラフィックを新しいリビジョンに移行し、状態インジケーターを確認します。

3 日目は、50% のトラフィックを新しいリビジョンに移行します。

4 日目は、すべてのトラフィックをこのリビジョンにルーティングします。

これで、ロールアウトが完了しました。新しいコードが Cloud Run サービスに到着したすべてのリクエストを処理するようになりました。

もちろん、必ずしも 4 日かけてロールアウトを行う必要はありません。同じコマンドを使用し、数時間かけて段階的にロールアウトできます。

ロールバック

デプロイ中やデプロイ後に問題が発生した場合、「blue」というタグが付けられた古い安定したリビジョンにトラフィックをロールバックできます。

または、リビジョンにタグが付けられていなかった場合は、gcloud またはユーザー インターフェースを使用し、リビジョンの名前を指定して特定のリビジョンにロールバックできます。そのためのコマンドラインは次のとおりです。

ユーザー インターフェースからロールバックを実行する方法は次のとおりです。

安全第一

サービスに新しい機能を追加する場合、追加することでエラーが発生するのは最も避けなければなりません。段階的なロールアウトとロールバックのサポートを利用すれば、特に重要なユーザー向けアプリケーションを自信を持って Cloud Run でホストできます。ぜひ Cloud Run をお試しください。新しい機能のご要望がございましたらお知らせください。

-プロダクト マネージャー Steren Giannini