次の方法で共有

Azure Virtual Machines 上の Oracle データベースのアーキテクチャ

  • [アーティクル]

適用対象: ✔️ Linux VM

この記事では、可用性の高い Oracle データベースを Azure にデプロイする方法について詳しく説明します。 また、ディザスター リカバリーの考慮事項についても説明します。 これらのアーキテクチャは、お客様のデプロイに基づいて作成されたものです。 このガイドは Oracle Database Enterprise Edition にのみ適用されます。

Oracle データベースのパフォーマンスを最大限に引き出す方法に関心がある方は、「Azure での Oracle データベースの設計と実装」を参照してください。

前提条件

  • 可用性ゾーンなどの Azure のさまざまな概念を理解していること
  • Oracle Database Enterprise Edition 12c 以降
  • この記事のソリューションを使用する際のライセンスに関連する事項を理解していること
  • 定義された RPO と RTO の要件

Oracle データベースの高可用性

クラウドで高可用性を実現することは、どの組織の計画と設計においても重要な要素です。 Azure は、可用性ゾーンと、可用性ゾーンが使用できないリージョンで使用される "可用性セット" を提供しています。 クラウドの設計方法の詳細については、「Azure Virtual Machinesの可用性オプション」を参照してください。

Oracle は、クラウドネイティブのツールとオファリングに加えて、Azure 上に設定できる、次のような高可用性のためのソリューションを提供しています。

このガイドでは、これらの各ソリューションのリファレンス アーキテクチャについて説明します。

クラウド用のアプリケーションを移行または作成する場合は、再試行パターンやサーキット ブレーカー パターンなどのクラウドネイティブ パターンを使用することをお勧めします。 アプリケーションの回復性の向上に役立つその他のパターンについては、クラウド設計パターンのガイドを参照してください。

クラウド内の Oracle RAC

Oracle Real Application Cluster (RAC) は、多くのインスタンスが 1 つのデータベース ストレージにアクセスするようにして高スループットの実現を支援する、Oracle が提供するソリューションです。 このパターンは全共有型アーキテクチャです。 Oracle RAC はオンプレミスで高可用性を実現するために使用できますが、クラウドでは、高可用性の実現のために Oracle RAC を単独で使用することはできません。 Oracle RAC の保護の対象となるのはインスタンス レベルの障害のみであり、ラック レベルやデータセンター レベルの障害はその対象ではありません。 このため、Oracle では、高可用性を実現するため、データベース (単一インスタンスであれ RAC であれ) と Oracle Data Guard を併用することを推奨しています。

一般に、ミッション クリティカルなアプリケーションを実行する場合は高い SLA が必要とされます。 Oracle では現在、Azure 上での Oracle RAC の認定とサポートは行っていません。 ただし、Azure では、インスタンスレベルの障害に対する保護に役立つ、可用性ゾーンや計画メンテナンス期間などの機能を提供しています。 これらのオファリングに加えて Oracle Data Guard、Oracle GoldenGate、Oracle Sharding を使用すると、ハイ パフォーマンスと回復性を実現できます。 これらのテクノロジを活用して、ラックレベル、データセンターレベル、さらに地政学的な障害からデータベースを保護できます。

Oracle Data Guard または GoldenGate を使用して複数の可用性ゾーンで Oracle Database を実行すると、99.99% のアップタイム SLA を実現できます。 可用性ゾーンがまだ存在しない Azure リージョンでは、可用性セットを利用して、99.95% のアップタイム SLA を達成できます。

Note

Microsoft が提供するアップタイム SLA より大幅に高いアップタイム目標を設定できます。

Oracle データベースのディザスター リカバリー

ミッション クリティカルなアプリケーションをクラウドでホストする場合、高可用性とディザスター リカバリーを念頭に設計することが重要です。

Oracle Database Enterprise Edition の場合、Oracle Data Guard で、ディザスター リカバリーに役立つ機能が提供されています。 ペアになっている Azure リージョンにスタンバイ データベース インスタンスを設定し、ディザスター リカバリー用の Data Guard フェールオーバーを設定することができます。 データ損失ゼロを実現するために、Active Data Guard に加えて、Oracle Data Guard 遠隔同期インスタンスもデプロイすることをお勧めします。

遠距離データ レプリケーションの場合は、Far Sync を利用することをお勧めします。Far Sync は Oracle Active Data Guard の機能です。

Note

Far Sync を有効にする場合は、Active Data Guard ライセンスが必要です。 ライセンス関連の事項については、Oracle の担当者にお問い合わせください。

