Ubuntu14.04でWordPressアプリケーションサーバーのレイヤー4ロードバランサーとしてHAProxyを使用する方法

投稿日: 2022-04-20 2022-04-20
タグ: HAProxy, Load Balancing, ubuntu

序章

このチュートリアルでは、WordPressサーバー（特にWebアプリケーション層）のレイヤー4ロードバランサーとしてHAProxyを使用する方法を説明します。アプリケーションサーバーの負荷分散により、セットアップに冗長性が追加され、サーバー障害やネットワークの問題が発生した場合の信頼性が向上し、負荷が複数のサーバーに分散されて読み取りパフォーマンスが向上します。セットアップには、別のMySQLデータベースサーバーに接続するWordPressアプリケーションサーバーが含まれていることを前提としています（セットアップ方法のチュートリアルについては、前提条件を参照してください）。

単一のWebサーバーアプリケーションのみを実行している場合は、レイヤー4の負荷分散がサイトに適しています。環境がより複雑な場合（例： WordPressと静的Webサーバーを別々のサーバーで単一のエントリポイントで実行する場合は、アプリケーション層（レイヤー7）の負荷分散を調べる必要があります。

このチュートリアルは、例としてWordPressを使用して作成されていますが、その一般的な概念を使用して、他のステートレスWebアプリケーションの負荷を分散できます。

前提条件

このチュートリアルを続行する前に、別のデータベースサーバーでWordPressサイトをセットアップする（または同様のセットアップを行う）チュートリアルを完了している必要があります。MySQLでサイトパフォーマンスを最適化するためのリモートデータベースのセットアップ方法

そのチュートリアルに従って、別々のWebアプリケーションとデータベースサーバーにWordPressをセットアップした後、2つのVPSが必要になります。複数のVPSを扱うため、参照用に、既存の2つのVPSを次のように呼びます。

wordpress-1 ：WordPressWebアプリケーションサーバー
mysql-1 ：WordPress用のMySQLサーバー

現在、環境の抽象的なビューは次のようになっています。

WordPress Application and Database Server

現在の環境に加えて、このチュートリアルでは2つの追加のVPSが必要になります。それらを呼び出します：

wordpress-2 ：2番目のWordPressWebアプリケーションサーバー
haproxy-www ：負荷分散用のHAProxyサーバー

レイヤー4負荷分散、バックエンド、 ACL など、基本的な負荷分散の概念や用語に慣れていない場合は、基本を説明する記事をご覧ください。 HAProxyと負荷分散の概念の概要。

私たちの目標

このチュートリアルの終わりまでに、次のような環境が必要になります。

HAProxy Load Balanced Web Application

つまり、ユーザーはHAProxyサーバーにアクセスしてWordPressサイトにアクセスします。これにより、ユーザーはラウンドロビン方式で負荷分散されたWordPressアプリケーションサーバーに転送されます。 2つ（必要に応じてそれ以上）の両方がMySQLデータベースにアクセスします。

現在の環境のスナップショット

オプション：このチュートリアルを続行する前に、現在の環境のスナップショットを作成する必要があります。このチュートリアルでは、スナップショットの目的は2つあります。

間違えた場合に職場環境に戻すため
元のサーバーの1回限りのレプリケーションを実行し、PHPとNginxを再度インストールして構成する必要をなくします

注： 2016年10月以降、スナップショットのコストは、ファイルシステム内の使用済みスペースの量に基づいて、1ギガバイトあたり月額0.05ドルになります。

wordpress-1およびmysql-1VPSのスナップショットを撮ります。

スナップショットができたので、残りの環境の構築に進む準備ができています。

2番目のWebアプリケーションサーバーを作成する

次に、元のWebアプリケーションサーバーと負荷を共有する2番目のVPSを作成する必要があります。これには2つのオプションがあります。

元のVPSのスナップショットwordpress-1から新しいVPSを作成します
新しいVPSを最初から作成し、wordpress-1と同じソフトウェアと構成で手動でセットアップします。

どちらの方法でも、プライベートネットワークオプションが利用可能な場合は、必ず選択してください。このチュートリアルで使用するすべてのVPSには、プライベートネットワークをお勧めします。

プライベートネットワークオプションがない場合は、プライベートIPアドレスをVPSのパブリックIPアドレスに置き換えます。アプリケーションとの間で暗号化されていないデータベースパスワードなどの機密データを送信する場合は、パブリックIPアドレスを使用することに注意してください。データベースサーバーは、その情報がパブリックインターネット上を移動するため、適切な方法ではありません。

オプション1：スナップショットを使用して新しいVPSを作成する

