そもそも冗長化とは
冗長化とは、情報技術の世界においてシステムの信頼性や可用性を確保するための一つの戦略です。具体的には、重要なシステムやサービスが一部の障害や故障によって停止することを防ぐために、同一の機能やデータを複数の装置や場所に分散させる手法を指します。
冗長化の目的は2つあります。1つ目は「故障耐性」であり、システムの一部が故障したときでもシステム全体が正常に稼働し続ける能力を意味します。2つ目は「負荷分散」であり、複数の装置や場所に同じ機能やデータを分散させることで、大量のリクエストに対しても迅速に応答する能力を向上させます。
WordPressの冗長化に関連する用語
ロードバランサー
ロードバランサーは、受け入れたネットワークトラフィックを複数のサーバに分散する装置です。これにより、システムの冗長化とともに、負荷分散が可能となります。
昔は高価であったロードバランサーも今はクラウドサービスの発達により、より安易に利用することとが可能で、大手クラウドサービス事業者の多くがロードバランサー機能を提供しています。
またその手法も大きくわけて「L4ロードバランサー」「L7ロードバランサー」の２つがあります。
L4ロードバランサー
L4はOSI7階層参照モデルのトランスポート層(ネットワーク層?)を指し、IP アドレスとポート番号による負荷分散が可能です。
AWSでは「Network Load Balancer」、Azureでは「Azure LB」と呼ばれているサービスを指します。
L4ロードバランサーは、クライアントとサーバ間のTCP/UDP接続の設立と管理を行います。また、L4ロードバランサーは高速で、大量のトラフィックを処理する能力があります。そのため、データベースクエリやAPIリクエストなどの、大量の短いリクエストを処理するのに適しています。
L7ロードバランサー
L7はアプリケーション層を指し、URLやHTTPヘッダー、Cookieで負荷分散が可能です。
AWSでは「Application Load Balancer」、Azureでは「Azure Application Gateway」と呼ばれているサービスを指します。
L7ロードバランサーは、リクエストの内容に基づいて高度なルーティング決定を行うことができます。これにより、特定のURLパスやヘッダーを持つリクエストを特定のサーバにルーティングする、といった高度な制御が可能です。この特性は、マイクロサービスアーキテクチャやAPIゲートウェイなど、複雑なルーティングルールを必要とする環境で特に有用です。
WordPress冗長化におけるロードバランサーの使い分け
両者の大きな違いは、トラフィックをどのように解析し、どの程度の細かさでルーティングを制御できるか、という点にあります。どちらを選択するかは、使用するアプリケーションの性質やニーズによるため、それぞれの特性を理解した上で適切な選択を行うことが重要です。
WordPress冗長化においては、「L7ロードバランサー」を利用し、閲覧者からのトラフィックを受け付けるサーバを複数台設置し（ここではWebサーバと呼ぶ）、管理画面用に１台設置する（ここではCMSサーバと呼ぶ）、N+1台構成が一般的です。
WordPressのディレクトリ構造において「/wp-admin/」というパスで管理画面が提供されるため、「L7ロードバランサー」に簡単な設定を追加することで、このパスに対するトラフィックを管理画面用サーバに転送し、それ以外を閲覧者用の複数台あるサーバに分散させることが可能になるためです（admin-ajax.phpの考慮も必要です）。
また、上記構成にした場合、アクセス数が多い時においても、サーバ負荷が高いのはWebサーバであり、CMSサーバは負荷が高くないので、記事の追加やサイトのメンテナンスがスムーズに行えるメリットもある。
レプリケーション
データベースのレプリケーションとは、同一のデータを複数の場所にコピーすることです。これにより、一つのポイント（サーバ）に障害が発生した場合でも、他のポイント（サーバ）でサービスを継続することが可能となります。
WordPress冗長化においては、ファイルのレプリケーションを行う「Lsyncd」とデータベースのレプリケーションを行う「MariaDB Galera Cluster」という２つの機能を利用します。
Lsyncd（Live Syncing Daemon）
Lsyncdは、1つの同期元ディレクトリから別の同期先ディレクトリへの自動的な同期を提供するオープンソースのツールです。
Lsyncdはinotifyというカーネルの機能を使用して、同期元のサーバのディレクトリの変更を監視し、変更があるたびにrsyncというファイル転送サービスを使用してその変更を同期先サーバに反映します。
Lsyncdは以下の特徴を持つため、リアルタイムなファイル同期が必要な状況、ハイアベイラビリティなウェブサイトの冗長化などに適しています。
- リアルタイムでファイルの変更を検出し、変更をターゲットディレクトリに反映します。
- 大量のファイルやディレクトリの変更を効率的に処理します。
- 大量のファイルやディレクトリの変更を効率的に処理します。
- ファイルやディレクトリの変更だけを転送し、そのためネットワークリソースを節約します。
- ローカルまたはリモートのターゲットディレクトリに同期することができます。
- 複数のターゲットディレクトリへの同時同期が可能です。
設定ファイルを作成することで、Lsyncdはどのディレクトリを監視し、どのディレクトリに変更を反映するか、または特定のイベント（ファイルの作成、変更、削除など）にどのように反応するかを制御することができます。これにより、Lsyncdは様々な環境や要件に対応できます。
MariaDB Galera Cluster
MariaDB Galera Clusterは、高可用性と信頼性を備えたマルチマスターのレプリケーションソリューションです。MariaDBの通常のスタンドアロンデータベースとは異なり、Galera Clusterはデータを複数のノード（サーバ、通常は3つ以上）間で同期的にレプリケーションします。
以下に、MariaDB Galera Clusterの主要な特性と機能について詳しく説明します。
マルチマスターレプリケーション
MariaDB Galera Clusterでは、すべてのノードがマスターノードとして機能します。つまり、任意のノードに対して読み書きの操作を行うことができます。これにより、単一の障害点（SPOF）がなくなり、高い可用性と耐障害性が実現します。
同期的レプリケーション
データは全てのノード間で同期的にレプリケーションされます。これにより、あるノードでの変更が他のすべてのノードにほぼリアルタイムで反映されます。結果として、データの一貫性が確保され、ノードがダウンした場合でもデータロスのリスクが最小限に抑えられます。
自動ノード回復
Galera Clusterは、ネットワーク分断やノードの故障から自動的に回復します。ノードがダウンした場合、残りのノードは引き続きサービスを提供します。そしてダウンしたノードが再起動したとき、そのノードは自動的にクラスターに再結合し、他のノードとデータを同期します。
MariaDB Galera Clusterは、Webホスティング、クラウドサービス、またはその他の高可用性を必要とするアプリケーションでの使用に適しています。ただし、Galera Clusterを最適に動作させるためには、ネットワークのレイテンシ、ノード間の通信、データベースのロック競合などを考慮する必要があります。
WordPressの冗長化の基本的構成
可用性を高めるために、サーバ（ここではKUSANAGIを利用）を３台構成で運用する場合の、全体構成は以下のとおりである。
３台のうち１台は、管理画面へのアクセス処理専用のものとする。これを「CMSサーバ」と呼称し、ロードバランサーのパスルールにてCMSサーバのターゲットグループを転送先とした振り分けを実施する。残る２台については、Webサイト表示のアクセスを処理するサーバとして分散処理を行う。２台を「Web1サーバ」「Web2サーバ」と呼称し、ロードバランサーのデフォルトアクションとして、２台の属するターゲットグループを転送先とした振り分けを行う。
管理画面よりアップロードされた画像ファイルは、Lyncdを用いてCMSサーバより、Web1、Web2サーバにリアルタイム同期を行う。
データベースについては、各サーバのローカルにてMariaDBを起動し、これらをGalera Clusterをもちいたマルチマスタ構成とする。
構築手順
以下に、3で示した構成を実現するための構築手順を示します。
マルチサーバ環境の構築
最終的には３台構成のマルチサーバ環境になりますが、まずはシングルサーバ構成において必要なセットアップを実施し、サイトの閲覧ができる状態まで構築します。
その後、クラウドサービスで提供されているサーバのコピー機能や、ディスクのコピー機能を利用して、サーバをコピーし、３台構成にします。
ホスト名やIPアドレスなどは構成上サーバーごとに別々である必要があるため、それぞれ設定します。
サーバーのコピー機能を使わず、３台それぞれで同じセットアップをすることも可能です。
しかし、微妙な差はどうしても生まれてしまう、環境が同じであることを保証できないため、当社ではサーバをコピーする方式を推奨しております。
これは開発環境を作成する場合も同様であり、本番サーバをコピーして開発サーバを構築しております。（本番サーバが先に構築する場合）
ファイル同期設定
lsyncdを用いて、CMSサーバからWeb1/Web2サーバーへの一方向のファイル同期設定を行います。
なお、カーネルパラメーター（fs.inotify.max_user_watches）やroot ユーザーでのSSH接続（鍵認証）を許可する設定が必要となります。
データベースのレプリケーション
次に、MariaDB Galera Clusterを用いてデータベースのレプリケーションを行います。
lsyncdをは一方向だけの同期でしたが、データベースは、CMSサーバ、Web1サーバ、Web2サーバのマルチマスタ構成となるため、全てのサーバで設定が必要となります。
L7ロードバランサーでのルーティング設定
ロードバランサーは、ユーザーからのリクエストを適切なサーバに分散します。
先の構成のとおり、管理画面へのアクセスはCMSサーバへ、通常のWebアクセスはWeb1とWeb2に分散するようにします。
ルール
/wp-admin 転送先：lpartner-cms-tg
wp-login.php 転送先：lpartner-cms-tg
デフォルト 転送先：lpartner-web-tg
lpartner-cms-tg
port：80
Protocol：HTTP
Target type：Instance
Target：lpartner-cms
lpartner-web-tg
port：80
Protocol：HTTP
Target type：Instance
Target：lpartner-web1、lpartner-web2
L7ロードバランサーでのSSLオフロード設定
冗長化とは直接関係ありませんが、SSLオフロード設定を合わせてします。
SSLオフロードとは、従来であればWebサーバで行っていたSSLの暗号化や復号の処理をL7ロードバランサーに肩代わりさせます。
SSL処理はサーバーリソースを多く使う処理であり、それをL7ロードバランサーにさせることで、サーバー側の負担が減り、より高いパフォーマンスを実現することができます。
また、SSL証明書の更新においても、CMS/Web1/Web2の３台作業するより、L7ロードバランサーの設定変更だけで済むので運用上のメリットもあります。
テストとチューニング
冗長化の設定が完了したら、テストを行い、必要に応じてチューニングを行います。
意図的にツールなどを用いて外部から大量のリクエストを送り、Web1/Web2に分散できていることを確認します。
また、Web1/Web2のどちらかを強制的に終了（HALT）させても、サイトが正常に閲覧できることを確認します。
バックアップの取得
あとは基本的なことですが、万が一の事態に備えて、全てのデータのバックアップを取得します。
これにより、データが破損または失われた場合でも、バックアップから復元することができます。
WordPressのセキュリティ対策は外注するのがおすすめ
WordPressの冗長化を行うことで、システムの信頼性や可用性を高めることができますが、同時にセキュリティ対策も重要となります。セキュリティ対策には専門的な知識と経験が求められるため、これを外部の専門業者に委託することがおすすめです。
プライム・ストラテジーのCMSプラットフォーム統合サービス
プライム・ストラテジーのCMSプラットフォーム統合サービスは、WordPressを含む各種CMSの冗長化、セキュリティ対策、パフォーマンスチューニングなどを一括して提供します。専門的な知識やスキルが必要なこれらのタスクを、確かな経験と技術を持つプロフェッショナルに任せることで、より安心してWordPressの運用を行うことができます。
まとめ
冗長化は、システムの信頼性や可用性を確保するための重要な戦略です。WordPressの冗長化を行うには、マルチサーバ環境の構築、データベースのレプリケーション、ロードバランサーの設定、ストレージの冗長化など、さまざまな手順を踏む必要があります。また、セキュリティ対策も重要であり、これを専門的な知識を持つ業者に委託することがおすすめです。プライム・ストラテジーのCMSプラットフォーム統合サービスは、これらの複雑なタスクを一括して対応します。