Oracle Far Sync は、Far Sync インスタンスと呼ばれる中間サーバーを導入することで、プライマリ データベースとセカンダリ データベースの間の遠距離に対処します。 このサーバーでは、プライマリ データベースから再実行データを受信し、スタンバイ データベースに転送します。 そのため、通信時間を短縮するために、Far Sync インスタンスがプライマリのより近くに配置されます。 その後、Far Sync サーバーでは再実行データをセカンダリ データベースに非同期的に転送します。

Note

Oracle Standard Edition データベースを使用する場合、高可用性とディザスター リカバリーの設定に使用できる DBVisit Standby や Tessell などの ISV ソリューションが用意されています。

参照用アーキテクチャ

Oracle データの保護

Oracle Data Guard は、エンタープライズ データの高可用性、データ保護、ディザスター リカバリーを保証します。 Data Guard では、スタンバイ データベースは、プライマリ データベースとトランザクション上一貫性のあるコピーとして保持されます。 プライマリ データベースとセカンダリ データベースとの間の距離、および待機時間に関するアプリケーションの許容範囲に応じて、同期または非同期のレプリケーションを設定できます。

Oracle Data Guard with Fast-Start Failover

Data Guard は、Fast Start Failover (FSFO) を使用してデプロイできます。 Fast-Start-Failover は、Data Guard ブローカー構成内で提供される機能です。 この機能を使用すると、障害が発生した場合に自動的にフェールオーバーできます。 顧客が使用する既定の時間は 30 秒ですが、要件に応じて調整できます。 これは OperationTimeout と呼ばれ、デプロイ時に定義する Data Guard プロパティの一部です。

Data Guard でこのプロパティを使用する方法

Data Guard タスクは、プライマリおよびセカンダリ データベースの正常性と状態を継続的に監視することです。 Fast-Start-Failover (FSFO) を有効にするとすぐに、オブザーバー プロセスがトリガーされ、一定の間隔で正常性状態が確認され、常に高可用性が確保されます。

プライマリ データベースが使用できなくなった場合、オブザーバーと Data Guard ブローカーによりこの中断が検出されます。 そのため、OperationTimeout パラメーターの 30 秒は、ブローカーがプライマリ データベースからの応答を待機してからさらにアクションを実行する時間を示します。

その結果、プライマリがこの 30 秒以内に応答しない場合、オブザーバーはプライマリにアクセスできないことを前提とし、フェールオーバー プロセスを開始します。

ブローカーは直ちにスタンバイ データベースをプライマリ状態に昇格させ、ロールを切り替え、確実にアプリケーションがスタンバイから迅速に再開できるようにします。

また、この間、ブローカーはトランザクションがスタンバイで最新の状態であることを確かめます。 構成するモード (最大可用性または最大保護にすることができる) では、同期レプリケーションによってデータ損失が最小限からゼロになります。 Oracle データベースは、高可用性を実現するために複数の可用性ゾーンに配置されます。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータ センターで構成されています。 回復性を確保するため、有効になっているリージョンにはいずれも最低 3 つのゾーンが別個に設定されています。 可用性ゾーンはリージョン内で物理的に分離されているため、データセンターで障害が発生してもデータは保護されます。 さらに、障害が発生した場合にセカンダリ データベースへのフェールオーバーを開始するために、2 つの可用性ゾーンに 2 つの FSFO オブザーバーが設定されます。 フェールオーバーが発生し、以前のプライマリ データベースが再び使用できるようになった後、復元できます。 Data Guard ブローカーはこのプロセス容易にします。

最終的に、計画的または計画外の停止が原因でプライマリ データベースが使用できなくなった場合、Data Guard によってスタンバイ データベースに切り替えられるかフェールオーバーされます。

この機能では、別の仮想マシンにオブザーバーを設定することで、回復性を高めることができます。 そのため、軽量 VM にオブザーバーをデプロイします。 このアプローチにより、高可用性と回復性が実現します。

Oracle Database バージョン 12.2 以降では、単一の Oracle Data Guard ブローカー構成で複数のオブザーバーを構成することもできます。 これにより、1 つのオブザーバーとセカンダリ データベースでダウンタイムが発生した場合の可用性が向上します。 Data Guard Broker とその利点の詳細については、「Oracle Data Guard Broker の概念」を参照してください。

次の図は、回復時間が 5 分未満で Far Sync を使用しない Oracle Data Guard のインストールを示しています。

Oracle Data Guard アーキテクチャを示す図。

Oracle データベースは、高可用性を実現するために複数の可用性ゾーンに配置されます。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータ センターで構成されています。 回復性を確保するため、有効になっているリージョンにはいずれも最低 3 つのゾーンが別個に設定されています。 可用性ゾーンはリージョン内で物理的に分離されているため、データセンターで障害が発生してもデータは保護されます。 さらに、障害が発生した場合にセカンダリ データベースへのフェールオーバーを開始するために、2 つの可用性ゾーンに 2 つの FSFO オブザーバーが設定されます。

