クラウド内のMySQL-AmazonRDSの長所と短所

データをパブリッククラウドサービスに移行することは大きな決断です。すべての主要なクラウドベンダーがクラウドデータベースサービスを提供しており、MySQL用のAmazonRDSがおそらく最も人気があります。

このブログでは、それが何であるか、どのように機能するかを詳しく見て、その長所と短所を比較します。

RDS（Relational Database Service）は、アマゾンウェブサービスのオファリングです。つまり、Amazonがデータベースをデプロイして運用するサービスとしてのデータベースです。データベースソフトウェアのバックアップやパッチ適用、高可用性などのタスクを処理します。いくつかのデータベースはRDSでサポートされていますが、ここでは主にMySQLに関心があります。AmazonはMySQLとMariaDBをサポートしています。 AmazonのMySQLのクローンであるAuroraもあり、特にレプリケーションと高可用性の分野で改善されています。

RDSを介したMySQLの導入

RDSを介したMySQLの展開を見てみましょう。 MySQLを選択した後、選択できるいくつかのデプロイメントパターンが表示されます。

主な選択は-高可用性を実現したいかどうかです。オーロラも宣伝されています。

次のダイアログボックスには、カスタマイズするためのいくつかのオプションがあります。多くのMySQLバージョンの1つを選択できます-いくつかの5.5、5.6、および5.7バージョンが利用可能です。データベースインスタンス-特定の地域で利用可能な一般的なインスタンスサイズから選択できます。

次のオプションは非常に重要な選択です。マルチAZデプロイメントを使用しますか？これはすべて高可用性に関するものです。マルチAZデプロイメントを使用しない場合は、単一のインスタンスがインストールされます。障害が発生した場合、新しいものがスピンアップされ、そのデータボリュームが再マウントされます。このプロセスには時間がかかり、その間データベースは使用できなくなります。もちろん、スレーブを使用してそのうちの1つを昇格させることで、この影響を最小限に抑えることができますが、これは自動化されたプロセスではありません。自動化された高可用性が必要な場合は、マルチAZデプロイメントを使用する必要があります。何が起こるかというと、2つのデータベースインスタンスが作成されます。 1つはあなたに見えます。別のアベイラビリティーゾーンにある2番目のインスタンスは、ユーザーには表示されません。これはシャドウコピーとして機能し、アクティブノードに障害が発生するとトラフィックを引き継ぐ準備ができています。トラフィックを障害が発生したインスタンスからシャドウインスタンスに切り替える必要があるため、これはまだ完全なソリューションではありません。私たちのテストでは、フェイルオーバーの実行に最大45秒かかりましたが、明らかに、インスタンスサイズ、I / Oパフォーマンスなどに依存する可能性があります。ただし、スレーブのみが関与する非自動フェイルオーバーよりもはるかに優れています。

最後に、ストレージ設定（タイプ、サイズ、PIOPS（該当する場合））とデータベース設定（識別子、ユーザー、パスワード）があります。

次のステップでは、さらにいくつかのオプションがユーザー入力を待っています。

インスタンスを作成する場所を選択できます：VPC、サブネット、パブリックに利用可能かどうか（RDSインスタンスにパブリックIPを割り当てる場合など）、アベイラビリティーゾーン、VPCセキュリティグループ。次に、データベースオプションがあります。最初に作成するスキーマ、ポート、パラメータ、オプショングループ、メタデータタグをスナップショットに含めるかどうか、暗号化設定です。

次に、バックアップオプション-バックアップをどのくらいの期間保持しますか？いつ服用してもらいたいですか？同様の設定はメンテナンスに関連しています-Amazon管理者がRDSインスタンスのメンテナンスを実行する必要がある場合があります-これは、ここで設定できる事前定義されたウィンドウ内で行われます。メンテナンス期間に少なくとも30分を選択しないオプションはないことに注意してください。そのため、本番環境でマルチAZインスタンスを使用することが非常に重要です。メンテナンスにより、ノードが再起動したり、しばらくの間可用性が失われたりする可能性があります。マルチAZがない場合は、そのダウンタイムを受け入れる必要があります。マルチAZ展開では、フェイルオーバーが発生します。

