CockroachDB、決して死なないデータベース

テッククランチイベント

このXCFの熾烈な試練の場において、マティスとキンボールは1995年に、おそらく史上最も人気のある写真編集ソフトであるAdobe Photoshopのオープンソース版、GIMPを開発しました。マティスとGIMPを共同開発していた頃を振り返り、キンボールはこう語ります。「ソースコードの最初の行から最後の行まで、GIMPは常にフリーソフトウェア運動への私の『貢物』でした。emacs、gcc、Linuxなどを使いこなした後、私のコンピューティング開発を大きく形作ってきたコミュニティに、本当に恩義を感じました。」

GIMPの開発は、CockroachDBで彼らが何をするかを予見していたことが判明する。「GIMPを開発した理由はCockroachを開発したのと全く同じです。Unixを使った高度な画像処理プログラムを使いたかったのですが、そのようなプログラムは存在しなかったのです」とキンボール氏は語る。「だから、自分たちで何とかしようと考えたのです。2015年にCockroachの開発に真剣に取り組み始めた時も、同じような考え方を持っていました。『これが必要だ。存在しない。これは世界中の多くの人々に大きな変化をもたらす可能性がある』と。」

GIMPは大成功を収めました。ラリーとセルゲイとの出会い、そしてこの写真編集ソフトを使った経験を振り返りながら、キンボールは「GIMPは、いつまでも喜びを与えてくれる贈り物です」と語りました。

Googleの初期のWebスケールの構築

マティスは1995年にバークレー大学を卒業しましたが、キンボールにはまだ2年間の在籍期間がありました。二人は連絡を取り合い、ドットコムバブルの絶頂期に様々なベンチャー企業に参画しました。そして2002年、マティスはGoogleに就職しました。彼は会社を大変気に入り、3ヶ月後にはキンボールをGoogleに招き入れるべく尽力しました。Cockroach Labsの3人目の共同創業者であるベン・ダーネルも、この頃Googleに入社しました。

Googleは驚異的な速度で成長し、データ管理に苦戦していました。AdWordsサービスだけでも、膨大な量のデータが生成され、保存・処理が必要でした。AdWordsは金鉱でしたが、同時にGoogleのデータベースを限界まで追い込んでいました。

キンボールは問題を詳しく調査した。「私がGoogleに着任した当時、私はAdWords製品を担当していました。データベースに大きな問題を抱えていました。MySQLで一種のシャーディングアーキテクチャを採用していましたが、そのアーキテクチャの不適切さが原因で軋んでいました」と彼は語った。「シャード数は1から2、4から8、16から32へと増加していきました。Googleは最終的にそのシャーディングアーキテクチャを禁止しました。これは興味深いことです。なぜなら、当時のシリコンバレーの他のスタートアップ企業は皆、そのアーキテクチャを採用していたからです。Googleは、より優れたものを構築すると述べました。」

彼らはそうしました、しかしその前に袋小路に入ってしまいました。

Googleは最初の試みとしてNoSQLソリューションを試しました。SQLデータベースはデータを多数のテーブルに分割して個別に保存しますが、NoSQLデータベースはデータをドキュメントの集合として保存します。当時のNoSQLデータベース（Googleのものも含む）の設計における大きな欠点の一つは、トランザクションをサポートしていなかったことです。

データを変更する際には、トランザクションが不可欠です。トランザクションの一般的な例としては、航空券の購入、ホテルの予約、レンタカーの予約を含む旅行の予約が挙げられます。エンタープライズデータアーキテクチャでは、通常、航空券、ホテル、レンタカーのデータは別々に存在します。したがって、旅行予約を正常に行うには、これら3つのデータがすべて適切に保存され、同期して更新される必要があります。

図1に示すように、トランザクションはこの種の問題を解決します。まず航空券が購入され、次にホテルが予約され、最後にレンタカーがレンタルされます。すべてがうまくいけば、トランザクションはコミットされます。レンタカーデータベースがダウンするなど、いずれかの時点で問題が発生した場合、データベースは航空券とホテルの予約をキャンセルし、トランザクションが失敗したと報告します。

