Embed Size (px)
Citation preview
新世代のOracle RAC Oracleホワイト・ペーパー/2020年1月
2 新世代のOracle Real Application Clusters（Oracle RAC）
目次
概要 ··············································································································································································································· 3
データベース設計に組み込まれる高可用性とスケーラビリティ ······································································································· 4
Oracle RACのコンポーネントの概要 ·········································································································································································································4
図1：Oracle RACアーキテクチャ概要の簡易図 ···············································································································································································································································4
Oracle RACのスケールアウト・アーキテクチャ·············································································································································································································································5
Oracle Clusterware················································································································································································································································································································6
Oracle ASM ·································································································································································································································································································································6
アプリケーション・コンティニュイティ ····························································································································································································································································6
Fleet Patching and Provisioning ·················································································································································································································································································7
新世代のOracle RAC ·····································································································································································································································7
Oracle Real Application Clusters 19c········································································································································································································································································7
エンジニアド・システム - Oracle RACを念頭に置いた設計 ················································································································ 9 Exadataのスケールアウト・アーキテクチャ ····················································································································································································································································9
Oracle RACに役立つExadataの拡張機能 ·······························································································································································································································································9
Oracle CloudへのOracle RACの利点の拡張··········································································································································11 Oracle RACとAutonomous Database ··································································································································································································································································· 11
Oracle RACと他のスケールアウト・データベースによるアプローチの比較 ·················································································12
結論 ·············································································································································································································14
3 新世代のOracle Real Application Clusters（Oracle RAC）
概要
企業が世界で成功できるかどうかは、高速で動作する、信頼性の高いミッション・クリティカルなアプリケーションにかかっています。そのような重要なアプリケーションに、可用性やスケーラビリティの問題があると、業務に支障が生じたり、業務が停止したりします。アプリケーションの可用性と応答性は、アプリケーションを下から支えるデータベースの信頼性と応答性で決まります。オラクルは長年、Oracle Real Application Clusters（Oracle RAC）の開発と強化に投資し、ミッション・クリティカルなアプリケーションで必要とされる透過的データベースの可用性とスケーラビリティを実現してきました。このテクノロジーは業界でも特異なもので、世界の大手企業の多くで、社内アプリケーションと顧客が使用する重要なアプリケーションの双方で使われています。
このホワイト・ペーパーでは、Oracle RACについて、および重要なアプリケーションで必須とされる、以下のような要件にOracle RACがどのように合致しているのかを説明します。
1. 高可用性 - 重要なアプリケーションをサポートするデータベースでは、アプリケーションからのリクエストに対応し続ける必要があり、ハードウェアやソフトウェアに障害が発生した場合でも、それは変わりません。また、アプリケーションの動作を中断させることなく、ハードウェア、OS、データベース・ソフトウェア、データベース・スキーマなどの全レベルで計画メンテナンスを実行できなければなりません。
2. ワークロードのスケーラビリティ - 重要なアプリケーションをサポートするデータベースでは、増え続けるアプリケーションのワークロードに動的に、かつ途切れることなく適応する必要があります。コンピューティング、ストレージ、メモリ、接続、ユーザー、アプリケーションの複雑さを透過的にスケーリングできなければなりません。
3. アプリケーションの変更が不要 - 重要なアプリケーションをサポートするデータベースは、アプリケーションに変更を加えることなく、上記の要件を満たす必要があります。企業は長年アプリケーションの開発に投資してきました。既存のアプリケーションを作り直すのは、単純に費用対効果が見込めません。
Oracle RACは、アプリケーション・コードを変更せずに、クラスタ内の最大100ノードでほぼ直線的なスケーラビリティと可用性を維持できるため、上記の必須要件に対応できる、優れたテクノロジーとなってきました。Oracle RACデータベースをOracle Exadata Database Machineと組み合わせることで、世界最大かつもっとも要件の厳しいOLTPおよび分析ワークロードを問題なく実行できます。
Oracle Database 19cにはRACアーキテクチャの主要な改善点が実装されており、わずか数年前と比べても、アプリケーションの可用性とスケーラビリティが何倍も向上しています。同時に、そのような改善点によってOracle RACテクノロジーは新しい世代を迎え、次世代のワークロードおよびアプリケーションのニーズを満たす準備ができています。
4 新世代のOracle Real Application Clusters（Oracle RAC）
データベース設計に組み込まれる高可用性とスケーラビリティ
オラクルは当初から、高可用性とスケーラビリティのコンセプトを考案し、Oracle Databaseの設計に組み入れています。これにはACID準拠のデータベース、安定したバックアップとリカバリ、レプリケーション・ソリューション（Oracle Data Guard）だけでなく、可用性が高く、スケーラビリティを備えるローカル・ソリューションとしてのOracle RACの提供も含まれています。
データベースの設計に高可用性とスケーラビリティを組み入れることで、とりわけOracle RACを使用してそのようにすることで、これまでにはなかった、集約型のOracle Database1とデータベース・アプリケーション（変更は発生しない）のあらゆる機能を対象とするスケーリング能力が実現しました。以下はその例です。
• Oracle RACはOracle Databaseのすべての機能とアーキテクチャをスケーリングします。 o Oracle MultitenantデータベースおよびCDB以外のデータベース o 分析とバッチを高速化するOracle Parallel SQL o クラスタ内のインスタンス全体を対象とするOracle Database In-Memory o Multi-Instance-Redo-Apply（MIRA）を使用するOracle Data Guard
• Oracle RACはOLTP、DWH、分析の複雑なワークロードをスケーリングします。 o 通常、Oracle RAC上で動作するSAP、Oracle E-Business Suite、PeopleSoft、Siebel、その他多数のビジネス・アプ
リケーション o 15,000以上のお客様がOracle RACを使用してワークロードを問題なく処理
• Oracle RACによって、24時間年中無休で稼働するシステムが、同種製品で最高レベルの高可用性を備えるようになります。 o Fortune 1000にランクインしている銀行、通信会社、航空会社、E-Commerce企業の大半が、自社の重要なアプリ
ケーションにOracle RACを使用 o Oracle RACは、ほとんどのハードウェアおよびソフトウェア障害、およびメンテナンス・イベント発生時も、デー
タベースの可用性を維持
本書ではこの後、Oracle RACがファンクション・シッピングと配信キャッシュの組合せを使用して、業界屈指のスケーラビリティと可用性をどのように達成しているか、最新バージョンのOracle RACはどのような点が改善されて、来たるべき新世代のアプリケーションとDBAが高可用性とスケーラビリティを活用できるようになっているかについて説明します。
Oracle RACのコンポーネントの概要
Oracle RACはアプリケーションに対して透過的なスケールアウト・データベース・アーキテクチャを実装しており、アプリケーションはそこで、任意のデータベース・インスタンス（サーバー上のプロセスとメモリのコレクションで、Oracle Databaseの実行に使用されるものと定義される）に接続します。このインスタンスは、さまざまなサーバーでホストされる、最大100個のデータベース・インスタンスから成るクラスタの一部です。すべてのサーバーは、実際のデータ（データベース・ファイルのセット）を保持している共有ストレージ・システムにアクセスできる必要があります。サーバーは専用の高速ネットワークを介して接続されている必要があります。このネットワークは通常、RACインターコネクトと呼ばれます。
図1：Oracle RACアーキテクチャ概要の簡易図
1 オラクルのコンバージド・データベース・アーキテクチャの詳細については、https://youtu.be/9d76-LhgMQsを参照してください。
5 新世代のOracle Real Application Clusters（Oracle RAC）
このインターコネクトはアーキテクチャの主要な部分であり、このインターコネクトによって、アプリケーション側からはOracle RACのスケールアウト・データベースが“1つのシステム”として認識され、そこではすべてのデータベース・インスタンスが、統制の取れた一貫した方法で、どのようなデータにもアクセスでき、データを更新できます。つまり、アプリケーションは、どのデータベース・インスタンスがワークロードのリクエストを処理しているのかを認識する必要がありません。加えて、Oracle RACは5つの重要なソフトウェア・コンポーネントを利用します。
1. スケールアウト・データベース・インスタンス。複数のデータベース・インスタンスがデータベースのデータに同時アクセスできるだけでは不十分であり、統制の取れたアクセスと更新が可能なインテリジェント機能を備えている必要があります。データベース・レイヤー内でのこのインテリジェント機能は、オラクル独自のキャッシュ・フュージョン・テクノロジーによって提供されます。これは、クラスタのノード全体で一貫したデータの分散キャッシュを実装し、効率的な水平スケーリングを実現するアルゴリズムです。
2. Oracle Clusterwareは、サーバーのコレクションを高可用性クラスタに変換します。管理の観点では、クラスタは独立したサーバーのプールとは対照的に、1つのエンティティとして管理されます。さらに、Oracle Clusterwareには障害検出、フェイルオーバー、クラスタのノード・メンバーシップ管理の機能もあります。
3. 自動ストレージ管理（ASM）は、個別のOracle RACデータベース・インスタンスすべてからのデータベース・ファイルへの同時アクセスを有効にして、ストレージをスケーリングします。さらにOracle ASMは、最適化されたデータベース・ファイル・アクセスおよびデータ・ミラー化によるストレージ障害からの保護などのボリューム管理機能を備えています。
4. アプリケーション・コンティニュイティ（AC）は、稼働中のインスタンスへのアクティブなアプリケーション接続を、透過的に自動フェイルオーバーします。これは、部分的に実行済みである処理中のリクエストとトランザクションを、中断なく迅速にリプレイすることで行われます。
5. Fleet Patching and Provisioning（FPP）は、Oracle RACで課題となっていたものの一部であるパッチ適用とプロビジョニングを大幅に自動化および簡素化します。Oracle Fleet Patching and Provisioning（旧称Oracle Rapid Home Provisioning）は、プロビジョニング、パッチ適用、アップグレードの調整を図り、アプリケーションにとってのデータベースの可用性を最大化します。
Oracle RACのスケールアウト・アーキテクチャ データベース・システムをサーバー全体で水平スケーリングするには、2つの基本的な方法があります。1）SQLを実行している、データへのアクセスを必要とするサーバーにデータを移動する（データ・シッピングまたは共有ディスクと呼ばれることがある）方法と、2）リモートのサーバーにSQLを送信し、データにローカルでアクセスする（ファンクション・シッピングまたはシェアード・ナッシングと呼ばれることがある）方法です。Oracle RACは、データ・シッピング共有ディスク・アーキテクチャであると誤って説明されることがたびたびありますが、実際には前述の2つの方法を組み合わせて使用し、それぞれの長所を利用してスケールアウト・アーキテクチャを実現しています。
Oracle RACはファンクション・シッピング（シェアード・ナッシング）によって、長時間稼働する分析およびバッチSQLを実行します。Oracle RACは、多量のデータを処理するSQL文をSQLフラグメントに分割し、クラスタ内のデータベース・インスタンス全体で並列に実行することで、長時間実行されるSQL文を自動的にパラレル処理します。従来のシェアード・ナッシング・データベースとは異なり、Oracle RACインスタンスはストレージからどのようなデータでも読み取れるため、データベース・データの特定のサブセットに拘束されることはありません。そのため、Oracle RACはクラスタのノード全体にワークロードを動的に分散させることができ、1つの低速なインスタンスが全体のオペレーションを低速にさせる大規模なスキューが回避されます。
ファンクション・シッピングは分析には非常に有効ですが、OLTPには不向きです。OLTPリクエストがアクセスする行数は概して少なく、非常に高速な応答時間が要求されます。RPCコールをリモート・ノードに送信して、1行にアクセスしたり、1つのインデックスを横断したりすると、非常に低速で、高コストになります。また、最後のリクエスト以降にデータが変更されている可能性があるため、アプリケーションが同じデータにアクセスするたびに、リクエストをリモート・ノードに再送信する必要があります。さらに、データが常駐するインスタンスにリクエストを送信するには、複雑かつ高コストの分散トランザクションと、2フェーズ・コミット・プロトコルによって、インスタンスを調整する必要があります。その上、シェアード・ナッシングは、多数の表やインデックスへのスケーリング機能が不足しているため、ERP、CRM、HCMなどの複雑なアプリケーションでは適切に動作しません。このような難点があるため、透過的なシェアード・ナッシング・データベースのアプローチは、長年の愛用者にも、OLTPソリューションとしては使われていません。現在、ERP、CRM、HCMのような複雑なOLTPアプリケーションを実行するシェアード・ナッシング・アーキテクチャはありません。
Oracle RACは、アプリケーションのリクエストを受信するインスタンスで直接、短時間稼働するOLTP SQLを実行します。インスタンスのローカルですでにキャッシュされているOLTP SQLでリクエストされたデータは、メモリから直接、即座にアクセスされます。インスタンスのローカルにないデータは、高パフォーマンスのデータ転送プロトコルを使用して、ストレージやリモート・インスタンスからそのインスタンスに移され、ローカルでキャッシュされます。
データをローカルでキャッシュすることで、同じデータへのその後のアクセスが劇的に高速になり、メッセージングが不要になります。キャッシュはよく知られた定評のある方法であり、多くの場合、リモート・アクセスを90 %～99 %減らして、応答時間を大幅に改善できます。トランザクションがインスタンスのローカルで実行されるために、高いコストのかかる分散トランザクションや2フェーズ・コミット・プロトコルも不要です。
6 新世代のOracle Real Application Clusters（Oracle RAC）
Oracle RACでは、アプリケーションはデータが常駐する場所（いずれかのデータベース・インスタンスのメモリ、またはディスク）を認識する必要はありません。アプリケーションが接続されるインスタンスに、RACプロトコルが自動でデータを移動するためです（データの位置の透過性）。完全なデータ整合性を維持しつつ、高パフォーマンスの分散キャッシュ・プロトコルを実装するアルゴリズムは、Oracleキャッシュ・フュージョンと呼ばれています。
キャッシュ・フュージョンはプライベート・クラスタのインターコネクトを利用して、クラスタ全体で単一の“融合型”キャッシュを仮想的に作成し、いずれかのOracle RACデータベース・インスタンスにキャッシュされたデータに共有アクセスできるようにします。キャッシュ・フュージョンは、インスタンス全体でデータ・ブロックをメモリからメモリに直接送信するため、パフォーマンスが高くなります。Oracle RACデータベース・インスタンスは、Oracle RAC構成全体で結合されたキャッシュにブロックがまだ存在しない場合のみ、ストレージからデータを読み取る必要があります。キャッシュ・フュージョンには、複数のインスタンスで同じデータ・ブロックが同時に更新されるのを防止するためのロック用プロトコルも実装されており、クラスタの個別のインスタンス全体に分散されたOracle RACキャッシュへの最適化された同時データ・アクセスを提供しつつ、整合性を確保します。
Oracle RACはファンクション・シッピング、データ・シッピング、分散データ・キャッシュを組み合わせて使用することで、分析、OLTP、バッチ、またはそれらを組み合わせたワークロードを独自の方法で最適化しています。オラクルは先般、Oracle RACのパフォーマンスをさらに向上させるため、Oracle RACのアルゴリズムの大幅な機能強化を実施しました。
Oracle Clusterware Oracle Clusterwareは、RACアーキテクチャで使用されるテクノロジーで、サーバーのコレクションを可用性の高い統合システムに変換します。Oracle Clusterwareでは、障害検出、ノード・メンバーシップ、ノード・フェンシング、最適なリソース配置が提供されます。Oracle RACとクラスタ内の他のアプリケーション向けに、クラスタ全体でコンポーネントの相互依存性を管理します。Clusterwareはリソース・モデルとポリシーを使用して、計画された停止時間や予期しない停止時間がコンポーネントで発生した際にも、高い可用性で応答します。
Oracle Clusterwareの詳細については、http://www.oracle.com/goto/clusterwareを参照してください。
Oracle ASM 自動ストレージ管理（ASM）は、データベースに統合されたファイル・システムとボリューム・マネージャであり、24時間365日の可用性で、多数のストレージ・デバイスを対象に、ストレージ容量の共有とスケーリングを有効にします。ASMはOracle RACデータベース向けに、クラスタのすべてのサーバーでストレージを管理します。データをストライプ化して、ホットスポットを回避し、I/Oのパフォーマンスを最大化します。ASMでは、ストレージ容量をオンラインで追加したり削除したりできます。ASMは、データの冗長化されたミラー・コピーを保持してフォルト・トレランスに利用します。または、ベンダーから提供される信頼性のあるストレージ・アレイ上で使用することもできます。データ管理は、データベース・ファイルごとに人間が介入するのではなく、データのクラス向けに、希望する信頼性およびパフォーマンスの特性を選択することで実行されます。
ASMによって、クラスタ化された大規模なデータベースで現実に発生する管理の問題の多くを解決できます。データベースや関連データのサイズが増大し、数千台のストレージ・デバイスや数十台のサーバーに及ぶと、ストレージ管理の従来の手法では効率的にスケーリングできず、人為ミスが発生しがちになります。手動でのロードバランシングなどのタスクも、非常に複雑になります。Oracle ASMは、Oracle RACおよびオラクルのシングル・インスタンス・データベースでのこうした問題を解決します。
Oracle ASMの詳細については、http://www.oracle.com/goto/asmを参照してください。
アプリケーション・コンティニュイティ Oracle RACはアクティブ-アクティブのデータベース管理システムで、RACデータベース・インスタンスやサーバーに障害が発生した後でも、データベース・サービスはOracle RACで稼働し続けます。これはアクティブ-パッシブ構成を利用するテクノロジーとは対照的です。アクティブ-パッシブ構成では、アクティブなデータベース・インスタンスで障害が発生すると、処理を再起動または再開する必要があり、通常はその後にフェイルオーバーが実行されて、一時停止時間（何分もの時間を要することがある）が発生します。どちらの状況でも、障害発生時に処理中であったSQLおよびコミットされていない全トランザクションが停止し、データベース管理システムによってロールバックされます。こうした障害に対応するには、アプリケーションごとに複雑なアプリケーション・ロジックを記述する必要があります。ただし、障害が発生するのはまれであるため、このロジックは往々にして無視されたり、十分にテストされなかったりし、アプリケーションの障害につながったり、データが論理的に破損する可能性を抱えたりします。
7 新世代のOracle Real Application Clusters（Oracle RAC）
Oracle RACに組み込まれているアプリケーション・コンティニュイティ（AC）を活用すると、稼働中のインスタンスへのアクティブなアプリケーション接続が、透過的に自動でフェイルオーバーされます。アプリケーション・コンティニュイティは、部分的に実行済みである処理中のリクエストとトランザクションを、中断のない迅速な方法でリプレイします。リプレイに成功すると、アプリケーションはあたかも障害など発生しなかったかのように、透過的に動作を続けます。アプリケーション・コンティニュイティを利用するアプリケーション開発者は、アプリケーションでトランザクションを誤って2回実行してしまうことを心配する必要はなく、複雑なエラー対応とリトライのためのコードを作成したり、さらに悪い場合には失敗したリクエストを手動でリカバリする方法を探したりする必要もありません。アプリケーション・コンティニュイティによって、アプリケーションの耐障害性が大幅に強化され、コード作成が簡単で迅速になります。
Oracleアプリケーション・コンティニュイティの詳細については、http://www.oracle.com/goto/acを参照してください。
Fleet Patching and Provisioning かつては、Clusterware、Oracle ASM、Oracle RACデータベースのプロビジョニングとパッチ適用は複雑な作業でした。オラクルのFleet Patching and Provisioning（FPP）は、このプロセスを大幅に自動化および簡素化します。Oracle Fleet Patching and Provisioning（旧称Oracle Rapid Home Provisioning）は、プロビジョニング、パッチ適用、アップグレードの調整を図り、アプリケーションにとってのデータベースの可用性を最大化します。
Oracle FPPはOracle RACアーキテクチャに完全に統合されています。Oracle FPPでは、標準化されたソフトウェア・ホーム（ゴールド・イメージ）のスペース効率に優れたリポジトリが保持され、任意の数のターゲット・マシンにプロビジョニングできます。指定したゴールド・イメージから、任意の数のホームをプロビジョニングできます。また、Oracle FPPには系統情報が保持されているため、デプロイしたソフトウェアの来歴を常に確認できます。
上記を含む機能を備えるOracle FPPは、ソフトウェアの理想的な高速パッチ適用システムであり、オンプレミスでもOracle Cloudでも使用されます。Oracle FPPはOracle Autonomous Databaseによって使用され、パッチ適用プロセスを完全に自動化します。Oracle FPPはOracle RACライセンスに含まれているため、オンプレミスのOracle Databaseでは、同じ機能を追加料金不要で利用できます。
Oracle FPPの詳細については、https://www.oracle.com/database/technologies/rac/fpp.htmlを参照してください。
新世代のOracle RAC オラクルはOracle RACテクノロジーの強化を継続しており、容易さ、スピード、スケーラビリティ、可用性を高めることを目指してきました。飛躍的進歩を遂げたOracle RAC 19cリリースはその集大成であり、次世代のあらゆるワークロードやアプリケーションのニーズに対応します。
Oracle Real Application Clusters 19c
図2：Oracle RAC 19cによるスケーラビリティの向上（左）と高可用性（右）
図2には、Oracle RAC 19cが、過去最高のスケーラビリティと信頼性に富むOracle RACである理由が示されています。Oracle RACはOracle RAC 11g Release 2以降、競合が発生しやすいワークロードへの対応能力を5倍に強化しつつ、クラスタの再構成時とインスタンス障害後の停止時間を、Oracle RAC 11g Release 2とOracle RAC 12c Release 2との間で4分の1に短縮しました。Oracle RAC 12c Release 2とOracle RAC 19cとの間ではさらに3分の2になっています。つまり、Oracle RAC 11g Release 2で1分間停止していたアプリケーションは、Oracle RAC 19cでは障害発生後15秒も経たないうちに完全に動作を再開していることになります。
8 新世代のOracle Real Application Clusters（Oracle RAC）
RACデータベース・インスタンスやサーバーの障害からのリカバリには、クラスタの再構成が必要です。クラスタの再構成中、障害発生時に変更可能だったデータへのアクセスには、インスタンスのリカバリが実行されるまで遅延が発生する可能性があります。RACデータベースで障害の発生したインスタンスのリカバリは、残りのインスタンスのいずれかによって実行されます。Oracle RAC 12c Release 2より前のバージョンのOracle RACでは、このプロセスには障害発生後のリカバリを実行するデータベース・インスタンスの選出や、標準のREDOログの読取りと適用などの5つの手順が発生していました。
Oracle RAC 12c Release 2以降で加えられた改善の1つでは、Recovery Buddy機能によって、その5つの手順のうちの2つが完全に不要になりました。Recovery Buddy機能は、新しいインスタンスの起動時に必ず、リカバリ用インスタンスをあらかじめ割り当てるため、インスタンスのリカバリを実行するインスタンスを選出する必要がなくなります。加えて、インターコネクトを介して、割り当てられたRecovery BuddyインスタンスにREDOログのリカバリ・データを直接送信し続ける新しい機能が導入されました。Buddyインスタンスはこの情報をメモリ内に格納するため、リカバリ実行時にREDOログを読み取る必要がなくなり、新規トランザクションの全データへのアクセスを再度有効にするための時間が短縮されます。
競合の発生しやすいワークロードでのパフォーマンスが5倍向上したことは、いくつかの機能について言及するだけで説明できるものではありません。以下の図3にあるさまざまな機能も、この重大な改善に役立ってきました。図3に挙げられているパフォーマンスを強化するための各機能が、競合の発生しやすいワークロードのパフォーマンス改善にどのように役立ち、貢献してきたかについては、本書では説明しません。
Oracle RACシステム上にあるSAP、オラクルのE-Business Suite、Siebelなどの複雑なアプリケーションや、通常の多くのOLTPおよび分析ワークロードは、シングル・インスタンスのシステムでは垂直方向にスケーリングされると仮定すると、ほぼ直線的なスケーラビリティとなります。世界中のあらゆる業界で、非常に複雑なワークロードを20年以上実行してきたことが、この事実を証明しています。
アプリケーションの拡張率が80 %未満の場合、このアプリケーションでは競合によってパフォーマンスが抑制されていると考えられます。そのような競合の原因は、以下の3つのうちのいずれか、または複数が組み合わされたものです。
1. 同じデータ・ブロックに対して、アプリケーションが頻繁なトランザクション上の変更を実行している（“書込みホットスポット”）。
2. REDOログへの書込みが必要なため、ブロックへの新しい変更が他のインスタンスに配信される速度が遅い（“REDOログの遅延”）。
3. アプリケーションがメタデータでの競合の原因となっている（“Right Growing Indexとインデックスの競合”） • OLTPの書込みホットスポットの大半はインデックスで発生。
Oracle RAC 19cはさまざまな機能を利用して、こうした競合の原因によるパフォーマンスへの影響を大幅に減らしています。
図3：パフォーマンスを強化するための各リリースでのOracle RACの機能
9 新世代のOracle Real Application Clusters（Oracle RAC）
エンジニアド・システム - Oracle RACを念頭に置いた設計
10年以上前にオラクルは、高いパフォーマンスと堅牢なデータベース・インフラストラクチャを実現する新しい戦略を打ち立てました。これは通常、Oracleエンジニアド・システムと呼ばれています。オラクルのエンジニアド・システムは、あらかじめ構成、調整、テストされた、サーバー、ネットワーク、ストレージの統合システムで、Oracle Databaseを念頭に置いて最適化されています。もっとも重要なエンジニアド・システム製品は、Exadata Database Machine（Exadata）とOracle Database Appliance（ODA）の2つです。この2つのシステムのうち、ODAの方がシンプルで、おもにOracle RACの展開を簡便化するために設計されています。ODAのハードウェアは、設定不要でRAC対応となっており、ODAのツールがオペレーティング・システム、ファームウェア、Oracle Clusterware、Oracle RACデータベース・ソフトウェアの展開とパッチ適用を調整します。Exadataはスケーラビリティが高くパフォーマンスに優れた製品で、一般的なハードウェア・システムにデータベースを展開している場合には利用できない多数の機能を備えています。
Exadataはオラクルが推奨するプラットフォームで、OLTP、DWH、レポート作成、バッチ処理、統合、データベースの混合ワークロードなどのデータベース・アプリケーション向けに非常に優れたパフォーマンスを発揮します。Oracle Exadataは費用対効果と可用性が高く、サポートが充実しています。Oracle Exadataによって、ユーザーはシステムを構築、テスト、メンテナンスする必要がなくなり、より重要なビジネスの問題に注力できます。さらに、オラクルはExadata Database Machineで必要なあらゆるものを提供し、統合しているため、独自のソフトウェア機能を多数開発することができ、一般的なプラットフォームにはない利点を備えています。
Exadataのスケールアウト・アーキテクチャ Oracle Exadata Database Machineは、データベース・サーバーとストレージ・サーバーの両方で、スケールアウト・アーキテクチャを採用しています。Oracle Exadata Database Machineが拡大するのに伴って、より多くのデータベースのCPU、ストレージ、およびネットワークをバランスよく追加し、ボトルネックのないスケーラビリティを維持できます。Exadataは、ストレージ層でのスケールアウト・コンピューティングによってOracle RACのスケールアウト・データベース・コンピューティングを補完し、データ処理が集中するオペレーションを高速化します。ストレージ・コンピューティングのスケールアウトは、アプリケーションに対してシームレスかつ透過的に機能します。
Oracle Exadataアーキテクチャは、Oracle Database管理システム向けに構築されています。多くのOracle Databaseがリリースされていくにつれ、中核となっているデータベースに機能や特徴が追加され、Exadataアーキテクチャの多彩な能力が活用されています。Oracle Exadata Database MachineとOracle Databaseとで併せて使用できる相乗的な機能には、ストレージ索引付け、ストレージ・サーバーによるSQLオフロード処理、Hybrid Columnar Compression、Smart Cache Flashなどがあります。これらの機能がシングル・インスタンスのデータベースとOracle RACデータベースにメリットをもたらす一方で、データベースとExadataには、Oracle RACデータベースに独自の利点を持ついくつかの改良点があります。
Oracle RACに役立つExadataの拡張機能 Exadata Instant Failure Detection
調整されたクラスタとして動作する、複数の独立したサーバーで構成されているOracle RACシステムは、クラスタ内のサーバーの障害を迅速に検知し、リカバリしなければなりません。そのため、Exadataにはノードの障害を検出し、わずか2秒で再構成できる、複数の拡張機能が組み込まれています。この機能を設計できたのは、オラクルがExadataでエンド・ツー・エンドのデータベースとネットワーク・インフラストラクチャを制御してきた結果です。
キャッシュ・フュージョンの拡張機能
Oracle RACのパフォーマンスは、基盤となっている通信の速度に左右されます。ExadataのOracleキャッシュ・フュージョンには、Exadataの遅延時間の少なさと、広帯域クラスタのインターコネクトによるメリットがあります。さらに、ExadataにはExafusionネットワーク・プロトコルが実装されており、オラクルのプロセスはオペレーティング・システムのカーネルをバイパスして、データベース・サーバー間のRDMAの読取りと書込みを直接実行できます。これで、プロセスではネットワーク・スタックの横断とコンテキスト・スイッチの増加によるオーバーヘッドがなくなるため、パフォーマンスが劇的に改善されます。
10 新世代のOracle Real Application Clusters（Oracle RAC）
Exadataのみで利用できるキャッシュ・フュージョンの最適化には他にも、Exadataコミット・キャッシュがあります。この機能はインメモリ・キャッシュで、RDMAプロトコルを使用して、トランザクションのコミット回数を記録します。RACデータベースのインスタンスは、実行中のトランザクションでデータの整合性を維持する必要があり、他のデータベース・インスタンスが同じデータをアクティブに使用している場合もそれが当てはまります。Exadataで使用されている最適化機能は、コミット・キャッシュを利用して、最初のデータベース・インスタンスが何らかのUNDOデータを読み取る必要があるかどうか、迅速に判断します。一部のワークロードでは、UNDOデータのデータ・ブロック・トラフィックは、この機能のおかげで60 %削減されました。
インメモリのフォルト・トレランス
Oracle Database In-Memoryでは、インメモリの列およびベクトル処理を実行するデータベース機能が既存のデータベースに提供され、分析を桁違いのレベルで透過的に加速させながら、混合ワークロードのOLTPを同時にスピードアップさせます。Oracle RACデータベースなどの既存のデータベースにOracle Database In-Memoryを展開するのは簡単で、アプリケーション変更のための要件はありません。
一般的なOracle RAC構成でデータベース・インスタンスに障害が発生した場合は、そのインスタンスのインメモリのデータが利用できなくなります。問合せは、存続しているデータベース・インスタンスで引き続き実行できますが、データをストレージからインメモリに再移入するには時間がかかり、その間、分析問合せの実行速度は著しく低下します。Exadataにはこれに対処するため、RACクラスタのインスタンスで任意でデータを複製して速度低下を防止する、Oracle Database In-Memoryのフォルト・トレランス・バージョンがあります。ストレージ・サブシステムがディスク全体にデータをストライプ化およびミラー化して高パフォーマンスと高可用性を実現するのと同様に、Oracle Database In-Memoryも、Exadata Database MachineのRACインスタンス全体にインメモリ・データを分散させて複製します。その結果として、サーバーやデータベース・インスタンスに障害が発生しても、インメモリの問合せでは、存続しているサーバー上にある複製されたデータ・コピーが透過的に使用されます。
Smart Fusion Block Transfer
REDOログの競合の影響下にあるOLTPワークロードでは、Exadata Smart Fusion Block Transferの機能が、REDOログの書込み遅延の影響を排除することで、パフォーマンスが向上します。保留中のREDO情報がディスクにフラッシュされてからでないと、ダーティ・ブロックをリモート・インスタンスに送信できない一般的なシステムとは異なり、Exadata上のOracle RACは、ストレージへのI/Oが開始されるとすぐに、ストレージ層からの確認を待たずにブロックを送信できます。他のプラットフォームと比較すると、この最適化によってスループットが40 %増加し、応答時間が33 %減少します。
図4：ExadataベースのOracle RACの改善点とパフォーマンスへの影響の概要
11 新世代のOracle Real Application Clusters（Oracle RAC）
Oracle CloudへのOracle RACの利点の拡張
Oracle RACは、オラクルのクラウド製品で重要な要素の1つとなっています。Oracle RACはOracle RAC Database Cloud Service（DBCS）、Oracle Exadata Service、Autonomous Databaseで使用できます。Oracle RACはOracle SaaSの基盤となっているデータベース・インフラストラクチャの一部でもあります。オンプレミスのOracle RACを展開する数千社がすでに経験している優れたパフォーマンスと可用性を同じように実現しながら、Oracle CloudでOracle RACデータベースを実行できるようになりました。これらのデータベース・サービスは、オンプレミスで展開されているデータベースと100 %の互換性があるため、Oracle Cloudへの円滑な移行が保証され、効率的なハイブリッド・クラウド戦略が遂行されます。
Oracle RAC構成をOracle Cloudに展開する場合、オンプレミスの展開の場合と同じように、ClusterwareやASMなどのRACインフラストラクチャの基盤となっているコンポーネントがすべて利用されます。相違点は、Oracle CloudでOracle RACを展開すると、高度に自動化されていて、数分で完了することです。
オラクルは、Oracle RACを完全にサポートするインフラストラクチャを構築している唯一のクラウド・ベンダーです。この手順には、仮想マシン間でのストレージの効率的な共有や、Oracle RAC対応ネットワーク・インフラストラクチャの提供が含まれます。このような理由により、Oracle RACはオラクルのクラウドのみでサポートされています。クラウド・インフラストラクチャでのOracle RACの展開に関する詳細については、MOS note 2093394.1を参照してください。
Oracle RACとAutonomous Database ミッション・クリティカルなアプリケーションで必要とされる高可用性とスケーラビリティを確保するために、オラクルは自社の旗艦となるデータベース・クラウド・サービス、つまりAutonomous Database Service（以下の図5を参照）の基盤にOracle RACを選定しました。
図5：Autonomous Databaseを下から支えるOracle RAC
Exadata上のOracle RACは、Autonomous Databaseで実行されるワークロードを透過的にスケールアウトします。Oracle RACの構成と運用に関わるすべての面が完全に自動化されています。相当数のCPUを使用して実行されるデータベースは、Oracle RACクラスタの複数のサーバーで稼働するように自動的に構成されます。Oracle RACのローリング・パッチ適用およびアプリケーション・コンティニュイティは、サーバー、OS、Clusterware、データベースのメンテナンス中にアプリケーションが停止するのを回避するために使用されます。クラスタの複数ノードに広がることで競合の原因となる可能性があるアプリケーション・モジュールは、接続文字列にコロケーション・タグを使用することで、同一のインスタンス上で稼働するように構成できます。
12 新世代のOracle Real Application Clusters（Oracle RAC）
Oracle RACと他のスケールアウト・データベースによるアプローチの比較
現在市場で入手できるデータベースの多さと、そうしたデータベースで使用できる高可用性およびスケーラビリティに富む多様なソリューションについて考えると、Oracle DatabaseとReal Application Clustersを選択するべき理由は何だろうか、という疑問が浮かびます。この質問に対する答えはシンプルです。オラクルは、スケーラビリティと可用性を備える既存の全アーキテクチャから、もっとも優れた部分を独自の方法で組み合わせ、あらゆる種類および規模のアプリケーションのニーズに対応します。
データベースの高可用性およびスケーラビリティ・ソリューションは、表1に挙げられているアプローチを使用して、詳細にカテゴリ分けできます。
表1：データベースの高可用性およびスケーラビリティ・ソリューション - 詳細なまとめ
テクノロジー 利点 欠点 Oracle RACとの比較
クラスタ・フェイルオーバー - 現在データベースが稼働している
サーバーで障害が発生すると、
データベースの実行は他のサー
バーで行われます。
使用と実装は比較的簡単です。 シンプルなソリューションでは、
スケーリングや透過的なメンテナ
ンスができません。
Oracle RACは優れたスケーラビ
リティ、非常に高速なフェイル
オーバー、透過的なメンテナンス
により、フェイルオーバー・クラ
スタ機能のスーパーセットとなっ
ています。
シェアード・ナッシング - データ
ベースは、ストレージを共有しな
い複数のコンピュータ上で透過的
に動作します。
共有ストレージを実装することな
く、複数のノードにスケーリング
できます。分析ワークロードに適
しています。
メッセージングとトランザクショ
ンの調整コストが高くなるため、
OLTPワークロードではパフォー
マンスとスケーラビリティが低下
します。 多数の表やインデックスへのスケ
ーリング機能が不足しているた
め、ERP、CRM、HCMなどの複
雑なアプリケーションでは適切に
動作しません。
シェアード・ナッシングの優れた
面と、共有ストレージの優れた面
が組み合わされています。 シェアード・ナッシングと同様の
方法でSQLのファンクション・シッピングを使用し、クラスタの
ノード全体で長時間実行のSQLを自動的にパラレル化します。その
ため、分析ワークロードとバッチ
を、ノード間で透過的にスケーリ
ングできます。
データ・シッピングと分散キャッシュを使用して、応答時間を短く
し、非常に複雑な（ERP）アプリ
ケーションであっても、OLTPワークロードを透過的にスケーリ
ングします。
データベース・シャーディング - シャーディング・キーに基づいて
ルーティングされるリクエストを
使用し、複数の物理データベース
から、論理データベースが構築さ
れます。
物理データベースが独立している
ため、高いスケラービリティを実
現し、障害を分離できます。
アプリケーションへの透過性があ
りません。 適切に動作するのは、シャーディ
ング・キーでパーティション化可
能なアプリケーションのみです。 クロス・シャードの操作に十分対
応していないか、まったく対応し
ていません。
非常に複雑な（ERP）アプリケー
ションでは機能しません。 分析に十分対応していないか、
まったく対応していません。
オラクル・ネイティブなデータ
ベース・シャーディングは、複数
の物理的なOracle Databaseでシャーディングを実装し、シャー
ディング・キーを使用してパー
ティション化可能なアプリケー
ションで最高のスケーラビリティ
を確保し、障害を分離します。
Oracle RACは、シャーディングさ
れた各データベース内で使用で
き、高可用性を確保し、シャード
の計画メンテナンスを実行して、
双方のテクノロジーのメリットを
結びつけます。
13 新世代のOracle Real Application Clusters（Oracle RAC）
テクノロジー 利点 欠点 Oracle RACとの比較
マスター-スレーブ・レプリケー
ション - マスター・データベース
から1つまたは複数のスレーブ・
データベースにレプリケーション
されるデータ。
災害からの保護やフェイルオーバー
に役立ち、一部のソリューションで
は読取りのスケーラビリティが確保
されます。
書込みのスケーラビリティはありま
せん。 通常、フェイルオーバー時に一部の
データが失われます。 読取りレプリカでは一般的に、デー
タ整合性が失われます。 接続とユーザーのスケーラビリティ
に難があります。 レプリカ間での分析のスケーラビリ
ティはありません。
Oracle RACの透過的なスケーラビ
リティとフェイルオーバーを、レプ
リケーションによる災害からの保護
と組み合わせることで、双方の優れ
た点を活用できます。 Oracle Active Data Guardは、レプ
リカ・データベースを使用して、
またOracle Database 19cではレプ
リカ・データベースでの透過的
アップデートを使用して、読取り
のスケーラビリティを高めること
ができます。
アクティブ-アクティブ・レプリ
ケーション - 完全にアクティブな
複数のデータベースでデータをレ
プリケーションします。
非常に高い可用性、災害からの保
護、優れた読取りのスケーラビリ
ティ。
複数レプリカへの書込みによって、
競合やデータ整合性の問題が生じる
可能性があります。 アプリケーションへの透過性があり
ません。
データベース（ファイル）のコピー
が複数必要です。 レプリカ間での分析のスケーラビリ
ティはありません。
各レプリカ内でOracle RACを使用
することで、書込みのスケーラビ
リティと分析のスケーラビリティ
が確保され、レプリカ数が減るた
め、競合の回避に役立ちます。
業界屈指のOracle GoldenGateレプ
リケーションは、Oracle RACに完
全に統合されています。
この考察から分かるように、Oracle RACは独特の方法で、OLTP、分析、および混合ワークロードのどのような組合せに対しても、高い可用性とスケーラビリティを提供し、オラクルのネイティブなシャーディング、Data Guard、レプリケーション・テクノロジーとシームレスに統合されて、ディザスタ・リカバリや、より一層優れたスケーラビリティ、可用性を実現します。Oracle RACは、最新のあらゆるデータベース・アーキテクチャのもっとも優れた属性を実装しつつ、それらの持つ欠点を最小化したり、排除したりします。
14 新世代のOracle Real Application Clusters（Oracle RAC）
結論
オラクルは長年、Oracle Real Application Clusters（Oracle RAC）の開発と強化に投資し、ミッション・クリティカルなアプリケーションで必要とされる透過的データベースの可用性とスケーラビリティを実現してきました。このテクノロジーは業界でも特異なもので、世界の大手企業の多くで、社内アプリケーションと顧客が使用する重要なアプリケーションの双方で使われています。
オラクルは先般、Oracle RACアーキテクチャを大きく改善し、ほんの数年前と比べても、アプリケーションの可用性とスケーラビリティが何倍も向上しています。同時に、そのような改善点によってRACテクノロジーは新しい世代を迎え、次世代のワークロードおよびアプリケーションのニーズを満たす準備ができています。
Oracle RACを念頭に置いて設計されているExadata Database Machineなどのエンジニアド・システムは、かつてないほどのレベルで、高可用性とスケーラビリティを大幅に改善します。同時に、エンジニアド・システムによってOracle RACシステムの展開と管理が容易になります。
Oracle Cloud、特にオラクルのAutonomous Databaseは、Oracle RACとエンジニアド・システムを十分に活用して、市場で入手できる最高のデータベース・サービスを提供しています。Oracle CloudもOracle RACの展開と管理を簡素化するため、展開の環境が大規模であっても簡単かつ効率的に管理できます。
Oracle RACのオンプレミスおよびOracle Cloudアーキテクチャの一部であるアプリケーション・コンティニュイティやFleet Patching and Provisioningなどの機能を利用することで、そうした管理タスクを完全に自動で実行することも可能であり、さらに重要な点として、アプリケーションやユーザーに対して透過的に実行することができます。
つまり、Oracle RACデータベースはミッション・クリティカルなアプリケーション環境に最適です。ミッション・クリティカルなアプリケーションでは、高可用性、動的なスケーラビリティ、アプリケーションの変更が不要であることが最重要な要件となりますが、これらはOracle RAC、特にOracle RAC 19cで完全に対応可能です。
ORACLE CORPORATION
Worldwide Headquarters 500 Oracle Parkway, Redwood Shores, CA 94065 USA
海外からのお問い合わせ窓口 電話 + 1.650.506.7000+ 1.800.ORACLE1 FAX + 1.650.506.7200 oracle.com
オラクルの情報を発信しています
+1.800.ORACLE1までご連絡いただくか、oracle.comをご覧ください。北米以外の地域では、oracle.com/contactで最寄りの営業所をご確認いただけます。
blogs.oracle.com/oracle facebook.com/oracle twitter.com/oracle
Copyright © 2020, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載されている内容は予告なく変更
されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律による黙示的保証を含め、商品
性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません。オラクルは本文書に関するいかなる
法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得
ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。
OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
IntelおよびIntel XeonはIntel Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の商標ま
たは登録商標です。AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。UNIXは、The Open Group
の登録商標です。0120
新世代のOracle RAC
Oracleホワイト・ペーパー | 2020年1月
