「データベースへのアクセスを止めない」──WebLogic ServerでOracle RACの障害を検知し、システム停止を防ぐOracle MAA

Oracle Java & Developers編集部
2013-07-26 16:00:00
  • このエントリーをはてなブックマークに追加

ビッグデータ時代とも呼ばれる昨今、社内外のさまざまなデータを活用してビジネス上の価値を引き出したり、あるいはビジネス機会を補足したりするうえで、「常にデータにアクセスできること」の重要性はますます高まっている。アプリケーション・サーバからデータベースへの接続に関しても、従来のようにデータベースを二重化するだけではもはや不十分だ。いずれかのノードが故障した際、それをアプリケーション・サーバ側で素早く検知できなければ、結局はシステム停止時間が長引いてしまう恐れがある。オラクルが提唱する企業システムの高可用性アーキテクチャ「Oracle Maximum Availability Architecture(MAA)」では、この課題の解消策としてWebLogic Serverの「Active GridLink for RAC」の活用を提案している。その概要、利点を紹介しよう。

ミッション・クリティカル・システムの高可用性を実現するアーキテクチャOracle MAA

 企業の事業活動のさまざまな領域でITが活用されるようになったことに伴い、企業システムを構成するハードウェアの故障やソフトウェアのトラブルなどによるシステムの停止が事業活動に及ぼす影響も年々大きくなってきた。特にビッグデータ時代とも呼ばれ、社内外のデータのリアルタイムな活用が企業の競争力に大きくかかわるようになってきた今日、障害などによるシステムの停止は、企業の業績そのものを大きく左右しかねない状況となっている。

 そこで重要性を増しているのが「システムの可用性」だ。ミッション・クリティカルな業務を担うシステムでは、サーバやストレージ、ネットワークの二重化などにより、単一障害点(Single Point of Failure)を解消するといった対応が図られることも珍しくなくなっている。

 ただし、場当たり的な対処では、真の意味で高可用性を実現することはできない。そこで、高可用性を実現するためのベスト・プラクティスとしてオラクルが提唱しているのがOracle MAAだ。

 Oracle MAAでは、ハードウェア障害やネットワーク障害、データ不整合、あるいはヒューマン・エラーなど、ミッション・クリティカル・システムの安定運用を阻害するさまざまな障害を想定し、それぞれについて適切な対策を講じることによってシステムの高可用性を確保する。

 例えば、データベースのハードウェア障害については、「Oracle Real Application Clusters(RAC)」を利用してデータベースをアクティブ/アクティブで冗長化することにより、いずれかのノードに障害が発生した場合でも、残りのノードで処理を継続することを可能にする。また、ストレージ障害にも対応できるよう、Oracle Automatic Storage Management(ASM)も利用する。このようなかたちで高可用性を実現し、ダウンしない、あるいはダウンしてもすぐに復旧するシステムを実現するのがOracle MAAの狙いである。

 オラクルは、このOracle MAAの一環として、WebLogic ServerとOracle Databaseの連携にも、高可用性を実現するためのテクノロジーを組み込んでいる。その具体例として挙げられるのがActive GridLink for RACだ。

アイドル時を利用した死活確認、SQLでの死活確認によるデータベース障害の検知には、いずれも課題が

 Oracle RACでは、Oracle Net Servicesに接続フェイルオーバーの仕組みが備わっており、RACインスタンスの1つに障害が発生すると、自動的に別のインスタンスに接続先が切り替わる。データベースにその都度接続するタイプのアプリケーションならば、この機能を使うことでインスタンス障害に対応することができる。

 しかし、アプリケーション・サーバの場合、その都度コネクションを張るのではなく、起動時にあらかじめ複数のコネクションを生成してプールに格納し、それを使い回す「コネクション・プーリング」の仕組みを使うのが一般的である。これにより、データベースに接続する度にコネクションを生成し、処理が完了したら切断するといった接続/切断の繰り返しに伴うリソースの浪費を防ぐわけだが、反面つなぎっぱなしになるため、データベースの障害を検知できないという問題がある。そのため、障害を検知してコネクションを張り直すための仕組みを何らかのかたちで用意しなければならない。

 具体的な実装方法としては、大別して2つの方法が考えられる。まず1つは、一定時間データベースへのアクセスがないタイミングを利用して、コネクションの死活を確認する方法。2つ目は、SQLを発行する前に、その都度コネクション確認用のSQLを発行するという方法だ。

 ただし、これらはいずれも、決して確実な方法とは言えない。例えば、始終データベースにアクセスするアプリケーションの場合、1つ目の方法ではインスタンスの死活を確認するタイミングがないため、結局は障害を検知することができない。2つ目の死活確認用SQLを毎回発行する方法ならば確実に障害を検知できるが、それによるSQLがデータベースの負荷を増大させてしまうというジレンマが生じる。

