データベース冗長化の重要性について
2018.09.02
2018.09.02
システムを構成する上で非常に重要な役割を担っているのがデータベースサーバーですが、データベースサーバー（以下、DBサーバー）の障害によりサーバーに格納されているデータが破損や消失するなどの事故が発生した場合、業務やサービス提供を継続することが出来なくなり、企業収益の損失や企業信用の低下を招く恐れがあります。
このようなリスクを回避するためにデータベースサーバーは通常、単一構成とせず冗長構成にすることで高可用性を確保する必要があります。
ここでは物理環境での冗長化方式、運用する上での問題点と近年、利用ケースが増加しているクラウド型データベースについて紹介させていただきます。
データベース冗長化の重要性について
物理環境での冗長化の方式としては以下の方式を採用することが一般的となっています。
1. アクティブ・スタンバイ構成
– メインで稼働しているサーバが故障時にもう1台同じサーバーを用意しておけば良いという考え方から生まれました。
– データ同期方法はディスクの同期、データベース標準のレプリケーション機能を使うものがあります。
– この方法のデメリットは片側がスタンバイ(非稼働)状態になってしまうことです。
2. マスター・スレーブ構成
– 現在では多くのデータベースにほぼ標準機能とされているレプリケーション機能を使用します。
– この構成であればスレーブは書き込みでが出来ませんが参照のみで稼働させておけます。スレーブを複数にすることも可能です。
– マスター障害時の切り替え(フェールオーバー)はデータベース標準のもの、MAH for MySQL、PGPoolなどのソフトを使いスレーブをマスターに昇格させるのが一般的です。
– スレーブを複数使用する際はDBサーバーの前段にロードバランサーなどの負荷分散装置が必要になります。
– マスターを1.で記載したアクティブ・スタンバイ構成にする構成もあります。
3. マルチマスター構成
– 全てのDBサーバーで書き込み・読み込みができる構成となります。
– OracleではRAC、MySQLではMySQL Enterprise、MariaDBではGalera Cluster、PostgreSQLではBi-Directional Replicationがあります。
– データベース標準のレプリケーション機能でも同様のことが出来るものもありますが、同一エントリの追加や削除を行ったときに動作結果が不安定になる場合があるのでほぼ用いられません。
– 上に挙げたソリューションは更新の重複を避けるために様々な工夫がされていますが今現在も各データベースで開発が活発な部分でもあり技術的には難しいものになり、障害時の復旧も複雑なものなる可能性があります。
– DBサーバーの前段にロードバランサーなどの負荷分散装置が必要になります。
各冗長化方式についての比較
| 項目 | アクティブ・スタンバイ構成 | マスター・スレーブ構成 | マルチマスター構成 |
|---|---|---|---|
| 待機系サーバー | データは同期されるが、サーバーはスタンバイ(非稼働)状態 | データ参照用サーバーとして稼働 | マスターサーバーとして稼働 |
| データ同期方法 | ディスク同期・共有またはレプリケーション機能を使用 | ディスク同期・共有またはレプリケーション機能を使用 | ディスク同期・共有または各DB毎のソリューションに付随のレプリケーション機能を使用 |
| 負荷分散装置 | アクティブにのみ更新・参照を行うため不要 | 更新クエリと参照クエリで接続先を変更する必要がある。 データ参照用サーバーが複数ある場合はロードバランサーやDNSのAレコードを複数登録するなどの仕組みが必要 ※一部クラウド環境では参照用サーバー用DNSのAレコード設定済みなので不要 |
ノード障害時のデータロストとダウンタイムを発生させないためにヘルスチェック機能と障害・復旧時の自動切り離し組み込み機能を持ったロードバランサーが必要 |
| ダウンタイム | VIPの付け替えなど （1分程度）のダウンタイムが生じる |
スレーブ側のサーバーがマスターへ昇格するまでのダウンタイム（30秒～1分）が生じる | 障害時の自動切り離し機能があれば、ダウンタイムは生じない |
【関連リンク】
物理環境でデータベースを運用していく際の問題点
物理環境でデータベースを運用する上で問題点として以下の点が挙げられますが運用する側はこれらの点について考慮した運用を検討する必要があります。
1. 人的リソースの確保
– 障害時の復旧のためデータベースに種類に応じた人員を置く必要があり、運用が属人的になりがちな傾向になる。
– データベース障害には時間に関係なく24時間体制の復旧体制を整える必要がある。
2. 高可用性設計
– 高可用性運用時に使用するデータベース毎のレプリケーション設計・設定を行なう必要がある。
– MySQLでは非同期レプリケーションか準同期レプリケーションか、障害発生時の復旧方法をMHAで行うかDRBDでアクティブスタンバイ構成にしておくかなど。
– PostgreSQLlではアーカイブログ同期かストリーミングレプリケーションか、障害発生時の復旧方法をpgpoolで行うか、独自の手法で自動化するかなど。
– DRBD・pacemakerを使用して高可用性を担保する運用はデータベースとは別の知識を必要とする。
3. 柔軟性(スピード)の問題
– 導入時のインストール・設定・チューニングに時間を要する。
– スケールアウトを迅速に行おうとした場合予め予備機を配しておくか部材を迅速に調達しなければならない。予備機準備は過剰在庫となるためコストも悪くなる。
4. バックアップ設計
– ハードウェア単位でのバックアップかソフトウェア単位でのバックアップか、又それぞれに応じた復旧方法をあらかじめ準備しておく必要がある。
– バックアップ用のストレージの確保、ストレージの冗長化の調達・設計コストを含める必要がある。
【関連リンク】
クラウド型データベースの活用
近年、パブリッククラウドの多くでクラウド型データベース(DBMS)をサービスとして提供している事業者があります。クラウド型データベース(DBMS)の特徴として、ハードウェアの調達が不要、データベースの構築が容易であったり、冗長化構成がサービスとして提供されている、OS/ミドルウェアの管理が不要など、データベースを運用する上で負荷となっていた点が大幅に解消されます。
1. 人的リソースを減少
– 予めどのデータベースも高可用性設計の環境が準備されている、又データベース毎の復旧方法を使い手が意識することはなく24時間体制で自動で行われるために今までかけていた人員コストを削減できる。
2. 高可用性設計の簡素化
– 各データベースに応じてレプリケーションが自動で設定されるため作業を簡素化出来る。
3. 柔軟性(スピード)の向上
– 予め目的のデータベースがインストールされている状態で調達が可能になる。
– サービスを停止すること無くリソースを柔軟に調達できる。又、不要なリソースをすぐに捨てられるため余剰を減らせるためコストがかからなくなる。
4. バックアップ設定を簡素化出来る
– ボリューム単位等でのバックアップ(スナップショット)の仕組みが出来ているため設計の必要が無く、リストアも使い手がデータベースの種類を意識すること無くほぼ一元の手順でリストアが可能になる。
【関連リンク】
まとめ
クラウドデータベースは初期費用無しでスモールスタートが可能で、かつスケールアップ/ダウンが柔軟に行なえるだけでなく高可用性のシステムが容易に構築出来るので、システム担当者は稼働させるシステム規模やデータベースの重要度に応じて、オンプレミスのデータベース、クラウド型データベースの使い分けの検討を行なうと良いでしょう。
