2つの基本的な違いがいくつかあることに気づきました。
EC2の方が安くなる
RDS メンテナンスを行う必要がない
これら 2 つ以外に、MySQL サーバーとして機能する別の EC2 サーバーとは対照的に、RDS からデータベースを実行する利点はありますか。インスタンスのサイズが類似していると仮定すると、負荷を処理できるという点で、両方とも同じ制限に直面しますか?
私の使用法についてもう少し情報を提供するために、私はデータベースを持っています。大きすぎたり何か (最大のテーブルは 100 万行) ではなく、SELECT ボリュームが高いだけです。
これは非常に複雑な答えを持つ単純な質問です！
つまり、RAID0 EBSを使用する場合、EC2は最大のパフォーマンスを提供します。RAID0 EBSを実行するには、次のようにかなりの量のメンテナンスオーバーヘッドが必要です。
http://alestic.com/2009/06/ec2-ebs-raid
http://alestic.com/2009/09/ec2-consistent-snapshot
RAID0 EBSのないEC2は、ひどいI / Oパフォーマンスを提供するため、実際にはオプションではありません。
RDSは、箱から出してすぐに非常に優れた（最大ではありませんが）パフォーマンスを提供します。管理コンソールは素晴らしく、インスタンスのアップグレードは簡単です。高可用性と読み取り専用のスレーブはクリックするだけです。それは本当に素晴らしいです。
簡単な答え：RDSを使用してください。まだフェンスにいますか？RDSで行く!!! 頭痛の種を楽しんだり、パフォーマンスを最大化するために最後まで少しずつ調整したりする場合は、EC2 + EBSRAID0を検討できます。VanillaEC2はMySQLホスティングにとってひどいオプションです。
この投稿には、次の優れたベンチマークがあります。
ベンチマークは、理想的な条件 (1 つのスレッドのみ) だけでなく、50 のスレッドがデータベースにヒットするというより現実的なシナリオにも焦点を当てているため、非常に優れています。
RDS は実際には高可用性システムではありません。RDS faq の詳細をお読みください。フェールオーバー イベント中は、フェールオーバーに最大 3 分かかる場合があります。追加の Amazon は、rds インスタンスを「アップグレード」する必要があると判断し、その時点でフェイルオーバーを実行します。これにより、データベースが「最大 3 分間」ダウンします (私たちの経験では、それよりも長くかかる場合があります)。
RDS の高可用性は、マスター - マスターまたはマスター - スレーブのレプリケーションとは大きく異なり、はるかに低速です。彼らは mysql レプリケーションを使用しませんが、ある種の ebs レプリケーションを使用します。したがって、フェイルオーバーの状況では、ebs をバックアップ マシンにマウントし、mysql を起動し、mysql が障害回復を行うのを待ち (うまくいけば、何も壊れていないことを願っています)、dns スイッチを実行します。
評価の参考になれば幸いです。
読み取り量が多く、マスター/スレーブ レプリケーションが必要なため、EC2 MySQL インスタンスを使用することにしました。もちろん、複数の RDS インスタンスをスピンアップし、それらの間で MySQL レプリケーションをセットアップすることもできますが、EC2 インスタンスを使用してそれを管理する Scalr.net を使用します。
基本的に、必要な MySQL インスタンスの数を Scalr に伝え、それらを維持し、レプリケーションのセットアップを自動化し、マスターが終了した場合にマスターへのスレーブ昇格の自動フェイルオーバーを処理します。SQL ダンプ バックアップと EBS ボリューム スナップショットの両方を行います。マスター。そのため、新しいスレーブを作成する必要がある場合、最後のマスター スナップショットの EBS ボリュームを自動的に一時的にマウントしてスレーブ DB を初期化し、適切なポイントからレプリケーションを開始します。すべてのポイントアンドクリック:)（いいえ、私はScalrなどで働いていません。Scalrのサービスを使用したくない場合は、オープンソースとして利用できます）
メンテナンスウィンドウの質問について。マルチ AZ を使用する場合、RDS は別のアベイラビリティ ゾーンにスタンバイ レプリカを作成するため、メンテナンスのためのダウンタイムがなく、ゾーンの障害から身を守ることができます。
それが私が来週かそこらで行うことを計画していることです. もちろん、それにはもっと費用がかかりますが、私はまだそれを少し解決していません.
RDS を数か月試してみましたが、いくつかの問題があります。
SQL プロファイラーの使用は注意が必要です。プロファイラーをサーバーに直接接続することはできないため、いくつかのストアド プロシージャを実行して、分析可能なログ ファイルを作成する必要があります。彼らはそれがどのように行われるかについていくつかの提案を提供していますが、それはユーザーフレンドリーとはほど遠いものです. この種の作業は、認定された SQL 専門家に依頼することのみをお勧めします。
Amazon がインスタンスをバックアップしますが、個々のデータベースを復元することはできません。私はいくつかの個別の顧客固有のデータベースを備えた Web アプリを持っています。私の解決策は、SQL を実行している EC2 インスタンスを起動して、本番 RDB データベースにアタッチし、データをインポートしてから EC2 インスタンスにバックアップすることでした。もう 1 つの解決策は、スキーマを再作成し、データを復元ポイントに戻す大規模な SQL スクリプトを (アプリ サーバー上に) 作成するサード パーティ ツールを使用することでした。
EC2 上の MySQL と RDS MySQL の比較
EC2 での MySQL の利点 Amazon EC2 リージョン間レプリケーション
Amazon EC2 リージョン間でスナップショットをコピーする
MySQL EC2 での EBS ストライピングによる RAID 0
EC2 上の MySQL には、3 TB を超えるディスク容量 (サイズによっては必要ありません) を接続できます。
EC2 での MySQL の欠点
RDS と比較した構成、監視、およびメンテナンス
RDS で利用可能なポイント イン タイム バックアップ
IOPS は RDS MySQL よりも低く (RAID 0 の後でも)、現在、EC2 の MySQL では 6 ディスクで 10800 ですが、RDS MySQL では 12500 IOPS 16KB です。
今週末も同じ質問がありました。メンテナンスを行う RDS には、週に 4 時間のダウンタイム ウィンドウがあります。EC2 のマイクロ インスタンスを使用できる場合、RDS はより高価に見えました。(これは、トラフィックが最小のテスト インスタンスに当てはまります) また、権限がないため、RDS インスタンスのタイムゾーンを変更できませんでした。
私は現在、別の会社による EC2 上の mysqlであるhttp://xeround.com/を見ています。彼らは InnoDB を使用せず、代わりに IDG と呼ばれる独自のエンジンを使用しています。私はそれを調査し始めたばかりですが、ベータ版であり、500MB のスペースを提供します。