concrete5 の運用環境を冗長構成で構築したいというご相談が多くありますので、まとめました。参考になれば幸いです。なお、本記事ではインフラ構成図が登場しますが、分かりやすさのために説明に必要なサービスのみに単純化していますのでご了承ください。
ミニマム（シングル）構成
まずは、最小構成から順にご紹介していきます。１つのWebサーバーで、PHPとMySQLの両方を動作させるパターンです。
この構成の最大のメリットは、インフラコストがかからないことです。ただし、Webサーバーがひとつしかありませんので、障害発生時に完全にWebサイトが止まってしまいます。データロストに備え、バックアップをしっかり取っておく必要があります。
バックアップも、同じWebサーバーに定期的に残しておくようでは、このサーバーが起動しなくなった場合に取り出せなくなってしまいます。基本的な考え方として、Webサーバーはいつ使えなくなるか分かりません。別のWebサーバーでWebサイトを再開できるよう、バックアップは外部に置いておく必要があります。
この構成のデメリットとして、将来的な構成変更に対応しにくいことも挙げられます。
スタンダード構成
次に、Webサーバーとデータベースサーバーを分離する構成です。
この構成のメリットは、データベースサーバーに AWS の提供する RDS などのマネジメントサービスを使うことで、保守管理の人的運用コストが下がることが挙げられます。バックアップも自動的に取ってくれますし、データ量やアクセス数の増加に伴いパフォーマンスが低下した際にも、ダウンタイムなしで簡単にスケールアップ（上位プランへの変更）が行えます。インフラコストは１台に比べて上がりますが、管理コストの低下を考えれば十分なメリットがあります。
また、図には書かれていませんが、ロードバランサーを用意しておくことで将来的な構成変更に対応しやすくなります。
冗長構成
Webサーバー、データベースサーバーともに２台に分散し、可用性を高める構成です。
冗長化構成はサーバーの台数は増えますが、Webサーバー、MySQLいずれも1台に障害が起きてもWebサイトが止まらないことが最大のメリットです。また、ロードバランサーを使って２つのWebサーバーにアクセスを分散していることで、1台の時よりも多くのアクセス数を処理することができますし、将来的にさらにアクセス数が増加した際に、構成変更（台数追加）に対応しやすくなります。後述しますが、2台構成には1台構成にない考慮すべき点が様々にありますので、1台構成を2台構成に変更するのは大変ですが、2台構成にしておけば3台以上にするのは楽になります。
データベースサーバーには、AWS が提供する Multi-AZ 配置 を使うことで、自動的にデータが同期され、障害時には自動的にフェイルオーバーが行われる構成を簡単に構築することができます。
冗長構成+ファイルストレージ
冗長構成としては通常、Webサーバー、データベースサーバーを２台にすることで完成ですが、concrete5 などの CMS を利用する際にはさらに考慮すべき点があります。それが、CMS からアップロードする画像や PDF などのファイルの置き場所です。サーバーAとサーバーBがあったとして、管理者がサーバーAに画像ファイルをアップしたあとで、閲覧者がサーバーBにアクセスした場合、閲覧者には画像ファイルがリンク切れになってしまいます。
Webサーバーの外部に AWS が提供する S3 などのファイルストレージを用意し、ファイルのアップロード先をそちらに変更することで、この問題を回避できます。
Webサーバーを冗長化しているのに、ファイルストレージが１台なのは矛盾している様に思えますが、S3 はデータ耐久性が高い（データロストが発生しない）サービスのため、この構成とすることがほとんどです。ただし、配信速度が遅いため、別途 CDN を必要とします。
通常、S3 にファイルをアップロードするには専用の API を使うためのカスタマイズが必要ですが、concrete5 はアドオンでファイルマネージャーからのアップロード先を S3 に変更できるため、カスタマイズ費用をかけずに簡単にこの構成に対応することができます。S3 は利用料金が非常に低価格なサービスのため、簡単に使えることは concrete5 の大きなアドバンテージです。
冗長化構成+NFS
ファイルアップロードの問題を解決するために、S3 ではなく、複数台のWebサーバーからネットワークで接続されたストレージ（NFS）を使うこともあります。
AWS にも、この用途で使用できるマネジメントサービスの EFS が2018年に東京リージョンに対応したことで、有力な選択肢のひとつとなりました。しかし、そもそもの NFS のメリットが、API を使わなくてもローカルディスクと同様にアクセスできる利便性なのですが、concrete5 ではすでに S3 に対応しているため、メリットが多くコストも安い S3 を使わない理由がほとんどありません。
冗長構成+rsync+lsyncd
ファイルアップロードの問題を解決するもうひとつの手段として、ファイルを２台のサーバー間で同期するという手法もあります。
管理者がCMSにアクセスする際に、必ず片方のWebサーバーにアクセスするようにし、もう片方のWebサーバーにアップロードされたファイルを同期するように設定します。よく使われるのはrsyncとlsyncdの組み合わせです。ロードバランサーを介すると、どちらのサーバーにアクセスするかが分かりませんので、ロードバランサーを回避するために管理者用のドメインを別途用意することになります。
concrete5 では、サイト内リンクを設定しても、ドメイン部分はデータベースに保存されず、表示する際に自動的にドメインを判別して切り替える仕様になっています（HTMLブロックは例外）ので、このようにドメインを分割しても意識せずに運用することができます。
ただし、この構成はWebサーバーを増やすと都度、同期設定が必要なため構成変更に弱く、また管理用に使用しているWebサーバーの重要度が高くなりすぎますので、あまりオススメできません。concrete5 で簡単に S3 が使えるようになっている以上、素直に使うのがベストです。
冗長構成+ファイルストレージ+キャッシュサーバー
concrete5 を冗長構成で運用する場合に検討すべき点は、アップロードファイルだけではありません。
ロードバランサーを使うことで、複数のサーバーにアクセスが分散されますが、このことでログイン状態の維持が問題になります。サーバーAでログインしていても、サーバーBに移った途端にログアウトされてしまいます。
また、表示の高速化にはキャッシュが必要になりますが、こちらも「サーバーAではキャッシュがあるが、サーバーBにはキャッシュがないことで、サーバーBにアクセスした際に表示が遅い」「問題がありサーバーAでキャッシュをクリアしたが、サーバーBにまだ残っている」などの問題が発生します。
これらの問題を解決する際に、キャッシュサーバーを使用します。
セッション情報（ログイン状態情報）や、キャッシュ情報を、外部のキャッシュサーバーにまとめることで、複数台のどちらのサーバーにアクセスしてもログイン状態が保たれ、表示も高速になります。この状態が、concrete5 における冗長構成の基本となります。
キャッシュサーバーには、AWS を使う場合、AWS が提供する ElastiCache を使うことが多いです。簡単に構築でき、マネージメントサービスなので管理コストも低減します。
ElastiCache では Redis および Memcached を利用できます。concrete5 は以前から Memcached をサポートしてきましたが、当社の協力により、次のバージョンからは Redis も標準でサポートされます。
DR（災害復旧）構成
ここまで冗長構成についてご紹介してきましたが、事業継続マネジメントのためには、地域をまたいで冗長化することもあります。
逆に通常の冗長構成はDR用途にはなりませんので、混同しないようにする必要があります。
冗長構成+CDN
ここからは、冗長構成に加えて考慮することが多い構成についてご紹介します。大量のアクセスを処理するためには、サーバー台数を増やすことでも対応できますが、CDN（コンテツデリバリーネットワーク）を利用する方がコストメリットが大きい場合があります。
concrete5 へのログインには Cookie が必要ですが、Cookieを許可するとCDNのパフォーマンスが下がってしまいます。そこで、CDN経由では concrete5 のログインをしないことにし、更新作業用に別のWebサーバーを用意することがあります。
閲覧者にログインさせる会員制サイトでなければセッション情報の共有は不要なため、キャッシュサーバーの必要性は下がりますが、キャッシュの共有のために導入することも多いです。
オートスケーリング構成
CDNを導入してもさばききれないアクセス数の増加が見込まれる場合、オートスケーリング構成（負荷状況に応じて自動的にサーバー台数が増減する）を採用する場合があります。この構成では、concrete5 のバージョンアップや、テーマのCSSファイル・JavaScriptファイルの変更の適用について考慮する必要がでてきます。ファイルを更新すべきWebサーバーが常に増減するため、事前にアップロード先のIPアドレスを固定できないからです。そのため、運用時のソースコードの更新と同期の方法について、事前に検討しておく必要があります。
まとめ
以上のように、冗長構成には構築の際には考慮すべきことがいくつかあります。一方、適切に構築すれば、サービス停止時間を短くできるだけでなく、管理コストをも下げることができます。そのためには、AWS などのクラウドサービスのマネジメントサービスを組み合わせることがポイントです。当社では、AWS 専用のサービス「concrete5 powered by AWS」をご用意していますので、冗長構成上に concrete5 環境をスピーディーに構築・ご提供することが可能です。お困りの際は、ご相談ください。
