設計の判断
可用性と災害復旧
DR の構成は、許容できる停止時間 (RTO) と失ってよいデータの時間幅 (RPO) から逆算して選びます。どちらも短いほど、待機側で動かしておくものが増え、費用が上がります。
災害復旧 (DR) の設計は、サービスの名前ではなく RTO と RPO の数字から始めます。RTO が数時間でよければバックアップから作り直すコールド、数十分ならデータだけ同期しておくウォーム、数分以内なら両方で動かし続けるホットを選びます。SLA、SLO、稼働率の計算は 可用性と冗長化 で扱いました。
RTO と RPO は技術者だけでは決められません。「注文が 1 時間止まったら売上をいくら失うか」「直近 5 分の注文が消えたら誰が困るか」を事業側と話して数字にします。
守る障害の範囲で、複製の方法が変わる
ゾーン障害への備えは、多くのマネージドサービスで設定 1 つで済みます。Cloud SQL の HA 構成なら費用はスタンドアロンの約 2 倍です。リージョン障害への備えは、データの複製、接続先の切り替え、手順の訓練まで要ります。要件に「リージョン障害」と書かれていなければ、まずマルチゾーン構成で足りるかを考えます。ゾーンとリージョンの関係は リージョン・ゾーンと可用性 で読んでください。
RTO と RPO から DR パターンを選ぶ
3 つのパターンは Google Cloud の DR 計画ガイドの分類です。ガイドは RTO と RPO を数値で示していないので、図の目安はこのカリキュラムでの読み替えです。
選ぶ順序は次のとおりです。
- RPO から複製の方法を決める。数時間の欠損を許せるならバックアップ、数分ならレプリケーション、0 に近いなら同期レプリケーションか Spanner。
- RTO から待機側で動かすものを決める。作り直す時間を待てるならコールド、データベースの昇格で済ませるならウォーム、切り替えの操作をなくすならホット。
- 厳しいほうに合わせる。RPO 5 分で RTO 4 時間なら、データは複製してアプリは障害時に作るウォームです。
- 費用を見積もって事業側に返す。合わなければ RTO と RPO を緩められないか交渉する。
1 つのシステムの中でも、部品ごとにパターンを変えてかまいません。DR 計画ガイドの例では、過去のコンプライアンス用データはコールド、顧客向けのオンラインサービスはホットです。
データベースごとの複製の仕組み
| サービス | ゾーン障害への備え | リージョン障害への備え |
|---|---|---|
| Cloud SQL | HA 構成。2 ゾーンに同期で書き込み、障害時は約 60 秒で切り替わる | 別リージョンのリードレプリカを昇格する。非同期なので RPO は 0 にならない |
| AlloyDB for PostgreSQL | リージョン内の HA 構成 | 別リージョンのセカンダリ クラスタを昇格する。非同期 |
| Spanner | リージョン構成で SLA 99.99% | デュアルリージョン、マルチリージョン構成で SLA 99.999%。リージョン間も強整合 |
| Firestore | リージョン構成で SLA 99.99% | マルチリージョン構成で SLA 99.999%。作成後にロケーションは変えられない |
| Bigtable | 別ゾーンにクラスタを追加 | 別リージョンにクラスタを追加。クラスタ間は結果整合 |
| Cloud Storage | リージョンのバケットでも複数ゾーンに冗長化 | デュアルリージョン、マルチリージョン。既定の複製は RPO 12 時間、ターボ レプリケーション (デュアルリージョンのみ) は RPO 15 分 |
| Compute Engine のディスク | リージョン永続ディスク、Hyperdisk Balanced High Availability で 2 ゾーンに同期複製 | 非同期レプリケーションで別リージョンへ。目標 RPO は 1 分 |
Cloud SQL の HA の待機側は読み取りに使えないので、読み取りを分散するならリードレプリカを別に作ります。Enterprise Plus エディションでは、別リージョンの DR レプリカとデータを失わずに役割を入れ替えるスイッチオーバーと、接続先を自動で切り替える書き込みエンドポイントが使えます (Cloud SQL の DR)。
RPO が 0 に近く、しかもリージョン障害に備える要件では、非同期の Cloud SQL と AlloyDB では足りません。Spanner のマルチリージョン構成を候補にします。
バックアップはレプリケーションとは別に持つ
レプリケーションは、誤って消した行もランサムウェアで暗号化されたデータも、そのまま待機側へ写します。過去の時点に戻すにはバックアップが別に要ります。
Backup and DR Service は、Compute Engine、Filestore、Cloud SQL、AlloyDB、VM 上の Oracle や SQL Server などのバックアップをポリシーでまとめて管理します。バックアップ ボールトに設定した保持期間 (最長 99 年) が過ぎるまで、管理者でも削除できません。Cloud SQL 単体なら、自動バックアップとポイントインタイム リカバリ (PITR) で障害の直前の時刻に戻せます。HA 構成ではこの 2 つの有効化が前提条件です。
試してみる
コールドパターンの最小形として、ディスクのスナップショットを別のゾーンで復元します。
gcloud config set compute/region asia-northeast1
# 10 GB のディスクを作り、スナップショットを取る
gcloud compute disks create dojo-dr-disk --size=10GB --zone=asia-northeast1-a
gcloud compute snapshots create dojo-dr-snap \
--source-disk=dojo-dr-disk --source-disk-zone=asia-northeast1-a
# スナップショットの保存場所 (storageLocations) を確認する
gcloud compute snapshots describe dojo-dr-snap --format="value(storageLocations)"
# 別のゾーンでディスクを復元する
gcloud compute disks create dojo-dr-restored \
--source-snapshot=dojo-dr-snap --zone=asia-northeast1-b
gcloud compute disks list --filter="name~dojo-dr"スナップショットはリージョンかマルチリージョンに保存されます。マルチリージョンなら、リージョン障害のときも別のリージョンで復元できます。RPO は最後にスナップショットを取った時刻で決まります。
後片付けをします。
gcloud compute disks delete dojo-dr-disk --zone=asia-northeast1-a --quiet
gcloud compute disks delete dojo-dr-restored --zone=asia-northeast1-b --quiet
gcloud compute snapshots delete dojo-dr-snap --quiet試験で問われる判断
以下は、このカリキュラムで作った例です。
「社内の経費精算システム。翌営業日までに復旧すればよく、前日分のデータまでは失ってよい」。日次のバックアップを別リージョンに置くコールドです。待機系を常時動かす選択肢は費用が過剰です。
「決済の記録。リージョンが停止しても 1 件も失わず、数分で再開する」。Cloud SQL のクロスリージョン レプリカは非同期なので外し、Spanner のマルチリージョン構成と、複数リージョンのバックエンドを持つグローバル ロードバランサを選びます。
「Cloud SQL をゾーン障害でも自動で切り替えたい」。HA 構成です。別リージョンのリードレプリカはリージョン障害への備えで、昇格に手動の操作が要ります。
「管理者のアカウントが乗っ取られても、バックアップを削除されないようにしたい」。Backup and DR Service のバックアップ ボールトに保持期間を設定します。レプリカを増やしても削除は複製されます。
次のページでは、オンプレミスや他クラウドのシステムを Google Cloud へ移す計画を立てます。