wordpress-1 のスナップショットを使用して、wordpress-2という新しいVPSを作成します。

この方法を選択した場合は、「オプション2」をスキップして「Webアプリケーションファイルの同期」セクションに進んでください。

オプション2：最初から新しいVPSを作成する

これは「オプション1」の代替手段です。

wordpress-1 のスナップショットを使用する代わりに、 wordpress-2 サーバーを最初からセットアップする場合は、必ず同じソフトウェアをインストールしてください。元のWordPressサーバーをどのようにインストールして構成したかを覚えていない場合は、前提条件ドキュメントのWebサーバーのセットアップセクションを参照してください。

クイックリファレンスとして、インストールまたは複製する必要のある関連ソフトウェアと構成ファイルのリストを以下に示します。

ソフトウェア：

MySQLクライアント
Nginx
PHP

このソフトウェアをインストールするには、wordpress-2サーバーで次を実行します。

sudo apt-get update
sudo apt-get install mysql-client
sudo apt-get install nginx php5-fpm php5-mysql

元のアプリケーションサーバーと一致するように編集または作成する必要がある構成ファイル：

/etc/php5/fpm/php.ini
/etc/php5/fpm/pool.d/www.conf
/etc/nginx/sites-available/example.com
/etc/nginx/sites-enabled/example.com

次のコマンドを使用してソフトウェアの構成が完了したら、PHPとNginxを再起動することを忘れないでください。

sudo service php5-fpm restart
sudo service nginx restart

新しいアプリケーションサーバーのインストールと構成が完了したら、WordPressアプリケーションファイルを同期する必要があります。

Webアプリケーションファイルを同期する

アプリケーションの負荷を分散する前に、新しいサーバーのWebアプリケーションファイルが元のWordPressサーバーと同期していることを確認する必要があります。これらのファイルの場所は、WordPressをインストールした場所と他のいくつかのファイルによって異なります。 WordPressで実行する必要のあるphpファイルに加えて、アップロードされたファイルとWordPressインターフェースを介してインストールされたプラグインは、アップロードまたはインストール時に同期する必要があります。前提条件のドキュメントでは、WordPressを/var/www/example.comにインストールしました。すべての例でこの場所を使用しますが、これを実際のWordPressインストールパスに置き換える必要があります。

サーバー間でファイルを同期する方法はいくつかあります。NFSまたはglusterFSはどちらも適切なオプションです。 glusterFSを使用して同期のニーズを満たします。これにより、各アプリケーションサーバーは、ファイルシステム全体の一貫性を維持しながら、アプリケーションファイルの独自のコピーを保存できるようになります。ターゲット共有ストレージの概念図は次のとおりです。

glusterFS Shared Volume

このセクションで使用されているglusterFSの用語に慣れていない場合は、このセクションの基になっているこのGlusterFSチュートリアルを参照してください。

注：次のサブセクションは、wordpress-1サーバーとwordpress-2サーバーの間を頻繁に移動します。必ず適切なサーバーでコマンドを実行してください。そうしないと、問題が発生します。

ホストファイルの編集

注：内部DNSがあり、VPSのプライベートIPアドレスのレコードがある場合は、この手順をスキップして、残りのglusterFSセットアップコマンドと構成をそれらのホスト名に置き換えてください。

それ以外の場合、wordpress-1およびwordpress-2 VPSの：

/ etc / hostsを編集します：

sudo vi /etc/hosts

次の2行を追加し、強調表示された単語をアプリケーションサーバーのIPそれぞれのIPアドレスに置き換えます。

wordpress_1_private_IP wordpress-1 wordpress_2_private_IP wordpress-2

保存して終了します。

GlusterFSをインストールし、レプリケートされたボリュームを構成します

wordpress-1およびwordpress-2 VPSの場合：

apt-getを使用してglusterFSサーバーソフトウェアをインストールします。

sudo apt-get install glusterfs-server

wordpress-1 で、次のコマンドを実行してwordpress-2とピアリングします。

sudo gluster peer probe wordpress-2

wordpress-2 で、次のコマンドを実行してwordpress-1とピアリングします。

sudo gluster peer probe wordpress-1

wordpress-1およびwordpress-2で、glusterFSが管理するファイルを保存する場所を作成するには、次のコマンドを実行します。

sudo mkdir /gluster-storage

wordpress-1 で、volume1と呼ばれる複製glusterFSボリュームを作成し、そのデータを両方のアプリケーションサーバーの/gluster-storageに保存します。

 sudo gluster volume createvolume1レプリカ2トランスポートtcpwordpress-1： / gluster-storage wordpress-2： / gluster-storage force

 期待される出力：ボリューム作成：ボリューム1：成功：データにアクセスするためにボリュームを開始してください

