✨

Google SpannerはCockroachDBがそれを凌駕する刺激に

2023/03/30に公開

ペストや核戦争によってもたらされる黙示録的な世界ではゴキブリとローリング・ストーンズのギタリスト、キース・リチャーズの2つだけが生き残るという古いジョークがある。Googleの分散型リレーショナルデータベースSpannerのクローンである新興ソフトウェア企業Cockroach Labsが何があっても生き残るシステムを象徴するものとしてこの特定の昆虫を選んだ理由はニューヨーク市出身であることから理解できるでしょう。しかし、RichardsDBと呼ぶこともできたはずです。

今週初めにベータ版が公開されたGoogleのSpannerのクラウド実装について説明したとき、私たちはCockroachDBの取り組みの背後にいる人たちと話をすることを約束しました。彼らは偶然にも全員が検索エンジンの巨人の出身で、Googleを際立たせるソフトウェアインフラの主要部分に携わっていた人たちです。私たちはCockroachDBがデータベース市場を揺るがす可能性があると考えています。CockroachDBの背後にいる人々がGoogleが行ったことを深く理解しているからだけでなく、より重要なのはSpannerに具現化されているアイデアとフリーでオープンソースのCockroachDBにコード化されているアイデアを商業化するには、非常に異なるアプローチが必要であることが理解できたことです。

複雑なシステムからシンプルさを求め、瞬時に、簡単に、地理的に拡張することを望む企業顧客の間で変化の機が熟しているデータベース市場において、CockroachDBはYahooのHadoopやHDFSからGoogleのMapReduceやGoogle File Systemになる可能性を秘めています。

Cockroach Labsの共同設立者兼CEOであるスペンサー・キンボールは、投げつける必要性を感じず、ニューヨークの歩道にそっとガントレットを置く。「私たちは、Googleの後を永遠に追い続けることに、企業として満足していません」とキンボール氏はThe Next Platformに語っています。「なぜなら、Googleは10年以上かけてSpannerを開発し、それが必要だという結論に達し、血と汗と涙と膨大な数のユースケースを経て、Spannerを進化させたからです。そして完成したのが、主要なユースケースをすべて移行させるソリューションであり、これは業界の方向性を示す基本的な指標となるものです。しかし、我々は彼らの後を追うだけで満足するつもりはありません」。

キンボールと共同創業者のピーター・マティス、ベン・ダーネルはいずれもGoogle出身で、Googleのハードウェアとソフトウェアのインフラがどのように機能するかについて十分に知っています。キンボールはオープンソースのグラフィック編集ツール「GIMP」の共同開発者であり、20年以上前のドットコムブーム時にカリフォルニア大学バークレー校在学中に作ったものです。マティスは大学時代のルームメイトで、GIMPのもう一人の生みの親です。二人ともGoogleに入社し、検索エンジン、そして広告配信ビジネスでライバルに差をつけた初代Googleファイルシステムの後継であるColossus分散ファイルシステムに携わりました。ダーネルは数年前にViewFinderという会社（Squareに売却）でキンボールやマティスとともに働き、それ以前はGoogleや他のいくつかの会社で自分の仕事をし、現在はCockroach Labsの最高技術責任者、マティスはエンジニアリング担当副社長です。そして彼らに共通する3つのことは、GoogleのColossusファイルシステム、そしてBigTableとSpannerデータベースを使い、それを新しいプロジェクトに使いたいと思いました。しかし、それはオープンソースではありませんでした。そこで2014年末、彼らはそれをクローン化することにしました。

この2年間で3人の元GoogleソフトウェアエンジニアはBenchmark CapitalとIndex Venturesを中心に、ちなみにGoogle Venturesからも少し甘めに、その他半ダースのベンチャー資金を調達し、最初の2ラウンドで2650万ドルを調達しました。現在、従業員数は33名で急速に成長しています。CockroachDBの分散型データベースは会社設立直後の2015年にアルファテストに入り、2016年中はベータテストを行ってきた。同社は第1四半期の終わり、つまり来月中に正式な1.0リリースを行う準備を整えつつあります。Googleが2週間後に開催される自社のNext '17カンファレンスに先駆けてCloud Spannerサービスを開始した理由を考えてみると、オープンソースのクローンであるCockroachDBから少し雷を落とそうとしたのかもしれません。

