AWS Re:cap 06: Amazon Aurora HA および DR グローバル復元力のための設計パターン (DAT442)

ビデオ: https://www.youtube.com/watch?v=TNURufOhu_A

Aurora のパフォーマンスへのアプローチ

パフォーマンスを目的としたレプリカの追加

● 読み取りトラフィックをレプリカにオフロードし、プライマリ ライターへの影響を軽減します。

● レプリカを特定のワークロード (分析など) 専用にすることで、ノイズの多い近隣を分離できます。

● きめ細かいパフォーマンス管理のために、最大 15 レプリカを追加できます。

● ストレージのスケーリング:

● Aurora ではストレージ容量とパフォーマンスが自動的に拡張され、手動プロビジョニングは必要ありません。

● インスタンスのスケーリング:

● フェイルオーバーとパフォーマンス管理のために、さまざまなサイズ (16XL、8XL、4XL など) のインスタンスを追加できます。

● DB インスタンスは弾力性があり、0 から 256 Aurora キャパシティ ユニットまで拡張できます。

● フェイルオーバー層は、サイズと容量に基づいてインスタンスのフェイルオーバー順序を管理するために定義されます。

● エラスティック インスタンスは、長期的なコストに影響を与えることなく、ワークロードの急増を管理するのに役立ちます。

課題: Aurora での接続管理

● 複数のインスタンスへの接続の管理、特にトランザクションの書き込み者の識別。

● テクニック:

● DB インスタンスごとに接続をプールして制限し、再接続を回避します。

● ドライバーフレームワーク:

● Spring や JDBC などの標準的な手法では、クラスタ化されたデータベースを効果的に処理できない場合があります。

Aurora エンドポイント

ライターエンドポイント

● 常に現在のライター ノードを指すため、一貫したトランザクション ルーティングが容易になります。

● リーダーエンドポイント:

● 大まかな負荷分散に DNS ラウンド ロビンを使用した読み取り操作用のインスタンスのプールを指します。

● カスタムエンドポイント:

● 特定のユースケース (分析など) 用のカスタム エンドポイントを作成するオプション。

AWS 高度なラッパードライバー

高速ドライバー

● クラスターの状態を詳細に把握した強化されたドライバーにより、迅速なフェイルオーバーが促進されます。

● RDS プロキシ:

● 接続を管理し、フェイルオーバー時間を短縮するための追加ツール。

● プラグイン:

● 強化されたフェイルオーバー、書き換え分割、Blue-Green デプロイメント。

マルチリージョンの復元力

● 課題: リージョンに障害が発生したりネットワークから切断された場合でも、ビジネスの継続性を確保します。

● 解決策: コピーを別のリージョンに維持し、最小限のコストで最新の状態に保ち、さまざまな目的に利用します。

● Aurora Global Database によるマルチリージョンの復元力:

● Aurora Global Database では、AMS および APG に対して最大 10 セカンダリ リージョンが許可されます。

● 内部レプリケーション サーバーは、リージョン間の非同期物理レプリケーションを処理します。

● ヘッド ノードは関与しないため、論理レプリケーションに関連するパフォーマンスが回避されます。

● 構成と利点:

● リージョン A: レプリカとストレージを備えたプライマリ リージョン。

● リージョン B: 最初にストレージを備えたセカンダリ リージョン。ローカル読み取り用の読み取り専用インスタンスを追加できます。

● 非対称構成も可能です。セカンダリ リージョンのインスタンスはプライマリと一致する必要はありません。

● RPO ラグは通常、領域ペアの距離に応じて約 1 秒です。

● グローバルエンドポイントとフェイルオーバー:

● グローバル エンドポイントはプライマリ リージョンの識別を管理します。

● リージョン A で障害が発生した場合、リージョン B へのフェイルオーバーが管理されますが、非同期レプリケーションによるデータ損失の可能性があります。

● グローバル エンドポイントは、迅速なリダイレクトのために Route 53 データ プレーンを使用して再ポイントされます。

● スイッチオーバー:

● スイッチオーバーは、両方のリージョンが正常な場合に実行されます。

