0

現在、すべてのユーザー生成コンテンツを中規模の EC2 インスタンスにアップロードしており、そこから cron ジョブを実行して、アップロードされたすべてのコンテンツを S3 に同期しています。バックエンドで (アップロードされたファイルにアクセスする必要があるたびに) 実行されるコードがいくつかあります。このコードは、リソースが S3 に移動されたかどうか、またはアップロード インスタンスで利用できるかどうかを確認します。

これは少し無駄に思えますが、冗長性を提供します。S3 がダウンしている場合、アップロード ボックスからファイルを強制的に提供する JavaScript コードが配置されています。実際のファイルのアップロードは、インスタンスではなく EBS に保存されます。

現在、S3 バケットには約 150 GB 相当のファイルがあります。これにより、S3 バケットの個別のバックアップを実行するのは非常に時間がかかり、定期的に実行することはほぼ不可能になります。

それで、私の質問は、これは必要ですか？S3 と EC2 の間のアップタイム統計を誰か教えてもらえますか? S3 がダウンしていても、EC2 は利用できるということはありますか? すべてを S3 に直接アップロードして、それが稼働していることを信頼する方が簡単なように思えます..一方、すべてを EBS に保存して、S3 を完全に無視することもできます。

4

1 に答える 1

2

S3 がダウンするよりも、EC2 インスタンスがダウンする可能性の方がはるかに高いです。1 つには、単一のアベイラビリティ ゾーン内の単一のネットワーク接続を持つ単一のホスト上で実行されている単一のインスタンスがあります。それを過ぎると、プラットフォーム レベルでは、EC2 (特に EBS を含む) には数回の 長引く 停止がありましたが、S3 には 2008 年以来、重要な可用性イベントはありませんでした。

S3 は、選択したリージョン全体に広がる分散システムです。結果整合性が保証されたオブジェクト レベルでの操作は、率直に言って、EBS や EC2 によって対処される問題よりもはるかに簡単です。

私は通常、アップロード プロセスが S3 をバッキング ストアとして扱うようにします。つまり、S3 に直接アップロードするか、ライトスルー方式で EC2 インスタンスを介してアップロードします。S3 がダウンしている場合、アップロードを処理できないことを受け入れます。このようにすると、アプリは実行されているが S3 は実行されていないという障害モードが導入されますが、データ損失の可能性が大幅に減少します。これは、通常、利用できないことよりも深刻な問題です。これにより、異なるアベイラビリティ ゾーンの異なる EC2 インスタンスを介してアップロードを同時に処理して、EC2 の障害をヘッジし、インスタンス ストア インスタンスを介して EBS の障害をヘッジすることもできます。

于 2012-12-17T22:12:57.287 に答える