「ランニングコストゼロ」で稼働する Web アプリケーションの技術構成
はじめに
こんにちは。クラウドエース株式会社で主にアプリケーション開発を担当している水野です。
今回は、「ランニングコストゼロ」で稼働するWeb アプリケーションの技術構成についてご紹介します。
プロダクト開発をする時に「マネタイズできるまでは費用を抑えたい」や「最小限のコストで長期的に運営したい」などのケースがあると思います。
そういう方にとって参考になる記事となっています。
また、基本的に Google Cloud を使用します。理由は私が Google Cloud 好きだからです。
あと、以下の3点を満たしていることも理由のひとつです。
- 永久無料枠が豊富
- 拡張性が高い（小規模から大規模システムに対応）
- Google Cloud プロダクト間とのコラボレーションが高い（楽に連携できる、システムパフォーマンスが上がりやすい等）
選定の方針
以下の方針をとります。
- ユーザー数が少ない間は、ランニングコストゼロ
- ユーザー数が増えたとしても、システム変更なく自動スケーリング
- ランニングコストを下げるためなら、パフォーマンスが落ちることを許容する
フロントエンド
App Engine というサーバレスサービスを使用します。
App Engine とは、サーバレスなアプリケーションフルマネージドサービスです。
実は、Google Cloud が一番最初にリリースしたサービスであり、歴史あるプロダクトになっています。
環境選択としてスタンダード環境とフレキシブル環境があるのですが、スタンダード環境を使用します。
静的ウェブサイトをホストするユースケースにも対応しているため、SSR だけでなく SPA としても利用できます。
嬉しいポイントは、デフォルトでキャッシュ機能を提供しているため、CDN のように動作できます。
そして、ゼロスケーリング機能があるため、インスタンスがゼロの時は料金が発生しません。
また、以下のような永久無料枠が存在します。
- 28 時間分のインスタンス（1 日あたり）*1
- 下り（外向き）1 GB（1 日あたり）
*1
App Engine は、VM 上で動くサービスです。そのため、コンテナ運用したい場合は、後述する Cloud Run を検討してみてください。
バックエンド
Cloud Run というコンテナサーバレスサービスを使用します。
Cloud Run とは、サーバレスなコンテナアプリケーションフルマネージドサービスです。
2024/2/29 現在で Google Cloud が積極的に機能アップデートを行っている注目プロダクトのひとつと言っても過言ではないでしょう。
App Engine との大きな違いは、コンテナで動くという点ですね。
サポートされている言語であれば、「Dockerfileなし」かつコマンドひとつで「コンテナのビルド、プッシュ、デプロイ」までやってくれたりと非常に使いやすいサービスです。
もちろん、App Engine と同様にゼロスケーリング機能を提供しており、インスタンスがゼロの時は料金が発生しません。
また、リクエストの認証もお手軽に設定ができ、簡単にセキュアな構成にすることが可能です。
こちらも以下のような永久無料枠が存在します。
- 200 万リクエスト（1 か月あたり）
- 360,000 GB 秒のメモリ、180,000 vCPU 秒のコンピューティング時間
- 1 GB の北米からの下り（外向き）ネットワーク（1 か月あたり）
Cloud Run のリージョンを北米にしておけば、無料で稼働できます。
「コンテナはちょっと。。。」という人は、App Engine を検討してみると良いですね。
データベース
Firestore というサーバレスデータベースを使用します。
Firestore とは、フルマネージドでスケーラブルなサーバレスのドキュメントデータベースです。
つまり、NoSQL のデータベースになります。
ドキュメントデータベースとは、任意のキー・バリューペアの集合からなる「ドキュメント」をデータモデルとしたデータベースです。RDB とは違い厳密なスキーマ定義の必要がないため、事前のデータベース設計に時間をかけずに開発を始められます。
Firestoreは、強い整合性を持ったACIDトランザクションを実行できます。一般的なNoSQLデータベースは整合性を提供していないため、アプリケーション側での工夫が必要です。ですが、Firestoreの場合だとその手間が省けます。これは嬉しいですね。
また裏側では、高いスケーラビリティを誇る Spanner という分散データベースに保存されており、高速なオートスケーリングを実現しています。
もちろん以下のような永久無料枠が存在します。
- Google Cloud プロジェクトあたり 1 GB のストレージ
- 50,000 回の読み取りオペレーション、20,000 回の書き込みオペレーション、20,000 回の削除オペレーション（1 プロジェクトあたり）
どうしても RDB を使用したい場合
残念ながら無料枠の存在するアプリケーション RDB サービスは、2024/2/29 現在で Google Cloud にはありません。（今後 Firestore 並にお手軽に使える RDB サービスが誕生してくれることを願ってます）
ただ、「NoSQL はちょっと。。。」という方もいると思いますので、代替案をいくつかご紹介します。
1. Supabase こちらは PostgreSQL を提供しているサービスです。Google Cloud ではないですが、無料枠もあり非常に使いやすいです。
2. PlanetScale こちらは MySQL を提供しているサービスです。Supabase と同様に Google Cloud ではないのですが、無料枠が存在するので、よければ検討してみてください。（私はまだ使ってことがないので、どこかの機会で使ってみたいなと思っています）
3. BigQuery
こちらは少し変わった案です。
Google Cloud には BigQuery というデータ分析基盤に使用するデータウェアハウスサービスがあります。
データウェアハウスとしてはものすごい高機能で使いやすいサービスなのですが、アプリケーションデータベースには適しません。
理由は、BigQuery がビッグデータにおいて高いパフォーマンスを持つ一方、アプリケーションレベルの小さなデータではパフォーマンスが低いためです。
読み取りのレイテンシが数秒になるのが当たり前の世界です。
ただ、BigQuery は永久無料枠が大きいという魅力があります。
- 1 TB のクエリ（1 か月あたり）
- 10 GB のストレージ（1 か月あたり）
もし数秒のレイテンシも許容できるアプリケーションなのであれば、BigQuery を検討してみると良いかもしれません。
アプリケーションデータベースとして採用できないとしても、ぜひデータウェアハウスとしてぜひ使ってみてください。
オブジェクトストレージ
Cloud Storage というオブジェクトストレージサービスを使用します。
Cloud Storage とは、非構造化データを保存するためのマネージドサービスです。
嬉しいポイントは、App Engine と同様にデフォルトでキャッシュ機能を提供しているため、とくに設定をしなくても CDN のように動作します。
また、以下のような永久無料枠が存在します。
- 5 GB 月の Regional Storage（米国リージョンのみ）
- 5,000 回のクラス A オペレーション（1 か月あたり）
- 50,000 回のクラス B オペレーション（1 か月あたり）
- 1 GB の北米から全リージョン宛ての下りネットワーク（1 か月あたり、中国とオーストラリアを除く）
A オペレーション、B オペレーションとは
おおまかにいうと以下です。
- A オペレーション：主に Cloud Storage への追加、更新、一覧取得の処理
- B オペレーション：主に Cloud Storage への取得の処理
詳細はこちらの「各クラスへのオペレーションの分類」をご覧ください。
Cloud Storage のリージョンを北米にしておけば、無料で稼働できますね。
認証
Identity Platform という認証サービスを使用します。
Identity Platform は、認証機能と認証データベースを提供している IDaaS にあたるサービスです。
Firebase Authentication の上位版という位置付けで、より高機能なサービスになっています。
さまざまな認証方法が実現できるだけでなく、使いやすい SDK、ユーザー認証に使用できる UI ライブラリが用意されていることも魅力のひとつです。
永久無料枠は以下になります。
- 5 万 MAU（1 か月あたり）
- 50 MAU（SAML/OIDC、1 か月あたり）
おまけ
今回は割愛しますが、以下のサービスも永久無料枠が豊富ですので、ぜひ使ってみてください。
1. CI/CD
2. シークレット管理
3. 非同期通信
おわりに
今回は、「ランニングコストゼロ」で稼働するWeb アプリケーションの技術構成についてご紹介しました。
無料枠をふんだんに使うことで、プロダクトが成長し、ユーザー数が増えるまでは無料で稼働することが可能です。
「マネタイズできるまでは費用を抑えたい」や「最小限のコストで長期的に運営したい」のような方にとって参考になる記事になっていると願っています。
またこの記事をきっかけに Google Cloud を好きになってもらえたら嬉しいです。
Discussion
GCPで0円運用してみたかったので助かります！
一つ質問がありまして、App Engineのスタンダード環境でカスタムドメインを使うとレイテンシが増えるそうですが、この場合は有料のCloud Load Balancingで解決するしかないのでしょうか？
goggle555 様
コメントありがとうございます。
回答が大変遅くなってしまい、誠に申し訳ございませんでした。
ご指摘いただいた通り、Cloud Load Balancing を使用していただくか、レイテンシの影響がないリージョン（大阪など）で利用していただくことになります。
あくまで私個人の意見にはなりますが、許容できるレイテンシなのか一度検証してみるのも良いと思っております。
公式ドキュメントに記載されている「著しいレイテンシ」が「どこまで著しいか」が明確になっていません。
そのため、許容できるレイテンシかどうかを確認することもひとつのアプローチになると考えます。