私は初めてAWSの実験に1日を費やしました。EC2インスタンスを実行していて、MySQLデータベースを保持するためにElastic Block Store(EBS)をマウントしました。
WebアプリケーションファイルもEBSに配置するのは理にかなっていますか、それとも通常のEC2ファイルシステムにデプロイするだけでよいですか?
私は初めてAWSの実験に1日を費やしました。EC2インスタンスを実行していて、MySQLデータベースを保持するためにElastic Block Store(EBS)をマウントしました。
WebアプリケーションファイルもEBSに配置するのは理にかなっていますか、それとも通常のEC2ファイルシステムにデプロイするだけでよいですか?
Web アプリケーション ファイルと言うとき、正確に何を指しているのかわかりません。
デプロイされたコードを参照している場合、おそらく EBS を使用する意味はありません。前提条件を備えた AMI を作成し、その AMI のインスタンスを作成して最新のコードをデプロイするスクリプトを用意します。どこかで手動で変更しなければならない設定を忘れがちなので、このプロセスを自動化してテストすることを強くお勧めします。
実行中のアプリケーションによって変更されるデータ ファイルを格納している場合、EBS は理にかなっています。これがユーザーがアップロードした画像などのようなものである場合、S3 がはるかに単純なモデルを提供することがわかるでしょう。
EBS は、データベース、lucene インデックス、ファイル ベースの CMS、SVN リポジトリ、またはそれに類似したものに適しています。
EBS は永続的なストレージを提供するため、EC2 インスタンスに障害が発生した場合でもファイルは存在します。どうやらIOパフォーマンスが向上しているようですが、念のためにテストします。
ファイルが (DB のように) 頻繁に変更され、それらを S3 (または他の場所) に同期し続けたくない場合は、EBS が適しています。変更を頻繁に行わず、必要に応じてファイルを手動で (またはスクリプトで) 同期できる場合は、それらを S3 に保存します。シャットダウンする必要がある場合、または何らかの理由でインスタンスを失った場合は、新しいインスタンスを起動するときにそれらをプルダウンできます。これは、コストを気にすることも前提です。コストが問題にならない場合は、EBS を使用する方が簡単です。DB と Web ファイル用に個別の EBS を用意する予定があるかどうかはわかりませんが、EBS を 1 つだけ用意する予定で、Web ファイル用に十分な空きスペースがある場合は、EBS の方が複雑ではありません。 . パフォーマンスが気になる場合は、前述のように、特定のアプリをテストすることをお勧めします。
私たちのアプローチは、ソース管理からコードの最新かつ最高のバージョンをフェッチするスクリプトを AMI に事前にデプロイすることです。これにより、新しいインスタンスをすばやく起動したり、実行中のすべてのインスタンスを更新したりすることが非常に簡単になります (一度に 1 つずつ負荷分散ローテーションから取り出し、スクリプトを実行し、ローテーションに戻します)。
アップデート:
行間を読むと、別の EBS ボリュームをインスタンス ストアに基づくインスタンスにマウントしているように見えます。AWS は最近、古いインスタンスストアのものと比較して多くの利点を持つ EBS でサポートされたインスタンスを導入しました。ただし、必要に応じて別のサーバーに簡単にマウントできるように、MySQL データを別の EBS パーティションにマウントしています。
MySQL データ用に別の EBS ボリュームを持つ EBS でサポートされたインスタンスを強くお勧めします。