こんにちは、つかさです。
今回はEBS,FSxまわりに関して記事を書いていこうと思います。
EBS,FSxは他のサービスと比較して理解しやすいですが、だからこそ試験では絶対に落としたくないですよね
確実に取れるよう理解を深めていきましょう！
基本構成
- 問題文
- 答え
- なぜその答えなのか
- その答えを理解するための周辺知識
EBS
問題
バックアップソフトウェアをそのままAWSへ移行します。データボリュームはEBSセカンダリボリュームで作成します。数TBのボリュームを扱うのでとにかくコスト下げたいです。最適なEBSボリュームタイプは何ですか？答え
Cold HDDになります。答えの理由
要件として、今回セカンダリボリュームであり、最もコストの低いEBSボリュームがあるので、Cold HDDが最適です。今回の問題はEBSボリュームタイプの使い分けについてきちんと理解しておくことが大切です。
EBSボリュームタイプ
まず初めに、大きく2つに分類することができます。SSDとHDDです。
| 役割 | 用途 | |
|---|---|---|
| SSD | 高速なI/O性能が必要なアプリケーションに最適。 | ルートボリューム |
| HDD | 低コストで大量のデータを保存する場合や、頻繁にアクセスされないデータを扱う場合に最適 | セカンダリボリューム |
ルートボリューム
インスタンスの起動時にOS（オペレーティングシステム）がインストールされているボリューム。システムの起動と基本的な運用に必要。
セカンダリボリューム
ルートボリューム以外でインスタンスに接続される追加のEBSボリューム。データの格納や特定のアプリケーション要件に合わせて利用される。
さらに細く見ていくと、それぞれ２つに分類することができます。
SSD
- 汎用SSD
最も一般的に使用されるSSDボリュームで、バランスの取れた価格とパフォーマンスを提供します。現在、gp2とgp3ボリュームがgp3の方が新しく、IOPSとスループットがカスタマイズ可能です。
IOPS
ストレージデバイスが1秒間に実行できる読み書き操作の総数を指す指標
| 役割 | |
|---|---|
| gp2 | 最大性能はボリュームで確保しているストレージサイズによって決まる。1GBあたり3 IOPSが割り当てられます。最小値は100 IOPSです。 |
| gp3 | IOPSを設定することで決まる。3000 IOPSを超えた分に関しては追加料金が発生。最大値は16000 IOPSです。 |
- プロビジョンドIOPS SSD
高いパフォーマンスが必要なケースに最適。ここでいう高いパフォーマンスとは、具体的にいうと、16000 IOPS以上の性能のこと。最大で65000 IOPSまで設定できます。
HDD
-
スループット最適化 HDD
ビッグデータ、データウェアハウス、ログ処理など、大量のデータを連続的に読み書きするワークロードに最適。 -
Cold HDD
頻繁にはアクセスされないが、保存が必要な大量のデータに最適。最もコスト効率の良い。
他のサービスなどを勉強していると、似たような言葉が出てきて、あれ？何だっけ？と頭の中で混乱してきてしまう時もあるかもしれません。定期的に見返し、頭の中を整理していきましょう！
問題
EBSボリュームにデータを保持しているオンプレミスから移行したアプリケーションがあります。このアプリケーションは1つのAZで運用しています。AZ障害に対応するように指示がありました。RPOは6時間です。どのような方法が最適ですか？答え
Data Lifecycle Managerを使用して6時間ごとにスナップショットを作成する。答えの理由
Data Lifecycle Managerを使用することで、簡単にAZ障害対応ができます。対応の流れとして、指定したスケジュールで自動的にEBSボリュームからスナップショットが作成され、S3に保存されます。S3はリージョン配下なので、AZ障害をの影響を受けません。障害が発生した場合は、S3にあるスナップショットからほかのAZを指定して、ボリュームを復元することができます。この問題で理解しておくべきことは、EBSスナップショットです。
EBSスナップショット
EBSボリュームは内部的にAZ内でレプリケートされています。このことで1つのハードウェア障害があったとしても影響がないように設計されています。しかしAZ障害には対応してません。よって継続的にデータを保存して保存する場合は、定期的なスナップショットの作成を行います。このスナップショットのライフサイクル管理を自動化するためのツールとしてData Lifecycle Managerがあります。
Data Lifecycle Manager
このサービスを利用することで、ユーザーはデータのバックアップ、保持、および削除ポリシーを定義し、それらを自動的に実行することができるようになります。
- 利用方法
AWS Management Console、CLI、またはSDKを使用してライフサイクルポリシーを設定します。ポリシーはJSON形式で記述され、どのEBSボリュームが対象か、スナップショットの作成頻度や保持期間、スナップショットの削除ルールなどの詳細を指定します。
今回の問題ではAZ障害対応でRPOが6時間の２点の要件から、Data Lifecycle Managerを利用し、
スナップショットの作成頻度を6時間と設定してあげることが最適になります。
RPO
データ復旧計画における重要な指標の一つであり、災害や障害が発生した際に失われることが許容されるデータの量を時間で表したもの
FSx
問題
複数のWindows,Linuxサーバーをオンプレミスから複数のAZへ移行しました。共通のファイルストレージもあるので移行する必要があります。AWSでどのように構築しますか？答え
FSx for Windows File Serverを使用する答えの理由
FSx for Windows File ServerはSMBプロトコルを使用をサポートしていてWindows,Linux環境でのファイル共有ができる。Saaを勉強している人なら一度は見たことがあるんではないでしょうか？
Windowsとファイルストレージという二つの単語からFSx for Windows File Serverを導き出せる人も多いかもしれません。しかし、ひっかけ問題や深い理解を求められる問題に出会った時、間違ってしまうかもしれません。なのでこの機会にFSxについて理解を深めていきましょう!
FSxを理解する上でまずEFSを理解することが大切です。EFSと比較することでより理解が深められると思っています。
EFS
一言でいうと、複数のAZにわたって共通のファイルストレージを簡単に構築できるAWSサービスです。
EFSの仕組み
-
マウントターゲットの自動配置
EFSは各AZに自動的にマウントターゲットを配置し、ユーザーやアプリケーションがどのAZに存在していても、同じファイルシステムにアクセスできるよう行ってくれる。 -
レプリケーションの自動化
AZ障害などが発生した際に、スムーズにフェイルオーバーできるよう他のAZにデータを複製してくれる。
この２つともユーザーが意識することなく、EFSが行ってくれます! ありがたい！
EFSの仕組みのユースケース
Webサーバー、コンテンツ管理システム、データ分析アプリケーションなど、共有データアクセスが必要な様々なアプリケーションに最適です。つまり汎用的で簡単に使用することができます。
一方で、EFSは色々とやってくれるのでカスタマイズ性が低いとも言えます。そこでカスタマイズ性の高いファイルストレージを構築したい時に使用するのがFSxになります。
FSx
EFxは２種類存在します。
- Amazon FSx for Windows File Server
こちらは主にWindowsベースのアプリケーションや環境で使用されます。
- なぜEFSではダメなのか？
理由
EFSは`NFSプロトコル`が使用されているが、windows環境では`SMBプロトコル`がメジャーです。`SMBプロトコル`を使用することで、Directoryの統合、ファイルロック、Windowsアクセスコントロールリスト（ACLs）など、Windows特有の機能を利用したファイルストレージ環境を構築したいから２. こちらは主に高性能コンピューティング（HPC）、ビッグデータ分析、機械学習などの計算集約的なアプリケーションで使用されます。
- なぜEFSではダメなのか？
理由
複数AZにわたるアクセスというよりも基本的に1つのAZ内での運用が中心です。Amazon S3と連携してデータを保持し、計算リソースに応じてデータを動的にロードするのが一般的で高スループットや低レイテンシのファイルアクセスを提供することに焦点を当てているから二つとも汎用的に使用するものではなく、特定の条件や要件によって使用されることがわかったと思います!
カスタマイズ性が高い分、可用性などを考慮した設定を手動で行なわなければないません!
まとめ
それぞれメリット、デメリットがあったと思います！２つのサービスの違いを理解した上で、要件に対してのベストなサービスを答えられるように頑張りましょう!
最後に
読んでいただきありがとうございました！
これからも自分のペースで記事を更新したり、新たな記事を書いていこうと思うので是非見ていただけたらなと思います！