この記事は、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で共有をしてしまえば、アプリケーション側での対応は不要ですが、コスト面などを考えると割高になる事も考えられます。

冗長化構成を行う際の参考にいただけると幸いです。