こんにちは、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などの選択肢があり選択に悩むところです。
この辺りは、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については下記の記事でも解説していますので是非ご覧下さい。
Amazon FSx for OpenZFS検証してみた
ここまで前説が長くなりました。
WordPressの環境を例に、Amazon FSx for OpenZFSがWebコンテンツ共有に耐えうるかどうか、確認したいと思います。
構成
以下の構成で検証を行います。
なお、Amazon FSx for OpenZFSサービスへのアクセスは指定したサブネットに設置されたENI経由のルーティングとなり、EC2インスタンスなどクライアントが参照するルートテーブルへ設定が入ります。Multi-AZ構成では、下図のように複数サブネットにENIがデプロイされます。
障害発生時や設定変更時にはフェイルオーバーが発生し、経由するENIが切り替わるようルートテーブルが自動的に変更されます。
ファイルシステムの作成手順
さて、作成手順も簡単に書いておきます。
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インスタンスへのマウント方法
ファイルシステム作成後、画面上の「アタッチ」ボタンをクリックするとマウント方法が表示されます。
（こちらも丁寧ですね）
検証結果
今回はAlmalinux9(カーネルバージョン 5.14)のインスタンスよりマウントしの検証を行いました。
パフォーマンスの検証にあたり、今回はWebサイト（WordPress）のDocument Root以下の全ファイルをコピーする速度を確認しました。
（約800MB、38000ファイル。EBS内であれば約5秒でコピーは完了します）
推奨通りマウントした場合(NFSv4)
まず普通にマウントした際は期待した速度は出ず、コピー完了まで約17分掛かりました。
やはり、細かいファイルを沢山書き込んだ場合は厳しいようです。
そこで、Blackbeltの記載を参考に切り分けを行いました。
NFS v3で利用の場合
パフォーマンス改善の可能性があるということで確認しましたが、約17分⇒15分と若干改善した程度でした。
TCPセッション多重化による向上
今回のインスタンスがLinuxカーネルバージョン 5.14ということもあり、TCPセッション多重化オプションの有無による速度の違いも検証しましたが、ほとんど違いはありませんでした。
IOPS設定を変更した場合(192⇒960）
単純にストレージ性能が足りない可能性を考慮し、デフォルトの192(64GB、3IOPS/GB)から5倍の960に変更しました。
結果、約17分⇒14分と、こちらも若干の性能向上は見られましたが、期待外れの結果でした。
インライン圧縮の影響
インライン圧縮による影響を考慮し、圧縮なしのボリュームへのコピーを行いましたが変化なしでした。
EC2インスタンスの帯域
EC2インスタンス側の帯域幅による影響を考慮し、EC2のインスタンスタイプを変更しましたが変化なしでした。
非同期書き込みへの変更
NFSマウントオプションに async を付加し、非同期書き込みに変更してみました
# mount -t nfs -o noatime,nfsvers=4.2,async,nconnect=16,rsize=1048576,wsize=1048576 fs-xxxxxxxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com:/fsx/ /fsx/
すると、約17分 ⇒ 約100秒と大幅な性能向上が認められました。
考察
検証時のCloudWatchメトリックのデータ（抜粋）を掲載します。
- 左側（19:38～19:55頃）
同期書き込みでコピーを行った際のデータとなり、概ね40IOPS程度で頭打ちとなっていました。 - 右側（20:15頃）
非同期書き込みでコピーを行った際は、360IOPS程度まで向上しました。
以上の結果により（Webコンテンツ等）細かいファイルを大量に書き込む環境の場合は、非同期書き込みにしないと設定したストレージの性能が出ず
- まずは非同期書き込み(async)にすることを検討
- 更に性能を上げたい場合はディスクのIOPS値を上げる
との対応が望ましいと思われます。
実際、前回の記事で問題となっていたWordPress管理画面上からのWordPressプログラム本体やテーマの更新作業においてもエラーなく終了することを確認できました。
まとめ
結果としては非同期書き込み(async)設定を検討しましょうということになるのですが…
本設定ではBlackbeltに記載があるように、インメモリキャッシュに書き込まれた段階で完了を返すため、書き込み直後に障害が発生した場合にデータロストが発生する可能性があります。今回はWebコンテンツの共有目的のためバックアップ保護により対処可能と考えますが、ミッションクリティカルなシステムの場合は留意が必要と思われます。
AWS上におけるファイル共有にて、Amazon FSx for OpenZFSがお手軽かつ有用であることが確認できたので、良しとしましょう。
ここまでお読みいただきありがとうございました。