📌 はじめに
Amazon EKS（Elastic Kubernetes Service）をマルチ AZ（Multi-AZ）構成で運用する際、最も頻繁に直面するストレージ設計の課題が**「複数ノード・複数 AZ を跨いだ Pod 間でのファイル同時読み書き（ReadWriteMany / RWX）」**です。
AWS の代表的なブロックストレージである Amazon EBS は単一 AZ 内でのマウント（ReadWriteOnce / RWO）に制約されるため、マルチ AZ を跨ぐ共有ストレージ要件を満たせません。
今回は、大量の小ファイル（Small Files）を高頻度に同時処理する EKS ワークロードに対し、Amazon EFS（Elastic File System） を用いてマルチ AZ 共有基盤を構築し、AWS Backup と連携して 1 年間のデータ長期保持・自動廃棄サイクルを実現する業界標準アーキテクチャをまとめます。
1. 業務シナリオとコア課題の整理
業務背景と環境特徴
- コンピュート基盤: Amazon EKS クラスター上で複数レプリカの Pod 群が稼働。
- 高可用性（HA）: ワーカーノードは複数のアベイラビリティゾーン（AZ-a、AZ-b 等）に物理分散して配置。
ストレージアクセスのコア課題
-
マルチ AZ 間での同時共有読み書き (RWX):
- アプリケーションが大量の「小さなファイル（Small Files）」を頻繁に生成する。
- これらのファイルは、異なる AZ で稼働するすべての Pod インスタンスから同時に読み書き（Kubernetes の
ReadWriteMany/ RWX モード）される必要がある。
-
小ファイル I/O への耐性と低遅延:
- 大量の小ファイルに対するランダムアクセスやメタデータ操作に対し、低遅延かつ高スループットな応答性が求められる。
-
EBS の物理的境界の壁:
- 標準的な Amazon EBS は単一 AZ に縛られるため、AZ-a のワーカーノードにアタッチされている EBS ボリュームを AZ-b のノードから直接マウントすることは不可能。
バックアップとコンプライアンス要件
- 生成された業務小ファイルに対し、統一された自動バックアップポリシーを策定し、1年間（365日）安全に保持した後に自動破棄すること。
2. アーキテクチャトポロジー
各 AZ のサブネットに EFS マウントターゲット（Mount Target） を配置し、EFS CSI Driver 経由で全ノードから統一されたファイルシステムをマウントします。
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ Amazon EKS クラスター (マルチ AZ 構成) │
│ │
│ ┌─────────────────────────────────────┐ ┌─────────────────────────────────────┐ │
│ │ アベイラビリティゾーン A (AZ-a) │ │ アベイラビリティゾーン B (AZ-b) │ │
│ │ [ Worker Node 1 ] │ │ [ Worker Node 2 ] │ │
│ │ - Pod レプリカ 1 (PVCマウント) │ │ - Pod レプリカ 2 (PVCマウント) │ │
│ │ │ NFSv4 マウント │ │ │ NFSv4 マウント │ │
│ │ ▼ │ │ ▼ │ │
│ │ [ EFS マウントターゲット A ] │ │ [ EFS マウントターゲット B ] │ │
│ └───────────────────┬─────────────────┘ └───────────────────┬─────────────────┘ │
└───────────────────────┼────────────────────────────────────────────┼───────────────────┘
│ │
▼ ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ Amazon EFS (フルマネージド マルチAZ 弾力性共有ファイルシステム) │
│ - 大量の小ファイルを収容、複数 Pod からのミリ秒級低遅延・同時並行読み書き (RWX) を実現 │
│ - 3 つ以上の AZ に自動冗長配置、容量はペタバイト級まで完全自動スケール │
└───────────────────────────────────────────┬────────────────────────────────────────────┘
│
│ 自動定期スナップショット / 集中バックアップ
▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ AWS Backup 集中バックアップ管理サービス │
│ - バックアッププラン: 日次/定期的な EFS 増量スナップショット取得 │
│ - ライフサイクルルール: コールドストレージ移行 ＆ 1年（365日）経過後に完全自動破棄 │
└────────────────────────────────────────────────────────────────────────────────────────┘
3. なぜ EFS ＋ AWS Backup が最適解なのか？（コア原理）
① マルチ AZ 間での同時並行アクセス（EFS Mount Target ＋ NFSv4）
-
ReadWriteMany (RWX) の完全サポート:
-
Amazon EFS は NFSv4.1 プロトコルに基づくフルマネージド共有ファイルシステムであり、数百〜数千のクライアントノードからの同時マウント・同時書き込みを標準でサポートしています。
-
各 AZ へのマウントターゲット展開:
-
EKS ノードが存在する各 AZ サブネットに EFS Mount Target（ENI） を作成します。
-
Pod がどの AZ のノードにスケジュールされても、同一 AZ 内のローカルマウントターゲットを経由して高速にアクセスするため、AZ 間通信オーバーヘッドを最小限に抑えられます。
-
CSI Driver による抽象化:
-
Kubernetes 公式の AWS EFS CSI Driver を導入することで、開発者は標準的な
StorageClass、PersistentVolume (PV)、PersistentVolumeClaim (PVC)を通じて、透過的に EFS を Pod へマウント可能です。
② 大量小ファイルの I/O ワークロードへの適合
-
POSIX 準拠のファイル操作:
-
Amazon S3 などのオブジェクトストレージと異なり、EFS は完全な POSIX 互換ファイルシステムを提供します。アプリケーション層で API 改修を行うことなく、Linux の標準ファイルシステム API（
open/read/write）で大量の小ファイルを直接操作できます。 -
スループットモードの最適化:
-
小ファイルの頻繁な読み書きに対しては、Elastic Throughput モード（またはプロビジョンドスループット）を選択することで、ストレージ使用容量が小さい段階でも十分な IOPS と帯域を確保し、メタデータアクセスのボトルネックを解消します。
③ AWS Backup による 1 年間保持ポリシーの自動化
-
フルマネージドな統合データ保護:
-
自前で Cron ジョブや Lambda スクリプトを組んで EFS スナップショットを管理・削除する運用は、スクリプトの保守や削除漏れのリスクを伴います。
-
ポリシーベースのライフサイクル管理:
-
AWS Backup のバックアッププラン（Backup Plan）を作成し、EFS ファイルシステムをターゲットとして紐付けます。
-
保持ルール（Retention Period）として「365 日（1年間）」を設定することで、期間満了後のバックアップデータ自動削除が保証され、運用オーバーヘッドが完全にゼロ化されます。
4. Kubernetes マニフェスト設定例 (EFS CSI Driver)
StorageClass の定義 (storageclass.yaml)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: efs-sc
provisioner: efs.csi.aws.com
parameters:
provisioningMode: efs-ap
fileSystemId: fs-0123456789abcdef0 # 作成した EFS の FileSystemId
directoryPerms: "700"
PersistentVolumeClaim の定義 (pvc.yaml)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: efs-shared-pvc
spec:
accessModes:
- ReadWriteMany # 複数ノードからの同時読み書きを宣言
storageClassName: efs-sc
resources:
requests:
storage: 50Gi
アプリケーション Deployment へのマウント (deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: small-file-processor
spec:
replicas: 4 # 複数AZに跨るPodレプリカ
selector:
matchLabels:
app: file-processor
template:
metadata:
labels:
app: file-processor
spec:
containers:
- name: processor
image: my-file-processor:v1.0
volumeMounts:
- name: shared-storage
mountPath: /data/shared
volumes:
- name: shared-storage
persistentVolumeClaim:
claimName: efs-shared-pvc
5. Terraform による AWS Backup 自動化コード例
# 1. AWS Backup Vault (バックアップ保管庫) の作成
resource "aws_backup_vault" "efs_vault" {
name = "efs-yearly-backup-vault"
kms_key_arn = "arn:aws:kms:ap-northeast-1:123456789012:key/xxxx" # バックアップ暗号化
}
# 2. バックアッププラン (日次バックアップ ＋ 1年保持)
resource "aws_backup_plan" "efs_backup_plan" {
name = "efs-backup-plan-1year"
rule {
rule_name = "daily-backup-rule"
target_vault_name = aws_backup_vault.efs_vault.name
schedule = "cron(0 18 * * ? *)" # 毎日 UTC 18:00 (JST 03:00) に実行
lifecycle {
delete_after = 365 # 365日 (1年間) 経過後に自動削除
}
}
}
# 3. バックアップ対象リソースの紐付け (対象 EFS を選択)
resource "aws_backup_selection" "efs_selection" {
name = "efs-selection"
plan_id = aws_backup_plan.efs_backup_plan.id
iam_role_arn = "arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole"
resources = [
aws_efs_file_system.shared_efs.arn
]
}
6. ストレージ選定の比較まとめ
| 比較項目 | Amazon EBS (gp3/io2) | Amazon S3 | Amazon EFS (本構成) |
|---|---|---|---|
| アクセスモード | 単一ノード (RWO) | オブジェクト API (HTTP GET/PUT) | 複数ノード・複数 AZ (RWX) |
| 小ファイル性能 | ブロックレベルで最速 | リクエスト課金と遅延が課題 | 高スループット・低遅延 (POSIX) |
| 可用性境界 | 単一 AZ に限定 | グローバル / リージョン | マルチ AZ 冗長 (標準) |
| アプリ改修 | 不要 | S3 SDK へのコード改修が必須 | 不要（標準マウント） |
7. まとめ
- EKS における RWX のデファクトスタンダード: マルチ AZ に分散した複数 Pod 間でリアルタイムに小ファイルを共有するには、EFS CSI Driver ＋ Amazon EFS の組み合わせが唯一無二の最適解。
- POSIX 互換によるゼロ改修: S3 のようなオブジェクトストレージへの移行改修コストをかけることなく、既存の小ファイル入出力ロジックをそのままクラウドネイティブに移行可能。
- AWS Backup による運用レスなコンプライアンス遵守: スクリプト運用を排除し、AWS Backup のライフサイクルルールで「1年間保持・自動破棄」を集中制御することで、管理オーバーヘッドを最小化できる。