NoSQLをプライベートクラウドにてサービス化した話

こんにちは。

2021年が始まり、もう2週間が経ちます。
日々の業務に追われると時が経つのは早く感じ、経験したことがあっという間に感じます。
身になる経験とするためにもアウトプットすることは大切と言われていますので、今回は去年の年末に実施したグロースエクスパートナーズグループ合同でのAdvent CalendarとしてQiitaに掲載した記事をご紹介します。

現在、私たちはプライベートクラウドのサービス開発に参画させていただいており、主にOSSを利用したIaaS/PaaSの提供を行っています。
昨今、NoSQLデータベースのサービス化が多かったため概要をまとめてみました。

NoSQLとは

まず、NoSQLは一般的に「非リレーショナルデータベース」として表現されます。

「リレーショナルデータベース(RDB)」は行と列で構成される表形式のデータ集合と言われていますので、それ以外のデータベースということになります。
名称からSQLを使わないので「NoSQL」と思われがちですが、SQLに限らない「Not Only SQL」であると提唱している方も多いようです。

NoSQLに分類されるデータベースは様々なモデルがありまして、私が携わったのは代表的な以下の4つです。

データモデル	概要
キー・バリュー	「キー」と「バリュー」の組み合わせでシンプルなデータモデル
カラム	列方向の処理に特化しているデータモデル
ドキュメント	自由な形式のデータで保存するデータモデル
グラフ	ノード（節点/頂点）の集合とエッジ（枝/辺）の集合で構成された（グラフ理論）データモデル

特徴を簡単にまとめてみました。

キー・バリュー

モデル図
データ例
代表OSS	redis、memcached、riak
パブリッククラウド	Amazon ElasticCache、Amazon DynamoDB、Azure Cosmos DB Table API/Azure Cache for Redis/Azure Table Storage､Memorystore、IBM Cloudant

カラム

モデル図
データ例
代表OSS	Cassandra 、Hbase
パブリッククラウド	Amazon Redshift、Cosmos DB Cassandra API、Cloud Bigtable 、IBM Cloudant

ドキュメント

モデル図
データ例
代表OSS	MongoDB、couchbase、CouchDB
パブリッククラウド	Amazon DynamoDB、Azure Cosmos DB、Firebase Realtime Database、IBM Cloudant

グラフ

モデル図
データ例
代表OSS	Neo4J、JanusGraph、ArangoDB、OrientDB
パブリッククラウド	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が増え、利用する機会も増えてくると思いますが、扱うデータに適したデータベースを選択することが大切だと感じましたので、色々な選択肢の中からお客様へ提供できるようなエンジニアになれるよう日々精進します。

今回ご紹介した内容は、グロースエクスパートナーズ Advent Calendar 2020の22日目に掲載したものとなります。
その他にも色々な視点のものがございますので、ぜひグロースエクスパートナーズ Advent Calendar 2020を閲覧いただければと思います。