Note

対称的な Data Guard デプロイを計画する場合は、可用性ゾーン 3 にもう 1 つのオブザーバーが必要であることに注意してください。

さらに、データベース レイヤーの概要を常に把握するために、Oracle Enterprise Manager をデプロイすることを強くお勧めします。 Azure Monitor は、次のメトリック (ディスクを監視する) を使用してデプロイすることをお勧めします。

  • [OS Disk IOPS Consumed Percentage]\(OS ディスク IOPS の消費率\)
  • [Data Disk IOPS Consumed Percentage]\(データ ディスク IOPS の消費率\)
  • データ ディスク読み取りバイト数/秒
  • データ ディスク書き込みバイト数/秒
  • ディスクのキューの深さ
  • Lun あたりのディスク帯域幅 (% 単位)

上記に加えて、VM 分析情報も有効にすることを強くお勧めします。

仮想マシンは、AWR 評価に基づいて選択されます。 詳細については、Oracle キャパシティ プランニングに関するページを確認してください。 ライセンス コストを節約し、パフォーマンスを最大化するために制約付きコア vCPU を使用することを強くお勧めします。

ディスクの種類の選択は、AWR 評価の出力によって異なります。

前述のとおり、Far Sync は、遠距離を克服してリージョン間でレプリケートするシナリオで主に使用される機能です。 このシナリオを参照して、Oracle Active Data Guard Far Sync では、Oracle Database に対してデータ損失ゼロの保護機能が提供されます。 Oracle Far Sync インスタンスは、別の VM にインストールする必要があります。

Premium SSD v2 は、オペレーティング システムを参照するファイルではサポートされていません。 詳細については、「Premium SSD v2 をデプロイする」を参照してください。

バックアップ先として Azure Premium Files が使用されます。 これは最もパフォーマンスが高いソリューションです。 バックアップ先として Azure Blob Storage を使用することもできます。 どのオプションが最適かを必ずテストしてください。 「Oracle Database バックアップ戦略」もご覧ください。

Oracle Data Guard 遠隔同期

前述のとおり、Far Sync は、遠距離を克服してリージョン間でレプリケートするシナリオで主に使用される機能です。 このシナリオを参照して、Oracle Far Sync では、Oracle Database に対してデータ損失ゼロの保護機能が提供されます。 Oracle Far Sync インスタンスは、別の VM にインストールする必要があります。

データ損失ゼロの保護を実現するには、プライマリ データベースと遠隔同期インスタンスとの間の同期通信が必要になります。 遠隔同期インスタンスは、プライマリから同期的に redo を受け取り、これをすべてのスタンバイ データベースに非同期的に直ちに転送します。 この設定により、プライマリ データベースのオーバーヘッドも軽減されます。これは、スタンバイ データベースすべてではなく、redo を遠隔同期インスタンスに送信するだけで済むからです。 Far Sync インスタンスで障害が発生すると、Active Data Guard ではプライマリ データベースからセカンダリ データベースへの非同期トランスポートを自動的に使用して、データ損失がほぼゼロの保護を維持します。 回復性を高めるために、各データベース インスタンス (プライマリとセカンダリを含む) に対して複数の遠隔同期インスタンスをデプロイできます。

次の図は、高可用性とディザスター リカバリーを実現する目的で Oracle Active Data Guard FSFO と Far Sync を使用するアーキテクチャです。

リージョン間の Active Data Guard 構成で Far Sync を使用する Oracle Database を示す図。

Note

対称的な Far Sync デプロイを計画する場合は、2 番目のリージョンにもう 1 つの Far Sync インスタンスが必要であることに注意してください。

Oracle GoldenGate

GoldenGate を使用すると、企業全体の複数の異種プラットフォーム間で、トランザクション レベルでのデータ交換やデータ操作を実行できます。 これは、トランザクションの整合性を維持しつつ、既存のインフラストラクチャに対するオーバーヘッドを最小限に抑えて、コミットされたトランザクションを移動します。 このモジュール式アーキテクチャでは、さまざまなトポロジで、選択したデータ レコード、トランザクションの変更、データ定義言語 (DDL) への変更を抽出およびレプリケートする柔軟性が実現します。

Oracle GoldenGate を使用すれば、双方向のレプリケーションを提供して、データベースを高可用性用に構成できます。 このアプローチを使用して、アプリケーション レベルの認識を必要とする "マルチマスター" または "アクティブ/アクティブ構成" を設定できます。 次の図に、Azure での Oracle GoldenGate アクティブ/アクティブ設定の推奨アーキテクチャを示します。 次のアーキテクチャでは、Oracle データベースは、ライセンス コストを節約してパフォーマンスを最大化するため、制約付きコア vCPU のハイパースレッド化されたメモリ最適化済み仮想マシンを使用して構成されています。 このアーキテクチャでは、パフォーマンスと可用性を向上するために、複数の Premium ディスクまたは Ultra ディスク (マネージド ディスク) を使用します。

