データベースの障害対策を考える

ツールを活用して障害を監視・分析する

■4. 障害を未然に防ぐ・障害が起こっても慌てない

　ここまでは、データベース障害が発生した際に役立つ機能について解説してきました。ここからは、障害を未然に防ぐための監視機能と、障害が起こってしまった際に管理者を補助してくれる機能について解説します。

■4.1. きちんと監視することで障害を未然に防ぐ

　障害は、起こってしまった場合の損害を考えると、未然に防ぐことが重要です。自然災害などは防ぐことができませんが、システム障害であれば、通常時にシステムをきちんと監視することで、その兆候をとらえ、未然に防ぐことが可能な場合もあります。ここでは、Oracleの統合運用管理ツールであるOracle Enterprise Managerを活用したシステム監視機能について紹介します。

　Oracle Enterprise Managerは、必要な監視項目を、メトリックとして用意しています（もちろん、ユーザーが定義することもできます）。例えば、ディスク使用率が75％を超えたら管理者にメールで通知する、といった運用が可能です。監視項目として、CPU使用率やディスクの書き込みエラーなどを設定しておくことで、データベースが停止してしまうような事態が起こる前に、管理者が対策を実施できるようになります。

　しかし、システム監視には注意点もあります。OLTP（オンライン・トランザクション処理）の時間帯と、バッチ処理の時間帯によって、アラート（警告）を出すしきい値を変える必要がある、ということです。Oracle Enterprise Managerでは、ベースラインの設定により、こうした、システムの変化に応じた柔軟な監視が可能です。これにより、日中のOLTP処理中のしきい値と、夜間のバッチ処理中のしきい値を異なる値に設定して監視することが可能です（図3-1）。

■4.2. ナレッジを活用して被害を最小限にとどめる

　次に、実際に障害が起こってしまった場面を想定します。障害が起こると、事前に手順などをマニュアル化していても、慌ててしまいます。こうした場面で非常に頼りになるのが、「Oracle Database 11g」で新たに加わった障害解決機能の1つである、データ・リカバリ・アドバイザです。図3-2にあるように、障害の内容を分析した上で、その対処方法をアドバイスしてくれる機能です。この機能によって、事前に想定していなかった障害にも、慌てずに対処することが可能です。

　Oracle Enterprise Managerの監視機能と障害解決機能については、以下の資料をご活用ください。

・GUIでパフォーマンス・チューニング：次世代データベース管理者”DBA2.0”
（http://www.oracle.co.jp/iSeminars/090413_1330/DBA20.pdf）
・Oracle Database 11gでの障害解決機能
（http://www.oracle.co.jp/iSeminars/090616_1100/20090616_infra_EM.pdf）

Oracle Coherenceで障害の影響を回避したユーザー事例も

■5. システム全体でデータベースの障害対策を考える

　ここまでは、データベース”単体”での障害対策という観点で見てきました。ここからは、もう少し対象を広げて、システム全体で障害対策を考えてみます。

　第2回でもお話しした通り、Oracleでは、主に性能向上を目的とした特定用途の製品群を用意しています（http://thinkit.jp/article/1044/3/）。こうした試みの中で登場した製品の1つが、Key-Value型データストアである「Oracle Coherence」です。以下では、興味深い事例として、Oracle Coherenceを活用したことで結果的にデータベース障害を回避したケースを紹介します。

　まず、Oracle Coherenceについて、簡単に紹介します。

　Oracle Coherenceは、複数サーバーを束ねて、各メモリ空間を統合し、仮想的な大規模メモリ空間を提供する製品になります（Oracleでは、データグリッド・ソリューションと呼んでいます）。

　通常の3階層アプリケーション・システムでは、アプリケーションは、データベースにアクセスしてデータの取得や変更などの操作を行います。一方、Oracle Coherenceは、アプリケーションとデータベースの間に入ります。アプリケーションはOracle Coherenceによって作られた仮想的なメモリ空間にアクセスして、データの操作を行います。

　Oracle Coherenceはメモリを最大限に活用するアーキテクチャーなので、高速性が求められる金融機関やWebシステムに、数多く採用されてきました。

　最近では、高速性以外の点に着目されて採用されるケースが増えてきています。今回は、そうした中でデータベースの障害対策に生かされたケースを紹介します。

　自動車関連のWebマーケティング・ソリューション・プロバイダである米Dealer.comは、CRMシステムのパフォーマンス改善のために、Oracle Coherenceを採用しました。アプリケーションからのデータ操作はメモリ上で完結させ、データは非同期でデータベースに反映する仕組みになっています（図3-3）。

　Oracle Coherenceによって処理性能や投資効率の改善という効果が表れましたが、さらなる効果を実感したのが、データベース障害の発生時でした。同社は、3時間にわたるデータベース障害に見舞われましたが、結果としてシステムへの影響はありませんでした。

　データベース障害がシステムに影響を及ぼさなかった理由は、すべての処理がメモリ上で完結する仕組みにあります。もちろん、データベース障害の最中に発生したトランザクションは、データベースの復旧後に、きちんと自動的にデータベースに反映され、失われることはありませんでした。

　このように、アプリケーションとデータベースの間に仮想的な大規模メモリ空間を用意することで、データベース障害にも対応することができるわけです。また、データベースの定期メンテナンス（パッチ適用、バージョンアップなど）の最中にシステム全体を停止するのは避けたい、というニーズでも、Oracle Coherenceを活用いただくケースが増えています。

　また、システム全体の計画停止ということで付け加えると（詳細は後の連載で解説しますが）、「Oracle Database 11g Release2」では、Online Application Upgradeと呼ぶ機能が実装されました。従来であれば長時間のシステム停止が避けられなかったアプリケーションのアップグレード作業やパッチ適用作業を、停止時間ゼロで実施できるようになります。

■今回のまとめ

（a）データベースに関係する障害は非常に幅広い
　システムを構想する段階では、メンテナンスなどの計画外停止までは考慮していないケースも少なくはありません。まずは、携わっているデータベースに関する障害を一通り、洗い出してみましょう。

（b）障害への対策方法は多様であり、その選択肢は増えている
　サーバー障害への対策方法だけでも、仮想化技術をはじめ、さまざまな方法が新たに登場してきています。今回は、個々の障害対策を検討するやり方については解説できませんでしたが、システムのサービスレベルなどに合わせて、適切な対策方法を選択しましょう。

（c）データベース単体ではなく、システム全体で対策方法を考える
　Oracle Databaseでは、ハードウエアを含めた各種の障害に対応できるよう、機能拡張を行っています。しかし、当然ながら、データベース層だけ動いていても、アプリケーションが止まってしまえば、システムは停止してしまいます。データベースに限定された対策だけでなく、システム全体で考えるようにしましょう。

　以上で第3回「データベースの障害対策」は終わりです。今回は、Oracle Directが手掛けた各種の事例から、新しい技術を活用した対処方法や、見落としがちなポイントを中心にまとめました。今後のシステム構想・構築に少しでもお役立ていただければ幸いです。