● 領域 A がプライマリであることを停止するように指示され、領域 B がプライマリになります。

● 中断することなくリージョン間の迅速な移行を可能にします。

● 切り替えプロセス:

● 特別なログ レコード (マーカー ログ レコード) をログ レコード ストリームに挿入します。

● もう一方の側はマーカーを認識し、指定されたログ時刻にプライマリになります。

● 同時にリージョン A はプライマリでなくなり、クリーンなハンドオフが保証されます。

● 結果はゼロ RPO と非常に低い RTO (約 30 秒) になります。

メンテナンスとアップグレード

● バージョンアップグレード (例: PostgreSQL 16 から PostgreSQL 17) と OS パッチが必要です。

● 自己管理型システムには、ダウンタイム、ロールバック用のスナップショット、互換性テスト、パフォーマンス テストが必要です。

● Aurora は、フルマネージドで自動化されたマイナー バージョンとパッチのアップグレード エクスペリエンスを提供します。

● オペレーティング システムのローリング アップグレードが利用可能になり、可用性が向上します。

● メンテナンスアクションは、指定した時間枠内で定義することも、Aurora によって自動的に管理することもできます。

● AWS ヘルス ダッシュボードはメンテナンス通知を提供します。

● メンテナンスのためのオプトイン自動化を強くお勧めします。

● AWS 組織のアップグレード ロールアウト ポリシー:

● 開発環境、QA、本番環境の複数の DB クラスタにわたるアップグレードを管理する新機能。

● DB クラスタのフリートのライフサイクル管理の自動化を簡素化します。

● AWS 組織内の複数のリソースにわたるタグに基づいてアップグレード ポリシーを設定できます。

● 例：

● Prod のタグが付いたリソースは最後にアップグレードされます。開発リソースが最初にアップグレードされます。

● デフォルトの動作: 認識されたタグのないリソースは 2 番目にアップグレードされます。

● アップグレードのロールアウトには、リソースへのポリシーの割り当て、アップグレード順序の決定、メンテナンス期間内の段階的な進行が含まれます。

● メンテナンス期間中に問題が検出された場合に、アップグレードを柔軟に停止できます。

● インプレースアップグレード:

● オープンソースと互換性のないメジャー アップグレードの場合は、インプレース アップグレードが実行されます。

● データベース クラスターのクローンの作成、クローンのアップグレード、およびアプリケーションのテストが含まれます。

● 検証が完了すると、クローンは破棄され、アップグレードが実稼働クラスターに適用されます。

● ブルーグリーン展開:

● メジャーアップグレード、スキーマ変更、静的パラメータ変更に対するより柔軟なアプローチ。

● 論理レプリケーションを使用して古い環境 ( Blue ) の同期を維持しながら、新しい環境 ( Green ) を作成することが含まれます。

● 運用環境に移行する前に、グリーン環境でアップグレードをテストできます。

● スイッチオーバーは一貫性を維持するためにリソースの名前を変更し、わずか 1 分で完了します。

● Blue-Green デプロイメントは、複数のリージョンにわたるグローバル データベースで利用できるようになりました。

● Aurora APG および AMS の機能の概要:

● レプリカを追加して可用性を高め、フェイルオーバーを有効にします。

● AWS Advanced Rapid Drivers を使用して、フェイルオーバー プロセスをよりスムーズにします。

● 最大 10 セカンダリ リージョンにわたる耐久性と可用性を実現するグローバル データベース。

● 低遅延のローカル リージョン読み取りと、グローバル エンドポイントによるエンドポイント管理の簡素化。

● クラスター全体のアップグレード、高速クローン、メンテナンスのための Blue/Green デプロイメントを管理および自動化します。

オーロラの紹介 DSQL

● Amazon Aurora DSQL は、常に利用可能なアプリケーション向けの最速のサーバーレス分散 SQL データベースです。 Aurora DSQL は、最速のマルチリージョン読み取りおよび書き込みを提供します。これにより、お客様は、インフラストラクチャ管理やダウンタイム メンテナンスをゼロにして、あらゆるワークロードの需要に合わせて拡張することが容易になります。

