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

テッククランチイベント

データアーキテクチャの本質的な目的は、データを消費者に可能な限り近づけることです。一つのアプローチとして、自分のデバイスにオフラインコピーを用意しておくという方法があります。Amazonが電子書籍をKindleにダウンロードするのはそのためです。あなたとデータの間には、ネットワークもファイアウォールも何も存在しません。データを手に取る以上に、データに近づくことはできません。

電子書籍のように頻繁に変更されないデータであれば、一度のダウンロードで十分ですが、株価のように急速に変化するデータには、はるかに高度な技術が必要です。そこでデータベースが活躍します。

データベースは、しばしばコンマ数秒という短い間隔で発生する膨大なデータの読み書きを高速に処理する中心的な場所となることを目的としています。Kindle本を執筆する著者は1人だけの場合が多いですが、データベースは数百万、あるいは数十億もの「著者」がデータを書き込み、書き込まれた新しいデータを読み取れるように設計されています。これは非常に強力な技術ですが、魔法のようなものではありません。時間と空間の制約は常に存在します。

キムボール氏が上で説明したQuoraの例に戻りましょう。ニューヨーク在住のユーザーが、ニューヨーク市でホストされているデータベースに質問への回答を書き込むと、シドニーのユーザーよりもずっと早くその回答が表示されます。ネットワークの状態によっては、この遅延は0.5秒から数秒に及ぶ可能性があります。キムボール氏が言うように、「これは大きな問題です」。

グローバルアプリケーションは、世界中にデータベースサーバーを設置することでこの問題に対処します。ユーザーが近くのデータベースサーバーに変更を加えると、その変更は地球上の他のすべてのデータベースサーバーに複製されます。そして、データを読み取る際には、ユーザーは最も近いデータベースサーバーにアクセスします。

レプリケーションにより、ユーザーはデータを読むために地球の反対側まで足を運ぶ必要がなくなりますが、同期という別の問題も発生します。ここで、図1に示すQuoraのシナリオをもう一度見てみましょう。

例えば、ニューヨークのユーザーが「史上最高のギタリストは誰ですか？」と質問したとします。そのユーザーはニューヨークのデータベースサーバーに質問をアップロードし、ニューヨークのユーザーにはすぐに表示されます。シドニーのユーザーには1～2秒後に表示されます。そのため、シドニーのデータベースサーバーはニューヨークのデータベースサーバーと同期が取れていない状態になります。シドニーは最終的には世界規模のレプリケーションプロセスの一環として新しいデータを取得しますが、遅延が発生します。すべてのデータベースサーバーの同期が完了すれば、ギタリストに関する質問に対するアクティビティがなくなり、同期が取れた状態になります。

しかし、パリの誰かが「エリック・クラプトンは史上最高のギタリストだ」と答えたとします。パリのユーザーは、西ヨーロッパのデータベースサーバーに書き込みを行うことでこの質問に答えます。この時点で、他のすべてのレプリケーションデータベースサーバーは再び同期が取れなくなります。パリのユーザーはエリック・クラプトンの答えを知っていますが、ニューヨークのユーザーは知りませんし、シドニーのユーザーも同様です。レプリケーションが伝播し、すべてのデータベースサーバーがエリック・クラプトンの情報を知るまでには時間がかかります。

ある意味、私たちは出発点に戻ったと言えるでしょう。時間と空間の不変の法則、つまりデータに近ければ近いほど読み取り速度が速くなるという法則です。ただし、この場合、距離はユーザーとデータベースサーバー間の距離ではなく、データベースサーバー同士の距離として定義されます。

このデータの不整合の問題は長い間存在しており、実際には CAP 定理と呼ばれる正式な定義があります。

CAP定理（一貫性、可用性、パーティションの頭文字）によれば、データを複数のデータベースサーバーまたはパーティション（P）に分散させる場合、必ず犠牲を払う必要があります。最終的に最も一貫性のあるデータ（C）を入手するか、古くて一貫性のないデータ（A）をすぐに入手するかのどちらかです。最新のデータをすぐに入手することはできません。

この問題は、世界規模の地理的範囲にわたるデータの読み取りと書き込みを困難にしており、CockroachDB が解決しようとしている問題です。

