Nasdaq をフィーチャーした Amazon Time Sync による分散システムの改善

セッションノート

Barbara Lipskovoff からの引用: クロックを同期すると、通信が削減され、分散システムのパフォーマンスが向上します。
時計の目的
一般的な測定スケールとしての時計。
分散システムでの従来の使用: 信頼されておらず、人間による可観測性のために使用されます。
アプリケーション:
ログメッセージ、メトリクス、モニタリング、UI ダッシュボード。
金融サービス、ヘルスケア、放送メディア、オンラインゲームなどの業界の監査。
分散システムでは、信頼性の高いクロックによる操作の簡素化、ロックの削減、およびリーダーの選出が可能になる可能性があります。

時計とは何ですか?

コンピューター時計の構築の基本

定期的にティックするものと、そのティックをカウントするものが必要です。
通常は、両方の機能を組み合わせた 1 つのハードウェア部品です。
方程式表現:
時間 T で、クロック C は、経過したサイクル数を周波数と定数で割ったものとして読み取ることができます。
簡単な例:
ハードウェアが 1 秒あたり 1 サイクルで動作している状態で 1000 サイクルをカウントすると、1000 秒が経過します。
結論：
コンピュータ上で時計を構築するための基本コンポーネント。

クロックのハードウェアオプション

ハードウェアの範囲

小型のフォームファクターの水晶発振器から、セシウムビーム、水素メーザー、今後登場する光時計などの大型機器まで。
フォームファクタは、数ミリメートルからキャビネットサイズの機器までさまざまです。
価格ポイント:
フォームファクターが小さいと、クラウドコンピューティングのコスト効率が高くなります。
大型の装置には数十万ドルの費用がかかる場合があります。
品質と精度:
時間を 1 マイクロ秒以内に維持する精度は次のように異なります。
小型フォームファクター: 数秒間正確です。
水素メーザーと光時計：何年も、場合によっては何世紀にもわたって正確です。

クロックドリフト

すべてのオシレーターがドリフトする

最も正確な原子時計でもドリフトが発生します。
マイクロ秒レベルのドリフトを高精度の時計で観測するには何世紀もかかる場合があります。
ドリフトの原因:
製造プロセス、経年変化（物理学者にとっての懸念事項）。
クラウドプロバイダーの場合: CPU やサーバーへのワークロードの影響による、電源のわずかな違いや温度の変動。
ドリフトの影響:
サイクルの周波数は時間の経過とともに変化し、クロックのドリフトが発生します。
例: 5 日間実行した EC2 インスタンスは、補正なしでは 75 ミリ秒のドリフトを示しました。
クロックドリフトへの対処
追跡と修正:
人間が腕時計を調整するのと同じように、コンピュータもドリフトを追跡して修正する必要があります。
Network Time Protocol (NTP):
時計を同期するために何十年も使用されてきました。
クライアントの時計がサーバー (基準時計) にメッセージを送信して時刻を調整します。

クロック同期における課題

継続的な調整が必要

クロックサイクルの周波数は常に変化します。
正確な時刻を 1 回だけではなく、繰り返し尋ねる必要があります。
ネットワーク通信の問題:
ネットワーク上で交換されるメッセージにはさまざまな遅延が発生します。
メッセージがドロップされると失敗するリスク。

問題の一部としてのネットワーク

実行可能性と遅延

通信遅延にノイズが多いと、実際のクロックドリフトを識別することが困難になります。
ネットワークの非対称性:
ネットワークは対称ではないため、完全な時計であっても観測される時間には差異が生じます。
クロックエラーとネットワークの非対称性を区別するのは困難です。

AWS ソリューション: Amazon Time Sync Service

顧客向けに、非決定的なネットワークを介したクロック同期の複雑さに対処します。
実装：
2017年に導入されました。
NTP (Network Time Protocol) エンドポイントを使用します。
世界中のすべての EC2 インスタンスでローカルに利用できます。
投資：
このサービスをグローバルにサポートするには、エンジニアリングとハードウェアに多額の投資が必要です。

Amazon Time Sync Service

基本的なセットアップ