エンタープライズを超えて

SpannerとそのクローンであるCockroachDBが同時に解決しようとしている問題は複数あり、GoogleはMegastoreとBigTableデータベースサービス、そしてSpannerの地理的に複製されたBigTableの進化を構築した15年の経験を持っています。それをキンボール、マティス、ダーネルは（文字通りではなく比喩として、ちょうどYahooのDoug CuttingがHadoopとHDFSを作るためにMapReduceとGFSに影響を受けたように）オープンソースかつエンタープライズ級のSpanner代替物を作成できました。

すべてのアプリケーションはデータを保存する何らかの手段を必要とします。生のフォーマットで、またはインデックス化し、より簡単に、より素早く検索できるようにするために何らかの構造が巻かれたデータベースでデータを保存することができます。昔、Googleはデータサービスを1つのデータセンターで運営していましたが、何らかの理由で障害が発生するとそのサービスは停止し、アプリケーションはオフラインになります。これは明らかに容認できないことでした。Googleの次の進化段階、つまり現在の多くの企業ではバックアップシステムを構築し、データベースを常に別のデータセンターに複製しています。ミッションクリティカルなアプリケーションの場合、ほとんどの企業はその第二のデータセンターで実行できるようにハードウェアとソフトウェアのスタンバイセットを用意しており、障害が発生した場合はそれが起動することを望んでいます。「普段はアクティブではなく、スタンバイモードになっており、その場合、物が腐り、立ち上がらないことがよくあります」とキンボール氏は説明します。「これは製品の観点からも問題です」

しかし、この高可用性フェイルオーバーモードにはさらに陰湿な問題があります。非同期処理を使うためデータセンター間で複製されるデータにタイムラグが発生するのです。データセンター間でレプリケートされるデータは非同期処理であるため遅延が生じます。

そのため、GoogleはSpannerでPaxosコンセンサスとマルチアクティブアベイラビリティを実装しました。このセットアップでは最低3組のコンピュート（シングルノードでもノードクラスタでも可）をセットアップし、LANまたはWANでリンクし、非常に厳格なタイムキーピングを行う必要があります。Googleはデータセンターで原子時計とGPS受信機を使用し、TrueTimeというプロトコルを使ってノードやクラスタのコンピュート部分に書き込まれるトランザクションのタイムスタンプを正確に記録しています。分散データベースに書き込みを行うには3つのノードのうち少なくとも2つのノードがデータを持ち、書き込みに成功したことに同意する必要があります。Googleがより多くのノードやクラスター、地域にまたがるデータベースを持つ場合、合意レベルを引き上げることができます。

「CockroachとSpannerはその機能を見ると非常によく似ています。」とキンボールは言います。「最大の違いは、私たちはさまざまな環境で動作するものを作っており、原子時計や特殊なハードウェアに頼ることができないことです。そのため、私たちが提供する微妙な保証が大きく変わりました。原子時計がどこにでもあるため、Googleは線形化可能な分離を提供でき、CockroachDBは直列化可能な分離を提供します。これは依然として非常に強い保証ですが、原子時計で得られるものにはまだ及びません。重要なのはCockroachDBは原子時計を与えればSpannerと全く同じ振る舞いができることです。CockroachDBとSpannerの違いは、Spannerはシステム内の任意の2つの時計間の可能なオフセットに対してはるかに小さな境界で動作できることで、CockroachはNetwork Time Protocolに頼る必要があることです。これが大きな違いであり、かなり微妙な違いです」

他にも大きな違いがありますが、それは追って説明します。

キンボール氏、マティス氏、ダーネル氏はCockroachDBを作るにあたって、完全にゼロから始めたわけではありません。他のオープンソースプロジェクトと同様、CockroachDBは他の人が行った先行研究を利用しています。その中にはGoogleやFacebookのデータベース界の著名人も含まれています。

