こんにちは、SCSK木澤です。
一昨年、WordPress等Webシステムのコンテンツ共有にAmazon EFSを用いることについての課題等をまとめました。
Amazon EFSはその後も性能改善を続けておりますが、まだユースケースを選びます。
今回はAmazon FSx for OpenZFSを用いて本件を解決したいと思います。
おさらい
Webサーバー間のコンテンツ同期
前回の記事でも触れていますが、改めてWebサーバのコンテンツ共有についておさらいします。
Webシステムの可用性を高めるためMulti-AZ構成にする際、DBの高可用性と合わせてWebコンテンツ（ファイル）の共有手段を検討する必要があります。
旧来の運用では、リリースの際に各Webサーバにファイルをデプロイする運用が多かったですが、CMS管理が多い今ではこれを自動化するため、Webサーバー間でコンテンツ同期を行う方式がよく採用されています。
但し本構成では両サーバが異なる設定で、更新系のアクセスは全て主系側（上図では左）で受け付けるようロードバランスを制御する必要がありますし、AWS上ではAuto-Scalingへの対応も難しくなるという問題があります。
Amazon EFSの利用とその課題
Linuxインスタンス間でコンテンツ共有する手段として真っ先に思いつくのがAmazon EFSとなるわけですが、この構成は一筋縄にはいきません。Amazon EFS自体が可用性、拡張性重視の分散ファイルシステムとなっているため、仕様上 小さなファイルを大量に書き込む際は速度が遅く、問題になることが多くあります。
EFSの性能に関するアップデートも順次行われており、大きいところでは2022年12月にElastic Throughputが発表されています。
とはいえ、なかなかWebコンテンツなど、EC2インスタンス間のファイル共有における要件を満たすことが難しいようで、現在Webページ上の表記でもコンテナ・サーバレスなどクラウドネイティブ開発におけるコンテンツ共有手段として推奨されている状況です。
Amazon FSx for OpenZFSについて
概要
Amazon FSx for OpenZFSは、OSSファイルシステムであるOpenZFSをベースにAWS上で提供されているマネージドサービスとなります。
OpenZFSは旧サン・マイクロシステムズによりSolarisで提供されているファイルシステム、ZFSをオープンソース実装したものであり、以下のような特徴があります。
- 高い耐久性（データ整合性の確保）
- 高いパフォーマンス・スケール
- 高可用性（スナップショット機能、バージョン管理機能）
- 圧縮および重複排除による容量削減
- セキュリティ機能（暗号化への対応）
余談となりますが私はAWS担当になる前はVMwareソリューション担当で、各社のSDS（ソフトウェアデファインドストレージ）製品の調査を行ったことがありOpenZFSベースの製品も多かったことを記憶しています。
Amazon FSx for OpenZFSでは、このような高機能ストレージを従量課金で利用できるというわけです。
プロトコルとしてはNFS(v3,v4.1)に対応しており、Linux及びWindowsインスタンス、オンプレミスのワークロードからも接続可能です。
ユースケースとしてはWordPressなどCMSとの親和性がWebサイトにて謳われています。
なお、2023年8月より、Multi-AZ構成にも対応しましたので本番環境でも利用しやすくなりました。
他サービスとの使い分け
Linuxインスタンス間のコンテンツ共有については、上記で採りあげたAmazon EFSや、他にもAmazon FSx for NetApp ONTAPなどの選択肢があり選択に悩むところです。
機能面で比較するとこんな感じになります（2025年3月時点）
使い分けとしては、Amazon FSx for OpenZFSのBlackbelt資料や公式サイトを参考にすると良いかと思います。
ざっくりまとめると、以下のようになります。
- Amazon EFS
- 主にサーバレス環境から利用する
- 高い性能は不要
- Amazon FSx for NetApp ONTAP
- ユニファイドストレージとして、NFS以外にもSMB、iSCSIプロトコルも利用したい
- 数TBを超える大容量ストレージである
- 重複排除やストレージ階層化機能を利用して容量削減したい
- ONTAP譲りの管理機能を利用したい
- Amazon FSx for OpenZFS
- お手軽にEC2インスタンス間のファイル共有に利用したい
- 容量はそれ程多くないが高い性能が必要である
コスト面での大きな違いとして、Amazon FSx for NetApp ONTAPの最低容量が1024GBなのに対し、Amazon FSx for OpenZFSは64GBから始められるということがあります。（容量単価はほぼ同じ）
お手軽に利用したいということであれば、Amazon FSx for OpenZFSの方が良さそうです。
なお、Amazon FSx for NetApp ONTAPについては下記の記事でも解説していますので是非ご覧下さい。
費用
Multi-AZ構成の場合、以下の通りです（2025年3月現在）
- ストレージ料金 ： $0.216/GB (※圧縮後のディスク容量）
- スループットキャパシティおよびIOPS料金
- スループットキャパシティ料金 $1.096/Mbps-月
- IOPS料金 $0.0288/IOPS-月
- Intelligent Tieringの場合は別途I/O課金(書き込み/読み取り)が発生
注意が必要なのは、スループットキャパシティ料金は ベースライン性能(160MB/s)から追加した分に発生するのではなく、ベースライン性能に対しても掛かる、ということです。
つまり、Multi-AZ構成の場合は最低でも $180/月 程度は掛かるということになりますので、注意してください。
ファイルシステムの作成手順
作成手順も簡単に書いておきます。
Amazon FSx for OpenZFSファイルシステムの作成
Amazon FSxのコンソールよりファイルシステムの作成をクリックし、続けてAmazon FSx for OpenZFSを選択します。
クイック作成でも問題ありませんが、今回はスタンダード作成で進めます。
ファイルシステム名と、デプロイタイプ(Multi-AZ)、容量(64GB/最小)を指定します。
デフォルトの性能は下記の通りですが、後で変更可能です。
- IOPS ： 3IOPS/GB
- スループット：160MB/秒
ネットワーク設定として以下を指定します。
- 接続するVPC
- セキュリティグループ
- ENIをデプロイするサブネット
- ルートテーブル
クライアントからのみ接続できるよう、セキュリティグループは事前に作成しておくことが望ましいです。
上述の通りルートテーブルはENI経由でのルーティングになるよう指定するものですので、EC2インスタンスなどNFSクライアントが参照できるよう指定する必要があります。
圧縮タイプとNFSエクスポートオプションを指定します。
（インライン）圧縮タイプには LZ4 及び ZStandard、及び圧縮なしが選択可能です。
NFSエクスポートオプションとして、今回は以下を指定しました。
- no_root_squash : rootでの移行作業が想定されたため（必ずしも必要なし）
- async : 非同期書き込み（後述）
次の画面でパラメータの確認が出来ます。
あとで編集可能な設定かどうかについて確認でき、親切ですね。
Linuxインスタンスへのマウント方法
ファイルシステム作成後、画面上の「アタッチ」ボタンをクリックするとマウント方法が表示されます。
（こちらも丁寧ですね）
Amazon FSx for OpenZFS検証してみた
WordPressの環境を例に、Amazon FSx for OpenZFSがWebコンテンツ共有に耐えうるかどうか、確認したいと思います。
構成
以下の構成で検証を行います。
なお、Amazon FSx for OpenZFSサービスへのアクセスは指定したサブネットに設置されたENI経由のルーティングとなり、EC2インスタンスなどクライアントが参照するルートテーブルへ設定が入ります。Multi-AZ構成では、下図のように複数サブネットにENIがデプロイされます。
障害発生時や設定変更時にはフェイルオーバーが発生し、経由するENIが切り替わるようルートテーブルが自動的に変更されます。
また、その仕様上 VPC外からアクセスする場合には、Transit Gatewayが必要となります。
性能検証結果
今回はEFSとFSx ZFSをマウントし書き込み性能の検証を行いました。
Almalinux9(カーネルバージョン 5.14)、t3a.small のインスタンスより両サービスをマウントしツールから IOPS、帯域の測定を行いました。なおブロックサイズ 1MB,4KB の2パターンの測定を行っています。
FSx ZFSについては、ベースライン性能(192IOPS, 160MB/s)の場合と、性能を拡張した場合(960IOPS,320MB/s)の両方を測定しました。
測定結果① 同期書き込みの場合
標準設定の場合の測定結果は以下の通りになりました。
ベースラインの性能でもEFSの3～4倍程度の性能値が出ていますが、正直期待したほどの性能は出ていません。
また、帯域およびIOPSの性能を拡張した場合でも頭打ちとなっており性能上昇は確認できませんでした。
Block Size 1024Kの場合
| IOPS | BandWidth(MB/s) | |
|---|---|---|
| EFS (Elastic Throughput) |
32 | 32.5 |
| FSx ZFS (Sync) 192IOPS BW160MB/s |
87 | 87.3 |
| FSx ZFS (Sync) 960IOPS BW320MB/s |
92 | 92.9 |
Block Size 4Kの場合
| IOPS | BandWidth(MB/s) | |
|---|---|---|
| EFS (Elastic Throughput) |
87 | 0.352 |
| FSx ZFS (Sync) 192IOPS BW160MB/s |
342 | 1.37 |
| FSx ZFS (Sync) 960IOPS BW320MB/s |
327 | 1.31 |
測定結果② 非同期書き込みの場合
そこで、NFSオプションより非同期書き込み(async)を有効にして再検証を行ったところ、大きな性能向上が確認できました。
Block Size 1024Kの場合
| IOPS | BandWidth(MB/s) | |
|---|---|---|
| EFS (Elastic Throughput) |
32 | 32.5 |
| FSx ZFS (Sync) 192IOPS BW160MB/s |
87 | 87.3 |
| FSx ZFS (Sync) 960IOPS BW320MB/s |
92 | 92.9 |
| FSx ZFS (async) 192IOPS BW160MB/s |
256 | 257 |
| FSx ZFS (async) 960IOPS BW320MB/s |
360 | 360 |
Block Size 4Kの場合
| IOPS | BandWidth(MB/s) | |
|---|---|---|
| EFS (Elastic Throughput) |
87 | 0.352 |
| FSx ZFS (Sync) 192IOPS BW160MB/s |
342 | 1.37 |
| FSx ZFS (Sync) 960IOPS BW320MB/s |
327 | 1.31 |
| FSx ZFS (async) 192IOPS BW160MB/s |
3768 | 14.7 |
| FSx ZFS (async) 960IOPS BW320MB/s |
3906 | 15.3 |
なお、Blackbelt記事には、性能向上するためのヒントとして幾つか記載があります。
こちらにはNFSv3でマウントする事などで性能向上する可能性があるとの記載がありますが、今回の環境では大きな違いは出ませんでした。また、インライン圧縮を外した場合や、EC2インスタンスのスペックを上げても違いは認められませんでした。
考察
以上の結果により（Webコンテンツ等）細かいファイルを大量に書き込む環境の場合は、非同期書き込みにしないと設定したストレージの性能が出ず
- まずは非同期書き込み(async)にすることを検討
- 更に性能を上げたい場合はディスクのIOPS値を上げる
との対応が望ましいと思われます。
なお、Webサイト（WordPress）のDocument Root以下の全ファイルをコピーする速度も確認しました。
（約800MB、38000ファイル。EBS内であれば約5秒でコピーは完了します）
この場合も非同期書き込み(async)を設定することでコピー時間が 約17分 ⇒ 約100秒と短縮され大幅な性能向上が認められました。
また、前回の記事で問題となっていたWordPress管理画面上からのWordPressプログラム本体やテーマの更新作業においてもエラーなく終了することを確認できました。
まとめ
結果としては非同期書き込み(async)設定を検討しましょうということになるのですが…
本設定ではBlackbeltに記載があるように、インメモリキャッシュに書き込まれた段階で完了を返すため、書き込み直後に障害が発生した場合にデータロストが発生する可能性があります。今回はWebコンテンツの共有目的のためバックアップ保護により対処可能と考えますが、ミッションクリティカルなシステムの場合は留意が必要と思われます。
AWS上におけるファイル共有にて、Amazon FSx for OpenZFSがお手軽かつ有用であることが確認できたので、良しとしましょう。
ここまでお読みいただきありがとうございました。
Storage JAWS #7で発表しました
本内容について、2025年3月12日に開催された Storage JAWS #7 で発表しました。
ご参加・ご視聴いただいた方、ありがとうございました！
2025年3月12日に開催 Storage JAWS #7 講演資料
WordPressのファイル共有にAmazon FSx for OpenZFSを利用する