EBS（Elastic Block Store）とElasticBeanstalkを使用してAmazonEC2でMySQLを実行する

Question

Elastic Beanstalkは初めてですが、64ビットのAmazonLinuxを実行しているコンテナで環境を作成しましたPHP5.3。MySQLをEBSにセットアップしてから、phpMyAdminをインストールしてデータベースをインポートします。

ただし、ドキュメントが機能しないため、これを行う方法がわかりません： EBS（Elastic Block Store）を使用してAmazon EC2でMySQLを実行する

そのガイドは2010年3月23日に最後に更新されたので、古くなっている可能性があります。

これが私がしたことです：

EC2インスタンスをセットアップし、EBSボリュームを接続し、sshを介してインスタンスに接続し、コマンド「Sudosu-」を使用してルートアクセスを取得しました（これまでのところ良好です）。
ガイドによると、「Sudo apt-get update && Sudo apt-get upgrade -y」コマンドを実行する必要がありますが、apt-getコマンドが見つかりません。問題ありません。yumupdateとyumupgradeを実行しました。
同様に、「Sudo apt-get install -y xfsprogs mysql-server」が機能しなかったため、「Sudo yum install -y xfsprogs mysql-server」を実行して、MySQLをインストールしました。
ガイドには/ dev/sdhにXFSファイルシステムを作成するように書かれていますが、私のEBSボリュームは/ dev/sda1に接続されており（これはElastic Beanstalkを使用する場合のデフォルトであり、変更できません）、すでにファイルシステムがありますそれ（Elastic Beanstalkが自動的に作成すると思います）なので、「Sudo mkfs.xfs/dev/sdh」コマンドを実行できません（「Sudomkfs.xfs/dev/sda1」に変更しました。ボリュームが付属しています）。
ガイドの次の3つのコマンドは実行されているように見えたので（エラーメッセージなし）、EBSボリュームを/ ebsvolとしてマウントしました。ただし、/ ebsvolには/ ebsvol内のルートディレクトリ構造のコピーがあることに気付きました。ただし、/ ebsvol/ebsvolは空のディレクトリです。この時点で少し心配ですが、続けます。
ガイドのコマンド（Sudo /etc/init.d/mysql stop）が機能しなかったため、コマンド「/ sbin/servicemysqldstop」を使用してMySQLサーバーを停止します。
次に、既存のデータベースファイルをEBSボリュームに移動し、MySQLがEBSボリュームを指すようにする必要があります。 mysqlファイルがガイドにあるべき場所に配置されていないため、これは惨事でした。 MySQLサーバーを再起動できません。

助けて！

Elastic BeanstalkでEBSボリュームを使用するようにMySQLを構成する更新されたガイドはありますか？ Google、stackoverflow、serverfaultを検索すると、2008/2009年のガイドがいくつか表示されるため、ElasticBeanstalkでテストされていません。（編集：Eric Hammondのドキュメントのようなものはありますが、CentOS/RHEL用ですか？）
MySQLの起動を妨げているすべてのマウントバインドを元に戻すにはどうすればよいですか？インスタンスとボリュームを削除して最初からやり直す必要がありますか？
Elastic BeanstalkのEBSでMySQLをセットアップしようとして時間を無駄にしていますか？入手可能な情報が不足していることに基づいて、それは次のいずれかです。a）簡単に実行でき、ガイドは必要ありません（したがって、私はばかです）。または、b）Elastic Beanstalkは不要/冗長であるため、誰もMySQLをセットアップしません（したがって、気にする必要はありません）。

編集：あなたのコメントと回答をありがとう。 AWSでPHP/MySQL Webサイトをセットアップするための最良の方法を見つけようとしています。そのため、AWSは「AWSでアプリケーションをすばやくデプロイおよび管理するためのさらに簡単な方法」としてElastic Beanstalkを販売しているため、ElasticBeanstalkは良いアイデアのように思われました。雲。"

ただし、MySQLをEBSで実行する場合、これは完全には当てはまらないようです。私が収集したことから、Elastic Beanstalkは自動的にスケーリングされ、おそらく自動スナップショット機能を備えているため、誰もがRDSを使用していると思います。

だから私はこれらのオプションが残っていると思います：

1）Elastic Beanstalkを使用しない：Eric Hammondのドキュメントに従って、EBSボリュームで実行されているMySQLでUbuntu EC2インスタンスをセットアップします（スケーラビリティの問題があるように思われますか？）。