Data Guard Broker - FSFO と可用性ゾーンを使用した Oracle Database を示す図。

Note

同様のアーキテクチャは、可用性ゾーンが現在使用できないリージョンでも、可用性セットを使用して設定できます。

Oracle GoldenGate には、データを 1 つの Oracle データベース サーバーから別の Oracle データベース サーバーに非同期的にレプリケートするのに役立つ Extract、Pump、Replicat などのプロセスが用意されています。 これらのプロセスを使用すると、双方向レプリケーションを設定して、可用性ゾーン レベルのダウンタイムが発生した場合でもデータベースの高可用性を確保できます。

前の図では、Extract プロセスが Oracle Database と同じサーバーで実行されています。 Data Pump プロセスと Replicat プロセスは、同じ可用性ゾーン内の別のサーバーで実行されています。 Replicat プロセスは、別の可用性ゾーン内のデータベースからデータを受信し、その可用性ゾーン内の Oracle データベースにデータをコミットするために使用されます。 同様に、Data Pump プロセスは、Extract プロセスによって抽出されたデータを、別の可用性ゾーンの Replicat プロセスに送信します。

上のアーキテクチャ図では、Data Pump プロセスと Replicat プロセスが別のサーバー上に構成されていますが、サーバーの容量や使用量によっては、すべての Oracle GoldenGate プロセスを同じサーバー上に設定することもできます。 サーバーの使用パターンを把握するため、AWR レポートと Azure の各種メトリックを常にご確認ください。

Oracle GoldenGate の双方向レプリケーションを異なる可用性ゾーンまたは異なるリージョンに設定する場合、異なるコンポーネント間の待機時間がアプリケーションで許容されることを確認することが重要です。 可用性ゾーン間やリージョン間の待機時間は変化する場合があります。 待機時間は、複数の要因によって異なります。 異なる可用性ゾーンやリージョンのアプリケーション層とデータベース層の間でパフォーマンス テストを設定することをお勧めします。 テストでは、構成がアプリケーションのパフォーマンス要件を満たしているか確認できます。

アプリケーション層は独自のサブネット内に設定でき、データベース層は独自のサブネットに分けることができます。 可能であれば、Azure Application Gateway を使用してアプリケーション サーバー間のトラフィックを負荷分散することをご検討ください。 Application Gateway は、堅牢な Web トラフィック ロード バランサーです。 これは、同じサーバー上にユーザー セッションを維持する Cookie ベースのセッション アフィニティを提供して、データベース上の競合を最小限に抑えます。 Application Gateway の代替手段としては、Azure Load Balancer と Azure Traffic Manager があります。

Oracle Sharding

シャーディングは、Oracle 12.2 で導入されたデータ層パターンです。 これを使用すると、独立した複数のデータベースのデータを水平にパーティショニングし、スケーリングできます。 これは、各データベースが専用の仮想マシンでホストされているシェアード ナッシング アーキテクチャです。 このパターンを使用すると、回復性と可用性が向上するだけでなく、読み取りと書き込みのスループットも向上できます。

このパターンにより、単一障害点が排除され、障害の分離やダウンタイムのないローリング アップグレードを実現できます。 1 つのシャードまたは 1 つのデータ センター レベルの障害のダウンタイムは、他のデータ センターの他のシャードのパフォーマンスや可用性には影響しません。

シャーディングは、ダウンタイムを許容できない高スループット OLTP アプリケーションに適しています。 同じシャーディング キーを持つすべての行は、必ず同じシャード上に置かれます。 そのため、パフォーマンスが向上し、高い整合性が得られます。 シャーディングを使用するアプリケーションには、一貫性のあるハッシュ、範囲、リスト、複合など、適切に定義されたデータ モデルとデータ分散戦略が必要です。 この戦略では、基本的に、customerId や accountNum などのシャーディング キーを使用してデータにアクセスします。 さらに、シャーディングを使用すると特定のデータ セットをエンド カスタマーの近くに保存できるので、パフォーマンスとコンプライアンスの要件を満たしやすくなります。

高可用性とディザスター リカバリーを実現するためにシャードをレプリケートすることをお勧めします。 この設定は、Oracle Data Guard や Oracle GoldenGate などの Oracle テクノロジを使用して実行できます。 レプリケーションのユニットには、シャード、シャードの一部、シャードのグループを指定できます。 1 つ以上のシャードの停止や速度低下が起きても、シャード化されたデータベースの可用性に影響しません。

