Block / File / Object Storageへの再設計

ストレージを再設計するときは、最初から、

「Amazon EBSとAmazon S3のどちらが安いか」

「Amazon EFSとAmazon FSxのどちらが高速か」

と比較するのではありません。

最初に確認するのは、アプリケーションが現在のストレージをどのような意味で利用しているかです。

代表的には、

ブロックデバイスとして利用
↓
ブロックストレージ

ファイルとディレクトリとして利用
↓
ファイルストレージ

オブジェクトキーとAPIで利用
↓
オブジェクトストレージ

という違いがあります。

同じ容量のデータでも、必要なアクセス方式が異なれば適切なストレージモデルも異なります。

1. 容量より先にアクセスパターンを確認する

ストレージ選択では、容量、IOPS、スループット、料金だけを見てはいけません。

まず、OSからブロックデバイスとして見える必要があるか、ファイルパスやディレクトリ階層が必要か、複数クライアントが同じファイルを共有するか、NFSやSMBなどのファイルプロトコルが必要か、ファイルロックなどの意味が必要か、オブジェクトキーとAPIでアクセスできるか、を確認します。

例えば、

ワークロードA
OSがファイルシステムを作成する
↓
ブロックストレージ

ワークロードB
複数サーバーが同じ共有ディレクトリを利用
↓
ファイルストレージ

ワークロードC
アプリケーションがオブジェクトAPIでデータを読み書き
↓
オブジェクトストレージ

となります。

つまりアクセスパターンは、アクセス頻度や性能だけではなく、アプリケーションから見たストレージの利用方法そのものも含みます。

2. Amazon EBSではブロックデバイスとしての意味を維持する

Amazon EBSがEC2へブロックデバイスを提供することは既に確認済みです。

再設計で重要なのは、現在ブロックデバイスであることが、本当にアプリケーション要件なのかを確認することです。

例えば、OSがローカルファイルシステムを管理する、特定のブロックデバイスをアプリケーションが直接利用する、単一EC2へ密接に結び付いたデータである、という要件なら、Amazon EBSのアクセスモデルを維持する理由があります。

一方、コンピューティング側を複数インスタンスへ変更する場合は、現在のEBS中心の構成がそのまま成立するとは限りません。

3. EBSにはアベイラビリティーゾーン境界がある

Amazon EBSボリュームはアベイラビリティーゾーンに作成されます。

EC2へアタッチする場合も、EBSボリュームとEC2インスタンスは同じアベイラビリティーゾーンに存在する必要があります。

例えば、

AZ-AのEBS
↓
AZ-AのEC2

は成立します。

一方、

AZ-AのEBS
↓
AZ-BのEC2

へ同じボリュームをそのままアタッチすることはできません。

したがって、

単一EC2
+
単一EBS

だったワークロードを、

複数EC2
+
複数のアベイラビリティーゾーン

へ再設計する場合は、既存のストレージアクセス方式をそのまま維持できるかを確認する必要があります。

4. EBS Multi-Attachは一般的な共有ファイルシステムではない

Amazon EBS Multi-Attachでは、対応するEBSボリュームへ複数のEC2インスタンスからアクセスできます。

ただし提供されるのは、複数インスタンスから同じブロックデバイスへアクセスする機能です。

通常のext4やXFSなどを、

複数EC2
↓
同じEBS
↓
通常の共有ファイルシステム

として安全に利用できるようにする機能ではありません。

共有書き込みを行う場合は、クラスタ対応ファイルシステム、アプリケーション側の書き込み制御、I/Oフェンシング、などを含めて成立条件を確認します。

したがって、

共有データが必要
=
Multi-Attachを有効化すればよい

とは判断しません。

5. Amazon EFSは「共有ファイルの意味」が必要な場合に利用する

Amazon EFSがNFSベースの共有ファイルストレージであること自体は既習です。

再設計で見るべきなのは、コンピューティングを再設計した後も、複数クライアントから同じファイル名前空間を共有する必要があるかです。

例えば、

単一EC2
+
EBS上のローカルファイル

から、

複数EC2
+
複数のアベイラビリティーゾーン

へ変更する場合でも、各EC2が同じ共有ファイルを参照する必要があるなら、ファイルストレージへの再設計を評価します。

Amazon EFSのリージョナルファイルシステムは、同一リージョン内の複数のアベイラビリティーゾーンから利用できるため、このような共有ファイルアクセスの候補になります。

ここで中心となる判断は、「EFSはNFSである」ではなく、現在のローカルファイルという前提を、共有コンピューティング構成でも維持する必要があるかです。

6. Amazon FSxは必要なファイルシステム互換性を維持するために評価する

Amazon FSxの各ファイルシステムの個別特徴は既習です。

再設計では、単なる共有ファイルではなく、現在利用しているファイルシステム固有の意味を維持する必要があるかを確認します。

例えば、Windows固有の共有機能、ONTAPの機能、Lustreの特性、OpenZFSの機能、などがアプリケーションや運用要件に組み込まれている場合です。