最後に、追加の監視に関連する設定があります。有効にするかどうかを指定しますか？

RDSの管理

この章では、MySQLRDSを管理する方法を詳しく見ていきます。利用可能なすべてのオプションについて説明するわけではありませんが、Amazonが利用できるようにした機能のいくつかを強調したいと思います。

スナップショット

MySQL RDSはストレージとしてEBSボリュームを使用するため、さまざまな目的でEBSスナップショットを使用できます。バックアップ、スレーブ-すべてスナップショットに基づいています。スナップショットは手動で作成することも、必要に応じて自動的に作成することもできます。 EBSスナップショットは一般的に（RDSインスタンスだけでなく）、I/O操作にいくらかのオーバーヘッドを追加することを覚えておくことが重要です。スナップショットを撮りたい場合は、I/Oパフォーマンスが低下することを期待してください。マルチAZ展開を使用しない限り、それはです。このような場合、「シャドウ」インスタンスはスナップショットのソースとして使用され、本番インスタンスへの影響は表示されません。

データベース管理に関するSevereninesDevOpsガイドオープンソースデータベースを自動化および管理するために知っておくべきことを学ぶ無料でダウンロード

バックアップ

バックアップはスナップショットに基づいています。上記のように、新しいインスタンスを作成するときにバックアップスケジュールと保持を定義できます。もちろん、後で「インスタンスの変更」オプションを使用して、これらの設定を編集できます。

いつでもスナップショットを復元できます。スナップショットセクションに移動し、復元するスナップショットを選択すると、新しいインスタンスを作成したときに表示されたものと同様のダイアログが表示されます。スナップショットは新しいインスタンスにしか復元できないため、これは驚くべきことではありません。既存のRDSインスタンスの1つにスナップショットを復元する方法はありません。意外かもしれませんが、クラウド環境でも、ハードウェア（および既存のインスタンス）を再利用することは理にかなっている場合があります。共有環境では、単一の仮想インスタンスのパフォーマンスが異なる場合があります。すでに使い慣れているパフォーマンスプロファイルに固執することをお勧めします。残念ながら、RDSでは不可能です。

RDSのもう1つのオプションは、ポイントインタイムリカバリです。これは非常に重要な機能であり、データを適切に管理する必要がある人にとっては必須の機能です。ここでは、物事はより複雑で明るくありません。手始めに、MySQLRDSがバイナリログをユーザーから隠すことを覚えておくことが重要です。いくつかの設定を変更して、作成されたbinlogを一覧表示できますが、それらに直接アクセスすることはできません。リカバリに使用するなどの操作を行うには、UIまたはCLIのみを使用できます。これにより、Amazonで許可されているオプションに制限され、5分間隔で計算される最新の「復元可能な時間」までバックアップを復元できます。したがって、データが9：33aに削除された場合、9：30aの状態までしか復元できません。ポイントインタイムリカバリは、スナップショットの復元と同じように機能します。つまり、新しいインスタンスが作成されます。

スケールアウト、レプリケーション

MySQL RDSでは、新しいスレーブを追加することでスケールアウトできます。スレーブが作成されると、マスターのスナップショットが取得され、新しいホストを作成するために使用されます。この部分はかなりうまく機能します。残念ながら、中間マスターを含むような、より複雑なレプリケーショントポロジを作成することはできません。マスターを作成することはできません-マスターセットアップ。これにより、HAはAmazon（およびマルチAZデプロイメント）の手に委ねられます。私たちが知る限り、GTIDを有効にする方法はありません（レプリケーションを制御できず、RDSにCHANGE MASTERがないため、GTIDの恩恵を受けることができるわけではありません）、通常の昔ながらのbinlog位置のみです。

