Hbaseの構造(運用)

提供: LunaBiblos

Software > DataBase > KeyValueストア > Hbaseの構造(運用)

HBaseに於けるCAP原則

HBaseに於けるPartition Toleranceの解釈にて、HDFS側の問題を除外して考慮するとHBaseはCPとなる。
HBase ClusterにNetwork分断が発生し2つのNetwork、「こちら側と「向こう側」に分断されてしまった状態を考える。
「こちら側」にZooKeeperの多数派(ZooKeeperのQUORUM)があるとすると、「向こう側」にあるZookeeperの少数派は自主的に停止し、Zookeeperと通信が行えなくなった「向こう側」のHBase Nodeが停止する。
上記の様な動作の結果、複数のRegionServerへのRegionファイルの多重割り当てによる整合性一貫性の欠損といった問題を回避する事が出来る。
同時にClusterを構成していたNodeの数が減る為、Cluster全体の処理能力低下に伴い、従来そのClusterに掛かっていた負荷に対しての応答速度が劣化する為、可用性が犠牲となってしまう。

しかしNetwork分断が発生した事をZooKeeperが分断を検知する迄に数十秒のタイムラグが発生する。
その間に「向こう側」にあるRegionServerがDataの更新をCommitしてしまう可能性が充分にある。本来であればCommitLogの保存先であるHDFSにAccessにいく所でErrorとなるはずだが、数十秒もあるタイムラグの最中に上記の様な事が起きる事は充分にあり得る。

その結果としてCommitLogが「こちら側」のNetworkに届かない。
一方、「こちら側」では欠損したNodeが持っていたDataを「こちら側」に残ったNode群で補う為に、CommitLogからのData復旧であるForwardRecoveryが実行される。この時に「向こう側」にCommitされてしまったDataは「こちら側」に残ったClusterには反映されず、Dataに矛盾が発生してしまう。

更に最悪の事態として、ForwardRecovery等によるDataの復旧が完了しDisk上の実ファイルであるSSTableに書込が行われるとCommitLogは削除されてしまう為、Networkが回復した後にそのData上の不整合が検出、修正出来なくなってしまう事である。

依り高次元な問題

分散Algorithmに置いてNetwork分断発生時の対応が難しくなるのが、分断箇所が二つ以上、つまりNetworkが3つ以上に分断された時である。
n個に分断された場合は回復時にn-1個の復旧処理が走る為、復旧処理同士が競合し衝突する可能性が出てきてしまう。
上記環境は特殊な事例ではなく、Networkの複雑化、仮想化が進んだ今であれば余計に身近な問題となってきている。