Nitro システムとソフトウェア時間デーモンを備えた EC2 インスタンス。
AWS 分散システムから Nitro システムを経由してサーバークロックを修正するための NTP パケット。
正確さ：
NTP サービスの精度: 1 ミリ秒未満、通常は 500 ～ 700 マイクロ秒。
お客様のメリット:
手間のかからない簡単なサービス。顧客が基盤となるテクノロジーを理解する必要はありません。

ナノ秒精度の課題と解決策

顧客の需要

顧客は、分散システムに対して 1 ミリ秒を超える精度を求めていました。
AWS アプローチ:
ナノ秒レベルの精度を実現するハードウェアに投資。
GPS と冗長アトミックハードウェアクロックからの専用ケーブルを使用しました。
信号 (GPS) は、AWS ネットワークをバイパスして、EC2 インスタンスに直接送信されます。
専用クロック同期:
クロック同期用の信号は完全に専用であり、データまたはコントロールプレーンを介しません。

Nitro ベースのシステム

Nitro クロック: ハードウェア基準クロック。
NTP パケット通信: Nitro カードと直接やり取りし、ネットワークは関与しません。
PTP ハードウェアクロック:
Nitro システムに Precision Time Protocol (PTP) ハードウェアクロックを追加しました。
ユーザーは PTP ハードウェアクロック (PHC) を読み取り、システムクロックをローカルで修正します。
精度レベル:
NTP: ソフトウェアレベルで 100 マイクロ秒未満。
PTP: ソフトウェアレベルで約 20 マイクロ秒。
広範な実装:
さまざまなサーバータイプ (Graviton、Intel、AMD、GPU) にわたって追加された参照 PTP ハードウェアクロック。
Nitro システムハードウェアをベースとして、グローバルなインフラ投資をサポートします。

ハードウェアパケットのタイムスタンプ

主な用途と利点

目的

ネットワークパケットのタイムスタンプのナノ秒レベルの精度を有効にします。
利点：
分散ワークロードのネットワークパフォーマンスの可観測性が向上しました。
サーバーが受信したメッセージをナノ秒の解像度で順序付けできるようにします。
ドライバーの組み込み機能。クラシックソケット API または DPDK ツールキット経由でアクセスできます。

仕組み

機能リリース前

アプリケーション層のタイムスタンプ:
メッセージが到着し、Nitro システムを通過してインスタンスに到達します。
アプリケーションはシステムクロックから時間を読み取り、タイムスタンプをメッセージに添付します。
ソケット API を使用して 4 行の C コードを使用します。
機能リリース後 (ハードウェアパケットタイムスタンプ):
Nitro システムと Nitro クロック:
メッセージが到着し、パケットはインスタンスに到達する前に Nitro システムと Nitro クロックによってタイムスタンプが付けられます。
タイムスタンプ付きのメッセージはアプリケーション層に渡されます。

実装とアクセス

アクセス方法

クラシックなソケット API。
カーネルインフラストラクチャをバイパスして直接パケットアクセスを行うための DPDK (Data Plane Development Kit) ツールキット。
解決：
ネットワークパケットの受信タイムスタンプにナノ秒の解像度を提供します。

比較例

前に

メッセージ受信後にシステムクロックから時刻を読み取る単純な処理。
後：
メッセージがアプリケーションに到達する前にハードウェアによってパケットのタイムスタンプが実行されるプロセスが強化され、より正確なタイムスタンプが提供されます。

ハードウェアパケットタイムスタンプの利点の強化

精度の向上

ネットワークパフォーマンスをより正確に表示します。
例: 2 つのインスタンス間の往復時間を測定します。
ユーザー空間アプリケーションの測定: ~400 マイクロ秒。
ハードウェアパケットタイムスタンプ測定: ~100 ～ 150 マイクロ秒。
観察可能な違い:
最大 250 マイクロ秒の差は、オペレーティングシステムとネットワークスタックで費やされた時間に起因します。
往復時間の約 2/3 を表し、より正確な観測可能性を強調します。
より鮮明なネットワークパフォーマンス:
アプリケーションとネットワーク間の遅延を特定し、内訳することができます。

NASDAQ の使用例の紹介

客観的

