アリババクラウドECSとWordPressを利用したサーバークラスタの設定～パート１

このチュートリアルでは、**アリババクラウド**のサーバー準備から、**アリババクラウドECS**と**WordPress**を使用して**サーバークラスタ**を設定する方法を発見します。

*本ブログは英語版からの翻訳です。オリジナルは[こちら](https://www.alibabacloud.com/blog/setting-up-a-server-cluster-for-enterprise-web-apps--part-1_584040)からご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。*

[Alibaba Cloud Tech Share](https://www.alibabacloud.com/campaign/techshare?spm=a2c65.11461447.0.0.34ad1729jhy8jr)執筆者、Jeff Cleverley。

このシリーズのチュートリアルでは、高トラフィックの Web アプリケーションや企業のビジネスサイトに適した水平方向にスケーラブルなサーバクラスタをセットアップします。クラスタは 3 台の Web アプリケーションサーバと 1 台のロードバランシングサーバで構成されています。クラスタ上にWordPressを設定してインストールしますが、実際のクラスタ構成はPHPベースのWebアプリケーションに適しています。

各サーバーは LEMP スタック (Linux, Nginx, MySQL, PHP) を実行します。サーバー間のリアルタイムのデータベース同期を提供するMySQLの代替として、[Percona XtraDB Cluster](https://www.percona.com/software/mysql-database/percona-xtradb-cluster?spm=a2c65.11461447.0.0.34ad1729jhy8jr) Databaseを使用します。ウェブアプリケーションのファイルレプリケーションとサーバー間の同期には、[GlusterFS](https://www.gluster.org/?spm=a2c65.11461447.0.0.34ad1729jhy8jr)を使用します。

###ロードバランサーとしてのNGINX
ロードバランサーとしては、HTTPS終了も行う軽量なNginxサーバーを利用する予定です。このタスクは[Alibaba Cloud Server Load Balancer](https://www.alibabacloud.com/product/server-load-balancer?spm=a2c65.11461447.0.0.34ad1729jhy8jr)で完了することができますが、HTTPSの終端とSSLを制御したいと考えています。そのため、別のサーバをプロビジョニングして、この作業を行うためにどのように設定できるかを実演します。Let's Encryptを使用して、ロードバランサーにSSL証明書を発行します。

クラスタの初期設定では、以下のように3つのアプリケーションサーバ間でHTTPリクエストの負荷を均等にバランスさせます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/789e88a3-57d2-202c-cf4d-2bdf0ad1646d.png)


<ロードバランサを搭載した3ノードサーバクラスタ>を均等にバランスよくさせています。

これは、サーバーのいずれかに障害が発生した場合や、サーバーのアップグレードを行いたい場合に優れた冗長性を提供する素晴らしい構成です。しかし、ロードバランシングを使用してサーバークラスタを使用する他の利点の1つは、各サーバーへのトラフィックを「重み付け」したり、特定のトラフィックを個々のノードにルーティングすることができることです。

Web アプリケーションが Enterprise で何らかの規模で使用されている場合、Web アプリケーションの管理者または他のバックエンドアプリケーションのユーザーが大量のデータ処理やその他の CPU 集中タスクを実行している可能性が高いです。またWeb アプリケーションの管理者側で発生している可能性のあるインポートやエクスポート、計算の実行などのバッチ処理ジョブは、サーバーのリソースを過剰に利用し、サイトの「訪問者が直面している」フロントエンドの速度低下につながる可能性があります。

サーバークラスタと効果的なロードバランシングを使用して、これらの問題を分離するソリューションを構築することができます。管理者とバックエンドユーザーのトラフィックを1台のサーバーに誘導し、そこでバッチ処理やその他の集中的なタスクを実行し、他のすべてのサイト訪問者とウェブトラフィックを他のサーバーに誘導します。データベースとファイルのレプリケーションのための効果的なソリューションがあり、3台のサーバーが同期されているので、ウェブトラフィックは影響を受けず、管理ノードで行われている作業の結果を受け取ることができます。

このようなソリューションは、次のように可視化することができます。



![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/c61df8e5-1089-3f5b-575a-77949e398b37.png)


<管理者のトラフィックをリダイレクトするロードバランサを搭載した3ノードクラスタ>

上からわかるように、ノード1は管理用にのみ使用され、ノード2と3はウェブトラフィックを提供します。

これらのチュートリアルでは、両方の方法でクラスタを設定していきます。

この一連のチュートリアルでは、私は`root`ユーザーを使用します。もしスーパーユーザを使用している場合は、必要に応じてコマンドの前に `sudo` コマンドを追加することを忘れないでください。私はまた、テストドメイン `yet-another-example.com` を使用しますが、コマンドを発行する際には、これをあなたのドメインに置き換えることを忘れないでください。

コマンドの中では、私のサーバのプライベートとパブリックのIPアドレスを使用しています。

###ステップ1：アリババクラウドコンソールでは
**サーバーの準備**
あなたのニーズに最も適したサイズの Alibaba インスタンスを 4 台プロビジョニングする必要があります。

これらのチュートリアルの目的のために、各サーバが作成されたときに、公開SSH鍵をアップロードしておく必要があります。

クラスタ内での役割をより明確に示すために、それぞれのホスト名を変更するのがベストです。私は以下のホスト名を選択しました。

- ノード1
- ノード1
- ノード2
- ロードバランサー

4 つの異なるサーバ上でターミナルで作業するので、間違ったインスタンスでコマンドを発行しないように、適切な名前を付けておくのがベストです。

そのためには、それぞれのサーバの情報を変更をクリックして、それぞれに適切なホスト名を与えます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/ddcf2d57-a6e5-cdb6-b0ea-ee7ba300fea3.png)


<各サーバーの情報を変更します>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/1e6cc44c-2d78-0a6d-a1c8-244e6cc9759e.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/ef98ccfa-740a-545b-0f6f-23e2fd7e08e1.png)


<クラスター内の各サーバに適切な名称を付与してください>

また、各サーバーのプライベートIPアドレスを記録しておく必要があります。

**セキュリティグループのポートを開く**
通常のポートに加えて、いくつかのポートを開く必要があります。これらのポートは、各ノードの Persona XtraDB クラスタデータベースがプライベート IP アドレスを介して他のノードと通信するために必要です。Perconaは以下のポートを開く必要があります。

- 3306 TCP インバウンド/アウトバウンド (標準 MySQL ポート)
- 4444 TCPインバウンド/アウトバウンド（Perconaクラスタポート)
- 4567 TCP インバウンド/アウトバウンド（Percona クラスタポート)
- 4568 TCP インバウンド/アウトバウンド（Percona クラスタポート)
セキュリティグループの受信ポートの設定は以下のようになっているはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/1f3da380-8ac7-46ab-b649-78679b8a2356.png)

