0. はじめに
前回はストレージ系のサービスをまとめました。今回はその第3弾として、データベース系のサービスを見ていきます。
AWSでRDS/DynamoDBを触ったことがあれば、Google Cloud側もそこまで迷わず理解できるかと思います。
1. データベース
| カテゴリ | AWS | Google Cloud |
|---|---|---|
| リレーショナル (RDBMS) | RDS | Cloud SQL |
| 高性能PostgreSQL互換 | Aurora (PostgreSQL互換) | AlloyDB for PostgreSQL |
| 分散リレーショナル | - | Cloud Spanner |
| ドキュメント型NoSQL | DynamoDB / DocumentDB | Firestore |
| ワイドカラム型NoSQL | DynamoDB / Keyspaces | Cloud Bigtable |
| インメモリキャッシュ | ElastiCache | Memorystore |
| DB移行 (低ダウンタイム) | DMS | Database Migration Service (DMS) |
| サードパーティSaaS DBのマネージド提供 | AWS Marketplace | Google Cloud Marketplace |
1-1. Cloud SQL
RDSに相当する、MySQL、PostgreSQL、SQL Serverを提供するフルマネージドのリレーショナルデータベースです。OLTP(トランザクション処理)ワークロードに特化しており、厳密な整合性・複数テーブルにまたがるACID特性を提供します。
- 一般的なWebアプリケーションや業務システムに適していますが、ペタバイト規模への急拡大や超高スループットのIoTデータには向きません。
- 基本的にリージョン(単一地域)レベルのサービスです。クロスリージョンレプリケーションで読み取りレプリカは複数リージョンに置けますが、書き込みは単一のプライマリインスタンスに限定されるため、グローバルに分散したユーザーへ低レイテンシで書き込みを提供したい場合はSpannerの方が適します。
- 既存アプリケーションがPostgreSQL/MySQL/SQL Serverで実装されている場合、最小限のコード変更でクラウド化できます。
- 自動バックアップとエクスポートの使い分け: 自動バックアップは短期的な障害復旧が目的で、保持期間はデフォルト7日程度までしか延ばせません。「毎月1日時点のコピーを3年間保持したい」といった監査目的の長期保存には、エクスポート機能でCloud Storage(Archiveクラス)へ毎月書き出すジョブを組むのが定石です。
- リージョン障害に対する災害復旧: Cloud SQLの公式なDR手法は、クロスリージョンリードレプリカを構成しておき、災害時にそのレプリカをスタンドアロンのプライマリインスタンスへ昇格させる方法です。非同期レプリケーションで継続的に複製されるためRPO(目標復旧時点)が数分程度、昇格操作だけで復旧できるためRTO(目標復旧時間)が10分〜2時間程度、という厳格な要件を運用の複雑さを抑えたまま満たせます。
- 高可用性(HA)構成のスタンバイは同一リージョン内の別ゾーンに配置されるためゾーン障害対策にとどまり、リージョン全体の障害には対応できません。
- 外部MySQLへの変更の自動伝播: 中央のCloud SQL for MySQLから、スキーマの異なる複数の外部MySQLデータベース(海外拠点のローカルDB等)へ変更を配布したい場合を考えます。まず各拠点のスキーマをCloud SQL側と標準化し、そのうえで各拠点のデータベースをCloud SQLの外部リードレプリカとして構成すると、MySQLネイティブのレプリケーションで変更がほぼリアルタイムに自動伝播します。
1-2. AlloyDB for PostgreSQL
Aurora(PostgreSQL互換)に相当する、PostgreSQL互換のフルマネージドリレーショナルデータベースです。
- 100% PostgreSQL互換が最大の特徴で、既存のPostgreSQLアプリケーションをスキーマ・コードにほぼ手を入れずに移行できます。
- ストレージとコンピューティングを分離したアーキテクチャや専用のカラム型エンジンにより、標準的なPostgreSQLと比べてトランザクションワークロードで最大4倍、分析クエリで最大100倍高速とされています。ストレージ・コンピューティングを独立してスケールできるため、大規模なデータセットにも対応可能です。
- Cloud SQL for PostgreSQLよりも高い性能・可用性が求められるワークロード向けの上位選択肢という位置づけです。
1-3. Cloud Spanner
リレーショナルデータベースの強い整合性(ACID特性)と、NoSQLのような水平スケーラビリティを両立したサービスです。
- グローバル規模でダウンタイムなしの動的スケーリングが可能で、大規模な決済処理などに適しています。
- BigQueryと異なりOLTP向けであり、料金もプロビジョニングしたノード/処理ユニットとストレージに基づきます(クエリ実行量に応じた従量課金ではありません)。
- Spannerは100% PostgreSQL互換ではありません。移行時はスキーマ・コードの変更を伴うため、PostgreSQL互換性を優先するならAlloyDB、グローバルな水平スケールを優先するならSpannerが候補になります。
- AWS側には長らく単純な1対1の対応先がありませんでしたが、分散SQLデータベースのAurora DSQLが近い立ち位置のサービスとして登場しています。
- 高優先度CPU使用率のアラートしきい値: Googleの推奨最大値はリージョンインスタンスで65%、マルチリージョンインスタンスで45%です。超過時に最短でパフォーマンスを回復させるには、クエリの書き直しよりもノード追加(水平スケーリング)の方が直接的です。
- ホットスポットとプライマリキー設計: プライマリキーに「登録順の連番」のような単調増加する値を使うと、Spannerがキー範囲ごとに分散させるデータが特定サーバーに集中し、読み取りが遅くなります。UUID等のランダムな値やハッシュ化した値に変えるのが定石です。
- サポートチームにテーブルデータへのアクセスはさせずCPU使用率・レイテンシなどの監視だけ許可したい場合は、
roles/monitoring.viewerを付与します(パフォーマンスメトリクスは自動でCloud Monitoringに出力されます)。
1-4. Firestore
DynamoDB/DocumentDBに相当する、モバイルやWebアプリのバックエンドに適したフルマネージドのNoSQLドキュメントデータベースです。
- 固定されたスキーマを持たず、柔軟なデータ構造を格納できます。モバイルSDKを通じたリアルタイム同期に優れます。
- 数百万デバイスからの高スループットな時系列データ書き込み(IoT用途)には特化していません(その用途はCloud Bigtable)。
- ローカルテストにはDatastoreエミュレータを利用できます。
gcloud components install cloud-datastore-emulatorでインストールしますが、Cloud SDKの導入方法(apt/tarball)やバージョンによってパッケージ名が変わる場合があるため、公式手順もあわせて確認してください。
1-5. Cloud Bigtable
DynamoDB/Keyspacesに相当する、ペタバイト規模のデータをミリ秒単位の低レイテンシで処理できる、フルマネージドのワイドカラム型NoSQLです。
- 高い書き込みスループットを持ち、IoTセンサーデバイスからのデータキャプチャや大量の時系列データの分析に最適です。
- GoogleSQLによる基本的なSELECTクエリには対応していますが、INSERT/UPDATE/DELETEなどのDML、JOIN・サブクエリ、複数行の複雑なトランザクションはサポートしません。
- 「Cloud Bigtable ML」という機能は存在しないので、BigQuery MLと混同しないよう注意が必要です。
- 「データごとに保持期間が来たら自動削除し、期間未到達のデータは残す」というレコード(セル)単位の自動失効を実現したい場合は、列ファミリーに経過時間ベースのガベージコレクションポリシー(最大経過時間、TTL)を設定します。テーブル全体の有効期限設定やディスク・バケット単位の一括削除は、保持期間に達していないデータも巻き込んで消してしまうため、レコード単位の選択的失効には使えません。
- PIIなどの機密データを扱う場合、テーブルへの読み取り・書き込み操作を監査ログに残すにはデータアクセス監査ログを明示的に有効化する必要があります(デフォルトでは無効)。
- 行キー(RowKey)設計とホットスポット: Bigtableは行キーの辞書順にデータを分割・配置するため、タイムスタンプや連番のデバイスIDを行キーの先頭に置くと、書き込み・読み取りが特定ノードに集中する「ホットスポット」が発生します。根本対策はノード数を増やすことではなく、行キーがキー空間全体に均等分散するよう設計を見直すこと(ハッシュ化やフィールド順の入れ替え)です。
- 行キーの順序は検索条件に合わせる: 複数条件(車両ID・イベントID・期間など)で絞り込んで読み取りたい場合は、行キーを検索条件の階層順に構成します。目的のデータが連続した行範囲にまとまり、プレフィックス指定の範囲スキャンで効率よく読み取れます(この場合もタイムスタンプは先頭に置きません)。
1-6. Memorystore
ElastiCacheに相当する、Redis・Valkey・Memcachedのフルマネージドなインメモリデータストアサービスです。
- キャッシュ層やセッションストア、リアルタイムのランキング処理などレイテンシが重要な用途に利用されます。
- Redis/Valkey向け(Memorystore for Redis/Valkey)とMemcached向け(Memorystore for Memcached)が別サービスとして提供されていますが、Memcached向けは2026年1月20日付で非推奨化が開始されており、Valkeyへの移行が案内されています。
- あくまでインメモリのキャッシュ/データストアなので、Apache Kafkaのようなイベントストリーミング基盤の代替にはなりません。オンプレのKafkaの移行先はCloud Pub/Subです。
1-7. Database Migration Service (DMS)
AWSのDMSに相当する、MySQLやPostgreSQLなどのデータベースをCloud SQLまたはAlloyDB for PostgreSQLへ移行するための、フルマネージドでサーバーレスなサービスです。Oracle・SQL ServerからPostgreSQL系への異種移行にも対応しています。
- CDC(Change Data Capture)技術によりソース側の変更を継続的に反映し、本番環境のダウンタイムを最小限に抑えた移行を実現します。転送中のデータは暗号化により保護されます。
- Storage Transfer Service(ファイル/オブジェクト単位の転送)やTransfer Appliance(物理デバイスでのオフライン移行)とは異なり、稼働中のリレーショナルDBの構造・データを保持したまま移行する点が特徴です。
1-8. Google Cloud Marketplaceのサードパーティマネージドデータベース
AWS Marketplaceに相当する、MongoDBのようにGoogle Cloudがネイティブに提供していないデータベースエンジンでも、サードパーティベンダーがフルマネージドなサービスとして提供している仕組みです(MongoDB社が提供するMongoDB Atlasが代表例)。
- Marketplace経由でデプロイすると、バックアップ・パッチ適用・スケーリング・高可用性の管理をベンダー側に任せられ、サポートSLAも受けられます。Compute Engine上に自前で構築する場合、これらはすべて自己責任になります。
- Cloud BigtableのHBase互換APIとはデータモデル・クエリ言語が異なり、MongoDBワークロードの代替にはなりません。
2. まとめ
今回はデータベース系のサービスをまとめました。リレーショナル・NoSQL・インメモリとカテゴリごとの対応はほぼ1対1ですが、Cloud Spannerのようにリージョン/グローバルという単一軸だけでは選びきれないサービスもあり、要件(整合性・スケール範囲・運用負荷)を分解して選定する必要があるカテゴリだと感じました。
次回はネットワーク系のサービスをまとめる予定です。
参考