pr

データの価値を高めるシステム選定とは

データが重要になればなるほど、データベースシステムは安定した稼働を求められる。データ＝資産という考え方が主流となったいま、その要求はいっそう強くなってきている。データベースシステムの安定稼働を実現する方法は複数考えられるが、それらをどう組み合わせ、どのように活用するかは選定者次第だ。

データの価値を守る

　「データ資産」という言葉を出すまでもなく、企業が持つデータの価値は近年高まりつつある。このデータを有効に活用するためにデータベースが存在することは言うまでもないが、もはやデータベースシステムがあれば、すべてが解決する時代ではない。データを安全に、安定して提供することが必須の条件となりつつある。システムの停止はそのままビジネスの停止を意味する。システムの根幹をになうデータベースに高可用性・安定稼働が求められるのは必然である。

　物理的に単一のデータベースサーバでは、何らかの障害が発生した際に、問題解析から解決、復旧に至るまでと、サービス停止を余儀なくされる時間が長期化するだけでなく、問題発見の目処が立たない場合には再開すら難しい。

　障害発生時だけでなく、例えば定期的なアップデート手続きなどの保守を行う場合にもシステムダウンが必要な場合がある。こうした場合に備え、あらかじめ冗長な構成を採用しておき、サービスを稼働した状態で計画停止を行うことが望ましい。

レプリケーションとフェイルオーバ

　レプリケーションは、一般には同一のシステムを複数用意して運用しておき、一部のノードにエラーなどの障害があった場合でも正しい結果を返すことができるようにする仕組みを指す。単純なコピーではなく、データが更新されるごとに同期して、常に最新の状態の複製が用意されるようになっている。一部のノードで書き込みに失敗した場合でも、データが破損したままの状態でダウンすることなく、常に正常な応答を行える。

　近年では、単に完全な複製を提供するだけでなく、選択的に必要なデータのみを複製できるものもある。この仕組みを利用して、障害対策以外の用途でも、例えば、高頻度で読み込み／書き込みが行われ負荷が高くなりやすいメインのデータベースシステムから参照用途のデータのみを切り分けるといった用途でも用いられる。

　一方のフェイルオーバは、サーバを冗長構成にしておき、メインのシステムに障害が発生した際に、待機系のシステムに切り替えを行い、システムを停止することなく稼働させる方法を指す。待機系のシステムがメインに代替している間にメインのシステムを復旧させることができる。復旧後はメインのシステムに切り替えるフェイルバックを行い、ユーザー側からは障害発生の有無が検知されないようにする。

　冗長にしておくことで、1つのサーバノードが停止した場合でも予備のサーバがプライマリとなって稼働を続けられる仕組みだ。近年ではHTTP経由で複製するDRDBのようなアプローチも注目されている。

ハードウェア的視点

　消耗部品にも注意が必要だ。ハードウェア部品の消耗、不測の人的・物理的障害の発生をゼロにすることは、現時点では難しい。障害が発生して当たり前と考え、最良の対処を行うことに注力したシステムづくりが重要になってくる。

　例えばハードディスクのようなストレージであれば、ディスクの読み込み／書き込みの頻度によって劣化の速度は異なってくるが、いずれにせよ、劣化し、エラーを発生させる日が来ると考えて備えるべきだろう。当然、扱うデータの性質によってシステムそのものを切り分けるなど、インフラ全体の構成も見直す必要がある。書き込み頻度によっては、SSDなどの選択肢も考えられる。

死活監視

　不特定多数のユーザーからのアクセスが想定されるシステムではとくに、高負荷によるダウン、レスポンスの低下が懸念される。この場合には、クラスタ構成を採用し、Oracle Real Application Clustersのようなアプリケーション層での効率的な負荷分散が考えられるが、分散処理を実施した場合でも、一部のノードが停止すれば、それだけ性能が劣化する恐れがある。そこで、ノードそれぞれの状態を監視し、把握しておく必要がある。

　SNMPプロトコルなどを使った死活監視が有効だが、単純な死活監視だけではカバーできないものもある。例えばデータベースサーバのプロセスそのものはダウンしていないものの、機能しない状態だ。クエリを投じてもレスポンスがない状況などを検知するには、実際にサーバに処理リクエストを送るよりほかない。