2）Elastic Beanstalkを使用する：データベースをRDSにセットアップします（スケーラビリティの問題はありません）。

3）Elastic Beanstalkを使用します：ただし、EBSボリュームで実行されているMySQLで構成されたubuntu AMIを使用します（これは可能ですか？Elastic BeanstalkはプライベートAMIで動作しますか？）

4）Elastic Beanstalkを使用する：最初からやり直して、ubuntu命令をCentOS/RHLで動作するように適合させるためのcyberx86の命令を使用します。

この時点で、私のデータベースとサイトのトラフィックは非常に少ないです。スケーラブルにするといいのですが、この時点では、ローカルホストでコードを動作させた後、gitを使用して新しいバージョンをデプロイできるように実行したいと思います。最優先事項は、ホスティングに時間を費やすのではなく、サイトを立ち上げて稼働させ、マーケティングと機能の構築に戻ることです。私は何をすべきか？

cyberx86 · Accepted Answer

私はElasticBeanstalkを使用していませんが、あなたがフォローしているガイドはEC2用です（これは間違いなくお手伝いできます）。あなたが抱えている最初の難しさは、あなたが使用しているガイドがUbuntu9.10用であるということです。 AmazonのLinuxはCentOS/RHELに基づいているので、CentOS6ガイドを見つければもっと楽になります。

問題の根本は、「EBSボリュームの接続」に起因しているようです。 EC2では、複数のEBSボリュームを単一のインスタンスにアタッチできます。すべてのインスタンスにはルートボリュームがあります。これらはS3ベースまたはEBSバックのいずれかです。はるかに好ましいアプローチは、EBSでバックアップされたルートボリュームを使用することです（少しコストがかかりますが、柔軟性と耐久性でそれを補います）。 EBSルートボリュームを持つインスタンスでは、ほとんどの場合、このボリュームが/ dev/sda1として接続されます。最近のLinuxシステムでは、デバイスは実際には/ dev/xvda1として表示されます（コマンドに渡す必要があるのは後者です）。（マウントされたボリュームをフォーマットしようとする以外に-インスタンスが実行されている状態でルートファイルシステムをフォーマットしようとしました-つまり、オペレーティングシステムを消去しようとしていましたが、可能であれば、絶対に良い考えではありません）。

この場合、2番目のEBSボリュームを追加することをお勧めします-インスタンスにアタッチし（たとえば、/ dev/sdhとして、コマンドには/ dev/xvdhを使用します）、それを使用してMySQLデータを保存します。（Elastic Beanstalkを使用していないにもかかわらず）この機能はEC2のかなり中心的な機能であるため、ElasticBeanstalkで2番目のボリュームをアタッチできないとは信じがたいです。

cat /proc/partitionsを実行する（またはfdisk -lを使用する）ことで、EBSデバイスのリストを取得できるはずです。

あなたが行ったことのステップ5で、実際にルートボリュームをそれ自体の中にマウントしていることに気付くでしょう（つまり、/ dev/sda1はすでに/としてマウントされており、/ dev/sda1を/ ebsvolとしてマウントしています）-そうすることは避けてください。

また、/etc/init.d/mysql stopは機能しませんでしたが、/etc/init.d/mysqld stopはおそらく機能していました。（ここでも、ls /etc/init.dを実行することでinit.dスクリプトのリストを取得できます。また、あなたと同じように、通常はserviceコマンドを使用します）。

MySQLデータベースは/ var/lib/mysqlにあるはずですが、/ etc/fstabのマウントポイントはおそらく正しくありません（/ ebsvol問題内のebsvolを考えると）。 cd /var/lib/mysqlすると、データベースを表示できるはずです。そうでない場合は、マウントが正しく機能していません。（/ var/lib/mysqlがmountpoint -d /var/lib/mysqlによって別のデバイスにマウントされていることを確認し、デバイスをcat /proc/partitionsと比較します）。

あなたがフォローしているガイドの基本的な考え方は非常に有効です-データとデータベースをルートボリュームとは異なるEBSボリュームに配置するのが一般的な方法です。これは、多くの利点（パフォーマンス、スナップショットの容易さ、インスタンス間の移動のしやすさ）を提供するためです。など）、基本的なLinuxコマンドは変更されていません。これらはUbuntu専用です。

