データベースの高可用性について　

プロアクシアコンサルティングでオープンソリューション事業部に所属している H.U です。
今回はデータベースの高可用性について軽く紹介できればと思います。

プロアクシアでの役割とこれまでの経験を教えてください

プロアクシア入社後は、主に AWS やデータベース関連の設計構築業務に従事しています。

これまでの経験ですが、汎用系オペレータとして IT 業務を始めて経験し、その後はオープン系運用や設計構築に携わり、10年前ぐらいからは、主に Oracle ですが、データベースの設計構築を行っていました。

最近では、AWS や Azure といったクラウド系の設計構築も行っています。　　　　　　　　　　　　　　　　　　　　　　　

データベース案件では、スタンドアロンからクラスタ構成といった様々なデータベース設計構築案件を担当しました。ここ最近では Oracle RAC や Lifekeeper を使った HA クラスター構築など行いました。

また、AWS 案件も担当しており、設計構築や技術支援を行っています。

インフラ設計にはアプリケーションの機能面とは違い非機能要件を定義し、設計を進めて行く必要があります。非機能要件には以下の６つの観点があります。

観点	説明
可用性	継続性、耐障害性、災害対策、回復性
性能・拡張性	業務処理量、性能目標値、リリース拡張性、性能品質保証
運用保守性	通常運用、保守運用、障害時運用、運用環境、サポート体制、その他の運用管理方針
移行性	移行時期、移行方式、移行対象 (機器、データ)、移行計画
セキュリティ	リスク、診断、アクセス・利用制限、秘匿、不正監視、NW・マルウェア・Web 対策など
システム環境	システム特性、適合規格、機材設置環境、環境マネージメント

データベースの高可用性とは、エンドユーザがデータベースシステムを中断なく利用できること、また障害時やメンテナンス時にも継続して利用できることを意味しています。

本ブログでは、データベースの可用性を向上させる方式についてご紹介できればと思います。

現在ではビジネスの事業継続性から止まらないシステム、止められないシステムを求められることが多くなってきています。

ひと昔前は HW やシステム異常時用に準備された待機系へと遷移する HA 構成が主流でしたが、近年では、利用者やデータ量の増加に伴う高負荷障害の対策や、震災などの拠点障害の対策を考慮して、遠隔地の待機系へ切り替えを行うなど多種多様な方式が生まれています。

最近では AWS などクラウドサービスだと、容易に海外のリージョンにもサーバを設置できるため、待機系を海外に配置することを検討されるケースも多くなっています。

可用性を向上させるための方式は、多種に渡ります。そのうちの一部を紹介したいと思います。

構成	説明	製品
HA 構成	アクティブ・スタンバイやアクティブ・アクティブで稼働させ、障害があったノードから正常なノードへ遷移させる方式	HACMP、LifeKeeper
DR 構成	アクティブ側の更新情報（アーカイブログ）をスタンバイへ継続的に送信し、障害時にはスタンバイをアクティブに昇格させる方式	Oracle Data Guard、 Stanby Express、Dbvisit
リアルタイムレプリケーション構成	アクティブ側の更新情報をSQLレベルで伝播させる方式。アクティブ側の負荷を軽減させる参照系DBとして使用することもある。	Oracle GoldenGate、SharePlex
クラスタ構成	複数のノードを関連付けさせて、一つのシステムとして稼働させる方式。スケールアウトが可能で負荷分散機能としても利用できる	Oracle RAC

HA 構成ではアクティブノード障害時のスタンバイノードへの切り替え (フェイルオーバ) が自動で行われるため、障害時の復旧を短期間で出来るというメリットがあります。

ただ、アクティブ・スタンバイと冗長化しているのは、あくまでもノードのみで、データベースを格納している共有ストレージは一つなので、RAID を組み、耐障害性を高めていても拠点障害には対応できないというところは許容する必要があります。

DR 構成ではプライマリとスタンバイで、データベース自体が冗長化されており、障害時にはスタンバイ DB へフェイルオーバが自動で行われるため、復旧を短期間で出来るというメリットがあります。

プライマリの更新情報 (アーカイブログ) をスタンバイに転送し、読み込ませることでデータを同期させていますが、障害時には更新情報がロストしてしまう可能性があることがあることは許容する必要があります。

リアルタイムレプリケーション構成では、上記２構成の耐障害性というよりは、負荷分散として使用されることもあります。

データベース自体はプライマリとセカンダリで同期されており、セカンダリは DWH などデータ分析などの参照系として使用することでプライマリの性能を保つ役割で使用されます。

プライマリの SQL をキャプチャして、セカンダリへ伝播させるのですが、オブジェクトの名前が何かしらの原因で合致していなかったりすると、伝播時に SQL エラーが発生し、同期がストップしてしまうので、運用が他の構成に比べて難しいというところが課題かと思われます。

クラスタ構成では、Oracle RAC を例とすると、HA 構成と同じフェイルオーバ機能＋負荷分散機能を要する構成になります。

HA 構成と違い、両ノードでインスタンスが起動している状態なので、フェイルオーバは HA 構成より素早く行えることや、無停止でノードを追加することができ、容易にスケールアウトさせることができるというところがメリットかと思います。

ただ、この構成も HA 構成と同様に拠点障害には対応できないというところを許容する必要があります。