開発者と運用担当者の利便性を維持したまま Heroku Enterprise から Cloud Run に移行する

※この投稿は米国時間 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 があるとします。非常にシンプルなアーキテクチャで、コンセプトとしては以下のようになります。

まず、データベースを見ていきましょう。Postgres を使用するのであれば Cloud SQL が最も近いと思われますが、AlloyDB や Spanner などの Postgres と通信する他のデータストアもあることを覚えておいてください。

データベースがプロビジョニングされると、以下のように 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 の開発について説明しています。