GTIDがないと、マルチスレッドレプリケーションを使用できなくなります。RDSパラメーターグループを使用して多数のワーカーを設定することは可能ですが、GTIDがないとこれは使用できません。主な問題は、クラッシュが発生した場合に単一のバイナリログ位置を特定する方法がないことです。一部のワーカーは遅れている可能性があり、一部のワーカーはより高度である可能性があります。最新の適用済みイベントを使用すると、それらの「遅れている」ワーカーによってまだ適用されていないデータが失われます。最も古いイベントを使用する場合、より高度なワーカーによって適用されたイベントが原因で「キーの重複」エラーが発生する可能性があります。もちろん、この問題を解決する方法はありますが、それは簡単ではなく、時間がかかります。簡単に自動化できるものではありません。

MySQL RDSで作成されたユーザーにはSUPER特権がないため、スタンドアロンMySQLでは単純な操作はRDSでは簡単ではありません。 Amazonは、ストアドプロシージャを使用して、ユーザーがこれらの操作の一部を実行できるようにすることを決定しました。常にそうであるとは限りませんが、私たちが知ることができることから、いくつかの潜在的な問題がカバーされています。マスターの次のバイナリログにローテーションできなかったときのことを覚えています。マスターのクラッシュとbinlogの破損により、すべてのスレーブが破損する可能性があります。そのための手順があります： rds_next_master_log 。

スレーブは手動でマスターに昇格できます。これにより、マルチAZメカニズムの上にある種のHAを作成する（またはバイパスする）ことができますが、既存のスレーブを新しいマスターに再スレーブできないという事実によって無意味になりました。レプリケーションを制御することはできません。これにより、マスターがすべてのトラフィックに対応できない限り、演習全体が無駄になります。新しいマスターをプロモートした後は、負荷を処理するスレーブがないため、マスターにフェイルオーバーできません。 EBSスナップショットを最初に作成する必要があるため、新しいスレーブのスピンアップには時間がかかり、これには数時間かかる場合があります。次に、インフラストラクチャに負荷をかける前に、インフラストラクチャをウォームアップする必要があります。

スーパー特権の欠如

前に述べたように、RDSはユーザーにSUPER特権を付与しないため、MySQLでそれを使用することに慣れている人にとっては迷惑になります。当然のことながら、最初の数週間で、クエリの強制終了やパフォーマンススキーマの操作など、かなり頻繁に行うことを実行する必要がある頻度を学習します。 RDSでは、事前定義されたストアドプロシージャのリストに固執し、直接行うのではなくそれらを使用する必要があります。次のクエリを使用して、それらすべてを一覧表示できます。

SELECT specific_name FROM information_schema.routines;

レプリケーションと同様に、多くのタスクがカバーされていますが、まだカバーされていない状況に陥った場合は、運が悪いことになります。

相互運用性とハイブリッドクラウドのセットアップ

これは、RDSが柔軟性に欠けているもう1つの領域です。クラウドとオンプレミスの混合セットアップを構築したいとします。RDSインフラストラクチャがあり、オンプレミスにいくつかのスレーブを作成したいとします。直面する主な問題は、論理ダンプを取得する以外に、RDSからデータを移動する方法がないことです。 RDSデータのスナップショットを撮ることはできますが、それらにアクセスすることはできず、AWSからそれらを移動することはできません。また、xtrabackup、rsync、さらにはcpを使用するためのインスタンスへの物理的なアクセス権もありません。唯一のオプションは、mysqldump、mydumper、または同様のツールを使用することです。これにより、複雑さが増し（文字セットと照合設定が問題を引き起こす可能性があります）、時間がかかります（論理バックアップツールを使用してデータをダンプおよびロードするのに長い時間がかかります）。

RDSと外部インスタンス間のレプリケーションを設定することは可能ですが（どちらの方法でも、データをRDSに移行することも可能です）、非常に時間のかかるプロセスになる可能性があります。

一方、RDS環境内にとどまり、インフラストラクチャを大西洋全体または米国東海岸から西海岸にまたがる場合は、RDSを使用すると、新しいスレーブを作成するときに地域を簡単に選択できます。

