こんにちは、プリセールスを担当しております國政です。
いつも当ブログをご覧頂きましてありがとうございます。
今やビジネス利用のシステムでは無くてはならないデータベースですが、商用製品、OSS製品などいろいろな選択肢がありますが、システムを設計構築する際にはこれらデータベース部分についての可用性を考慮しておく必要があると思います。
ひと括りにデータベースの可用性部分を考えると言ってもその手法は多岐にわたります。具体的には複数台のサーバーを束ねクラスターを構成し、分散手法を用いてパフォーマンスを向上させることによる可用性の向上や、2台のサーバーを準備し、Active/Standby構成のHAクラスターシステムなどが考えられます。
前者の手法では価格が高額になりやすく、後者の場合は切換え時間が多少必要になります。かける費用と設計上のダウンタイムのバランスとしてはHAクラスターが所属するフォールトレジリエント(FR)レベルが最適解と私たちは考えています。
掛ける費用と得られる効果
掛ける費用と得られる効果(ダウンタイム)については下図で示しておきます。
LifeKeeperをはじめとするHAクラスター―のAvailability(可用性)レベルは99.99%で設計上の許容ダウンタイムは年間53分、1ヶ月で考えると４分のダウンタイムとなります。もちろんこの数値は設計上の上限数値ですので実際に障害が発生しなかった場合などはダウンタイムが限りなく小さくなります。
<可用性レベル、ダウンタイム、費用感>
どのような手法を採用するにせよ、ダインタイムの最小化と障害の影響範囲をできる限り小さくすることがデータベースに求められる要件である事に変わりはありません。
これらデータベースを対象とした場合、DBMS自体が持つ可用性を高める仕組みと当社LifeKeeperを始めとするHAクラスターでの可用性の高め方について考察してみましょう。
>>仮想環境(VMware)上でミッションクリティカルなIT基盤を構築するには？
DBMSの持つ機能での可用性の確保の方法
MySQLの場合
パターン１：マスター/スレーブ構成のMySQLレプリケーション
・マスター/スレーブの関係を持ちます。スレーブはマスターの複製として機能しますが、
マスターに障害が発生した場合などの場合、手動で切り替える必要があり復旧に時間が
かかる場合もあり、MySQL内包の機能で構成できる点は良いがマスター障害時には手動でマスターに昇格させる必要があるので自動復旧とまではいかない。
パターン２：InnoDB Cluster
・DB部分の可用性をグループレプリケーションで、システムへの接続をMySQL Routerにより可用性を高める手法です。負荷分散やスケールアウト、スケールアップなど複数のサーバーを跨いで使う場合やダウンタイムを極端に減らしたい場合にはInnoDBClusterを利用する価値はあるかと思います。
但し、大半の作業がコマンドラインでの設定となり構築時の負荷は大きめで初回導入時にはコンサルティングを利用した方が良いなど敷居が高い。商用のMySQLサブスクリプションは4ソケットまでで1台辺り120万円程必要となっており複数台の利用や高性能なマシンでは比較的高額になる傾向があります。
PostgreSQLの場合
pgpool-IIサーバーをキーにしたバックエンドクラスタ
可用性を高める手法として思いつくのはpgpool-II
サーバーをキーにしたバックエンドクラスタへの接続手法ですが、pgpool-IIサーバー自体が可用性を取れていない単一障害点となりますのでここは何かしらの手当が必要な個所です。
Streaming Replication
こちらはクラスターを構成するプライマリーサーバーからスタンバイサーバーへログシッピング(WAL)を行い続け、受信したスタンバイサーバーは受信したWALからリカバリ作業をし続ける事で常にマスターとスタンバイは同じ状態を保つ仕組みですがStreaming Replicationの構成では、障害の検知、自動的にスタンバイ機からマスターへの昇格、自動復旧などの機能はありませんので、pgpool-IIの管理機能を組み合わせるかLifeKeeperなどのソフトウェアと組み合わせる必要があります。後日ブログで紹介する予定ですが、このStreaming Replicationの機能を生かしたままLifeKeeperと連携する為のGeneric ARKの用意がありますので、LifeKeeperからStreaming Replicationの状態を監視し、適切な運用を実現する事も可能です。
OracleDBの場合
Oracle RAC システム
OracleDBで可用性を高める仕組みとしては、複数台のサーバーで負荷分散クラスターとして高い可用性と高いパフォーマンスを実現するRACシステムが挙げられます。OracleDBで可用性を考えた場合、RAC構成、ログ転送機能を使ったレプリケーションなど可用性を高める手法や機能は充実しています。しかしながらOracle DBMSでこれらの機能を使うには一般的には高価な部類のライセンスが必要になります。普及価格帯ライセンス+HAクラスター構成は費用対効果が出せる構成と考えられます。
まとめ
どの構成を検討する場合でも、障害からは「できる限り早く」、「できる限り自動で」、「できる限りシンプルな運用ができ」、「できる限りサポートの有る製品」がシステムを安定かつ継続的に利用する上で重要な事となります。
もちろん、費用が潤沢で無停止に近い運用が必要といった要件にはHAクラスターは向きませんが、数分から10分以内には正しく切り替わるシステム、パフォーマンス向上を目的としたクラスター化ではなく可用性を上げる目的であれば費用対効果が適切なHAクラスターシステムの導入が最適です。
例えば、年商300億円を売り上げるシステムのDB部分が停止した際の金額的なリスクを考えると、1分辺りおよそ6万円の金銭的な損失があると試算されます。障害時のオペレーションが手動切り替えの運用を採用していた場合など、復旧まで1時間ほどかかった場合は約360万の損失に加え、目に見えない機会損失や復旧までにかかる運用コストも合わすと1時間当たり500万近くの損失が想定されます。
コストの観点では、設計、運用、構築時の工数も見えにくい点ですが少ないに越した事はないですLiifeKeeperでは、GUIベースで操作の敷居を下げ、DBMS用のスクリプト集ARK(Application Recovery Kit)の用意があり、ARKを使うとウィザード形式でHAクラスター構成を行う事ができ、各リソースの依存関係も自動で判断し、構築されます。これら簡単構築は各段階での工数削減に大きく効いてきます。
<クラスター構成を劇的に楽にするスクリプト集(Application Recovery Kit)>
また、あまり知られてないもう一つの利点としては、LifeKeeperは「ノードライセンス」である事も選ばれ続ける理由の一つとなります。前途したDBMS自体に内包する機能をサポート付きで利用した場合はCPUソケット数に応じた料金が必要な場合が多く、他社HAクラスター製品もそのようなCPU課金の製品もあり、想定した費用感を大幅に超える場合も見受けられます。
ビジネスに欠かせない大事なDBMS、可用性を高める手法としてHAクラスターが実は費用対効果の観点ではベストな選択である事がお分かりいただけたかと思います。
検討中の案件への適合確認や実際に評価をしてみたいなどのご相談は大歓迎です。
以下のお問い合わせフォームからご遠慮なくお問い合わせ下さい。
お問い合わせ
LifeKeeper/DataKeeper「見積を依頼したい」「もっと詳しい話を聞いてみたい。」といった場合は、下記よりお気軽にお問い合わせください。
→[お問い合わせ窓口] https://mk.sios.jp/BC_Web_Free-entry_Inquiry.html
評価版ダウンロード
LifeKeeper/DataKeeper/Single Server Protectionの機能を30日間無料でご利用いただくことができます。要件に対応できるかなど、基本的な機能確認にぜひご利用ください。
→[評価版のお申込み] https://mk.sios.jp/BC_DL_Evaluation.html