<セキュリティグループ受信ポートの構成>について

セキュリティグループの送信ポートの設定は以下のようになるはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/a10ceda0-33cd-316a-5540-a44601f06031.png)


<セキュリティグループ送信ポートの構成>について

**ドメインを追加する**
アリババクラウドDNSで使用するドメインを追加する必要があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/f4213c5a-9185-e625-dc6d-221060fe2092.png)


<ドメイン追加>

A'レコードには、ロードバランサーとして動作するサーバーのパブリックIPアドレスを設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/d1a70029-fca4-d4b9-bf43-1dabf858c428.png)

<ロードバランシングサーバのIPアドレスを持つレコードを追加します>

www'ホストの'CNAME'レコードを追加することを忘れないようにしてください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/f1f4cd11-25bd-5dba-1290-66a0c2bc627b.png)

WWWホストの記録も追加してください。

###ステップ2: Percona XtraDBクラスタのインストールと構成
Perconaは、MySQLの代替として最適化された優れたドロップインを提供しています。今日のチュートリアルでは、データベースのレプリケーションと同期のために特別に作成されたPercona XtraDB Clusterを使用します。

Percona：
"Percona XtraDB Cluster は、MySQL ® クラスタリングのためのアクティブ/アクティブな高可用性と高スケーラビリティのオープンソースソリューションです。Percona Server と Percona XtraBackup を MySQL 高可用性ソリューションの Codership Galera ライブラリに統合し、単一のパッケージでコスト効率の高い MySQL 高可用性クラスタを作成することができます"

その前に
**プライベートネットワークが機能していることを確認します。**
各ノードにログインします。

`$ ssh root@node_public_ip_address`

各サーバノードでは、'ping'を使用して他のノードにpingしてみてください。私の場合はnode1からnode2にpingします。