AWS の高精度時間テクノロジーを使用して、パブリッククラウド環境での市場運営に向けた NASDAQ の進歩を実証するため。

NASDAQ 背景

金融市場のイノベーター

1971年に誕生した世界初の電子取引所。
株式、債券、オプション、デリバティブなど、世界中で 30 以上の市場を運営しています。
Amazon など、時価総額トップのテクノロジー企業をホストしていることで知られています。
テクノロジープロバイダー:
130 以上の市場運営者と 2,300 の金融機関にサービスを提供しています。
世界中の NASDAQ 取引所に上場されている 44,400 社以上の上場企業をサポートしています。
資本市場のライフサイクルをサポートするテクノロジーを 6,000 社に提供。

NASDAQ のクラウドの旅

10年以上前に始めた

AWS Redshift を使用したデータリポジトリとデータウェアハウジングから始まりました (2012 ～ 2013)。
現在約 60 ペタバイトのデータを保存し、バックオフィス機能をサポートしています。
リアルタイム処理への進化:
リアルタイム市場情報のストリーミングを使用した市場監視。
パブリッククラウドを通じて市場データの配信が可能。
AWS Outpost でのオプション取引所の開始:
2022年、AWS OutpostでNASDAQ MRXを発売。
現在、Outpost で 6 つ以上のマーケットシステムを実行しています。
パブリッククラウドの重要なシステム:
市場参加者にリアルタイムの洞察を提供するホストシステム。
クラウドのスケーラビリティ、パフォーマンスを活用し、大量のメッセージとピーク時の管理容量に合わせた適切なサイジングを実現します。

クラウドへの移行における特有の課題

地理的制約

株式および株式オプションの取引は主に New Jersey 北部で行われます。
遅延の依存関係により、特定の場所にコンピューターを展開する必要があります。
超低レイテンシーのトランザクション:
トランザクションは、注文から動作までの時間約 20 マイクロ秒で測定されます。
大量のメッセージ:
1 日に 1,000 億件を超えるメッセージを処理します。
特定の交換システムは、1 秒あたり最大 200 ～ 300 万のメッセージを処理します。
高い復元力と稼働時間の期待:
資本市場が効率的かつ適切に運営されるためには不可欠です。
多数の上場企業の主要上場会場。

NASDAQ Exchange システムアーキテクチャ

マッチングエンジン

注文の予約、取引、買い手と売り手のマッチングのための主要なロジックを処理します。
ポートの注文:
顧客が注文フローを取引所に送信するためのインターフェイス。
検証、取引前リスク、その他の機能を実行します。
公開市場データフィード:
エンジンのアクティビティを市場にマッチングするビューを公開します (例: NASDAQ I)。
クライアント:
インバウンドトランザクションを通じて、注文ポートとマッチングエンジンへの注文フローを提供します。

従来のオンプレミスモデル

客観的

決定論的で統計的に公平な市場を参加者に提供します。
身体的特徴への依存:
データセンター内のファイバーの長さ。
システムコンポーネントと顧客の間のスイッチホップの数。
ネットワーク遅延の原因:
D1 と D2:
物理的なセットアップによるネットワーク遅延の主な原因。
D3:
ネットワークと処理コンポーネントの両方が含まれます。
往復遅延の約半分、約 10 マイクロ秒。
秩序ある処理:
マッチングエンジンの順次処理により、注文が顧客によって送信され、顧客および公開市場データフィードに返されるときに一貫して繰り返し処理されることが保証されます。

パブリッククラウドの課題

予測できないネットワーク状態。
固定されたケーブル長や既知のスイッチホップはありません。
他のネットワークトラフィックまたは予測できないノード配置による潜在的な遅延。

解決策: ハードウェアのタイムスタンプと並べ替えバッファー

主要な期間

