【ITニュース解説】壊れたEC2からEBSが復旧できるか検証してみた

クラウド上でシステムを運用する際、もしサーバー自体が故障してしまったら大切なデータはどうなるのか、という疑問はシステムエンジニアを目指す上で避けて通れないテーマだ。今回の検証は、まさにその疑問に対し、実際に手を動かし具体的な解決策を探る非常に実践的な内容である。

まず、基本的な用語から説明する。クラウドサービスの一つであるAWS（アマゾン ウェブ サービス）において、EC2（Elastic Compute Cloud）とは、インターネット上に用意された仮想的なコンピューター、つまりサーバーのことだ。このEC2インスタンスを起動することで、私たちはインターネット上でプログラムを実行したり、ウェブサイトを公開したりできる。EC2インスタンスは、あたかも自分の手元にある物理的なパソコンのように利用できるが、実体はAWSのデータセンター内に存在している。

次に、EBS（Elastic Block Store）についてだ。これはEC2インスタンスに接続して使うストレージ、つまりデータを保存するための記憶装置である。自分のパソコンで言えば、ハードディスクやSSDのようなものだと考えるとわかりやすい。EBSボリュームは、EC2インスタンスの「Cドライブ」にあたる部分としてOSやプログラムがインストールされる「ルートボリューム」と、ユーザーが作成したデータやアプリケーションのデータが保存される「Dドライブ」にあたる「データボリューム」に分けられることが多い。これらは物理的には別々のEBSボリュームとして管理され、用途に応じてEC2インスタンスにアタッチ（接続）したり、デタッチ（取り外し）したりできる点が重要だ。

今回の検証で問われたのは、「もしEC2インスタンスのルートボリューム、つまりOSが壊れて起動できなくなった時、リアルタイムで更新されていたデータボリュームは無事に救い出せるのか？」という切実な問題だった。この疑問に答えるため、実際にEC2インスタンスを立ち上げ、データボリュームを準備し、意図的にOSを破壊するという大胆な検証が行われた。

検証の手順は次の通りだ。まず、AWS上に新しいEC2インスタンスを起動する。これは、検証用の仮想サーバーを用意するステップだ。次に、追加のEBSボリュームを作成し、これをデータボリュームとしてEC2インスタンスにアタッチする。アタッチしたEBSボリュームは、そのままではOSから利用できないため、ファイルシステムを作成し、特定のディレクトリにマウントするという作業が必要になる。これは、新しいハードディスクをパソコンに接続した際に、フォーマットしてドライブとして認識させるのと同じ感覚だ。

データボリュームの準備ができたら、その中に適当なファイルを作成し、内容を継続的に更新するように設定する。これは「リアルタイムで更新されている」という状況を再現するためだ。例えば、ログファイルやデータベースのファイルなどが常に書き込まれている状態を想定している。そして、最も重要なステップが、EC2インスタンスのルートボリュームを意図的に破損させることだった。具体的には、「rm -rf /」という非常に危険なコマンドを実行した。このコマンドは、ルートディレクトリ（システムの最上位）以下のすべてのファイルとディレクトリを強制的に削除するというものであり、通常は絶対に行ってはならない操作だ。これを実行すれば、OSは起動に必要なファイルを失い、確実に機能不全に陥る。

予想通り、このコマンドの実行後、EC2インスタンスは停止し、二度と起動できない状態になった。OSが壊れてしまったため、インスタンスに接続することも不可能だ。しかし、ここで検証の核心が問われる。壊れたEC2インスタンスから、先ほどリアルタイムで更新していたデータボリュームをデタッチし、別の新しいEC2インスタンスにアタッチしてみるのだ。新しいインスタンスにデータボリュームをアタッチした後、再びマウントする作業を行う。そして、マウントしたデータボリュームの中身を確認する。

検証の結果、驚くべきことに、ルートボリュームを破壊され起動不能になったEC2インスタンスから取り外したデータボリュームは、完全に無傷であり、以前書き込んでいたファイルも全て正常に残っていた。このデータボリュームを新しいEC2インスタンスに接続し直すことで、中に保存されていたデータは問題なく復旧できたのだ。

この検証から得られる教訓は非常に大きい。まず、EC2インスタンスのルートボリュームとデータボリュームは、物理的にも論理的にも独立しているという事実だ。OSが格納されているルートボリュームが壊れても、データが格納されているデータボリュームは影響を受けない。これにより、もしサーバーのOS部分に何らかの障害が発生し起動できなくなっても、データボリュームを切り離して別の正常なEC2インスタンスに付け替えることで、大切なデータだけは救い出せる可能性があることが示された。

ただし、注意すべき点もある。OSが破壊されたEC2インスタンスは、たとえデータボリュームが無事であったとしても、そのインスタンス自体はもはや使用できない。OSの再インストールや修復は現実的ではなく、事実上、新しいEC2インスタンスを起動し直す必要があった。つまり、サーバーの「買い替え」が必要になるということだ。

この検証は、システムを設計・運用する上で、データとOS、そしてアプリケーションをいかに分離して考えるかという重要な視点を提供する。データの保護という観点からは、OSの障害でデータが失われない仕組みは非常に心強い。しかし、EC2インスタンスそのものの復旧コストや、一時的なサービス停止のリスクを考えると、やはりEBSスナップショット（EBSの特定の時点の状態をバックアップする機能）や、S3（大量のデータを保存できるストレージサービス）へのデータ転送といった、定期的なバックアップの仕組みを構築しておくことが、究極的なデータ保護とシステム運用の安定性につながることを強く示唆している。この実証は、システムエンジニアがクラウド環境で障害対応やデータ保全を考える上で、非常に貴重な知見となるだろう。