`# ping 172.20.213.159`

プライベートネットワーク接続をしている場合は、パケットの送受信を確認するメトリクスが表示されるはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/57b0d922-35bc-4542-2fe1-9cf1e368960d.png)

<各ノードから他のノードのプライベートIPアドレスをPingします>

**Percona XtraDB クラスタのインストール**
各ノードで、次のコマンドを実行します。

```
# wget https://repo.percona.com/apt/percona-release_0.1-4.$(lsb_release -sc)_all.deb
# dpkg -i percona-release_0.1-4.$(lsb_release -sc)_all.deb
# apt-get update
# apt-get upgrade
```

そして最後にパッケージをインストールします。

`# apt-get install percona-xtradb-cluster-57`

インストール中に、クラスタの新しい root パスワードを設定するように求められます。各インストールで同じルートパスワードを使用するようにしてください。

**データベースレプリケーションの設定**
**レプリケーションユーザーの作成**

これを行うにはレプリケーションユーザが必要ですが、これを設定する必要があるのはnode1のみです。

ルートパスワードを使用して MySql にログインします。

`# mysql -u root -p`

レプリケーションのために新しいユーザーとユーザーパスワードを作成してください。強力なパスワードを使用する必要があります。

`CREATE USER 'new_user'@'localhost' IDENTIFIED BY 'new_users_password’.`

ここで、レプリケーションユーザが必要とするすべての権限を付与します。

`GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'new_user'@'localhost’.`

その後、特権をフラッシュして終了します。

```
FLUSH PRIVILEGES;
EXIT;
```

あなたの端末はこのようになっているはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/9e789e15-dc6b-c8a1-561d-fb7d03085bfa.png)


<データベースレプリケーションユーザを作成します>

**レプリケーション設定ファイルのカスタマイズ**

各ノードで 'wsrep.cnf' レプリケーション設定ファイルを開いて編集します。

`# nano /etc/mysql/percona-xtradb-cluster.conf.d/wsrep.cnf`

以下のように若干異なるパラメータを入力する必要があります。

1、すべてのノードの設定ファイルで、wsrep_cluster_addressに3つのプライベートIPアドレスをカンマで区切って入力します。
2、wsrep_node_addressにそのノードのプライベートIPアドレスを入力します。
3、wsrep_node_nameには別のノード名を入力します。
4、各ノードの設定ファイルでwsrep_sst_authのsstパスワードを入力します。

以下の通りです。

**ノード1の設定**

```
[mysqld]
# Path to Galera library
wsrep_provider=/usr/lib/galera3/libgalera_smm.so

# Cluster connection URL contains IPs of nodes
#If no IP is found, this implies that a new cluster needs to be created,
#in order to do that you need to bootstrap this node
wsrep_cluster_address=gcomm://172.20.62.56,172.20.213.159,172.20.213.160

# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW

# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB

# Slave thread to use
wsrep_slave_threads= 8

wsrep_log_conflicts

# This changes how InnoDB autoincrement locks are managed and is a requirement $
innodb_autoinc_lock_mode=2

# Node IP address
wsrep_node_address=172.20.62.56
# Cluster name
wsrep_cluster_name=pxc-cluster

#If wsrep_node_name is not specified,  then system hostname will be used
wsrep_node_name=pxc-cluster-node-1

#pxc_strict_mode allowed values: DISABLED,PERMISSIVE,ENFORCING,MASTER
pxc_strict_mode=ENFORCING

# SST method
wsrep_sst_method=xtrabackup-v2

#Authentication for SST method
wsrep_sst_auth=new_user:new_users_password
```

**ノード2の設定**

```
[mysqld]
# Path to Galera library
wsrep_provider=/usr/lib/galera3/libgalera_smm.so

# Cluster connection URL contains IPs of nodes
#If no IP is found, this implies that a new cluster needs to be created,
#in order to do that you need to bootstrap this node
wsrep_cluster_address=gcomm://172.20.62.56,172.20.213.159,172.20.213.160

# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW

# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB

# Slave thread to use
wsrep_slave_threads= 8

wsrep_log_conflicts

# This changes how InnoDB autoincrement locks are managed and is a requirement $
innodb_autoinc_lock_mode=2

# Node IP address
wsrep_node_address=172.20.213.159
# Cluster name
wsrep_cluster_name=pxc-cluster

#If wsrep_node_name is not specified,  then system hostname will be used
wsrep_node_name=pxc-cluster-node-2

#pxc_strict_mode allowed values: DISABLED,PERMISSIVE,ENFORCING,MASTER
pxc_strict_mode=ENFORCING

# SST method
wsrep_sst_method=xtrabackup-v2

#Authentication for SST method
wsrep_sst_auth=new_user:new_users_password
```

