Storage Performanceの選択

ゴール

ストレージ性能を選ぶときは、

IOPSが高いサービス
スループットが高いサービス

という単純な比較はしません。

まず、

どのようにデータへアクセスするのか
↓
何を性能目標としているのか
↓
そのアクセス方法と性能特性を
満たせるストレージはどれか

と判断します。

例えば、

小さいランダムI/Oを
大量に処理したい

場合と、

数TiBのデータを
大きなI/Oで連続転送したい

場合では、同じストレージを選ぶとは限りません。

さらに、

オブジェクトAPIでよいのか
EC2へブロックデバイスが必要か
複数サーバーから同じファイルを共有するのか
SMB / NFS / Lustreなど特定のアクセス方式が必要か

も重要です。

1. 最初にアクセスパターンを分解する

ストレージを選ぶ前に、少なくとも次を確認します。

アクセス方式
+
I/Oサイズ
+
ランダム / シーケンシャル
+
読み取り / 書き込み比率
+
同時アクセスするクライアント数
+
共有が必要か
+
負荷が一定か急増するか

例えば、

8 KiB
ランダム
数万回/秒

ならIOPSが重要です。

一方、

1 MiB前後
シーケンシャル
大容量スキャン

ならスループットが中心になります。

すでに定義した性能指標を、ここではストレージ選択条件として使用します。

2. 性能数値だけでサービスを決めない

例えば、

30,000 IOPSが必要

という情報だけでは不十分です。

同時に、

EC2からブロックデバイスとして使う？
複数ノードでファイル共有する？
オブジェクトAPIでアクセスする？
Windows SMBが必要？
HPC向けの並列ファイルアクセス？

を確認します。

したがって、

性能目標
+
アクセスパターン
+
必要なアクセスインターフェイス

を組み合わせて判断します。

3. Amazon S3はオブジェクトAPIで大規模にアクセスする場合の候補

アプリケーションが、

PUT
GET
HEAD
DELETE

などのAmazon S3 APIでデータを扱える場合、Amazon S3を評価できます。

典型的には、

静的コンテンツ
データレイク
バックアップデータ
分析対象オブジェクト
大量の非構造化データ

などです。

Amazon S3は高いリクエストレートへ自動的にスケールできます。

ここで重要なのは、

Amazon S3
=
EC2へアタッチする
通常のブロックデバイス

ではないことです。

アプリケーションがオブジェクトAPIを利用できること自体が、重要なアクセス条件になります。

4. 低レイテンシーのオブジェクトアクセスではS3 Express One Zoneも評価する

通常のAmazon S3よりも低いオブジェクトアクセスレイテンシーが重要で、

コンピューティングと
ストレージを同じAZへ配置できる

+

単一AZという条件を
設計上受け入れられる

場合は、

S3 Express One Zone

を評価できます。

S3 Express One Zoneは、

ディレクトリバケット
+
単一AZ
+
一貫した1桁ミリ秒の
読み取り / 書き込みレイテンシー

を特徴とします。

したがって、

オブジェクトAPIが必要
+
アクセスレイテンシーを
さらに下げたい

という判断で候補になります。

5. Amazon EBSはEC2からブロックストレージとして使う

EC2上のOSやアプリケーションが、

ブロックデバイス

として永続ストレージへアクセスする場合、Amazon EBSを評価します。

例えば、

ファイルシステム
データベースファイル
トランザクションデータ
ブートボリューム

などをEC2から扱う構成です。

EBSでは、

小さいランダムI/O
大きいシーケンシャルI/O
必要IOPS
必要スループット
必要レイテンシー

によって、適切なボリュームタイプが変わります。

6. 一般的なSSDブロック要件ではgp3を最初に評価する

汎用 SSD（gp3）は、

トランザクション処理
仮想デスクトップ
中規模データベース
ブートボリューム
開発環境
一般的なアプリケーション

など、幅広いワークロードに利用できます。

現行のgp3では、ボリューム容量とは別に、

IOPS
スループット

を必要量へ設定できます。

最大性能は、

80,000 IOPS
2,000 MiB/秒

です。

したがって、

EC2用ブロックストレージ
+
小さいランダムI/O
+
通常〜高性能のSSD

なら、まずgp3を評価します。

7. 持続的な非常に高いIOPSではio2 Block Expressを評価する

プロビジョンド IOPS SSD（io2）Block Expressは、

非常に高いIOPS
+
持続的なI/O性能
+
低いI/Oレイテンシー

が必要なワークロード向けです。

現行仕様では、対応するNitroベースのEC2で、

最大256,000 IOPS
最大4,000 MiB/秒

をサポートします。

また、16 KiB I/Oでは、

平均500マイクロ秒未満

のレイテンシーを実現するよう設計されています。

例えば、