データベースの障害を即座に検知するActive GridLink for RAC

 さらに、RACを利用する際に考慮すべき問題として、それぞれのコネクションが、どのRACインスタンスに接続しているのかを把握できないことが挙げられる。

 例えば、RACインスタンス1から3までの3つのインスタンスがあり、インスタンス1に障害が発生したとしよう。

 このとき、コネクション・プール内のコネクション群のうち、どれがどのRACインスタンスに接続しているのかを把握していて、なおかつインスタンス1に障害が発生したことを検知できれば、該当のコネクションのみクローズし、インスタンス2やインスタンス3に接続するコネクションはそのまま生かすといった対処がとれる。

 しかし、コネクションとRACインスタンスの関係を把握できない場合、その必要がないコネクションについても「クローズ→再生成」を行ってしまい、エラーの発生や処理性能の低下を招く恐れがある。

 Active GridLink for RACには、これらの問題を一挙に解決する「Fast Connection Failover(FCF)」という仕組みが備わっており、これによってダウンタイムを最小限に抑えている。

 まずインスタンス障害の検知については、Oracle RACに備わる「Oracle Notification Service」との連携で実現している。Oracle Notification Serviceは、インスタンス障害などを外部に通知するために用意されたOracle RACの機能であり、Active GridLink for RACはこの通知を受け取ることによって障害を検知する。これにより、データベース側の障害を発生時点で即座に検知できるとともに、コネクション確認用のSQLが不要になるため、データベースの負荷の軽減も図れるというわけだ。

 また、Active GridLink for RACで生成されるコネクションは、自分が現在どのインスタンスに接続しているのかを把握している。つまり、Oracle RAC側のインスタンスに障害が発生した場合でも、そのインスタンスに接続しているコネクションだけをクローズし、稼働中の他のインスタンスに接続するコネクションを再生成できるのだ。こうした仕組みにより、インスタンス障害が発生しても素早くそれを検知し、回避できるとともに、性能劣化の抑制が可能となっているわけだ。

二重化したOracle RAC環境にも対応

 上述したActive GridLink for RACの機能に関しては、すでにWebLogic Serverの販売パートナーであるNECが技術検証を行っており、実際にパブリック・ネットワーク障害やインター・コネクト障害が発生した際、どの程度の時間で復旧できるのかが明らかになっている。

 その結果によれば、FCFを使わなかった場合はパブリック・ネットワーク障害で9分30秒、インター・コネクト障害で5分の時間をエラー検知に要していた。これがFCFを用いた場合は、それぞれ15秒、33秒にまで短縮できたという。特にリアルタイム性が要求されるシステムにおいて、この検知時間の差は極めて大きいのではないだろうか。

 なお、Oracle RAC自体の障害に対応するために、Oracle RAC環境をもう1つスタンバイ環境として用意して冗長化するというケースもあるだろう。しかし、Oracle RAC環境を二重化したとしても、それに接続するアプリケーション・サーバがOracle RACの障害を検知し、接続先をスタンバイ環境に速やかに切り替えられなければ意味がない。

 このように、WebLogic Serverでは、Oracle MAAの一環としてOracle RACとActive GridLink for RACを組み合わせることで、データベース環境にトラブルが発生しても迅速にリカバリして処理を継続する仕組みが実現されている。高い可用性が求められるシステムでは、ぜひこれらの機能の活用を検討していただきたい。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]