Cloud Run リリースからの 1 年を振り返る
Google Cloud Japan Team
※この投稿は米国時間 2020 年 12 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。
Cloud Run は、コンテナの柔軟性と、サーバーレスのシンプルさ、スケーラビリティ、生産性を組み合わせるという明確な前提に基づいて構築されています。Cloud Run を使用すれば、数回クリックするだけで、安全な HTTPS エンドポイントの背後でコンテナを自動でスケールするフルマネージド環境に Git リポジトリを継続的にデプロイできます。また、Cloud Run はフルマネージドであるため、インフラストラクチャの管理が不要で、アプリケーションの迅速な提供に集中できます。
Cloud Run の一般提供（GA）から丸 1 年が経ちました。今回は Cloud Run がこの 1 年でどのように進化したかをまとめました。
エンタープライズ向け
Google では Cloud Run を 21 のリージョンに展開できるよう取り組んでまいりました。年末までに残りのすべての Google Cloud リージョンでご利用いただけるようになる予定です。
Cloud Run サービスでは、プライベート IP でのリソースへの接続や、サーバーレス VPC コネクタを使った Cloud Memorystore Redis と Memcached の使用が可能になりました。サーバーレス VPC コネクタは共有 VPC をサポートしているため、オンプレミスやさまざまなプロジェクトのリソースに接続できます。すべての下り（外向き）トラフィックをこの VPC 経由でルーティングすることで、Cloud Run からのトラフィックの外向きの静的 IP アドレスを利用できます。これは、特定の IP 範囲のみを許可する外部サービスを呼び出す場合に役立ちます。
また Cloud Load Balancingを Cloud Run で利用できるようになりました。独自の TLS 証明書を使用する、受け入れる SSL のバージョンを指定する、ロードバランサで URL ベースのカスタム ルーティングを構成するなどして、さまざまなコンテンツを別々のバックエンドから提供できます。
さらに、グローバルな負荷分散では、複数のリージョンからのトラフィックを処理して世界各地に分散したアプリケーションを実行できます。Cloud CDN を介してエッジにキャッシュされた静的コンテンツを提供したり、Cloud Armor ウェブ アプリケーション ファイアウォールでエンドポイントを保護したりすることも可能です。
API Gateway のサポートにより、顧客に合った API を構築して Cloud Run で実行できます。認証の実装や API のホスティングに関するその他の一般的な懸念事項を考慮する必要はありません。
段階的なロールアウトとロールバックにより、各リビジョンに送信されるトラフィックの割合を制御して、専用 URL を使って特定のリビジョンをテストすることで、Cloud Run サービスの新しいリビジョンを安全にリリースできるようになりました。
デベロッパー指向
Google もデベロッパーなので、デベロッパー コミュニティで高評価を受けているプロダクトの開発に取り組んでいることを誇りに思っています。
初心者ユーザーでも、初めて試してから 5 分も経過しないうちにアプリをビルドしてデプロイできます。非常に高速で簡単なので、誰でも 1 日に複数回デプロイすることも可能です。Cloud Run によって生産性が向上し、コードをより速くリリースできるようになったという話を聞くと、嬉しく思います。
昨年、Google は開発者の生産性向上に役立つ多くの機能を追加しました。
Git リポジトリからの継続的デプロイを設定するための簡単なユーザー インターフェースを追加しました。特定のブランチに commit を push するか、新しいリリースをタグ付けるたびに、Cloud Build で自動的にビルドされて Cloud Run にデプロイされます。
また、アプリケーションの開発も容易になりました。Cloud Codeを使用して、ローカルで Cloud Run アプリケーションをデプロイして実行できるようになりました。使い始めたばかりの方は、Cloud Code で作成される新しいアプリケーション テンプレートを利用して、エミュレータでコードをローカルで実行またはデバッグできます。
Dockerfiles の記述を好まない方のために、Google Cloud Buildpacks を使って、アプリケーション コードをサポートされている言語のコンテナ イメージに直接変換できるようになりました。これは、既存のアプリケーションを Cloud Run に移行する場合に最適です。同じように、Buildpacks を Functions Framework と併用することで、Cloud Functions をコンテナ イメージに変換できます。
次に、サービスのパフォーマンスをモニタリングしてレイテンシの問題を簡単に特定できるよう、Cloud Run サービスに送信されたリクエストが、特に設定しなくても Cloud Trace でキャプチャされるようになりました。サービス間の分散トレースが必要な場合は、送信リクエストに、取得したトレース ヘッダーを渡すだけで、自動的にトレーススパンが相互に関連付けられます。
Cloud Run はリクエストに応答して、Pub/Sub によって push されたメッセージを非公開かつ安全に処理できますが、60 を超える Google Cloud ソースから Cloud Run サービスをトリガーする機能も追加されました。さらにオーケストレーションの強化については、Cloud Run を使用した処理を自動化してオーケストレートするワークフローを活用できます。
柔軟性
Google は常に Cloud Run の限界を押し広げ、ユーザーがフルマネージド環境でより多くのワークロードを実行できるよう努力を続けています。最大 4 GBのメモリと 4 つの CPU をコンテナに割り振ることができるようになりました。
また、特にゼロからのスケーリングにおいて「コールド スタート」を最小限に抑えたいという声があったので、コールド スタートを回避してリクエストを処理するために、ウォーム コンテナ インスタンスの最小数を維持する機能を追加しました。こうしたアイドル状態のインスタンスは、リクエストを処理していない場合、アクティブなインスタンスよりも料金が安くなります。コールド スタートが気になる場合は、これを試してみてください。
gRPCとサーバー側ストリーミングを使用すると、計算時に部分的なレスポンスを送信して、サービスの最初のバイトまでの時間を短縮でき、またサーバー側からデータをストリーミングするアプリケーションを作成できます。この機能によりレスポンスを 32 MB に制限する必要はなくなり、サーバー送信イベント（SSE）を実装できます。
リクエストのタイムアウトが 1 時間になり、1 つのリクエストを最大 1 時間実行できるようになりました。サーバー側ストリーミングと組み合わせれば、大きなサイズのレスポンス（ドキュメントや動画など）をストリーミングしたり、Cloud Run から長時間実行されるタスクを処理したりすることも可能です。
最後に、インスタンスの正常終了では、Cloud Run がコンテナ インスタンスをスケールダウンする前に、プロセスに終了シグナル（SIGTERM）を送信します。これにより、ローカルに保持されていたテレメトリ データのフラッシュ、オープン接続の終了、ロックの解除などが可能になります。
Cloud Run の次のステップ
Cloud Run の初年度は素晴らしい 1 年になりましたが、これはほんの序章にすぎません。Google は今後も Cloud Run を改善し、さらに多様なワークロードに対応できるよう取り組んでまいります。同時に、優れた開発者エクスペリエンスを提供し、重要な企業要件に応えることが Google の焦点であることに変わりはありません。Cloud Secret Manager からのシークレットのマウントや Identity-Aware Proxy との統合、双方向ストリーミングと WebSocket など、今後のリリースにご期待ください。
Cloud Run の現在の機能や今後リリース予定の新機能については、リリースノートをご覧ください。また、新機能の詳細については、こちらの動画をご覧ください。Google は Cloud Run の未来を皆様と一緒に作っていきたいと考えています。ぜひ調査研究にご参加ください。
-プロダクト マネージャー Steren Giannini
-シニア デベロッパー アドボケイト Ahmet Alp Balkan
