ビジネスの継続性を確保し、データ損失を最小限に抑えるには、高可用性（HA）と障害復旧（DR）が AlloyDB Omni の重要なデータ保護戦略となります。HA は、データベースの可用性を維持し、目標復旧時間（RTO）を最小化することに重点を置きます、一方、DR は、壊滅的なイベントからの復旧と目標復旧時点（RPO）を最小化することに重点を置きます。
RTO と RPO はビジネス要件に沿って決定され、次のように定義されます。
- RTO は、収益や生産性の損失など、ビジネスに許容できない影響が生じるまでに、データベースが停止または使用不能になる可能性がある最大時間です。
- RPO は、ビジネス要件に影響しない範囲で、ビジネスで発生する可能性のあるデータ損失の最大量です。たとえば、完全な監査証跡を必要とするインベントリ システムでは、データ損失をゼロにする必要がある場合があります。
AlloyDB Omni には、次の可用性リファレンス アーキテクチャが用意されています。下に行くほど可用性レベルが高くなります。
- Standard Availability: バックアップを使用してデータを保護します。
- Enhanced Availability: リージョン内のゾーン レプリケーション（HA）を使用してデータを保護します。
- Premium Availability: ゾーン レプリケーションとリージョン レプリケーション（HA と DR）を使用してデータを保護します。
可用性メカニズム
可用性を確保する主なメカニズムは次のとおりです。
- データベースのバックアップ
- データベース レプリケーション
データベースのバックアップ
データベースのバックアップは、データ保護の基本的な側面であり、データベース データファイルの物理コピーを作成します。フル、増分、差分といった異なる種類のバックアップは、目標復旧時点（RPO）、バックアップのサイズと期間、そして復元にかかる時間の間で、それぞれ異なるバランスを提供します。
効率的な復元が行われる状態を確保し、システム障害が発生した場合のデータ損失を最小限に抑えるには、堅牢なバックアップ戦略の対象にデータベースと write-ahead log（WAL）ファイルの両方のバックアップが含まれている必要があります。データファイルの定期的な（通常は毎日）バックアップは非常に重要です。また、データベースの変更を記録する WAL ファイルもバックアップする必要があります。WAL ファイルは、ポイントインタイム リカバリや、復元時のデータの整合性を維持するために不可欠です。
データベース レプリケーション
PostgreSQL は、信頼性を高めるためにレプリカ サーバーを備えています。これらのレプリカは、アプリケーション接続を受け入れないウォーム スタンバイ、または読み取り専用モードで動作するホット スタンバイのいずれかに分類されます。プライマリ データベースの変更はレプリカに継続的に適用されるため、レプリカのデータは最新の状態に保たれます。プライマリ データベースで障害が発生すると、レプリカはプライマリ ステータスにプロモートされ、プライマリ データベースの役割を引き継ぎます。
データベース レプリカは、プライマリ インスタンスと同じゾーンまたはデータセンター、別のゾーン、別のリージョン、またはこれらのロケーションの組み合わせに配置できます。レプリカがプライマリ データベースから離れた場所に配置されているほど、レプリカを最新の状態に保つために変更を送信する際のレイテンシが増大します。離れたロケーション間のデプロイの場合は、リージョン障害などの大規模な障害の影響を軽減するために、通常、データ レプリケーションは非同期で行われます。このアプローチにより、このような設定で発生する可能性のあるパフォーマンスの低下を回避できます。
高可用性デプロイでは、通常、レプリカはプライマリ データベースの近くにデプロイされます。たとえば、同じデータセンター内の異なるゾーンにデプロイされたレプリカは、RTO が低く、RPO がほぼゼロになります。一方、障害復旧構成では、サービス停止に対して必要とされる保護レベルに応じて、レプリカは個別のデータセンターまたはリージョンにデプロイされます。このアプローチでは、RPO が高くなり（レプリケーションが非同期になる可能性があるため）、RTO が変動します。
次のテーブルに、AlloyDB Omni の可用性リファレンス アーキテクチャで使用されるメカニズムの概要を示します。
| 機能 | Standard | エンハンスト | プレミアム |
|---|---|---|---|
| バックアップ | ✔ | ✔ | ✔ |
| ゾーンレプリカ | ❌ | ✔ | ✔ |
| クロスゾーン レプリカ | ❌ | ✔ | ✔ |
| リージョン レプリカ | ❌ | ❌ | ✔ |
表 1. サポートされている AlloyDB Omni の可用性メカニズム
データベースの障害と復元のシナリオ
データベースの障害は、次のレベルで発生する可能性があります。
- インスタンス（ノードまたはサーバー）の障害: データベース自体に障害が発生します。
- サーバーの障害: データベースをホストするサーバーで障害が発生します。
- ゾーンの障害: サーバーをホストするデータセンター全体で障害が発生します。
- リージョンの障害: 複数のデータセンター（アベイラビリティ ゾーン）を含むリージョン全体が（洪水や大規模地震などにより）使用できなくなります。
イベントの数が少ない場合、障害の可能性とリスクは減少しますが、イベントの防止に必要な費用は増加します。企業はリスク許容度を判断し、潜在的な中断を受け入れるか、リスクを最小限に抑えるために復元力の高いアーキテクチャに投資するかを選択する必要があります。
次のテーブルに、AlloyDB Omni リファレンス アーキテクチャでサポートされている復元シナリオを示します。
| 障害のタイプ | Standard | エンハンスト | プレミアム |
|---|---|---|---|
| VM / インスタンスの障害 | ✔ | ✔ | ✔ |
| ノード / サーバーの障害 | ✔ | ✔ | ✔ |
| ゾーンの障害 | ❌ | ✔ | ✔ |
| リージョンの障害 | ❌ | ❌ | ✔ |
表 2. サポートされている復元シナリオ
AlloyDB Omni データベースのビジネス目標を検討してください。たとえば、ミッション クリティカルなアプリケーションでは、99.99% の可用性と復元時のデータ損失ゼロといった厳しい要件が求められる場合があります。可用性リファレンス アーキテクチャの目標は、RTO と RPO の要件に対応することです。
AlloyDB Omni は、Standard、Enhanced、Premium の可用性アーキテクチャを提供して、計画的および計画外の停止からデータベースを保護し、さまざまなビジネスニーズに対応します。たとえば、開発環境ではバックアップによる基本的な保護機能を使用し、ミッション クリティカルなアプリケーションでは高可用性と障害復旧の設定を導入できます。
次のステップ
AlloyDB Omni の可用性リファレンス アーキテクチャの詳細を確認する。
- バックアップを使用してデータを保護する（Standard 可用性）。
- リージョン内でゾーン レプリケーションを使用してデータを保護する（エンハンスト可用性）。
- ゾーン レプリケーションとリージョン レプリケーションを使用してデータを保護する（プレミアム可用性）。