CockroachDB はこの問題をどのように解決しますか?

CockroachDB は、データベース設計において地理的最適化を最優先に考え、パフォーマンスに関する詳細な作業の多くを自動化することで、グローバル規模で可能な限り高速にデータの書き込みと読み取りを行うという課題に取り組んでいます。Cockroach Labs のグループプロダクトマネージャーである Andy Woods 氏は、「これは、信頼性が高く低レイテンシのアプリケーションをグローバル規模で容易に提供できるようにすることです」と述べています。

これを実現するために、Cockroach Labsはデータベース設計に「マルチリージョン・データベース・アーキテクチャ」と呼ばれる機能を導入しました。詳細を見ていきましょう。

マルチリージョンデータベースの理解

ほとんどのデータセットの規模に対応するために、データベース テクノロジでは、特定のデータが特定のデータベース サーバーに配置されることを定義するシャーディングと呼ばれる論理戦略を使用してデータをセグメント化することがよくあります。

従来、シャードはデータセットの標準化された特徴に基づいて作成されます。例えば、郵便番号全体を、郵便番号の最初の数字に基づいて10のカテゴリに細分化できます。各シャードは、シャーディングロジックに従って、別々のコンピューター、ハードドライブ、あるいはデータセンターに保存されます。

シャーディングの利点は、データの取得が容易になることです。ユーザーがデータベース内のデータに対してクエリを実行するたびに、データベースエンジンはデータベース全体を網羅し、クエリの条件に従ってデータを取得・組み立てます。例えば、「郵便番号が50000から50009の範囲に居住するすべてのユーザーを取得」というリクエストは、その郵便番号の範囲をホストするデータベースサーバーに送られます。

リレーショナルデータベースでは、これは各テーブルの行を調べて目的のデータを見つけることを意味します。数百万行にも及ぶ大規模なデータベースでは、この処理にかなりの時間がかかる可能性があります。しかし、論理的なルールに従って、コンピュータのハードディスク上、あるいは同じ地域のデータセンター内で行が近接してグループ化されている場合、クエリの実行時間は多くの場合劇的に短縮されます（図2を参照）。データのシャーディングは、CAP定理によって課せられる負担の一部を軽減します。

シャーディングの欠点は、確実に動作させるには多くの技術的ノウハウと継続的な管理が必要になることです。テーブルに新しい列を追加したり、シャーディングロジックを変更したりするといった単純な作業でさえ、リスクが高く、時間のかかる作業であり、高度な技術的専門知識を必要とします。一歩間違えれば、企業のデータベースは深刻な問題に直面する可能性があります。

ほとんどのシャーディングロジックはデータに基づいていますが、異なるアプローチがあります。物理的な地理情報を考慮し、ユーザーの所在地に基づいてデータをグループ化するのです。マルチリージョンデータベースでは、地理情報に基づいて定義されたポリシーに従って、データがセグメント化され、物理データベースサーバーのクラスター全体に分散されます。CockroachDBは、マルチリージョンデータベースアーキテクチャを採用することで、シャーディングに伴う多くの問題を解消します。

CockroachDB では、データベースエンジニアは論理データベースをマルチリージョンとして宣言します。その後、論理データベース、あるいは個々のテーブルを、地球上の 1 つまたは複数のリージョンに割り当てることができます。

図3は、米国東部リージョンと米国西部リージョンのデータベースサーバーにバインドされたMyDBというCockroachDBデータベースを示しています。MyDBデータベース内の3つのテーブルが米国西部リージョンに、1つのテーブルが米国東部リージョンにバインドされていることに注意してください。これは、マルチリージョン機能を使用してCockroachDB内のテーブルを特定の地理的な場所に分割する例です。

CockroachDB のマルチリージョン機能を使用して地理的な近接性に応じてデータをセグメント化することで、Cockroach Labs の主な指令である「可能な限りユーザーに近いデータを取得する」が達成されます。

行レベルのパーティション分割を理解する

それだけではありません。Cockroach Labsは、地理的データセグメンテーションの概念をさらに進化させ、テーブルの個々の行を地域に割り当てる機能を提供しています。これは行レベルのジオパーティショニングと呼ばれ、データベースマニアにとっては非常に重要な機能です。実際、Cockroach Labsはこの機能を有料のエンタープライズ顧客にのみ提供しています。

