concrete5 のAWSでの冗長化構成
この記事は、concrete5 Japan Advent Calendar 2016に参加しています。
こんにちは、岩本です。 現在、東京オフィスでの研修中のため、わさびちゃんに1週間ほどあっていません。忘れられて、次会った時に威嚇されないか心配です。
CONCRETE5 CMSで冗長化構成
システム要件により冗長化が必要になる場合があります。
その際、AWSを用いることで安価に冗長化構成の構築が可能です、ただし、アプリケーションでの対応も別途必要になります。
今回はconcrete5にて冗長化構成を行う際を記載します。
CONCRETE5 で冗長化を行うための対応
インフラで冗長化を行なうには、アプリケーション側でも、下記のような考慮が必要になります。
- ブラウザのセッションの共有
- CMSで生成されるキャッシュの共有
- アップロードファイルの共有
上記を踏まえたAWS構成
- WEBサーバー
- ELB + EC2
- DBサーバー
- RDS Multi-AZ
- アップロードファイルの共有
- AmazonS3
- ブラウザセッション・CMSのキャッシュの共有
- Elasticache
CONCRETE5での対応
アップロードファイルの共有
アップロードされるファイルを一元化する必要があります、
concrete5 では、Storage for Amazon S3 アドオンを利用します。
詳しい利用方法は、こちらをご覧ください。
ブラウザセッション・CMSのキャッシュの共有
複数台のWEBサーバーを利用する場合、ブラウザのセッションを維持するために、PHPのセッションを外部に切り出す必要があります。
また、concrete5 にはキャッシュ機能が標準で備わっていますが、キャッシュの生成は、サーバーへの初回のアクセス時に生成される仕様であり、
仮に各サーバー上にキャッシュがある場合、キャッシュのパージも複数台同時に行わないと、キャッシュ内容に差分が生じます。
そこで、ブラウザセッションとキャッシュをMemcahed(Elasticache)に書き出します。
詳しい手順は、こちらをご覧ください。
別のアプローチ NFS
concrete5 では、キャッシュ及びアップロードファイルは、標準ではルートディレクトリ以下の"/files"ディレクトリに保存されます。 そこで"/files"ディレクトリ をNFSにて共有する手法も考えられます。 ※別途PHPセッションの共有も必要です。
NFS 構成との比較
キャッシュの保存先を「NFS」と「Elasticache」とした場合のパフォーマンスの比較を行いました。
※AWSでNFSを利用する場合、EFSという選択肢がありますが、 現在、東京リージョンではEFSは残念ながら利用できませんので、今回はEC2内にNFSサーバーを構築する事で代用します。
ベンチマークは、concrete5でフルページキャッシュをONにしたTOPページにApacheBenchを実施した結果が下記となります。
画像の保存先を「NFS」と「S3アドオン」とした場合のパフォーマンスの比較が下記となります。 同じく、フルページキャッシュをONにしたTOPページにApacheBenchを実施しました。
まとめ
ベンチマーク結果より、パフォーマンスは各環境にて大きな差がなことが読み取れます。 それぞれの箇所にキャッシュデータが存在してとしても、一度PHPに読み込まれてしまえば、メモリ上に展開され、ネットワークによるロスがあまり発生しないからだと考えられます。
ただし、今回アクセスが発生するのはある特定の1ページでしたが、実運用のサイトとなると複数のページにアクセスが発生し、
キャッシュ量、キャッシュのTTLなど、ある為、ファイルとして保存されるNFSとメモリ上に展開されるMemcachedで性能差がもう少し出るのではないかとも考えられます。
また、NFSとs3を比較した場合ですが、パフォーマンスではおなじですが、EFSとs3では価格差があります。
NFSで共有をしてしまえば、アプリケーション側での対応は不要ですが、コスト面などを考えると割高になる事も考えられます。
冗長化構成を行う際の参考にいただけると幸いです。