1.
Cloud Onr
Cloud OnAir
Cloud OnAir
Google Cloud における RDBMS 運用
2020 年 11 月 19 日 放送

2.
写真を配置後
角丸六角形くり抜きの図形を
被せてください
https://goo.gl/NcsiAz
Speaker
Cloud OnAir
Data Management Specialist
Daichi Egawa
Google Cloud Japan にてデータベース関連の
サービスの技術支援に従事。

3.
Agenda
Cloud OnAir
1
3
2
4
RDBMS 運用における課題
Google Cloud のデータベース ソリューション
Cloud SQL による課題の解決とその特徴
Cloud Spanner による課題の解決とその特徴

4.
Cloud OnAir
Cloud OnAir
RDBMS 運用における課題

5.
Cloud OnAir
現代のビジネス状況
予測可能・連続的 予測不可能・非連続的
（コロナ、デジタル化による産業の変化 etc.）

6.
Cloud OnAir
不確実性の時代におけるデータベース運用の課題
導入・保守コスト 俊敏性・拡張性 機会損失の防止・可用性

7.
Cloud OnAir
導入・保守コスト
● 初期投資はなるべく避けたい
● 固定費は削減したい
● データベースの運用、保守には多額の費用がかかる

8.
Cloud OnAir
データベース運用に関わるタスク
● データベース運用には
多くのタスクが発生
● 組織によっては、
それぞれのタスクの
担当者が異なる
○ タスクの依頼や連携にも課
題があるケースも
アプリの最適化
電源 / HVAC /
ネットワーク
DB バックアップ
& 監視
スケーラビリティ
ホスト
メンテナンス
OS / DB インストール&
パッチ
ラックの
導入と管理
高可用性構成
典型的なデータベース管理

9.
Cloud OnAir
俊敏性・拡張性
● ハードウェアの導入、データベース構築に
時間がかかる
● サイジングやキャパシティ プランニングが困難である
● CPU、メモリ、ストレージの追加などのイベントが
長時間かかる。場合によってはトラブルにつながる。

10.
Cloud OnAir
機会損失の防止・可用性
● 機会損失防止のために、ダウンタイムは避けたい
● 可用性向上のための高度な設定を行うことができる
人材が不足している
● 本来、冗長化が必要なシステムであるにも関わらず、単一
障害点を許容する構成になっていることがある

11.
Cloud OnAir
Cloud OnAir
クラウド データベースによる
課題へのアプローチ

12.
データベース管理戦略の進化に合わせて自社の戦略を変更
Gartner, Inc.* によると、2022 年までに、すべての
データベースの 75 % はクラウド プラットフォームに
デプロイまたは移行されると予測され、これまでに
クラウドからオンプレミスに戻すことを検討された
データベースは 5 % にすぎません。
*Gartner のプレスリリース
出典: 「Gartner Says the Future of the Database Market is in the Cloud」、2019 年 7 月 1 日
詳細: https://cloud.google.com/solutions/data-management?hl=ja

13.
Cloud OnAir
近年のデータベース利用におけるトレンド
● コスト低減に向けた取り組み
○ クラウド コンピューティングへの移行
● データベース運用の省力化に向けた取り組み
○ マネージドサービス(Database as a Service (DBaaS)
Cloud Native DB) への移行

14.
Cloud OnAir
データベース構築の選択肢
クラウド
オンプレミス上に構築 IaaS 上に構築 DBaaS (*) を
利用
Cloud Native DB (**)
を利用
(*)既存 RDBMS との強い互換性を保持するサービス
(**)DBaaS の中でもクラウドで動かすことを前提に作られた新しいアーキテクチャをもつサービス

15.
Cloud OnAir
クラウドコンピューティング利用によるコスト削減
● 規模の経済
○ データセンター、HW は大量に
一括調達したものを利用可能
● 従量課金
○ 開発工程が終わったら、開発環境を
停止してコスト削減
○ 検証サーバは土日など停止可能
○ 減価償却などのオペレーションが不要
● データセンターでの物理的な作業が不要
○ オペレーションを改善し、より開発スピードUP
コスト削減↓

16.
Cloud OnAir
データベース構築の選択肢
クラウド
オンプレミス上に構築 IaaS 上に構築 DBaaS (*) を
利用
Cloud Native DB (**)
を利用
(*)既存 RDBMS との強い互換性を保持するサービス
(**)DBaaS の中でもクラウドで動かすことを前提に作られた新しいアーキテクチャをもつサービス

