Taiki's Blog

ビジネスやテクノロジー、社会問題の今後に迫ります

【ブログ移行計画③】AWSのバックアップ機能と周辺知識

こんにちは、Taikiです。

前回はAWS上のWordPressに投稿データを移行しました。

vtaiki.hatenablog.com

移行後は大切なデータを保護したい、そこで今回はAWSのバックアップ機能とその周辺知識に触れます。主に実機ベースで得た知見ですが、私見込のため、情報の偏りをご留意ください。情報に誤りがあれば適宜修正したいと思います。

目次はこちらです。

AWSの基本的なコンポーネント

まずはAWSの基本的な構成要素について説明します。

  • AMI:インスタンスを起動するためのテンプレート
  • EC2:インスタンスと呼ばれる仮想サーバー
  • EBS:ボリュームと呼ばれる物理ディスクみたいなもので、システム領域やデータ領域はここに保存される
  • S3:スナップショットで作成されたデータはここに保存される

大雑把に言うと、AWSのサーバーはインスタンスとボリュームで構成されます。インスタンスはサーバーを起動するために必要な情報が保存されています。ボリュームには、サーバーの稼働に必要なデータが保存されています。そのため、インスタントの情報とボリュームのデータに矛盾があるとインスタントの起動に失敗します。

下図では、インスタントが継承されたルートデバイス名と、そのインスタンスにアタッチされたボリュームが持つルートデバイス名に差異があると、起動に失敗することを表しています。

f:id:vtaiki:20191111234715p:plain

では、そもそもインスタンスは先の情報をどこから取得するのでしょうか。それはAMI(Amazon Machine Imange)からです。このAMIからインスタンスを起動するタイミングで必要な情報を取得します。AMIとはインスタンスを作成するためのテンプレートです。

S3は、スナップショットを作成したデータが保存される、バックアップの保存領域です。VPCとは別の場所にあるため、オフサイトバックアップ先と捉えても良いでしょう。S3にはバックアップ以外にも用途があり、例えば、動画や静止画などの大容量データをここから配信することで、迅速にコンテンツを配信したり、料金を節約できます。その理由はEBSよりS3の料金が安いからです。

S3標準ストレージ:0.023USD/GB(最初の50GB)

EBS東京リージョン: 0.12USD/GB

出典:AWS(2019年11月9日時点)

バックアップの仕組み

AWSのサーバーはインスタンスとボリュームで構成されていると先にお伝えしました。そうすると、バックアップ対象は、インスタンスとボリュームになりますが、インスタンスはAMIというイメージを作成し、ボリュームはスナップショットを作成することで、バックアップを取得できます。

下図では、サービスとそれに相当する機能を一覧にしています。赤の矢印はバックアップ、青の矢印は復元の流れを表しています。

f:id:vtaiki:20191110181128p:plain

インスタンスとボリュームのバックアップ方法

インスタンスのバックアップ方法は2通りあります。1つはインスタンスからイメージを作成する方法、もう1つはインスタンスからスナップショットを作成する方法です。

f:id:vtaiki:20191110192923p:plain

どちらもインスタントの停止は不要ですが、内部でDBが動いている場合は、データの不整合が起こりやすいので停止して作成した良いと思います。インスタンスからのイメージ作成は基本手動ですが、クラウド事業者が提供するサービスを使用すれば自動作成も可能になります。例えば、クラウドワークスが提供するCloudautomatorだとそれが可能です。

インスタンスからスナップショットを作成する場合、手動と自動どちらでも可能です。自動だとライフサイクルマネージャで管理が可能です。

では、イメージ作成、スナップショット作成、どちらが良いかという話ですが、イメージ作成の方が復元の手順が1つ減ります。スナップショットからインスタンスを作成することはできません。まずAMIなるイメージを作成することになります。イメージを作成するまでには少し時間がかかるため、迅速に復旧したい場合は、イメージ作成の方が良いでしょう。

ちなみに、ボリュームのバックアップ方法はスナップショットの一択です。スナップショットを作成する時は、インスタンスとボリュームのどちらかを選択する必要があります。後にボリュームを作成する場合は、そのまま「Volume」を選び、イメージを作成する場合は「Instance」を選びます。

f:id:vtaiki:20191112003749p:plain

インスタンスとボリュームが壊れた時の復元シナリオ

こちらはインスタンスが破損した時に、スナップショットから復元する時の手順です。

  1. 既存インスタンスの停止
  2. 既存インスタンスから既存ボリュームをデタッチ
  3. スナップショットからAMI作成
  4. AMIから新規インスタンス起動、停止
  5. 新規インスタンスから新規ボリュームをデタッチ
  6. 既存ボリュームを新規インスタンスにアタッチ
  7. 新規インスタンスの起動、動作確認

こちらはボリュームが破損した時に、スナップショットから復元する時の手順です。

  1. 既存インスタンスの停止
  2. 既存インスタンスから既存ボリュームをデタッチ
  3. スナップショットから新規ボリューム作成
  4. 新規ボリュームを既存インスタンスにアタッチ
  5. 既存インスタンスの起動、動作確認

 まとめ

最近は、VPNサービスを提供する ネットワークベンダーがAWSリセールサービスも提供しており、そのサービス内に自社製のバックアップ機能が付与されていたりもします。

流石に個人ユースでは、そこまでの機能は不要かと思いますが、インスタンスとボリュームの違いが分かれば、どの程度の間隔でどうバックアップ取得すれば良いかも見えてきます。例えば、インスタンスに保存される情報(インスタンスタイプやアベイラビリティゾーン、アーキテクチャやプラットフォーム等)が変更されることは殆どありませんが、ボリュームに保存されるデータ(ブログやWebサイト)はよく変更されるでしょう。そうすると、インスタンスは手動で適宜バックアップ、ボリュームは毎時自動バックアップという方針も出てきます。

じゃあインスタンスで自動バックアップを取得しておけば良いのではという話にもなりますが、そうするとサイズや料金も変わってきます。今回はあまり深追いせずにこの辺で。