EBSとインスタンスストアの利点（およびその逆）[終了]

Amazon EC2のインスタンスでEBSとインスタンスストアを比較すると、どのようなメリットがあるのか​​わかりません。どちらかといえば、EBSはコストの差が比較的小さいにもかかわらず、はるかに便利（停止、開始、持続+速度の向上）のようです...？また、EBSがまだ比較的新しいことを考慮して、EBSが利用可能になったことで、より多くの人々がEBSを使用しているかどうかについての指標はありますか？

一番下の行は、ほとんど常にEBSでバックアップされたインスタンスを使用する必要があるということです。

ここに理由があります

• EBSでサポートされているインスタンスは、APIを介して（誤って）終了できないように設定できます。
• EBSでバックアップされたインスタンスは、使用していないときは停止し、必要に応じて再開すると（Virtual PCの一時停止など）、少なくとも数十GBのEBSストレージに費やすよりもはるかに多くの費用を節約できます。
• EBSでバックアップされたインスタンスは、クラッシュしたときにインスタンスストレージを失うことはありません（すべてのユーザーの要件ではありませんが、リカバリがはるかに高速になります）。
• EBSインスタンスストレージのサイズを動的に変更できます。
• EBSインスタンスストレージをまったく新しいインスタンスに転送できます（実行中のAmazonのハードウェアが不安定になったり、時々発生する場合があります）。
• イメージをS3からフェッチする必要がないため、EBSでバックアップされたインスタンスを起動する方が高速です。
• EBSでバックアップされたインスタンスのメンテナンスが予定されているハードウェアの場合、インスタンスの停止と起動は新しいハードウェアに自動的に移行します。また、インスタンスを強制停止して再度起動することで、障害が発生したハードウェア上でEBS-backedインスタンスを移動することもできました（障害が発生したハードウェアによって距離が異なる場合があります）。

私はAmazonのヘビーユーザーであり、テクノロジーがベータ版から抜け出した直後に、すべてのインスタンスをEBSバックアップストレージに切り替えました。結果に非常に満足しています。

EBSはまだ失敗する可能性があります-特効薬ではありません

クラウドベースのインフラストラクチャは、いつでも故障する可能性があることに注意してください。それに応じてインフラストラクチャを計画します。EBSを使用したインスタンスは、一時ストレージインスタンスと比較して一定のレベルの耐久性を提供しますが、失敗する可能性があります。任意のアベイラビリティーゾーンで必要に応じて新しいインスタンスを起動し、重要なデータ（データベースなど）をバックアップできるAMIを用意し、予算に余裕がある場合は、ロードバランシングと冗長性のためにサーバーの複数のインスタンスを実行します（理想的には複数のアベイラビリティーゾーンで） ）。

しない場合

ある時点で、Instance Storeインスタンスでより高速なIOを実現する方が安くなる場合があります。それが確かに本当だった時代がありました。現在、EBSストレージには多くのオプションがあり、多くのニーズに対応しています。オプションとその価格設定は、テクノロジーの変化に応じて常に進化しています。本当に使い捨てであるインスタンスが大量にある場合（それらがなくなるだけでビジネスに大きな影響を与えない場合）、コストとパフォーマンスを比較してください。EBSでサポートされているインスタンスもいつでも停止する可能性がありますが、私の実際的な経験では、EBSの方が耐久性が高いということです。

AWSセットアップの99％はリサイクル可能です。したがって、私にとっては、インスタンスを終了しても問題はありません。失われるものはありません。たとえば、私のアプリケーションはSVNからインスタンスに自動的にデプロイされ、ログは中央のsyslogサーバーに書き込まれます。

私が目にするインスタンスストレージの唯一の利点は、コストの節約です。それ以外の場合は、EBS-backedインスタンスが優先されます。エリックはすべての利点に言及しました。

[2012-07-16]今日、私はこの答えを非常に異なる言い方にします。

過去1年ほど、EBSでバックアップされたインスタンスを使った経験はありません。AWSでの最後のダウンタイムもEBSをかなり破壊しました。

RDSのようなサービスもある種のEBSを使用していると思います。私たちが自分で管理するインスタンスでは、可能な場合はEBSを廃止しました。

データベースクラスターをIron（=実際のハードウェア）に戻した拡張部分を取り除く。インフラストラクチャの残りの部分は、複数のEBSボリュームをソフトウェアRAIDにストライプ化し、1日2回バックアップするDBサーバーです。バックアップとバックアップの間に失われるものは何でも、私たちは我慢できます。

