2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

foundationdb-logo.png

はじめに

クラウドコンピューティングの進化は、データベース技術にも革新をもたらしています。その中で、高度なスケーラビリティ、堅牢性、および柔軟性を兼ね備えた分散型キーバリューストアであるFoundationDBは、注目を集めています。オープンソースプロジェクトとして提供されているこのデータベースは、シンプルなキーバリューモデルを基盤としながら、豊富なデータモデルやAPIをサポートする「レイヤー」を通じて、多様なアプリケーションやサービスに適用可能なデータベース基盤となっています。

今回はFoundationDBの基本的な概要から始めて、その設計コンセプト、アーキテクチャ、そして選定する際に考慮すべき制限事項を、公開されている論文[8][9]を中心に要約する形で解説します。

FoundationDBとは?

FoundationDBは、高度なスケーラビリティ、堅牢性、および柔軟性を備えた分散型のキーバリューストアです。現在はApple Inc.によりオープンソースプロジェクトとして広く提供されています。FoundationDB自体は、シンプルなキーバリューモデルとする基盤であり、従来のデータベースによるデータモデルやAPIについては、その上位「レイヤー」で実現する手法を取ります。

このデータベースの最大の特徴は、分散環境においてもデータの整合性と信頼性を保証するACIDトランザクションの実装にあります。これにより、複雑なトランザクションをシンプルに扱うことが可能となります。さらに、水平方向にスケーラブルな特性を持ち、クラウドインフラストラクチャの基盤として、または大規模なデータセットを扱うアプリケーションの理想的なバックエンドとしても注目されています。

開発者はFoundationDBの堅牢なトランザクション機能と分散システムの特性を活用しつつ、アプリケーション特有のニーズに合わせたデータモデルを柔軟に実装できるという利点があります。

FoundationDBのレイヤーコンセプト

FoundationDBのレイヤコンセプトは、極限まで単純化されたコア機能と、それを基にした上位レイヤでの機能追加という設計思想に基づいています。AppleはFoundationDBのオープンソース化時に、強力かつ単純なコアをベースにして、上位レイヤで追加機能を構築するという新しいデータベース構築のコンセプトを提案しました。このアプローチは、ストレージ層とデータモデル、インデックスを分離し、疎結合なデータベースの構築を指針としています。

FoundationDB自体のデータモデルは非常に単純なキーバリューストアですが、このレイヤコンセプトに沿って、利用者はリレーショナルデータモデル、グラフデータベース、または特定のビジネスロジックなどのレイヤを実装することが可能です。この柔軟性により、FoundationDBは様々な種類のアプリケーションやサービスに適用できる非常に汎用的なデータベース基盤となっています。

レイヤ実装の例としては、AppleによるMongoDB互換の「Document Layer」やCloudKitのバックエンドとなる「Record Layer」、Linux Foundationによる「JanusGraph」などがあります。

FoundationDBのアーキテクチャ

FoundationDBのアーキテクチャは、クリティカルなシステムメタデータの管理とクラスター全体のオーケストレーションを担うコントロールプレーン(Control Plane)と、トランザクション処理とデータストレージを行うデータプレーン(Data Plane)から構成されています。

foundationdb_01.png

コントロールプレーン

コントロールプレーンは、トランザクションシステムの設定や重要なシステムメタデータを保持する役割を持ちます。コーディネーター(Coordinator)は合意アルゴリズムであるPaxosグループを形成し、クラスターコントローラーを選出します。シーケンサー(Sequencer)はトランザクションに読み取りとコミットのバージョンを割り当て、データディストリビューター(Data Distributor)は障害の監視とストレージサーバー間のデータバランスを取ります。レートキーパー(Rate keeper)はクラスターの過負荷保護を提供し、クラスターコントローラー(Cluster Controller)はクラスター内の全サーバーを監視し、シーケンサー、データディストリビューター、レートキーパーといったプロセスを管理します。これらのプロセスは障害時に再配置される設計になっています。

データプレーン

データプレーンは、読み取りを主とする小規模なキーセットの読み書き、低競合、スケーラビリティが必要なOLTPワークロードを対象としています。アンバンドルアーキテクチャを採用し、インメモリでのトランザクション処理を行う分散トランザクションシステム(Transaction System)、Write-Ahead-Logを保存するログシステム、データの保存と読み取りサービスを提供する分散ストレージシステム(Storage System)で構成されています。トランザクション処理はトランザクションシステムのシーケンサー(Sequencer)、プロキシ(Proxy)、リゾルバー(Resolver)などのステートレスプロセスから構成され、ストレージシステムのサーバーは連続したキーレンジのデータシャードを保存し、分散B-treeを形成します。ストレージエンジンにはSQLiteの改良版が使用されています。

FoundationDBは、このコントロールプレーンとデータプレーンによるアーキテクチャにより、高い可用性、スケーラビリティ、および堅牢性を実現しています。

FoundationDBの制限

単純かつ強力なFoundationDBですが、レイヤを設計する上でいくつかの重要な制限事項があります。これらの制限事項には、FoundationDB設計上の制限と、現時点の実装上の制限があり、適用アプリケーションで許容できるかの判断が必要となります。

設計上の制限事項としては、トランザクションのサイズは10,000,000バイト以内に制限され、キーのサイズは10,000バイト以内、値のサイズも100,000バイト以内に制限されています。また、性能上も1MBを超えるトランザクションは推奨されず、SSDを前提としているためHDDでの運用は想定されていません。

現時点の制限事項としては、トランザクションの実行時間は最大5秒に制限されており、最大500コア/プロセスを想定した最適化、最大100TBのデータベースサイズを想定した試験が実行されています。セキュリティの観点では、FoundationDBクラスターに接続できる任意のユーザーは、データベース内のすべてのキーを読み書きできるなどの制限に留意する必要があります。

最後に

FoundationDBは、シンプルで強力なコア機能の提供に注力しており、その柔軟性、スケーラビリティ、そして堅牢性により、様々なアプリケーションやサービスに適用可能な強力なデータベース基盤となります。オープンソースとして提供されており、データベース技術の未来を形作る上で重要な役割を果たし、今後の発展が期待されます。

参考資料

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?