16:00:00ツイート印刷コメントを書くビッグデータ時代とも呼ばれる昨今、社内外のさまざまなデータを活用してビジネス上の価値を引き出したり、あるいはビジネス機会を補足したりするうえで、「常にデータにアクセスできること」の重要性はますます高まっている。アプリケーション・サーバからデータベースへの接続に関しても、従来のようにデータベースを二重化するだけではもはや不十分だ。いずれかのノードが故障した際、それをアプリケーション・サーバ側で素早く検知できなければ、結局はシステム停止時間が長引いてしまう恐れがある。RAC」の活用を提案している。その概要、利点を紹介しよう。MAA企業の事業活動のさまざまな領域でITが活用されるようになったことに伴い、企業システムを構成するハードウェアの故障やソフトウェアのトラブルなどによるシステムの停止が事業活動に及ぼす影響も年々大きくなってきた。ビッグデータ時代とも呼ばれ、社内外のデータのリアルタイムな活用が企業の競争力に大きくかかわるようになってきた今日、障害などによるシステムの停止は、企業の業績そのものを大きく左右しかねない状況となっている。そこで重要性を増しているのが「システムの可用性」だ。Failure)を解消するといった対応が図られることも珍しくなくなっている。場当たり的な対処では、真の意味で高可用性を実現することはできない。MAAでは、ハードウェア障害やネットワーク障害、データ不整合、あるいはヒューマン・エラーなど、ミッション・クリティカル・システムの安定運用を阻害するさまざまな障害を想定し、それぞれについて適切な対策を講じることによってシステムの高可用性を確保する。Clusters(RAC)」を利用してデータベースをアクティブ/アクティブで冗長化することにより、いずれかのノードに障害が発生した場合でも、残りのノードで処理を継続することを可能にする。Management(ASM)も利用する。Databaseの連携にも、高可用性を実現するためのテクノロジーを組み込んでいる。Servicesに接続フェイルオーバーの仕組みが備わっており、RACインスタンスの1つに障害が発生すると、自動的に別のインスタンスに接続先が切り替わる。データベースにその都度接続するタイプのアプリケーションならば、この機能を使うことでインスタンス障害に対応することができる。アプリケーション・サーバの場合、その都度コネクションを張るのではなく、起動時にあらかじめ複数のコネクションを生成してプールに格納し、それを使い回す「コネクション・プーリング」の仕組みを使うのが一般的である。これにより、データベースに接続する度にコネクションを生成し、処理が完了したら切断するといった接続/切断の繰り返しに伴うリソースの浪費を防ぐわけだが、反面つなぎっぱなしになるため、データベースの障害を検知できないという問題がある。そのため、障害を検知してコネクションを張り直すための仕組みを何らかのかたちで用意しなければならない。具体的な実装方法としては、大別して2つの方法が考えられる。1つは、一定時間データベースへのアクセスがないタイミングを利用して、コネクションの死活を確認する方法。2つ目は、SQLを発行する前に、その都度コネクション確認用のSQLを発行するという方法だ。これらはいずれも、決して確実な方法とは言えない。始終データベースにアクセスするアプリケーションの場合、1つ目の方法ではインスタンスの死活を確認するタイミングがないため、結局は障害を検知することができない。2つ目の死活確認用SQLを毎回発行する方法ならば確実に障害を検知できるが、それによるSQLがデータベースの負荷を増大させてしまうというジレンマが生じる。RACさらに、RACを利用する際に考慮すべき問題として、それぞれのコネクションが、どのRACインスタンスに接続しているのかを把握できないことが挙げられる。RACインスタンス1から3までの3つのインスタンスがあり、インスタンス1に障害が発生したとしよう。このとき、コネクション・プール内のコネクション群のうち、どれがどのRACインスタンスに接続しているのかを把握していて、なおかつインスタンス1に障害が発生したことを検知できれば、該当のコネクションのみクローズし、インスタンス2やインスタンス3に接続するコネクションはそのまま生かすといった対処がとれる。コネクションとRACインスタンスの関係を把握できない場合、その必要がないコネクションについても「クローズ→再生成」を行ってしまい、エラーの発生や処理性能の低下を招く恐れがある。Failover(FCF)」という仕組みが備わっており、これによってダウンタイムを最小限に抑えている。Service」との連携で実現している。RACはこの通知を受け取ることによって障害を検知する。これにより、データベース側の障害を発生時点で即座に検知できるとともに、コネクション確認用のSQLが不要になるため、データベースの負荷の軽減も図れるというわけだ。RACで生成されるコネクションは、自分が現在どのインスタンスに接続しているのかを把握している。RAC側のインスタンスに障害が発生した場合でも、そのインスタンスに接続しているコネクションだけをクローズし、稼働中の他のインスタンスに接続するコネクションを再生成できるのだ。した仕組みにより、インスタンス障害が発生しても素早くそれを検知し、回避できるとともに、性能劣化の抑制が可能となっているわけだ。Serverの販売パートナーであるNECが技術検証を行っており、実際にパブリック・ネットワーク障害やインター・コネクト障害が発生した際、どの程度の時間で復旧できるのかが明らかになっている。その結果によれば、FCFを使わなかった場合はパブリック・ネットワーク障害で9分30秒、インター・コネクト障害で5分の時間をエラー検知に要していた。これがFCFを用いた場合は、それぞれ15秒、33秒にまで短縮できたという。リアルタイム性が要求されるシステムにおいて、この検知時間の差は極めて大きいのではないだろうか。RAC環境をもう1つスタンバイ環境として用意して冗長化するというケースもあるだろう。RACの障害を検知し、接続先をスタンバイ環境に速やかに切り替えられなければ意味がない。RACを組み合わせることで、データベース環境にトラブルが発生しても迅速にリカバリして処理を継続する仕組みが実現されている。高い可用性が求められるシステムでは、ぜひこれらの機能の活用を検討していただきたい。お試しいただけるトライアル・サービスをご提供しております。permission.×このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。