01
テストの背景
Amazon Aurora MySQL は、クラウド専用に構築された MySQL 互換のリレーショナル データベースであり、商用データベースに匹敵するパフォーマンスと可用性を 1/10 のコストで実現します。
Amazon RDS for MySQL を使用すると、クラウドでの MySQL デプロイメントのセットアップ、運用、拡張が簡単になります。Amazon RDS を使用すると、スケーラブルな MySQL サーバーを数分でデプロイできます。
お客様が Amazon Cloud Technology を使用して MySQL データベース サービスをホストする場合、通常は Amazon Aurora MySQL または Amazon RDS for MySQL を選択する必要があります。このテストは、Amazon Aurora MySQL と Amazon RDS for MySQL のクラスターのフェイルオーバー時間と読み取り専用インスタンスの拡張時間を、さまざまなモード、さまざまなモデル、ワークロードの有無で比較し、お客様が Amazon Cloud Technology Services で MySQL データベースをホストする選択を支援することを目的としています。参考資料を提供します。
02
テスト環境
03
テストの前提条件
このテストは次の 3 つの前提に基づいています。
ストレス テスト インスタンス、Amazon Aurora MySQL、Amazon RDS for MySQL はすべて 1 つの VPC にあります
Amazon Aurora MySQL と Amazon RDS for MySQL はどちらも実稼働テンプレートのデフォルト設定を使用します
Amazon CloudTrail をオンにして、クラスターのフェイルオーバーと読み取り専用インスタンスの拡張の開始時間と終了時間を個別にカウントします。
04
テストアーキテクチャ図
4.1 Amazon Aurora MySQL テスト アーキテクチャ図
4.2 Amazon RDS for MySQL テストのアーキテクチャ図
05
テストケース
5.1 クラスター フェイルオーバー時間のテスト ケース。テストは次の 8 つの構成モードに基づいており、ワークロードなしとワークロードありのクラスター フェイルオーバー時間をそれぞれテストします。
*ワークロード シナリオ: データベースには 100 GB のデータが保存され、マスター ノードの CPU ワークロードは 80% です。
5.2 読み取り専用インスタンスの拡張時間のテスト ケース。テストは次の 8 つの構成モードに基づいており、ワークロードなしとワークロードありの読み取り専用インスタンスの拡張時間をそれぞれテストします。
*ワークロード シナリオ: データベースには 100 GB のデータが保存され、マスター ノードの CPU ワークロードは 80% です。
06
試験方法
6.1 クラスタフェイルオーバー時間の試験方法
1. Amazon Aurora MySQL の場合、コンソールでターゲット クラスターの書き込みインスタンスを選択し、次の画像の [フェールオーバー] ボタンをクリックします。
2. [ログとイベント] をクリックし、以下の最近のイベントでフェールオーバーの開始時刻と終了時刻を表示し、フェールオーバーに費やされた時間を計算します。
3. Amazon RDS for MySQL の場合、コンソールで対象クラスターのマスターインスタンスを選択し、下図の「再起動」ボタンをクリックし、次のページで「再起動とフェイルオーバーを実行するかどうか」にチェックを入れ、「確認」をクリックします。
4. [ログとイベント] をクリックし、以下の最近のイベントでフェールオーバーの開始時刻と終了時刻を表示し、フェールオーバーに費やされた時間を計算します。
5. ワークロードをシミュレートするシナリオで時間を再計算します。ワークロードをシミュレートする手順は次のとおりです。
ストレス テスト インスタンスに sysbench をインストールします (手順については、https://github.com/akopytov/sysbench を参照してください)。
次のコマンドに従って、100 GB のデータをデータベースに書き込みます
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --threads=64 --mysql-host=bench-test.cluster-cum78jhrtci1.ap-south-1.rds.amazonaws.com --mysql-user=admin --mysql-password=xxxx --mysql-port=3306 --mysql-db= bench _test --oltp-tables-count=100 --oltp-table-size=5000000 --db-driver=mysql prepare左にスワイプするとさらに表示されます
次のコマンドに従って、マスター ノードでストレス テストを実行します。
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=bench-test.cluster-cum78jhrtci1.ap-south-1.rds.amazonaws.com --mysql-user=admin --mysql-password=xxxx --mysql-port=3306 --mysql-db= bench_test --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --time=3600 --oltp-read-only=on --threads=120 run #可以通过调整 threads 来控制工作负载，不同数据库实例类型线程数不一样左にスワイプするとさらに表示されます
6.2 読み取り専用インスタンスの拡張時間のテスト方法
1. Amazon Aurora MySQL の場合、コンソールでターゲット クラスターを選択し、次の画像の [リーダーの追加] ボタンをクリックします。
2. CloudTrail の CreateDBInstance イベントの時刻を、読み取り専用インスタンスを追加する開始時刻として使用します。
3. コンソールに戻り、ターゲット クラスター「ログとイベント」の最後のステップの時刻を読み取り専用インスタンスの追加の終了時刻として使用します。
4. Amazon RDS for MySQL の場合、コンソールでターゲットクラスターを選択し、以下の画像の [リードレプリカの作成] ボタンをクリックします。
5. CloudTrail の CreateDBInstanceReadReplica イベントの時刻を、読み取り専用インスタンスの追加の開始時刻として使用します。
6. コンソールに戻り、ターゲット クラスター「ログとイベント」の最後のステップの時刻を読み取り専用インスタンスの追加の終了時刻として使用します。
7. シミュレートされたワークロード シナリオで時間を再計算します。ワークロードをシミュレートする手順は次のとおりです。
ストレス テスト インスタンスに sysbench をインストールします (手順については、https://github.com/akopytov/sysbench を参照してください)。
次のコマンドに従って、100 GB のデータをデータベースに書き込みます
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --threads=64 --mysql-host=bench-test.cluster-cum78jhrtci1.ap-south-1.rds.amazonaws.com --mysql-user=admin --mysql-password=xxxx --mysql-port=3306 --mysql-db= bench _test --oltp-tables-count=100 --oltp-table-size=5000000 --db-driver=mysql prepare左にスワイプするとさらに表示されます
次のコマンドに従って、マスター ノードでストレス テストを実行します。
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=bench-test.cluster-cum78jhrtci1.ap-south-1.rds.amazonaws.com --mysql-user=admin --mysql-password=xxxx --mysql-port=3306 --mysql-db= bench_test --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --time=3600 --oltp-read-only=on --threads=120 run #可以通过调整threads来控制工作负载，不同数据库实例类型线程数不一样左にスワイプするとさらに表示されます
07
テストデータ
7.1 クラスターフェイルオーバー時間のテストデータ
表に記録されている時間は、3 回のテストの平均時間です。
7.2 読み取り専用インスタンスの拡張時間テストデータ
表に記録されている時間は、3 回のテストの平均時間です。
08
テストの結論
Amazon Aurora MySQL のクラスターのフェイルオーバー時間は、読み取り/書き込みモード、インスタンス モデル、ワークロードとほとんど相関がなく、全体の時間は 29 秒から 41 秒の間に分布しています。Amazon RDS for MySQL のクラスターのフェイルオーバー時間は、読み取り/書き込みモードやインスタンス モデルにはあまり関係がなく、ワークロードに関係しています。ワークロードがない場合は 50 秒から 65 秒ですが、ワークロードがある場合は 85 秒に増加します。 -93 秒、ワークロードによるフェイルオーバー時間が長くなります。
Amazon Aurora MySQL の読み取り専用インスタンスの拡張時間は、読み取り/書き込みモード、インスタンス モデル、ワークロードとほとんど相関がなく、全体の時間は 6 分 08 秒から 6 分 57 秒の間に分布しています。Amazon RDS for MySQL の読み取り専用インスタンスの拡張時間と読み取り/書き込みモードは、インスタンス モデルにはあまり関係なく、ワークロードに関係しています。ワークロードがない場合、6 分 12 秒から 7 分 1 秒です。ワークロード発生時は6分12秒～7分1秒 15分19秒～15分31秒と増加 ワークロード発生時は読み取り専用インスタンスの拡張時間が長くなります。
Amazon Aurora MySQL と Amazon RDS for MySQL を比較する
ワークロードがない場合、Amazon Aurora MySQL クラスターのフェイルオーバー時間は Amazon RDS for MySQL の 64% であり、Amazon Aurora MySQL クラスターのフェイルオーバー時間はさらに短くなります。
ワークロードがなければ、Amazon Aurora MySQL の読み取り専用インスタンスの拡張時間は Amazon RDS for MySQL の 96% であり、両者の差はわずかです。
ワークロードが存在する場合、Amazon Aurora MySQL クラスターのフェイルオーバー時間は Amazon RDS for MySQL の 33% であり、Amazon Aurora MySQL クラスターのフェイルオーバー時間はより短くなります。
ワークロードがある場合、Amazon Aurora MySQL の読み取り専用インスタンスの拡張時間は Amazon RDS for MySQL の 42% であり、Amazon Aurora MySQL 読み取り専用インスタンスの拡張時間の方が短くなります。
要約すると、クラスターのフェイルオーバー時間と読み取り専用インスタンスの拡張時間の点で、Amazon Aurora MySQL は Amazon RDS for MySQL よりも優れています。
この記事の著者
ハン・ユーグアン
Amazon Cloud Technology ソリューション アーキテクト。インターネット ビジネスのビッグデータ ビジネス シナリオに精通しています。Amazon Cloud Technology に入社する前は、Cheetah Mobile でビッグデータのシニア オペレーションおよびメンテナンス エンジニアとして働いていました。10 年以上のオペレーションおよびメンテナンスの経験があり、クラウド アーキテクチャの設計を深く理解しており、クラウドの運用と保守、Devops、ビッグ データ ソリューションに関して豊富な実務経験を持っています。
郭李
2019 年にシニア ソリューション アーキテクトおよびソリューション アーキテクト マネージャーとして Amazon クラウド テクノロジーに入社しました。アーキテクト チームを率いて戦略的顧客と企業顧客をサポートする責任を負っています。Amazon クラウドの機械学習、データ分析、セキュリティ コンプライアンス テクノロジーの専門家でもありますテクノロジー。
聞いたので、下の 4 つのボタンをクリックしてください
バグに遭遇することはありません！