高可用性が目的の場合、スタンバイ シャードはプライマリ シャードが配置されているのと同じ可用性ゾーンに配置できます。 ディザスター リカバリーが目的の場合、スタンバイ シャードは別のリージョンに配置できます。 シャードを複数のリージョンにデプロイして、それらのリージョンでトラフィックを処理することもできます。 シャード化されたデータベースの高可用性とレプリケーションの構成の詳細については、「シャードレベルの高可用性」を参照してください。

Oracle Sharding は、主に次のコンポーネントで構成されています。 詳細については、「Oracle Sharding の概要」を参照してください。

  • シャード カタログ。 すべてのシャード データベース構成データの永続的なストアとなる特別な用途の Oracle データベース。 シャード データベースでのシャードの追加や削除、データのマッピング、DDL などのすべての構成変更は、このシャード カタログ上で開始されます。 また、シャード カタログには、SDB 内のすべての重複表のマスター コピーも格納されます。

    シャード カタログは、具体化されたビューを使用して、すべてのシャード内の重複表に変更を自動的にレプリケートします。 シャード カタログ データベースは、マルチシャード クエリや、シャーディング キーを指定しないクエリの処理に使用されるクエリ コーディネーターとしても機能します。

    シャード カタログの高可用性を実現するために、ベスト プラクティスとして Oracle Data Guard を可用性ゾーンや可用性セットと一緒に使用することをお勧めします。 シャード カタログの可用性は、シャード化されたデータベースの可用性には影響しません。 シャード カタログのダウンタイムは、Data Guard フェールオーバーが完了する短い期間のメンテナンス操作とマルチシャード クエリにのみ影響します。 SDB では引き続きオンライン トランザクションをルーティングして実行します。 カタログが停止しても、影響は生じません。

  • シャード ディレクター。 シャードが存在するリージョンや可用性ゾーンごとにデプロイする必要がある軽量なサービスです。 シャード ディレクターは、Oracle Sharding のコンテキストでデプロイされるグローバル サービス マネージャーです。 高可用性を実現するために、シャードが存在する各可用性ゾーンに少なくとも 1 つのシャード ディレクターをデプロイすることをお勧めします。

    最初にデータベースに接続するときに、シャード ディレクターではルーティング情報を設定してその情報をキャッシュし、その後の要求時にシャード ディレクターがバイパスされるようにします。 シャードとのセッションが確立されると、すべての SQL クエリと DML がその特定のシャードのスコープ内でサポートされ、実行されます。 このルーティングは高速で、シャード内トランザクションを実行するすべての OLTP ワークロードに使用されます。 最高のパフォーマンスと可用性を必要とするすべての OLTP ワークロードには、直接ルーティングを使用することをお勧めします。 ルーティング キャッシュは、シャードが使用できなくなったとき、またはシャーディング トポロジに変更が発生したときに自動的に更新されます。

    高パフォーマンスのデータ依存ルーティングの場合、Oracle では、シャード データベース内のデータにアクセスする際に接続プールを使用することを推奨しています。 Oracle 接続プール、言語固有ライブラリ、およびドライバーは、Oracle Sharding をサポートしています。 詳細については、「Oracle Sharding の概要」を参照してください。

  • グローバル サービス。 グローバル サービスは通常のデータベース サービスに似ています。 グローバル サービスには、データベース サービスのすべてのプロパティに加え、シャード化されたデータベース用のプロパティが用意されています。 これらのプロパティには、クライアントとシャードの間のリージョン アフィニティや、レプリケーション ラグの許容範囲などがあります。 シャード化されたデータベースとの間でデータの読み取り/書き込みを行うために、グローバル サービスを 1 つだけ作成する必要があります。 Active Data Guard を使用してシャードの読み取り専用レプリカを設定する場合、読み取り専用ワークロード用に別のグローバル サービスを作成できます。 クライアントは、これらのグローバル サービスを使用してデータベースに接続できます。

  • シャード データベース。 シャード データベースとは、お使いの Oracle データベースのことです。 各データベースは、FSFO が有効になっているブローカー構成で Oracle Data Guard を使用してレプリケートされます。 ユーザーが各シャードで Data Guard のフェールオーバーやレプリケーションを設定する必要はありません。 この特性は、共有データベースが作成される時に自動的に構成およびデプロイされます。 特定のシャードが失敗すると、Oracle Sharding ではデータベース接続をプライマリからスタンバイにフェールオーバーします。

