Amazon EC2 のインスタンスについて、EBS とインスタンスストアのどちらから得られるメリットがよくわかりません。どちらかといえば、EBS の方がはるかに便利 (停止、開始、永続化 + 速度の向上) であり、コストの差は比較的少ないようです...? また、EBS がまだ比較的新しいことを考えると、EBS が利用可能になった今、より多くの人々が EBS を使用しているかどうかについての指標はありますか?
132439 次
10 に答える
297
肝心なのは、ほとんどの場合、EBS でサポートされたインスタンスを使用する必要があるということです。
これが理由です
- EBS でサポートされているインスタンスは、API を介して (誤って) 終了できないように設定できます。
- EBS でサポートされているインスタンスは、使用していないときに停止し、再び必要になったときに再開できます (仮想 PC の一時停止など)。少なくとも、私の使用パターンでは、数十 GB の EBS ストレージに費やすよりもはるかに多くのお金を節約できます。
- EBS でサポートされているインスタンスは、クラッシュしてもインスタンス ストレージを失うことはありません (すべてのユーザーの要件ではありませんが、復旧がはるかに高速になります)。
- EBS インスタンス ストレージのサイズを動的に変更できます。
- EBS インスタンス ストレージを新しいインスタンスに移すことができます (実行していた Amazon のハードウェアが不安定になったり故障したりする場合に役立ちます。これは時々発生します)。
- イメージを S3 からフェッチする必要がないため、EBS でサポートされているインスタンスを起動する方が高速です。
- EBS-backed インスタンスのハードウェアのメンテナンスがスケジュールされている場合、インスタンスの停止と開始により、新しいハードウェアに自動的に移行されます。また、インスタンスを強制停止してから再度起動することで、障害が発生したハードウェアで EBS-backed インスタンスを移動することもできました (障害が発生したハードウェアによって距離が異なる場合があります)。
私は Amazon のヘビー ユーザーであり、テクノロジーがベータ版から出るとすぐに、すべてのインスタンスを EBS でバックアップされたストレージに切り替えました。私は結果にとても満足しています。
EBS はまだ失敗する可能性があります - 特効薬ではありません
クラウドベースのインフラストラクチャはいつでも失敗する可能性があることに注意してください。それに応じてインフラストラクチャを計画します。EBS-backed インスタンスは、エフェメラル ストレージ インスタンスと比較して一定レベルの耐久性を提供しますが、失敗する可能性があり、実際に失敗します。任意のアベイラビリティ ゾーンで必要に応じて新しいインスタンスを起動し、重要なデータ (データベースなど) をバックアップできる AMI を用意し、予算が許せば、負荷分散と冗長性のために複数のサーバー インスタンスを実行します (複数のアベイラビリティ ゾーンが理想的です)。 ）。
しないとき
ある時点で、Instance Store インスタンスでより高速な IO を実現する方がコストがかからない場合があります。それが確かに真実だった時がありました。現在、EBS ストレージには多くのオプションがあり、多くのニーズに対応しています。オプションとその価格は、テクノロジーの変化に応じて常に進化しています。本当に使い捨て可能なインスタンスが大量にある場合 (それらがなくなっても、ビジネスに大きな影響を与えることはありません)、コストとパフォーマンスの計算を行ってください。EBS でサポートされているインスタンスもいつでも終了する可能性がありますが、私の実際の経験では、EBS の方が耐久性があります。
于 2010-09-02T19:55:03.680 に答える
69
AWSセットアップの99％はリサイクル可能です。したがって、私にとっては、インスタンスを終了するかどうかは実際には問題ではありません。何も失われることはありません。たとえば、私のアプリケーションはSVNからのインスタンスに自動的にデプロイされ、ログは中央のsyslogサーバーに書き込まれます。
私が見ているインスタンスストレージの唯一の利点は、コスト削減です。それ以外の場合は、EBSでサポートされているインスタンスが優先されます。エリックはすべての利点について言及しました。
[2012-07-16]今日はこの答えを大きく変えたいと思います。
過去1年ほど、EBSでサポートされたインスタンスについては良い経験がありません。AWSでの最後のダウンタイムは、EBSもかなり破壊しました。
RDSのようなサービスもある種のEBSを使用していると思いますが、それはほとんどの部分で機能しているようです。私たちが自分たちで管理しているインスタンスでは、可能な場合はEBSを削除しました。
データベースクラスターをアイアン（=実際のハードウェア）に戻した拡張機能を削除します。インフラストラクチャに残っているのはDBサーバーだけで、複数のEBSボリュームをソフトウェアRAIDにストライプ化し、1日2回バックアップします。バックアップの間に失われるものが何であれ、私たちは一緒に暮らすことができます。
EBSは、本質的にネットワークボリューム、つまりリモートからサーバーに接続されたボリュームであるため、やや不安定なテクノロジーです。私はそれで行われた作業を否定していません-本質的に無制限の永続ストレージはAPI呼び出しだけであるため、これは素晴らしい製品です。ただし、I/Oパフォーマンスが重要なシナリオにはほとんど適していません。
また、ネットワークストレージの動作に加えて、すべてのネットワークがEC2インスタンスで共有されます。インスタンスが小さいほど（たとえば、t1.micro、m1.small）、実際のホストシステム上のネットワークインターフェイスは、その上で実行される複数のVM（= EC2インスタンス）間で共有されるため、悪化します。
取得するインスタンスが大きいほど、もちろんそれは良くなります。ここでより良いとは、理にかなった範囲内を意味します。
永続性が必要な場合は、インスタンス間で一元化するためにS3のようなものを使用するように常にアドバイスします。S3は非常に安定したサービスです。次に、インスタンスのセットアップを自動化して、新しいサーバーを起動し、サーバーが自動的に準備できるようにします。その場合、インスタンスよりも長持ちするネットワークストレージを用意する必要はありません。
したがって、全体として、EBSでサポートされているインスタンスにはこれまで何のメリットもありません。ブートストラップに1分を追加してから、潜在的なSPOFで実行します。
于 2010-10-21T14:55:50.360 に答える
41
We like instance-store. It forces us to make our instances completely recyclable, and we can easily automate the process of building a server from scratch on a given AMI. This also means we can easily swap out AMIs. Also, EBS still has performance problems from time to time.
于 2011-11-24T14:39:26.570 に答える
17
エリックはかなりそれを釘付けにしました。私たち ( Bitnami ) は、人気のあるアプリケーションや開発フレームワーク (PHP、Joomla、Drupal など) 向けの無料の AMI の人気プロバイダーです。EBS を利用した AMI は、S3 を利用した AMI よりもはるかに人気があると言えます。一般的に、s3 でバックアップされたインスタンスは、1 台のマシンに障害が発生した場合に別のマシンがスピンアップする、分散型の時間制限のあるジョブ (データの大規模な処理など) に使用されると思います。EBS を利用した AMIS は、Web サーバーやデータベース サーバーなどの「従来の」サーバー タスクに使用される傾向があり、ローカルで状態を保持するため、クラッシュした場合にデータを利用できる必要があります。
言及されていなかった側面の 1 つは、実行中に EBS でバックアップされたインスタンスのスナップショットを作成できるという事実です。これにより、インフラストラクチャの非常に費用対効果の高いバックアップを効果的に作成できます (スナップショットはブロックベースで増分です)。
于 2011-06-26T20:38:09.607 に答える
16
私は前職でエリックとまったく同じ経験をしました。現在、私の新しい仕事では、前の仕事で実行したのと同じプロセスを実行しています... EBS でサポートされているインスタンス用にすべての AMI を再構築しています。 64台）。
EBS でバックアップされたインスタンスはすぐに起動するので、Amazon AutoScaling APIを使い始めることができます。これにより、CloudWatch メトリクスを使用して追加のインスタンスの起動をトリガーし、それらを ELB (Elastic Load Balancer) に登録し、必要に応じてシャットダウンすることもできます。不要になりました。
この種の動的な自動スケーリングこそが AWS のすべてであり、IT インフラストラクチャの実際の節約が実現できる場所です。古い s3 の「InstanceStore」でサポートされているインスタンスで自動スケーリングを正しく行うことはほとんど不可能です。
于 2010-12-31T00:25:08.057 に答える
13
私は EC2 を自分で使い始めたばかりなので専門家ではありませんが、Amazon 自身のドキュメントには次のように書かれています。
一時データにはローカル インスタンス ストアを使用することをお勧めします。より高いレベルの耐久性が必要なデータには、Amazon EBS ボリュームを使用するか、データを Amazon S3 にバックアップすることをお勧めします。
鉱山を強調します。
私はWeb ホスティングよりも多くのデータ分析を行っているため、永続性は Web サイトの場合ほど重要ではありません。Amazon 自身が行った違いを考えると、EBS がすべての人に適しているとは思いません。
両方を使用した後、もう一度重量を量ることを忘れないようにします.
于 2012-08-07T06:09:35.840 に答える
4
ほとんどの人は、ステートフルであるため、EBS でサポートされたインスタンスを使用することを選択します。内部で実行およびインストールされているものはすべて、停止/停止またはインスタンスの障害に耐えられるため、より安全です。
インスタンス ストアはステートレスです。インスタンスに障害が発生した場合、内部のすべてのデータが失われます。ただし、インスタンス ボリュームは VM が実行されている物理サーバーに関連付けられているため、無料で高速です。
于 2015-12-11T21:01:54.113 に答える
2
このすべてに不慣れで、誤ってここに着陸した場合
現在、クイックスタート セクションのすべての AMI は EBS でサポートされています
また、 EBSとインスタンス ストアの違いについては、公式ドキュメントに適切な説明があります。
＆この画像はそれをかなり要約しています
于 2016-04-18T08:16:32.573 に答える
0
複数のインスタンスを実行し、AWS インスタンスのスケジュールされたサービスを予期しない料金の回避の優先事項の 1 つとして割り当てる場合は、 instance-store を使用しないことをお勧めします。
EBS ボリュームのドキュメントと、 j2d3およびSiddharth Sharma からの回答で説明されているように、インスタンス ストアは必要なだけ実行できますが、停止することはできません。自動開始/停止またはインスタンス回復によってサービスをスケジュールできないことを意味します。
さらに、この種のスキームでは、 Elastic BeanstalkでバックアップされたEBSを使用する利点もありません。これは、必要なすべてのリソースが確実に実行され続けるように設計されているためです。停止したサービスは常に自動的に再起動します。
EC2 - Classicに追加された VPC、EBS、および ELB を使用した場合の合計料金のうち、EC2 - Classicとは異なり、停止したインスタンスが関連付けられたElastic IPアドレス
EBS ボリュームは自動的に保存されます。
結論として、質問の主要部分を取り上げます。
EBS の方がはるかに便利 (停止、開始、永続化 + 速度の向上) で、コストの差は比較的少ないようです...?
答えはイエスですが、インスタンスが EBS ベースの場合は停止できます。アカウントに残り、請求されることはありません。ボリュームのみが課金されますが、 EBS は時間単位で課金されます。また、利用可能なすべてのタイプの中で、 EBS ボリュームのサイズを変更する柔軟性があると考えるかもしれません。
Ericがすでに挙げた利点に加えて、S3 はコスト面で EBS よりも安い場合もあれば、そうでない場合もあることに注意してください。同じプラットフォームとアプリケーションのアーキテクチャ内で両方のタイプのインスタンスを常に実行し続ける場合、コストの違いは比較的小さいことに同意します。
ただし、低コストのサービスでアプリケーションを実行するシナリオがある場合は、未処理のタスクをすべてプルし、パイプラインまたはラムダを介してVPC /EBSにロールします。たとえば、1 日 1 時間未満という短時間で実行できます。 instance-storeを使用すると、別の話になります。
于 2016-07-06T22:46:48.333 に答える