ノード3 の設定

```
[mysqld]
# Path to Galera library
wsrep_provider=/usr/lib/galera3/libgalera_smm.so

# Cluster connection URL contains IPs of nodes
#If no IP is found, this implies that a new cluster needs to be created,
#in order to do that you need to bootstrap this node
wsrep_cluster_address=gcomm://172.20.62.56,172.20.213.159,172.20.213.160

# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW

# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB

# Slave thread to use
wsrep_slave_threads= 8

wsrep_log_conflicts

# This changes how InnoDB autoincrement locks are managed and is a requirement $
innodb_autoinc_lock_mode=2

# Node IP address
wsrep_node_address=172.20.213.160
# Cluster name
wsrep_cluster_name=pxc-cluster

#If wsrep_node_name is not specified,  then system hostname will be used
wsrep_node_name=pxc-cluster-node-3

#pxc_strict_mode allowed values: DISABLED,PERMISSIVE,ENFORCING,MASTER
pxc_strict_mode=ENFORCING

# SST method
wsrep_sst_method=xtrabackup-v2

#Authentication for SST method
wsrep_sst_auth=new_user:new_users_password
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/b299da87-caf8-eaec-ff5b-f748ddfdaae9.png)

<すべてのノードのプライベートIPアドレスを入力してください>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/606f1403-e2af-8a5d-e1f5-87fac7d2193e.png)


<ノード1の設定>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/33c8290e-1afb-08e6-bb29-88633c08b63e.png)

<ノード2の設定>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/5aa2f125-2653-20a4-f222-870d21cd9b9e.png)

<ノード3の設定>

**クラスタのブートストラップ**
ノード1で以下のコマンドを実行してクラスタをブートストラップします。

`# /etc/init.d/mysql bootstrap-pxc`

端末はOKの返事をしてくれるはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/634ed76b-969d-a911-0185-d8d20de66b37.png)

<ノード1上のクラスタをブートストラップします>

実行中であることを確認するには、私のsqlにログインして以下のように実行することで、今でも、いつでも確認することができます。

`show status like 'wsrep%’.`

次にノード2とノード3で以下を実行します。

`# /etc/init.d/mysql start`

各サーバでは、端末は OK で応答するはずです。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/8e127a2f-8681-cae3-80dd-ef513a069642.png)


**Perconaクラスタの他の2つのノードを起動します。**

**データベースのレプリケーションをテスト**
これで、3つのノードを持つPerconaデータベースクラスタが完成したはずですが、テストしてみましょう。

各ノードで、mysql にログインします。

`# mysql -u root -p`

各ノードでデータベースを表示します。

`SHOW DATABASES;`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/e72d99f0-b447-acf1-d391-a5b1da534c55.png)

<ノード1のデータベース>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/13f5a630-116b-ea80-0797-d5efd068cce2.png)

<ノード2のデータベース>

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/5699f789-ddc3-caa6-2731-5008296ac613.png)

<ノード 3のデータベース>

ノード1のみで、'test_sync'という名前の新しいデータベースを作成します。

`CREATE DATABASE test_sync;`

これを行った後、ノード2とノード3で再びデータベースを表示します。

`SHOW DATABASES;`

これで、ノード1で作成した'test_sync'データベースがノード2とノード3の両方にレプリケートされていることがわかるはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/5925bed7-45f2-cbaa-de4b-37aa284f66c0.png)

**Test_syncがノード2にレプリケートされました。**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/3d64e3bb-f70a-be40-a807-2d8acc257d8d.png)

Test_syncがノード3にレプリケートされました。

成功、データベースレプリケーションができました。

###ステップ3: GlusterFSファイルネットワークのインストールと設定
クラスタは、クラウドストレージやメディアストリーミングなどのデータ集約的なタスクのためのオープンソースのソフトウェアで、スケーラブルなネットワークファイルシステムです。