wordpress-1 で再度、次のコマンドを実行して、作成したglusterFSボリュームvolume1を起動します。

 sudo gluster volume start volume1

 期待される出力：ボリューム開始：ボリューム1：成功

wordpress-1 で、作成して開始したばかりのglusterFSボリュームに関する情報を表示するには、次のコマンドを実行します。

sudo gluster volume info

WordPressサーバーごとに1つずつ、2つのglusterFS「ブリック」があることがわかります。

glusterFSボリュームを実行しているので、それをマウントして、複製ファイルシステムとして使用できるようにします。

共有ストレージをマウントする

まず、ファイルシステムをwordpress-1にマウントしましょう。

wordpress-1 で、fstabを編集して、共有ファイルシステムが起動時にマウントされるようにします。

sudo vi /etc/fstab

ファイルの最後に次の行を追加して、/storage-poolをマウントポイントとして使用します。これを自由に置き換えてください（こことこのglusterFSセットアップの残りの部分）：

wordpress-1： / volume1 / storage-pool glusterfs defaults、_netdev 0 0

保存して終了します。

wordpress-1 で、glusterFSボリュームを/storage_poolファイルシステムにマウントできるようになりました。

sudo mkdir / storage-pool sudo mount / storage-pool

これにより、共有ボリューム/storage-poolがwordpress-1VPSにマウントされます。 df -hを実行でき、マウントされたファイルシステムとしてリストされているはずです。次に、同様のプロセスに従って、共有ストレージをwordpress-2にマウントします。

wordpress-2 で、fstabを編集して、共有ファイルシステムが起動時にマウントされるようにします。

sudo vi /etc/fstab

ファイルの最後に次の行を追加して、/storage-poolをマウントポイントとして使用します。別の値を使用した場合は、必ずここでその値に置き換えてください。

wordpress-2： / volume1 / storage-pool glusterfs defaults、_netdev 0 0

wordpress-2 で、glusterFSボリュームを/storage_poolファイルシステムにマウントできるようになりました。

sudo mkdir /storage-pool
sudo mount /storage-pool

これで、/storage-poolファイルシステムで作成、変更、または削除されたファイルは、サーバーの1つが一時的にダウンした場合でも、両方のサーバー間で同期されます。

WordPressファイルを共有ストレージに移動する

次のステップは、wordpress-1のWordPressファイルを共有ストレージに移動することです。強調表示された単語を独自の値に置き換えてください。 /var/www/example.comは、WordPressファイルが配置された場所（およびNginxがファイルを検索する場所）を表し、example.com自体は単にディレクトリのベース名です。

wordpress-1 で、次のコマンドを実行して、WordPressアプリケーションファイルを共有ファイルシステム/storage-poolに移動します。

sudo mv /var/www/example.com / storage-pool / sudo chown www-data：www-data /storage-pool/ example.com

次に、共有ファイルシステム上のWordPressファイルを指すシンボリックリンクを作成します。このリンクには、WordPressファイルが最初に実行されて保存されていた場所があります。

sudo ln -s /storage-pool/ example.com /var/www/example.com

これで、WordPressファイルは共有ファイルシステム/storage-poolに配置され、元の場所/var/www/example.comを介してNginxに引き続きアクセスできます。

新しいアプリケーションサーバーを共有ストレージにポイントする

次のステップは、共有ファイルシステム上のWordPressファイルを指すシンボリックリンクを新しいWebアプリケーションサーバー上に作成することです。

スナップショットオプションを使用してwordpress-2を作成した場合は、wordpress-2で次のコマンドを実行します。

sudo rm /var/www/example.com sudo ln -s /storage-pool/ example.com /var/www/example.com

* wordpress-2 を最初から作成した場合は、wordpress-2で次のコマンドを実行します。

sudo mkdir -p / var / www sudo ln -s / storage-pool / example.com /var/www/example.com

WordPressアプリケーションファイルを同期するのは以上です。次のステップは、新しいアプリケーションサーバーwordpress-2にデータベースへのアクセスを許可することです。

新しいデータベースユーザーを作成する

MySQLはユーザー名とソースホストでユーザーを識別するため、新しいアプリケーションサーバーwordpress-2から接続できる新しいwordpressuserを作成する必要があります。

データベースVPSmysql-1 で、MySQLコンソールに接続します。

mysql -u root -p

次のMySQLステートメントで、強調表示されているすべての単語を環境に適したものに置き換えます。