ネットワーク経由のトランザクション時間を理解するには、D1、D2、および D3 に焦点を当てます。
ハードウェアのタイムスタンプ:
ナノ秒の精度を使用して、各ネットワークポイントでの各トランザクションの時間を記録します。
Nitro および Amazon Time Sync Service を通じて提供されます。
並べ替えバッファ:
マッチングエンジンの前に位置します。
インバウンドトランザクションの順序付けに焦点を当てます (アウトバウンドフローにも同様のテクニックが適用されます)。
時間ベースの境界:
ハードウェアのタイムスタンプを使用して定義します (例: クライアントからの注文の場合は T1、T2、T3)。
トランザクションが発生した順序で処理されるようにします。
特許取得済みの技術:
低遅延システムのパブリッククラウドに向けた NASDAQ の姿勢を進化させるための基盤です。

プロトタイプと実験

使用される AWS インスタンス

M7I.2XL インスタンス。
近接配置グループ:
コンピューティングノードが複数のラックまたは同じラック内に近接して配置されていることを確認しました。
並べ替え用のハードウェアタイムスタンプ:
タイムスタンプに基づいてパケットを並べ替えるのに使用されます。
時間境界のあるテスト:
5 マイクロ秒の境界により、パケットの約 25% が並べ替えられました。
50 マイクロ秒境界で最大 84% 以上のパケットが再順序付けされました。
反復と進化:
近接配置機能と Amazon Time Sync Service については、粒度をさらに高めるために継続的に取り組んでいます。

戦略的ビジョン

スケーラブルな取引システム

パブリッククラウドでもオンプレミスでも、スケーラブルで高性能なシステムの開発を目指します。
パブリッククラウドのイノベーション:
AI やデータのパブリッククラウドへの移行など、クラウドイノベーションを採用します。
強化されたセキュリティと信頼性:
可用性、セキュリティ、信頼性に対する高い期待。
パブリッククラウドは、復元力を考慮して責任を持って構築すれば、大きな利点をもたらします。
市場専門知識の活用:
世界中で 30 の取引所を運営し、130 の市場にテクノロジーを提供するリーダーとして、NASDAQ はテクノロジーの適用について戦略的に考えています。

ソフトウェアでの優れたクロックの活用

同期クロックを使用した分散システムでの通信の削減を強調します。
AWS 時刻同期サービス:
ソフトウェアでマイクロ秒の精度でナノ秒範囲のクロックを提供します。
ハードウェアパケットのタイムスタンプ:
アプリケーションはより正確なタイミングから恩恵を受けることができ、パフォーマンスと可観測性が向上します。

分散システムの課題

複数のクロック

分散システムには複数のサーバーがあり、それぞれに独自のクロックがあります。
クロックは完全には同期していないため、イベントの順序付けが複雑になります。
従来のソリューション:
分散ロック、リーダー選出、および順序付けに使用されるコンセンサスアルゴリズム。
これらのアルゴリズムはパフォーマンスを制限し、システムが成長するにつれて複雑さを増します。

クロックの不確実性と誤差の範囲

人間の視点

人間は時間を正確であると考えますが (例: 午後 2 時)、時計には不確実性があります。
精密時計:
ソフトウェア層の AWS 精度クロックには不確実性があります (例: ±20 マイクロ秒)。
アプリケーションの誤差の範囲:
アプリケーションでは、この誤差の範囲を考慮する必要があります。
例: 銀行口座の取引では、当座貸越を避けるために正しい注文が必要です。

クロックの不確実性の推定

複雑な質問

顧客は時計の不確実性の間隔を理解する必要があります。
例：
EC2 インスタンスの時刻同期デーモンを検査してエラーを推定します。
時刻同期のソース:
インターネット NTP サーバー (time.aws.com など): ~395 マイクロ秒の不確実性。
Nitro システム経由のローカル NTP サーバー: ~90 マイクロ秒の不確実性。
PTP ハードウェアクロック (Nitro システムによる拡張 Amazon Time Sync Service): より正確です。

AWS 簡略化

AWS は、顧客が時計の不確実性を理解し、管理できるようにすることを目的としています。
深い技術知識がなくてもお客様をサポートできるよう、詳細な説明が提供されます。

AWS Clockbound ソフトウェア

目的

