おつかれさまです。
ジーアールソリューションズの@yshinozuka-grsです。
この記事はグロースエクスパートナーズ Advent Calendar 2020の22日目となります。
現在、プライベートクラウドのサービス開発に参画しており、主にOSSを利用したIaaS/PaaSの提供を
行っています。
今年はNoSQLデータベースのサービス化が多かったので、これを機会に概要をまとめてみました。
NoSQLとは
まず、NoSQLは一般的に「非リレーショナルデータベース」として表現されます。
「リレーショナルデータベース(RDB)」は行と列で構成される表形式のデータ集合と言われていますので、
それ以外のデータベースということになります。
名称からSQLを使わないので「NoSQL」と思われがちですが、SQLに限らない「Not Only SQL」であると
提唱している方も多いようです。
NoSQLに分類されるデータベースは様々なモデルがありまして、私が携わったのは代表的な以下の4つです。
| データモデル | 概要 |
|---|---|
| キー・バリュー | 「キー」と「バリュー」の組み合わせでシンプルなデータモデル |
| カラム | 列方向の処理に特化しているデータモデル |
| ドキュメント | 自由な形式のデータで保存するデータモデル |
| グラフ | ノード（節点/頂点）の集合とエッジ（枝/辺）の集合で構成された（グラフ理論）データモデル |
特徴を簡単にまとめてみました。
| キー・バリュー | カラム | ドキュメント | グラフ | |
|---|---|---|---|---|
| モデル図 |  |
 |
 |
 |
| データ例 |  |
 |
 |
 |
