こんにちは、こんばんわ！クラウドインテグレーション事業部の魚介系エンジニア松尾です。
以前の記事で数回に分けて EFS に対するデータ移行方法を紹介させていただきました。
今回は EFS 自体のご紹介として、現在どのような仕様でどういった機能を提供しているか、どういったユースケースでの利用が想定されるかについて投稿させていただきます！
EFS に関する前回までの記事については以下となります。
techblog.forgevision.com techblog.forgevision.com techblog.forgevision.com
はじめに
EFS は 2016年にリリースされた比較的歴史のあるサービスです。
ここ数年で、Mountpoint for Amazon S3やEBS Multi-Attach、ECS・Fargate の EBS 統合など目的によっては代替となるようなサービスの発表がありますが、2024年現在でも Linux OS でファイル共有を行う場合は EFS が第一の検討サービスとなることは間違い無いかと思います。(パフォーマンス要件次第で FSx for NetApp ONTAPとの比較にはなるかもしれませんが・・・。)
EFS も以前より機能が拡張され、より汎用性の高いサービスとなっておりますので、以降で現在設定可能なパラメータや機能について紹介させていただきます。
EFS の利用をご検討中の方の一助になれば幸いです。
EFS 起動時のパラメータについて
ファイルシステムの設定
ファイルシステムのタイプ
EFS は単一または複数のアベイラビリティーゾーン(以降 AZ)でデータを保管するかを選択することができます。
単一 AZ の場合は可用性が減少する代わりにストレージ費用が安くなります。(データの転送料は変わりません)
EFS のコストは他のストレージサービスと比べ比較的割高であるため、後述のライフサイクル管理の部分も含めた構成の検討が必要です。
バックアップ
以前の記事でも紹介しておりますが、EFS でバックアップを取得するためには AWS Backup を利用する必要があります。
EFS コンソール画面でもバックアップ設定が可能となっておりますが、 実際は AWS Backup が動作する形となります。
少し話が変わりますが、AWS Backup から EFS のバックアップをリストアした際の注意点として、バックアップ時のディレクトリ構成がそのままリストアされず、AWS Backup からのリストアを示す「リカバリディレクトリ」配下にリストアされます。
これを知らずにアプリケーションを起動すると動作不具合が起こる可能性があるため十分ご注意下さい。
ライフサイクル管理
データのアクセス頻度に応じて低頻度アクセス(IA)への移行さらに、アーカイブへの移行を行うようライフサイクルの設定が可能です。
この機能を用いることでデータによって費用を10分の一以下に抑えることもできます。
最短1日で低頻度アクセス(IA)への移行も可能となっております。
また、アーカイブへのアクセスが発生した場合でも標準ストレージへの移行も自動設定可能ですので、データの需要に応じて柔軟に対応が可能となっております。
なお、単一 AZ を利用している場合はアーカイブへの移行はできません。
暗号化
説明不要かもしれませんがストレージは KMS のキーを使って暗号化が可能です。
AWS の管理キーまたはカスタマー管理キーから選択できます。
パフォーマンス設定
スループットモード
スループットモードを拡張またはバーストから選択できます。
拡張の場合、さらに以下のモードの選択が必要となっております。
伸縮自在(推奨)
I/O 予測が難しいワークロードの場合を想定したモードで、スループットが自動的にスケーリングされ、実際に転送されたデータに対して課金されるモードとなります。
比較的最近のアップデートで追加されたモードで、以前はバーストモードではパフォーマンスが出ない、プロビジョニングモードは試算が難しいなどの課題がありましたが、本モードが追加されたことでその点が柔軟に対応ができるため、導入のしやすさが格段に上がりました。
ただし、本モードの場合データ量に応じてスケーリングし続けるため、コスト面を考慮すると運用をしていく中でワークロードに応じたモードの変更も視野に入れる必要があります。プロビジョニング済み
スループットの要件を見積もることが可能な場合は本モードの選択をお勧めします。
I/O の見積りが難しいワークロードの場合は、一先ずは前述の「伸縮自在」を選択し、傾向が見えたら本モードへの切り替えを行うと良いかと思います。
バーストスループットを選択した場合、以下のパフォーマンスモードを選択する必要がございます。
汎用(推奨)
オペレーションごとのレイテンシーが低く、バーストスループットの場合、本モードの利用が推奨されています。最大I/O
前世代のパフォーマンスタイプで、汎用モードよりも高いレイテンシーに耐えられる高度に並列化されたワークロード向けのモードです。
現在は利用が推奨されないモードとなります。
以前はワークロードによっては「最大I/O」を利用するケースの説明書きがあった記憶ですが、現在は機能として提供はあるもののほぼ利用することは無いようです。
ネットワークアクセス
クライアントが EFS にアクセスするためのインターフェースをマウントターゲットとして提供する必要があります。
具体的には以下の設定が必要です。
VPC
EFS に接続するクライアントが配置された VPC を選択しますAZ
マウントターゲットを配置する AZ を選択します
冗長化する場合は複数の AZ の選択が必要です。サブネット
マウントターゲットを配置する AZ に紐づくサブネットを選択します
選択した AZ に応じて指定が必要です。IPアドレス
サブネットの CIDR に応じた IP アドレスを自動または手動で付与します。セキュリティグループ
各マウントターゲットのセキュリティグループを設定します。
クライアントの IP アドレスが動的な場合(EC2 Auto Scaling や ECS など)は場合はクライアントにアタッチされたセキュリティグループをネストしましょう。
ファイルシステムポリシー
EFS でリソースポリシーを設定することが可能です。
カスタムポリシーを作成することも可能ですが、既定で指定可能なポリシーパターンやジェネレータがあるため、細かい要件が無い場合はそれらを活用すると良いでしょう。
- 既定のオプション
- デフォルトでルートアクセスを禁止する
- デフォルトで読み取り専用アクセスを強制する
- 匿名アクセスを禁止
- すべてのクライアントに対して転送時の暗号化を強制する
EFS で提供されている機能について
アクセスポイント
ファイルストレージで一般的に提供されているエクスポート機能と同様の機能と考えてよいと思います。
EFS ではデフォルトで root ユーザーのみが読み取り/書き込み/実行のアクセス許可権限を保有しておりますが、他のユーザで EFS 上の操作を行うには、root ユーザで明示的にアクセス許可を付与する必要があります。
少数のユーザやアプリケーションで EFS を利用する場合はそういった権限管理をマニュアルで運用しても大きな手間ではないかもしれませんが、ユーザ、アプリケーションが増えてくるとディレクトリ構成が煩雑になり、運用のオーバーヘッドが大きくなることが危惧されます。
そういった場合に、アクセスポイントを使用することで、root 以外のユーザやグループに対するディレクトリのアクセス管理を自動化することができます。
アクセスポイントで指定できる項目は以下の通りです。
アクセス先のルートディレクトリの指定
特定のユーザ・グループ用のルートディレクトリを指定できます。
指定しない場合は「/」となります。クライアント OS のユーザ ID・グループ ID・セカンダリグループ ID の指定
EFS の権限を付与するユーザ・グループを指定できます。
「アクセス先のルートディレクトリの指定」で指定したディレクトリをルートディレクトリ「/」として識別します。アクセス先のルートディレクトリの作成
事前に root ユーザで EFS 内に一般ユーザ用のルートディレクトリを準備してない場合に、ディレクトリを自動で作成することができます。
また、ユーザ・グループに対して ディレクトリの権限付与することができます。
指定できるパラメータは以下の通りです。- 所有者ユーザー ID
ディレクトリの操作権を与える OS ユーザを指定します。 - 所有者グループ ID
ディレクトリの操作権を与える OS グループを指定します。 - アクセスポイントのアクセス許可
ディレクトリのパーミッション(755など)を設定します。
- 所有者ユーザー ID
以上の設定により、EFS 側でルートディレクトリをコントロールしたり、ユーザ・グループに適切な権限を与えることが可能となります。
前提として EFS マウントヘルパー(amazon-efs-utils の一機能)を利用したアクセスポイン ID トへのマウントを行う必要があります。詳細は以下 AWS 公式ドキュメントをご確認下さい。
amazon-efs-utils ツールの使用 - Amazon Elastic File System
なお、前述のアクセスポリシーと組み合わせて利用することで、アクセス元のリソースごとにアクセスポイントを制御するなどセキュリティ面も強化することも可能ですので、併せて利用しましょう。
レプリケーション
任意の AWS リージョンに対して EFS のレプリカを作成する機能になります。
既存の EFS を指定するか、レプリケーション設定内で新規の EFS を作成してレプリケーションを開始することができます。
宛先 EFS は読み取り専用の EFS として機能し、レプリケーション設定を削除することで書き込みが可能となります。(マウントターゲットは個別に設定が必要です)
ユースケースとしては災害時の DR サイトとしての利用が主になるかもしれませんが、私が AWS を触り始めてからの7、8年はリージョン全体で障害が発生するケース(AZ 障害はありましたが・・・)はほぼなかったため、システムの非機能要件に応じて検討をいただければと思います。
現在の仕様から考えられるユースケース
結論として、AWS の複数のコンピューティングリソース(EC2、Lambda、ECSなど)でリアルタイムなファイル共有が必要な場合は EFS の利用を第一に考えるべきだと思います。
EFS がリリースされてから今日まで様々な AWS サービスがリリースされてきましたが、現在においてもデータ共有ストレージとしては他リソースとの親和性や汎用性は EFS が最も高いと考えます。
データ共有観点での他ストレージサービスとの使い分けとしては、以下と考えてよいかと思います。
| AWSサービス | 用途 |
|---|---|
| EBS | 他リソースとのデータ共有が不要な場合 |
| EFS | 他リソースとリアルタイムなデータ共有が必要な場合 |
| S3 | 他リソースとのリアルタイムなデータ共有が不要な場合 |
| FSx for Netapp ONTAP | 他リソースとリアルタイムなデータ共有が必要な場合(EFS よりも高パフォーマンスが求められる場合) |
| FSx for Windows File Server | Windows で他リソースとのデータ共有が必要な場合 |
上記いずれのストレージサービスを選択した場合でも使い方次第でコストの優位性は変わりますので、実際のワークロードに最適なストレージをご選択ください。
最後に
ここまで数回に渡って EFS のデータ移行関連の記事を投稿させていただいておりましたが、今回は EFS 自体の機能を一通り説明させていただきました。
未だ EFS はデータ共有ストレージの第一線として活躍しているサービスですので、今後の機能アップデートも期待できそうです！(クォータの設定など？)
最近の AWS の記事はデータ移行関連が多かったので、次は別ジャンルの記事を投稿できればと思います！！
では次回もお楽しみに！！！