残念ながら、マスターをある地域から別の地域に移動したい場合、単一のノードがすべてのトラフィックを処理できない限り、これはダウンタイムなしでは事実上不可能です。

セキュリティ

MySQL RDSはマネージドサービスですが、セキュリティに関連するすべての側面がAmazonのエンジニアによって処理されるわけではありません。アマゾンはそれを「共有責任モデル」と呼んでいます。つまり、Amazonは、ネットワークとストレージレイヤー（データが安全な方法で転送されるようにする）、オペレーティングシステム（パッチ、セキュリティ修正）のセキュリティを管理します。一方、ユーザーは残りのセキュリティモデルに注意を払う必要があります。 RDSインスタンスとの間のトラフィックがVPC内で制限されていることを確認し、データベースレベルの認証が正しく行われていることを確認し（パスワードなしのMySQLユーザーアカウントがないこと）、APIセキュリティが確保されていることを確認します（AMIが正しく設定され、必要最小限の権限で）。ユーザーは、ファイアウォール設定（セキュリティグループ）にも注意を払い、RDSとそれが含まれるVPCが外部ネットワークにさらされるのを最小限に抑える必要があります。そもそも暗号化されたRDSインスタンスを作成することにより、アプリケーションレベルまたはデータベースレベルのいずれかで、保存データの暗号化を実装することもユーザーの責任です。

データベースレベルの暗号化は、インスタンスの作成時にのみ有効にできます。既存の実行中のデータベースを暗号化することはできません。

RDSの制限

RDSを使用する予定がある場合、またはすでにRDSを使用している場合は、MySQLRDSに伴う制限に注意する必要があります。

SUPER特権の欠如 すでに述べたように、非常に煩わしい場合があります。ストアドプロシージャは多くの操作を処理しますが、別の方法で物事を行うことを学ぶ必要があるため、これは学習曲線です。 SUPER権限がないと、外部の監視ツールやトレンドツールを使用する際に問題が発生する可能性があります。機能の一部にこの権限が必要なツールがまだいくつかあります。

MySQLデータディレクトリとログに直接アクセスできないため、アクションの実行が困難になります それらを含みます。 DBAがバイナリログまたはテールエラー、低速クエリ、または一般ログを解析する必要がある場合があります。 RDSでこれらのログにアクセスすることは可能ですが、MySQLホストのシェルにログインして必要なことを行うよりも面倒です。それらをローカルにダウンロードするのにも時間がかかり、何をするにしても待ち時間が長くなります。

レプリケーショントポロジの制御の欠如、マルチAZ展開でのみ高可用性。 レプリケーションを制御できないため、データベースレイヤーに高可用性メカニズムを実装することはできません。複数のスレーブがあるかどうかは関係ありません。スレーブをマスターに昇格させても、残りのスレーブをこの新しいマスターから再スレーブする方法がないため、それらの一部をマスター候補として使用することはできません。これにより、ユーザーはマルチAZ展開を使用する必要があり、コストが増加します（「シャドウ」インスタンスは無料ではなく、ユーザーは料金を支払う必要があります）。

計画的なダウンタイムによる可用性の低下。 RDSインスタンスをデプロイする場合、RDSインスタンスでメンテナンス操作を実行できる30分の週単位の時間枠を選択する必要があります。一方では、RDSはサービスとしてのデータベースであるため、これは理解できます。そのため、RDSインスタンスのハードウェアとソフトウェアのアップグレードはAWSエンジニアによって管理されます。一方、これにより、メンテナンス期間中にマスターデータベースがダウンするのを防ぐことができないため、可用性が低下します。この場合も、マルチAZセットアップを使用すると、最初にシャドウインスタンスで変更が発生し、次にフェイルオーバーが実行されるため、可用性が向上します。ただし、フェイルオーバー自体は透過的ではないため、いずれにせよ、稼働時間が失われます。これにより、予期しないMySQLマスターの障害を念頭に置いてアプリを設計する必要があります。これは悪いデザインパターンではありません。データベースはいつでもクラッシュする可能性があるため、アプリケーションは、最も悲惨なシナリオにも耐えられる方法で構築する必要があります。 RDSでは、高可用性の選択肢が限られているだけです。