トランザクションの利点は、ストレージ層でデータの整合性が確保され、開発者がアプリケーションの機能開発に集中できることです。欠点は、各トランザクションがデータベース内のテーブルをロックし、他のユーザーが使用できなくなるため、データベースのパフォーマンスが大幅に制限される可能性があることです。数百万、そして数十億のユーザーがインターネットに殺到す​​るにつれ、複数のアプリケーションをまたいで多数のユーザーを同時にサポートすることが不可欠になりました。

こうした欠点にもかかわらず、GoogleはNoSQL技術の開発に注力していました。「Googleのアプリケーション開発者からの報告は明確でした。彼らは一様に、NoSQLは弾力的なスケーリングなどができる素晴らしい技術だと述べていましたが、もはやトランザクション処理はできない、と」とキンボール氏は語ります。「AdWordsチームは、『500ものテーブルと複雑なリレーションシップがあり、SQLデータベースには高度な技術が備わっているため、それを避けては以前と同じことを実行できない』と言っていました」

アプリケーション開発者からの根強い懸念を受けて、Googleは2006年に、世界規模のトランザクションを必要とするプロジェクトのニーズを満たすために設計されたリレーショナルデータベースを開発しました。GoogleはこのデータベースをSpannerと名付け、現在もGoogle Cloudの中核サービスとして機能しています。「GoogleがSQLを復活させたのは、AdWordsをその方向に進めたいと考えたからです」とキンボール氏は語ります。「私がGoogleを去る頃には、SpannerはGoogleのほとんどの業務の基盤となっていました。」

Googleにおけるインフラをめぐる争いは、やがて急成長するインターネット経済全体に波及することになる。「まるで水晶玉を覗き込み、『2020年に人々が求めるデータベースのパラメータは何か？』と自問自答しているようなものでした。私は2010年にその答えを知っていました。なぜなら、Googleがその問いに答えを出していたし、私もその場にいたからです」とキンボール氏は語った。

CockroachDB の創業者3人は、最終的にGoogleを去りました。ダーネルは2009年にGoogleを去り、スタートアップ企業のFriendFeedに入社しました。FriendFeedは2009年にFacebookに買収され、最終的に閉鎖されました。キンボールとマティスは2012年にGoogleを去り、Viewfinderという会社を設立しました。2012年当時Dropboxで働いていたダーネルは、数か月後にViewfinderに加わりました。

ビューファインダー、スクエア、分散トランザクションの問題解決

Viewfinderで3人は、「CockroachDB」の必要性がGoogleだけでなく、ウェブ上で事業を展開するすべての企業において明白に明らかになったことに気づきました。Viewfinderは、Flickrに匹敵する規模で、SnapchatやInstagramに匹敵するポテンシャルを秘めた写真共有サービスで、世界中の何百万人ものユーザーに最高のユーザーエクスペリエンスを提供することを目指していました。これは、オーストラリア、ヨーロッパ、アメリカなど、地球上のどこにいてもユーザーが様々な形式のデータに即座にアクセスできることを意味していました。

当初、このスタートアップはAmazon Web ServiceのNoSQLデータベースであるDynamoDBを使用していましたが、その取り組みは苦戦続きでした。「エンジニアリング時間の約3分の1をデータベースの問題解決に費やしていました。これは珍しいことではありません」とキンボール氏は言います。

同社は消費者の支持を得るのに苦労しており、最終的にViewfinderは2013年にデジタル決済会社Squareに買収されました。世界的な金融取引に重点を置いていたSquareは、世界規模のデータ管理の課題に対処するためにエンジニアリングの才能を必要としていました。

同社はキンバル、マティス、ダーネルに新たなスタートと広い自由を与えた。スクエア在籍中、彼らはオープンソースの設計文書を作成し、グローバル規模の取引をサポートするリレーショナルデータベースがどのように動作するべきかを詳細に記述した。彼らの文書は、GoogleがSpannerについて発表した論文を読んだオープンソースコミュニティの多くの人々の注目を集めた。

彼らの論文は、データベース市場への投資に意欲的なベンチャーキャピタリスト数名の注目を集めました。2015年にCockroach Labsが誕生しましたが、ベータ版リリースの準備が整うまでには、さらに1年間の作業が必要でした。

