これまで、コンピューティング基盤（GKE）、ネットワーク接続、セキュリティ（ゼロトラスト/SASE）の各レイヤーの設計を解説してきました。
最終的なハイブリッド戦略において、最も重要かつ判断が難しい リレーショナルデータベース（RDB）の設計に焦点を当てます。オンプレミスDBを維持し続けることの是非を判断するための客観的な基準と、クラウドワークロードからのセキュアなDBアクセスを実現する最小権限設計を提示します。
TL;DR — RDBのオンプレ継続判断は「ライセンス」「データ主権」「接続要件（RTT/帯域）」の3基準で決定する。クラウド上のワークロードからは、長期クレデンシャル（パスワード）を使用せず、IDベースでアクセスすることを徹底する。
簡易チェック: 現在のDBのバージョン、ライセンス費用、専門家の確保が、クラウド移行のメリットを上回るか？
RDBのオンプレミス継続判断とマネージドサービス選定基準
この節を読めば：オンプレDBを維持すべきか、Google Cloud のマネージドDBへ移行すべきかの客観的な判断軸を確立できます。
ハイブリッドクラウド環境において、RDBの配置を決定する際、単純な技術的適合性だけでなく、ビジネス的・法的側面での判断が必要です。
-
オンプレミス継続判断の3基準
オンプレミスDBを維持し続けるかを判断する主要な軸は以下の3つです。
- データ主権とコンプライアンス: 医療や金融など、特定の法規制によりデータが特定の地理的場所（例：国内データセンター）から出られない場合。
- レガシー依存とライセンス: 旧バージョンのDBでしか動かないアプリケーション依存性がある場合、または既存のエンタープライズライセンス（Oracle, SQL Serverなど）の初期投資を最大限に活用したい場合。
- 極めて低いレイテンシ要件: オンプレミスで稼働するレガシーアプリケーションが、同一ネットワーク内のDBに対し1ミリ秒未満のRTTを要求する場合。クラウド接続では実現が困難。
-
マネージドRDB（Cloud SQL, AlloyDB）の選定基準
- 上記の継続基準に該当しない場合、運用負荷の低いマネージドDBへの移行が推奨されます。
- Cloud SQL: MySQL, PostgreSQL, SQL Server などのオープンソースおよび商用DBに対応したフルマネージドサービス。最も一般的に使用されます。
- AlloyDB for PostgreSQL: PostgreSQLとの互換性を保ちつつ、高いトランザクション性能と可用性を要求する基幹システム向け。
IaC実践: Cloud SQL for PostgreSQLの最小定義
オンプレミスのレガシーDBからの移行先として一般的なCloud SQLのTerraform定義です。
resource "google_sql_database_instance" "postgres_instance" {
database_version = "POSTGRES_14"
name = "hybrid-app-db"
region = "asia-northeast1"
project = var.project_id
settings {
tier = "db-f1-micro"
# VPCネットワーク内の限定された接続を許可（セキュリティ強化）
ip_configuration {
ipv4_enabled = false
private_network = google_compute_network.hybrid_vpc.id
}
}
}
ゼロトラストに基づくDBアクセス最小権限設計
この節を読めば：パスワードなどの長期クレデンシャルに依存しない、セキュアなDBアクセス方法を実装できます。
オンプレミスDBへのアクセスは、ハイブリッド環境におけるセキュリティの最弱点となりがちです。GKE PodやCloud Runサービスが、DBのユーザー名とパスワード（長期クレデンシャル）を環境変数やSecretとして持つ方法は推奨されません。
1. IDベース認証の適用（最も安全）
Workload IdentityとIAMを組み合わせ、DBアクセスに必要な最小限の権限を持つサービスアカウントをPodに付与します。
- Google Cloud SQLへのアクセス: Cloud SQL Auth Proxy / Cloud SQL Auth Socket を利用し、IAMユーザーまたはサービスアカウントとして認証することで、パスワードなしでDBへ接続できます。
- オンプレミスDBへのアクセス: DB側がKerberosやLDAPなどのIDプロバイダと連携し、クラウドサービスアカウントと連携させる仕組み（IDフェデレーション）を構築する必要があります。
2. 権限とネットワークの最小化
オンプレミスDBへのアクセス権を付与する際は、以下の原則を徹底します。
-
DBユーザー権限: アプリケーションが実行に必要な
SELECT/INSERT/UPDATEのみを与え、DB管理権限（DDL、DBユーザー作成など）は分離します。 - VPCファイアウォール/DB Firewall: 接続元のVPC ConnectorのIPアドレス、またはGKE Podが属する特定のCIDRレンジのみを許可します。
- データ暗号化: Cloud VPN または Interconnect 経由のトラフィックは暗号化されていますが、DB接続自体もSSL/TLSを強制します。
IaC実践: 最小権限のデータベースユーザー定義（概念）
これは、オンプレミスDB側でDBAが設定すべき最小権限制限の概念です。
-- GKE Pod のサービスアカウントから接続される DB ユーザーの作成例
CREATE USER 'gke_app_writer'@'10.x.x.x' IDENTIFIED BY 'IAM_AUTH_PROXY';
-- 実行に必要な権限のみを付与（最小権限）
GRANT SELECT, INSERT, UPDATE ON app_database.* TO 'gke_app_writer'@'10.x.x.x';
-- DBAの管理用アカウントとは権限を完全に分離する
最終チェックとオブザーバビリティの重要性
この節を読めば：シリーズ全体を通して設計したアーキテクチャの健全性を評価できます。
本シリーズで設計したハイブリッドクラウドアーキテクチャの健全性は、**オブザーバビリティ（可観測性）**によって担保されます。特に、オンプレミスとクラウドをまたぐデータアクセスにおいて、以下の3要素を統合して監視することが、性能問題やセキュリティインシデントの迅速な解決に不可欠です。
- ログ（Logging）: GKE Podのアプリログ、VPC Connectorのフローログ、DBのSlow Queryログなど、分散したログを一元的に集約（例: Cloud Logging）。
- メトリクス（Metrics）: RTT（第3回）、DB接続数（第3回）、IOPS（第4回）、CPU/メモリ使用率を定量的に監視（例: Cloud Monitoring）。
- トレース（Tracing）: アプリケーションのユーザーリクエストがGKE、VPC Connector、オンプレDBを横断する際の処理時間を可視化（例: Cloud Trace）。
最終的に、この統合された監視基盤によって、設計どおりのSLA（サービス品質保証）が達成されているかを継続的に検証します。
まとめ：ハイブリッドクラウド設計の総括
全8回のうち、第6回までで設計の主要な要素が完了しました。
- コンピューティング基盤
- ネットワーク接続
- データ永続化
- セキュリティ
- データベース
この設計パターンは、レガシーを抱えつつクラウドネイティブを目指すエンタープライズ企業にとって、安全かつ効率的なハイブリッドジャーニーの確かな設計指針となるでしょう。
ハイブリッドクラウド × ゼロトラスト × IaC の実践アーキテクチャ設計