AWSにWordPress3.8をインストールしてみた – その2

2014.02.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは 大場 です。

前回は"AWSにWordPress3.8をインストールしてみた – その1"で、Single-AZのシンプルな構成でWordPressをインストールする方法を紹介させていただきました。今回はこの環境でS3を使ってサーバの負荷を下げたり、ELBを使って負荷分散したりする方法をご紹介します。構成のイメージとしては以下の通りです *1

wp-test10

ステップとしては以下の通りです。

メデイアファイルをS3に保存できるようにする

通常はWordPressサーバ上に保存されるメディアファイルを、S3上に保存できるようにするために"Amazon S3 for WordPress"プラグインをインストールします。このプラグインをインストールすることで、追加されるメディアは自動的にS3と同期され、WordPressサイトへのアクセスがあった際にメディアはS3から提供されるようになります。これでサーバはメディア提供をS3に任せるために処理負荷を下げることができるのと同時に、メディアファイルをより確実(S3の耐久性は99.999999999%)に保存しておくことが可能になります。

手順は以下の通りです。

WordPress管理画面の[プラグイン]-[新規追加]から ”Amazon S3 for WordPress” を検索して「いますぐインストール」を左クリックします。

wp-test11

すると、以下のような画面が表示されます。これはプラグインのインストール時に実行されるスクリプトの実行ユーザと、ファイルやフォルダのオーナーが違うことに起因するようです。

wp-test12

以下の通り/var/www.html配下のファイルのオーナーを変更することで対処しました。

$ cd /var/www/
$ ls -l | grep html
drwxr-xr-x 3 root root 4096 Jan 23 20:44 html
$ sudo chown -R apache:apache html

上記のオーナー変更後に、再度プラグインのインストールを実施すると以下の画面が表示されますので「プラグインを有効化」を左クリックします。

wp-test13

WordPress管理画面から[設定]-[Amazon S3]で AWS Access Key ID と Secret Key を入力して「Authenticate Account」ボタンを左クリックします。

wp-test14 wp-test15

以下を設定して「Save」ボタンを左クリックします。 ・ Use this bucket: 使用するS3のバケットを選択 ・ File Uploads: S3連携の有効/無効

wp-test16

簡単ですが、プラグインについてはこれで準備完了です。 さっそく、新しく投稿してみます。テスト投稿の第2弾は「牛肉どまん中弁当」 *2

wp-test17

投稿した記事の画像上でカーソルを止めてみると *3、WordPressサーバからではなく、プラグインの設定で指定したS3上のバケット”wptest-001”にリンクが張られていることが確認できました。

wp-test18

さらに、AWSコンソール上からS3のバケットを見てみると画像データがアップされていることが確認できました。

wp-test19

Multi-AZ+ELBで冗長構成にする

ここからは、Multi-AZ構成でさらに冗長性を高めるとともに、ELBを利用して負荷分散をおこなう手順を紹介します。

ロードバランサの作成

はじめに、ロードバランサを作成して、その配下に既存のWordPressサーバを配置してみます。 *4

AWSマネジメントコンソールでEC2サービスを選択して、左側のメニューから “Load Balancer” を選択し「Create Load Balancer」ボタンを左クリックします。

wp-test20

以下を設定します(それ以外はデフォルト)。 ・ Load Balancer Name: ロードバランサの名前 ・ Create LB inside: ロードバランサを配置するVPC

wp-test21

Ping Pathで、Health Checkに使用するパスを “/index.html” から “/” に変更します。それ以外は、デフォルトでもいいのですがチェックが早く済むように “Health Check Interval” や “Healthy Threshold” を短く設定しています。 *5

wp-test22

EC2を配置するサブネットを選択します。冒頭に記載した構成イメージに従って “10.0.1.0/24” と “10.0.2.0/24” のサブネットを選択します。

wp-test23

ELBにセキュリティグループを割り当てます。ここでは、HTTPを通すセキュリティグループを選択しています。

wp-test24

該当するインスタンスにチェックをします。

wp-test25

設定の確認をして「Create」ボタンを左クリックします。

wp-test26

正常に作成されたことを確認して「Close」ボタンを左クリックします。

wp-test27

数分待った後、作成したロードバランサのInstancesタブのStatusがIn Serviceになっていることを確認します。

wp-test28

DescriptionタブからDNS Nameを確認してコピーしておきます。

wp-test29

WordPress管理画面の[設定]-[一般]から、Wordpressアドレス(URL)とサイトアドレス(URL)をELBのDNS Nameに変更します。

wp-test30

インスタンスのコピー

ここまで作成したインスタンスを、別のAZ上にコピーしてロードバランサ配下に配置します。

AWSマネジメントコンソールでEC2サービスを選択して、左側のメニューから “Instances” を選択します。該当するインスタンス上で右クリックし、「Create Image」を左クリックして AMI を作成します。

wp-test31

イメージ作成のリクエストが受理されていることを確認します。

wp-test32

左側のメニューから “AMIs” を選択して、作成したAMIのステータスが available になるまで待ちます。

wp-test33

ステータスがavailableになったら、「Launch」ボタンを左クリックしてインスタンスを作成します。作成するまでの手順はEC2の起動と同様なので割愛します。

wp-test34

インスタンスが立ち上がったら、左側のメニューから “Load Balancer” を選択し、WP-LBのInstancesタブから、作成したインスタンスを追加します。

wp-test35

追加した後、それぞれのインスタンスのStatusがIn Serviceになっていることが確認できれば終了です。

wp-test36

まとめ

ここまでで EC2+RDS+ELB+S3 を使ったWordPressの構成ができあがりました。気が付いたら画像が盛りだくさんになっていますが、チュートリアル的な感じで使っていただけると嬉しいです。 次回は、独自ドメインでサイトを公開するところまでやってみたいと思いますので、引き続きよろしくお願いします。それでは。

脚注

  1. Route53を使って独自ドメインで公開するところまでやりたかったのですが、今回そこまで書ききれませんでした。そこは次回紹介したいと思います。
  2. 先日実家へ帰ったときに山形新幹線つばさで食べました。
  3. ブラウザはChromeを使用。
  4. WordPressでは、WordPress・サイトアドレスをデータベース上に保持しており、ここにはサーバのパブリックIPアドレスが含まれています。今回の構成ではEIPを使っていない関係上、EC2の停止/起動のタイミングでIPアドレスが変わってしまい、WordPress・サイトアドレスとの整合性がとれなくなる問題が発生します。DBを直接書き換えて解決することもできますが、少々面倒なので、先にELBを構成してしまい、WordPress・サイトのアドレスにELBのDNS Nameを設定する作業を先にやってしまいまうことにします。先にインスタンスをコピーするのが自然な流れかと思いますが、前述の理由でELBを先に構成しています。
  5. 今回は動作確認が目的ですので。