FoundationDBはACIDを保証しながらNoSQL並の可用性と性能を提供するデータベースだ。InfoQはこのプロジェクトの創立者のひとりであるNick Lavezzo氏へ独占インタビューを行い、詳しい話を聞いた。
InfoQ: FoundationDBは読み取りと書き込み用の異なる2つのノードを利用することでCAP定理が定義する限界を回避し、ACIDとスケーラビリティを両立させていると聞きました。これは正しいですか。アーキテクチャを詳しく教えてください。
Nick: FoundationDBはCAP定理を回避していません。ネットワークの分断がある中で一貫性を維持するために従来の発想に捕らわれない方法(NoSQL向け)を採用しているだけです。分散していながら、完全に一貫しているデータベースを実現するのは大変難しいので、単純化して別のサーバに異なる役割を与えました。最も重要な2つの役割とは、トランザクションサーバとストレージサーバです。トランザクションサーバはACIDを保証するために衝突の検出を行います。ストレージサーバはkey-valueペアのチャンクを保持し、トランザクションサーバが許可した読み取りと書き込みを提供します。もちろん、単一の物理マシンや小さなクラスタで役割を重複させてひとつのコンピュータでひとつ以上のタスクを実行することもできます。もっと詳しい内容は私たちのサイトの説明をご覧下さい。
InfoQ: FoundationDBと"レイヤ"のエコシステムはオープンソースと商用版の両方で提供されると聞きました。ソースは既に利用できるようになっているのですか。
Nick: データベースのコアを構築するのに注力していますので、おおやけにできるほど内部のレイヤはきれいになっていませんし、ドキュメントもありません(アルファ版のテスターが要求すればソースを開示しています)。レイヤの公開リポジトリはベータ版に向けて準備しようと思っています。レイヤは高レベルのデータモデルを見るための素晴らしいツールとして利用できます。また、FoundationDBのkey-value APIを使えばいかに簡単に強力な仕組みが構築できるかを示すデモにもなっています。レイヤ/アプリケーションコードに興味のある方はここの事例をご覧下さい。
InfoQ: C++上に構築されたFlowという新しい言語とツールを提供するようですね。詳しく聞かせてください。
Nick:私たちのサイトの新しいセクションでFlowとその目的を説明しています。
InfoQ: すれにFoundationDBを使ってアプリケーションを開発している人はいますか。
Nick:私たちのテスターはFoundationDBを使ってアプリケーション開発をしています。でもこのような事例を聞きたいのではないですよね。実運用環境での実績を聞きたいのだと思います。FoundationDBは現在アルファ版です。数週間前にスナップショットバックアップ機能の提供を始めるまでは、実運用環境環境では利用しないようにアドバイスをしていました。システムがどのくらい耐障害性を備えているかが問題なのではなく、誰かが間違えて(あるいは意図的に)データを消してしまった場合、復旧させるには外部に保持しているバックアップが必要です。現在ではバックアップ機能があるため、アルファ版のテスターと協力して実運用環境で使うプロジェクトを実施しています。
InfoQ: FoundationDBはGoogle Spannerのようにノードをグローバルに分散させることはできますか。そのようなことができるようにする予定はありますか。どのように実現するつもりですか。
Nick:あります。FoundationDBはローカルでもデータセンターをまたいだクラスタでも利用できるように設計しています。FoundationDBはマルチデータセンター構成の場合、ネットワークのトポロジを理解し、複製を異なるデータセンターに保持する、といったようなインテリジェントな動作をします。しかし、Google Spannerのように、FoundationDBは全世界のデータセンターを使って単一の世界規模のデータベースを作るという用途としては設計されていません。近くにある複数のデータセンターで効率よく動作するように設計されています(高速なアクセスを実現するためにデータを世界中に自動的に移動させるのは、データを読み取るという点では可能ですが、書き込みの場合は難しく、アプリケーション固有の処理になってしまいます。Neither SpannerもFoundationDBもそのような処理には取り組んできません)
どのように実現するかですが、最も簡単に説明すると、FoundationDBやSpannerのようなシステムの場合、複雑なレイヤ状の保証が搭載されており、それが合わさって全体の整合性を保つようになっています。Spannerは単一の“グローバル変数”である時間を使ってクラスタのすべてのノードをまたいで強い推論をすることで整合性を保っています。例えばコンピュータAがある値を更新し、その値をコンピュータBが読み取る場合、Aが書き込んだよりも後にBが読み取りをした場合、SpannerのTrueTimeはBが変更後の値を読んでいることを保証します。FoundationDBの方式は異なります。Paxosと呼ばれるアルゴリズムを使って小さな情報(私たちの“グローバル変数”)を保存し、保証を構築して、そこから推論します。時間には依存しません。