高可用性実装のオプションを減らしました。 レプリケーショントポロジ管理に柔軟性がないことを考えると、実行可能な高可用性の方法はマルチAZ展開のみです。この方法は優れていますが、ダウンタイムをさらに最小限に抑えるMySQLレプリケーション用のツールがあります。たとえば、MHAまたはClusterControlをProxySQLと組み合わせて使用すると、（長時間実行されるトランザクションがないなどの条件下で）アプリケーションに透過的なフェイルオーバープロセスを提供できます。 RDSを使用している間は、この方法を使用できません。

データベースのパフォーマンスに関する洞察が減少しました。 MySQL自体からメトリックを取得することはできますが、状況を10kフィート完全に把握するには不十分な場合があります。ある時点で、ユーザーの大多数は、ハードウェアまたはインフラストラクチャの障害によって引き起こされる本当に奇妙な問題に対処する必要があります。ネットワークパケットの損失、接続の突然の終了、または予期しない高いCPU使用率です。 MySQLホストにアクセスできる場合は、Linuxサーバーの状態を診断するのに役立つ多くのツールを活用できます。 RDSを使用する場合、AmazonのモニタリングおよびトレンドツールであるCloudwatchで利用できるメトリクスに制限されます。より詳細な診断を行うには、サポートに連絡して、問題を確認して修正するように依頼する必要があります。これは迅速かもしれませんが、メール通信のやりとりが多く、非常に長いプロセスになる可能性もあります。

MySQLRDSからデータを取得する複雑で時間のかかるプロセスによって引き起こされるベンダーロックイン。 RDSはMySQLデータディレクトリへのアクセスを許可しないため、xtrabackupなどの業界標準ツールを利用してデータをバイナリ方式で移動する方法はありません。一方、内部のRDSはAmazonが管理しているMySQLであり、アップストリームと100％互換性があるかどうかを判断するのは困難です。 RDSはAWSでのみ利用できるため、ハイブリッドセットアップを行うことはできません。

概要

MySQLRDSには長所と短所の両方があります。これは、データベースの操作について心配することなく、アプリケーションに集中したい人にとって非常に優れたツールです。データベースをデプロイし、クエリの発行を開始します。バックアップスクリプトを作成したり、モニタリングソリューションを設定したりする必要はありません。これは、AWSエンジニアによってすでに行われているため、必要なのはそれを使用することだけです。

MySQLRDSのダークサイドもあります。スレーブを追加するだけでなく、より複雑なセットアップとスケーリングを構築するためのオプションの欠如。マルチAZ展開で提案されているものよりも優れた高可用性のサポートが不足しています。 MySQLログへの面倒なアクセス。 MySQLデータディレクトリへの直接アクセスの欠如と物理バックアップのサポートの欠如。これにより、RDSインスタンスからデータを移動することが困難になります。

要約すると、データベースの詳細な制御よりも使いやすさを重視する場合、RDSは問題なく機能する可能性があります。将来のある時点で、MySQLRDSを超える可能性があることに注意する必要があります。ここでは必ずしもパフォーマンスについてのみ話しているわけではありません。それは、より複雑なレプリケーショントポロジに対する組織のニーズ、または時々発生するさまざまな問題に迅速に対処するためのデータベース操作に対するより良い洞察を持っている必要性に関するものです。その場合、データセットのサイズがすでに大きくなっていると、RDSから移動するのが難しい場合があります。データをRDSに移動することを決定する前に、情報管理者は特定の領域における組織の要件と制約を考慮する必要があります。

次のいくつかのブログ投稿では、RDSから別の場所にデータを取り出す方法を紹介します。 EC2への移行とオンプレミスインフラストラクチャへの移行の両方について説明します。