● リレーショナル データベース、分散データベース アーキテクチャ、サーバーレス サービスの長所を組み合わせます。

● 複雑なクエリを実行し、スケールアウトし、従量課金制の価格を提供するように設計されています。

● DSQL アーキテクチャの概要:

● EC2 で実行されているセルフマネージド PostgreSQL との比較。

● DSQL は、PostgreSQL バックエンド プロセスと同様に、接続ごとにクエリ プロセッサを使用します。

● 読み取りクエリは、DSQL ストレージ エンジンに直接送信されます。

● 書き込みは、コミットされるまでクエリ プロセッサ上のメモリにバッファリングされます。

● コミット時に、トランザクションは同時実行制御のために Adjudicator に送信され、次に耐久性のために Journal に送信され、少なくとも 2 AZ にレプリケートされます。

● Journal は、従来の PostgreSQL と同様に、ストレージを更新するために使用されます。

● DSQL はアクティブ/アクティブ サービスであり、どの接続でいつでもデータの読み取りまたは書き込みを行うことができます。

● クエリ プロセッサ (QP) は、異なるホストまたは可用性ゾーン上で実行できます。

● DSQL での在庫状況:

● データベース ノードに障害が発生すると、クエリ プロセッサ (QP) が障害を検出し、トラフィックを正常なレプリカにシフトします。

● レプリカは同じアベイラビリティーゾーンに存在することも、異なるアベイラビリティーゾーンに存在することもできます。

● 実行中の操作では、再試行により遅延がわずかに増加する可能性があります。

● DSQL は継続的にデータをバックアップし、障害が発生したノードを自動的に置き換えます。

● 交換ノードはジャーナルに接続して最新のデータを入手します。

● 最適なパフォーマンスを得るために、トラフィックはローカル レプリカに戻されます。

● 同時実行制御と耐久性:

● Adjudicator は同時実行制御と競合解決を処理します。

● 単一の裁定者により、ネットワーク調整を必要とせずに競合を迅速に解決できます。

● スタンバイ アジュディケーターは、フェイルオーバーのために他の可用性ゾーンに保持されます。

● 失敗した場合、スタンバイ審査員がリーダーシッププロトコルを実行して新しいリーダーを選出します。

● クエリ プロセッサは、新しいリーダー審査員に対して実行中のコミットを再試行します。

● このプロセスはシームレスであり、アプリケーションからのアクションは必要ありません。

DSQL の高可用性

● DSQL は単一障害点がないように設計されています。

● アクティブ/アクティブ アーキテクチャにより、すぐに使用できる高可用性が実現します。

● DSQL は、増加する負荷に対処するために自動的にスケーリングするように設計されています。

● 同時実行制御プロトコル:

● DSQL は、トランザクションがめったに競合しないことを前提として、オプティミスティック同時実行制御を使用します。

● 競合が発生するとシリアル化失敗エラーが発生し、クライアントはトランザクションを再試行する必要があります。

● アプリケーションは、再試行とオプティミスティック同時実行制御の問題を処理する必要があります。

● ヘルパー関数を構築するか、最下位のアプリケーション層に処理を組み込むことをお勧めします。

● 不必要な競合の回避:

● 不要な競合を最小限に抑えて再試行を減らすようにアプリケーションを設計します。

● 異なる行を更新するトランザクションは、競合することなく同時にコミットできます。

● 内部シャーディングとスケーリング:

● DSQL は、裁定者とジャーナルの負荷の増加に対処するために、内部で自動的にシャード化します。

● クエリ プロセッサは、適切なシャードにコミットを送信します。

● 最適化された 2 フェーズ コミットにより、複数のシャードにわたるアトミック トランザクションが保証されます。

● DSQL は、新しいノードをオンラインにし、レプリカ間で負荷を分散することにより、自動的にスケールアウトします。

● DSQL のレプリカは常に強力な整合性を保っており、シームレスなスケーリングが可能です。

● DSQL の一貫性:

● DSQL は、時間ベースの同期プロトコルを通じて強力な一貫性を保証します。

● マイクロ秒精度のタイムスタンプには EC2 Time Sync Service を使用し、測定誤差を修正するには Clockbound ライブラリを使用します。