100,000 IOPS超
+
小さいランダムI/O
+
レイテンシーにも厳しい

という要件なら、

gp3ではなく
io2 Block Expressを評価

という判断になります。

8. EBSで大きなシーケンシャルI/Oならst1を評価する

スループット最適化 HDD（st1）は、

IOPS

よりも、

スループット

を重視するHDDボリュームです。

向いているのは、

ETL
ログ処理
データウェアハウス
大規模な連続読み書き
大きなデータセットのスキャン

などです。

典型的には、

大きなI/O
+
シーケンシャル
+
頻繁にアクセス

というアクセスパターンです。

逆に、

小さいランダムI/O

を大量に処理する場合は、st1ではなくSSD系を評価します。

9. Cold HDDは別の選択軸を持つ

Cold HDD（sc1）も、大きなシーケンシャルI/O向けのEBS HDDです。

性能面では、

st1
→ 最大500 MiB/秒

sc1
→ 最大250 MiB/秒

という違いがあります。

ただし、sc1の主要な選択条件には、

データへのアクセス頻度が低い
+
ストレージコストを最小化したい

ことも含まれます。

そのため、

必要スループットが
250 MiB/秒以下
↓
必ずsc1

とは判断できません。

ここでは、

st1 / sc1
→ どちらも大きな
   シーケンシャルI/O向け

st1
→ 頻繁にアクセスする
   スループット重視のワークロード

sc1
→ 低頻度アクセスという
   別の選択条件も持つ

という位置付けだけ押さえます。

ストレージのアクセス頻度やコストを中心とした最適化判断とは分けて考えます。

10. EBS性能はボリュームだけでは決まらない

例えば、

gp3
80,000 IOPS

を設定しても、

EC2インスタンス側がそれだけのAmazon EBS性能を提供できなければ、実際には到達できません。

概念的には、

EBSボリューム側の性能上限

と

EC2インスタンス側の
Amazon EBS性能上限

↓
低い方が実効性能を制限

します。

そのため、

IOPSが足りない
↓
ボリュームのIOPS設定だけ増やす

とは判断しません。

ボリューム
+
EC2側のAmazon EBS帯域幅 / IOPS

の両方を確認します。

11. Amazon EFSは複数クライアントで共有するNFSファイルストレージ

複数のLinux系コンピューティングから、

同じファイル
同じディレクトリ

へNFSで同時アクセスしたい場合、Amazon EFSを評価できます。

例えば、

複数EC2
複数コンテナ
複数アプリケーションノード

から共有するファイルシステムです。

Amazon EFSは容量がファイルの増減に応じて伸縮するため、

ストレージ容量を
事前に固定してプロビジョニングする

必要がありません。

12. EFSでは現在、汎用パフォーマンスモードを基本にする

Amazon EFSには、

汎用
最大 I/O

というパフォーマンスモードがあります。

ただし現在AWSは、

汎用パフォーマンスモード

をすべてのファイルシステムで推奨しています。

最大 I/Oは前世代のパフォーマンスタイプで、

汎用より
オペレーションごとの
レイテンシーが高い

という特性があります。

したがって、

IOPSが多い
↓
最大 I/Oを選ぶ

とは判断しません。

現行設計では、まず汎用パフォーマンスモードを評価します。

13. EFSではスループットモードを負荷パターンから選ぶ

Amazon EFSのスループットモードには、

エラスティック
プロビジョニング済み
バースト

があります。

エラスティックスループット

負荷が予測しにくい
ピークが急に発生する
平均負荷がピークよりかなり低い

場合に向いています。

EFSがワークロードに合わせてスループットを自動調整するため、必要量を事前に決める必要がありません。

プロビジョニング済みスループット

必要スループットが明確

で、指定したスループットを確保したい場合に評価します。

バーストスループット

ファイルシステムに保存されているデータ量などに基づくベースラインとバースト特性を利用します。

重要なのは、

NFS共有だからEFS

で終わらず、

負荷変動
+
必要スループット

からスループットモードまで判断することです。

14. Amazon FSxは必要なファイルシステム特性から選ぶ

Amazon FSxでは現在、

FSx for Windows File Server
FSx for Lustre
FSx for NetApp ONTAP
FSx for OpenZFS

を利用できます。

どれも、

高性能なファイルストレージ

というだけで選びません。

まず、

必要なプロトコル
ファイルシステム互換性
既存アプリケーション要件
並列アクセス特性

を確認します。

15. Windowsネイティブの共有ファイルではFSx for Windows File Server

次のような要件なら、

SMB
Windowsファイルシステム機能
Microsoft Windows Server互換
Active Directory連携

FSx for Windows File Serverを評価します。

例えば、

複数Windowsサーバー
↓
共通SMB共有

という構成です。