|
| 代表OSS | redis、memcached、riak | Cassandra 、Hbase | MongoDB、couchbase、CouchDB | Neo4J、JanusGraph、ArangoDB、OrientDB |
| パブリッククラウド | Amazon ElasticCache、Amazon DynamoDB、Azure Cosmos DB Table API/Azure Cache for Redis/Azure Table Storage､Memorystore、IBM Cloudant | Amazon Redshift、Cosmos DB Cassandra API、Cloud Bigtable 、IBM Cloudant | Amazon DynamoDB、Azure Cosmos DB、Firebase Realtime Database、IBM Cloudant | Amazon Neptune、Azure Cosmos DB Graph API |
1つのデータモデルにおいても複数のOSSがあり、その中からメリット・デメリットを比較し、プライベートクラウド環境に合うものを選択しました。 ご参考までに以下に選定理由をまとめています。
NoSQLが選ばれる理由
一般的にNoSQLのメリットは、迅速で柔軟なスキーマ（柔軟性）、拡張性の高さ（スケーラビリティ）、特定のデータに高いパフォーマンスと機能性（高性能・高機能）を提供するといわれています。
私が携わったのは4つのデータモデルでは以下理由から採用されました。
| データモデル | 選定されたOSS | 選定理由 |
|---|---|---|
| キー・バリュー | Redis | Memcachedと比較して、システムの継続性（キーストアの永続性、レプリケーション、プライマリの自動フェールオーバー、バックアップ・リストアの機能がある）が高いものが選択されました。 |
| カラム | Cassandra | HBaseと比較して、SPOF（単一故障点）が無く可用性が高いものが選択されました。 |
| ドキュメント | MongoDB | CouchDBと比較して、機能面では同等のものでしたが、ドキュメントストアの中で多く活用され大手の採用事例も多数あることから選択されました。 |
| グラフ | Neo4j | JanusGraph、ArangoDB、OrientDBと比較して、機能面では同等のものでしたが、グラフストアの中で多く活用され大手の採用事例も多数あることから選択されました。 |
選定理由に共通していたこととしては、「可用性・継続性の高さ」「活用事例の多さ」でした。
どちらもOSSのメリットであるスケーラビリティの良さと、利用者が多いことで長期利用が可能であるものが選ばれたとも言えます。
アーキテクチャ
サービス化に伴うアーキテクチャの検討を行う際、公式ドキュメントやQiitaなどを参考にさせてもらいますが
インフラ寄りの内容が少なかったので今回データモデル毎に要点をまとめました。
キー・バリュー / Redis
| 項目 | 値 | 備考 |
|---|---|---|
| ライセンス形態 | Community | - |
| 最小インスタンス | 最小2台(プライマリ1/スレーブ1)、最小3シャード | インスタンス数は可用性を担保。シャードはRedis Clusterの最小値 。 |
| 最小vCPU/RAM | 1vCPU/4GB | vCPU数は性能影響が低いため最小とし、必要に応じてRAMを増やす。 |
| 可用性 | Redis Cluster構成、ロードバランサVIPを利用 | ロードバランサを用いて利用者に対する設定の容易性と耐久性を考慮。組み合わせるミドルウェアによってRedis Clusterが推奨されていないものがあった。 |
| スケールアップ (vcpu/RAM、ボリューム)1 | 不可 | 利用頻度が少ないと考えられ、また既存Redis Clusterからシャード数・フレーバが異なるRedis Clusterへのデータ移行（バックアップのリストア）で代用が可能であるため。 |
| スケールイン・アウト | 一部可能 | オンライン状態にて実施。インスタンスはスレーブのみ増減可能。シャードは追加のみ可能。 |
| 運用（バックアップ） | メモリのダンプファイル(Redis Database)取得 | - |
| データ操作/インターフェース | redis-cli | - |
カラム / Cassandra
| 項目 | 値 | 備考 |
|---|---|---|
| ライセンス形態 | Community | - |
| 最小インスタンス | 最小3台 | 可用性担保のためマルチノードでの提供 |
| 最小vCPU/RAM | 1vCPU/4GB | 公式ドキュメントでは最小「2vCPU/8GB」、一般「8vCPU/32GB」となっているが使用リソースを抑えるため最小とした。(本番環境時は要検討としている) CPUの制約はないがCPUコアが多ければ読み書き両方のスループット向上。RAMはCassandraヒープを2GB以上、システムRAMの50％以下を推奨。 |
| 可用性 | マルチノード構成、ロードバランサVIPを利用 | ロードバランサを用いて利用者に対する設定の容易性と耐久性を考慮。 |
| スケールアップ (vcpu/RAM、ボリューム)1 | 可能 | オフライン状態にて実施。 |
| スケールイン・アウト | 可能 | オンライン状態にて実施。 |
| 運用（バックアップ） | CassandraツールによりDBのSnapshotを取得 | - |
| データ操作 | CQL（Cassandra Query Language） | - |
| インターフェース | cqlsh、DataStax DevCenter | - |
ドキュメント / MongoDB
| 項目 | 値 | 備考 |
|---|---|---|
| ライセンス形態 | Community | - |
| 最小インスタンス | 【非シャード構成】最小3台、【シャード構成】最小9台 | シャード構成の内訳は1つのプライマリノードと2台以上のセカンダリノードに加え（これをレプリカセットとする)、Config用レプリカセット、Shard用レプリカセットを1つずつ用意。 |
| 最小vCPU/RAM | 2vCPU/8GB | CPUとRAMに特に制約はありませんが、バックアップなど他プロセスとの実行負荷を考慮した。 |
| 可用性 | Mongosルーターによるバランシング | 利用者はクライアントに配置したmongosルーターから接続。 Shard追加／削除はmongosルーター経由でないと実施できないため、Configにもmongosルーターを配置。 |
| スケールアップ (vcpu/RAM、ボリューム)1 | 可能 | オフライン状態にて実施。 |
| スケールイン・アウト | 可能 | オンライン状態にて実施。インスタンスは増減可能。シャードは追加のみShard用レプリカセットに可能。（削除は必要時個別対応） |
| 運用（バックアップ） | Mongodump/データファイルコピー | 大規模システムでのMongodumpフルバックアップは推奨していないため増分バックアップのみとし、フルバックアップはデータファイルコピーバックアップとした。 |
| データ操作 | JavaScript | - |
| インターフェース | mongo Shell、MongoDB Compass | - |
グラフ / Neo4j
| 項目 | 値 | 備考 |
|---|---|---|
| ライセンス形態 | Enterprise、Community | 本番環境はEnterpriseライセンス、開発環境はCommunityライセンスを利用。 |
| 最小インスタンス | 【Enterpriseライセンス】最小3台、【Communityライセンス】1台 | EnterpriseライセンスのCoreサーバは、耐障害性を考慮し1台の障害まで耐えられる3台構成、Replicaサーバは障害が発生してもサービス提供に影響が少なく使用リソースを抑えるため0台とした。 |
| 最小vCPU/RAM | 1vCPU/4GB | 公式ドキュメントでは最小「2vCPU/2GB」、推奨「16vCPU以上/ワークロードを考慮したサイズ」であるが、EnterpriseライセンスはvCPU数に依存するためシステム要件の最小以下とした。 |
| 可用性 | ロードバランサVIPを利用 | - |
| スケールアップ (vcpu/RAM、ボリューム)1 | 可能 | オフライン状態にて実施。 |
| スケールイン・アウト | 可能 | Enterpriseライセンスのみインスタンス増減可能。Coreサーバの場合、オフライン状態にて実施。 |
| 運用（バックアップ） | 【Enterpriseライセンス】オンラインのフル/増分バックアップが可能。【Communityライセンス】オフラインのフルバックアップのみ。 | - |
| データ操作 | Cypher | - |
| インターフェース | cypher-shell、Neo4jブラウザ | - |
まとめ
今回のNoSQLはお客様の強い要望でサービス化し、私たちも新しい技術を知ることができました。
そのサービス開発の際、パブリッククラウドや公式ドキュメント、Qiitaなどを参考に開発をしましたが、
データベースの利用方法についての情報は多いものの、アーキテクチャに関する情報が少ないと
感じることがありインフラエンジニア目線で概要をまとめさせていただきました。
今後も新しいNoSQLが増え、利用する機会も増えてくると思いますが、扱うデータに適したデータベースを
選択することが大切だと感じましたので、色々な選択肢の中からお客様へ提供できるようなエンジニアに
なれるよう日々精進します。
（既ににRDBでもNoSQLでもない、VoltDBがあるようですね、、、）
参考資料
以下サイトを参考にさせていただきました。詳細を知りたい方ははこちらを参照頂ければと思います。
ご紹介したミドルウェアの公式サイト
- redis（ https://redis.io/ ）
- cassandra（ https://cassandra.apache.org/ ）
- MongoDB（ https://www.mongodb.com/ ）
- Neo4j（ https://neo4j.com/ ）
パブリッククラウドのNoSQL概要
- AWS NoSQL（ https://aws.amazon.com/jp/nosql/ ）
- Azure NoSQL（ https://azure.microsoft.com/ja-jp/overview/nosql-database/ ）
- GCP Cloud Bigtable（ https://cloud.google.com/bigtable ）
- IBM Cloud NoSQL Databases（ https://www.ibm.com/cloud/learn/nosql-databases ）
その他
- リレーショナルおよびNoSQLデータベース管理システムのナレッジベース
- DB-Engines（ https://db-engines.com/en/ ）
- de:code2016 講演資料
- RDB技術者のためのNoSQLガイド/（ https://www.slideshare.net/recruitcojp/rdbnosqlnosql ）