クラウド由来のデータベースとして 2010 年に開発されて以降、クラウドの次の 3 つの基本的特性を活かすため Microsoft は Azure Cosmos DB を慎重に設計し、エンジニアリングしてきました。

• グローバル分散。透過的なマルチマスター レプリケーションを利用します。
• スループットとストレージの世界規模でのエラスティック スケーリング。水平方向のパーティション分割を活用します。
• きめ細かいマルチテナント。データベース エンジンからレプリケーション プロトコルに至るまであらゆる方法を駆使した高度に制御されたリソース システム スタックを利用します。

Cosmos DB はこれら 3 つの特性で構成されていて、世界中で書き込みと読み取りの両方に関してエラスティック スケーラビリティをこれまでにない方法で提供し、99 パーセントタイルで 10 ミリ秒未満の待ち時間と 99.999% の高可用性を保証しています。このサービスは透過的にデータのレプリケーションを行い、明確に定義された 5 つの整合性モデル (TLA+ を使用して厳密に指定されたモデル) から選択した、グローバルに分散された Cosmos データベースの単一のシステム イメージを提供します。ユーザーは、世界中のどの場所にあるローカル レプリカに対しても書き込みと読み取りを行うことができます。昨年、このサービスが開始されて以降、Microsoft による設計の選択内容と、変更が加えられた固有のエンジニアリングのトレードオフが間違っていないことが検証されてきました。

とても高速かつグローバルでスケーラブルな書き込み

Azure の基本的なサービスの 1 つとして Cosmos DB は既定ですべての Azure リージョンで実行されます。この記事を執筆している時点で、Cosmos DB は 50 を超える地理的リージョンで運用されていて、2 から 50 を超えるリージョンのどこにおいてもグローバルにレプリケートするよう幾万ものユーザーが Cosmos データベースを構成しています。

ユーザーは複数のリージョンにまたがって Cosmos データベースを使用してきましたが、これまでは書き込み (および読み取り) に関して指定できるリージョンは 1 つのみで、その他すべてのリージョンは読み取りのみが指定できました。数年にわたる Microsoft 内部のワークロード実行による徹底的なサービス テストの結果、本日、Cosmos データベースで複数の書き込みリージョンを設定できるようになったことをお知らせできるのは嬉しいことです (別名 “マルチマスター” 構成)。この機能によって以下の利点がもたらされます。

• 世界中における 99.999% の書き込みと読み取りの可用性 – Cosmos DB では 99.999% の読み取り可用性に加えて、財務 SLA によって裏付けされた 99.999% の書き込み可用性が提供されるようになりました。
• 世界中における書き込みと読み取りのエラスティック スケーラビリティ - 読み取りに加え、世界中でエラスティック スケールの書き込みも提供できるようになりました。Cosmos DB コンテナー (またはデータベース) でアプリケーションが構成するスループットは、財務 SLA によって、すべてのリージョンに送達できることが保証されています。
• 世界中において 99 パーセントタイルで 10 ミリ秒未満の書き込みと読み取りの待ち時間 - Cosmos DB では 10 ミリ秒未満の読み取り待ち時間に加え、世界中のあらゆる場所において 99 パーセントタイルで 10 ミリ秒未満の書き込み待ち時間が財務 SLA によって保証されるようになりました。
• 明確に定義された複数の整合性モデル – Cosmos DB のレプリケーション プロトコルは、明確に定義され、実際的かつ直感的な 5 つの整合性モデルを提供し、適切なグローバル分散型アプリケーションを簡単にビルドできます。また、整合性モデルを利用できるようにするため、高水準の TLA+ 仕様も作成しました。
• 無限のエンドポイント スケーラビリティ – Cosmos DB のレプリケーション プロトコルは、100 か所のデータセンターと無数のエッジ デバイスで調和がとれた状態で拡大縮小するよう設計されています。このアーキテクチャは Azure リージョンとエッジ デバイスを同じものとして扱い、どちらも Cosmos DB レプリカをホストでき、マルチマスター レプリケーション プロトコルで true-peer として参加できます。
• マルチマスターの MongoDB、Cassandra、SQL、Gremlin、Table - Cosmos DB はマルチモデルおよびマルチ API データベースとして、SQL (Cosmos DB)、Cassandra (CQL)、MongoDB、Table Storage、Gremlin の各 API に対するネイティブの書き込みプロトコル互換サポートを提供します。Cosmos DB を使用すると、業界最高レベルの総合的な SLA によってやはり保証されている、MongoDB アプリケーションと Cassandra アプリケーションに関するフル マネージドで、セキュリティで保護され、準拠し、コスト効率の高い、サーバーレス データベース サービスを利用できます。前述の機能は、Cassandra、MongoDB、Gremlin、Table Storage、SQL など Cosmos DB がサポートするすべての API で使用できるようになりました。たとえば、Cosmos DB を利用して、マルチマスターのグローバル分散型 MongoDB を持ったり、Apache Gremlin によってアクセスできるグラフ データベースを使用したりできます。

