サービスレベルに応じてデータベースの可用性を確保する「Oracle Maximum Availability Architecture」とは何か？：データベースクラウドに求められる3つの要件（1）（2/4 ページ）

Oracle Database 12cによるプライベートクラウド環境の構築に際して課題となることの1つが、必要な「可用性」をいかにして確保するかということだ。オラクルは、サービスレベル要件に応じてデータベースシステムの可用性を確保するためのブループリントとして「Oracle Maximum Availability Architecture」を提唱している。[プライベートクラウド/データベース統合][高可用性/災害対策][Oracle Database 12c]

[PR／＠IT]

計画停止／計画外停止の影響を最小化するさまざまなテクノロジー

　Oracle MAAでは、高可用性を実現するために「Oracle Real Application Clusters（RAC）」や「Oracle Automatic Storage Management（ASM）」「Oracle Data Guard」「Oracle GoldenGate」といったテクノロジーの活用を推奨している。これらは、システムに要求される可用性のレベルに応じて適宜、選択／適用すればよい。

　これらのテクノロジーを使うことで、さまざまな障害に対して迅速な復旧が可能となる。例えば、OS障害やハードウェア障害といった単一ノード障害に対しては、Oracle RACを使うことで停止時間を数秒程度に抑えられる他、Oracle ASMを使うことでストレージ障害やデータ破損がアプリケーションに及ぼす影響を最小限にすることができる。

　計画停止においても、これらのテクノロジーが有効だ。例えば、ストレージの容量が不足した場合、オンラインでストレージを追加可能なOracle ASMを利用していれば、データベースを止めることなく容量を追加できる。また、Oracle RACを利用している場合は、ノードごとに作業するローリング方式により、データベースを止めることなくメンテナンスやパッチ適用（一部のパッチを除く）が行えるのだ。

拡張性と可用性を高いレベルで実現するテクノロジー

　こうしたメリットをもたらすOracle MAAにおいて、中核的な役割を担うのがデータベースをクラスタ化するOracle RACと、ストレージ仮想化のOracle ASMである。以下に、それぞれの特徴を詳しく見ていこう。

　Oracle RACは、データベースを複数のノードで実行することにより、高い可用性と拡張性を実現し、さらに投資コストの最適化を実現するテクノロジーである。

　一般的なHA（High Availability）構成では、データベース環境をアクティブなプライマリ環境とスタンバイのセカンダリ環境で二重化し、プライマリ側に障害が発生した際にはセカンダリ側に切り替えることで可用性を確保する。この構成の問題点の1つは切り替えに時間がかかることであり、データベースの再起動やディスクの切り替えなどの作業が必要となるため、どうしても数分から数十分のダウンタイムが発生してしまう。

　一方、Oracle RACでは、全てのノードがアクティブとなり、いずれかのノードに障害が発生すると、そのノードの処理を別のノードが引き継ぎ、そのまま継続して稼働する。これらの引き継ぎ処理にかかる時間は数十秒から数分程度であり、一般的なHA構成よりも回復が速いというメリットを備える。

　拡張性の高さもOracle RACの強みの1つだ。一般に、データベースサーバのCPU能力やメモリが不足した際には、ハードウェアのリプレースで対処する。それに対して、Oracle RACでは、新たにノード（サーバ）を追加するスケールアウトのアプローチで処理能力を高められるため、ハードウェアを全て入れ替える必要はない。

　また、スケールアウトによる能力増強が可能であることから、最初は最小規模のクラスタ構成でスタートし、必要に応じてノードを追加しながらシステム全体の性能を高めていくことができる。スタンバイ環境が不要なため、投資を無駄にせず、サーバ資源を有効に活用できることも見逃せないメリットだ。

　なお、以前のOracle RACでは、基盤となるOracle Clusterwareをデータベースごとにインストールする必要があり、それぞれのOracle RAC環境間でのリソースの再配置が難しいという課題があった。しかし、Oracle Database 11g R2以降では、基盤の統合により複数システム間で柔軟にサーバリソースを融通できる仕組みが整備された。これにより、時間帯や負荷に応じてデータベースに割り当てるサーバリソースを振り分けられるようになり、例えば「日中の営業時間帯はOLTPに、夜間は集計処理用のデータベースに多くのリソースを割り当てる」といった運用が可能となっている。