CockroachDBは、Googleを離れた元エンジニアSpencer Kimball、Peter Mattis、Ben Darnellの3人が2015年に公開した分散SQLデータベースです。Google Spannerの2012年論文を強く意識した設計で、PostgreSQL互換のワイヤープロトコルを採用しながら、地理分散と強い整合性を両立する点が特徴です。「叩いてもなかなか死なないゴキブリのように」というネーミング由来そのままに、ノード障害に強い設計を売りにしています。
この記事の目次
- Spanner DNAを引き継ぐ三特性
- 創業から現在までの歩み
- 活躍する典型シナリオ
- 競合する分散SQLとの比較
- まとめ
Spanner DNAを引き継ぐ三特性
CockroachDBは、データを Range と呼ぶ64MB前後の塊に分割し、Raftコンセンサスで3レプリカずつ複製します。リーダーが落ちても自動的にフォロワーが昇格するため、ノード障害時もアプリ側にトランザクション失敗が伝わりません。分散DBでありながらSQL（PostgreSQLワイヤープロトコル）でアクセスでき、既存のPostgreSQLクライアントがほぼそのまま動きます。
整合性レベルは標準でシリアライザブル。Spannerが原子時計とGPSを使うTrueTimeで実現したことを、CockroachDBはNTP同期とハイブリッド論理クロック（HLC）で近似します。厳密にはSpanner並みの保証ではないものの、汎用ハードウェア上で実用十分な精度を出している点が評価されています。
創業から現在までの歩み
Cockroach Labsの創業は2014年。Kimball氏はGmail、Mattis氏はColossus、Darnell氏はGoogle Reader出身で、揃ってGoogle社内インフラの知見を持ち寄った布陣です。GitHubで2015年に初公開、2017年に正式なV1.0をリリース、2019年に企業向けGAという段階を踏みました。
2021年6月、CockroachDBはApache 2.0からBusiness Source License（BSL）に切り替え、クラウドベンダーがマネージドサービスとして提供することを実質的に禁じる路線へ移行しました。この決断はElasticやRedisの方針転換とも重なり、OSSビジネスの難しさを象徴する事例として議論を呼びました。現在は自社マネージドの CockroachDB Cloud を主軸に、エンタープライズ向け展開を強めています。
活躍する典型シナリオ
CockroachDBが最も価値を発揮するのは、複数の地理拠点にまたがって動かしたい元帳系システムです。DoorDash、Comcast、Netflixの一部基盤などが採用事例として挙げられており、いずれも「リージョン障害でサービスを止めたくない」要件を抱えていました。テーブル単位・行単位でリージョンを指定できるので、欧州ユーザーのデータをEU内に留める、といったレジデンシー対応も柔軟です。
一方、単一リージョンで高スループットを出したい用途にはオーバースペックになりがちです。ベンチマーク上、同じハードのPostgreSQLよりレイテンシが伸びる場面があり、Raftラウンドトリップの分だけ書き込みが重くなる点はトレードオフとして受け入れる必要があります。用途が「単一AZの普通の業務系」なら、まずPostgreSQLで足りるかを再確認するのが定石です。
競合する分散SQLとの比較
直接の競合は、PingCAPのTiDB、YugabyteDB、そしてGCPのSpanner本体です。TiDBはMySQLワイヤー互換、CockroachDBとYugabyteはPostgreSQL互換と、フロントの互換性が分かれます。AWSのAuroraは厳密には単一リージョン内のスケールアウトに特化していて、CockroachDBほどの地理分散性能はありません。
選定軸は「どこで動かしたいか」と「既存アプリの互換性」です。GCPで完結するならSpannerが圧倒的に楽、MySQLが社内標準ならTiDB、PostgreSQL資産を活かしてマルチクラウド/オンプレで分散したいならCockroachDB、というふうに分かれます。いずれにせよ単一ノードDBでは支えきれない規模になってから検討するのが、失敗しない順番です。
まとめ
CockroachDBは、Spanner論文が示した「世界中に伸びるSQL」のビジョンを汎用ハードで実現した製品です。止まらないサービスを地理分散で組みたい現場では、最初に検討候補に挙がる名前のひとつになっています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント