AWSでMySQLまたはMariaDBを管理するためのRDSとEC2の比較

RDSは、AWSクラウドでデータベースを自動的に構成および維持するサービスとしてのデータベース（DBaaS）です。ユーザーは、Elastic Compute Cloud（EC2）で直接MySQLを実行する場合と比較して、特定の構成に対する権限が制限されています。ただし、RDSは、提供されるインスタンスと構成を使用できる限り、便利なサービスです。

Amazon RDSは現在、さまざまなMySQLおよびMariaDBバージョンと、MySQL互換のAmazonAuroraDBエンジンをサポートしています。レプリケーションはサポートされていますが、事前定義されたWebコンソールから予想されるように、いくつかの制限があります。

RDSを使用する場合、いくつかのトレードオフがあります。これらは、データベースインスタンスの管理とプロビジョニングの方法だけでなく、パフォーマンス、セキュリティ、高可用性などの重要な要素にも影響を与える可能性があります。

このブログでは、レプリケーションに焦点を当てて、RDSの使用とEC2でのMySQLの実行の違いを見ていきます。これから説明するように、EC2インスタンスでMySQLをホストするか、AmazonRDSを使用するかを決定するのは簡単な作業ではありません。

RDSプラットフォームのトレードオフ

AWSがホストできるデータベースの最大サイズは、ソース環境、ソースデータベース内のデータの割り当て、およびシステムのビジー状態によって異なります。

AWSはリージョンに分割されています。すべてのAWSアカウントには、リージョンごとに、作成できるAWSリソースの数に制限があります。リソースの制限に達すると、そのリソースを作成するための追加の呼び出しは失敗します。

Amazon RDS MySQL DBインスタンスの場合、プロビジョニングされた最大ストレージ制限により、InnoDBファイル/テーブルテーブルスペースを使用する場合、テーブルのサイズは最大サイズ6TBに制限されます。

InnoDBのテーブルごとのファイル機能は、大きなデータベースをクラウドに移行することを検討していない場合でも考慮する必要があります。一部の既存のDBインスタンスには下限があることに気付くかもしれません。たとえば、2014年4月より前に作成されたMySQL DBインスタンスには、2TBのファイルとテーブルのサイズ制限があります。この2TBのファイルサイズ制限は、2014年4月より前に取得されたDBスナップショットから作成されたDBインスタンスまたはリードレプリカにも適用されます。

データベースレプリケーションの設定と維持の方法に影響を与える主な違いの1つは、SUPERユーザーがいないことです。この制限に対処するために、AmazonはさまざまなDBAタスクを処理するストアドプロシージャを導入しました。以下は、MySQLRDSレプリケーションを管理するための主要な手順です。

レプリケーションエラーをスキップします：

CALL mysql.rds_skip_repl_error;

レプリケーションを停止します：

CALL mysql.rds_stop_replication;

レプリケーションを開始します

CALL mysql.rds_start_replication;

RDSインスタンスをAWSの外部で実行されているMySQLインスタンスのリードレプリカとして設定します。

CALL mysql.rds_set_external_master;

MySQLインスタンスを再構成して、AWSの外部で実行されているMySQLインスタンスのリードレプリカではなくなります。

CALL mysql.rds_reset_external_master;

証明書をインポートします。これは、SSL通信と暗号化されたレプリケーションを有効にするために必要です。

CALL mysql.rds_import_binlog_ssl_material;

証明書を削除します。

CALL mysql.rds_remove_binlog_ssl_material;

レプリケーションマスターログの位置を、マスター上の次のバイナリログの先頭に変更します。

CALL mysql.rds_next_master_log;

ストアドプロシージャは多くのタスクを処理しますが、それは少し学習曲線です。 SUPER特権がないと、外部レプリケーション監視の使用で問題が発生する可能性もあります。

Amazon RDSは現在、以下をサポートしていません：

• グローバルトランザクションID
• 移動可能なテーブルスペース
• 認証プラグイン
• パスワード強度プラグイン
• レプリケーションフィルター
• 準同期レプリケーション

最後になりましたが、シェルへのアクセス。 Amazon RDSでは、Telnet、Secure Shell（SSH）、またはWindowsリモートデスクトップ接続（RDP）を介したDBインスタンスへの直接ホストアクセスは許可されていません。アプリケーションホスト上のクライアントを引き続き使用して、mysqlクライアントなどの標準ツールを介してDBに接続できます。