この場合、

共有ファイルが必要
↓
すべてAmazon EFS

とはせず、必要な互換性を維持できるAmazon FSxを評価します。

7. FSx for ONTAPはファイルアクセス以外も提供できる

ストレージを、

EBS = ブロック
EFS / FSx = ファイル
S3 = オブジェクト

というサービス名だけで固定分類すると、実際のアクセス方式を見落とすことがあります。

例えばAmazon FSx for NetApp ONTAPでは、NFS、SMB、に加えて、iSCSIによる共有ブロックアクセスも利用できます。

既存NetApp ONTAP環境でiSCSI LUNを使用しているなら、

ブロックアクセス
↓
必ずAmazon EBS

とは判断しません。

FSx for ONTAPで、既存のアクセス方式、ONTAP固有の機能、共有ブロック要件、を維持できるかを評価できます。

重要なのは、サービス名ではなく、実際に利用するプロトコルとアクセス方式を見ることです。

8. Amazon S3へ変更する場合はオブジェクトアクセスへ適合できるかを見る

Amazon S3がオブジェクトストレージであること自体は既習です。

再設計で重要なのは、既存アプリケーションがオブジェクトアクセスへ適合できるかです。

Amazon S3では、

バケット
↓
オブジェクトキー
↓
オブジェクト

というモデルでデータを扱います。

これは、ブロックデバイス、通常の共有ファイルシステム、とは異なります。

したがって、大量のデータを保存できる、高い耐久性を持つ、大規模にスケールできる、という理由だけで、既存のファイルアクセスをAmazon S3へ置き換えるとは判断しません。

9. ファイルストレージとオブジェクトストレージではアプリケーションの前提が異なる

既存アプリケーションが、ファイルパス、ディレクトリ階層、ファイルロック、既存ファイルの更新、ファイルシステム固有の権限、などを前提としている場合があります。

一方、Amazon S3の通常のオブジェクトアクセスでは、オブジェクトキー、Amazon S3 API、を中心にデータを扱います。

したがって、

既存ファイルアプリケーション
↓
保存先だけS3バケットへ変更
↓
アプリケーション変更なし

が必ず成立するわけではありません。

現在のアプリケーションを大きく変更しないなら、必要なファイルシステムの意味を維持できるAmazon EFSやAmazon FSxなどを評価する必要があります。

ファイルアクセス自体をオブジェクトアクセスへ変更する場合は、単なる保存先変更ではなく、アプリケーション変更を伴う別のモダナイゼーション判断になります。

10. オブジェクトストレージが自然なワークロードもある

一方、アプリケーションがもともと、画像、動画、ログ、バックアップファイル、データレイク上のデータ、などを、

オブジェクトキー
+
API

で扱っている場合は、Amazon S3のオブジェクトモデルと自然に適合します。

重要なのは、

データの種類

だけではなく、アプリケーションがそのデータへどのようにアクセスするかです。

同じ画像データでも、Amazon S3 APIから取得する場合と、共有ファイルパスから開く場合では、必要なストレージモデルが異なります。

11. コンピューティング構成を変えるとストレージモデルも再評価が必要になる

既存環境では、

EC2 1台
+
EBS上のローカルファイルシステム

で問題がなかったワークロードを考えます。

ターゲットで、

EC2複数台
+
複数のアベイラビリティーゾーン

へ変更し、すべてのEC2が同じデータを参照する必要があるなら、各EC2へ個別EBSを配置するだけでは、同じファイル名前空間を共有するという新しい要件を満たせません。

また、1つのEBSボリュームを複数のアベイラビリティーゾーンへそのままアタッチすることもできません。

この場合は、現在必要なファイルシステムの意味を維持するなら共有ファイルストレージ、アプリケーションを変更してオブジェクトアクセスへ移行できるならオブジェクトストレージ、などを評価します。

つまり、コンピューティングアーキテクチャの変更によって、適切なストレージアーキテクチャも変わる可能性があるということです。

12. ブロック / ファイル / オブジェクトの選択軸

この対応だけで最終決定するのではなく、プロトコル、共有範囲、更新方法、ロック、ファイルシステム互換性、アベイラビリティーゾーン境界、アプリケーション変更の可否、まで確認します。

13. 判断フロー

現在のストレージアクセスパターンを確認
↓
ブロック / ファイル / オブジェクトのどの意味が必要か
↓
共有アクセスが必要か
↓
必要なプロトコル・ファイルシステムの意味を確認
↓
アベイラビリティーゾーン境界を確認
↓
コンピューティング構成変更後も現在方式で成立するか
↓
アプリケーション変更なしで成立するか
↓
Amazon EBS / Amazon EFS / Amazon FSx / Amazon S3を評価
↓
必要なストレージモデルを確定

重要なのは、サービス名から選ぶのではなく、アプリケーションが必要とするストレージの意味から選ぶことです。