wordpressuser ：MySQLWordPressユーザー。既存のユーザー名と同じであることを確認してください
wordpress_2_private_IP ： wordpress-2VPSのプライベートIP
password ：MySQLWordPressユーザーのパスワード。それが既存のパスワードと同じであることを確認してください（そしてそれが良いパスワードであることを確認してください！）

このステートメントを実行して、新しいWordPressサーバーwordpress-2から接続できるMySQLユーザーを作成します。

CREATE USER'wordpressuser ' @' wordpress_2_private_IP ' IDENTIFIED BY'password ';

繰り返しになりますが、wordpressuser、wordpress_2_private_IPの代わりに独自の値を使用し、データベースの名前が「wordpress」でない場合は、それも変更してください。

 GRANT SELECT、DELETE、INSERT、 UPDATEONwordpress 。* TO'wordpressuser'@'wordpress_2_private_IP ' ; フラッシュ特権;

これで、2番目のWebアプリケーションサーバー wordpress-2 が、データベースサーバーmysql-1上のMySQLにログインできるようになりました。

まだ負荷分散されていません

実行中の2つのWebアプリケーションサーバーがありますが、各サーバーはそれぞれのパブリックIPアドレスを介してアクセスする必要があるため、アプリケーションは負荷分散されないことに注意してください。 http://example.com/ などの同じURLを介してアプリケーションにアクセスし、2つのWebアプリケーションサーバー間でトラフィックのバランスをとることができるようにする必要があります。これがHAProxyの出番です。

HAProxyをインストールする

プライベートネットワークで新しいVPSを作成します。このチュートリアルでは、これをhaproxy-wwwと呼びます。

haproxy-www VPSで、apt-getを使用してHAProxyをインストールしましょう。

sudo apt-get update
sudo apt-get install haproxy

HAProxy initスクリプトを有効にする必要があるため、HAProxyはVPSとともに開始および停止します。

sudo vi /etc/default/haproxy

ENABLEDの値を1に変更して、HAProxyinitスクリプトを有効にします。

ENABLED=1

保存して終了します。これで、HAProxyはVPSで開始および停止します。また、serviceコマンドを使用してHAProxyを制御できるようになりました。実行されているかどうかを確認しましょう。

user@haproxy-www:/etc/init.d$ sudo service haproxy status
haproxy not running.

実行されていません。使用する前に構成する必要があるため、これで問題ありません。次に、環境に合わせてHAProxyを構成しましょう。

HAProxyの設定

HAProxyの設定ファイルは、2つの主要なセクションに分かれています。

グローバル：プロセス全体のパラメーターを設定します
プロキシ：デフォルト、リッスン、フロントエンド、およびバックエンドパラメーターで構成されます

繰り返しになりますが、HAProxyまたは基本的な負荷分散の概念と用語に慣れていない場合は、次のリンクを参照してください。HAProxyと負荷分散の概念の概要

HAProxy構成：グローバル

すべてのHAProxy設定は、HAProxy VPS、haproxy-wwwで行う必要があります。

まず、デフォルトのhaproxy.cfgファイルのコピーを作成しましょう。

cd /etc/haproxy; sudo cp haproxy.cfg haproxy.cfg.orig

次に、テキストエディタでhaproxy.cfgを開きます。

sudo vi /etc/haproxy/haproxy.cfg

globalとdefaultsの2つのセクションがすでに定義されていることがわかります。まず、いくつかのデフォルトパラメータにいくつかの変更を加えます。

defaults で、次の行を探します。

mode    http
option  httplog

どちらの場合も、「http」という単語を「tcp」に置き換えます。

mode    tcp
option  tcplog

モードとしてtcpを選択すると、レイヤー4ロードバランシングを実行するようにHAProxyが設定されます。この場合、これは、特定のIPアドレスとポートのすべての着信トラフィックが同じバックエンドに転送されることを意味します。この概念に慣れていない場合は、 Intro toHAProxyのTypesof LoadBalancingセクションをお読みください。

まだ設定ファイルを閉じないでください！次にプロキシ設定を追加します。

HAProxy構成：プロキシ

最初に追加したいのはフロントエンドです。基本的なレイヤ4負荷分散設定の場合、フロントエンドは特定のIPアドレスとポートでトラフィックをリッスンし、着信トラフィックを指定されたバックエンドに転送します。

ファイルの最後に、フロントエンドwwwを追加しましょう。必ずhaproxy_www_public_IPをhaproxyのpublicIPに置き換えてください-wwwVPS：

フロントエンドwwwbindhaproxy_www_public_IP ：80default_backendwordpress-バックエンド

上記のフロントエンド設定スニペットの各行の意味は次のとおりです。

