Professional Cloud Database Engineer
Professional Cloud Database Engineer
Professional Cloud Database Engineer という試験が ベータ版でリリースされた。
https://cloud.google.com/certification/guides/cloud-database-engineer?hl=ja
によれば
Professional Cloud Database Engineer ベータ版認定試験ガイド
Professional Cloud Database Engineer は、2 年以上の Google Cloud の経験、5 年以上のデータベースと IT に関する全般的な経験を持つデータベース プロフェッショナルです。Professional Cloud Database Engineer は、アプリケーションでデータの保存と取得に使用される Google Cloud データベースを設計、作成、管理、トラブルシューティングします。Professional Cloud Database Engineer には、ビジネス要件や技術要件をスケーラブルで費用効果の高いデータベース ソリューションに変換できる十分な知識が必要です。
とのことである。この記事では、Google Cloud Professional Cloud Database Engineer 試験の試験ガイドについて確認し、公式ドキュメントへのリンクを充実させ、注目ポイントについて記述したい。所謂「試験対策マニュアル」の一種である。
I'm certified as a Google Cloud Certified - Professional Cloud Database Engineer.
Series ID 27
2022-08-29 現在、Beta ではなく、試験が公開されている。
試験ガイド 2022-04-16
(Partially Updated at 2022-08-30)
セクション 1: スケーラブルで可用性の高いクラウド データベース ソリューションを設計する
1.1 関連する変数を分析して、データベースの容量と使用計画を実行します。次のような流れになります。
a. シナリオを考慮し、現在の環境ワークロードの指標と将来の要件に基づいてソリューションのサイズ設定を行う
b. さまざまなデータベース構成（マシンタイプ、HDD と SSD など）のパフォーマンスとコストのトレードオフを評価する
料金 https://cloud.google.com/sql/pricing?hl=ja
によれば、
アイオワ us-central1 HA でSSD ストレージ容量: 1 GB あたり \$0.340/月
HDD ストレージ容量: 1 GB あたり \$0.180/月
バックアップ容量: 1 GB あたり \$0.080/月（使用量）であり、100 GB で、SSD は3000円、HDD が約半分。HA でない状態にすると、両方その半分。バックアップは、HA でない、HDD の容量に対する料金と同程度。
料金計算ツール https://cloud.google.com/products/calculator?hl=ja
で、db-standard-1
Location: Iowa
SSD Storage: 100.0 GiB
JPY 16,290.75db-standard-1
Location: Iowa
HDD Storage: 100.0 GiB
JPY 14,325.39である。バックアップについては、「残存している最初のバックアップ」+「その他のバックアップの差分」を基にデータ量が計算されるため、期間等を調整してもあまり意味がない。
SSD ストレージと HDD ストレージのいずれかを選択する によれば、
そのインスタンスでの SSD ストレージまたは HDD ストレージの選択は変更できません。
のようにディスク種別の変更はできないので注意。
c. パフォーマンス要件に基づいてデータベースのコンピューティングとストレージのサイズを調整する
1 GB あたりの R/W IOPS はストレージ容量と、vCPU の個数の両方によって、小さい方の値で規定される。
簡単にまとめると、「1.5 TB くらいまでは、容量を増やせば増やすほど速度が上がる」「SSD は4倍速」である。料金は倍で4倍速なので、SSD がオトクである。
ディスクは https://cloud.google.com/compute/docs/disks/performance?hl=ja#type_comparison のリージョンPD の標準/SSD を見れば良い。
パフォーマンス要件を満たすようにディスクを構成する https://cloud.google.com/compute/docs/disks/performance?hl=ja#performance_factors も読んでおくと良い。オーバーヘッド等も踏まえて記載されている。
例えば、8 vCPU ではr-IOPS w-IOPS r-MBps w-MBps HDD 5,000 15,000 800 400 SSD 15,000 15,000 800 800 となる。この値は結構大きいので、参考程度で構わない。
HDDについて、容量あたりのパフォーマンスはsize(GB) r-IOPS w-IOPS r-MBps w-MBps 32 24 48 3 3 128 96 192 15 15 1,000 750 1500 120 120 5,000 3,750 7,500 600 400 SSDについて、容量当たりのパフォーマンスは
size(GB) r-IOPS w-IOPS r-MBps w-MBps 32 960 960 15 15 128 3,840 3,840 61 61 1,000 30,000 30,000 480 480 5,000 100,000 100,000 1,200 1,200 となっている。SSD は特に 読み込み IOPS に優れ、スループットは HDD の 4倍程度と考えると良い。SSD でも 500 GB くらいまでは、8vCPUの IOPS 上限に収まる。スループットは 1.6 TB くらいのサイズにするまでは上限に収まる。
1.2 要件に沿って、データベースの高可用性と障害復旧のオプションを評価します。次のような流れになります。
Cloud SQL データベースの障害復旧 と
Cloud SQL for PostgreSQL の障害復旧: 完全なフェイルオーバーとフォールバック プロセス を一読しておくと良い。a. マルチリージョン、リージョン、ゾーンのデータベース デプロイ戦略間のトレードオフを評価する
若干伝送遅延がある。Google Cloud Inter-region latency and throughput によれば、
us-east1 - us-central1 31 ms, us-east1 - us-west1 63 ms である。大陸横断100ms程度と思っていたら良い。asia-northeast1 - us-east1 は 153 ms である。
トレードオフという点で言うと、HA なしの価格Eを基準として、HA ありだと2E、別リージョンにリードレプリカを作ると3Eかかる。b. シナリオを考慮して、アプリケーションの可用性要件に基づいてメンテナンスの時間枠と通知を定義する
Cloud SQL インスタンスでのメンテナンスについて を読もう。いくつかポイントを抜き出しておく。- メンテナンス時間枠 メンテナンスの時間枠は1時間で、曜日と時間帯を指定する。
- 更新の順序 ステージング環境を先に、プロダクション環境を後に…といった使い方ができる。
Any、Earlier、Laterのいずれかで、LaterはEarlierの1週間後。 - メンテナンス拒否期間 繁忙期は「ちょっと待って！」ができる。最大90日…3か月はメンテナンスを拒否できる。
日曜午前 12 時～午前 1 時（米国東部時間）、更新の順序: Later、メンテナンス拒否期間: 11 月 1 日から 1 月 15 日。…といった具合である。クリスマスシーズンを避けることができる。
自動バックアップでは 4 時間 のバックアップ時間枠が使用されるが、時間を間違えないようにしよう。
c. Google Cloud のマネージド データベースのデータベース アップグレードを計画する
どこを参照すれば良いのか分からない…
データを移行してデータベースのメジャー バージョンをアップグレードする これが MySQL, あと PostgreSQL, SQL Server追加: 上記にはないのだが、データ保存について、の地理的要件がある場合も考えておきたい。例えば、「地域外にデータ保存をしてはいけない」といった場合がある。
データ所在地の概要- データの保存: データの保存場所を構成します。… バックアップを含め、データの保存場所を構成できる
- データの暗号化: 暗号鍵の保存場所を制御します。 …顧客管理の暗号鍵（CMEK） が使える
- データへのアクセス: データへのアクセス権を制御します。…アクセスできるユーザーを制御できる。
VPC Service Controls についても大まかな概要は把握しておきたい。
VPC Service Controls では、Cloud SQL Admin API または Cloud Storage API を使用して、Cloud SQL API によるデータのインポートとエクスポートを制限できます。この制限により、選択したネットワーク内の場所にデータが確実に保存されるようになります。VPC Service Controls を使用して、サービスにアクセスできる仮想境界を定義するサービス境界を作成します。これにより、データが境界外に移動されることを防ぎます。Google Cloud IAM ポリシーに従ってユーザーが承認されている場合でも、この制約を適用できます。
1.3 アプリケーションがデータベースに接続する方法を決定します。次のような流れになります。
a. スケーラブルで可用性に優れた、安全なデータベースを設計する
スケーラブルという視点で、Cloud SQL では足りないことがある。スループットを稼ぐ必要があるとき、世界規模で利用されるが、同期も必要になるとき、データ容量がとにかく多いとき…である。
アプリで利用し、オフラインになる可能性がある場合は、Firestore を使う。IoT 系や、データをとにかく保存するときは Bigtable を検討する。大規模ならSpanner。
Cloud SQL は行志向で、それ以外は列志向 DB である。
1.4.b も併せて理解しておく。b. ネットワークとセキュリティ（Cloud SQL Auth Proxy、CMEK、SSL 証明書）を構成する
Cloud SQL Auth Proxy について を読んでおく。
単純には、ローカルの好きなポート（例: 3306）から、Cloud SQL に通信できるトンネルを作成できると考えれば良い。コネクション プールは使えない。c. セッション プーラー サービスの使用を正当化する
データベース接続を管理する を流し読みする。
HAProxy を使用した Cloud SQL for PostgreSQL での読み取り専用ワークロードのスケーリングやオンプレミスの PostgreSQL クラスタを Google Cloud に移行するにあるように、PostgreSQL では PgBouncer というセッションプーラーを上手に使うと、水平スケールや、ダウンタイム縮小が可能である。d. マネージド サービスの監査ポリシーを評価する
監査ログ これ？
1.4 Google Cloud で適切なデータベース ソリューションを評価します。次のような流れになります。
a. マネージド データベース サービスと非マネージド データベース サービスの違い（セルフマネージド、ベアメタル、Google マネージド データベース、パートナー データベース サービス）
- セルフマネージド: 全部自分でやる
- ベアメタル: Bare Metal Solution を計画する を読もう。
- Google マネージド データベース: Cloud SQL, Spanner, Firestore, Bigtable, BigQuery, etc. これらはすべて Google Managed である。
- パートナー データベース サービス: Oracle, RDS on AWS 等のことだろう。
特に、Bare Metal の意義については分かっておこう。特に、Oracle のデータベースを動かす用途で語られる。
Bare Metal Solution は、専用の HPE または Atos ベアメタル サーバーをリージョンごとに拡張して提供するマネージド ソリューションです。低レイテンシのネットワーク ファブリックを使用した高パフォーマンスのマネージド接続を通じて Google Cloud に接続されます。
Google Cloud によって管理されるネットワークには、お客様の Bare Metal Solution 環境への低レイテンシの Cloud Interconnect 接続が含まれます。
Bare Metal Solution は、お客様所有ライセンスの使用（BYOL）モデルを使用
Oracle データベース ファイルに使用するボリュームのスナップショットを作成することは推奨しません。代わりに、リカバリ ポイント目標（RPO）を満たすため、RMAN などのツールや Actifio などのソリューションを使用して、Oracle データベースの適切なバックアップを作成します。b. SQL と NoSQL のビジネス要件（構造化、半構造化、非構造化）を区別する
Google Cloud のデータベース オプションについての説明 を一読しよう。
RDBMS は、普通は Cloud SQL で、ゲームや世界規模の商取引は Spanner を、どうしても Oracle なら Bare Metal を使う。
NoSQL として、Document (JSON, XML) 中心になりそうなら、Firestore がよい。モバイルアプリ・Web アプリのバックエンドとして「オフラインでも読める」という要件が必要な場合も オフライン データの有効化 とともに、Firestore を使うのが良い。
IoT やとにかく大容量の Key-value store が必要なら、Bigtable を利用する。Bigtable はミリ秒未満のレイテンシで高スループット、(3つ以上のリージョンでは) 99.999% の SLA …とまさに強い。他の所に書いたほうが良いが、ms オーダーの低レイテンシが要求される場合、Memory Store をキャッシュに用いることがある。
余裕があれば、それそれのプロダクトの「主な機能」を読んでおこう。
BigQuery は 99.99% の SLA である。データ分析に向いているので、Spanner から や、他の Cloud SQL からも change data capture (CDC) で転送 することがある。
c. Google Cloud でデータベース ソリューションを実行するコストを分析する（比較分析）
他のプロダクトと同じで「使った分だけ」なのは大きな利点。
d. アプリケーションとデータベースの依存関係を評価する
普通のネットワークと同様な、IP での接続であれば、アプリ改修は不要。それ以外はライブラリの利用が必要なことがある。
Oracle -> Postgres であれば、差分が小さいこともあるが、DB サーバのソフトウェアを変えると、アプリ側のSQLに変更が必要なこともあるので注意する。おまけ: 分散型DBでは、主キーの設計が大事である。Spanner なら UUID か、どうしても連番っぽくしたいのであれば、ビット反転 と併用する手はある。
セクション 2: 複数のデータベース ソリューションにまたがるソリューションを管理する
2.1 データベースの接続とアクセス管理に関する考慮事項を決定します。次のような流れになります。
a. データベースの接続とアクセス制御に関する Identity and Access Management（IAM）ポリシーを決定する
Cloud SQL のロール
roles/cloudsql.clientは、GAE, Auth Proxy 用。roles/cloudsql.instanceUserは人間用…多分。roles/cloudsql.viewerというのもある。Spanner はIAM を使用したアクセス制御
roles/spanner.viewerは「データは読めない」、roles/spanner.databaseUserでデータの読み書きができる。b. データベース ユーザーを管理する（認証、アクセスなど）
上記をもとに考える。
2.2 データベースのモニタリングとトラブルシューティングのオプションを構成します。次のような流れになります。
a. 低速なクエリとデータベースのロックを評価し、不足しているインデックスを特定する
PostgreSQL ではQuery Insights ダッシュボードが使える。sqlcommenter で、アプリのORMと連携しよう。(MySQL, SQL Server には類似機能がない)
2022-04 の記事 で、MySQL の Query Insights がプレビュー版として公開されていることは記載されている。b. データベースの指標（RAM、CPU ストレージ、I/O、Cloud Logging）をモニタリングして調査する
c. 割り当てをモニタリングして更新する
Cloud SQL はストレージの自動増加もできる。マネージドサービスによっては、普段の利用では容量の心配が不要なものもある。
d. データベース リソースの競合を調査する
同じキーへの書き込み競合や、分散システムでは特定ノードへのアクセス集中のことだろうか。
e. エラーとパフォーマンス指標に関するアラートを設定する
Spanner は Key Visualizer で、キーの状況が見られる。Key Visualizer で大規模な Cloud Spanner パフォーマンス指標を把握する
2.3 データベースのバックアップと復元のソリューションを設計します。次のような流れになります。
a. SLA と SLO を考慮して、バックアップと復元のオプション（自動バックアップ）を推奨します。
b. データベースのエクスポート データとインポート データを構成する
SLA によっては、バックアップを別リージョンに置くか、read replica の作成が必要だろう。
バックアップのリージョンは設定可能で、インスタンスと別の場所にすることも可能である。c. 目標復旧時間（RTO）と目標復旧時点（RPO）を設計する
RPO が1日未満の場合、「日時バックアップ」ではもちろん対応できない。したがって、PITR (Point in time recovery) を有効にしておく必要がある。MySQL では binlog, PostgreSQL では WAL (write-ahead logs) が利用される。
Spanner については Cloud Spanner がポイントインタイム リカバリ機能への対応を開始 を読んでおく。
マイクロ秒という細かい時間単位で復元できる
全バージョンのデータやスキーマを 1 時間～7 日間保持でき
データベースの特定部分だけを復元するかを選択できまた、タイムスタンプの範囲 を指定した、ある程度の stale を許容した読み取りや、過去データの読み取りも簡単に行える。Spanner すごい。
RTO が短い場合、「バックアップからリストア」では間に合わない。
リージョン障害に素早く対応したい場合、HA だけでは無理である。Read replica を別リージョンに設置すると、1時間未満の RTO にも対応できる。RPO もほぼゼロを達成できる。後述の「データベースにマルチリージョンのレプリケーションを設定する」を読もう。
2.4 Google Cloud でデータベースのコストとパフォーマンスを最適化します。次のような流れになります。
a. スケールアップとスケールアウトのオプションを評価します。
スケールアップは、1台なら1台のまま、CPUやメモリを増設することを指す。スケールアウトは、複数台に分散することを指す。
Cloud SQL の場合、「書き込み」も分散することはできない。分散させたい場合、水平・垂直分割によるシャーディングを行う必要がある。
「読み込み」の分散は 1.3.c も参考になると思う。
SpannerやNoSQLのプロダクトによっては、小規模のアプリケーション側の工夫で、スケールアウトに対応した設計が達成できる。Firestore のネイティブ モードでは、ドキュメントの更新オペレーションを、1 秒あたり最大 10,000 件の書き込みと 100 万を超える接続までスケールできます。アプリがこの書き込みレート制限を超える場合は、1 秒あたり数百万の書き込みまでスケールアップできる Datastore モードを使用することをおすすめします。これらのモードの違いについては、ネイティブ モードと Datastore モードからの選択をご覧ください。
日中に生成されるトラフィック パターンが安定している（オンライン ショッピング サービスなど）
有機的成長が期待される新しいアプリケーション
Bigtable を初めて使用するワークロードb. 現在と将来のワークロードに基づいてデータベース インスタンスをスケーリングする
Cloud Spanner には Autoscaler という Google が作成したオープンソースツールが存在する。Cloud Spanner の自動スケーリング の3つのグラフは見ておくと良い。stepwise, linear, direct の3種類でスケーリングが可能である。
また、次の条件に当てはまるワークロードを持つユーザーも対象としています。
- ユーザーの需要が定期的に変動している。
- コンピューティング リソースやストレージの必要量が時間の経過とともに増加すると予測される。
c. レプリケーション戦略を定義する
Cloud SQL でのレプリケーションについて は一読しておきたい。スケーラブル+可用性という点では、Read Replica だろう。Database Migration Service の存在については頭においておく。
Cloud SQL は- リードレプリカ: 読み込み専用のインスタンスを追加できる。HA で用いている2ゾーンと別ゾーンが良い。
- クロスリージョン リードレプリカ: 読み込み専用のインスタンスを「別リージョンに」追加できる
- 外部リードレプリカ: Cloud SQL プライマリ インスタンスを複製する外部（on-premises 等）のインスタンス
- 外部サーバーから複製する場合の Cloud SQL レプリカ: 外部サーバの(リード)レプリカとして、Cloud SQL を構成できる
Firestore は自動である。
自動マルチリージョン レプリケーションと強整合性により、障害が発生した場合でも、データの安全性と 99.999% の可用性が保証されます。
Bigtable は Cloud Bigtable の規模 に
1 つのクラスタ内で強整合性があり、クラスタ間のレプリケーションにより結果整合性が追加される
とあるように、複数クラスタのレプリケーションが可能である。Zonal で 99.99% で、3リージョン以上にすると 99.999% をSLAで保証する。
d. データベース ソリューションの実行費用を継続的に評価して最適化する
2.5 データベース タスクを自動化するソリューションを決定します。 次のような流れになります。
a. データベースのメンテナンスを実行する
b. テーブルの断片化を評価する
MySQL であれば、Optimize table や Analyze table があるが…PostgreSQLであれば、vacuum と REINDEX だろうか。
分散DBであれば、むしろUUIDによって分散しているほうが良い。c. データベースのエクスポートをスケジュール設定する
Cloud Scheduler で Cloud SQL データベースのエクスポートをスケジューリングする これを読め。
Cloud Storeage に入れておけば基本は良いだろう。
セクション 3: データ ソリューションを移行する
3.1 データの移行とレプリケーションを設計、実装します。次のような流れになります。
a. ダウンタイムなし、ほぼダウンタイムなし、長時間の停止、フォールバック計画などの移行戦略と計画を策定し、実施する
ダウンタイムほぼなしのうち、短い選択肢は、ストレージ共有型のHA構成である。プライマリ障害時は、
failoverする。ただし、移行には使えないだろう。
ダウンタイムを削減するには、ストリーミング レプリケーションを行う。これは、- バックアップの転送
- それ以後の差分の転送・適用
を行うものである。データ量・ワークロードにも依るが…初期転送には時間がかかるため、遅れが生じているものの、段々とレプリカが追いつく。「その遅れ」程度の時間と、移行に伴う作業の停止時間で移行ができる。
帯域幅に余裕がある状態であれば、DBサーバへの外からの接続を停止した後、ダンプを取得し、転送、インスタンス作成…とフルバックアップからの構成を行うことで移行ができる。DBアプリケーションのバージョンによってはこの選択肢を選ぶしかないこともある。
フォールバック計画は、「うまく移行できなかったときにどうするか」である。
b. Google Cloud から移行元へのリバース レプリケーション
アプリケーションがまだ on-premises で動いているときなどには必要。前もってレプリケーションの準備を行っておかないと、転送に時間がかかって間に合わない。
c. フォールバック計画やスキーマ変換などを含めて、データベースの移行を計画し、実行する
d. 特定のシナリオに適したデータベース移行ツールを特定する
Database Migration Service はメジャーバージョンアップにも利用できる。pglogical および Database Migration Service で Postgres をアップグレードする, Database Migration Service を使用して MySQL メジャー バージョンをアップグレード
a. で考えたような、戦略・計画もシナリオのひとつである。追加: Database Migration Service についてはきちんと把握しておくべきである。
例えば、PostgreSQL の場合、使用可能な要件がある。
- pglogical が入っている
- primary key が設定されている
ことである。
Database Migration Service による PostgreSQL の移行 は「料金」の手前まで読んでおくと良い。MySQL については Configure your source を見ると、重要な所では
- Dump 時に DDL 変更が走っていない(change data capture (CDC) phase はOK)