並列レプリケーション フラグ

• レプリケーションを並列適用することでスループットが向上し、遅延を抑える。
• リードレプリカ側で設定する。途中から有効にする場合は一度レプリケーションをオフにしてからフラグを設定し再度有効化する。

フェイルオーバーレプリカへの一部の操作が失敗する → レプリケーションラグの可能性

PgBouncer : OSSのコネクションプーラー

コネクションプーリング

アプリケーションがデータベースとのコネクションをキャッシュすることで、DB とのコネクションハンドシェイクをスキップでき、アプリケーションのパフォーマンスを向上させることができる。データベース側にとってもコネクションを大量に維持しなくてよくなりメモリの使用を抑えることができる。

https://rtam.xyz/articles/2021/08/lambda-connection-pooling/

CloudSQL Auth Proxy

• インターネット公開することなく内部IPでDB接続が可能。
  • 外部公開しないのでIP ホワイトリストを必要としない。
• DBのSSL有効化は必須ではない。

クエリ インサイト

クエリのパフォーマンスとリソース消費を可視化する機能。

gcloud sql operations listコマンド

• バックアップを含む CloudSQL インスタンスで実行されたすべての操作を一覧表示するツール。
• ステータス、開始時刻と終了時刻などのメタデータを確認可能なため、手動バックアップの現在の状態と進行状況を判断などに利用可能。

レプリケーションラグ

• プライマリインスタンスからレプリケートされる時間を示す。
• 復旧の際にデータ損失の可能性を判断するのに有用。
• Cloud Monitoringのメトリクスで確認可能。
  • 遅れている秒数/バイト数(ポスグレのみ)/プライマリにコミットしてからWAL receiverで受け取るまでの秒数

原因

• プライマリ インスタンスが、レプリカに変更を十分な速さで送信できない。
  • network_lagメトリクスで確認可能。
• レプリカが変更を十分な速さで受信できない。
  • network_lagメトリクスで確認可能。
• レプリカが変更を十分な速さで適用できない。
  • replica_lagメトリクスで確認可能。

mysql.slave_master_info

• MySQL のこのテーブルには、レプリケーション構成に関する情報が含まれる。
• スタンバイレプリカを昇格しフェイルオーバーする前に、レプリケーションの状態を確認することでデータ損失の可能性を判断できる。

同じリージョン内のゾーン間
→ 同期 レプリケーションを設定できゾーン障害が発生してもデータ損失が発生しない
→ 同期レプリケーションは長距離ではパフォーマンスに影響を与えうるため、異なるリージョン間では 非同期 レプリケーションを利用することが推奨。

クエリ操作のレイテンシを 1 ミリ秒未満に抑えたい → Memorystoreでキャッシュする

gcloud sql instance patchコマンドで既存インスタンスに設定変更可能。
→ フェイルオーバーレプリカの有効化、vCPU追加など

CSVファイルとしてGCSへ定期的にエクスポートする → Cloud Composerでcloudsql.instances.export APIの利用

IOが遅いなどでストレージ タイプ(HDD、SSD)を変更したいとき、直接更新はできない。
→ 新規にインスタンスを構築し、データを移行する。

https://cloud.google.com/sql/docs/mysql/choosing-ssd-hdd?hl=ja

リードレプリカの昇格は手動。-> RTOが小さい用件では難しい

Cloud SQL インスタンスの高可用性 (HA) を有効にすると、データベースが異なるリージョン間で動作することが保証され、リージョンの停止が発生した場合にフェイルオーバー メカニズムが提供される。

→

短い RTO (Recovery Time Objective) が求められる場合に HA 構成が有用である

https://blog.g-gen.co.jp/entry/professional-cloud-database-engineer

HA 構成が同期レプリケーションであるのに対し、 リードレプリカは非同期レプリケーション

レプリケーションの仕組み

Cloud SQL リードレプリカは、PostgreSQL ストリーミング レプリケーションを使用します。変更は、プライマリ インスタンスの先行書き込みログ（WAL）に書き込まれます。WAL sender がレプリカの WAL receiver に WAL を送信し、そこで適用されます。

https://cloud.google.com/sql/docs/postgres/replication/replication-lag?hl=ja#metrics

Serverless Export

• 大規模なデータベースの 1 回限りのエクスポートを作成する場合に推奨。
  • エクスポートされるデータ量が少ない場合はリードレプリカからエクスポートを取得でOK。
• エクスポート オペレーションをオフロードするために、個別の一時的なインスタンスが Cloud SQL によって作成されプライマリインスタンスに負荷をかけない。

圧縮

Cloud SQL では、圧縮ファイルと非圧縮ファイルの両方のインポートとエクスポートがサポートされています

https://cloud.google.com/sql/docs/mysql/import-export?hl=ja#serverless

Query Insights

高負荷の SQL やその実行計画を確認できる。
インフラコストやサイズの適正などの視点ではない→レコメンダー使う

