Summary
この文書の要点
- 共有する場合でもDB、スキーマ、ユーザー権限を分ける。
- 接続数上限とコネクションプールを早めに見る。
- アプリごとにschema、DBユーザー、権限、マイグレーション履歴を分ける。
- 接続数、バックアップ、メンテナンス、障害時の影響範囲を共有前提で設計する。
どこが設計の難所か
小規模アプリごとにDBインスタンスを持つとコストと管理が増えます。一方で、一つのCloud SQLにすべてを入れると、接続数、性能、障害、権限、復元の影響が広がります。
Cloud Runはスケールアウト時に接続数が増えやすく、DB側の上限に当たることがあります。また、あるアプリの重いクエリが別アプリへ影響する可能性があります。
Cloud SQLを複数の小規模アプリで共有すると、コストや運用は抑えられます。一方で、接続数の上限、マイグレーションの衝突、バックアップ復元時の巻き込み、権限漏れが問題になります。
境界をどう切るか
共有する場合は、最低でもアプリごとにDBまたはスキーマとDBユーザーを分けます。接続情報、マイグレーション、バックアップ確認をアプリ単位で管理し、Cloud SQL Auth ProxyやIAMの利用範囲を明確にします。
設計では、インスタンス共有、データベース分離、schema分離、テーブル共有を分けて考えます。小規模アプリなら同一インスタンス内でDBまたはschemaを分け、アプリごとのDBユーザーに最小権限を与える構成が扱いやすいです。
実装で効く細部
各Cloud Runサービスには必要なDBユーザーだけを渡し、マイグレーションも対象スキーマに限定します。コネクションプールを設定し、最大インスタンス数とDB接続数の関係を計算します。重い集計はジョブへ逃がします。
Cloud Runから接続する場合、アプリごとにサービスアカウントとDBユーザーを分け、接続設定も別管理にします。マイグレーション履歴テーブルはアプリごとに持ち、CI/CDから別々に実行できるようにします。
- 共有インスタンスでも、アプリ間で同じDBユーザーを使い回さない。
- 復元はインスタンス全体かDB単位かを確認し、巻き戻し影響を事前に把握する。
- 接続プールの上限をアプリ別に調整し、一つのアプリが接続を使い切らないようにする。
壊れ方を観測する
検証では、アプリ別の接続数、マイグレーション誤適用、権限外テーブルアクセス、バックアップからの部分復元手順を確認します。負荷試験では同時アクセス時の接続枯渇を見ます。
検証では、権限外schemaへのアクセス拒否、同時デプロイ時のmigration競合、接続数上限、バックアップ復元手順を確認します。障害訓練として、一つのアプリだけ停止した場合とDB全体が止まった場合を分けて考えます。
捨てた選択肢とトレードオフ
共有DBはコストを抑えますが、完全な障害分離はできません。重要度や負荷が高いアプリは専用インスタンスへ分ける判断が必要です。初期は共有、成長後に分離できる設計にしておくと現実的です。
インスタンス共有はコスト効率が良い一方、障害影響は広がります。完全分離は安全ですが運用費が増えます。業務重要度、データ機密性、アクセス量が違うものは早めに分離する判断が必要です。
現場に残す判断軸
Cloud SQL共有は、単に同じ接続先を使うことではありません。スキーマ、権限、接続数、復元の境界を設計すれば、小規模アプリ群を無理なく運用できます。
Cloud SQL共有は、単なる節約策ではなくテナンシー設計です。権限、migration、接続、復元を分けて考えると、小規模でも安全な共有ができます。