図 4 をご覧ください。これは、姓、名、市、州、郵便番号別にリストされた顧客の簡単な表を示しています。

テーブルの最初の2行には米国西部に対応する郵便番号の顧客が、最後の行には東海岸に対応する郵便番号の顧客が含まれていることに注目してください。CockroachDBの行レベルパーティション機能を有効にすると、西海岸の顧客のデータは米国西部リージョンに、東海岸の顧客のデータは米国東部リージョンに自動的に配置されます。これにより、西海岸で実行されるアプリケーションから西海岸の顧客データに非常に高速にアクセスできるという利点があります。

ある意味で、同社はCAP定理という本質的な原則に反抗しようとしていると言えるでしょう。パーティション化されたデータベースでは、最終的には一貫性のあるデータを得ることも、即座に一貫性のないデータを得ることもできますが、今すぐ一貫性のあるデータを得ることはできません。CockroachDBは「P」に焦点を当てることで、この定理を覆しています。つまり、ほとんどのユーザーが、常にではないにしても、ほとんどの場合、一貫性と可用性の両方を備えたデータを利用できるようにデータをパーティション化するのです。

行レベルのジオパーティショニングは非常に重要で、実現するのは非常に困難です。しかし、運用上の大きな負担なしに細粒度シャーディングのメリットを享受できるため、その努力は十分に報われます。CockroachDBは、そのすべての作業を引き受けます。

CockroachDB を使用している人にとって、これは何を意味するのでしょうか?

CockroachDB は、グローバル規模でデータを管理する必要がある企業にとって大きなメリットをもたらします。データベースレベル、テーブルレベル、行レベルを問わず、パーティショニングをサポートするデータ管理機能は、CockroachDB サーバーエンジンによって自動的に実行されます。これは、データベースアーキテクチャに強力な追加機能をもたらします。

しかし、学習曲線は存在します。開発者は、データベースプログラミングに使用される標準クエリ言語であるSQLのCockroach Labsバージョンに実装された機能強化を習得するのに、ある程度の時間を要するでしょう。

CockroachDB には、フォールトトレランスをより詳細に制御できる「サバイバルゴール」と呼ばれる機能があります。フォールトトレランスとは、データベースがシステム障害から回復する能力です。数百台、場合によっては数千台もの物理データベースサーバーで構成される世界規模のデータベースインフラストラクチャでは、マシンやネットワークの障害によってサーバーが利用できなくなることは珍しくありません。

サバイバルゴールとは、CockroachDBのデータベース管理者（DBA）が論理データベースがデータベースサーバーのクラスタ全体にデータを複製する方法を宣言するための構成設定です。サバイバルゴールは、Cockroach Labsのデータベースアーキテクチャへのアプローチにおいて重要な役割を果たします。サバイバルゴールはCockroachDBの仕組みに組み込まれた概念であるため、開発者とDBAはサバイバルゴールの扱い方を習得するために時間をかける必要があります。

最後に、企業がCockroachDBの導入を決定する際に直面する現実的な影響は、この技術の導入に伴うコミットメントの度合いを受け入れることです。データベースの選定は大きな決断です。導入後、データベースは通常、企業にとって長年、場合によっては数十年にわたって使用されることになります。企業がCockroachDBの導入を決定すれば、それは決定を下した人々にとってキャリアアップのきっかけにも、キャリアを終わらせるきっかけにもなり得ます。すべては導入の成功にかかっています。データベースがアプリケーションのアーキテクチャにどのように適合するかを慎重に計画することが不可欠です。

CockroachDB はあらゆるアプリケーションに使用できますが、世界中のユーザーが正確かつ信頼性の高い方法でグローバルデータに超高速にアクセスできるようにしたい企業に最適です。要件が少なく、パフォーマンスへの要求も低いアプリケーションには、よりシンプルなデータベースが適しています。

そうは言っても、CockroachDB は非常に価値のある顧客に対して特別でユニークなものを提供しており、それが同社のビジネスを非常に興味深いものにしています。これがこの EC-1 の次の部分のトピックです。

「開発者はご存知の通り、お金を払うことを好まない」

CockroachDB EC-1 目次

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

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