RDSのドキュメントに記載されているように、他にも制限があります。

EC2上のMySQLによる高可用性

（制御を維持しながら）展開および管理/保守タスクを自動化するために、ClusterControlを使用することができます。 RDSの場合と同様に、GUIを介してデータベースセットアップを数分で展開できるという便利さがあります。ノードの追加、バックアップのスケジュール設定、フェイルオーバーの実行などもGUIを介して便利に実行できます。MySQLをEC2で直接操作するオプションがあり、それによって高可用性オプションの制御を維持できます。このルートを進むときは、自由に使えるさまざまなAWS機能を活用する方法を理解することが重要です。 「DIYクラウドデータベース」ホワイトペーパーを必ず確認してください。

展開

ClusterControlは、マスタースレーブレプリケーションからマルチマスタークラスターまで、さまざまな高可用性データベースセットアップの展開を自動化できます。すべての主要なMySQLフレーバーがサポートされています-OracleMySQL、MariaDB、PerconaServer。 VPC /セキュリティグループの初期設定が必要です。これらについては、DIYクラウドデータベースのホワイトペーパーで詳しく説明されています。 AWS、Google Cloud、Azureのいずれであっても、同様の概念が適用されることに注意してください

Galera Clusterは、高可用性MySQLサービスをデプロイするときに検討するのに適した代替手段です。ドロップインの代替ではありませんが、従来のMySQLマスタースレーブアーキテクチャの信頼できる代替としての地位を確立しています。ほとんどのアプリケーションは、それでも実行できるように適合させることができます。複数のAWSリージョンにまたがるデータベースに異なるセグメントを定義することが可能です。

Galeraクラスター内の同期レプリケーションと、クラスターと1つ以上のスレーブ間の非同期レプリケーションを組み合わせることにより、「ハイブリッドレプリケーション」をセットアップできます。スレーブの遅延などのオプションにより、データの保護レベルが向上します。

プロキシレイヤー

高可用性を実現するには、高可用性セットアップを展開するだけでは不十分です。アプリケーションは、どのノードが機能していて、どのノードが機能していないかをどういうわけか知る必要があります。トポロジーの変更（例：マスターを別のホストに移動する場合も、アプリケーション層でのエラーを回避するために、何らかの方法で伝播する必要があります。 ClusterControlは、HAProxy、MaxScale、ProxySQLなどのプロキシの展開をサポートします。 HAProxyとProxySQLの場合、KeepalivedとVirtualIPを使用して冗長インスタンスをデプロイするための追加オプションがあります。

クロスリージョンレプリカ

Amazon RDSは、リードレプリカサービスを提供します。 AWSは世界中の多くのデータセンターにサービスを提供しているため、クロスリージョンレプリカを使用すると、読み取りをスケーリングできます。すべての読み取りレプリカにアクセスでき、最大5つのリージョンで読み取りに使用できます。これらのノードは独立しており、アップグレードパスで使用することも、スタンドアロンデータベースに昇格させることもできます。

それに加えて、AmazonはDRBD、同期ディスクレプリケーションに基づくマルチAZデプロイメントを提供しています。リードレプリカとの違いは何ですか？主な違いは、プライマリインスタンスのデータベースエンジンのみがアクティブであるため、他のアーキテクチャのバリエーションにつながることです。

リードレプリカとは対照的に、データベースエンジンのバージョンアップグレードはプライマリで行われます。もう1つの違いは、AWS RDSはDRBDで自動的にフェイルオーバーしますが、レプリカの読み取り（非同期レプリケーションを使用）には手動操作が必要になることです。

RDSでのマルチAZフェイルオーバーは、DNS変更を使用してスタンバイインスタンスをポイントします。Amazonによると、これはフェイルオーバー中の60〜120秒以内に発生するはずです。スタンバイはプライマリと同じストレージデータを使用するため、トランザクション/ログの回復が行われる可能性があります。データベースが大きくなると、InnoDBのリカバリにかなりの時間がかかる可能性があるため、DR計画とRTOの計算でそれを考慮してください。

もちろん、これには追加費用がかかります。基本的な例を見てみましょう。 2vCPU、4GB RAMを備えたdb.t2.mediumホストのコストは、月額185.98米ドルです。マルチゾーン（MZ）レプリカを370.98 UDBに有効にすると、価格は2倍になります。価格は地域によって異なりますが、MZでは2倍になります。