17.
Cloud OnAir
DBaaS, Cloud Native DB 選択の背景
● DBaaS, Cloud Native DB は、マネージドサービス
○ データベース運用に必要な作業をクラウド プロバイダーにオフロード
● 俊敏性、拡張性のための機能
○ データベース プロビジョニングは自動化され、即座に起動可能
○ ストレージ容量の管理、スケール アップ が容易に可能
○ Cloud Native DB ではストレージなどのサイジングが不要になることが多い
(ユーザーが意識しなくても自動で拡張する)
● 高可用性のための機能
○ 冗長構成を簡単に構築 (DBA が工数を費やす作業をそのまま利用可能)
○ Cloud Native DB では高可用性がビルトインされた設計になっていることが多い
(ユーザーが意識しなくても冗長構成が保たれている)

18.
なぜマネージド データベースを活用すべきか
アプリの最適化
電源 / HVAC /
ネットワーク
DB バックアップ
& 監視
スケーラビリティ
ホスト
メンテナンス
OS / DB インストール&
パッチ
ラックの
導入と管理
高可用性構成
典型的なデータベース管理
● マネージド DB の活用により優秀なエンジニアの生産性を向上
Cloud OnAir

19.
なぜマネージド データベースを活用すべきか
アプリの最適化
電源 / HVAC /
ネットワーク
DB バックアップ
& 監視
スケーラビリティ
ホスト
メンテナンス
OS / DB インストール&
パッチ
ラックの
導入と管理
高可用性構成
典型的なデータベース管理
● マネージド DB の活用により優秀なエンジニアの生産性を向上
Cloud OnAir
IaaS 上にデータベースを構築した場合でも
これらの作業の負荷軽減が可能

20.
なぜマネージド データベースを活用すべきか
アプリの最適化
電源 / HVAC /
ネットワーク
DB バックアップ
& 監視
スケーラビリティ
ホスト
メンテナンス
OS / DB インストール&
パッチ
ラックの
導入と管理
高可用性構成
典型的なデータベース管理
● マネージド DB の活用により優秀なエンジニアの生産性を向上
Cloud OnAir
DBaaS, Cloud Native DB での
データベース管理
プログラミング
アプリの最適化/
チューニング
サーバ管理、スケーリングやバッ
ク アップはサービスの
一部として提供

21.
Cloud OnAir
即座に起動、削除、よりスムーズに拡張
● 即座に起動、削除
○ GUI により数クリックの操作で起動
○ CLI により作成作業の自動化も可能
○ 削除も同様にできるので、
不要になったら即座に削除
● 拡張
○ ワークロードに合わせて柔軟に変更可能
○ 拡張作業も GUI, CUI で即座に実施可能

22.
可用性、耐障害性の向上もより簡単に
Cloud OnAir
● データベース管理者が時間を費やす
高度な設定がビルトイン
○ レプリケーション、
自動フェイル オーバー
○ 自動バック アップ
○ 数クリックでのデータベース復元
ゾーンA ゾーンB
永続ディスク 永続ディスク
リージョン IPアドレス
プライマリDB スタンバイDB
リージョン
永続ディスク
レプリケーションの例

23.
Cloud OnAir
Cloud Native DB によるさらなる運用省力化
● Cloud Native DB では、DBaaS 以上に
インフラストラクチャレイヤーが抽象化(ユーザー
が意識しなくて良い) され、
運用負荷軽減に繋がる
● 以下のような機能がビルトインされているケース
が多い
○ 自動シャーディング
○ ストレージの自動スケーリング
○ 計画的なメンテナンスによる
ダウンタイムがない
自動スケーリングの例

24.
Cloud OnAir
Cloud OnAir
Google Cloud の
データベース ソリューション

25.
Cloud OnAir
Google Cloud のデータベース ソリューション
Cloud
Memorystore
BigQuery
Cloud Datastore /
Cloud Firestore
Cloud
Bigtable
Cloud
SQL
Cloud
Spanner
● すべてマネージドサービスとして
前述の課題へのアプローチが可能
○ 導入・保守コストの軽減
○ 即座に利用可能、ワークロードに合わせた拡張
○ 高い可用性をもつための機能、設計
● 多様な選択肢
○ ユースケース、ワークロードに合わせて
最適なサービス選択が可能
○ 複数のサービスを組み合わせて実施可能
○ 必要に応じて Compute Engine (IaaS) 上に
構築することも可能