フロントエンドwww：「www」という名前のフロントエンドを指定します。これを使用して着信wwwトラフィックを処理します
bind haproxy_www_public_IP：80 ：haproxy_www_public_IPをhaproxy-wwwのパブリックIPアドレスに置き換えます。これは、このフロントエンドがこのIPアドレスとポートで着信ネットワークトラフィックを処理することをHAProxyに通知します
default_backend wordpress-backend ：これは、このフロントエンドのすべてのトラフィックがwordpress-backendに転送されることを指定します。これは次のステップで定義します。

フロントエンドの構成が完了したら、次の行を追加してバックエンドの追加を続けます。強調表示された単語を適切な値に置き換えてください。

バックエンドワードプレス-バックエンドバランスラウンドロビンモードtcpサーバーwordpress- 1wordpress_1_private_IP ：80チェックサーバーwordpress-2 wordpress_2_private_IP ：80チェック

上記のバックエンド構成スニペットの各行の意味は次のとおりです。

backend wordpress-backend ：「wordpress-backend」という名前のバックエンドを指定します
balance roundrobin ：このバックエンドが「roundrobin」負荷分散アルゴリズムを使用することを指定します
mode tcp ：このバックエンドが「tcp」またはレイヤー4プロキシを使用することを指定します
serverwordpress-1…：「wordpress-1」という名前のバックエンドサーバー、プライベートIP（置換する必要があります）、およびリッスンしているポート（この場合は 80 ）を指定します。「チェック」オプションを使用すると、ロードバランサーはこのサーバーで定期的にヘルスチェックを実行します。
serverwordpress-2…：これは「wordpress-2」という名前のバックエンドサーバーを指定します

保存して終了します。これでHAProxyを開始する準備ができましたが、最初にロギングを有効にしましょう。

HAProxyログの有効化

HAProxyでのロギングの有効化は非常に簡単です。まず、rsyslog.confファイルを編集します。

sudo vi /etc/rsyslog.conf

次に、次の2行を見つけ、コメントを外してUDPsyslog受信を有効にします。完了すると、次のようになります。

$ModLoad imudp
$UDPServerRun 514
$UDPServerAddress 127.0.0.1

次に、rsyslogを再起動して、新しい構成を有効にします。

sudo service rsyslog restart

HAProxyログが有効になりました！ HAProxyが起動すると、ログファイルが/var/log/haproxy.logに作成されます。

HAProxyとPHP/Nginxを起動します

haproxy-www で、HAProxyを起動して、構成の変更を有効にします。

sudo service haproxy restart

新しいアプリケーションサーバーの設定方法によっては、PHPとNginxを再起動してWordPressアプリケーションを再起動する必要がある場合があります。

wordpress-2 で、次のコマンドを実行してPHPとNginxを再起動します。

sudo service php5-fpm restart
sudo service nginx restart

これで、WordPressが両方のアプリケーションサーバーで実行され、負荷分散されます。ただし、最後に行う必要のある構成変更が1つあります。

WordPress構成を更新する

WordPressアプリケーションのURLが変更されたので、WordPressのいくつかの設定を更新する必要があります。

いずれかのWordPressサーバーで、wp-config.phpを編集します。 WordPressをインストールした場所にあります（チュートリアルでは、 /var/www/example.com にインストールされていますが、インストールは異なる場合があります）。

 cd /var/www/example.com ;  sudo vi wp-config.php

上部にあるdefine('DB_NAME', 'wordpress');という行を見つけて、その上に次の行を追加し、強調表示された値に置き換えます。

 define（'WP_SITEURL'、' http：// haproxy_www_public_IP '）;  define（'WP_HOME'、' http：// haproxy_www_public_IP '）;

保存して終了します。これで、WordPress URLは、元のWordPressサーバーだけでなく、ロードバランサーを指すように構成されました。これは、wp-adminダッシュボードにアクセスしようとしたときに機能します。

負荷分散が完了しました！

これで、Webアプリケーションサーバーの負荷が分散されました。ロードバランサーのパブリックIPアドレスまたはドメイン名haproxy-wwwを介して、ユーザーが負荷分散されたWordPressにアクセスできるようになりました。

結論

これで、ユーザーの負荷が2つのWordPressサーバーに分散されます。さらに、WordPressアプリケーションサーバーの1つがダウンしても、他のWordPressサーバーがすべてのトラフィックを転送するため、サイトは引き続き利用できます。

この設定では、サイトが正しく機能するために、HAProxyロードバランサーサーバーhaproxy-wwwとデータベースサーバーmysql-1が実行されている必要があることに注意してください。

ミッチェル・アニカス

getdocs

13036