Amazon EBS・EFSとストレージの使い分けのシナリオ判断

保存先を選ぶ提案や障害対応を読み、EBS・EFS等の条件に照らして判断します。設定を変えれば直る問題と、方式そのものが要件に合わない問題を区別して説明します。

この単元で学ぶこと

業務要件に適合する保存方式を選ぶ
停止・障害・復元の条件を評価する
容量・費用・権限を具体例で切り分ける

本文解説

1. EC2上のDB用ディスク EC2で自社管理DBを動かし、OSからブロックデバイスとして扱う保存先が必要な事例ではEBSを検討します。容量だけでなくIOPS、スループット、遅延とインスタンス側の性能条件を確認します。バックアップ、パッチ、DBの設定等をサービスが全て代行するという意味ではありません。

2. 台数が変わるWebアプリ LinuxのWebサーバーが増減し、同じNFSディレクトリから投稿画像を扱いたい場合はEFSが候補です。別AZでも稼働する構成で保存先にも多AZの要件があればRegionalを比較します。サーバー個別のEBSへ同じディレクトリ名を作るだけでは内容は共有されません。

3. 消えてよい一時結果処理途中の再生成可能データを、EC2ホストに付属する低遅延な一時領域へ置くならInstance Storeの消失条件を受け入れます。停止・終了等の後にも必須の注文データまで同じ場所へ置かないようにします。単なる再起動と停止を区別し、再実行できる手順を用意します。

4. AZ障害からの復旧 AZ AのEBSを使えない場合に、取得済みの通常のリージョン内スナップショットからAZ Bへ新規ボリュームを作る方法を検討します。復旧点取得後の変更は別途復元できる仕組みがなければ含まれません。ボリュームの復元、接続、アプリ起動と検証に必要な時間も見積もります。

5. 容量の計算同じ種類・性能条件で100GiBのEBSを三つ保持すれば、確保容量の合計は300GiBです。各ボリューム内の使用量が20GiBでも、確保容量が自動で合計60GiBへ縮むという意味ではありません。この比較は容量部分の前提であり、性能やスナップショット等の費用は別に扱います。

6. マウント後の権限 EFSのディレクトリは見えるのにアプリが書けないなら、利用するユーザーID、グループ、モードや採用したIAM認可等を確認します。経路がない場合と、到達後に操作が拒否される場合では直す場所が違います。NFSの全通信を開けるだけで全てのファイル権限を解決しようとしないようにします。

7. 終了前の確認検証用EC2を終了する前に必要なEBSの削除設定と復旧点を確認します。スナップショットがある場合も、取得後の更新やアプリ整合性を確認します。保存費を下げるため削除する作業と、必要なデータを守る作業を一つの手順へまとめ、復元した結果も検証します。

8. 提案を評価する安い一つの単価だけを示した提案には、互換性、保存範囲、復旧時間、必要性能、保護の費用を補います。例えばOne ZoneとRegionalは同じNFSでもAZ障害の要件が違います。再生成可能なデータと唯一の原本を分け、失える範囲を明らかにしてから選定します。

図解

障害からの復旧を段階で検証 — 復旧点の存在だけで、最新状態や即時の再開は保証されません。

重要ポイント

要件にあるプロトコルと障害範囲を優先する。
EBSの確保容量とファイル使用量を混同しない。
復旧点以後の変更と復旧時間を確認する。

間違えやすい点

同じディレクトリ名なら別EBSの内容も共有されると思う。
バックアップがあるだけで最新状態へ即時に復帰できると考える。

用語解説

確保容量: EBSボリュームとして用意したサイズ。内部のファイル使用量とは異なる。
再生成可能: 失われた後も元データや手順から作り直せる性質。
アプリ整合性: アプリが正しい状態として利用できるようデータが揃っていること。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。