EC2で同じことを実現するために、仮想マシンをさまざまなリージョンにデプロイできます。各AWSリージョンは完全に独立しています。 AWSリージョンの設定は、コンソールでEC2_REGION環境変数を設定することで変更できます。または、AWSコマンドラインインターフェイスで--regionパラメーターを使用してオーバーライドすることもできます。サーバーのセットの準備ができたら、ClusterControlを使用してレプリケーションをデプロイおよび監視できます。標準のコマンドを使用して、コンソールから手動でレプリケーションを設定することもできます。

クロステクノロジーレプリケーション

Amazon RDSMySQLまたはMariaDBDBインスタンスと、AmazonRDSの外部にあるMySQLまたはMariaDBインスタンスとの間でレプリケーションをセットアップすることができます。これは、バイナリログを介してmysqlの標準レプリケーション方法を使用して行われます。バイナリログを有効にするには、my.cnf構成を変更する必要があります。シェルにアクセスできないと、このタスクはRDSでは不可能になりました。それはそれほど明白ではない方法で行われます。 2つのオプションがあります。 1つは、バックアップを有効にすることです。AmazonRDS DBインスタンスで、保持を0より大きい自動バックアップを設定します。または、ビルド済みのスレーブサーバーへのレプリケーションを有効にします。どちらのタスクでも、後でレプリケーションに使用できるバイナリログが有効になります。

レプリカに適用されていることを確認するまで、マスターインスタンスでbinlogを維持します。このメンテナンスにより、障害が発生した場合にマスターインスタンスを復元できるようになります。

もう1つの障害は、権限です。 Amazon RDS DBインスタンスでレプリケーションを開始するために必要なアクセス許可は制限されており、AmazonRDSマスターユーザーは利用できません。このため、Amazon RDS mysql.rds_set_external_masterコマンドとmysql.rds_start_replicationコマンドを使用して、ライブデータベースとAmazonRDSデータベース間のレプリケーションを設定する必要があります。

レプリカであるAmazonRDSインスタンスのフェイルオーバーイベントを監視します。フェイルオーバーが発生した場合、レプリカであるDBインスタンスが、異なるネットワークアドレスを持つ新しいホストに再作成される可能性があります。フェールオーバーイベントを監視する方法については、「AmazonRDSイベント通知の使用」を参照してください。

以下の例では、RDSからEC2インスタンスにある外部DBへのレプリケーションを有効にする方法を示します。
バイナリログを有効にする必要があります。ここではRDSスレーブを使用します。

バイナリログを保持する時間数を指定します。

mysql -h RDS_MASTER -u<username> -u<password>
call mysql.rds_set_configuration('binlog retention hours', 7);

RDS MASTERで、次のコマンドを使用してレプリケーションユーザーを作成します。

CREATE USER 'repl'@'ec2DBslave' IDENTIFIED BY 's3cr3tp4SSw0rd';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'ec2DBslave';

RDS SLAVEで、次のコマンドを実行します。

mysql -u<username> -u<password> -h RDS_SLAVE
call mysql.rds_stop_replication;
SHOW SLAVE STATUS;  Exec_Master_Log_Pos, Relay_Master_Log_File.

RDS SLAVEで、次の形式でmysqldumpを実行します。

mysqldump -u<username> -u<password> -h RDS_SLAVE --routines --triggers --single-transaction --databases DB1 DB2 DB3 > mysqldump.sql

DBダンプを外部データベースにインポートします：

mysql -u<username> -u<password> -h ec2DBslave
tee import_database.log;
source mysqldump.sql;

CHANGE MASTER TO 
 MASTER_HOST='RDS_MASTER', 
 MASTER_USER='repl',
 MASTER_PASSWORD='s3cr3tp4SSw0rd',
 MASTER_LOG_FILE='<Relay_Master_Log_File>',
 MASTER_LOG_POS=<Exec_Master_Log_Pos>;

RDSでのみAWSによって作成されたテーブルを無視するレプリケーションフィルターを作成します

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('mysql.rds\_%');

レプリケーションを開始します

START SLAVE;

レプリケーションステータスを確認する

SHOW SLAVE STATUS;

今のところ以上です。 AWSでのMySQLの管理は大きなトピックです。下のコメントセクションであなたの考えを教えてください。