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

  • [アーティクル]

適用対象: ✔️ Linux VM

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

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

前提条件

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

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 遠隔同期インスタンスもデプロイすることをお勧めします。

アプリケーションで待機時間が許容される場合は、ご使用の Oracle プライマリ データベースとは異なる可用性ゾーンに Data Guard 遠隔同期インスタンスを設定することをご検討ください。 この構成は十分にテストしてください。 [Maximum Availability](最大限の可用性) モードを使用して、再実行ファイルの同期トランスポートを遠隔同期インスタンスに設定します。 これらのファイルは、スタンバイ データベースに非同期に転送されます。

"最大可用性" モード (同期) で別の可用性ゾーン内に遠隔同期インスタンスを設定する場合、アプリケーションのパフォーマンス低下は許容されない可能性があります。 これが該当しない場合は、プライマリ データベースと同じ可用性ゾーンに遠隔同期インスタンスを設定できます。 可用性をさらに高めるために、プライマリ データベースの近くに複数の遠隔同期インスタンスを設定し、スタンバイ データベースに少なくとも 1 つのインスタンスを設定することをご検討ください (ロールが遷移する場合)。 詳細については、Oracle Active Data Guard 遠隔同期に関する記事を参照してください。

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

参照用アーキテクチャ

Oracle データの保護

Oracle Data Guard は、エンタープライズ データの高可用性、データ保護、ディザスター リカバリーを保証します。 Data Guard では、スタンバイ データベースは、プライマリ データベースとトランザクション上一貫性のあるコピーとして保持されます。 プライマリ データベースとセカンダリ データベースとの間の距離、および待機時間に関するアプリケーションの許容範囲に応じて、同期または非同期のレプリケーションを設定できます。 計画的停止や計画外の停止が原因でプライマリ データベースが使用できなくなった場合、Data Guard でスタンバイ データベースがプライマリ ロールに切り替えられ、ダウンタイムを最小限に抑えます。

Oracle Data Guard を使用している場合は、セカンダリ データベースを読み取り専用で開くこともできます。 このような構成は、Active Data Guard と呼ばれます。 Oracle Database 12c では、Data Guard 遠隔同期インスタンスと呼ばれる機能が導入されました。 このインスタンスを使用すると、パフォーマンスに悪影響を与えずに、Oracle データベースのデータ損失ゼロの構成を設定できます。

Note

Active Data Guard には追加のライセンスが必要です。 このライセンスは、遠隔同期機能を使用する場合にも必要になります。 ライセンス関連の事項については、Oracle の担当者にお問い合わせください。

Oracle Data Guard with Fast-Start Failover

Oracle Data Guard with Fast-Start Failover (FSFO) は、個々のマシンにブローカーを設定して、回復性をさらに向上します。 Data Guard ブローカーとセカンダリ データベースは、どちらもオブザーバーを実行して、プライマリ データベースのダウンタイムを監視します。 このアプローチを使用すると、Data Guard オブザーバーのセットアップでも冗長性を確保できます。

Oracle Database バージョン 12.2 以降では、単一の Oracle Data Guard ブローカー構成で複数のオブザーバーを構成することもできます。 このセットアップを行うと、1 つのオブザーバーとセカンダリ データベースでダウンタイムが発生した場合の可用性が向上します。 Data Guard Broker は軽量で、比較的小規模な仮想マシンでホストできます。 Data Guard Broker とその利点の詳細については、「Oracle Data Guard Broker の概念」を参照してください。

次の図に、可用性ゾーンを使用して Azure で Oracle Data Guard を使用する場合の推奨アーキテクチャを示します。 このアーキテクチャで、99.99% の VM アップタイム SLA を実現できます。

Diagram that shows a recommended architecture for using Oracle Data Guard on Azure with availability zones.

