Joomla 駆動型の新しい Web サイトがあり、Mysql データベースに依存する多くのカスタム アプリが含まれています。これはすべて Amazon EC2 でホストされ、ルート デバイスは EBS です。
私の懸念はMysqlのセットアップにあります。ほとんどのデフォルト設定で mysql-server をインストールしました (セキュリティのクリーンアップ以外)。
私の質問は、別の EBS ボリュームで実行するように Mysql をセットアップする必要があるかどうかです: http://aws.amazon.com/articles/1663または Amazon RDS: http://aws.amazon.com /rds/mysql/ ?
これらは両方とも、ユーザーが 0 人の現在の私のスタートアップにとってはやり過ぎのようです。これが成長した場合に備えて積極的に対応したいのは明らかですが、後でこれらを追加するのが大きな苦痛になるかどうかはわかりませんか?
多くの理由から、MySQL を別の EBS ボリュームで実行するようにセットアップする必要があります。ここにいくつかあります：
より簡単なバックアップ。MySQL ダンプを実行して S3 にプッシュするのではなく、EBS ボリューム全体のスナップショットを作成できます。ボリュームのスナップショットがある場合、MySQL ダンプを使用するよりもはるかに迅速にデータベースを復元できます。
ディスク競合。すべてを同じディスクで実行すると、ディスクの競合が発生します。特に MySQL のレプリケーションを行おうとしている場合。MySQL ログ用に 1 つ、データ用に 1 つ、その他すべて用に 1 つのボリュームがあります。
EBS ボリュームは比較的安価です。
必要に応じて、ボリューム全体を別のインスタンスに移動できます。
全体として、それははるかに良い選択です。必要に応じて、より多くの理由を提供できます。
しばらくは EBS ボリュームを使いこなしてから、シャード化、NOSql 用のアプリケーションの書き換え、Amazon RDS への移行などを決定できると思います。しかし、私の意見では、何もなくなるまで MySQL を使用することです。
RDSが利用可能になる前に、MySQLをEBSの記事に書きました。
RDSから始めることをお勧めします。セットアップは簡単で、多くの心配事に対応でき、楽しいです。
将来的にRDSの制限に達した場合にのみ、独自のMySQLの管理に切り替えてください（それほど可能性は高くありません）。その場合は、私の記事のベストプラクティスに従い、別のEBSボリュームを使用してください。
RDS を使用しない場合は、複数の EBS ボリュームをソフトウェア RAID 構成にストライピングすることを検討する必要があります。
そうしないと、適度にビジーな MySQL インスタンスに対して EBS IO パフォーマンスが低すぎることに気付くかもしれません。
その方法の詳細については、