26.
Google Cloud のデータベース関連サービス
Cloud OnAir
移行に適した
OSS および 商用 DB
モダナイズに適した
クラウドネイティブ DB
データ
ウェアハウスキャッシュ
Cloud
Memorystore
BigQuery
マネージド
Redis &
memcached
Cloud Firestore
(Native / Datastore Mode)
サーバーレスで
スケーラブルな
ドキュメントストア
Cloud
Bigtable
低レイテンシで
スケーラブルな
ワイドカラムストア
Cloud
SQL
マネージド
MySQL &
PostgreSQL &
SQL Server
Cloud
Spanner
スケーラブルで
可用性の高い
ミッション
クリティカル
RDBMS
サーバーレスで
スケーラブルな
エンタープライズ
DWH
今回のテーマ

27.
Cloud OnAir
Compute Engine (IaaS) 上に DB 構築するという選択肢
● Compute Engine 上ではより自由度の高い選択やデータベース運用が可能
● 以下のようなケースでは、Compute Engine 上での DB 構築が必要
○ マネージド サービスでは対応していないRDBMS, バージョンを利用したい
○ マネージド サービスで提供されるCPU、メモリ サイズでは不足する
○ OS への設定が必須である
■ OS パラメータをチューニングしたい
■ データベースと同じ OS 上に監視エージェントなどを
インストールしたい
○ データベースの管理者権限が必要な処理がある

28.
Cloud OnAir
Cloud OnAir
Cloud SQL

29.
Cloud OnAir
Cloud SQL とは？
フルマネージドなリレーショナル データベース サービス高可用
性、バックアップ、暗号化、パッチ適用、
容量増加などが組み込まれた RDBMS の
マネージド サービス
MySQL
PostgreSQL
SQL Server
Google Cloud の各種サービスとの容易な統合
クライアントやドライバーを用いた接続だけでなく
GCP の各種サービスと容易に連携可能

30.
Cloud OnAir
Cloud SQL の特徴
導入・保守コスト 俊敏性・拡張性 機会損失の防止・可用性
● 規模の経済
● 従量課金
● フルマネージド
サービスによる
保守コストの削減
● すぐに簡単に作成可能
● 容易なスケールアップ
● ストレージの
自動スケーリング
● リード レプリカによる
参照スケールアウト
● 高可用性設定
(同期レプリケーション＋
自動フェイル オーバー)
● 自動バックアップ

31.
Cloud SQL (高可用性構成) のアーキテクチャ イメージ
Cloud OnAir
ゾーン A ゾーン B
永続ディスク 永続ディスク
東京リージョン
IPアドレス
プライマリDB
スタンバイDB
リージョン
永続ディスク
同期レプリケーション
リードレプリカ
リードレプリカ
非同期レプリケーション

32.
Cloud OnAir
各種 DB インスタンスを簡単に作成
数ステップで DB インスタンスを作成
● 最低限の情報を入れるだけで作成可能
● 必要に応じて設定オプションを追加
柔軟に選択可能なマシンタイプ
● CPU 最大 96 コア
● RAM 最大 624 GB

33.
Cloud OnAir
自動拡張するスケーラブルなストレージ
容量に応じた性能をプロビジョニング
● 容量は最小 10 GB から最大 30 TB
● SSD または HDD を選択可能
● 最大 60,000 IOPS
必要に応じて自動拡張
● ストレージのサイジングが不要で
拡張に伴う停止も無し

34.
リードレプリカによる性能向上
ゾーン A ゾーン B
東京リージョン IP アドレス X
プライマリDB
リードレプリカ リードレプリカ
IP アドレス Y IP アドレス Z
非同期レプリケーション
● プライマリ インスタンスより
非同期レプリケーションにより
データを複製
● 読み取りの負荷分散が可能
● 注意
○ 本機能は PostgreSQL, MySQL
エンジンで提供
○ 接続先となる IP アドレスは
プライマリ インスタンスのものとは
異なる
○ リードレプリカは性能向上のための
機能。高可用性を備えたものではなく、
それを提供するものではない。

35.
Cloud OnAir
自動バックアップにより容易に実現できる高可用性
自動取得される日時バックアップ
● 時間帯を選択するだけで自動取得
● 任意時間でオンデマンド取得も可能
● 最大 7 世代まで保持