お客様の時計の不確実性の理解と管理を簡素化します。
可用性：
オープンソースで、2021 年から GitHub で利用可能です。
主な機能:
1 回の操作で 3 つの情報を提供します。
現在の時刻: 例: 月曜日の午後 2 時
不確実性の範囲: 例: ±20 マイクロ秒。
クロックステータス: 初期化、フリーランニング、または同期。
サポートとスケーラビリティ:
PTP ハードウェアと NTP ソースをサポートします。
要求の厳しいワークロードに合わせて拡張し、1 秒あたり数百万のクエリを実行できます。
言語と互換性:
パフォーマンスとメモリの安全性を考慮して Rust で書かれています。
RSS ではクラウドとして、また C アプリケーションで利用できます。

クロックエラー限界

発振器のドリフトと通信遅延による最悪の場合のクロック誤差に対する最も厳しい制限。
Clockbound の役割:
蓄積されたエラーにもかかわらず正確な回答を提供し、ナノ秒およびマイクロ秒レベルの精度シナリオで威力を発揮します。
YugabyteDB Clockbound の使用法
AWS のオープンソース Clockbound ソフトウェアを使用したオープンソースデータベース。
ハイブリッド論理クロックシステム:
従来の論理順序と高精度クロックを組み合わせます。
観察された利点:
遅延の削減: お客様は遅延が 3 分の 1 に短縮されました。
スループットの向上: トランザクションのスループットが 2 倍になりました。
再試行の減少: トランザクション間の競合 (読み取りと書き込みなど) が減少するため、再試行が 1000 分の 1 に減少します。
顧客エクスペリエンスの向上:
データベースの一貫性、分離性、および全体的なユーザーエクスペリエンスが強化されました。

AWS の高精度クロックの使用

高精度時計を活用したサービス

Aurora DSQL: マルチリージョン、グローバルスケールのデータベース。
Dynamo DB グローバルテーブル: マルチリージョン、グローバルスケールのデータベース。
使用理由:
リージョン間のネットワーク遅延 (例: 米国西部 2 と米国東部 1 の間で 70 ミリ秒)。
高精度時計の利点:
マイクロ秒からナノ秒の範囲のクロックにより、ネットワーク経由でパケットを送信するよりも高速なトランザクションの順序付けが可能になります。

AWS による Aurora DSQL での高精度クロックの使用

マルチリージョンのデータベースの一貫性

マルチリージョンデータベースの一貫性と分離を維持するために重要です。
Clockbound の不確実性ウィンドウ:
さまざまな地域にわたるイベントを管理するために使用されます。
例: イベント 1 は、イベント 2 または 3 と比較して過去であることが保証されます。
イベント 2 と 3 には重複があるため、再試行を避けるために慎重な処理が必要です。
考えられる解決策:
再試行を防ぐためにイベント (イベント 3 など) の開始を遅らせます。
データベース設計の考慮事項:
システム設計、イベントの種類、顧客の要件によって異なります。

新しい EST デーモンのリリース

目的

顧客による高度なタイミング機能の使用を簡素化するため。
改善点:
既存の Clockbound ソフトウェアと同じソフトウェアスタックの下に構築されています。
大幅な改良により、精度と信頼性が向上しました。
顧客の信頼:
AWS は、顧客の信頼とエクスペリエンスを長期にわたって維持および向上させることを目指しています。
スタンドアロン時間クライアント:
Clockbound には、スタンドアロンの時間クライアントとデーモンが含まれるようになりました。
同期と情報提供:
オペレーティングシステムのクロックを同期します。
現在の時刻、不確実性ウィンドウのサイズ、およびクロックのステータスをアプリケーションに提供します。
規制と観察可能性の理由:
法規制への準拠とシステムの可観測性にとって重要です。
組み込みのメトリクスと可観測性:
可観測性は、組み込みメトリクスを備えた第一級の機能です。
高性能とメモリの安全性:
メモリの安全性と高いパフォーマンスを実現するために、同じ Rust ソフトウェアスタック上に構築されています。
プロセス間通信用の共有メモリセグメントにより高いパフォーマンスを実現します。

クラウドファースト設計のパラダイムシフト