EBSは本質的にネットワークボリュームであるため、やや不安定なテクノロジーです。リモートからサーバーに接続されたボリュームです。私はそれで行われた作業を否定していません。本質的に無制限の永続ストレージはAPIを呼び出すだけなので、素晴らしい製品です。ただし、I / Oパフォーマンスが重要なシナリオには適していません。

ネットワークストレージの動作に加えて、すべてのネットワークはEC2インスタンスで共有されます。インスタンスが小さいほど（t1.micro、m1.smallなど）、実際のホストシステム上のネットワークインターフェースが、その上で実行される複数のVM（= EC2インスタンス）間で共有されるため、パフォーマンスは低下します。

取得するインスタンスが大きいほど、当然、より良いインスタンスになります。ここのほうが理にかなっていることを意味します。

永続化が必要な場合は、S3のようなものを使用してインスタンス間を集中化するように常にアドバイスします。S3は非常に安定したサービスです。次に、インスタンスのセットアップを自動化して、新しいサーバーを起動でき、それ自体で準備ができるようにします。その場合、インスタンスよりも長く存続するネットワークストレージを用意する必要はありません。

したがって、全体として、EBSでバックアップされたインスタンスには何のメリットもありません。ブートストラップに1分を追加してから、潜在的なSPOFで実行します。

インスタンスストアが好きです。これにより、インスタンスを完全にリサイクル可能にする必要があり、特定のAMIでサーバーを最初から構築するプロセスを簡単に自動化できます。これは、AMIを簡単に交換できることも意味します。また、EBSにはまだ時々パフォーマンスの問題があります。

エリックはそれをかなり釘付けにしました。私たち（Bitnami）は、人気のあるアプリケーションや開発フレームワーク（PHP、Joomla、Drupalなど）に無料のAMIを提供する人気のプロバイダーです。EBSを利用したAMIは、S3を利用したAMIよりもはるかに人気があることがわかります。一般に、s3でバックアップされたインスタンスは、1つのマシンに障害が発生した場合に別のマシンが単純に起動する分散時間制限付きジョブ（たとえば、データの大規模な処理）に使用されると思います。EBSでサポートされたAMISは、ローカルで状態を維持するため、クラッシュした場合にデータを利用できるようにするWebサーバーやデータベースサーバーなどの「従来の」サーバータスクに使用される傾向があります。

私が言及しなかった1つの側面は、実行中にEBS-backedインスタンスのスナップショットを取得できるという事実です。これにより、インフラストラクチャの非常に費用対効果の高いバックアップを効果的に作成できます（スナップショットはブロックベースで増分です）。

私は最後のポジションでエリックとまったく同じ経験をしました。今私の新しい仕事では、最後の仕事で実行したのと同じプロセスを実行しています... EBSでバックアップされたインスタンス用にすべてのAMIを再構築します。32ビットマシン（安価）として再構築することもできますが、32と64台のマシン）。

EBSでバックアップされたインスタンスは、Amazon AutoScaling APIの使用を開始できるほど迅速に起動します。これにより、CloudWatchメトリックを使用して追加のインスタンスの起動をトリガーし、それらをELB（Elastic Load Balancer）に登録し、いつでもシャットダウンできます。もう必要ありません。

この種の動的な自動スケーリングは、AWSのすべてです。ITインフラストラクチャにおける実際の節約を実現することができます。古いs3 "InstanceStore"を使用したインスタンスで自動スケーリングを正しく行うことはほとんど不可能です。

私はEC2を使い始めたばかりなので、専門家ではありませんが、Amazonのドキュメントには次のように書かれています。

一時データにはローカルインスタンスストアを使用することをお勧めします。より高いレベルの耐久性が必要なデータの場合は、Amazon EBSボリュームを使用するか、データをAmazon S3にバックアップすることをお勧めします。

強調鉱山。

私はWebホスティングよりも多くのデータ分析を行うので、永続性はWebサイトの場合ほど重要ではありません。アマゾン自体の違いを考えると、EBSがすべての人に適しているとは思いません。

両方を使用した後は、もう一度計量することを忘れないようにします。

EBSはVMの仮想ディスクに似ています。

