CAP定理を元にしたデータベースの分類とデータ特性

今回からは数回にわたり、代表的なNoSQLプロダクトである「Amazon DynamoDB」や「Apache Cassandra」、「Amazon ElastiCache」へアクセスするSpringアプリケーションを開発する方法について、以下のステップに沿ってわかりやすく解説していきます。

1. NoSQLデータベースの特徴とデータ特性
　・CAP定理を元にしたデータベースの分類とデータ特性
　・AP型データベースAmazon DynamoDBとApache Cassandraの特徴
2. Amazon DynamoDBへアクセスするSpringアプリケーション
　・Amazon DynamoDBの概要及び構築と認証情報の作成
　・Spring Data DynamoDBを用いたアプリケーション(1)
　・Spring Data DynamoDBを用いたアプリケーション(2)
3. Apache CassandraへアクセスするSpringアプリケーション
　・Apache Cassandraの概要及びローカル環境構築
　・Spring Data Cassandraを用いたアプリケーション(1)
　・Spring Data Cassandraを用いたアプリケーション(2)
4. Amazon ElastiCacheへアクセスするSpringアプリケーション
　・AmazonElasiCacheの概要及びローカル環境でのRedisServer構築
　・Spring SessionとSpring Data Redisを用いたアプリケーション(1)
　・Spring SessionとSpring Data Redisを用いたアプリケーション(2)
　・Amazon ElastiCacheの設定
　・セッション共有するECSアプリケーションの構築(1)
　・セッション共有するECSアプリケーションの構築(2)

なお、解説にあたっては以下の前提知識がある開発者を想定しています。

また、動作環境は以下のバージョンで実施しています。

将来的には、AWSコンソール上の画面イメージや操作、バージョンアップによりJavaのソースコード内で使用するクラスが異なる可能性があります。

NoSQLデータベースの特徴とデータ特性

リレーショナルデータベース(RDB)と対比して、NoSQLデータベースでは、キーバリュー型やドキュメント指向型、カラム指向型、グラフ指向型など、機能や特徴によっていくつかの分類方法があります。そのなかの1つが、分散データベースという観点から分類する方法です。この分類の基礎となる考え方が、「ブリューワのCAP定理」と呼ばれる、広域に分散した環境下におけるデータベース・サービスに関する理論です。後々、保存に適したデータ特性やデータモデルの検討にも関係してくるので、ここで基礎的な内容を押さえておきましょう。

CAP定理は、限定的な条件が前提にはなるのですが、「広域な環境で分散してデータを保存する場合に、以下の3つの特性のうち、2つまでしか同時に満たすことができない」という定理です^※。

※　3つのうち常に2つが満たされるわけではなく、「原則として2つの特性を重視すると残りの1つが失われる」と捉えたほうがよいでしょう。

この観点からデータベース全体を分類すると、RDBは一貫性(Consistency)と可用性(Availability)を重視したCA型のデータベースということになります。

定理を説明する単純な例としては、広域(複数のアベイラビリティゾーン)を跨いで、都市名データをキーと共に都市テーブルへ保存することを考えるとわかりやすいでしょう。こうした分散された環境下では、RDBは、以下のいずれかの方法でデータベース間の同期をとりながら更新するケースが一般的です。

上記では、単純化のために2つのアベイラビリティゾーンに限定していますが、複数のゾーンにあるデータは、いずれも常に最新のデータを返し(Consistencyが保証される)、「複数同時に壊れる」というまれなケースを除いて、片方のノードで障害が発生しても可用性(Availability)が保証されます。

ただし、この構成はネットワークが分断されると、一貫性／可用性共に崩れてしまいます。実際にはネットワークも二重化などの対策が取られているので障害になることはまれですが、ゾーン間の通信が使用不能になると、CA型データベースとしては機能不全に陥ります。つまり、一貫性／可用性を保ちつつ、同時にネットワーク分断耐性を満たすことはできません。

他方、可用性(Availability)を下げることをトレードオフとして、一貫性(Consistency)とネットワーク分断耐性(Partition Tolerance)を高める手法もあります(CP型)。データを複数のアベイラビリティゾーン(の別ノード)に分けて保存する方式で、一般的にこの方法はシャーディング(Sharding)と呼ばれます。

シャーディングは、どちらかと言えば性能向上を目的とした負荷分散のためにRDBなどでもよく利用される手法です。特定のデータノードが一時的に分断されても一貫性(Consistency)は保持されます。ただし、ノードの数が増えることで故障確率が上昇し、読み込みと書き込みが制限され、可用性(Availability)が損なわれる確率が上がります。このシャーディングを機能として備えるデータベースとして有名なプロダクトとしては、「Apache HBase」や「MongoDB」、「Redis」などが挙げられます。

最後に、一貫性(Consistency)を下げることをトレードオフとして、高い可用性(Availability)とネットワーク分断耐性(Partition Tolerance)を持つAP型のデータベースの代表例が、「Amazon DynamoDB」「Apache Cassandra」です。

AP型データベースでは、以下のイメージのように、複数のアベイラビリティゾーンにデータベースを配置し、1つのノードやネットワークに障害が起きてもデータが損なわれないよう、各ノードにデータを分散して配置します。

大きな特徴は、単一障害点がないことです。どこのノードからでもデータ更新が可能であり、スケーラビリティにも優れた、まさにクラウドらしい分散型構成だと言えるでしょう。ただし、ノードの故障や通信のエラーにより、複数のノード間で整合性がとれない(一貫性を損なう)ケースが発生します。

それらの問題を解決し、一貫性を担保する手段として、読み込み時に最新のデータで古いノードのデータを更新するReadRepair機能や、Quorumをベースに結果整合性をとる方法(雑に言えば、不整合が出た場合に、なるべく多くの一致したデータを判定する多数決に似た手法)が用意されています。

このようにCAPによる特性に応じて、各データベースに適したユースケースやデータ特性をまとめると以下のようになります。

次回は、クラウドならでは特性を多数備えたAP型データベースについてもう少し深掘りし、DynamoDBやApache Cassandraの特徴や違いについて紹介します。