クラウドファーストになるようシステムを再設計しました。
従来のフィードバックループシステムから、クラウドアプリケーションに適したフィードフォワード情報システムに移行します。
テスト用シミュレータ
新しいソフトウェアスタックにはシミュレータが付属しています。
ユーザーがソフトウェアをテストし、問題を報告し、改善を提案できるようにします。
クラウドネイティブな同期
可用性は、仮想化のすべての層にわたって最優先事項です。
VM クロック (仮想マシンクロック) と呼ばれる新しい機能を Linux カーネルに提供しました。
新リリースの Clockbound との組み合わせ:
Nitro クロックからインスタンスへの時刻の直接転送を許可します。
メンテナンスイベント中のパフォーマンスが向上し、スムーズなワークロード操作が保証されます。
新システムの性能
システムは、複数時間にわたってドリフトを追跡し、±1 マイクロ秒以内に修正します。
不確実性の窓:
Clockbound デーモンのクエリによってプロットされた不確実性のウィンドウのサイズ。
ノコギリ波動作: クロックが更新されると拡大または縮小します。
達成された不確実性ウィンドウ: アプリケーション内で 20 ～ 26 マイクロ秒。

Northern New Jerseyの株式とオプションは、Wall Street取引を推進する主要な金融データハブ（SecaucusのEquinixのような）としての役割、金融専門家を惹きつける近接性、安定した配当を提供するNJRのような企業による堅調な地域経済などにより重要です。強力なインフラとニューヨークへの通勤手段に支えられ、多様な投資を生み出しています

ハイテクデータセンターから確立された企業までの風景。

ニュージャージー州北部が株式とオプションのハブとなる理由

データセンター大国: ニュージャージー州 Secaucus は、高頻度取引に不可欠な主要なデータセンター (Equinix NY4 など) をホストしており、活動を Manhattan から移し、ニュージャージーを金融テクノロジーの中心地にしています。
ニューヨーク市への近さ: 優れた交通機関 (電車、フェリー) がニュージャージー州とニューヨーク市を結び、金融専門家を惹きつけ、Manhattan の金融街で働く人々にとっての高級住宅地となり、ベルゲンや Hudson Counties などの地域経済を押し上げています。
有力な地元企業: New Jersey は、一貫した配当と価値指標で知られる、配当重視の株式投資家にとって魅力的な New Jersey Resources (NJR) などの企業を設立しました。
投資エコシステム：この地域は、不動産の大幅な値上がり（株式の一種）、安定した需要、そしてNJEDA（New Jersey Economic Development Authority）が支援する「イノベーションエコシステム」の成長の恩恵を受けており、伝統的な投資とテクノロジー主導の投資の両方を促進しています。
税金と規制環境: New Jersey には、非居住者ストックオプション収入に対する規制などの特定の規制があり、投資家に影響を与える高度な金融規制の枠組みを示しています。
これが投資家にとって何を意味するか
データとテクノロジーへの注力: テクノロジー関連分野と金融をサポートするデータインフラストラクチャにチャンスが存在します。
価値と収入: 州内またはその近郊に拠点を置き、不動産投資 (不動産株式) と並行して、安定した配当金を支払う企業を探します。
通勤者の魅力: ニューヨーク市への通勤が盛んなエリア (Weehawken、Bergen County など) は需要が高く、堅実な不動産の株式市場を表しています。

Equinix のニュージャージー州 Secaucus キャンパス (NY2、NY4、NY5、NY6) は、Wall にとって重要な低遅延ハブです

主要な金融取引所や取引エコシステムへの直接接続を提供するストリート、

多数の金融会社を収容し、高セキュリティで信頼性の高いコロケーションを提供します。

高頻度取引 (HFT) や Dow Jones ニュースフィードなどの重要なデータサービスにより、

スピードと市場への近さ。これらの施設はデジタルバックボーンとして機能し、企業が次のことを可能にします。

取引を高速化するためにサーバーを取引所の近くに配置します。

Wall Street にとって重要な理由

低遅延: 交換局に物理的に近いため、HFT にとって重要なデータの移動時間が最小限に抑えられます。
市場アクセス: 取引会場、データプロバイダー (Dow Jones など)、およびその他の金融参加者への直接接続。
信頼性: 中断のない財務業務を実現するために、堅牢な電力、冷却、セキュリティを備えた設計。