CockroachDBはFacebookが作成したRocksDBという低レベルのストレージエンジンをベースにしており、CockroachDBクラスタを構成するサーバーノードのディスクやフラッシュストレージへのインターフェースとなっている。このRocksDBストレージエンジンは、Googleが作成しオープンソース化したLevelDBというキーバリューストレージエンジンから派生したもので、GoogleのBigTableデータベースサービスやSpannerデータベースサービスで具現化されたアイデアをベースにしています。(BigTableは水平方向に拡張可能なSQLデータベースの単一インスタンスで、SpannerはレプリケーションにPaxosコンセンサスを使用した地理的に分散したものである)。

CockroachDBの大部分はGoで書かれています。GoはUnixとCをもたらしたベル研究所のプログラマの一人で最近ではGoogleで働くロブ・パイクが作った言語です。GoはGooglerに人気があります。KubernetesもTensorFlowもGoで書かれています。GoはC++を劇的に簡略化したもので、キンボール氏はコードの構造化には非常に意見が多いため、そのコードの書き方の違いが少なくオープンソースのコードがプロジェクト間や中でうまく並ぶようになると述べています。また、C++のコードと統合するための洗練されたサービスもあり、パフォーマンスを上げるためにコードをできるだけ鉄に近づけたいというスポットでよく使われるそうです。ちなみにRocksDBはそれ自体がC++で書かれており、Cockroach Labsによって少し手を加えられています。

コンセンサスレプリケーションについては、CockroachDBはGoogleが採用したPaxos方式ではなく、その名を冠した（そしてAndroidにインスパイアされた）LinuxディストリビューションやTectonicという商用Kubernetesプラットフォームを作成したCoreOSが作ったetcdを利用しています。厳密にはこのコンセンサス機構はRaftと呼ばれる方式をベースにしています。

このマルチアクティブな可用性メカニズムに加えて、CockroachDBはデータセットの成長に合わせてデータを自動的にシャードし、ローカルノードに拡散します。ネットワークにサーバーノードを追加するだけで、このようなことが勝手に行われ、水平方向のスケーラビリティを実現しています。

「スケールは非常に重要です。多くの企業はスケールを必要とせず、データベースの単一インスタンスですべてを維持し、スケールアップし続けることができると感じています」とスペンサーは諭す。「しかし、現実には企業が生成している大量のデータのうち、運用システムで一緒に保存していないものがあり、それを他のシステムに置くことでデータアーキテクチャを複雑にしていることが多いのです。スケールは一般的に言われているよりもより一般的なニーズであると言えるでしょう。もちろん、スケールが必要でデータベースのシャーディングに苦労している企業もあります。そのような企業にとってSQLを使いながらスケーリングできるシステムは重要なイノベーションであることは明らかです。

これは明らかに想像以上に厄介なことで、サーバーをラック内でローカルに複製するだけでなく、ラック間やデータセンター、地域間で複製し、特定の種類の障害に対する耐性を高めることができます。このように、SpannerとCockroachDBは似ています。しかし、いくつかの重要な点で大きく異なっています。

1つはパッケージ化された方法であり、これはGoogleがBorg/Omegaクラスタおよびコンテナ管理システムの変種をオープンソース化することを困難にしている点です。

Googleは何事にもレイヤーアプローチをとっています。Spannerは単独で動作する1つのシステムではなく、他のシステムの上に乗って動作します。Zookeeperによく似たChubbyを使い、TrueTimeという原子時計システムを使い、その下に分散ファイルシステムであるColossusを使っています。そして、ColossusはDというシステムの上に構築されています。Dはサーバーノードからディスク容量をエクスポートするサービスです。

PostgresはMySQLや他のデータベース管理システムを模倣するのではなく、別の理由で選択されました。オープンソースのPostgresデータベースはSQLとプログラマーの間に翻訳層を作るオブジェクトリレーショナルマッピングと呼ばれる高次抽象化機能の実装が優れているのです。プログラマーとデータベース設計者はインメモリデータ構造を配置したオブジェクトに対する考え方が大きく異なっており、ORMはデータベース設計者が望むことを標準的なSQLインターフェースを用いて実現する方法をプログラマーに提供するとキンボールは言います。

