インスタンスをマイクロインスタンス、さらに小さなインスタンスに移動したいのですが、マイクロインスタンス AMI に基づいて新しい AMI を起動しようとすると、64 ビットインスタンスのオプションしか表示されません。
私の最初の ami は、ubuntu 10.04 イメージに基づいています。
64 ビットインスタンスと 32 ビットインスタンス間で移動することはできませんか?
ロードバランサーを使用して 32 ビットインスタンスと 64 ビットインスタンスを連携させることは可能ですか?
大量のデータをアップロードする Web サイト/Web アプリがあります。最初は 65 GB の画像から始めて、100 GB 以上の画像に移行していく予定です。
どのインスタンス タイプが最適かはわかりません。負荷が高いときにインスタンスの数を増やすために、ロード バランサーと自動スケーリングを使用するつもりでした。
また、ロードバランサーを使用する場合、AMI インスタンスの 1 つがプライマリ イメージになり、残りはそのクローンとして機能しますか?
答え1
イメージは、作成されたのと同じアーキテクチャ (32 ビットまたは 64 ビット) でのみ起動できます。マイクロ インスタンスは 32 ビットまたは 64 ビットのいずれかになりますが、作成時に 64 ビット イメージを使用した場合は、そのイメージしか使用できません。予算に余裕があれば、「小さい」インスタンスではなく「大きい」インスタンスを使用できます。
異なるタイプのインスタンスをロードバランスすることは完全に可能です (Amazon の ELB を使用するか、HAProxy、Squid、varnish などを使用した別のインスタンスを使用するかのいずれか)。
最大の問題は、その量のデータをどこに保存するかということだと思います。同じコンテンツを提供するインスタンスを複数用意する（そしてアップロードする）場合は、共有ストレージGlusterFS などを使用してインスタンス間でデータを共有したり、Web インスタンスが NFS マウントする「ストレージ サーバー」を用意したりすることもできます。
オートスケーリングの仕組みは、まず「マスター」イメージの AMI ID である「起動イメージ」を設定します。次に、トリガー (負荷が高すぎるなど) に応じてこのイメージを起動します。これが概念的に何を意味するかを考えることが重要です。つまり、起動される各インスタンスは元のイメージに基づいており、新しいデータや更新された構成などは含まれません。
まとめると、複数の Web サーバーを使用する場合は、何らかの共有ストレージが必要になります。多くの場合、これはデータベース (Amazon の RDS サービス上にあるものなど) ですが、データではなく大きな「ファイル」を保存する必要があるようですので、分散ストレージまたはストレージ サーバーが必要です。
答え2
によるAmazon EC2 インスタンスの説明ページマイクロインスタンスは 32 ビットと 64 ビットで使用できますが、スモールインスタンスタイプは 32 ビットでのみ使用できます。これが、スモールインスタンスタイプで最初の 64 ビット AMI を起動できなかった理由です。
- アップデート: AWSはその間に64 ビットのユビキタスつまり、すべてのインスタンスタイプは64ビットイメージで使用でき、並列（32 ビットと 64 ビット）AMI を維持することなく、垂直方向（より大きなインスタンスとより小さなインスタンス）にスケーリングすることが容易になります。（見るEC2 アップデート: 新しいミディアムインスタンス、64 ビット Ubiquity、SSH クライアント詳細については）。
ロード バランサーの問題に関して: これは使用パターンに大きく依存します。32 ビットと 64 ビットの両方のインスタンス タイプは、ロード バランサーの背後で問題なく連携できます。ただし、インスタンス タイプは 1 つに絞ることをお勧めします。一般に、アップロードのみで画像処理などを行わない場合は、I/O とメモリが主な懸念事項になると思います。Web アプリに必要な最小限の設定で試してみて、両方のインスタンス タイプで負荷テストをいくつか実行することをお勧めします。