umount /pathを使用してマウントを元に戻します。もちろん、通常どおり、デバイスがビジーでないことを確認する必要があります（MySQLを起動できなかった場合は問題にならない可能性があります）。ただし、umountは一時的なものにすぎないため、/etc/fstabを編集して、そこからマウントポイントへの参照を削除する必要があります。インスタンスに価値のあるものがない場合は、最初からやり直す方がよい場合があります（いくつかのボリュームをアンマウントするのが難しいためではなく、最初からどこで問題が発生したかを常に簡単に把握できるためです。既知の状態）。

最後に、Elastic Beanstalk上のMySQLに関して：Elastic Beanstalkのポイントは、リソースのプロビジョニングとスケーリングを自動的に処理することです-それはまだコアAWSコンポーネント（EC2、S3、ELBなど）に基づいていますが、あなたのためにいくつかのことをします。 Elastic Beanstalkは通常、RDSを使用してMySQLデータベースを処理します。 RDSは、MySQLインスタンスのプロビジョニングとスケーリングを簡素化するMySQLのAmazonマネージドバージョンです。 MySQLは、多くの設定がないと自動スケーリングに適していません。 2番目のMySQLインスタンスを起動して、2つのインスタンス間で負荷を分割することはできません。レプリケーションを設定する必要がありますが、これは簡単な作業ではない場合があります）。

基本的に、Webサーバーインスタンスから実行され、シームレスに自動スケーリングできるようにMySQLをセットアップできる場合は、Elastic Beanstalkを気にせずに、EC2を直接使用する方がほぼ確実です。したがって、ほとんどの人は実際にはElastic BeanstalkでMySQLをセットアップしないことをお勧めします（別のMySQLインスタンスをセットアップすることもできますが、Beanstalkを使用している場合は、RDSの方がおそらく簡単なアプローチです）。

編集：

主にブラックボックスとして動作する他の多くのサービスとは異なり、ElasticBeanstalkでは基盤となるコンポーネントにアクセスできます。とはいえ、EC2インスタンスを手動でセットアップする作業を行う場合は、ElasticBeanstalkのポイントを否定しています。

EC2を使用している場合、PHP/MySQLへのアプローチはいくつかあります。

Webサーバーとデータベースの両方を単一のインスタンスでホストできます-開始時には、これは合理的なアプローチですが、水平方向にはあまり拡張できません（ただし、より大きなインスタンスを使用して垂直方向に拡張できます）。うまくいけば、x-largeインスタンスの容量を超えるまでに、より複雑なセットアップをセットアップできるようになります。とはいえ、冗長性には悪影響があります。すべてがその単一のインスタンス上にあり、コンポーネントに障害が発生するとセットアップ全体が停止します。
1つのインスタンスでウェブサーバーをホストし、データベースにRDSを使用できます。ほとんどの適切に設計されたアプリケーションは、データベースよりもWebサーバーに負担をかけます（そして、データベースの負荷は理想的には読み取りバイアスされます）。このようなシナリオでは、Webサーバーインスタンスを比較的簡単にスケーリングできます（たとえば、ELBの背後に配置することで、すべてが同じコンテンツを提供していることを確認するための少しの努力が必要です）。 RDSはAWSによって管理されるMySQLです-完全に自動化されているわけではありませんが、自動スケーリングには大いに役立ちます。基本的に、RDSは、必要に応じて引き継ぐことができる複数のホットバックアップを備えた、複数の読み取り専用スレーブと単一の書き込みマスターをプロビジョニングします。欠点は、実行中のすべてのインスタンスに対して料金を支払っているということです（そして、MySQLの複雑な設定の一部を完全に制御することはできません）。
最後のアプローチは、Webサーバークラスターと独自のMySQLクラスターを使用することです。基本的に、（上記のように）Webインスタンスをスケーリングしてから、個別にスケーリングするMySQLインスタンスをセットアップします。 MySQLレプリケーションを調べる必要があります（または、アプリケーションをそのデータ構造に適合させることができる場合は、MySQLクラスターを使用することもできます）。

同じトピックに関する他のいくつかの回答：

私の見解では、通常、ワンクリックソリューションは最善のアプローチではありません。手動で何かを行うことによって提供されるコントロールが好きです。私は通常、より調整された効率的な最終結果が得られるだけでなく、システムがどのように機能するかをはるかによく理解しているため、何が悪いのかをはるかに簡単に理解できます。セットアップの複雑さを十分に理解すれば、いつでも独自のセットアップを自動化できます。

