Cloudflareでちょっと天狗になっていた自分が、GCPの保守案件に入ることになった
普段、Cloudflare WorkersやR2を使っています。
APIを動かしたいときはWorkers。画像やファイルを置きたいときはR2。やりたいことに対して「たぶん、これを使えばいいな」と見当がつくようになってきました。
そうなると、少しだけ「クラウド、わかってきたかも」と思ってしまう。
そんなところで、保守チームの案件に入り、GCPを使うことになりました。
Cloud Run。Artifact Registry。ロードバランサ。Cloud Armor。
名前を見ても、どこにアプリがいて、何を更新すればよくて、どこからアクセスが来るのかがつながらない。
Cloudflareで使う機能には慣れてきたけれど、別のクラウドの構成を読めるかというと、話は別でした。
そこで今回は、「Cloudflareでいうと、どの役割に近いんだろう？」を手がかりに、GCPの構成を読むためのメモを書いてみます。
※実際の案件構成を紹介する記事ではありません。これから保守に入る自分向けの学習メモです。ここでは、Cloud RunでWebアプリやAPIを動かす構成を例にします。
知っている名前に置き換えると、少し安心する
まずは、Cloudflareで知っている役割と並べてみました。
「Workersでやっているようなアプリの実行は、Cloud Runで考えるんだな」「R2に近いのはCloud Storageか」くらいなら、入り口としてはわかりやすいです。
ただし、これは名前の翻訳表ではありません。役割が近くても、動き方や設定方法まで同じではないので、そこは分けて考えます。
そして、この図に出てこないArtifact Registry。
これを理解するには、まず「アプリを動かすまでに何をするのか」から見たほうがよさそうです。
アプリを動かす前に、置いておく場所がある
Workersを起点に考えると、まず知りたいのは「GCPでは、どこでアプリが動くのか」です。
今回の例では、それがCloud Runです。HTTPリクエストを受け取り、アプリが処理して結果を返します。例えば、商品一覧をJSONで返すAPIなら、その処理をするアプリがCloud Runで動きます。
一方で、実行方式はWorkersと違います。
JavaScript／TypeScriptのWorkersはV8 isolatesという仕組みで動きます。今回扱うCloud Runサービスは、コンテナを動かします。Workersのコードや設定を、そのまま持っていけば動くという話ではありません。
ここで出てくるコンテナイメージは、アプリのコードや実行に必要なものをまとめたパッケージです。そのパッケージを保管する場所として使うのが、Artifact Registryです。
Artifact Registryに置いて、Cloud Runで動かす。
この2つは、セットで覚えると整理しやすそうです。Artifact Registryにイメージがあっても、それ自体がユーザーからのリクエストを処理するわけではありません。
なお、Cloud Runにはソースコードからデプロイする方法もあります。毎回自分でDockerfileを書く必要がある、という意味ではありません。
参考：Workersの実行方式、Cloud Runの概要、Artifact Registryの概要
新しいものを置いたのに、古いアプリが動いている？
保守で考えておきたいのは、例えばこんな場面です。
「新しいイメージは保存されている。でも、使ってみると古い動作のまま」
この場合、Artifact Registryへの保存だけを見て「更新済み」とは判断できません。
- 新しいイメージが保存されているか
- そのイメージでCloud Runのリビジョンを作ったか
- そのリビジョンにアクセスが振り分けられているか
リビジョンは、イメージや設定を固定したアプリの実行バージョンです。例えばlatestというタグのイメージを上書きしても、既存のリビジョンが自動で新しい中身に切り替わるわけではありません。
また、新しいリビジョンを作っても、そこへアクセスを流さない運用ができます。
「新しいアプリを用意した」と「利用者が新しいアプリを使っている」は別。
デプロイが自動化されていても、この途中の段階を追えるようにしておきたいです。
参考：Cloud Runのデプロイ仕様、リビジョンへのトラフィック割り当て
アプリが動いていても、アクセスが届くとは限らない
次は、ユーザーがアクセスする側から見ます。
ここでは、Cloud Runの前に外部向けのApplication Load Balancerを置き、Cloud Armorを組み合わせる構成を考えます。
※Cloud Armorは、LBのバックエンドサービスに適用するセキュリティポリシーとして描いています。接続に使うserverless NEGなどは省略した概念図です。
まず、アクセスの行き先を決める
その担当が、**ロードバランサ（LB）**です。GCPではCloud Load Balancingというサービスがあり、ここではWeb向けのApplication Load Balancerを扱います。
例えば、同じドメインへのアクセスでも、/api/*はAPI用のサービスへ、それ以外はWeb用のサービスへ、といった振り分けを設定できます。
Cloudflareで役割が近いのはCloudflare Load Balancingです。ただ、設定方法や振り分けの仕組みまで同じではありません。
また、Cloud RunにはサービスのURLがあるので、Cloud Runを使うだけなら、外部LBを必ず用意するわけではありません。今回のようにCloud Armorを組み合わせたい場合などに、LBを前段へ置きます。
参考：Cloud Runと外部LBの構成、Cloudflare Load Balancing
そのアクセスを通してよいか、ルールで検査する
ここで出てくるのが、Cloud Armorです。
CloudflareのWAFやレート制限を手がかりにすると、役割をつかみやすいです。アクセス元IPやWAFルールなどの条件で、リクエストを許可・拒否する制御ができます。
今回の構成では、LBのバックエンドサービスにCloud Armorのセキュリティポリシーを適用します。
なので、アクセスできないときも、いきなり「Cloud Runのアプリが壊れた」と決めつけず、LBでどこへ振り分けているか、Cloud Armorで拒否されていないかを確認する必要があります。
逆に、Cloud Armorを設定したから、どの入口から来ても守られるわけではありません。
Cloud Runの標準URLへ直接アクセスできると、そのリクエストはLB側のCloud Armorを通りません。
ルールの内容と一緒に、「保護したいアクセスが、そのルールを通る経路になっているか」も見る必要があります。
そのときに出てくる設定も、混ぜないように整理しておきます。
| 設定 | 確認すること |
|---|---|
| Ingress | どの経路からのアクセスを受け付けるか |
| IAMによる呼び出し権限 | 誰がそのサービスを呼び出せるか |
参考：Cloud ArmorとCloud Runの連携上の注意、Cloud RunのIngress設定
R2を知っていても、「保存する場所」はひとまとめにしない
Artifact Registryも保存するサービスなので、R2と結びつけたくなります。ただ、何を保存するのかが違います。
| 保存するもの | GCPで使うサービス |
|---|---|
| アプリが扱う画像やファイル | Cloud Storage |
| アプリを動かすためのコンテナイメージ | Artifact Registry |
R2のようなオブジェクトストレージとして考えるなら、近いのはCloud Storageです。API・権限・料金はそれぞれ違うので、使うときには別途確認します。
なお、CloudflareにもContainersで使うイメージ用のレジストリがあります。Artifact Registryと役割を比べるなら、R2よりもこちらです。
参考：Cloud Storageの概要、Cloudflare Containersのイメージ管理
次は、サービス名よりも「どこにつながるか」を見たい
今回の範囲は、2本の流れで覚えておこうと思います。
- 更新するとき：Artifact Registryへ保存し、Cloud Runへデプロイする。利用者のアクセスが新しいリビジョンへ向いているかも確認する。
- アクセスされたとき：LBで行き先を決め、Cloud Armorのルールを適用し、Cloud Runへ届ける。
更新が反映されないなら、更新の流れを追う。アクセスできないなら、ログを見ながら、どこまで届いているかを追う。
もちろん、実際には権限やネットワーク、アプリ自身の不具合など、見ることはもっとあります。これで保守ができるようになった、という話ではありません。
ただ、Cloudflareでの経験も、GCPになった途端に全部使えなくなるわけではなさそうです。「アプリを動かす」「ファイルを保存する」「アクセスを振り分ける」という役割を手がかりにすれば、少しずつつなげて考えられます。
「Cloudflareならだいたいわかる」の、その「なら」の部分を忘れずに。まずは保守対象の構成図と手順書を、この役割分担と照らし合わせながら読んでいこうと思います。