制限付きのAmazon EC2バックアップ戦略（スナップショットをほとんどまたはまったく取得できない？）
同様の質問が出されましたが、EC2の使用に関する私の理解に何か足りないものがあるかどうかを知るために、状況下で何が推奨されるかを知る必要があります。
小さなスタートアップがEC2ネットワークでビジネスを運営していて、バックアップオプションに関するアドバイスを求めてきました。彼らは現在自己資金で運営されており、可能な場合はコストを節約するためにできることを行っています。それらのシステムの構成を深く掘り下げることなく、例としてWebサーバーを示します。データベースを備えたシンプルなWebサーバーです。摩擦は、彼らがサーバーを停止させたくないということです。
セットアップを行っている人は、データベースを定期的にダンプしてS3に保存するか、必要なときにAmazonで新しいサーバーを再構築するスクリプトを作成する必要があると考えています。 。彼は、サーバーのスナップショットを作成するのは無駄であると提案しました。サーバーは多くのディスクスペースを必要とし、本質的に大きなデータダンプ間でデータが腐敗し、スナップショットがすぐに古くなるためです。
私の考えは、VMのスナップショットを作成してから、データベースの定期的なダンプを実行してS3に保存することでした。 EC2インスタンスを失ったり、更新などで使用できなくなった場合は、最初から始めて完全に新しいインスタンスを構築するのではなく、スナップショットを使用して、最新のデータベースダンプを使用してサーバーを比較的迅速にバックアップできます。新しいAMI。
私の理解では、EC2インスタンス（またはEBSストア）のスナップショットを撮るにはダウンタイムが必要であり、彼らはそれをためらっています。また、スナップショットを作成するときにファイルシステムの一貫性を保つために、サーバーをシャットダウンする必要があることも読みました。まだバランサーの背後にクラスターがないため、スナップショットに関連するオプションが制限されます。
サーバーを構築するためのスクリプト記述は、Amazonに特定されない限り、EC2に関連する役割を持つ新しいサーバーをデプロイできるChefまたはPuppetサーバーの作成を伴います。現在、新興企業にはその種のサーバーを維持するための資金がありませんし、今のところ、それほど多くのサーバーを展開する必要はありません。
理想的には、仮想バランサーまたはAmazonのバランサーサービスの背後に多数のサーバーを作成し、一度に1つずつサーバーを停止して更新またはスナップショットを実行するための資金が必要です。データベースのダンプを実行している場合、システムの更新によってアプリケーションが依存するライブラリが変更され、サービスがダウンした場合、更新を実行するという考えには今のところ神経質になっています。
また、別のオプションとして、EBSボリュームを作成してマウントするスクリプトを実行し、サーバーでrsyncなどを実行して、ほとんどのファイルシステム情報をEBSボリュームにキャプチャし、コンテンツを圧縮してS3にコピーし、ボリュームを切断することも想定しました。ストレージコストを節約するためにそれを破棄し、データベースダンプを実行して、他の方法では一貫性のない飛行中のデータをキャッチします。一部のサーバーでは、データベースのニーズが増大するにつれて、一時的なEBSボリュームに保存する必要が生じる可能性があります。
VMWareサンドボックスは、Amazonの本番システムに適用する前に更新を事前テストできる環境でネットワークシステムを再作成するために作成されています。これにより、システムの更新によってアプリケーションが強制終了される可能性が最小限に抑えられることを願っています。
したがって、システム上にデータベースとアプリケーションサーバーを備えた1つのサーバーを実行するという制限を与えて、ダウンタイムをできるだけなくすようにします（スナップショットの使用を制限し、バックアッププロセスをできるだけ「ホット」にします（サーバーを停止せずにライブで作成された）、EC2インスタンスのスナップショットを動作状態で作成し、そこからデータベースダンプを実行してS3にコピーする時間をスケジュールすることを提案するのは間違っていますか？追求するより良い戦略はありますか？スナップショットがダウンタイムを引き起こす場合、サーバーのライブバックアップを作成する際に？
この質問には、特にダウンタイムの概念に関して興味深いことがあります。アプリケーションがダウンタイムに敏感な場合は、回復時間も考慮に入れる必要があるという考えの一部です（極端な議論として、バックアップが必要な場合を除いて、バックアップはダウンタイムを必要としません。その場合、ダウンタイムは無限に近づく可能性があります）。
EBSについて少し
EBSボリュームとスナップショットはブロックレベルで動作します。その結果、EBSボリュームが使用されている場合でも、インスタンスの実行中にスナップショットを取得できます。ただし、実際にディスク上にある（つまり、ファイルキャッシュにない）データのみがスナップショットに含まれます。一貫性のあるスナップショットのアイデアを生み出すのは後者の理由です。
- 推奨される方法は、ボリュームを切り離し、スナップショットを作成してから再接続することです。通常は実用的ではありません。
- 次善の策は、書き込みキャッシュをディスクにフラッシュし、ファイルシステムをフリーズし、スナップショットを取得することです。
ここで興味深い点は、上記の両方の場合で、スナップショットが再接続/フリーズ解除してディスクへの書き込みを再開するのを待つ必要がないことです。スナップショットが開始されると、データはその時点で一貫性があります。通常、これはディスクが書き込みロックされている間、ほんの数秒しか必要としません。また、ほとんどのデータベースはディスク上のファイルを合理的な方法で構造化するため（挿入による既存のブロックへの影響が最小限になる可能性が高くなります）、スナップショットに追加されるデータが最小限に抑えられます。
バックアップのポイントを検討してください
EBSボリュームはすでにアベイラビリティーゾーン内で複製されているため、ある程度の冗長性が組み込まれています。インスタンスが終了した場合は、EBSボリュームを新しいインスタンスに接続するだけで、（一貫性の欠如を乗り越えた後）どこからでも再開できます。やめた。多くの点で、これにより、EBSボリュームは、アクセス可能な場合、不整合なスナップショットのようになります。そうは言っても、ほとんどのEC2ユーザーは、おそらく2011年初頭からのEBSボリュームのカスケード障害を思い出します-ボリュームは数日間アクセスできず、一部のユーザーもデータを失いました。
RAID1
EBSディスクの障害から保護しようとしている場合（実際に発生します）、RAID1セットアップを検討することができます。 EBSボリュームはブロックデバイスであるため、mdadmを使用して簡単に希望の構成にセットアップできます。 EBSボリュームの1つが仕様どおりに実行されない場合は、手動で失敗させる（後で後で別のEBSボリュームに置き換える）のは簡単です。もちろん、これには欠点があります-すべての書き込みの時間が長くなり、パフォーマンスが変動する可能性が高くなり、I/Oコストが2倍になり（パフォーマンスではなく金銭的）、より広範囲のAWS障害に対する実際の保護がありません（昨年の一般的な問題はロック状態にあったEBSボリュームをデタッチできないこと）、そしてもちろん、障害時のディスクの一貫性のない状態。
S3FS
特定のアプリケーション（データベースでは絶対にありません）のオプションは、S3をローカルファイルシステムとしてマウントすることです（たとえば、s3fsを介して）。これは遅く、ファイルシステムに期待される機能の一部が不足しており、期待どおりに動作しない可能性があります（結果整合性）。とはいえ、アップロードされたファイルをインスタンス間で利用できるようにするなどの単純な目的には、メリットがあるかもしれません。明らかに、優れた読み取り/書き込みパフォーマンスを必要とするものには適していません。
MySQL bin-log
MySQL固有のもう1つのオプションは、bin-logの使用です。 bin-logを格納する2番目のEBSボリュームをセットアップし（データベースへの追加の書き込みの影響を最小限に抑えるため）、それを使用するデータベースダンプと組み合わせて使用できます。 s3fsでこれを行うこともできますが、パフォーマンスが許容できる場合は実際にメリットがあります（rsyncはs3fsを直接使用するよりもおそらく優れており、できる限り圧縮する必要があります）。
しかし、もう一度、目的の考えに戻ります。上記の提案で何が起こるかを考えてみましょう。
- EBSボリュームにアクセスできません：
- RAID1-データにアクセスできないため、役に立たない
- bin-log-S3にエクスポートしない限り、役に立たない-おそらくそれを行ったとしても遅延
- インスタンスが予期せず終了します：
- RAID1-ディスクは使用可能ですが、整合性がありません。データベースがそれ自体で不整合から回復する場合があります
- bin-log-データにアクセスできる必要がありますが、最後のいくつかのイベントを確認する必要がある場合があります
- 誰かがrootとしてDROP DATABASEを実行します：
- RAID1-存在しないデータベースの完全なコピーが2つある
- bin-log-コマンドの直前までイベントを再生できるため、問題ありません。
したがって、実際には、RAID1はほとんど役に立たず、bin-logに時間がかかりすぎます。どちらも特定の状況ではメリットがあるかもしれませんが、アイデアのバックアップにはほど遠いです。
スナップショット
スナップショットは差分であり、データを含む（そして圧縮されている）実際のブロックのみを保存することに注意してください。 EBSボリュームとは異なり、20 GBのボリュームがあっても1 GBしか使用しない場合でも、「プロビジョニングされた」ストレージ（20 GB）に対して課金されます。スナップショットでは、使用した分だけが課金されます。スナップショット間でデータが変更されない場合、（理論的には）料金は発生しません。 （スナップショットはPUTS/GETSおよび使用済みストレージに対して課金されます）。
余談ですが、アプリケーションデータ（データベースを含む）をルートボリューム（既にセットアップされている可能性があります）に保存しないことを強くお勧めします。利点の1つは、うまくいけば、ルートボリュームの変更が最小限になることです。つまり、スナップショットの頻度が少なくなる（または変更が最小限になる）ことで、コストと使いやすさが低下します。
古いスナップショットはいつでも削除できることも言及しておく必要があります。たとえそれらが差分であっても、他のスナップショットには影響しません。つまり、スナップショットに割り当てられた各ブロックは、そのブロックを参照しているスナップショットがなくなるまで解放されません。
定期的なダンプの問題は、最初にダンプ間の時間（MySQLのbin-logを使用して対処される可能性があります）とリカバリの難しさです。大きなダンプをインポートして、bin-logからすべてのイベントを再生するには時間がかかります。また、ダンプの作成には、パフォーマンスへの影響がないわけではありません。間違いなく、そのようなダンプはスナップショットよりもはるかに多くのストレージを必要とする可能性があります。ほとんどの点で望ましいデータベースとスナップショット専用のEBSボリュームをセットアップします（ただし、スナップショットを作成すると、パフォーマンスにも多少の影響があります）。
スナップショットとEBSボリュームの利点は、他のインスタンスで使用できることです。インスタンスの起動に失敗した場合は、ルートボリュームを別のインスタンスに接続して問題を診断して修正するか、データをコピーして、わずか数分のダウンタイムでルートボリュームを切り替えることができます（インスタンスを停止し、デタッチします）。ルートボリューム、新しいルートボリュームを接続し、インスタンスを起動します）。これと同じ考え方が、2番目のEBSボリュームにデータを置く場合にも当てはまります。基本的に、カスタムAMIから新しいインスタンスを起動し、現在のEBSボリュームをそれに接続するだけです。これにより、ダウンタイムを最小限に抑えることができます。
（2つのEBSボリュームを使用して同じサーバー（マスタースレーブ）にMySQLの2つのコピーをセットアップし、スレーブをシャットダウンしてそのスナップショットを撮ることができるという議論をすることができます（そして私はおそらくそれをお勧めしません） EBSボリューム（ダウンタイムなしで一貫性があります）が、パフォーマンスコストはそれだけの価値がない可能性があります）。
AWSには自動スケーリングがあり、一定数のインスタンスを維持できます（その数が1の場合でも）。ただし、スナップショットからデプロイします。そのため、スナップショットが役に立たない場合、前提はあまり役に立ちません。 。
もう1つのポイント-単一のスナップショットから必要なだけインスタンスをデプロイできます（いつでも単一のインスタンスにのみ接続できるEBSボリュームとは異なります）。また、EBSボリュームはアベイラビリティーゾーン内での使用に制限されていますが、スナップショットはリージョン内で使用できます。
理想的には、スナップショットを使用すると、サーバーがダウンした場合、最後のスナップショットを使用して新しいスナップショットを起動できます。特に、ルートボリュームをデータから分離している場合、更新が不適切な場合、ダウンタイムが最小限に抑えられます（データを含むEBSボリュームを転送し、そのスナップショットを作成して、不整合が原因で破損する可能性のあるものをすべて保存します。
ちなみに、Amazonは、EBSボリュームの失敗率は、最後のスナップショット以降に変更されたデータの量とともに増加すると述べています。
最終的な推奨事項
- スナップショットを使用します-それらは素晴らしいです-それらはそれを引き起こすよりもはるかにダウンタイムを削減します
- データとルートボリュームを分離し、データベースを独自のボリュームに配置し、必要に応じて更新前にスナップショットを作成する
- Bin-logを使用して、可能な限り「ホット」に保ちます-これ（圧縮）をS3にアップロードします
- 実際にインスタンスからデータを取得していることを確認します（データがEBSボリューム上で変更されていなくても、ボリューム自体に一時的にアクセスできない場合があります）。
推奨読書：
（私は私が書きすぎたと思いますが、十分に言っていません-うまくいけば、あなたは読む価値のある何かを見つけます）。
ライブEBSボリュームのスナップショットを作成することは可能です ただし、ファイルシステムが一貫性のある状態にあり、スナップショットの開始中にフリーズするように注意する必要があります。すべてのファイルシステムがこれを可能にするわけではありませんが、それは確実に可能であり、私たち自身のバックアップソリューションの基礎です。
EBSスナップショットは、変更されたデータに対してのみ課金されるため、かなり安価であり、データ課金はそれ自体で非常に合理的です。ただし、これはブロックレベルの変更に基づいているため、かなり迅速に変更される可能性があることに注意してください。これはスナップショット間でも当てはまり、スナップショット間で変更されたデータのみが課金されます。コストを把握するために、スナップショットストレージに月額$ 10未満を支払い、毎日のスナップショットを作成して、過去7日間と過去数か月分の毎週のスナップショットを保持します。このスキームに従ったサーバーは2台あります（最大20のスナップショット、 20GBハードドライブ）。
Zmanda Cloud Backupのような安価で安価なバックアップソリューションはどうですか？これを使用して、約6台のサーバーと1台のSQL Serverをバックアップし、月額わずか約10ドルです。自己署名証明書を使用してデータを暗号化でき、s3を使用してデータを保存します（したがって、EC2からバックアップする場合はデータ転送料金はかかりません）。