AWS Certified Solutions Architect - Associate (SAA-C03) #11 Domain 3-3 高性能アーキテクチャ — ストレージの選択
#10 キャッシング に続いて、今回は データをどのストレージに置くのか を扱います。AWS のストレージ選択は、まず ブロック・ファイル・オブジェクト の 3 つのタイプを分け、その中で性能・共有・コストの要件に合ったサービスを選ぶ順序です。
3 つのストレージタイプ #
| タイプ | サービス | アクセス方式 | たとえ |
|---|---|---|---|
| ブロック (Block) | EBS | インスタンスにディスクとして接続 | コンピューターに挿したハードディスク |
| ファイル (File) | EFS, FSx | ネットワークファイルシステム (共有) | 共有ネットワークドライブ |
| オブジェクト (Object) | S3 | API/HTTP でオブジェクト単位 | 無限のファイル保管庫 |
最初の分かれ道は 「1 つのインスタンス用のディスク (EBS) か、複数のインスタンスが共有するファイルシステム (EFS/FSx) か、オブジェクト保存 (S3) か」 です。
EBS — ブロックストレージ #
EBS は EC2 インスタンスに接続するブロックボリュームです。基本的に 1 つの AZ に属し 1 つのインスタンスに接続 されます (複数の AZ が共有するストレージではありません)。ボリュームタイプはワークロードに応じて選びます。
| タイプ | 分類 | 適する |
|---|---|---|
| gp3 / gp2 | 汎用 SSD | ほとんどのワークロード、ブートボリューム |
| io2 / io1 | プロビジョンド IOPS SSD | 高 IOPS・高性能 DB |
| st1 | スループット最適化 HDD | ビッグデータ、ログ処理 (シーケンシャルアクセス) |
| sc1 | コールド HDD | あまり使わない大容量 (最安) |
「高 IOPS が必要なデータベース」は io2、「大きなシーケンシャルスループット (ログ・ビッグデータ)」は st1、一般的なら gp3 です。
EFS — 共有ファイルシステム (Linux) #
EFS は 複数の EC2 インスタンスが複数の AZ から同時にマウントする マネージド NFS です。容量が自動的に増減し、Linux ワークロードの共有ファイルシステムに適しています。「複数のインスタンスが同じファイルを共有しなければならない」という要件の基本の答えです。
- ストレージクラス — Standard、IA (低頻度アクセス)、One Zone (単一 AZ・低コスト)
- あまりアクセスしないファイルを IA へ自動移動してコストを下げられます。
FSx — 特殊目的のファイルシステム #
FSx は特定のワークロードに合わせたマネージドファイルシステムです。試験には主に 2 つが出ます。
| FSx の種類 | プロトコル/用途 |
|---|---|
| FSx for Windows File Server | SMB、Windows 環境の共有ファイル (AD 連携) |
| FSx for Lustre | HPC・ML などの高スループット・高性能コンピューティング |
「Windows の SMB ファイル共有」は FSx for Windows、「HPC・機械学習の超高スループットファイルシステム」は FSx for Lustre です。(このほかに NetApp ONTAP、OpenZFS もあります。)
S3 ストレージクラス #
S3 はオブジェクトストレージであり、アクセス頻度と復旧時間に応じてクラス を選びます。クラスの選択がコスト問題の核心です。
| クラス | アクセス頻度 | 特徴 |
|---|---|---|
| Standard | 多い | 基本。即時アクセス |
| Intelligent-Tiering | 不明/変動 | アクセスパターンに応じて自動で階層移動 |
| Standard-IA | まれ | 保存が安い、取得手数料。複数 AZ |
| One Zone-IA | まれ | さらに安い、単一 AZ (耐久性が低い) |
| Glacier Instant Retrieval | アーカイブ | 即時アクセス可能なアーカイブ |
| Glacier Flexible Retrieval | アーカイブ | 分~時間単位の復旧 |
| Glacier Deep Archive | 長期保管 | 最安、復旧 ~12 時間 |
- アクセスパターンが分からない → Intelligent-Tiering (自動最適化)
- たまに使うが即時アクセスが必要 → Standard-IA (または Glacier Instant Retrieval)
- ほとんど使わない長期保管、復旧が遅くてもよい → Glacier Deep Archive (最安)
- One Zone-IA は単一 AZ なので、その AZ の障害時にデータを失う可能性があり、再生成可能なデータ にのみ適しています。
ライフサイクルポリシー (Lifecycle) #
ライフサイクルルールでオブジェクトを時間の経過とともに 自動的により安いクラスへ移動 したり、有効期限を切らせたりします。例:「30 日後に Standard-IA へ、90 日後に Glacier へ、365 日後に削除。」#8 バックアップ のバージョン管理と組み合わせて、古いバージョンを低コストで保管します。
試験の出題パターン #
- 「複数の EC2 が共有 するファイルシステム (Linux)。」 → EFS
- 「Windows SMB 共有。」 → FSx for Windows File Server
- 「HPC/ML 高スループット ファイルシステム。」 → FSx for Lustre
- 「単一インスタンスの 高 IOPS ブロック。」 → EBS io2
- 「アクセスパターンが 不明、自動でコスト最適化。」 → S3 Intelligent-Tiering
- 「最安コストの長期保管、復旧 12 時間 OK。」 → Glacier Deep Archive
- 「古いオブジェクトを 自動で低コスト移動。」 → S3 ライフサイクルポリシー
よく出会う落とし穴 #
1) EBS を複数のインスタンス・複数の AZ が共有すると思う #
EBS は基本的に単一 AZ・単一インスタンス用です。共有ファイルシステムは EFS です。
2) One Zone-IA の耐久性を見落とす #
One Zone-IA は単一 AZ にのみ保存されるため、AZ 障害時に損失のリスクがあります。重要な元データには不適切です。
3) Glacier クラスの復旧時間の違いを無視する #
Glacier Instant は即時、Deep Archive は ~12 時間です。「即時アクセス」が手がかりなら Deep Archive は誤答です。
4) Windows 共有に EFS を勧める #
EFS は Linux NFS です。Windows SMB 共有は FSx for Windows です。
まとめ #
この記事で押さえたこと:
- 3 つのタイプ — ブロック (EBS) · ファイル (EFS・FSx) · オブジェクト (S3)。共有の有無が最初の分かれ道
- EBS — 単一 AZ・単一インスタンス。io2 (高 IOPS) · st1 (スループット) · gp3 (汎用)
- EFS (Linux 共有 NFS) vs FSx (Windows SMB / Lustre HPC)
- S3 クラス — Standard · Intelligent-Tiering (パターン不明) · IA · Glacier (アーカイブ、Deep は最安・遅い)
- ライフサイクルポリシー で自動コスト最適化
次へ — Domain 3-4 DB の選択 #
ストレージを押さえたので、高性能ドメインの最後として データベースの選択 を扱います。
#12 Domain 3-4 DB の選択 では、RDS の Multi-AZ (高可用性) とリードレプリカ (読み取り拡張) の違い、クラウドネイティブな Aurora、NoSQL の DynamoDB、そして分析用の Redshift まで、ワークロードに合ったデータベースの選択を整理します。