数十年の研究 + 厳密なエンジニアリング = Cosmos DB

昨年 Cosmos DB サービスの提供を開始した際に、チューリング賞の受賞者 Dr. Leslie Lamport が Cosmos DB の技術的基盤について説明しているビデオ インタビューと共に、Cosmos DB の技術的概要について執筆しました。この内容の続編として、こちらでは Leslie 氏の最新ビデオ インタビューを取り上げています。その中では、Cosmos DB のアーキテクチャの進化、これまでにないレプリケーション プロトコル設計における TLA+ の採用、Paxos から、世界規模のエンジニアリングを使用するエピデミック プロトコルに至るまでさまざまな分散型システムについて数十年にわたる研究の結果、真に宇宙 (コスモス: Cosmos) スケールのアプリのビルドを可能にするために Cosmos DB が生み出されたいきさつについて説明しています。

このブログ記事は、Cosmos DB のグローバル分散アーキテクチャをいくらか掘り下げて説明しています。Cosmos データベースで複数の書き込みリージョンの使用を可能にする新機能も含まれています。以下のシナリオでは、Cosmos DB のグローバル分散のシステムモデルや、世界中における書き込みを拡大縮小するためにアンチエントロピ ベースの設計について説明します。

グローバル分散のシステム モデル

Cosmos DB サービスは Azure の基本的サービスの 1 つなので、パブリック クラウド、ソブリン クラウド、DoD クラウド、政府機関クラウドなど世界中の Azure リージョンすべてでデプロイできます。1 つのデータセンターで、専用のローカル ストレージをそれぞれのマシンで使用して大量の “スタンプ” で Cosmos DB サービスをデプロイおよび管理します。Cosmos DB は 1 つのデータセンターの多数のクラスターでデプロイされます。各クラスターは、さまざまな世代のハードウェアを実行する可能性があります。通常、特定のクラスター内のマシンは 10 から 20 の範囲の障害ドメインにまたがります。

図 1: システム トポロジ

Cosmos DB におけるグローバル分散はターンキー方式です。いつでもボタンを数回クリックするだけで (またはプログラムを使用して API を 1 回呼び出すだけで)、ユーザーは自分の Cosmos データベースに関連付けられている地理的リージョンの数を追加 (または削除) することができます。Cosmos データベースは一連の Cosmos コンテナーで構成されます。Cosmos DB では、コンテナーは分散とスケーラビリティの論理ユニットとしての役割を果たします。(内部的に) 作成するコレクション、テーブル、グラフは、Cosmos コンテナーとして示されます。それぞれのコンテナーは完全にスキーマが独立していて、それそれがクエリのスコープを持ちます。Cosmos コンテナー内のすべてのデータはインジェスト時に自動的にインデックス作成されます。これにより、ユーザーはスキーマを扱ったりインデックス管理に手間をかけたりすることなくデータのクエリを実行できます。特に、グローバル分散セットアップ時にその点が役立ちます。

図 2 に示されているように、コンテナー内のデータは 2 つのディメンションに沿って分散されます。

• 特定のリージョンにあるコンテナー内のデータはパーティション キーを使用して分散されます。パーティション キーはユーザーが提供し、基本的なリソース パーティションで透過的に管理されます (ローカル分散)。
• これに加えて、リソースの各パーティションには地理的リージョンをまたいでレプリケーションを実施します (グローバル分散)。

Cosmos DB を使用するアプリが Cosmos コンテナーでスループットをエラスティックにスケーリングするとき (または多くのストレージを使用するとき)、Cosmos DB はすべてのリージョンにおいてパーティション管理 (分割、複製、削除など) 処理を透過的に実行します。このため、Cosmos DB からはスケール、分散、障害とは関係なく常に、任意の数のリージョンでグローバルに分散された、コンテナー内のデータのシステム イメージが 1 つだけ提供されます。

図 2: 世界中の複数のリージョンにまたがる 2 つのディメンションにおけるリソース パーティションの分散。