• EBSに支えられた耐久性のあるインスタンスは、自由に開始および停止できます（コスト削減）。
• ポイントインタイムバックアップを取得するために、任意の時点でスナップショットを作成できます
• AMIはEBSスナップショットから作成できるため、EBSボリュームは新しいシステムのテンプレートになります

インスタンスストレージは次のとおりです。

• ローカルなので、一般的に高速
• 非ネットワーク化、通常の場合、EBS I / Oはネットワーク帯域幅を犠牲にします（個別のEBS帯域幅を​​持つEBS最適化インスタンスを除く）
• 1秒あたりのIOPSが制限されています。プロビジョニングされたI / Oでも数千IOPSに達する
• 壊れやすい。インスタンスが停止するとすぐに、インスタンスストレージ内のすべてが失われます。

それぞれを使用する場所は次のとおりです。

• EBSをバッキングOSパーティションと永続ストレージ（DBデータ、重要なログ、アプリケーション構成）に使用する
• インプロセスストレージ、重要でないログ、一時的なアプリケーションの状態にインスタンスストレージを使用します。例：外部ソートストレージ、一時ファイルなど
• インスタンスストレージは、インスタンス間にレプリケーションがある場合（NoSQL DB、分散キュー/メッセージシステム、レプリケーションを備えたDB）、パフォーマンスが重要なデータにも使用できます。
• システム間で共有されるデータにはS3を使用します：入力データセットと処理された結果、または起動時に各システムで使用される静的データ。
• プリベークされた起動可能なサーバーにAMIを使用する

ステートフルであるため、ほとんどの人はEBSバックアップインスタンスの使用を選択します。内部で実行およびインストールしたものはすべて、停止/停止またはインスタンスの障害が発生しても存続するため、安全です。

インスタンスストアはステートレスであり、インスタンスに障害が発生した場合は、内部のすべてのデータとともにストアを失います。ただし、インスタンスボリュームはVMが実行されている物理サーバーに関連付けられているため、無料で高速です。

これらすべての初心者で、誤ってここに着陸した場合

現在、クイックスタートセクションのすべてのAMIはEBSでサポートされています

また、EBSとインスタンスストアの違いについては、公式ドキュメントに説明があります

＆この画像はかなり要約しています

複数のインスタンスを実行し、予期しない請求を回避するための優先順位の1つとしてAWSインスタンスのスケジュールされたサービスを割り当てる場合は、インスタンスストアを使用しないことをお勧めします。

EBSボリュームのドキュメントとj2d3およびSiddharth Sharma からの回答で説明されているように、インスタンスストアは必要な限り実行できますが、停止することはできません。自動開始/停止またはインスタンスの回復によってサービスをスケジュールできないことを意味します。

さらに、この種のスキームでは、Elastic BeanstalkでEBS Backedを使用するメリットもありません。これは、必要なすべてのリソースを確実に実行し続けるように設計されているためです。停止したサービスは常に自動的に再起動されます。 レビューすべての残りの部分を、使用上の総費用のうち、VPC、EBSおよびELBをに加えることEC2-クラシック、EC2-VPCでのELBは、ほとんどのとは異なり、最良の選択であるEC2-クラシック、停止したインスタンスが保持してそれに関連する弾性をIPアドレスEBSボリュームは自動的に保存されます。

結論として、あなたの質問の主要部分を取る：

EBSは、コストの差が比較的小さいにもかかわらず、はるかに便利（停止、開始、持続+速度向上）のようです...？

答えは「はい」ですが、インスタンスがEBSベースの場合は停止できます。それはあなたのアカウントに残ります、あなたはそれのために請求されません。ボリュームのみが課金されますが、EBSは1時間ごとに課金されます。また、利用可能なすべてのタイプの中で、EBSボリュームのサイズを変更する柔軟性があると考えることもできます。

Ericがすでにリストしている利点に加えて、コストの点でS3はEBSよりも安い場合とない場合があることにも注意する必要があります。アプリケーションの同じプラットフォームとアーキテクチャ内で両方のタイプのインスタンスを常に実行し続けても、コストの差は比較的小さいことに同意します。

ただし、より低コストのサービスでアプリケーションを実行するシナリオがある場合は、すべての未処理のタスクをプルし、パイプラインまたはラムダを介してそれらを短時間でVPC / EBSに割り当て、1日1時間未満と言います。インスタンスストアを使用すると、別の話になります。