Oracle のシャード化されたデータベースは、Oracle Enterprise Manager Cloud Control GUI と GDSCTL コマンド ライン ユーティリティの 2 つのインターフェイスでデプロイおよび管理できます。 Cloud Control を使用すると、さまざまなシャードの可用性とパフォーマンスを監視することもできます。 GDSCTL DEPLOY コマンドを実行すると、シャードとそれぞれのリスナーが自動的に作成されます。 また、このコマンドは、管理者によって指定されたシャードレベルの高可用性に使用されるレプリケーション構成を自動的にデプロイします。

データベースをシャード化するには、以下のさまざまな方法があります。

  • システム管理のシャーディング: パーティション分割を使用して自動的にシャード間に分散されます
  • ユーザー定義のシャーディング: シャードへのデータのマッピングをユーザーが指定できます。これは、規制やデータのローカライズ要件が存在する場合に適しています
  • コンポジット シャーディング: 異なる "シャード領域" のためにシステム管理のシャーディングとユーザー定義のシャーディングを組み合わせたものです
  • テーブルのサブパーティション: 通常のパーティション テーブルに似ています

詳細については、「シャーディング方法」をご覧ください。

シャード化されたデータベースは、アプリケーションや開発者には単一のデータベースのように見えます。 シャード化されたデータベースに移行する場合は、慎重に計画して、どのテーブルを複製し、どのテーブルをシャード化するかを把握してください。

重複表はすべてのシャードに格納されるのに対し、シャード化されたテーブルは異なるシャード間に分散されます。 小さいテーブルやディメンション テーブルは複製し、ファクト テーブルは分散/シャード化することをお勧めします。 データは、シャード カタログをセントラル コーディネーターとして使用するか、各シャードでデータ ポンプを実行することにより、シャード データベースに読み込むことができます。 詳細については、「シャード化されたデータベースにデータを移行する」を参照してください。

Data Guard での Oracle Sharding

Oracle Data Guard は、システム管理、ユーザー定義、コンポジットのシャーディング方法で使用できます。

次の図に、各シャードの高可用性を実現するために Oracle Data Guard で Oracle Sharding を使用する場合のリファレンス アーキテクチャを示します。 このアーキテクチャ図は、コンポジット シャーディング方法を示しています。 アーキテクチャ図は、データの局所性、負荷分散、高可用性、ディザスター リカバリーの要件が異なるアプリケーションでは異なる可能性があります。 アプリケーションで、異なるシャーディング方法を使用する場合があります。 Oracle Sharding では、これらのオプションを提供することにより、このような要件を満たし、水平的かつ効率的にスケーリングを行えるようにしています。 同様のアーキテクチャは、Oracle GoldenGate を使用してデプロイすることもできます。

Data Guard Broker - FSFO と可用性ゾーンを使用した Oracle Database Sharding を示す図。

システム管理のシャーディングは、構成と管理が最も容易です。 ユーザー定義のシャーディングやコンポジット シャーディングは、データやアプリケーションが地理的に分散しているシナリオや、各シャードのレプリケーションを制御する必要があるシナリオに適しています。

上記のアーキテクチャでは、データを地理的に分散し、アプリケーション層を水平にスケールアウトする目的でコンポジット シャーディングを使用しています。 コンポジット シャーディングは、システム管理のシャーディングとユーザー定義のシャーディングを組み合わせたもので、両方の方法の利点を活用できます。 上のシナリオでは、リージョンによって区切られた複数のシャード領域にデータがまずシャード化されます。 次に、コンシステント ハッシュを使用して、そのデータがそのシャード領域の複数のシャード間にさらにパーティション化されます。

各シャード領域には複数のシャードグループが含まれています。 各シャードグループは複数のシャードを格納しており、レプリケーションのユニットになっています。 各シャードグループには、そのシャード領域のすべてのデータが格納されています。 シャードグループ A1 と B1 はプライマリ シャードグループで、シャードグループ A2 と B2 はスタンバイです。 シャードグループではなく、個々のシャードをレプリケーションのユニットに指定することもできます。

上記のアーキテクチャでは、高可用性を実現するために、各可用性ゾーンに Global Service Manager (GSM)/シャード ディレクターがデプロイされています。 データ センターやリージョンごとに、少なくとも 1 つの GSM/シャード ディレクターをデプロイすることをお勧めします。 さらに、アプリケーション サーバーのインスタンスは、シャードグループを含むすべての可用性ゾーンにデプロイされます。 この設定により、アプリケーションは、アプリケーション サーバーとデータベース/シャードグループの間の待機時間を短く維持できます。 データベースに障害が発生した場合、スタンバイ データベースと同じゾーンにあるアプリケーション サーバーは、データベース ロールの遷移が発生すると、要求を処理できます。 Azure Application Gateway とシャード ディレクターは、要求と応答の待機時間を追跡し、それに応じて要求をルーティングします。

