なぜAWS EBSボリュームをバックアップすべきか（その方法とは）

EBSはAWSが提供するブロックストレージサービスです。EC2インスタンスを運用している場合、サーバーのストレージディスクとして確実に使用しています。ただし、障害から安全ではないため、定期的なバックアップは必ず行うべきです。

"フォールトトレラント"は安全であることを意味しない

もちろん、EBSはバックエンドでかなりの耐障害性を備えています。AWSはJBODアレイを運営している野蛮人の集まりではありません。彼らは単一のドライブの故障を考慮に入れて計画していますので、一つの悪いドライブがサーバーをダウンさせることはありません。

しかし、EBSの故障は発生する可能性があり、実際に発生しています。EBSボリュームの年間故障率（AFR）は0.1%から0.2%の間です。これは多くはなく、単一のハードドライブの約4%と比べると非常に低いですが、ゼロではありません。EBSボリュームが故障することはまずないでしょうが、多数運用している場合には、いくつかの問題に遭遇する可能性があります。

簡単な解決策は、バックアップを行うことです。EBSはこのための素晴らしいツールを提供しています---スナップショット機能です。スナップショットを作成することができ、これはS3に保存されるバックアップとして機能し、より耐久性があります。EBSの障害が発生した場合、バックアップから復元できます。これを自動化する必要はありません。EBSライフサイクルマネージャーがそれを管理できますが、デフォルトでは有効になっていません。当然、S3にデータを保存するための追加ストレージコストが発生しますが、EBSよりも安価です。

AWSはこの事実を隠そうとはせず、定期的なスナップショットバックアップの実施を推奨しています。ほとんどの人も一般的にバックアップを推奨しますが、クラウドの魔法に取りつかれてこの事実を忘れてしまうことは簡単です。結局のところ、これは他の誰かのコンピュータに過ぎず、他のコンピュータと同じように故障する可能性があります。この極端な例として、2019年9月にAWSのUS-EAST-1データセンターで発生した停電と発電機の故障があり、EBSサーバーとそのデータが消失しました。

高可用性アーキテクチャとクラウドコンピューティング全体の背後にある主な理由は、孤立した障害が必然的に発生した場合に、アプリケーション全体がダウンしないようにすることです。最初に障害を防ぐための対策を講じるべきですが、時にはハードドライブのように、ハードウェアの問題であり、コードで修正できるものではありません。

一方、S3は非常に安全で、耐久性は99.999999999%（つまり11個の9）です。S3に10,000,000個のオブジェクトを保存する場合、平均して10,000年に1つのオブジェクトが失われることを期待できます。これは、EBSとは異なり、S3は最低3つのアベイラビリティゾーン全体に完全に複製されており、各ゾーン内のドライブ障害を常に監視しているためです。もし全てのデータセンターが炎上してしまったとしても、あなたのS3バケットやその中のスナップショットはまだ安全であるはずです。

EBSスナップショットはどのように機能しますか？

EBSスナップショットは増分バックアップです。次のバックアップでは変更されたデータのみを保存するため、定期的にスナップショットを作成しても莫大なストレージコストがかかることはありません。

それらをオンにするのはかなり簡単です。EC2コンソールからサイドバーのElastic Block Store > ライフサイクルマネージャーに移動し、新しいポリシーを作成します。

このポリシーが適用されるタグを指定する必要があります。これは、単一のEBSボリュームの名前であるか、すべてに適用される包括的なタグである可能性があります。

このポリシーのスケジュールやスナップショット保持ポリシーを設定できます。通常、長期間のバックアップを保持する必要はありませんので、スナップショットの頻度に応じて少数を保持するのが良いでしょう。

高可用性に真剣に取り組んでいるなら、迅速なスナップショットの復元を有効にすることもできます。これにより、復元が完全に瞬時に行えるようになります。しかし、これはかなり高価なので、誰もが有効にすべきものではありません。