物理的にはリソース パーティションは、レプリカ セットと呼ばれるレプリカのグループによって実装されます。各マシンは、固定セットのプロセス内のさまざまなリソース パーティションに対応するたくさんのレプリカをホストします (図 1 を参照)。リソース パーティションに対応するレプリカは動的に配置されて、1 つのクラスター内の多数のマシンと 1 つのリージョン内の多数のデータセンター内で負荷を分散します。

レプリカは、特定の Cosmos DB テナントに一意に属します。各レプリカは Cosmos DB のデータベース エンジン インスタンスをホストします。このインスタンスは、リソースおよび関連するインデックスを管理します。Cosmos DB データベース エンジンは、Atom-Record-Sequence (ARS) ベースの型システムで動作します¹。  このエンジンはスキーマの点で完全に独立していて、レコードの構造体とインスタンス値の境界をぼかします。Cosmos DB ではインジェスト時に自動的に効率的な方法ですべてをインデックス作成することにより、完全なスキーマ独立を実現しています。これにより、ユーザーはスキーマを処理したり、インデックス管理を行ったりすることなくグローバルに分散されたデータをクエリできます。次に Cosmos DB データベース エンジンは、いくつかの調整プリミティブ、言語ランタイム、クエリ プロセッサー、およびデータのトランザクション ストレージとインデックス作成を担うストレージ サブシステムとインデックス作成サブシステムなどを実装するいくつかのコンポーネントで構成されます。耐久性と高可用性を提供するため、このデータベース エンジンは SSD 上にデータとインデックスを保持し、レプリカ セット内のデータベース エンジン インスタンス間でレプリケーションを行います。テナントの規模が大きいほどスケールの大きなスループットとストレージに対応し、レプリカの規模も大きくなるか、レプリカの頻度が多くなる、あるいはその両方が備わります (その逆も当てはまります)。システム内のすべてのコンポーネントは完全に非同期です。スレッドはブロックされることなく、各スレッドは、不要なスレッド切り替えが生じることなく短期間動作します。レート制限とバック プレッシャが、管理制御からすべての I/O パスに至るまでスタック全体で組み込まれています。このデータベース エンジンはきめ細かいコンカレンシーを活用するように、および少量のシステム リソースで運用しながら高スループットを実現するように設計されています。

Cosmos DB のグローバル分散は、レプリカ セットとパーティション セットという 2 つの主要な抽象化に依存しています。レプリカ セットはモジュール式の調整用レゴ ブロックで、パーティション セットは 1 つ以上の地理的分散リソース パーティションの動的オーバーレイです。グローバル分散の仕組みを理解するには、これら 2 つの主要な抽象化について理解する必要があります。

レプリカ セット - 調整のレゴ ブロック

リソース パーティションは、複数の障害ドメインにまたがっているセルフ マネージド方式で動的に負荷を分散するレプリカ グループ (別名、レプリカ セット) として実現します。このセットは、レプリケートされたステート マシン プロトコルを集合的に実装し、リソース パーティション内のデータの高可用性、耐久性、強固な整合性を確保します。レプリカ セットのメンバーシップ N は動的です。障害、管理操作、および再生成/回復のためのレプリカの失敗時点に基づいて N_Min から N_Max までの範囲で変動します。メンバーシップが変更すると、レプリケーション プロトコルも読み取りと書き込みのクォーラムのサイズを再構成します。特定のリソース パーティションに割り当てられるスループットを統一感を持って分散するため、2 つのアイデアを採用しています。1 つ目は、リーダーにおける書き込み要求の処理コストは、フォロワーにおける更新に適用されるコストよりも高くなるという点です。それに対応して、リーダーに割り当てられるシステム リソースはフォロワーよりも多くなっています。2 番目に、可能な限り、指定の整合性レベルの読み取りクォーラムはフォロワー レプリカによってのみ構成されます。絶対に必要な場合を除き、読み取りのためにリーダーにアクセスしないようにします。Cosmos DB がサポートしている 5 つの整合性モデルのクォーラム ベースのシステムにおける負荷とキャパシティの関係に関して実施された研究に基づいて数多くのアイデアを採用しています。

パーティション セット – 動的で地理的な分散オーバーレイ

リソース パーティションのグループは、それぞれが Cosmos データベース リージョンで構成されているリソース パーティションから成り、構成されているすべてのリージョンでレプリケートされた同じキー セットを管理します。この高度な調整プリミティブはパーティション セットと呼ばれ、特定のキー セットを管理するリソース パーティションの地理的に分散された動的オーバーレイです。指定されたリソース パーティション (つまり、レプリカ セット) は 1 つのクラスター内のものですが、パーティション セットは複数のクラスター、データセンター、地理的リージョンにまたがることがあります (図 2 と 3)。

