こんにちは、SCSKの木澤です。
今回はWebシステムにおけるコンテンツ同期と、Amazon EFSの利用について触れたいと思います。
はじめに
本サイトも含めて、私はWebサイトの構築・運用に長く携わってきました。
昨年から今年に掛けて、AWSにおけるWordPressの構成等の記事をいくつか寄稿させていただきました。
Webコンテンツの共有方法
今回はWebサーバの冗長化について考えます。AWS上で構築する以上、やはり可用性を高めるためにMulti-AZ構成にしたいわけですが、その際はWeb3層構成に準えて、このようなイメージでよく語られるかと思います。
HTTP(S)アクセスはALBでロードバランスし、DBはMulti-AZ構成にする。これは間違いでは無いのですが一般的なWebサイトにおいてはWebコンテンツ(ファイル)の共有も検討する必要があります。
静的ファイルで更新していた時代であれば両サーバのファイルを同様に入れ替えれば良かったのですが、CMS全盛の現在においてはDBだけでなくWebサーバ上のファイルも動的に更新されますので、共有する仕組みを用意しないと片系のみ更新されて不整合が発生することになります。
WordPressにおいてアップロードされるメディアファイルについては、S3にコピーすることでオフロードできますが、それでもWordPress本体やプラグイン、テーマなどのファイルはDocumentRoot以下に配置され、適宜更新されます。
このWebコンテンツ(DocumentRoot)の共有方法というのは簡単なようで奥の深い世界で、オンプレミス時代からNASを用いたり、またNASがSPOFになってしまっては障害時に元も子もありませんので、別途レプリケーションソフトを導入するなどして対応してきました。
EFSで共有する構成とその問題
さて、AWS上ではどう実現するべきなのか。
昔はマネージドサービスが存在しなかったため、OSSのGlusterFSを導入したサーバをMulti-AZに配置し冗長構成で運用したりしておりましたが、OSSの管理は自前で行う必要があり、不具合時の運用などハードルが高くなるという問題がありました。
現在ではAmazon EFSがあるし、このように構成すればいいのではありますが・・・
実はこの構成、一筋縄にはいきません。
Amazon EFS自体が可用性、拡張性重視の分散ファイルシステムとなっているため、仕様上（特に書き込みの）速度が遅く、問題になることが多くありました。実際、本サイトの構築の際に検証を行いましたが問題が発生し、採用を見送った経緯があります。
そのため、WordPressの冗長構成を解説する記事では、Webサーバ間にOSSを用いたコンテンツ同期を行う構成が良く語られています。
正直この構成の方が「枯れた」構成かと思います。
但し、本構成では両サーバが非対称であるため、更新系のアクセスは全て主系側（上図では左）で受け付けるようロードバランスを制御する必要があり更新系の可用性が下がりますし、Auto-Scalingへの対応も難しくなります。
EFSのパフォーマンスと今年のアップデート
EFSのパフォーマンス概要
EFSのパフォーマンスについてはAWS Blackbeltで語られています。
また、クラスメソッドさんのブログでも大変良くまとめられていますのでご紹介します。
EFSにおいては容量に準じたバーストクレジットが付与される仕様となっているため、低容量のユースケースでは大量の書き込みリクエストを処理する場合にバーストクレジットが枯渇し問題になるケースが有るというわけです。低容量且つ高性能が必要な場合はプロビジョニンドスループットモードを利用し、別途追加料金を支払うことでことで対応できる場合があります。
EFSパフォーマンスに関する今年のアップデート
さて、今年はEFSに関する多くのアップデートがありました。
今年はパフォーマンスに関するアップデートが多く、期待が持てます。
2022/2 サブミリ秒の読み取りレイテンシー
2022/11 Elastic Throughput
2022/11 EFSのレイテンシー軽減（まずは北バージニアから）
検証してみた
WebサーバからEFSを直接マウントする構成について、私としては2020年秋頃に一度確認して利用を見送っておりますが、2022年のアップデートを踏まえて解消しているのかという観点で確認を行いました。
検証方針
最新EFS構成である北バージニアリージョンでEFSを用いたWordPressのコンテンツ共有構成を構成し、動作に支障がないのか、どのような設定が望ましいのか確認していきます。
なお、パフォーマンスモードを随時切り替えて確認を行いました。
- 汎用（us-east1に適用済のレイテンシー低減反映）
- 拡張（Elastic Throughputモード）
- 拡張（プロビジョニングスループット 10MiB/秒）
検証構成
検証環境としてこのようなシステム構成を準備しました。
- ALBで負荷分散（ラウンドロビン）
- WordPressサーバ x2 （Multi-AZ）
- Database（Aurora MySQL）
- EFS
手順
今回は本サイトの開発環境のバックアップを用いてサイトの立ち上げを行いました。
Webサーバ1台＋Aurora構成で動作確認を行った後、マネジメントコンソールの表記に従いEFSボリュームのマウントを行います。
(マウントターゲットの作成) $ sudo mkdir /efs (マウント実施) $ sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /efs (マウント状態の確認) $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 876M 0 876M 0% /dev tmpfs 900M 0 900M 0% /dev/shm tmpfs 900M 17M 884M 2% /run tmpfs 900M 0 900M 0% /sys/fs/cgroup /dev/nvme0n1p1 30G 6.8G 24G 23% / tmpfs 180M 0 180M 0% /run/user/1000 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ 8.0E 0 8.0E 0% /efs
展開したドキュメントルートのコンテンツ全てをEFS配下にコピーします。
$ sudo cp -rp ./DocumentRoot /efs/
今回のデータではDocumentRoot配下のデータ量は475MBありましたが、EFSへのコピーに約10分掛かりました。
なお、パフォーマンスモードを切り替えても違いは見受けられませんでした。
DocumentRootを容易に切り替えられるようにシンボリックリンクを張ります。
また、wp-config.php をDocumentRootの親ディレクトリにコピーします。
$ sudo ln -s /efs/DocumentRoot ./DocumentRoot $ sudo cp wp-config.php /efs/
以上でEFS切り替え後の動作確認ができるようになりました。
同様の設定を２号機側でも行います。
動作確認結果
サイト表示／管理者アクセス
今回は時間の関係で負荷試験は行なっておりませんが、サイトとしての表示については、以下どちらとも特に支障なく表示できました。
- ゲストユーザーとしてのアクセス
- 管理者画面へのログイン、WordPressに関する操作
負荷分散のパラメータはチューニングを行なわずデフォルトの設定のままで、ラウンドロビンでの動作でしたが問題無さそうです。
WordPress更新処理
ここからが特に負荷が掛かる問題となり得る箇所、プラグインやテーマ、WordPressプログラム自体の更新処理となります。
以下の通りでした。
- プラグインの更新
⇒ 単発での更新は正常完了を確認（時間は掛かる） - テーマの更新
⇒ 容量の大きいテーマの場合、処理がタイムアウトする恐れあり。
（当方環境においては、更新・アップロードは成功することを確認したがタイムアウトした） - WordPressプログラムの更新
⇒ テーマと同様、処理がタイムアウトした（更新は成功していた）
タイムアウトに関するチューニングなどを施せば改善の可能性があると思われますが、まだローカルボリューム(EBS)と同様に利用するのは難しいとの結果となりました。
まとめ
WordPressサイトにおけるDocumentRootを直接EFSで共有することは、書き込みパフォーマンスの影響から現時点ではまだ難しそうです。
但し体感ではありますが、ここ1年の読み込み速度の向上やレイテンシー軽減の効果はあると感じられました。
表示系でのコンテンツ共有においては、更新系を分離したりAWS DataSync等も併用すれば使えるのではないかと思いました。
なお、AWSのストレージサービスにおいて、現在ではこのようなユースケース向けの別の選択肢として、Amazon FSx for NetApp ONTAPも利用の視野に入るかと思います。
後日Amazon FSx for NetApp ONTAPの構成も検証してみたいと思います。