性能面では、

スループットキャパシティ
+
ストレージIOPS

などをワークロードに合わせます。

16. 高度に並列化されたファイル処理ではFSx for Lustre

多数のコンピューティングノードが、

同じ大規模データセット

を並列処理し、

非常に高い集約スループット
+
多数クライアントからの
並列ファイルアクセス

を必要とする場合、

FSx for Lustre

を評価します。

代表例は、

HPC
機械学習
大規模分析
メディア処理

などです。

FSx for Lustreは複数のファイルサーバーやディスクへスケールアウトし、大量のクライアントから並列アクセスするワークロード向けです。

17. ONTAPやOpenZFSが要件なら該当するFSxを選ぶ

FSx for NetApp ONTAP

例えば、

NFS
SMB
iSCSI
NVMe/TCP

などの複数プロトコルや、

既存のONTAP機能

を必要とする場合に評価します。

同じデータへNFSとSMBからアクセスするマルチプロトコル構成も可能です。

FSx for OpenZFS

NFS
+
OpenZFSベースの
ファイルシステム機能

を必要とする場合に評価します。

つまりAmazon FSxでは、

FSxという名前

だけではなく、

必要なファイルシステム
+
プロトコル
+
性能特性

まで見て種類を選びます。

18. 「IOPS型」と「スループット型」をストレージ選択へ適用する

すでに性能目標として、

IOPS
スループット

を分けました。

ストレージ選択では、これをアクセスパターンと結び付けます。

つまり、

IOPSが必要

だけでサービスを選ばず、

どの形式のI/Oを
どこから
どのように行うのか

まで確認します。

19. 代表的な選択を整理する

これは、

サービス名の暗記表

ではありません。

各行の左側にある、

アクセスパターン
+
性能目標

が決定条件です。

20. よくある誤判断

21. SAP-C02での判断フロー

ストレージ性能目標
        ↓
アクセス方式は？
        ↓
オブジェクトAPI？
├─ はい
│   ↓
│  Amazon S3
│   ↓
│  単一AZを受け入れて
│  より低いレイテンシーが必要？
│       ↓
│  S3 Express One Zoneも評価
│
└─ いいえ
    ↓
    EC2からブロックデバイス？
    ├─ はい
    │   ↓
    │  Amazon EBS
    │   ↓
    │  小さいランダムI/O？
    │  → gp3 / io2を評価
    │
    │  大きいシーケンシャルI/O？
    │  → st1を評価
    │
    └─ いいえ
        ↓
        共有ファイル？
        ↓
        NFSを伸縮自在に共有？
        → Amazon EFS
        ↓
        特定のファイルシステム要件？
        ├─ Windows / SMB
        │  → FSx for Windows File Server
        ├─ 大規模並列処理
        │  → FSx for Lustre
        ├─ ONTAP / マルチプロトコル
        │  → FSx for NetApp ONTAP
        └─ OpenZFS / NFS
           → FSx for OpenZFS

最後に、

必要IOPS
必要スループット
必要レイテンシー
クライアント数
負荷変動

が、そのサービスの性能範囲と一致するか確認します。

まとめ

Storage Performanceの選択では、

最高性能のストレージを選ぶ

のではありません。

まず、

アクセスパターン
↓
必要なアクセス方式
↓
IOPS / スループット / レイテンシー
↓
ストレージサービス
↓
サービス内の性能設定

と判断します。

代表的には、

オブジェクト
→ Amazon S3

EC2ブロック
→ Amazon EBS

共有NFS
→ Amazon EFS

特定ファイルシステム
→ Amazon FSx

です。

その上で、

小さいランダムI/O
→ IOPS重視

大きいシーケンシャルI/O
→ スループット重視

多数クライアント
→ 並列性と集約性能

変動の大きい共有ファイル負荷
→ EFSのスループットモード

非常に高いEBS IOPS
→ io2 Block Express

のように絞ります。

SAP-C02では、「このサービスが速いから選ぶ」ではなく、「このアクセスパターンと性能目標を、このサービスのアクセス方式と性能特性が満たすから選ぶ」という判断が重要です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク2.5 AWSストレージオプション・アクセスパターン
• Amazon EBS ボリュームの種類 — gp3 / io2 / st1 / sc1の性能特性
• Amazon EBS I/O の特性およびモニタリング — IOPS・I/Oサイズ・スループット
• Amazon EBS 最適化インスタンス — EC2側のEBS性能上限
• Amazon EFS のパフォーマンス仕様 — パフォーマンスモード・スループットモード
• Amazon S3 パフォーマンスガイド — 大規模オブジェクトアクセス
• S3 Express One Zone — 低レイテンシーオブジェクトアクセス
• Amazon FSx — Windows / Lustre / ONTAP / OpenZFS