図 3: パーティション セットはリソース パーティションの動的オーバーレイ

パーティション セットは、同じキー セットを所有する複数のレプリカ セットで構成されている、地理的に分散している “スーパー レプリカ セット” と見なすことができます。レプリカ セットの場合と同様、パーティション セットのメンバーシップも動的です。暗黙的なリソース パーティション管理処理に基づいて変動し、特定のパーティション セットにおいて新しいパーティションが追加されたり、削除されたりします (例: コンテナーでスループットをスケールアウトする場合、Cosmos データベースにリージョンを追加/削除する場合、障害が発生する場合など)。 パーティション セットの各パーティションを所有することにより、それぞれのレプリカ セット内のパーティション セット メンバーシップを管理し、メンバーシップは完全に分散され、高可用性を実現できます。パーティション セットを再構成する間に、リソース パーティション間のオーバーレイのトポロジも確立されます。トポロジは整合性レベル、地理的距離、およびソースとターゲットのリソース パーティション間で利用できるネットワーク帯域幅に基づいて動的に選択されます。

このサービスを使用することによって、単一の書き込みリージョンと複数の書き込みリージョンのいずれかで Cosmos データベースを構成できます。このどちらを選択するかに基づいて、パーティション セットで書き込みを行えるよう構成されるのが 1 つのリージョンのみかすべてのリージョンにおいてであるかが決まります。システムでは 2 つのレベルの入れ子になったコンセンサス プロトコルが導入されています。1 つのレベルは、書き込みを承認するリソース パーティションのレプリカ セットのレプリカで動作します。もう 1 つはパーティション セット レベルで動作して、パーティション セット内のコミットされたすべての書き込みが順序どおりに実行されることを保証します。このマルチレイヤーの入れ子になったコンセンサスは、高可用性に関する当社の厳密な SLA の遂行や、Cosmod DB がお客様に提供する整合性モデルの実装において重要となります。

柔軟な競合解決を使用したアンチエントロピ

更新の伝達、競合解決、因果関係の追跡に関する Microsoft の設計は、以前のエピデミック アルゴリズムと Bayou システムからヒントを得ています。Cosmos DB のシステム設計ではカーネルの概念が引き続き採用され、通信に便利な参照フレームが導入されていますが、Cosmos DB システムに適用されるときに大幅な変更が加えられています。こうした変更が必要となったのは、以前のシステムにおいては、Cosmos DB で必要なリソース管理もスケールも不要で、Cosmos DB がお客様に提供する様々な機能 (有界整合性制約など) や厳密で包括的な SLA を提供する必要もなかったためです。

パーティション セットは複数のリージョンで分散され、Cosmos DB の (マルチマスター) レプリケーション プロトコルを導入して、特定のパーティション セットを構成するリソース パーティション間でデータをレプリケートするという点を思い出してください。(パーティション セットを構成する) それぞれのリソース パーティションは書き込みを承諾し、対象リージョンに対してローカルなクライアントに対して通常読み取りを行います。リージョン内のリソース パーティションで承諾された書き込みは耐久性の高い状態でコミットされ、クライアントに対して確認応答する前にリソース パーティションで高可用になります。これらは仮の書き込みで、アンチエントロピ チャネルを使用してパーティション セットの他のリソース パーティションに伝達されます。クライアントは、要求ヘッダーを引き渡すことによって、仮の書き込みまたはコミット済みの書き込みを要求できます。アンチエントロピ伝達 (伝達頻度も含む) は、パーティション セットのトポロジ、リソース パーティション間のリージョンの近接度、構成されている整合性レベルに基づいて動的に行われます。パーティション セット内では、Cosmos DB は動的に選択されたアービター パーティションが含まれるプライマリ コミット スキーマに従います。アービターの選択は、オーバーレイのトポロジに基づくパーティション セットの再構成において不可欠な部分です。コミット済み書き込み (複数行/バッチ更新を含む) は完全に順序どおりに実行されることが保証されます。

