Spanner Omni は、TrueTime API のソフトウェア ベースのバージョンを実装することで、セルフマネージド環境で外部整合性を実現します。このシステムは、クラスタベースのアーキテクチャに依存して、信頼できるタイムスタンプを提供します。これにより、トランザクションがインフラストラクチャ全体で厳密なシリアル順序を反映します。
正確で一貫性のあるタイムスタンプとシリアライズ可能性を維持するには、ネットワーク レイテンシとクロック ドリフトに基づいて時間間隔を計算するプライマリ タイムサーバーとホストベースのクライアントを構成します。特定の指標でデプロイのパフォーマンスをモニタリングし、基盤となるハードウェアがクロックレート エラーとタイムスタンプ同期の必要な仕様を満たしていることを確認します。
Spanner Omni と TrueTime
Spanner のマネージド バージョンと同じ外部整合性を提供するために、Spanner Omni は Google の TrueTime API のソフトウェア ベースの実装を使用します。マネージド Spanner 環境では、TrueTime は物理的な GPS 受信機と原子時計に同期された複数のタイムサーバーを使用して、不確実性の間隔を狭めています。Spanner Omni はセルフマネージド インフラストラクチャで実行され、この物理ハードウェアに依存できないため、クラスタベースのアーキテクチャを使用して整合性を実現します。
この実装では、すべてのトランザクションが順次実行されます。あるトランザクションが別のトランザクションの開始前に終了した場合、2 番目のトランザクションには最初のトランザクションの効果が反映されます。Spanner Omni は、次の因果関係の順序付けに依存しています。t1 = TrueTime::Now() の呼び出しが t2 = TrueTime::Now() の呼び出しの開始前に完了した場合（異なるマシン上でも）、t2.latest は t1.earliest よりも後になります。これらの間隔から commit タイムスタンプを割り当てることで、Spanner Omni は、トランザクション t1 がトランザクション t2 の開始前に commit された場合、キー タイムスタンプに t1 が t2 の前に発生したことが反映されるようにします。
Spanner のマネージド バージョンで TrueTime が使用される方法については、Spanner のドキュメントの TrueTime と外部整合性をご覧ください。
TrueTime アーキテクチャ
クラスタベースのアーキテクチャでは、次の 2 つのコア コンポーネントを使用して、デプロイ全体で TrueTime を提供します。
タイム サーバー: クラスタは、1 つのデータベース サーバーをプライマリ タイム サーバーとして指定します。サーバーは、Spanner Omni デプロイ全体で信頼できる唯一の情報源であり、ローカルの高精度クロックから時刻を提供します。高可用性を確保するため、プライマリ サーバーが応答しなくなった場合、クラスタは別のデータベース サーバーを動的に昇格させてこのロールを引き継ぎます。タイムサーバーは Spanner Omni バイナリにバンドルされているため、個別のインフラストラクチャや外部依存関係は必要ありません。
タイム クライアント: デプロイ内の各ホストマシンでバックグラウンド デーモンが実行されます。プライマリ タイムサーバーに定期的にクエリを実行して現在の時刻パラメータを取得し、マシンで実行されているプロセスに公開します。
TrueTime は、Spanner Omni データベース サーバーとプライマリ タイムサーバー間のネットワーク ラウンドトリップ時間（RTT）と、境界付きのクロック ドリフトに基づいて時間間隔を計算します。デプロイ内のすべてのホストマシンには、レート エラーの既知の範囲内で動作するローカル クロックが必要です。
不確実性（イプシロン）とレイテンシへの影響
TrueTime は、単一の値ではなく、インターバル [earliest, latest] として時間を表します。TrueTime は、次の 2 つの要因に基づいて、この不確実性間隔のサイズを計算します。
ネットワークのラウンドトリップ時間（RTT）: タイム クライアントとプライマリ タイムサーバー間の同期中のレイテンシ。プライマリ タイムサーバーと同じデータセンターにあるクライアントは、リモート データセンターにあるクライアントよりも不確実性が大幅に低くなります。
クロック ドリフト: クライアント マシンとサーバー マシンの物理クロックが同期の間に自然にドリフトすること。
不確実性が高いと、トランザクションの commit 待ち時間が長くなる可能性があります。ただし、Paxos レプリケーションにもネットワーク通信が必要であるため、TrueTime の不確実性が Paxos のラウンド トリップ レイテンシよりも小さい限り、トランザクションの commit レイテンシは増加しません。
詳細については、Spanner の仕組み: 厳格な直列化可能性と外部整合性について理解するをご覧ください。
ハードウェア要件
ソフトウェア ベースの TrueTime が正しく機能するには、基盤となるハードウェアが次の要件を満たしている必要があります。
- タイムスタンプ カウンタ: ハードウェア タイムスタンプ カウンタを使用する必要があります。Linux x86 アーキテクチャでは、このカウンタはタイムスタンプ カウンタ（TSC）です。
- クロックレートの誤差の範囲: ローカル クロックは、公称周波数からの既知の範囲内のレート誤差で動作する必要があります。
sla_tester_violation_count指標を使用して、クロックレート エラーの違反をモニタリングできます。詳細については、TrueTime のオブザーバビリティをご覧ください。
制限事項
Spanner Omni を実行している仮想マシン（VM）またはコンテナのライブ マイグレーション中は、TrueTime はサポートされていません。Amazon Web Services（AWS）などのプラットフォーム上の特定の認定マシンタイプと Amazon マシンイメージ（AMI）には例外があります。詳細については、Spanner Omni のシステム要件をご覧ください。
オブザーバビリティ
Grafana の TrueTime ダッシュボードを使用して、次の指標をモニタリングできます。これらの指標を使用して、ソフトウェア ベースの TrueTime が想定されるパラメータ内で動作していることを確認します。
| 指標 | 説明 | 推奨される対処方法 |
|---|---|---|
true_time_is_available |
TrueTime API が利用可能かどうかを確認します。 | 利用不可に対するアラートを構成します。TrueTime が使用できない場合、Spanner Omni も使用できない可能性があります。使用不能状態は一時的な場合と永続的な場合があり、調査が必要です。 |
sla_tester_violation_count |
クロック動作の問題またはハードウェア要件の違反の可能性を示します。 | 調査して違反の原因を特定します。考えられる原因としては、ライブ マイグレーション、VM の一時停止、TSC が想定されるクロック レートの範囲外で動作していることなどが考えられます。 |
true_time_interval_uncertainty |
TrueTime 間隔の イプシロンを追跡します。 | この指標をモニタリングして、トランザクションのレイテンシを最小限に抑えます。不確実性が高いと、コミットの待機時間が長くなり、トランザクション全体のレイテンシが増加する可能性があります。 |