ゼロから理解する「Oracle RAC」：ゼロからのリレーショナルデータベース入門（7）（2/2 ページ）

Oracle RACの仕組み

　Oracle Databaseでは、（読み書き速度がメモリより劇的に遅い）ディスクI/Oの発生を抑えるために、データを参照、更新時に「データベース・バッファ・キャッシュ」と呼ばれるメモリ領域にデータをキャッシュすることで効率を高めています。また、キャッシュ上で変更されたデータについても、すぐにディスク上のデータベースには反映しない「遅延書き込み」と呼ばれる機能を実装しています。

　では、“複数”のインスタンスで1つのデータベースを管理するOracle RAC構成ではどうするのでしょう。あるインスタンスで更新した内容を、別のインスタンスでも同様に参照できるようにする「データの一貫性を保つ仕組み」が必要になってきます。

　Oracle RACでは、これを「キャッシュフュージョン（Cache Fusion）」と呼ばれる機能によって実現しています。

データの一貫性を保つ「キャッシュフュージョン」とは

　キャッシュフュージョンを利用してデータ一貫性を実現する仕組みを理解しましょう。

　インスタンスAとインスタンスBへほぼ同時に異なる変更要求があった場合、Oracle RACの構成では、以下のようにデータが処理されます。

• 1：「インスタンスA」に接続したユーザーが、「リンゴ」を「ミカン」のデータへ変更するよう要求する
• 2：インスタンスAは、データファイルから「リンゴ」データが含まれるデータブロックを読み込む（図5）

図5　インスタンスAは、データファイルから「リンゴ」データが含まれるデータブロックを読み込み、インスタンスAのデータベース・バッファ・キャッシュに確保する

• 3：インスタンスA上に確保したデータブロックの「リンゴ」が「ミカン」に更新される（図6）。更新内容は、「遅延書き込み」機能により、すぐにデータファイルには反映されない

図6　インスタンスAは、自身のシステムグローバル領域（SGA）のデータベース・バッファ・キャッシュにあるデータを、リンゴから「ミカン」に変更する

• 4：その後、インスタンスBに接続したユーザーが、インスタンスAで更新した同じデータブロック内の「バナナ」を「ブドウ」に変更するよう要求する
• 5：ただし、インスタンスAはインスタンスBから要求されたデータブロックを保持している。そのため、インスタンスAは変更済みデータブロックを「REDOエントリ」としてREDOログ・ファイルに書き出す
• 6：インスタンスAは、変更内容（ミカンに変更）を含んだデータブロックをインスタンスBに送信する（図7）

図7　インスタンスAは変更内容をREDOログ・ファイルに書き出した上で、変更内容を含めたデータブロックをインスタンスBに送信する

• 7：インスタンスBは、該当するデータブロックをインスタンスAから受信したデータを基に、自身の変更要求である「バナナ」を「ブドウ」に変更する（図8）。

図8　インスタンスAから受信した変更済みデータを基に、インスタンスBはキャッシュ内のデータを変更する

　このような流れで、ディスクへの反映を待たずともデータの一貫性が保たれるように動作します。シングルノードやフェイルオーバー型のクラスタリングで動作するインスタンスと、Oracle RACの大きな違いはこの「キャッシュフュージョン」の部分です。

　Oracle RAC構成は、複数のインスタンスで1つのデータベースを管理しており、各インスタンスはそれぞれ独立した共有メモリ、バックグラウンドプロセスを保持しています。これに加えて、各インスタンスで処理される「トランザクションも独立」しています。そのため、変更履歴を保持するオンラインREDOログのグループや、変更前情報を保持するUNDO表領域がインスタンスごとに必要となります（図9）。

図9　Oracle RACの物理構成

Oracle RACの構築で考慮すべき「3つ」のポイント

　前述したように、Oracle RACは可用性、負荷分散、拡張性を実現するロードバランス型のクラスタリング構成です。そのため、Oracle RACを構成するサーバやストレージなどのハードウェアも可用性、負荷分散、拡張性に優れた構成でなければ、そのメリットを十分に生かせません。

　ここでは、Oracle RAC構築時に考慮してほしい3つのポイントを紹介します。

ポイント1：単一障害点をなくす

　Oracle RACに限らず、クラスタ全体の可用性は「単一障害点の有無」によって決まります。単一障害点とは、ある1箇所の障害がシステム全体の障害につながってしまう弱点箇所のことです。「SPOF（Single Point of Falure）」とも呼ばれます。単一障害とならないよう、要所を冗長化（多重化）したりします。

　全体最適の考え方からも単一障害点は極力なくすべきですが、全て対策するのは困難でしょう。「どのレベル」で障害点となる箇所を冗長化してシステムダウンを起こりにくく対策するかを考えることが重要です。併せて、故障箇所の与える影響や復旧に要する時間も考慮しておく必要があります。

　軸となるポイントは、「Oracle RACとしてのサービスを継続する」ことです。ハードウェアの冗長化によってすぐに復旧できる障害なのか、あるいはOracle RACによってすぐに復旧できる障害なのか。万が一障害が発生したときに、Oracle RAC環境がどんな挙動をするのかを把握した上でハードウェア構成を検討することが必要になるでしょう。

ポイント2：シンプルな構成を目指す

　Oracle RAC構成も、障害時の復旧作業や定期的なメンテナンス作業を考慮した上で、可能な限りシンプルな構成にすることが推奨されます。

　ハードウェアを冗長化したとしても、必ずシステムの可用性が高まるわけではありません。ハードウェア部品が多ければ、その分故障発生リスクが増えることになります。また、冗長化による複雑な構成は人為的ミスを誘発する可能性も高くなります。

ポイント3：リソースの仮想化を有効に利用する

　24時間365日の高可用性を必要とするシステムの場合は、ハードウェアリソースをクラウドサービスを用いて仮想化することによって、柔軟かつ動的な拡張が可能になります。例えばストレージ装置の仮想化技術を有効に使えば、ビジネスの成長や急な需要増などに応じて、データファイルの配置領域を柔軟に拡張していけます。初期コストを抑えながら、将来を見据えた柔軟なシステムを構築できる手段といえます。

　もっとも、単にストレージレベルの領域拡張を行う機能というよりかは、「データベースサーバとして使用する」上で柔軟に対応可能な仮想化技術であるかどうかを見極めるようにするとよいでしょう。

まとめ

　2017年3月現在、Oracle RAC構成は比較的安価に実現できるようになっています。クラスタリング構成のスタンダードな選択肢としてOracle RAC構成は既に広く普及しており、またアクティブ−スタンバイ型のRAC One Nodeの登場により、片方だけのライセンスでも利用可能になりました。例えば、「ライセンスコストを抑えながら可用性を確保したい場合」の選択肢として採用するケースも増えています。

　さらに、Oracle Database専用アプライアンスである「Oracle Exadata」や「Oracle Database Appliance」などでも高可用性＋高性能のためのデータベース基盤としてOracle RACが活用されています。こういったところからも、構築コスト、ライセンスコスト、ランニングコストを抑えつつ、可用性と拡張性を両立できる方法として、Oracle RACはかなり身近な存在になったといえるでしょう。