　これを手動でコンソールから行ったり、サーバインスタンスごとにスクリプトを自動実行するような「力技」も可能だろうが、万一、システム構成の変更や拡張などが必要になった場合、すべてに人力で対処するのは難しいだろう。決して万人にお勧めできる対策ではない。近年では、一般的な障害検知機能だけでなく、独自にクエリを投じてサーバの状況を検証するので、プロセスが生きていてもレスポンスが悪いといった、検知が難しい状況にも対応する製品も登場しているので活用したいところだ。

導入前の検証とコスト

　このように、さまざまな対策を講じたとしても、ハードウェアが性能を発揮できなければ意味がない。そこで、システム構築に際しては、事前にあらゆる状況を想定して検証を行う必要がある。独自に検証システムを構築して意図的に問題を発生させるなどして詳細なデータを事前に得ておく必要がある。想定を超える状況が発生した際の対処方法も検討しなくてはならない。

　このような独自での検証が難しい場合でも、ベンダが提供する検証センターを活用したり、そのベンダが持つノウハウの提供を受けることも可能だ。さまざまな状況下でソフトウェアがどう挙動し、ハードウェアがどのようであるか、詳細なデータをもとに検証しているプロの指導のもと、最適な構成にチューニングされた製品を選定し、汎用機並みに信頼できるシステムを構築するという方法も検討に値するだろう。

ITインフラが組織に与える影響

　一方で、あらゆる業務はITインフラを抜きに語れないものになっている。データが透過的かつスピーディに伝達できるようになった半面、ソフトウェア的／ハードウェア的な制約を感じることも少なくないだろう。

　システム選定はコスト面を中心に考えがちだが、そこで選定したシステムが今後のビジネスを決定付ける。例えば細かな業務フロー1つを取っても、簡易なインターフェイスでだれもが扱える場合と、コマンドラインインターフェイス経由で必ずエンジニアが行わなければならない場合とでは、意思決定スピードが大きく異なるはずだ。あるいは、エラー発生時の対策が個人的スキルに依存している場合と、システマチックに自動検出・対処を行う場合も同様だ。構築・運用ノウハウがなく、かつそれを確立できるだけの人的リソースを確保できないという問題のために、システムの大規模リプレイスを断念せざるを得ず、苦しい運用を続けている場合もあるだろう。

　やや大げさな物言いになるが、ITインフラの制約によってビジネスが規定される場面も少なくないと言えるのではないだろうか。システム選定者は、システムがビジネスを規定するという側面に注意すべきである。

　

ソリューションFLASH Pick UP!

SharePlex for Oracle SharePlex for Oracleは、Oracleデータベース向けのレプリケーションソフトウェアだ。独自のアーキテクチャを採用しているため、メインのデータベースに大きな負荷をかけずにほぼリアルタイムで複製を行える。また、テーブル単位の複製などにも柔軟に対応している。この利点を活かし、基幹システムから分析系の処理に必要な部分を切り出し、生産性を向上させた企業を取材した。 HAクラスタリングソフトウェア「CLUSTERPRO X」 いまやシステムの停止はそのままビジネスの停止を意味し、時には企業の死活問題にまで発展することさえあり得る。システムの根幹をになうデータベースには、以前にも増して高可用性が求められるようになってきた。こうしたニーズに応えるべく、NECのHAクラスタリングソフトウェア「CLUSTERPRO X」では、単なるプロセス監視のレベルを超えてデータベースの可用性を大幅に向上するための強力な監視機能を用意している。 レガシーモダナイゼーションを推進するDell＋Oracle 一口に「このシステムは止まっちゃ困るんです」といっても、よくよく分析していくと、システムによって求められる可用性のレベルは千差万別だ。クラスタ構成はどうするか、バックアップ／リカバリ体制をどう整えるか、災害対策はどこまで用意するか……顧客が抱える異なるニーズに対し、デルとオラクルはそれぞれの強みを生かした多様な選択肢を提供し、レガシーモダナイゼーションを通じて最適な解を提供している。

提供：クエスト・ソフトウェア株式会社
日本電気株式会社、デル株式会社
企画：アイティメディア 営業本部
制作：＠IT 編集部
掲載内容有効期限：2009年1月31日