こんにちは。エンジニアの中野です。前回は、私たちが開発している FractalDB: LINEヤフーのオンプレミス・マルチテナンシー型データベースシステムの紹介という記事を公 開しました。
今回は続いて、開発に至った背景とそれからどのようなサービス設計を行ったのか、少し具体的な話をさせていただきます。
課題(FractalDB開発の背景)
社内クラウドDBが欲しい
比較的昔から「パブリッククラウドの"クラウドDB"、例えばAWS DynamoDB(以下DynamoDB)やGCP Cloud Spanner、Microsoft Azure CosmosDBのようなデータベースが社内にも欲しいよね」という漠然とした話はありました。
例えば、DynamoDBを使ったアプリケーション作成は、通常のRDBMSを使ったアプリケーション開発と以下のような違いがあります。
普通のRDBMSを使ったアプリ | DynamoDBを使ったアプリ | |
---|---|---|
スケール |
|
|
メンテナンス |
|
|
分析/集計処理 |
|
|
クエリ体系が別物なのでRDBMSを置き換えるものでは決してありませんが、DynamoDBを使ったアプリは一度作ってしまえばその後のメンテナンスは比較的楽になるのが特徴として挙げられます。
特にマイクロサービスのようにアプリケーションの責 任を小さく分割している場合は、DynamoDBのようなシンプルな操作で十分である場合が多くなるため、DynamoDBの弱点の影響をあまり受けず、メリットを享受できるため相性が良いです。
LINEヤフー社内にもKubernetes環境(ZCP)、 ZAPのようなアプリケーション実行基盤や、Function as aserviceの環境が整備が整ってきたこともあり、データベースプラットフォームとしてもそれらと相性の良い、すぐ使えて手間がかからず、スケールするDBMSがあるべきと考えていました。
社内運用の課題
LINEヤフーではMySQLやApache Cassandra(以下Cassandra)、RedisをDatabase as a Serviceとして既に社内に対して提供していて、社内のDB利用者は比較的簡単にDBを構築・運用・利用できる環境が既に整備されています。
これらはそれぞれのDBMSを構築して運用するものですので、どうしても解決が難しい課題がいくつか残っていました。
- 整合性とスケーラビリティを同時に実現するのは難しい
- これ自体を解決できるソフトウェアは比較的多く存在しますが、続く2つの課題やその他の基準と照らし合わせると選択肢が多くはない状態でした。
- 集約率の問題
- DBのインスタンスのすべてがフル稼働しているわけではありません。その余力を集めると全体として相当量のリソースの余剰がある状態でした。
- もし仮に1つのクラスターに全ユーザーを収容できるのであれば、80%を超えるコスト削減が試算によって見込まれていました
- 正直この試算がFractalDBが始まる決定打となりました
- DB利用者、DBAの運用 負荷が高い
- 現状でも自動化によって平時の運用負荷は十分低く抑えられていますが、構成を変える必要がある場合の負荷の低減が難しいという課題がありました。
- DBMSのバージョンアップ
- ハードウェアのライフサイクルによる移設
- これらはDBAとアプリケーション開発者の連携が必要で、双方にある程度の負荷がかかります。
- これが数百、数千と積み重なると非常に大きなコストとなります。
- 現状でも自動化によって平時の運用負荷は十分低く抑えられていますが、構成を変える必要がある場合の負荷の低減が難しいという課題がありました。
既存の解決策では解決出来ない課題
最初の目標を達成するだけなら選択肢はたくさんあります。"NewSQL"という単語で代表されるような、書き込みにスケーラビリティを持ちつつも、整合性、さらにはSQLが利用できるソフトウェアはパブリッククラウド上、製品、またはOSSにも存在します。
ただ、私たちのチームではプラットフォームとして会社全体に提供するのを目的にしています。そのため、社内の多くのアプリケーションから依存されても問題ない製品を選定する必要がありました。
- 費用がなるべく低いこと
- 長期的なメンテナンスが見込まれるもの、コミュニティが開かれていて活発なこと
- ライセンスや開発主体に対する懸念がないこと
これらは通常アプリケーションのDBMSを選定する際にはあまり問題にはなりません。LINEヤフーでもサービスが必要と判断すれば個別専用のクラスターとして準備する場合もあります。
ただ、プラットフォームとして社内に提供した場合、数百のインスタンスが作られ数百のアプリケーションから依存されます。その上で十年 単位で維持するためにこれらの要件を通常よりは考慮しました。
Cassandraの課題
これらに加えて、現在社内に提供しているCassandraにもいくつか課題がありました。
- 利便性
- セカンダリインデックスの課題
- 結果整合性によって問題となるケースがあること
- 拡張性
- 特定のKeyをSplitし、スケールアウトすることができない
- 運用面
- Compactionの処理の関係でディスク容量を活用できない
- Java GC 発生時に高負荷となる
- 大容量のクラスターではRepair処理をgc_grace_seconds以下で常に完了させることが運用負担となる
互換性の問題や、ある程度トレードオフになってしまう課題もあるため、社内利用者が純粋なCassandraか、FractalDBかを選択できるようになっています。FractalDBは主キーのスキャンができたりセカンダリインデックスが使える等、Cassandraに比べて"MySQLに近い使用感"なCassandra互換DBMSになっています。
実現可能性
DBMSのすべてを内製するのはチームの規模的にも現実的ではありませんでした。
そんな中、FoundationDBがLayered Architecture (参考:Document Layer)という概念を提唱しました。これはトランザクションが使えるスケーラブルなKVSであるFoundationDBを使って、その上でクエリ処理をFoundationDBユーザーが実装することを前提とした設計です。
実際、このような疎結合なDBMSの設計は近年よく見られるようになってきていて、それぞれレイヤーの分け方は違いますがGCP CloudSpannerやAmazon Aurora、TiDB等も1つのクエリを 処理するのに、役割の違う複数のサーバーが担当する設計になっていて、この設計が一般的となっていることも後押ししました。
DBMSの開発において、難しいポイントの1つであるデータの保存をFoundationDBにすべて任せてしまい、われわれが開発するのはデータを保存しない、ステートレスなAPIサーバーのみとできます。これによって、比較的小さいチーム規模で開発・運用できるめどが立ちました。
ここまでのまとめ
まとめると、FractalDB開発の契機となった主な理由は以下の通りです。
- きっかけとなった課題
- クラウドDBの実現
- 整合性とスケーラビリティの両立
- 集約率を向上
- 運用の負荷を軽減
- 現行のCassandraの課題
- 後押しした実現可能性
- FoundationDBを活用したLayered Architectureの可能性
アーキテクチャの詳細
これらの目標を達成する上で、まずFractalDBのアーキテクチャを FractalDB: LINEヤフーのオンプレミス・マルチテナンシー型データベースシステムの紹介より少し深掘って紹介します。