RDSについて覚えておくべき1つのポイント-それはすでにEBSに裏打ちされています。 RDSはMySQLです-似たようなものでも、別のリレーショナルデータベースでもありません。これは、EBSでサポートされているEC2インスタンスで実行されているMySQLのマネージドインスタンスです。 AWSはソフトウェアを最新の状態に保ち、データの通常のEBSスナップショットなどを実行できます。インスタンスで実行されている基盤となるソフトウェアに直接アクセスすることはできません。

オペレーティングシステムの選択に関しては、私はAmazonのLinuxに偏っています。 AWSによって十分にサポートされており、最小限のリソースを使用します。CentOSと完全に互換性があります（実際のところ、最新バージョンにはデフォルトでEPELリポジトリが含まれています）。違いは通常わずかであるため、通常の視点は、使い慣れたLinuxディストリビューションを使用することです（CentOSは、作業中の命令に対してUbuntuと同様に機能します-ほとんどのコマンド（apt-getを除く）はCentOSで同じです。私自身のセットアップでは、AmazonのLinuxを使用して別のEBSボリュームにデータベースがあることを考えると、それを行うのは難しくないことを保証できます）。

主な考慮事項がいくつかあることをお勧めします。

Linuxシステムの快適さ/学習意欲-独自のサーバーをセットアップすることを気にせず、それらをよりよく理解したいのであれば、私は間違いなくEC2ルートに行きます。それを正しく行えば、より良い最終結果が得られ、長期的にはより多様性があります。ただし、このアプローチを採用している場合は、実行しているコマンドが何をするのかを本当に理解したいということを述べておきます。ガイドに従うだけでは、本当にコミットしたいのであれば十分ではありません。
予算-AWSではすべてに価格があることを忘れないでください。 AWSがあなたのために行うことが多ければ多いほど、彼らはあなたに請求します。 RDSインスタンスのコストは同等のEC2インスタンスよりも約30％高く（マイクロインスタンスはありません）、それらが提供する冗長性が必要な場合は、複数のRDSインスタンスを実行する必要があります（それぞれに料金を支払います）。 Elastic Beanstalkは、インスタンス、ロードバランサー、RDSインスタンスなどをプロビジョニングします。コストはすぐに加算されます。
時間-時間がなく、いくつかのボタンを押して何か機能したい場合は、ElasticBeanstalkがおそらく最善のアプローチです。

AMIに組み込まれたMySQLでElasticBeanstalkを使用しないことをお勧めします-動作したとしても、かなり不安定になる可能性があります。（クラスターにインスタンスを追加および削除したとき、またはデータが他のインスタンスではなく一方のインスタンスに移動したときに何が起こるかを考えてみてください...）

スケーラビリティを念頭に置くことは素晴らしいことですが、すぐに最適化しないでください。そうしないと、何も実行されません。確かにそれを覚えておいてください、しかし特定のコンポーネントをスケーラブルにするためのコスト（時間、お金など）が現時点で実用的でないなら、それについてあまり心配しないでください-それをスケーリングする時が来たら、あなたはそれを理解します（結局のところ、最も人気のあるサイトはそのように始まりました）。

アプリケーションがキャッシュを利用できるように設計されている場合は、大いに役立つことをお勧めします。

通常、EC2では、水平方向（より多くのインスタンス）よりも垂直方向（より大きなインスタンス）にスケーリングする方が適切です。ただし、最初に、冗長性を確保し、単一障害点を最小限に抑えるために、2つのインスタンスにスケーリングする必要があります。したがって、考えられるアプローチは次のとおりです。