GlusterFSを使用することで、各ノードが同じファイルで動作することが保証され、冗長性によるデータの安全性も確保されます。クラスタでは各ファイルにトリプル冗長性を使用しています。つまり、3ノードのクラスタでは各ノードがすべてのファイルのコピーを持っていることになりますが、ノード数を増やすとスペースの節約につながります。

**GlusterFSのインストール**
**<すべてのノード>**

まず、拡張ファイルシステムで使用するUbuntuの「attr」パッケージをインストールします。

`# apt-get install attire`

次にGlusterFSをインストールします。

`# apt-get install glusterfs-server`

**Glusterボリュームを作成し、ディレクトリをアタッチ**

ノード1

他の2つのノードのプライベートIPアドレスを使用して、以下のコマンドを実行します。


```
# gluster peer probe 172.20.213.159
# gluster peer probe 172.20.213.160
```

Peer probeは、このような成功メッセージで応答する必要があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/b3ac74ed-c518-8311-b0e3-04e4092c36e7.png)


**Gluster Peer Probeの成功**

その後、3ノードすべてのプライベートIPアドレスを使用して、以下のコードでGlusterボリュームを作成します。

`# gluster volume create glustervolume replica 3 transport tcp 172.20.62.56:/gluster-storage 172.20.213.159:/gluster-storage 172.20.213.160:/gluster-storage force`

そして、ボリュームを開始します。

`# gluster volume start glustervolume`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/6fd35c7b-7da0-2753-29c6-90a4f83ff31e.png)

<クラスターボリュームの作成と開始について>

**<すべてのノード>**

これで、ディレクトリを `glustervolume` にリンクする準備ができました。

そのためには、各ノードの `/var/www/` ディレクトリにウェブアプリケーションのルートディレクトリを作成します。

`# mkdir /var/www/yet-another-example.com -p`

ディレクトリをマウントして、`glustervolume`にリンクします。

`# mount -t glusterfs localhost:/glustervolume /var/www/yet-another-example.com`


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/4635b6ad-6e63-745a-55a4-0cf5d21b9b13.png)

<各ノードにWebアプリケーションのルートディレクトリを作成し、連携>

**テストファイルの複製**
これで GlusterFS クラスタファイルサーバができ、そこに Web アプリケーションの WordPress をインストールできるようになりました。しかし、その前にテストをしてみましょう。

**<任意のノードにおいて>**

マウントされた`/var/www/yet-another-example.com`ディレクトリ内にテストファイルを作成します。

`# touch /var/www/yet-another-example.com/test.html`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/0211029a-ce53-a2fa-4714-96ed9f253cfa.png)

<1つのノードにテストファイルを作成します>

**<別のノードで>**

他のノードでは、マウントされたディレクトリを変更して、'test.html' ファイルが複製されていることを確認するためにコンテンツをリストアウトします。

`# cd /var/www/yet-another-example.com && ls`

すべてが動作していれば、他のノードのディレクトリに最初のノードで作成されたテストファイルが表示され、このようなものが表示されるはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/80d888e8-9ee0-cd22-e787-39df0d7e6b03.png)

<他のノードにレプリケートされているかどうかを確認します>

###成功です!
これで、Percona XtraDB ClusterとGlusterFSのおかげで、データベースのレプリケーションと分散ファイルシステム(冗長性を持つ)が動作するサーバーのクラスタができました。

[次のチュートリアル](https://www.alibabacloud.com/blog/setting-up-a-server-cluster-for-enterprise-web-apps--part-2_584446?spm=a2c65.11461447.0.0.34ad1729jhy8jr)では、PHP7とNginxをインストールしてLEMPスタックのインストールを完了させます。次に、WordPressをインストールする前に、それぞれのノードサーバのNGINXバーチャルホスト、ロードバランサのNginx設定、SSL証明書の設定を行います。パート2が終わる頃には、HTTPSでWordPressを動作させている負荷分散されたサーバクラスタが完全に動作するようになるでしょう。

最後のチュートリアルでは、1つのノードにリソースの多い管理者アクセスを確保し、他の2つのノードは訪問者アクセス用にウェイトを置くようにクラスタを再構成します。また、FastCGI キャッシングを有効にし、データベースポートを保護し、GlusterFS ファイルシステムへのアクセスを制限することでクラスタを強化します。

*アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
[アリババクラウドジャパン公式ページ](https://www.alibabacloud.com/ja)*