地球規模のデータベースの構築

GoogleのSpannerに関する論文と自社の設計ドキュメントに大きなインスピレーションを得た3人の共同創設者は、基盤技術のライセンスに関して意見が分かれました。Spannerとは異なり、CockroachDBはオープンソースコードであり、現在もGitHubで公開されています。

CockroachDB は、開発者が複数の地理的地域にまたがるデータベースを作成できるように設計されています。このテクノロジーには3つの主要な機能があり、これらについてはこの EC-1 のパート2で詳しく説明します。1つ目は、データを特定の地理的地域にローカライズできることです。つまり、ニューヨークのユーザーに関連するデータを東海岸のデータセンターに保存することが可能です。2つ目は、データベースへのクエリ実行時にすべてのデータが正確であることを保証します。3つ目は、堅牢なデータレプリケーション機能により、データセンターがダウンした場合でもデータが常に利用可能であることを保証します。

これら3つの特徴を組み合わせることで、業界を定義づけるほどの巨大企業となる可能性を秘めたデータベースが誕生します。結局のところ、CockroachDBという名前には理由があります。「これは、その堅牢性の証です。ゴキブリのように、壊れないのです」とキンボール氏は言います。（少なくともデータベースの名前としては、記憶に残りやすい名前でもあります。）

当初の収益モデルは、エンタープライズレベルでサポートサービスを販売し、高度な機能を必要とする企業にはエンタープライズライセンス料を請求することでした。しかし、それは過去の話であり、今は違います。企業は今でもCockroachDBのエンタープライズライセンスとサポートサービスを購入できますが、Cockroach Labsはデータベース・アズ・ア・サービス（DBaaS）製品であるCockroachCloudに大きな力を入れており、これについてはパート3で詳しく取り上げます。

Cockroach Labs は、創業者が2012年にGoogleを去って以来、長い道のりを歩んできました。ニューヨーク市に拠点を置く同社は、フィンテックや広告企業にとってニューヨークが最適だという従来の考えに反し、まさに同社が必要​​とするタイプの技術系人材を擁しています。ニューヨーク市とシリコンバレーの開発者採用について話す際、キンボール氏は「ここの人たちはベイエリアの人たちほど金銭的な要求は強くありません。ニューヨークのエコシステムは、私たちと同じくらい急速に成長してきたのです」と述べています。

同社は前年比300%弱の成長を遂げており、2020年の売上高は2019年の2倍となっているが、具体的な数字は明らかにしていない。Crunchbaseによると、現在、Cockroach Labsは250人以上の従業員を抱え、Benchmark、GV、Index Ventures、Redpointといった企業から総額3億5000万ドル以上の投資を受けている。

おそらく最も重要なのは、オープンソースのコードベースに300人以上の外部貢献者がいることです。Cockroach Labsは開発者によって設立され、今日までそのルーツを忠実に守り続けています。同社は開発者のサポートとトレーニングにも多額の投資を行っています。

キンボール、マティス、ダーネルの3人は、Googleとその後の2つのスタートアップでの経験から得た洞察が、CockroachDBを他のデータベースとは一線を画すものにしていると考えています。彼らは車輪の再発明をしているのではなく、Googleで生まれたアイデアを長年かけて発展させてきた技術を進化させているのです。その歴史、エンジニアリングの鋭さ、開発者の関心の広さ、そして豊富な資金力を考えると、CockroachDB、そしてひいてはCockroachCloudは、現在そして近い将来、分散データベースとデータベースサービスの世界で大きな存在感を示すことになるでしょう。

しかし、その将来を理解するには、CockroachDB の基盤となる製品を理解する必要があり、この点についてはこの EC-1 のパート 2 で説明します。

レイテンシとの世界的戦争でエンジニアがCAP定理とどう戦ったか

CockroachDB EC-1 目次

• 導入
• パート1：起源の物語
• パート2：技術設計
• パート3: 開発者との関係とビジネス
• 第4部：競争環境と将来

Extra Crunch の他の EC-1 もチェックしてください。