CAP定理は、分散システムは一貫性と可用性の両方を備えることはできないと述べています。つまり、どちらか一方を選ばなければなりません。
しかし、私たちは、多くの一般的な障害状況でシステムの可用性を大幅に向上させると同時に、強い一貫性をサポートするアルゴリズムを設計しました。
一貫性には、より厳密なものからより厳密でないものまで、いくつかのレベルがあることに注意することが重要です。
「強い一貫性」は聖杯であり、一貫性の最も厳しいレベルです。
強力な一貫性は、単一レコードへのすべての書き込みが特定の順序（順次）で適用され、書き込みが再順序付けされたりスキップされたりしないことを保証します。
単一レコードのトランザクションには、「linearizable」と「sequential」の2つの強力な一貫性レベルがあります（Jepsenの一貫性モデルマップの右の枝にあるピンクの四角形を見てほしい）。
複数レコードのトランザクションには、さらに強い一貫性のレベルがあります（Jepsenのモデル・マップの左側のブランチ）。
このブログでは、システム内で各レコードの複数のコピーの保存（複製）をサポートする分散データベースシステムにおける単一レコードトランザクションにのみ焦点を当てます。
この違いを簡単に説明すると、単一レコードトランザクションとは、分散データベースシステムにおいて単一のデータレコードに対してデータベース操作（読み取り、作成、更新、削除）を実行するアトミックトランザクションです。
これに対し、マルチレコードトランザクションでは1つ以上のデータレコードに影響を与える可能性のある複数の操作を実行します。
さらに、線形化可能な一貫性と順序一貫性に加えて、「最終的一貫性」と「強い最終的一貫性」といった、業界で一般的に使用される用語についても説明します。
基礎を築くために、一貫性の議論の基盤となるCAP定理について簡単に説明しましょう。
CAPの定理
1998年にカリフォルニア大学バークレー校のEric Brewer教授によって作られたCAP定理では、分散システムについて次のように述べています。
「分散データベースの設計において、パーティション許容度に直面した場合、一貫性（CP）か可用性（AP）のどちらかを選択することができるが、両方を持つことはできない。」
分割耐性
前提：我々は複数のノードを含む分散データベースシステムを持っており、システムに障害が発生しています。
障害は、ネットワークの分断問題、ノードのクラッシュ問題（一つまたは複数のノードが影響を受ける可能性があります）などです。分割耐性とは、データベース管理システム（データベースクラスター）が、ネットワーク通信の障害イベント中でも機能し、サービスを提供し続ける必要があることを意味します。
可用性
分散システムは、新しいデータの書き込みや既存データの読み取りや更新を含む、クライアント/アプリケーションに対してサービスを提供し続けます。
クライアント/アプリケーションがデータベースシステムにアクセスできない場合は、利用不可とみなされます。
一貫性
データは、任意の時点でクラスタ内のすべてのノード間で一貫していなければなりません。
書き込み活動が完了すると、データ項目のすべてのコピーに同じ値が必要です。
直後の読み取りがこれらのレコードコピー（潜在的に異なるノード上）のいずれかにアクセスする場合、同じ結果を返すべきです。
これは、CAP定理の原則に基づく強い一貫性の特定の定義です。我々は、さまざまな種類の一貫性をリストする際に、これを再度説明します。
ネットワークの分断が存在する場合は、分散システムでは一貫性と可用性は不可能であることに注意してください。
これは、ノードが決してダウンせず、通信問題が決して発生しないという理論的なシナリオでのみ起こり得ます。
つまり、分割耐性が必要ない場合です。
しかし、それは実際にはほぼ不可能なシナリオです。というのも、実生活では通信問題が確実に発生し、ノードはいずれかの時点でダウンする（またはネットワークから切断される）からです。
関連用語
このブログでは、上記の他にさまざまな種類の一貫性を定義するために使用される用語が出てきます。
- 古くなった読み取り：最も最近にコミットされた値ではないデータ（つまり、古い/時代遅れのデータ）を読むこと。
- ダーティリード：まだコミットされておらず、取り消される可能性があるデータを読むこと。
- 失われた書き込み：コミットされたデータを失うこと。
一貫性は同期システムを必要とする
可用性よりも強い一貫性を優先する：分散データベースシステム（CAP定理のCPモード）は、分散データベースシステムを形成するノードの単一クラスター内でのデータの同期レプリケーションをサポートする必要があります。
このようなシステムは、ネットワークの分断が存在しても、以前に説明した強い一貫性のルールを決して破ることはありません。
同期レプリケーションとは、データがプライマリに書き込まれると、すぐにレプリカにコピーされ、書き込みがコミットされる前にプライマリに確認が戻ることを意味します。
非同期レプリケーションでは、データはプライマリノードに書き込まれ、コミットされた後にレプリカにコピーされます。
書き込み操作：すべての強い一貫性モデルは、書き込みを保持する必要があります。つまり、後続の読み取りに対して書き込みが失われることはありません。
読み取り操作：一定のロジックに従いますが、これは一貫性モデルに依存し、以下で説明します。
強い一貫性モデル
単一レコードトランザクションの強い一貫性には、2つの読み取りモデル、または2つの異なる一貫性レベルがあります（書き込みには1つの強い一貫性レベルのみがあります）。
Aerospikeは、線形化モデルと、セッション一貫性とも呼ばれる逐次読み取りモデルの両方をサポートしています。
線形化一貫性
読み取りは、読み取られているレコードが含まれるパーティションのマスターコピーを含むノードに行きます（つまり、そのパーティションのマスター）。
その後、マスターは、同じパーティションのレプリカを持つすべてのノードに確認し、特定のレコードに対して一貫した値を持っているかどうかを確認します。
マスターを含むすべてのレプリカが同意すれば、読み取りは成功します。
そうでなければ、失敗し、クライアントアプリケーションは適切な失敗コードを受け取り、読み取りを再試行できます。
したがって、レコードへのすべての読み取りは、同じレコードへの他のすべての読み取りや書き込みに対して厳密に順序付けられ、つまり「線形化」されます。
そして、どのアプリケーションが書き込んだかに関係なく、すべての読み取りはレコードへの最も最近のコミットされた書き込みを見ることになります。
線形化は通常、最高レベルの強い一貫性を持ちます。また、設計と実装が最も難しいものです。
逐次一貫性
逐次一貫性は、マスターに到着する読み取りを含みますが、マスターはレプリカと確認する必要はありません。
それはマスターでのローカル読み取りに過ぎません。
これには少ないホップが含まれるため、読み取りが速くなります。
ここで重要なのは、特定のアプリケーションがデータベースに書き込んだデー タはすべて、同じアプリケーションがその後に永遠に読み込むことが保証されるということです。
最新の書き込みを読むという保証は、特定のアプリケーションの書き込みにのみ適用されるこに注意してください。他のアプリケーションが同時にレコードで行う書き込みや読み取り（線形化読み取りとは異なります）には適用されません。ネットワークの分断、ノードのアップ/ダウンなどの障害イベントが発生した場合にのみ、古くなった読み取りが発生する可能性があることに注意してください。
逐次一貫性を視覚的な例で説明しましょう：
図1：異なるアプリケーションによるシーケンシャルリードが容易に利用できない場合のシーケンシャル一貫性の例
線形化一貫性と逐次一貫性の比較
線形化一貫性と逐次一貫性は、いくつかの共通点を持っています。
これら2つのモデルが重なる例を以下に示しましょう。
両モデルとも
- 書き込みが完了するとすぐに強く一貫しています。
- 書き込みが失われることはないため、データを失うことはありません。
- ダーティリードを生成することはできません（これは強い一貫性では不可能です）。
各一貫性モデルでの読み取りは異なります。単一レコードトランザクションの場合、
- 線形化はより厳格なモデルです。
- 読み取りは遅く、古いデータを返すことができません。 逐次はより緩やかなモデルです。読み取りは速いものの、古いデータを返す可能性があります。例えば、逐次読み取りは、通常のシステム運用（つまり、障害がない状況）でAP読み取りと同じくらい速くなることがあります。
線形化と逐次読み取りの選択は、リクエストごとに行うことが重要です。
クライアントは、API実行時に読み取りが線形化されるようにリクエストできます。その後、同じクライアントは、後続のデータ項目を読むために逐次読み取りを使用できます。
結果整合性と強い結果整合性
前のセクションで説明された2つのモデル – 線形化一貫性と逐次一貫性 – は、まさに強い結果整合性の例です。これらは同期レプリケーションに基づいており、強く一貫しています。
しかし、非同期レプリケーションを使用するシステムには、さらに2つのモデル、偶発的一貫性と強力な偶発的一貫性が適用されます。
結果整合性
結果整合性は、操作がクラスタ内のさまざまなコピーに非同期的に適用されることを指示します。
同じデータレコードに対する複数の同時操作が、さまざまなコピーに順不同で到着する可能性があります。
したがって、書き込みが失われる可能性があり、唯一の約束は、追加の書き込みが発生しない限り最終的にデータが収束することです（これが結果整合性が「収束」とも呼ばれる理由です）。
複製が非同期であるため、書き込み操作を完了した後、データのすべてのコピーが更新されるわけではありません。
更新レコードの状態がどこでも同じ値に収束するまで、古いデータを持つノードが存在し、読み取り操作は古いデータを返す可能性があります。
注目すべき点は、この収束がいつ起こるかについて、拘束時間の保証はないということです。
- 長所：速度と可用性
- 短所：データの損失、古いデータ
強い結果整合性
このモデルでは、レコードに対して行われる一連の操作は、データベース内のそのデータ項目のすべてのコピーが、データを失うことなく同じ結果になるように適用されます。
言い換えルト、強い結果整合性は、データ項目のすべての複製が更新または一連の更新を受け取った後、それらがさらなる介入なしに決定論的に同じ値に収束することを保証します。
同じ一連の更新を受け取った2つの複製は、それらの更新が異なる順序で到着したとしても、最終的には同じ値になります。
- 長所：データの損失もダーティリードもなし
- 短所：古い読み取りが発生する可能性がある。例えばネットワークの分断が解消されるまでこの状態になる可能性があります。収束するまで、さまざまなノード/クラスター間に違いが存在します。
一貫性モデル – まとめ
要約すると、一貫性のレベルが高いほど、データベースシステムはそのレベルの一貫性を維持するためにより一層の努力が必要です。
その見返りとして、陳腐なデータがなくなります。それでも、ある種の強い一貫性モデルでは、古いデータがあっても問題ありません。
強い一貫性では、ダーティリードやデータの損失（つまり、書き込みの損失）は決して許されません。
ここでは、我々が取り上げた一貫性モデルの概要を示します：
- 線形化一貫性：読み取りは遅いですが、常に最新のデータを取得します。データが古くなることは決してありません。これは最高レベルの強い一貫性です。
- 逐次一貫性：読み取りは速い一方で、時々古いデータを取得することがあります（これも強い一貫性です）。これは、トランザクションプロセスのどこにいるかに比べて、古いデータを取得することを意味します。それでも、データはデータベースにコミットされたものなので正確です。
- 強い結果整合性：読み取りはさらに速くなりますが、さらに多くの古い読み取りが可能です。このモデルは強く一貫していません。なぜなら、データの更新がシステムのさまざまなノード間で同期していないからです。
- 結果整合性：古いデータを取得するだけでなく、書き込みの損失も起こりやすくなります。
Aerospikeにおける強い結果整合性
NoSQLデータベースは、アクセスの速度と膨大なデータ量を扱う能力を提供するために作られました。
そのため、NoSQLデータベースはリアルタイムWebアプリケーション、電子商取引、オンラインゲーム、オンライン広告、その他多くのアプリケーションカテゴリに理想的です。
Aerospikeでは、これらのユニークな差別化要因を提供する強い一貫性スキームを開発しました。
1.高性能での強い一貫性
2018年初めにAerospike 4.0をリリースした際、リリースノートと技術情報を含むブログ投稿で、当時のAerospikeのCTOはこのように綴っています。
「内部テストにより、強い一貫性であっても高性能が達成可能であることが示されました。我々の予備的な結果は、セッション一貫性（別名逐次一貫性）での高性能を証明しています 。 APモードのAerospikeと比較して実質的な性能損失はありません。そして、完全な線形化で非常に高い性能を実現しています」
ブログには以下のパフォーマンスデータも示されています。
2: Aerospikeは他の強い一貫性システムよりもCPモードでの可用性が高い
最初から、Aerospikeのエンジニアは、一般的に発生する障害状況中に強い一貫性と可用性の両方を提供することに焦点を当てていました。
例えば、データベースシステムのローリングアップグレードは、ノードを一度に1つずつダウンさせ、アップグレードし、クラスターに戻すというものです。
もう一つは、ネットワーク障害中に正確に2つのサブクラスターが形成されるスプリットブレインシナリオです。
3つ目のケースは、複数のデータセンターにまたがる単一のデータベースクラスターのマルチラック展開でのラック全体の障害です。
これらの障害シナリオのすべてで、システムはオペレーターの介入なしに、一貫性と可用性を保ちながら100％のデータ可用性で継続することができます。
さらに、障害状況が解消されると、システムは再びオペレーターの介入なしに安定状態に戻ります。
したがって、Aerospikeは、他のシステムが利用できなくなる可能性のある多くの一般的な障害シナリオ中に、強い一貫性と100％のデータ可用性を、パフォーマンスへの影響を最小限に抑えながら維持します。
しかし、クラスター内のノードに影響を与える多くの同時障害が発生すると、CAP定理が発動し、システムは一貫性を保つためにデータの可用性を制限します。
5年以上にわたり、ユニークな強い一貫性アルゴリズムがAerospikeに、強い一貫性で展開された多くのミッションクリティカルなシステムに類を見ない可用性を提供し、業界をリードするパフォーマンスとアップタイムを実現してきました。
妥協の少ない強い一貫性
Aerospikeの強い一貫性機能に関するより詳細な情報はこちらからご覧いただけます。また、詳しい内容については担当者よりご紹介が可能です。ぜひご連絡ください！
このブログは、2024年1月25日のブログ「Implementing strong consistency in distributed database systems 」の翻訳です。