「そこにはインピーダンスミスマッチがあり、それはかなり極端です」とキンボール氏は言います。「そのため、プログラミング環境からSQLを使ってデータにアクセスするのは非常に厄介です。そこで、このオブジェクトリレーショナルマップはSQLとプログラマの間に翻訳レイヤーを作り、CockroachDBやこれをサポートする他のデータベースが非常に標準的なSQLインターフェースを持つことを要求しています。Spannerは（これはGoogle側の非常に興味深い決定であり、クラウドにおけるBigTableの初期の失敗という点で持続している考え方を示唆しています）標準的なSQLインタフェースを持ちません。一方、読み取り専用のクエリではSELECTメカニズムを使用し、非常に標準的です。BigTableは優れた最新のSQL構文を作成し、いくつかの新しいものを導入しています。しかし、Spannerサーバーがアプリケーションに提供するAPIには、SQLを何らかの方言で期待する膨大な数のツールを可能にするために、十分な親しみやすい表面領域が作られていないのです。挿入と更新を行うための完全に独自のRPCベースのインターフェイスを持っていますが、これは奇妙な選択であり明らかに採用の障壁となることがわかります。彼らのロードマップがどうなっているかは分かりませんが、もしかしたらこれを大いに改良して、標準的なORMを使えるようにするのかもしれません。しかし、これは彼らの興味深い製品決定でした。私たちはまったく別の道を歩み、これらのORMを動作させる必要があると考え、それを実現するために1.0のリリースを遅らせる可能性もありました。これは非常に重要なことで、人々はこのデータベースをどのように使っているのか、開発者の足元を切り崩すようなことはしてはいけないのです。彼らの計画について予言するつもりはありませんが、彼らは非常に多くのリソースとプログラマーを持っているので、Spannerをどこにでも連れて行くことができます。

CockroachDBは重要なSQL 92標準のほとんどをサポートし、SQL 2011のいくつかの機能とGoogle独自のいくつかのSpanner機能を備えています。Cockroach Labsはフルテキストインデックスに役立つネイティブJSONサポートなどのNoSQL機能を追加し、おそらく1.0リリースをきっかけにジオパーティション機能を追加する予定です。価格についてはキンボール氏はまだ設定していないが、MongoDB NoSQLデータベースの企業向けサブスクリプションより安くなることはなく、Oracleの同名データベースとそのRAC拡張機能より安くなるとある種の皮肉を込めて述べている。

パフォーマンスに関してはストレージにSSDを搭載したノードでそれなりの速度の普通のイーサネット・ネットワークを使用して、Cockroach Labsはデータベースを100ノードまで拡張し、コードの最適化なしで1秒間に約5万件のスループットを提供することができました。これは1日に約70億件のトランザクションに相当し、帯域や低レイテンシで特別ではないWAN上で動作し、読み取りと書き込みトランザクションを50ミリ秒以下で提供でき、1ミリ秒以下で提供できる場合もあります。

CockroachDBの最も重要な点は、プライベートクラウドやパブリッククラウド、あるいはその両方にデプロイできることでしょう。自動レプリケーションがあるため、これは単に異なるセットのインフラ間でデータを複製する方法ではなく、異なるインフラにデータを移動する方法です。CockroachDBクラスターを立ち上げてデータを取得し、その後、何かをオフにすればデータを移植するために他のことをする必要はありません。企業はこのポータビリティを気に入ることでしょう。

「DropboxがAWSのS3で経験したことは、現代企業にとって最も重要な資産を、クラウドベンダーの専有ストレージシステムに委ねることがいかに危険であるかを示しています」とキンボール氏は言う。「DropboxはS3に代わるストレージのアーキテクチャーにおそらく1世紀もの時間を費やしましたが、それは経済的な理由から、そしてAWSがS3で提供していた大規模なボリュームディスカウントにもかかわらず、非常に意図的に選択されたものでした。ある時点でコスト曲線は逆転します。ストレージのような付加的なサービスを導入するのは非常に安価ですが、ある時点でAmazonの利益率を考慮しなければなりません。規模の経済があり、最終的には自分でやることになるのです」

エンタープライズを超えて

Discussion