因果関係の追跡とバージョン ベクターにおいて更新の競合を検出して解決するために、エンコードされたベクター クロックを導入しました (レプリカ セットとパーティション セットのそれぞれのレベルのコンセンサスに対応するリージョン ID と論理クロックが含まれます)。このトポロジとピア選択アルゴリズムは、バージョン ベクターの固定の最小限のストレージと最小限のネットワーク オーバーヘッドを確保するよう設計されています。このアルゴリズムによって、厳密な収束プロパティが保証されます。
複数の書き込みリージョンが構成されている Cosmos データベースの場合、システムによって、開発者が選択できる多数の柔軟な自動競合解決ポリシーが提供されています。以下の選択肢が含まれます。

1. 最後の書き込みが有効 (LWW)。既定では、ユーザーはシステム定義のタイムスタンプ プロパティを使用します (時刻同期クロック プロパティに基づきます)。また Cosmos DB を使用することによって、競合解決に使用する他のカスタムの数値型プロパティを指定できます。
2. アプリケーション定義のカスタム競合解決ポリシー (マージ プロシージャとして表現)。競合のアプリケーション定義のセマンティクス調整用に設計されています。これらのプロシージャは、データベース トランザクションの支援によって書き込み間の競合が検出されると、サーバー側で呼び出されます。システムにより、コミットメント プロトコルの一部としてマージ プロシージャの実行が 1 回だけとなることが保証されます。利用可能ないくつかのサンプルが準備されています。
3. CRDT (Conflict-free-Replicated-Data-Types)。当社のデータベース エンジンのコア (ARS) 型システム内部に固有の方式。この方式では、コミットメント プロトコルの一部としてデータベース エンジン内部で、競合の自動解決がトランザクションで直接行えます。

明確に定義された 5 つの整合性モデル

Cosmos データベースで単一または複数の書き込みリージョンのどちらを構成した場合であっても、このサービスによって提供される 5 つの明確に定義された整合性モデルを使用できます。複数の書き込みリージョンを可能にする新たに追加されたサポートに関しては、整合性レベルの以下の側面に注目できます。

これまで同様、有界整合性制約では、すべてのリージョンにおいて、読み取りすべてが最新の書き込みから k プレフィックスまたは t 秒以内に行われることが保証されます。また、有界整合性制約を使用した読み取りでは、モノトニックになり、一貫性のあるプレフィックスとなることが保証されます。アンチエントロピ プロトコルはレートが制限された状態で実行され、プレフィックスが累積しないことと、書き込みのバックプレッシャを適用する必要がないことが保証されます。セッションの整合性の場合も従来どおり、モノトニックな読み取り、モノトニックな書き込み、RYOW、読み取り後の書き込み、一貫性のあるプレフィックスが世界規模で保証されます。強力な一貫性で構成されたデータベースの場合、システムで、パーティション セットそれぞれでリーダーを指定することによって単一の書き込みリージョンに戻すことができます。

5 つの整合性モデルのセマンティクスについてはこちらで取り上げられています。また、高水準の TLA+ 仕様を使用して数学的に記述されています。

まとめ

Cosmos DB はグローバル分散型データベースとして、任意の数の Azure リージョンにデータを透過的にレプリケートします。これまでにない完全な分散型でマルチマスター レプリケーション アーキテクチャを使用することによって、ご利用になっている Cosmos データベースと関連付けられているすべてのリージョンで書き込みと読み取りの両方をエラスティックにスケーリングできます。世界中のあらゆる場所にある Cosmos データベースのローカル レプリカに書き込んでグローバルに書き込みをエラスティックにスケーリングする機能は、ここ数年の間、機能してきました。喜ばしいことに、この機能をすべての皆様に一般公開できるようになりました。

謝辞

Azure Cosmos DB は、現在の形式に拡張して成熟されるまでの間、2010 年後期に “Project Florence” として運用が開始されました。Azure Cosmos DB の堅牢性を高めるため、数年にわたり幅広くこのサービスを利用してきた Microsoft 内のすべてのチームに感謝いたします。先人の努力や発見に感謝したいと思います。コンピューティング、ネットワークキング、Service Fabric など Azure Cosmos DB が基盤としている多数のコンポーネント テクノロジがあり、継続的な支援に謝意を表します。Dr.Leslie Lamport にも、分散システムの設計に関してインスピレーションを与え、アプローチに影響を与えてくださり、感謝いたします。Cosmos DB を使用してミッション クリティカルなアプリを構築し、サービスの限界を押し広げ、常にベストを求めてきたお客様には、非常に感謝しています。最後に、Cosmos の開発に携わったすべての皆様の多大な努力と貢献に心から感謝します。

---

1. JSON、BSON、CQL などの文法は、ARS 型システムの厳格なサブセットです。