マイクロインスタンスから始めます-データベースとアプリケーションの両方をその上に置きます（これより小さくすることはできないので、良い出発点になります）。
- もちろん、これは垂直方向にスケーリングするのは非常に簡単です。x-largeインスタンスを使用するまで、インスタンスをアップグレードし続けてください。問題は冗長性にあります。インスタンスに問題がある場合、アプリケーションはオフラインです。
ここで、通常はデータベースを別のインスタンスに分離する必要があります（a）データベースはアプリケーションとは異なる負荷を認識し、b）Webサーバーとまったく同じ方法でMySQLを自動スケーリングできないため）が、マイクロインスタンスは負荷をうまく処理できないため、最初に大きなインスタンスにアップグレードし、少なくとも小さなインスタンスにアップグレードしてから、おそらく中程度にアップグレードすることをお勧めします（基本的に、より大きなインスタンスタイプが必要になると、効果はおそらく大きくなります）
データベースをWebサーバーから分離します。これにより、データベース（高メモリなど）とWebサーバー（高CPUなど）のさまざまなニーズと、それぞれのスケーリング方法の違い（推奨読書）に対応できます。この時点で、独自のMySQLインスタンスを実行する代わりにRDSを使用することを決定する場合があります。
アプリケーションを専用インスタンスで実行しているので、データベースを気にせずにスケーリングできます。冗長性を確保するために自動スケーリングを設定します。これにより、アプリケーションノードのいずれかが失敗した場合、または負荷が指定したしきい値を超えた場合に、アプリケーションノードが自動的に追加されます。
2番目のデータベースノードを追加し、ノード間のレプリケーションを構成します（MySQLクラスターまたはNoSQLソリューションを使用することを選択した場合は、自動スケーリングもセットアップできるはずです）。この時点ですべてに冗長性があり、ノードに障害が発生した場合でも、オンラインのままである必要があります。
需要に応じて、一度に1つのインスタンスをより大きなインスタンスサイズにアップグレードします。

edpeciulis · Answer

Elastic BeanstalkとEC2にもう少し慣れてきたので、Elastic Beanstalkの使用をやめることにしました。これは、いくつかの優れた機能がありますが、自分の好みにはあまりにも管理されているためです。たとえば、httpd.confファイルを変更できないという事実は好きではありません（変更することはできますが、環境を再起動すると変更は消えます）。もう1つの理由は、Elastic BeanstalkをMySQLで（適切に、つまり自動スケーリングと自動バックアップで）実行する唯一の方法はRDSを使用することです。新しいサインアップで3か月のRDSを無料で入手できますが、私はその機能が必要な規模ではないため、RDSに月額76ドルを支払う価値はありません。

結論：適度な量のトラフィックがあり、スケーリングしてそれ自体を処理するソリューションが必要な場合は、RDSを使用したElasticBeanstalkが最適なオプションです。 gitを使用してデプロイできるという事実が気に入っています。これは、Heroku forPHPのようなものです。スタートガイドには、MySQLのセットアップ手順が含まれている必要があります。

私がしたこと：「SyntheticElastic Beanstalk」を使用することを選択しました：AWSのさまざまなオファリングを使用してその機能を再作成でき、希望どおりに構成できる柔軟性があります。 AWSに飽き飽きしている間、Webアプリと同じEC2インスタンスにMySQLをセットアップしました（スケーリングが必要な場合は理想的ではありませんが、AWSの使用方法を学習している間は完全に問題ありません）。

このガイドこれは、Amazon linuxAMIを実行しているEC2インスタンスにLAMPスタックをセットアップするために使用したものです。 phpmyadminを使用してデータベースをインポートする方が簡単だと思います。私はマイクロインスタンスを使用しているため、デフォルトでEBSを使用し、スナップショットを作成してデータをバックアップできます。 EC2用のCLIツールをセットアップして実行することをお勧めします

ec2-modify-instance-attribute --block-device-mapping "/dev/sda1=:false" i-xxxxxxx

ここで、i-xxxxxxxxは、EBSボリュームが接続されているEC2インスタンスです。これにより、インスタンスが終了した場合にEBSボリュームが削除されるのを防ぎます。そのEBSボリュームはすべてが実行され、データベースが保存される場所なので、それを失いたくありません（Elastic Beanstalkで遊んでいたときに、EC2インスタンスが終了し、ElasticBeanstalkが新しいEBSで別のインスタンスを即座に開始しましたボリュームがアタッチされましたが、幸い元のEBSボリュームのDeleteOnTermination設定を「false」に変更したため、新しいインスタンスを停止し、新しいEBSボリュームをデタッチし、古いEBSボリュームをアタッチすることができました。これにより、MySQLのインストールとデータベース）。

全体として、ウェブアプリをAWSに移行するプロセス全体は、依然としてお尻のかなりの苦痛です。学習曲線を終えた今、私はそれをより快適に感じていますが、始めるためのより良いドキュメントがあるべきだと考えずにはいられません。