アプリケーションの観点から見ると、クライアント システムが Azure Application Gateway または Azure の他の負荷分散テクノロジに対して要求を行い、そこから、クライアントに最も近いリージョンに要求がリダイレクトされます。 Azure Application Gateway は固定セッションもサポートしているため、同じクライアントからの要求はすべて同じアプリケーション サーバーにルーティングされます。 アプリケーション サーバーは、データ アクセス ドライバーで接続プールを使用します。 この機能は、JDBC、ODP.NET、OCI などのドライバーで使用できます。 これらのドライバーは、要求の一部として指定されたシャーディング キーを認識できます。 JDBC クライアントの Oracle Universal Connection Pool (UCP) を使用すると、非 Oracle アプリケーション クライアント (Apache Tomcat や IIS など) は、Oracle Sharding と連携できます。 詳細については、「データベース シャーディングの UCP 共有プールの概要」を参照してください。

最初の要求の間、アプリケーション サーバーはそのリージョンのシャード ディレクターに接続して、その要求のルーティング先となるシャードのルーティング情報を取得します。 渡されたシャーディング キーに基づいて、ディレクターはアプリケーション サーバーをそれぞれのシャードにルーティングします。 アプリケーション サーバーは、マップを構築することによってこの情報をキャッシュし、後続の要求ではシャード ディレクターをバイパスして、要求を直接シャードにルーティングします。

GoldenGate での Oracle Sharding

次の図に、各シャードのリージョン内の高可用性を実現するために Oracle GoldenGate で Oracle Sharding を使用する場合のリファレンス アーキテクチャを示します。 前述のアーキテクチャとは異なり、このアーキテクチャでは、可用性ゾーンが複数ある、1 つの Azure リージョン内での高可用性のみを図示しています。 Oracle GoldenGate を使用して、前述の例と同様の、複数リージョンの高可用性のシャード化されたデータベースをデプロイすることもできます。

GoldenGate で可用性ゾーンを使用した Oracle Database Sharding を示す図。

上記のリファレンス アーキテクチャでは、システム管理のシャーディング方法を使用してデータをシャード化しています。 Oracle GoldenGate のレプリケーションはチャンク レベルで実行されるため、1 つのシャードにレプリケートされたデータの半分を別のシャードにレプリケートできます。 残りの半分は異なるシャードにレプリケートできます。

データがレプリケートされる方法は、レプリケーション係数によって異なります。 レプリケーション係数が 2 の場合、シャードグループ内の 3 つのシャードにまたがって、データの各チャンクのコピーが 2 つ作成されます。 同様に、レプリケーション係数が 3 で、シャードグループ内に 3 つのシャードが存在する場合、各シャード内のすべてのデータがそのシャードグループ内の他のすべてのシャードにレプリケートされます。 シャードグループ内の各シャードには、異なるレプリケーション係数を指定できます。 この設定は、1 つのシャードグループ内および複数のシャードグループにまたがる高可用性とディザスター リカバリーの設計を効率的に定義するのに役立ちます。

上記のアーキテクチャでは、シャードグループ A とシャードグループ B はどちらも同じデータを格納していますが、異なる可用性ゾーンに存在しています。 シャードグループ A とシャードグループ B の両方に同じレプリケーション係数 3 が指定されている場合、シャード テーブルの各行またはチャンクは、2 つのシャードグループ全体で 6 回レプリケートされます。 シャードグループ A のレプリケーション係数が 3 で、シャードグループ B のレプリケーション係数が 2 に指定されている場合は、各行またはチャンクは、2 つのシャードグループ全体で 5 回レプリケートされます。

この設定により、インスタンスレベルや可用性ゾーンレベルの障害が発生した場合でも、データの損失を防ぐことができます。 アプリケーション レイヤーは、各シャードに対して読み取りと書き込みを実行できます。 競合を最小限に抑えるため、Oracle Sharding はハッシュ値の範囲ごとに "マスター チャンク" を指定します。 この機能を使用して、特定のチャンクに対する書き込み要求が、対応するチャンクに確実に転送されます。 さらに、Oracle GoldenGate には、発生する可能性のある競合を処理する自動競合検出と解決機能が用意されています。 Oracle Sharding を使用した GoldenGate の実装に関する詳細と制限事項については、「シャード化されたデータベースで Oracle GoldenGate を使用する」を参照してください。

上記のアーキテクチャでは、高可用性を実現するために、各可用性ゾーンに GSM/シャード ディレクターがデプロイされています。 データ センターやリージョンごとに、少なくとも 1 つの GSM/シャード ディレクターをデプロイすることをお勧めします。 アプリケーション サーバーのインスタンスは、シャードグループを含むすべての可用性ゾーンにデプロイされます。 この設定により、アプリケーションは、アプリケーション サーバーとデータベース/シャードグループの間の待機時間を短く維持できます。 データベースに障害が発生した場合、スタンバイ データベースと同じゾーンにあるアプリケーション サーバーは、データベース ロールが遷移すると、要求を処理できます。 Azure Application Gateway とシャード ディレクターは、要求と応答の待機時間を追跡し、それに応じて要求をルーティングします。

