Cloud run+FirestoreのWebシステムアーキテクチャ

概要

田舎でシステム開発していると、「なるべく安く」が前提とあり、ランニングコストが1万でも2万でもかかると「高い」と思われるので、インスタンスを立てるようなアーキテクチャを使用できない場合がそこそこあります。なので、大前提としてサーバレスである必要があります。

アクセス数が増えると場合によってはインスタンスを立てるような構成の方が安かったりするが、そもそも何万PVだとかなんとかいくこともないし、そういうシステムの場合、片田舎だとメンテできる人材がほとんどいないので、そういった運用面でもサーバレスである必要があります。

上記を前提として、私は以下のサービスをよく使用しています。

• Cloud run
• Firestore
• Cloud load balancing

アーキテクチャ

GitHubにてリポジトリ管理し、CI/CDはCloud Buildを用います。Cloud runはGUI上にがCI/CD設定をGUI上でできるようになったので、Container Registryを意識しなくてよくなり、Cloud buildの設定ファイルを書く必要がなくなった。

Cloud load balancing有

こちらはload balancingを採用する都合上、ほっといても約2000円/月～くらいかかる。ただ、リソース管理などの観点では採用しておくと良い。CDN設定をし、Chache-Control設定をすると、firestoreのRead数を削減も可能です。Cloud DNSの設定で、カスタムドメイン設定もできる。設定管理は少し面倒なので、最初は採用せず、あとで設定をするでも良い気がする。
Cloud runにサービスアカウントを設定すると、GCPの各種サービスの権限を付与できるので、クレデンシャルの管理もやりやすい。

Cloud load balancing無

こっちはほっとけば10円/月もかからない場合がある。一応Cloud runではカスタムドメイン設定もできるので、料金を押さえて、とくに何も考えたくない場合は採用しない方が安く済む。

Firebase採用

こっちもほっといても10円/月もかからない場合がある。
フロントエンド側のディプロイ先は、Firebase hostingを利用しても良いと思う。rewrite設定でCloud runと接続も可能なので、好き勝手にバックエンド処理を書ける。ただ、少しだけサーバ側との通信が遅くなっているような気がする。SSRが必要な場合は、結局load balancingを利用した場合とそれほどアーキテクチャが変わらず、個人的にただ通信速度が遅くなっただけのように感じる。

Firebaseの裏でもなにがしかload balancingが動いているためか、ヘッダー情報（Cache-Controlなど）に気を付けないとデータ更新の検知が出来ないので注意が必要となる。Firebase側の設定でもカスタムドメイン設定できる。

おわりに

基本構成は以上になりますが、もし認証が必要であればIdentity platformを使用すると良いです。サインインやパスワード変更の処理はある程度手離れできます。

あとはストレージ容量やなんやかんやで料金に変動がありますが、インスタンスを立てるよりは比較的安いように思います。
あとは、面倒な機能等は必要に応じてfunctionsやpubsubなどで実装すると良いです。最近はeventarcとCloud runを使用すると実行環境にも拘れるので良いです。