上の図では、クライアント システムは、Web を利用し、Oracle バックエンドを使用してカスタム アプリケーションにアクセスします。 Web フロントエンドは、ロード バランサーで構成されます。 Web フロント エンドは、適切なアプリケーション サーバーへの呼び出しを行い、作業を処理します。 アプリケーション サーバーは、プライマリ Oracle データベースにクエリを実行します。 この Oracle データベースは、ライセンス コストを節約してパフォーマンスを最大化するため、制約付きコア vCPU のハイパースレッド化されたメモリ最適化済み仮想マシンを使用して構成されています。 複数の Premium ディスクまたは Ultra ディスク (マネージド ディスク) が、パフォーマンスと高可用性のために使用されています。

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

他のオブザーバーやスタンバイ データベースを、上のアーキテクチャで示したゾーンとは異なる可用性ゾーン (この例では AZ 1) に設定することもできます。 最後に、Oracle Enterprise Manager (OEM) を使って、Oracle データベースのアップタイムとパフォーマンスが監視されます。 OEM では、パフォーマンスおよび使用状況の各種レポートを生成することもできます。

可用性ゾーンがサポートされていないリージョンでは、可用性セットを使用して、可用性が高い方法で Oracle Database をデプロイできます。 可用性セットを使用すると、99.95% の VM アップタイムを実現できます。 次の図に、この場合のリファレンス アーキテクチャを示します。

Diagram that shows Oracle Database using availability sets with Data Guard Broker - FSFO.

Note

  • デプロイされている OEM のインスタンスは 1 つだけであるため、Oracle Enterprise Manager VM を可用性セットに配置する必要はありません。
  • 可用性セット構成では、Ultra ディスクは現在サポートされていません。

Oracle Data Guard 遠隔同期

Oracle Data Guard 遠隔同期は、Oracle Database に対してデータ損失ゼロの保護機能を提供します。 この機能を使用すると、データベース マシンで障害が発生した際のデータ消失を防ぐことができます。 Oracle Data Guard 遠隔同期は、別の VM にインストールする必要があります。 遠隔同期は、コントロール ファイル、パスワード ファイル、spfile、スタンバイ ログのみを持つ軽量な Oracle インスタンスです。 データ ファイルや REDO ログ ファイルはありません。

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

次の図に、Oracle Data Guard 遠隔同期を使用した高可用性アーキテクチャを示します。

Diagram that shows Oracle database using availability zones with Data Guard Far Sync & Broker - FSFO.

上記のアーキテクチャでは、遠隔同期インスタンスがデータベース インスタンスと同一の可用性ゾーンにデプロイされ、両者の間の待機時間を短縮しています。 アプリケーションが待機時間の影響を受けやすい場合は、データベースと遠隔同期インスタンスを近接通信配置グループにデプロイすることをご検討ください。

次の図に、高可用性とディザスター リカバリーを実現する目的で Oracle Data Guard FSFO と遠隔同期を利用したアーキテクチャを示します。

Diagram that shows Oracle Database using availability zones for disaster recovery with Data Guard Far Sync and Broker - FSFO.

Oracle GoldenGate

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

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

Diagram that shows Oracle Database using availability zones with Data Guard Broker - FSFO.

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 を使用してデプロイすることもできます。

Diagram that shows Oracle Database Sharding using availability zones with Data Guard Broker - FSFO.

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

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

各シャード領域には複数のシャードグループが含まれています。 各シャードグループは複数のシャードを格納しており、レプリケーションのユニットになっています。 各シャードグループには、そのシャード領域のすべてのデータが格納されています。 シャードグループ 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 を使用して、前述の例と同様の、複数リージョンの高可用性のシャード化されたデータベースをデプロイすることもできます。

Diagram that shows Oracle Database Sharding using availability zones with GoldenGate.

上記のリファレンス アーキテクチャでは、システム管理のシャーディング方法を使用してデータをシャード化しています。 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 の使用をご検討ください。
  • データベースへの修正プログラムと更新プログラムの適用を管理してダウンタイムが発生しないようにするには、Azure Pipelines を使用します。
  • アプリケーション コードを調整して、アプリケーションの回復性を高める可能性のあるクラウドネイティブ パターンを追加します。 「クラウド設計パターン」ガイドで定義されている、再試行パターン、サーキット ブレーカー パターンなどのパターンを検討してください。

次のステップ

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