アプリケーションの観点から見ると、クライアント システムが Azure Application Gateway または Azure の他の負荷分散テクノロジに対して要求を行い、そこから、クライアントに最も近いリージョンに要求がリダイレクトされます。 Azure Application Gateway は固定セッションもサポートしているため、同じクライアントからの要求はすべて同じアプリケーション サーバーにルーティングされます。 アプリケーション サーバーは、データ アクセス ドライバーで接続プールを使用します。 この機能は、JDBC、ODP.NET、OCI などのドライバーで使用できます。 これらのドライバーは、要求の一部として指定されたシャーディング キーを認識できます。 JDBC クライアントの Oracle Universal Connection Pool (UCP) を使用すると、非 Oracle アプリケーション クライアント (Apache Tomcat や IIS など) は、Oracle Sharding と連携できます。

最初の要求の間、アプリケーション サーバーはそのリージョンのシャード ディレクターに接続して、その要求のルーティング先となるシャードのルーティング情報を取得します。 渡されたシャーディング キーに基づいて、ディレクターはアプリケーション サーバーをそれぞれのシャードにルーティングします。 アプリケーション サーバーは、マップを構築することによってこの情報をキャッシュし、後続の要求ではシャード ディレクターをバイパスして、要求を直接シャードにルーティングします。

修正プログラムの適用とメンテナンス

Oracle ワークロードを Azure にデプロイする場合、ホスト オペレーティング システム レベルのすべての修正プログラムを Microsoft が適用します。 Microsoft は、計画されているオペレーティング システム レベルのメンテナンスを事前にお客様にお伝えします。 異なる 2 つの可用性ゾーンの 2 つのサーバーに同時に修正プログラムが適用されることはありません。 VM のメンテナンスと修正プログラムの適用の詳細については、「Azure Virtual Machines の可用性オプション」を参照してください。

仮想マシンのオペレーティング システムへの修正プログラムの適用は、Azure Automation Update Management を使用して自動化できます。 Oracle データベースへの修正プログラムの適用とメンテナンスは、Azure Pipelines または Azure Automation Update Management を使用して自動化およびスケジュールし、ダウンタイムを最小限に抑えることができます。 継続的デリバリーとブルーグリーン デプロイの詳細については、「段階的公開型手法」を参照してください。

アーキテクチャと設計に関する考慮事項

  • ライセンス コストを節約してパフォーマンスを最大化するには、Oracle Database VM に制約付きコア vCPU のハイパースレッド化されたメモリ最適化済み仮想マシンを使用することをご検討ください。 パフォーマンスと可用性を向上させるには、複数の Premium ディスクまたは Ultra ディスク (マネージド ディスク) を使用します。
  • マネージド ディスクを使用する場合、再起動時にディスク/デバイス名が変更される可能性があります。 再起動してもマウントが確実に持続するように、名前ではなく、デバイス UUID を使用することをお勧めします。 詳細については、「新しいファイル システムを /etc/ fstab に追加する」を参照してください。
  • リージョン内で高可用性を実現するには、可用性ゾーンを使用します。
  • Oracle データベースには、Ultra ディスク (使用可能な場合) か Premium ディスクの使用をご検討ください。
  • スタンバイ Oracle データベースは、Oracle Data Guard を使用して別の Azure リージョンに設定することをご検討ください。
  • アプリケーションとデータベース層の間の待機時間を短縮するには、近接通信配置グループの使用をご検討ください。
  • Azure VM の最大ネットワーク帯域幅は (通常)、同じ SKU 上の最大ディスク スループットよりも高くなります。 同じ VM SKU で高いスループットを実現することも、データベースに Azure NetApp Files などの高パフォーマンスで待ち時間の短いネットワーク ストレージを使ってより小さな VM SKU を 使用することもできます。
  • 管理、監視、ログのため、Oracle Enterprise Manager を設定します。
  • データベースのストレージ管理を合理化するには、Oracle Automatic Storage Management の使用をご検討ください。
  • Oracle Data Guard の概要
  • アプリケーション コードを調整して、アプリケーションの回復性を高める可能性のあるクラウドネイティブ パターンを追加します。 「クラウド設計パターン」ガイドで定義されている、再試行パターン、サーキット ブレーカー パターンなどのパターンを検討してください。

次のステップ

次の Oracle リファレンス記事の中から、お客様のシナリオに当てはまるものをご確認ください。