36.
HA 構成による高可用性
- ゾーン間でのリアルタイム データ同期
ゾーンA ゾーンB
永続ディスク 永続ディスク
東京リージョン IPアドレス
プライマリDB スタンバイDB
リージョン
永続ディスク
リージョン永続ディスクによる同期
プライマリ DB への書き込みは、
リージョン永続ディスク（Regional PD）を通
じ、スタンバイ DB が配置されたゾーンの永
続ディスクへも
同期書き込みが行われる
これによりレプリケーション遅延が
なくなり、フェイルオーバーにかかる
時間を大幅に短縮

37.
Cloud OnAir
Cloud OnAir
Cloud SQL アップデート

38.
Cloud OnAir
主な新機能 (1 / 2)
● Cloud SQL 共通
○ Cloud SQL インスタンスのメンテナンス事前通知とスケジュール変更
○ メンテナンス拒否期間の設定
○ リージョン間の Private IP 接続
○ クロス リージョン レプリカのサポート (PostgreSQL、MySQL エンジンでサポート）
○ サーバーレス エクスポートをサポート (PostgreSQL、MySQL エンジンでサポート）
○ Cloud VPN 経由の接続をサポート
○ VPC サービス コントロールのサポート
○ 顧客管理の暗号鍵 (CMEK) のサポート
○ 確約利用割引 (CUD) をサポート
その他、新しいマシンタイプの登場なども！
詳細: https://cloud.google.com/sql/docs/release-notes

39.
Cloud OnAir
主な新機能 (2 / 2)
● For MySQL
○ MySQL 8.0 をサポート
○ データベースフラグを 80 までサポート
● For PostgreSQL
○ PostgreSQL 12 をサポート
○ PostgreSQL 13 をサポート
○ PostgreSQL にて新たに 8 つの拡張機能をサポート
○ Cloud SQL IAM データベースの認証をサポート
○ pgAudit (監査に利用可能な拡張機能 )をサポート
● For SQL Server
○ SQL Server エンジンをサポート
○ デフォルトの照合順序を設定をサポート
詳細: https://cloud.google.com/sql/docs/release-notes

40.
● 96 コア マシンタイプの登場
● MySQL 8.0 のサポート
● PostgreSQL 10, 12, 13 のサポート
● SQL Server 2017 のサポート
最新 DB バージョンへの追従は常に行っているため、最新情報を確認のこと
新たに追加されたマシンタイプと DB バージョンUpdates
Cloud OnAir

41.
メンテナンス通知の受信
● 実施予定日の 1 週間前までにコンソール上で通
知を確認できる
● メール通知を受け取るには、コンソールの
設定よりメンテナンスの時間枠の通知を
有効化
メンテナンス期間の拒否
● メンテナンス 1 回につき、1度の
拒否期間 (1 ～ 90 日)を設定可能
○ 繁忙期のメンテナンス実施を回避可能
Cloud SQL インスタンスのメンテナンス事前通知Updates
Cloud OnAir

42.
1. pg_repack
オンラインでのテーブル及び
インデックスの再編成が可能
2. postgres_fdw
リモートの PostgreSQL に接続し
テーブルを参照することが可能
● PostgreSQL は機能拡張が可能で、さまざまなモジュールが提供されている
● Cloud SQL for PostgreSQL でサポートされてきた PostGIS もその 1 つ
PostgreSQL の拡張機能の追加Updates
3. pageinspect
4. pgfincore
5. pg_freespacemap
6. pg_visibility
7. PL/Proxy
8. postgresql-hll
2020年に追加された拡張機能
9. pgAudit
より柔軟なデータ
ベースの監査が可能
Cloud OnAir

43.
マスターと異なるリージョンにリードレプリカを
配置することが可能になった
クロスリージョンレプリカの利点
● アプリに近いリージョンにレプリカを
配置することで読み取り性能の向上
● レプリカはマスターへ昇格可能であり
DR サイトの構築が可能
クロスリージョン レプリカUpdates
Cloud OnAir

44.
Cloud SQL において、
異なるリージョン間での
プライベート IP による通信が
できるようになった
そのため、利便性や可用性が
さらに向上した
リージョン間のプライベート IP 接続Updates
Cloud SQL の専用 VPC
東京リージョン
10.35.32.0/24
master-db
10.35.32.3
大阪リージョン
10.35.33.0/24
replica-db1
10.35.33.3
ユーザーの VPC
東京リージョン
10.146.0.0/20
client-vm
10.146.0.6
Private IP 通信
北米リージョン
10.35.34.0/24
replica-db2
10.35.34.3
クロスリージョン
レプリケーション
東京リージョンから、
大阪リージョンや
北米リージョンなど、
異なるリージョンの
Cloud SQL へプライベートIP 通信
が可能

45.
● 確約利用割引 (CUD) とは
○ データベース インスタンスを、
継続使用することと引き換えに
適用される割引料金
● 特徴
○ 1 年間 (25% 割引) or 3 年間 (52% 割引)
○ リージョン内の Cloud SQL インスタンスの
使用量の合計に自動的に適用 (適用する
インスタンス、エンジンの選択の必要なし)
● 注意点
○ 特定のリージョンを選択してのコミットメント
○ 共有 CPU マシンタイプ (db-f1-micro、db-g1-small な
ど) は対象外
確約利用割引 (CUD) をサポートUpdates
Cloud OnAir

46.
Cloud OnAir
Cloud OnAir
Cloud Spanner

47.
Cloud OnAir
Cloud Spanner 概要
フルマネージドなデータベースで容易に構成可能、パッチ適用なども全自動
テーブル構造に対してSQL でのクエリや、ACID トランザクションをサポート
DR 構成も可能で 99.999 % の可用性を提供、メンテナンスによるダウンタイムも無し
テーブルは自動シャーディングされ、スケール アウト / インが実施可能
クラウド ネイティブのリレーショナルデータベース
リレーショナル データベースのようテーブル構造に対してSQL と
トランザクションをサポートし、NoSQL のようなスケーラビリティを持つ

48.
Cloud OnAir
Cloud Spanner の特徴
導入・保守コスト 俊敏性・拡張性 機会損失の防止・可用性
● 規模の経済
● 従量課金
● フルマネージド
サービスによる
保守コストの削減
● すぐに簡単に作成可能
● ノード追加による
スケール アウト
● ストレージの
自動スケーリング
● デフォルトで冗長化
● 最大 99.999 % の可用性
● マルチリージョン
構成による災害対策
● ダウンタイムなしで
様々なオペレーションが可能

49.
Cloud OnAir
Cloud Spanner の設定項目
インスタンス名 / ID
任意の名前を入力
構成
どこのリージョンに
インスタンスを
構築するかを選択
ノード数
必要なスループット性能に
応じてノード数を入力
必要な入力項目は
わずか 3 種類

50.
Cloud OnAir
Cloud Spanner の設定項目
インスタンス名 / ID
任意の名前を入力
構成
どこのリージョンに
インスタンスを
構築するかを選択
ノード数
必要なスループット性能に
応じてノード数を入力
必要な入力項目は
わずか 3 種類
可用性に影響を与える
設定項目
性能 (スループット) に
影響を与える設定項目

51.
Cloud OnAir
Cloud OnAir
可用性の仕組み
- 構成の選択とレプリケーション

52.
Cloud OnAir
Cloud Spanner の設定項目
インスタンス名 / ID
任意の名前を入力
構成
どこのリージョンに
インスタンスを
構築するかを選択
ノード数
必要なスループット性能に
応じてノード数を入力
必要な入力項目は
わずか 3 種類

53.
53
東京リージョン（asia-northeast1）
内部は a, b, c の 3 つのゾーンに
分かれている。
大阪リージョン（asia-northeast2）
内部は a, b, c の 3 つのゾーンに
分かれている。
リージョン
独立した地理的地域のこと。
各リージョンには少なくとも 3 つのゾーン
があり、同一リージョン内のネットワーク
レイテンシは
95 % tile で 1 ms 未満になるように
設計されている。
ゾーン
同一リージョン内の各ゾーンは
独立されて設計されており、電源、
冷却、ネットワーク、コントロール
プレーンなどは、他のゾーンから
切り離されている。
https://cloud.google.com/solutions/best-practices-compute-engine-region-selection?hl=ja
a
b
c
a
b
c
Google Cloud のリージョンとゾーン

54.
54
東京リージョン
大阪リージョン
シングル リージョン構成
日本国内には東京と大阪の 2 リージョンから選
択。もちろんその他海外のリージョンも
選択可能。可用性は 99.99 %
マルチ リージョン構成
複数のリージョンを同時に利用することにより、可用
性を 99.999 % に向上させ、またリージョン障害や災
害など地理位置に依存した障害にも
耐えることができる。
日本では、東京及び大阪 (及びソウル*1
) を同時に利
用することで実現
*1) ソウルには実際のデータを保存しないが、
リージョン障害発生時においてもデータの
整合性担保ができるよう通信を行う。
Cloud Spanner の構成
Cloud OnAir

55.
Cloud OnAir
Cloud Spanner インスタンスの作成画面
インスタンス名 / ID
任意の名前を入力
構成
どこのリージョンに
インスタンスを
構築するかを選択
ノード数
必要なスループット性能に
応じてノード数を入力
必要な入力項目は
わずか 3 種類
構成：
(シングル) リージョン
ノード数：1

56.
Cloud Spanner のアーキテクチャ イメージ
Cloud OnAir
東京リージョン (asia-northeast1)
ゾーン a ゾーン b ゾーン c
Cloud Spanner
インスタンス
1 ノード
node1 node1 node1
分散ストレージ 分散ストレージ 分散ストレージ
● ノード数に関係なく裏側で冗長化(ノード数 1 でも単一障害点のない構成)
● データはノードとは分離された分散ストレージに保存
● コンピュートとストレージは切り離されており、それぞれ独立して性能と可用性を担保
コンピュート
ストレージ
コンピュート
ストレージ

57.
Cloud Spanner は強整合性をもったレプリカを持つ
Cloud OnAir
東京リージョン (asia-northeast1)
ゾーン a ゾーン b ゾーン c
node1 node1 node1
データはゾーンごとにレプリカが作成される。1 つがリーダー(代表者) となり、
分散合意アルゴリズムとしてのPaxos アルゴリズムを用いた同期レプリケーションにより、
強整合性を持った複製を持っている。
コンピュート
ストレージ
分散ストレージ 分散ストレージ 分散ストレージ
強整合性を持った
レプリケーション レプリカ レプリカ
レプリカ
（Leader）

58.
強整合性をもったレプリケーションをするための条件
Cloud OnAir
Google Cloud 東京リージョン
ゾーン a ゾーン b ゾーン c
強整合性を持ったレプリケーション
レプリカのうち 1 つがリーダー（Leader）となり、
書き込みリクエストはリーダーが受け付ける。
書き込みを commit する際、リーダーは他のレプリカに
更新内容を転送しつつ、この内容で書き込みを行っても
問題ないか採決を行う。 全体のレプリカのうち 過半数から同
意が得られたら、書き込みが成功となる。
障害があっても、レプリカの過半数が生き残れば
処理を継続できる。
commit しても良いか？
commit
ok
ok
リーダー（Leader）
書き込みリクエストを
受け付ける。
リーダー自身も
採決に参加する。
遠くのレプリカからの返事
リーダー含めて過半数 (3 分の 2) からの応答を
待てばよいので、地理位置が離れており、遠くにある
レプリカの応答は、障害時以外では通常待たずに
書き込み成功とみなされる。
レプリカ
レプリカ
（Leader）
レプリカ

59.
ゾーン障害時は他のレプリカがリーダーに昇格
東京リージョン (asia-northeast1)
ゾーン a ゾーン b ゾーン c
Cloud Spanner
インスタンス
1 ノード
node1 node1 node1
分散ストレージ 分散ストレージ 分散ストレージ
59
ゾーン障害時は他のレプリカがLeader となり、ダウンタイムなく処理を継続することができる。
レプリカ
レプリカ
（Leader）
障害
昇格
Cloud OnAir

60.
60
東京大阪マルチリージョン構成 (asis1)
Cloud OnAir
正常時
マルチ リージョン構成では 5 つレプリカがあるので、
過半数である 3 つから返事がくれば良い。
正常時は、まず東京リージョンに書き込みが行き、
東京で 2 つ、大阪から 1 つ応答があった時点で、
書き込みが成功する。東京ソウル間のレイテンシは
無視できる。
障害時
東京リージョン障害時の場合、大阪リージョンが
リーダーになる。その場合であっても、大阪 2 つ、
ソウル 1 つで過半数を満たせるため、レプリカ間の
整合性を保ちながら、処理を継続できる。
DR を含め様々な障害に自動対応可能
これらが全てフルマネージドで提供され、
稼働率として SLA 99.999 % を提供。
ウィットネス レプリカ
（データを保持しない）
リーダー レプリカ
レプリカ

61.
Cloud Spanner マルチ リージョン構成におけるレプリカ構成
東京リージョン (asia-northeast1)
node1 node1
分散ストレージ 分散ストレージ
マルチ リージョン構成であっても、シングル リージョンの仕組みの
延長で構築できる。リージョン障害時であっても
過半数のレプリカを残すためには、3 つのリージョンで
構築する必要がある。
レプリカ
レプリカ
（Leader）
大阪リージョン (asia-northeast2)
node1 node1
分散ストレージ 分散ストレージ
レプリカレプリカ
ソウルリージョン
(asia-northeast3)
node1
ウィットネス レプリカ
レプリカ間の整合性を保つための投票には
参加するが、データを保存しないレプリカ。
合意に必要な情報は受け取るが、それを
取得可能なデータとしては保存せずに捨てる。
Cloud OnAir

62.
Google Cloud 東京リージョン
ゾーン a
(参考) 障害発生時に過半数のレプリカが保てない構成
62
データ
ゾーン b
データ
Google Cloud 大阪リージョン
ゾーン a
データ
ゾーン b
データ
例 1 - 東京 2, 大阪 2
単一リージョンだけで
過半数を満たせないので、リー
ジョン障害に
耐えられない。
Google Cloud 東京リージョン
ゾーン a
データ
ゾーン b
データ
Google Cloud 大阪リージョン
ゾーン a
データ
ゾーン bゾーン c
データ データ
例 2 - 東京 3, 大阪 2
東京リージョン障害時に、
大阪リージョンだけで
過半数を満たせないので、リー
ジョン障害に
耐えられない。
4 つのうち
2 つしか
残らないため
NG
5 つのうち
2 つしか
残らないため
NG
障害
障害
Cloud OnAir

63.
Cloud OnAir
Cloud OnAir
スループット向上 (拡張性) のしくみ
- ノードの追加と自動シャーディング

64.
Cloud OnAir
Cloud Spanner の設定項目
インスタンス名 / ID
任意の名前を入力
構成
どこのリージョンに
インスタンスを
構築するかを選択
ノード数
必要なスループット性能に
応じてノード数を入力
必要な入力項目は
わずか 3 種類

65.
コンピュートとストレージの分離
Cloud OnAir
東京リージョン (asia-northeast1)
ゾーン a ゾーン b ゾーン c
Cloud Spanner
インスタンス
1 ノード
node1 node1 node1
分散ストレージ 分散ストレージ 分散ストレージ
コンピュート
ストレージ
コンピュート
ストレージ
コンピュートとストレージは切り離されており、
それぞれ独立して性能と可用性を担保。

66.
node1
ゾーン a ゾーン b ゾーン c
node2 node1 node2 node1 node2
2 ノード目追加
数秒で起動完了
Cloud Spanner
インスタンス
2 ノード
東京リージョン (asia-northeast1)
分散ストレージ 分散ストレージ分散ストレージ
コンピュート
ストレージ
66Cloud OnAir
ノード追加によるコンピュートの水平スケール
ノード追加とは、新たなコンテナの起動する。データ自体は分散ストレージ経由で共有されて
いるため、ノードの追加と削除は速やかに完了する。

67.
ノード数の数だけ処理能力が向上する
node1
ゾーン a ゾーン b ゾーン c
node2 node1 node2 node1 node2
Cloud Spanner
インスタンス
4 ノード
東京リージョン (asia-northeast1)
分散ストレージ 分散ストレージ分散ストレージ
node3 node4 node3 node4 node3 node4
ストレージ
コンピュート
Cloud Spanner 1 ノードの性能
読み込みでは最大 10,000 qps 書き込みでは2,000 qps を処理可能 (*)
(*)パフォーマンス値は推定値であり、ワークロード、スキーマ設計、データセットの特性によって大きく変わります。
参考：https://cloud.google.com/spanner/docs/instances?hl=ja#regional-performance

68.
コンピュートとストレージの分離
Cloud OnAir
東京リージョン (asia-northeast1)
ゾーン a ゾーン b ゾーン c
Cloud Spanner
インスタンス
1 ノード
node1 node1 node1
分散ストレージ 分散ストレージ 分散ストレージ
コンピュート
ストレージ
コンピュート
ストレージ
コンピュートとストレージは切り離されており、
それぞれ独立して性能と可用性を担保。

69.
ストレージのスケール (自動シャーディング)
ゾーン a
node1
分散ストレージ
69
● Cloud Spanner テーブルのデータは、内部で一定の単位で分割
○ 主キー (PK) のレンジで、自動的に分割
○ 分割単位を「スプリット」と呼ぶ
自動分割
テーブル
スプリット スプリット スプリット
Cloud OnAir

70.
ストレージのスケール (自動シャーディング)
ゾーン a
node1
分散ストレージ
70
スプリットは分散ストレージに保存されているため、
コンピュートノードが増えると担当するスプリットを変更することによって、
性能がスケールするようになっている。
自動分割
テーブル
スプリット スプリット スプリット
node2 node3
Cloud OnAir

71.
自在にスケール可能な Cloud Spanner
node1
分散ストレージ
71
このようにして Cloud Spanner は、1 ノードの小規模構成から、数百ノードもの
大規模構成まで、柔軟にスケールさせることが可能。
分散ストレージ内のスプリットは、データサイズや負荷状況に応じて分割や結合が行われる。
node2 Node X・・・
・・・
Cloud OnAir

72.
Cloud OnAir
Cloud OnAir
Cloud Spanner アップデート

73.
Cloud OnAir
主な新機能
● チェック制約のサポート
● Generated columns のサポート
● Numeric 型のサポート
● 最も古いアクティブなクエリ (ロングランニングクエリ) の監視をサポート
● Cloud Spanner エミュレータをサポート
● 統計情報を SQL で取得可能に
● バックアップとリストアをサポート
● 外部キー制約をサポート
詳細: https://cloud.google.com/spanner/docs/release-notes

74.
外部キー制約 (Foreign Keys) が 追加
特徴
● 外部キー制約が DDL で定義できるようになった
● 非キー列や複数テーブル間で外部キー制約を実現
○ 補足：これまでは Cloud Spanner のインターリーブ機能を
利用して、外部キー制約に似たことを実現していた
FEATURE
player_items
PK player_id STRING(32)
PK, FK item_id INT64
quantity INT64
items
PK item_id INT64
name STRING(255)
price INT64
Cloud OnAir

75.
マネージド バックアップ リストア
特徴
● インスタンス内の DB 単位で
バックアップ取得可能
● バックアップは、インスタンスに紐付いた専用領
域に保管され、最大 1 年間保持可能
● 同一インスタンス及び、同一リージョンの別の
インスタンスに対してリストア可能
● リストア時間は非常に高速
FEATURE
Cloud OnAir

76.
Cloud Spanner エミュレータ がリリース
特徴
● 任意の環境で動作可能なエミュレータを、バイナリ及びコンテナで提供
● 開発者のローカル環境はもちろん、CI / CD に組み込んでの利用も可能
● 開発コストの削減、開発効率の向上
エミュレータと実機との動作の違いに注意
● Cloud Spanner エミュレーターでは内部的なロックの取り方が異なるため、
トランザクションの競合をテストするような用途には向かない
● エラーメッセージの出方が異なる場合がある
$ gcloud beta emulators spanner start
Executing: docker run -p 127.0.0.1:9010:9010 -p 127.0.0.1:9020:9020 gcr.io/cloud-spanner-emulator/emulator:0.7.3
[cloud-spanner-emulator] 2020/04/19 14:15:10 gateway.go:135: Cloud Spanner emulator running.
[cloud-spanner-emulator] 2020/04/19 14:15:10 gateway.go:136: REST server listening at 0.0.0.0:9020
[cloud-spanner-emulator] 2020/04/19 14:15:10 gateway.go:137: gRPC server listening at 0.0.0.0:9010
$ gcloud spanner instances create emu-instance --config=emu-config --description="Dev Instance" --nodes=1
FEATURE

77.
Cloud OnAir
Cloud OnAir
まとめ

78.
Cloud OnAir
まとめ
● クラウド データベースを利用することで、不確実性の時代における
データベース運用の課題に対応
○ コスト、俊敏性・拡張性、可用性に関わる課題へのアプローチ
● マネージド サービスを活用し、データベース エンジニアの生産性を向上
○ Cloud SQL を利用して、高可用性、バックアップ、暗号化、
パッチ適用、容量増加などの作業を効率的に実施
○ Cloud Spanner を利用して、ダウンタイムのより
短いデータベース運用を実施