また Sqlcommenter というオープンソースライブラリを使うことでアプリケーション側で ORM を使っている場合でも SQL の特定に役立ちます。

https://blog.g-gen.co.jp/entry/professional-cloud-database-engineer

ORM → Djangoのモデルとかあれ

メンテナンスウィンドウ

最大 90 日間のメンテナンス拒否期間を設定可能
1時間枠で設定を行う

ポスグレのオンラインバックアップ→ Oracle同様アーカイブログ、RMAN

HA構成

Cloud SQL で HA 構成を有効化することで、プライマリとスタンバイという2台のデータベースを利用した冗長構成を簡単に組むことができます。そのため、本番環境の可用性を確保するためには HA 構成がオススメです。 HA 構成を利用することで、 Cloud SQL の SLA （稼働率99.95%）が適用されるため、安心してサービスを運用できます。

99.95%のSLA

仕組み

書き込みを行なう場合は IP アドレスを通じてプライマリ DB に書き込みがなされます。このとき、裏側でリージョン永続ディスクというものが利用されており、このリージョン永続ディスクに対してプライマリ DB が書き込みを行います。リージョン永続ディスクは2つのゾーンにまたがって同期のレプリケーションで書き込みを行っており、これによってデータの堅牢性を高めています。

https://www.topgate.co.jp/blog/google-service/16078

マルチリージョンレプリケーション選択可能

Firestore Data Bundlesを活用すると、CDNを通してFirestoreからの読み取りをBundleという形式で配信する

https://zenn.dev/moga/articles/firestore-data-bundles

Datastore モード

大規模なコレクション全体にわたる強力な一貫性と高いトランザクションスループットを必要とするアプリケーション向けにカスタマイズされている。

もしくは、オンプレのワークロードを全く変更せずにクラウド移行する段階でも可能な選択肢。

マルチクラスター ルーティング
→ 複数のクラスタにルーティングさせることで耐障害性を高める手法。

https://christina04.hatenablog.com/entry/bigtable-app-profiles

Bigtable Key Visualizer

• Bigtableの行キー全体のWrite/Read操作のパターンと量を視覚化する。
• ホットスポットやその他の異常を検出するのに役立つツール。

低レイテンシでのRead → SSDを選択

CPU使用率は35%が推奨

マネージドサービスへの移行が対象。GCEへの移行とかはPgBouncer

現在、Database Migration Service は MariaDB と互換性がありません。

https://cloud.google.com/database-migration/docs/mysql/known-limitations

ソース

MySQL ソース
Oracle ソース
PostgreSQL ソース（AlloyDB for PostgreSQL を含む）
SQL Server ソース

宛先

-BigQuery

• GCS
• CloudSQL
• Spanner
• Dataflow
• Data Fusion

https://cloud.google.com/datastream/docs/faq?hl=ja

設定でallow_commit_timestamp = trueとすることでPITRが利用できる。

ホットスポットの回避方法

• UUID
• ビット反転 → 主キーの分散シーケンスの作成が容易になる。

リードレプリカが必要な RPO に準拠しているかの監視 ← レプリケーション監視ツールの使用。
※ 一般のモニタリング サービスでは無理

roles/spanner.databaseReader ※ roles/spanner.reader ではない

Cloud Spanner インポート ユーティリティ

データベースへのデータのロードのためのツール

特定のテーブルへのReadOnly権限を実現する場合、
spanner.database.readSessions.create 権限を有効にし特定のテーブルへの読み取り専用アクセスを許可する。

バックアップ コピーの数

• Cloud Spanner バックアップに関連するコストを最も直接的に削減する方法。
• 管理対象のバックアップ コピーの数を減らすことでストレージ要件が直接削減される
• 運用機能に比較的大きな影響を与えずにコスト効率を確保できる。

CMEK対応

クエリタグ

• トランザクションタグ
• リクエストタグ

→ タグごとのメトリクス集計(クエリの平均速度)やコスト算出に利用できる。
→ 複数のアプリケーションが混在する環境でどのアプリケーションのクエリが負荷が高いかなどのパフォーマンス解析に有用

https://zenn.dev/google_cloud_jp/articles/756f47aa39b2b6

処理ユニット( Processing Unit )
→ 1 つの処理ユニットは、読み取りと書き込みの両方のスループットとコンピューティング容量を提供

DynamoのRCU、WCUみたいなもの？

Query Insights

SQL クエリの監視を容易にし、サービス パフォーマンスに影響を与える可能性のある長時間実行クエリに関する分析情報を提供

2000回の読み取り操作/1sec に対応。

DB移行する際、移行元のDBに主キーが含まれ、移行後にレコードの一意性を維持できることを確認しておくこと。

gcloud spanner instance failoverコマンドでプライマリインスタンス名を引数に指定し、フェイルオーバーをテストできる。

JSONなど半構造化データもいける！