開発者と運用担当者の利便性を維持したまま Heroku Enterprise から Cloud Run に移行する
Google Cloud Japan Team
※この投稿は米国時間 2022 年 11 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。
世界中の最先端の開発者にとって、コードを記述してリモートの Git リポジトリに push し、コードのデプロイ方法について頭を悩ますことなくアクセス可能な URL にデプロイするという一連の快適なフローは当然のものとなっています。数年前に Heroku が世に広めたこのワークフローは、開発者に歓迎され、彼らの生産性を高めました。ただし、運用チームでは多少の柔軟性の低下が生じていました。
セキュリティと統合の要件を満たす際に生じる、この柔軟性の低下に対処するために Heroku が導入したのが Private Spaces です。Heroku によってプロビジョニングされるアプリケーションやデータストアは、デフォルトでインターネットにアクセスしますが、Private Spaces によってネットワークをインターネットから切り離すことができます。
Cloud Run は Google Cloud のサーバーレスの万能ソリューションとして急速に頭角を現しており、Heroku に慣れた開発者も無理なく移行できます。その基本機能は以下のとおりです。
オープンソースの Buildpacks または Dockerfile を使用した Git push 経由の継続的デプロイ
各インスタンスの CPU およびメモリ要件の設定
ゼロから数千のインスタンスにスケーリングして自動的にトラフィックの需要を満たす水平スケーリングが可能なアプリ
このように Cloud Run は開発者の利便性を維持する一方、運用担当者にも配慮しています。Cloud Run UI では以下のような機能を利用できます。
IAM ベースのアクセス制御による適切なシークレット管理。シークレットを環境変数として設定する必要がなくなります。
Blue Green またはカナリア デプロイのさまざまなリビジョン間でのトラフィック管理。
SLI および SLO の定義が容易。例: 1 暦月でリクエストの 90% に 200 ミリ秒以内に対応しなければならない。
ソフトウェア デリバリー シールド、Binary Authorization、Cloud Armor などのツールによるサービスのセキュリティ保護。このテーマだけでブログを 1 本投稿する価値があるのは確実です。
Cloud Run での Private Spaces の再現
ここで、ネットワーク分離に焦点を当てましょう。インターネットに接続するアプリと、プライベート データベースと通信するプライベート バックエンド API があるとします。非常にシンプルなアーキテクチャで、コンセプトとしては以下のようになります。




データベースがプロビジョニングされると、以下のように IP が明確に表示されます。


もちろん、Cloud SQL には他にも数多くの機能があります。詳しくは、こちらのドキュメントをご覧ください。
これで Postgres への対応は済みました。次は、Cloud Run のプライベート バックエンド API について見ていきます。
Google Cloud コンソール経由で新しい Cloud Run サービスを作成する場合、上り(内向き)設定を「内部トラフィックのみ」に制限すると、VPC を含む内部ソースからのトラフィックのみがサービスにアクセスできます。つまり、インターネットからはアクセスできません。
セキュリティをさらに強化するために、承認済みユーザーからのリクエストのみに対応するように指定することも可能です。この場合、「ユーザー」とは関連するサービス アカウントを使用する別のサービスである可能性が高く、このサービスを呼び出すために「roles/run.invoker」が必要となります。


次に、VPC コネクタを構成して、バックエンド API サービスから Postgres インスタンスに確実にアクセスできるようにします。これにより、Cloud Run サービスは VPC に、さらには Postgres インスタンスの内部 IP に到達できます。


VPC コネクタが作成されたら、それを Cloud Run サービスと関連付けることができます。


後は、Postgres インスタンスのプライベート IP アドレスを使用するようにコードを構成するだけです。このとき、Twelve-Factor App のベスト プラクティスに従い、Cloud Run サービスを構成する際に環境変数に接続文字列を指定します。これにはデータベースのパスワードが含まれる場合もあるため、Secret Manager を使用して、暗号化によって保護されたシークレットからこの環境変数をマウントするとさらに良いでしょう。
最後に、インターネットからのリクエストに応答し、バックエンド API サービスと安全に通信するフロントエンド Cloud Run サービスを設定しましょう。
フロントエンド サービスについて [すべてのトラフィックを許可する] と [未認証の呼び出しを許可する] を選択すると、ウェブ上の全ユーザーが URL にアクセスできるようになります。もちろん、中央のオプションを選択し、Cloud Load Balancing を Cloud Armor と関連付けて使用することもできます。Cloud Armor は DDoS 攻撃やアプリケーション攻撃を防御し、多様な WAF ルールを提供します。しかしここでは、シンプルにしましょう。


Google Cloud のバックエンド サービスは VPC ネットワーク内からのリクエストのみを受け付けること、また Cloud Run にはプライベート IP アドレスがないことを覚えておいてください。
フロントエンドからのすべての下り(外向き)トラフィックが実際に VPC コネクタに転送されるようにしましょう。これにより、フロントエンドが URL エンドポイントを介してバックエンド API を呼び出す際に、バックエンドが VPC 内からのリクエストを受け取り、許可します。


注: バックエンドが認証を求める場合、フロントエンド サービス用のサービス アカウントを作成し、サービス間認証パターンに従って必要なロールを付与することを忘れないでください。
これで、運用面で問題のないプライベート スペースを実現できました。ここでは、2 つの Cloud Run サービスから構成された 1 つのアプリがある、バックエンド サービスと Postgres インスタンスがインターネット ネットワークから切り離された環境を構築しました。本ブログを読んだ後、前述したテクノロジーを使用して実際に試してみたい場合は、Google Cloud Skills Boost にアクセスしてください。特定の領域のクラウド スキルを磨くことを目的とした学習プログラム、クエスト、ラボをご用意しています。
たとえば、こちらのラボでは、Go を使用した Cloud Run での REST API の開発について説明しています。
- アプリ エコシステム担当カスタマー エンジニア Felipe Ryan