● 以前にコミットされたタイムスタンプより常に後の線形化可能なタイムスタンプを保証します。

● ストレージは整合性を確保するために行を返す前にジャーナルからの更新を待ちます。

2 フェーズ コミット (2PC) プロトコルの概要

● 2PC は、トランザクションのすべての参加者が一緒にコミットまたは中止されることを保証する分散システム プロトコルです。

● これは、準備とコミット/中止の 2 つのフェーズで構成されます。

● フェーズ 1: 準備フェーズ:

● コーディネーターは、参加しているすべてのノードに「準備」リクエストを送信します。

● 各参加者はトランザクションの作業を実行し、必要なロックを取得し、「準備された」レコードをトランザクション ログに書き込みます。

● 参加者は「はい」または「いいえ」の投票をコーディネーターに送り返します。

フェーズ 2: コミット/中止フェーズ

参加者全員が「はい」と投票した場合

● コーディネーターは、「コミット」レコードをログに書き込み、すべての参加者に「コミット」メッセージを送信します。

● 参加者はトランザクションをコミットし、ロックを解放し、コーディネーターに確認応答を送信します。

● 参加者の誰かが「いいえ」と投票した場合:

● コーディネーターは、「中止」レコードをログに書き込み、すべての参加者に「中止」メッセージを送信します。

● 参加者はトランザクションをロールバックし、ロックを解放します。

● 主な考慮事項: 原子性:

● 2PC は、トランザクションがアトミックであること、つまりすべてのノードで完了するか、すべてのノードで完全に失敗することを保証します。

● 一貫性：

● 複数のノード間でデータの一貫性を確保しますが、ブロックして決定を待つため、可用性に影響を与える可能性があります。

● 障害の処理:

● 障害から回復するメカニズムが含まれています。コーディネーターに障害が発生すると、手動介入が必要な「インダウト」状態になる可能性があります。

DSQL での接続管理

● DSQL への接続は、セッション ルーティング層によって管理されます。

● 変動を引き起こすネットワーク イベントが発生している間でも、接続を迅速に利用できるようにします。

● すぐに使用できるクエリ プロセッサ (QP) のウォーム プールを維持します。

● 接続が要求されると、DSQL はプールから使用可能な QP を割り当てます。

● 接続障害の処理:

● 接続障害が発生した場合、アプリケーションは障害を検出して再試行する必要があります。

● オプティミスティック同時実行制御セクションの再試行ハンドラーは、この目的に役立ちます。

● 可用性を維持するには、アプリケーションで接続エラーに対する再試行ロジックを実装する必要があります。

● ストレージやアジュディケータの障害とは異なり、アプリケーションは失敗した接続を手動で再接続する必要があります。

● DSQL は、適切な接続管理を促進するために、接続の最大有効期間を 1 時間に設定します。

● 接続管理のベスト プラクティス:

● クライアント側の接続プーリング ライブラリ (Java C3PO など) をヘルス チェックと最大接続有効期間とともに使用します。

● DSQL には本質的に接続プーリングが含まれているため、サーバー側のプーリング (例: PG バウンサー、RDS プロキシ) が不要になります。

● 待ち時間を短くするために、同じアベイラビリティーゾーン内の QP に接続することをお勧めします。

● 現在のゾーンが使用できない場合、DSQL は正常なゾーンに自動的にフェイルオーバーします。

DSQL のマルチリージョン クラスター

● DSQL は、2 つのリージョンにクラスターを作成し、3 番目のリージョンを監視リージョンとして指定することにより、マルチリージョン クラスターをサポートします。

● 監視リージョンはジャーナルのコピーを保持し、リージョン障害に対するクォーラムベースのプロトコルを容易にします。

● アプリケーションはリージョン間でアクティブな状態を維持でき、両方のリージョンで読み取りと書き込みを処理できます。

● クォーラムベースのプロトコル

● 分散システムで使用される方法で、操作が有効であるとみなされる前に操作に同意するために最小限の参加ノード (クォーラム) を要求することで、データの一貫性、フォールト トレランス、および信頼性を確保します。

● S3 クォーラムベースのプロトコル:

● 分散システムでは、「クォーラム」とは「会議を構成するために必要な最小限のメンバー数」を意味します。

● クォーラム メカニズムは、Amazon S3 のような分散ストレージ システムでデータの冗長性と一貫性を確保するための投票アルゴリズムです。

● 中心となる概念と用語:

● 読み取りクォーラム (Vr): 読み取り投票の最小数

● 書き込みクォーラム (Vw): 書き込み投票の最小数

● 総投票数 (V)

● 動作原理:

● 分散システム内に V 個のデータ レプリカがあると仮定します。

● データの一貫性を確保するには、読み取りおよび書き込み操作でノード確認の「クォーラム」を取得する必要があります。

● 基本的なルール:

● Vr + Vw > V: 同じデータの読み取りと書き込みが同時に行われないようにし、読み取りと書き込みの競合を回避します。

● Vw > V / 2: シリアル化されたデータ変更を保証し、2 つの書き込み操作が同時にデータを変更することを防ぎます。

● Vr と Vw を調整すると、システムの読み取りパフォーマンスと書き込みパフォーマンスのバランスをとることができます。

● Amazon S3 について:

● Amazon S3 は、2020 で、すべての GET、PUT、および LIST オペレーションに強い整合性があると発表しました。

● 書き込まれたデータはすぐに最新バージョンとして読み取れるため、ビッグデータのワークロードが簡素化されます。

● S3 は、少なくとも 3 つの可用性ゾーンにデータ レプリカを保存するアーキテクチャを通じて、高い耐久性と可用性を保証します。

地域的な障害の処理

● リージョンに障害が発生した場合 (リージョン B に障害が発生した場合など)、監視リージョンは障害の曖昧さを解消し、障害が発生したリージョンをクォーラムから除外するよう投票します。

● DSQL は、障害が発生したリージョンを除外するようにジャーナルを自動的に再構成し、クラスターが正常なリージョン (リージョン A) で利用可能な状態を維持できるようにします。

● データの損失はなく、トランザクションは引き続き少なくとも 1 つの他の AWS リージョンにレプリケートされます。

● 障害が発生したリージョン (リージョン B) がオンラインに戻ると、DSQL がそれを検出し、最新の状態に更新し、マルチリージョン構成を復元します。

● 推奨パターン: アクティブな冗長性を実現するために、両方のリージョンのクラスターと並行してアプリケーションをデプロイします。

● アクティブ冗長性の利点:

● アプリケーションを複数のリージョンのクラスターと並行してデプロイすると、待ち時間が短くなり、アプリケーションの機能を継続的に検証できます。

● グローバル エンドポイント (例: Route 53 DNS レコード) を使用して、最も近い利用可能な正常なリージョンにトラフィックを送信します。

● グローバル エンドポイントを使用したリージョン障害の処理:

● リージョンに障害が発生した場合でも、データは失われず、DNS はトラフィックを正常なリージョンに自動的に転送します。

● 継続的な検証により、正常な領域が動作していることが保証されます。

● DSQL でのメンテナンス:

● DSQL は、顧客によるメンテナンスの必要がないフルマネージド サービスです。

● クエリ プロセスは定期的に更新バージョンに置き換えられ、最新の OS、セキュリティ パッチ、パフォーマンスの向上、および機能が保証されます。

● お客様がメンテナンス作業を行う必要はありません。

● 要点:

● Aurora は、PostgreSQL、MySQL、DSQL の 3 つのエンジンを提供します。

● すべてのエンジンは、そのままの状態で 3 AZ の耐久性を備えています。

● スケーリング オプションはさまざまです。 APG および AMS は書き込みの場合はスケールアップし、読み取りの場合はスケールアウトします。 DSQL は、ハンズフリーの自動スケーリングを提供します。

● マルチリージョンに関する考慮事項: APG および AMS を使用すると、データを損失することなくフェイルオーバーをテストできます。 DSQL は、リージョン全体でのアクティブ/アクティブをサポートします。

● すべてのエンジンは、自動セキュリティ アップデートとマイナー バージョン アップグレードにより簡単なメンテナンスを提供します。