Amazon Aurora グローバルな復元力を実現する HA および DR 設計パターン

(DAT442)

レジリエンスの定義

中断からワークロードを回復する能力
リソースの動的な取得と中断の軽減が含まれます
高可用性 (HA):
ワークロードが利用可能な時間の割合
歴史的に測定されたもの (例: 5/9 の可用性)
災害復旧 (DR):
インシデント後にワークロードを回復するためのテクニック
目標復旧時間 (RTO): サービスを再開するまでの最大時間
目標復旧時点 (RPO): 許容可能な最大データ損失
Aurora に焦点を当てる:
Aurora PostgreSQL (APG) および Aurora MySQL (AMS)
同様の機能と復元力

高可用性 (HA)

目標: システムの継続的な稼働を維持し、中断を最小限に抑え、単一障害点を回避します。
方法: 冗長性、自動フェイルオーバー、負荷分散。多くの場合、同じデータセンターまたはリージョン内で行われます。
例: 複数のインスタンスを持つ Web サーバー、1 つのノードに障害が発生した場合に自動スイッチオーバーを行うデータベースクラスター。
焦点: マイナーで頻繁に発生する問題 (ハードウェア障害、メンテナンスなど) に対するフォールトトレランス。
災害復旧 (DR)
目標: 大規模災害 (自然災害、大規模なデータ破損) の後に業務を復旧します。
方法: バックアップ、レプリケーション、オフサイトデータセンター、定義されたリカバリ手順 (RTO/RPO)。
例: クラウドバックアップからのデータの復元、リージョン停止後のセカンダリリージョンへのフェールオーバー。
焦点: 大規模で壊滅的な出来事に対する回復力。
主な違いと関係
範囲: HA は小規模な障害を処理します。 DRは大きなものを扱います。
アプローチ: HA はプロアクティブです。 DR はリアクティブです。
統合: それらは補完的です。堅牢な HA は DR の必要性を軽減しますが、DR は HA が不十分な場合に究極のセーフティネットを提供します。

データベースノードに障害が発生した場合はどうなりますか?

自己管理型データベース

データベースエンジンとストレージを組み合わせた単一ノード
バックアップ中の潜在的なパフォーマンスの問題
RPO は最長 24 時間になる場合があります
ノードに障害が発生した場合、RTO は何時間にも及ぶ可能性があります。
Aurora の耐久性:
1 つのアベイラビリティゾーン内の 1 つのデータベースクラスターから開始
データレプリケーションにAuroraストレージを利用
3 つの AZ にまたがるノードを備えたマルチテナントストレージフリート
各書き込みは 3 つの AZ にわたって 6 回レプリケートされます。
ユーザーは 1 部のみ料金を支払います
非同期レプリケーションがない場合、RPO は 0 です
Aurora はページではなくログレコードのみを書き込み、耐久性とパフォーマンスを向上させます。
Aurora でのバックアップと復元:
ストレージエンジンは、パフォーマンスに影響を与えることなく、データを S3 に継続的にバックアップします。
ポイントインタイム復元 (PITR) は、復元可能な最も早い時間 (最大 35 日) から最も遅い時間 (ビジーなデータベースの場合は約 5 分前) まで利用できます。
復元プロセスには、S3 からのデータの取得、内部ログレコードの適用、トランザクション回復のためのエンジンの起動が含まれます。
データベースインスタンスの可用性:
基本構成には 1 つのインスタンスが含まれます。故障した場合は交換に 10 ～ 15 分かかります。
スタンバイインスタンスを追加すると、可用性が向上します。 Aurora はプライマリとの同期を維持します。
スタンバイインスタンスへのフェイルオーバーは数秒以内に行われ、同じサイズと負荷容量が維持されます。
結果として RPO は 0、RTO は通常約 30 秒となり、マルチ AZ 可用性パターンが実現します。

パフォーマンスの回復力

パフォーマンスはアプリケーションの要求に応じて変動する可能性があり、リソースが無駄になる可能性があります。
オープンソースソリューションは、スケールアップ (ハードウェアのアップグレード) またはスケールアウト (データベースの分割) を提供しますが、どちらも一貫性とノイジーネイバーにとって課題です。