MySQL Galeraクラスター（Percona、MariaDB、またはCodershipビルドのいずれか）の実行は、残念ながら、Amazon RDSでサポートされている（またはその一部である）データベースではありません。 RDSでサポートされているデータベースのほとんどは非同期レプリケーションを使用していますが、GaleraClusterは同期マルチマスターレプリケーションソリューションです。 Galeraは、正しく機能するためにストレージエンジンとしてInnoDBも必要とします。また、MyISAMなどの他のストレージエンジンを使用することもできますが、トランザクション処理が不足しているため、このストレージエンジンを使用することはお勧めしません。
RDSにはネイティブのサポートがないため、このブログでは、AWS環境を使用してGaleraベースのクラスターを選択してホストするときに利用できるサービスに焦点を当てます。
AWSクラウドプラットフォームを選択する理由と選択しない理由は確かにたくさんありますが、この特定のトピックでは、理由ではなく、活用できるものの利点と利点について説明します。 AWSプラットフォームを選択します。
仮想サーバー（Elastic Compute Instances）
前述のように、MySQL GaleraはRDSの一部ではなく、InnoDBは、アプリケーション要件に適したリソースを必要とするトランザクションストレージエンジンです。クライアント要求トラフィックの需要に対応する能力が必要です。この記事の時点で、Galera Clusterを実行するための唯一の選択は、AmazonのコンピューティングインスタンスクラウドオファリングであるEC2を使用することです。
EC2インスタンスの複数のノードでシステムを実行できるという利点があるため、EC2とオンプレミスでGaleraClusterを実行してもそれほど違いはありません。 SSH経由でサーバーにリモートアクセスし、目的のソフトウェアパッケージをインストールして、使用するGaleraClusterビルドの種類を選択できます。
さらに、EC2を使用すると、このオファリングはより弾力的で柔軟性があり、よりシンプルできめ細かいセットアップを提供および提供できます。環境をスケールアウトする必要がある場合は、Webサービスを利用して多数のノードを自動化または構築できます。たとえば、ステージング環境または開発環境の構築を自動化できます。また、目的の環境をすばやく構築し、目的のOSを選択してセットアップし、要件に合った適切なコンピューティングリソース（CPU、メモリ、ディスクストレージなど）を取得するためのエッジを提供します。EC2により、ハードウェアを待つ時間がなくなります。 、その場でこれを行うことができるので。 AWSCLIツールを活用してGaleraクラスターのセットアップを自動化することもできます。
EC2は、AWSコンピューティングノードでGaleraCluster環境をホストしたい消費者向けに非常に柔軟な選択肢を多数提供しています。 AWS Free Tierには、1年間、毎月750時間のLinuxおよびWindowst2.microインスタンスが含まれています。 EC2 Microインスタンスのみを使用することで無料利用枠内にとどまることができますが、これは本番環境での使用に最適ではない場合があります。
GaleraノードをプロビジョニングするときにデプロイできるEC2インスタンスには複数のタイプがあります。理想的には、これらのr4 / r5 / x1ファミリ（メモリ最適化）とc4 / c5ファミリ（計算最適化）が理想的な選択肢であり、これらの価格は、サーバーリソースのニーズの大きさとOSの種類によって異なります。
計算能力（1時間あたりまたは1秒あたり）で支払う。実行するインスタンスのタイプによって異なります。たとえば、インスタンスのタイプを除いて、UbuntuインスタンスとRHELインスタンスをプロビジョニングする場合、価格が異なる場合があります。長期的なコミットメントや前払いは必要ありません。また、計算能力を増減する柔軟性もあります。これらのインスタンスは、中断できない短期的、スパイク状、または予測不可能なワークロードを持つアプリケーションや、Amazon EC2で初めて開発またはテストされるアプリケーションなど、低コストで柔軟な環境のニーズに推奨されます。詳細については、こちらをご覧ください。
使用する専用ハードウェア上で実行される専用サーバーを取得する必要があるなど、コンプライアンスおよび規制要件を探している場合、このタイプのオファーはニーズに適しています。専用ホストは、Windows Server、SQL Server、SUSE Linux Enterprise Server、Red Hat Enterprise Linux、またはVMにバインドされているその他のソフトウェアライセンスを含む、既存のサーバーにバインドされたソフトウェアライセンスを使用できるようにすることで、コンプライアンス要件に対応し、コストを削減するのに役立ちます。 、ソケット、または物理コア。ライセンス条項が適用されます。オンデマンド（1時間ごと）またはオンデマンド価格の最大70％オフの予約として購入できます。詳細については、こちらをご覧ください。
これらのインスタンスを使用すると、オンデマンド価格の最大90％オフで予備のAmazonEC2コンピューティング容量をリクエストできます。これは、開始時間と終了時間が柔軟なアプリケーション、非常に低いコンピューティング価格でのみ実行可能なアプリケーション、または大量の追加容量を緊急に必要とするユーザーに推奨されます。詳細については、こちらをご覧ください。
このタイプの支払いオファーでは、最大75％の割引を受けることができます。また、予約するインスタンスに応じて、容量の予約を取得して、能力にさらに自信を持たせることができます。必要なときにインスタンスを起動します。これは、アプリケーションの使用状況が定常状態または予測可能である場合、予約済みの容量が必要なアプリケーション、または1年または3年の期間にわたってEC2を使用して合計コンピューティングコストを削減できるお客様に推奨されます。詳細については、こちらをご覧ください。
EC2の最後の1つは、1秒あたりの請求も提供することです。これには、請求から1時間の未使用の分と秒のコストもかかります。これは、Galeraノードからのトラフィック要求を処理するためだけに、または特定のノードで限られた時間だけ使用してテストする場合に、最小限の時間でスケールアウトする場合に有利です。
AWSでのデータベース暗号化
データの機密性が懸念される場合、またはセキュリティコンプライアンスと規制に必要な法律を順守する場合、AWSは保存データの暗号化を提供します。 MariaDBクラスターバージョン10.2+を使用している場合、Amazon Web Services（AWS）キー管理サービス（KMS）APIとインターフェイスするためのプラグインサポートが組み込まれています。これにより、AWS-KMSキー管理サービスを利用して、責任の分離と、キーアクセスリクエストのリモートロギングと監査を容易にすることができます。このプラグインは、暗号化キーをローカルファイルに保存するのではなく、マスターキーをAWSKMSに保持します。
MariaDBを最初に起動すると、AWSKMSプラグインはAWSKey Management Serviceに接続し、新しいキーを生成するように要求します。 MariaDBは、そのキーを暗号化された形式でディスクに保存します。ディスクに保存されているキーを使用してデータを復号化することはできません。むしろ、起動するたびに、MariaDBはAWS KMSに接続し、サービスにローカルに保存されたキーを復号化します。復号化されたキーは、MariaDBサーバープロセスが実行されている限りメモリ内に保存され、そのメモリ内の復号化されたキーはローカルデータの暗号化に使用されます。
または、EC2インスタンスをデプロイするときに、データストレージボリュームをEBS（Elastic Block Storage）で暗号化するか、インスタンス自体を暗号化することができます。 EBSタイプのボリュームの暗号化はすべてサポートされていますが、影響はあるかもしれませんが、遅延はごくわずかであるか、エンドユーザーには見えません。 EC2インスタンスタイプの暗号化では、ほとんどのラージインスタンスがサポートされています。したがって、コンピューティングノードまたはメモリ最適化ノードを使用している場合は、その暗号化を活用できます。
- 汎用：A1、M3、M4、M5、M5a、M5ad、M5d、T2、T3、およびT3a
- 計算の最適化：C3、C4、C5、C5d、およびC5n
- 最適化されたメモリ：cr1.8xlarge、R3、R4、R5、R5a、R5ad、R5d、u-6tb1.metal、u-9tb1.metal、u-12tb1.metal、X1、X1e、およびz1d
- ストレージの最適化：D2、h1.2xlarge、h1.4xlarge、I2、およびI3
- 高速コンピューティング：F1、G2、G3、P2、およびP3
EC2タイプのインスタンスのデプロイ時に常に暗号化を有効にするように、AWSアカウントを設定できます。これは、AWSが起動時に新しいEBSボリュームを暗号化し、暗号化されていないスナップショットの新しいコピーを暗号化することを意味します。
残念ながら、この記事の執筆時点では、GaleraノードクラスターのMulti-AZ / -Region / -CloudデプロイをサポートするAWSコンソール（またはそのAWS API）にはそのような直接サポートはありません。
高可用性、スケーラビリティ、および冗長性
マルチAZデプロイメントを実現するには、ガレラノードをさまざまなアベイラビリティーゾーンにプロビジョニングすることをお勧めします。これにより、クォーラムの不足によるクラスターのダウンやクラスターの誤動作を防ぐことができます。
AWS Auto Scalingをセットアップし、自動スケーリンググループを作成してステータスチェックを監視および実行することもできるため、クラスターは常に冗長性、スケーラブル、および高可用性を備えています。 Auto Scalingは、不明な理由でノードがダウンした場合の問題を解決するはずです。
マルチリージョンまたはマルチクラウド展開の場合、Galeraにはgmcast.segmentと呼ばれる独自のパラメーターがあり、サーバーの起動時にこれを設定できます。このパラメータは、Galeraノード間の通信を最適化し、ライトセットリレーやISTおよびSSTドナーの選択などのネットワークセグメント間で送信されるトラフィックの量を最小限に抑えるように設計されています。
このタイプのセットアップでは、Galeraクラスターの異なるリージョンに複数のノードをデプロイできます。それとは別に、Galeraノードを別のベンダーにデプロイすることもできます。たとえば、GaleraノードがGoogle Cloudでホストされていて、MicrosoftAzureで冗長性が必要な場合です。
これらのタイプの実装方法の詳細については、ブログ「MySQLまたはMariaDB用のGaleraクラスターを使用した複数のデータセンターのセットアップとMySQLを使用したゼロダウンタイムネットワークの移行」を確認することをお勧めします。展開の。
AWSでのデータベースパフォーマンス
アプリケーションの要求に応じて、メモリを消費するクエリのメモリが最適化されたインスタンスを選択するのが理想的です。アプリケーションに、Webサーバーまたはバッチ処理に高いパフォーマンスを必要とするより高いトランザクションがある場合は、コンピューティング最適化インスタンスを選択します。 Galera Clusterの最適化について詳しく知りたい場合は、このブログ「MySQLまたはMariaDB用のGaleraClusterのパフォーマンスを向上させる方法」を確認してください。
AWSでのデータベースバックアップ
AWSには、MySQL Galeraテクノロジーに固有の直接サポートがないため、バックアップの作成が難しい場合があります。ただし、AWSは、EBSスナップショットを使用したディザスタおよびリカバリソリューションを提供します。インスタンスに接続されているEBSボリュームのスナップショットを作成してから、CloudWatchを使用してスケジュールごとにバックアップを作成するか、Amazon Data Lifecycle Manager（Amazon DLM）を使用してスナップショットを自動化できます。
取得されたスナップショットは増分バックアップであることに注意してください。つまり、最新のスナップショットの後に変更されたデバイス上のブロックのみが保存されます。これらのスナップショットをAWSS3に保存して、ストレージコストを節約できます。または、Percona XtrabackupやMydumper（論理バックアップ用）などの外部ツールを使用して、これらをAWS EFS-> AWS S3->AWSGlacierに保存することもできます。
バックアップデータをより費用効果の高い方法で保存する必要がある場合は、AWSでライフサイクル管理を設定することもできます。大きなファイルがあり、AWS EFSを利用する場合は、AWSバックアップソリューションを活用できます。これもシンプルでありながら費用対効果の高いソリューションです。
一方、監視ソリューションとバックアップソリューションの両方を提供する外部サービス（ClusterControlなど）を使用することもできます。詳細を知りたい場合は、こちらをご覧ください。
AWSでのデータベースモニタリング
AWSは、Galeraノードを可視化するためのヘルスチェックといくつかのステータスチェックを提供しています。これは、CloudWatchとCloudTrailを介して行われます。
CloudTrailを使用すると、ログを有効にして検査し、実行されたアクションとトレースに基づいて監査を実行できます。
CloudWatchを使用すると、メトリクスの収集と追跡、ログファイルの収集と監視、カスタムアラームの設定を行うことができます。カスタムニーズに応じてセットアップし、リソース使用率、アプリケーションパフォーマンス、および運用状態に関するシステム全体の可視性を得ることができます。 CloudWatchには、制限内に収まっている限り、無料利用枠が付属しています（下のスクリーンショットを参照してください）。
CloudWatchには、配布されるメトリクスの量に応じた価格もあります。こちらをチェックして、現在の価格を確認してください。
注意：CloudWatchを使用することには欠点があります。特にMySQLGaleraクラスターノードを監視するために、データベースの状態に対応するようには設計されていません。または、レポートに役立ち、問題のあるノードを診断するときに分析しやすい高解像度のグラフまたはチャートを提供する外部ツールを使用することもできます。
これには、Percona、DataDog、Idera、VividCortex、または独自のClusterControlによるPMMを使用できます（ClusterControl Communityでは監視が無料であるため）。個々のアプリケーション要件に基づくニーズ。監視ツールが積極的に通知したり、Slack、PagerDutyなどのインスタントメッセージングシステムの統合を提供したり、深刻な健康状態を悪化させたときにSMSを送信したりできることが非常に重要です。
AWSのデータベースセキュリティ
EC2インスタンスの保護は、データベースをパブリッククラウドにデプロイする上で最も重要な部分の1つです。プライベートサブネットを設定し、設定に応じてポートまたは送信元IPを許可するためにのみ優先される必要なセキュリティグループを設定できます。ノードがソフトウェアパッケージにアクセスまたは更新するためにインターネットにアクセスする必要がある場合は、データベースノードを非リモートアクセスで設定し、ジャンプホストまたはインターネットゲートウェイを設定するだけです。これを設定する方法については、以前のブログ「AWSおよびVPNを使用したGCPでのセキュアマルチクラウドMySQLレプリケーションのデプロイ」をご覧ください。
これに加えて、TLS / SSL接続を使用して転送中のデータを保護したり、データが保存されているときにデータを暗号化したりできます。 ClusterControlを使用している場合、転送中の安全なデータのデプロイはシンプルで簡単です。試してみたい場合は、ブログSSL Key Management and Encryption of MySQL DatainTransitをチェックしてください。保存データの場合、S3を介したデータの保存は、AWSサーバーサイド暗号化を使用して暗号化するか、前述のAWS-KMSを使用して暗号化できます。 AWS-KMSを使用してMariaDBクラスターをセットアップして活用する方法については、この外部ブログを確認してください。これにより、データを安全に保管しておくことができます。
AWSでのGaleraクラスターのトラブルシューティング
AWS CloudWatchは、特にシステムメトリクスを調査およびチェックアウトする場合に役立ちます。ネットワーク、CPU、メモリ、ディスク、およびそのインスタンスを確認したり、使用量とバランスを計算したりできます。ただし、これは特定のケースを掘り下げるときに要件を満たさない場合があります。
CloudTrailは、特定のAWSアカウントに基づいて管理されているアクションの確実なトレースを実行できます。これは、発生がMySQL Galeraからのものではないかどうかを判断するのに役立ちますが、AWS環境内のバグまたは問題である可能性があります（たとえば、ゲストとしてのインスタンスが存在するホストマシン内でHyper-Vに問題が発生しているなど）ホストされています。）
ClusterControlを使用している場合は、[ログ]-> [システムログ]に移動すると、MySQLGaleraノード自体から取得したキャプチャされたエラーログを参照できます。これとは別に、ClusterControlは、緊急時やMySQLGaleraノードが故障した場合にアラームと通知システムを増幅するリアルタイムの監視を提供します。
MySQLと互換性のあるAWSRDSとは異なり、AWSはMySQLGaleraClusterセットアップを完全にサポートしていません。このため、AWS環境内で本番環境で使用するためにGalera Clusterを実行するための推奨事項や意見のほとんどは、非常に長い間実行されてきた経験豊富で十分にテストされた環境に基づいています。
MariaDBクラスターは、AWSテクノロジースタックソリューションを常に簡潔にサポートしているため、生産性が高くなっています。 MariaDB 10.5バージョンの次のリリースでは、S3ストレージエンジンのサポートを提供する予定です。これは待つ価値があるかもしれません。
外部ツールは、AWSクラウドで実行されているMySQL Galeraクラスターの管理と制御に役立ちます。そのため、AWSクラウドを実行または移行する必要がある理由について、ジレンマやFUDがある場合でも、大きな問題にはなりません。プラットフォーム。
AWSは、万能のソリューションではない場合もありますが、ニーズに合わせてカスタマイズおよび調整できるさまざまなソリューションを提供します。
ブログの次のパートでは、別のパブリッククラウドプラットフォーム、特にGoogle Cloudを見て、GaleraClusterをプラットフォームで実行することを選択した場合にどのように活用できるかを確認します。