AWSクラウドで スケーラブルWebサイト を構築する(その3)

前回、スケーラブルWebサイト(その2)投稿で、次の手順を実施しました。

  • ElasticLoadBlancingを構築する
  • WordPressインストール
  • RDSのマルチAZ配置

今回は、主にSSL化の調整作業をメインに実施していきます。

設定ファイルを修正します

まず、普通のWebサイトの場合で、Webサーバが稼働しているだけでWordpressを考えない場合は、ドキュメントルートにある「.htaccess」を以下のように変更すれば大抵大丈夫かと。(ファイルが存在しなければ下の内容で生成し、元々ファイルある場合はマージ)

# SSL
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !^ELB-HealthChecker
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^/?(.*) https://%{HTTP_HOST}/$1 [R,L]
</IfModule>

そして、Wordpressサイトの場合には、 ドキュメントルートにある「.htaccess」 については同じように扱いますが、その他に「wp-config.php」に以下を追加しました。

リダイレクト設定の追加

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')  → これを追加
$_SERVER['HTTPS'] = 'on';                                         → これを追加

/*
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');   → これをコメントアウト
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/');     → これをコメントアウト
*/
define('WP_SITEURL', 'https://mikolabo.net');    → これを生かす
define('WP_HOME', 'https://mikolabo.net');      → これを生かす

SITEURL と HOME をHTTPSに強制変更します。
これにより、管理画面メニューの「設定」→「一般設定」の 「WordPress アドレス (URL)」 と 「サイトアドレス (URL)」が変更されます。

ちなみに、日々運用していくと、Wordpressのプラグインの設定影響で、 「.htaccess」「wp-config.php」とも内容が気が付かないうちに大きく変わっていたりします。

また、パーミッションの関係で、パーマリンクで不具合を誘発し、画面が表示できなくなったりと、トラブルに色々遭遇したことがあります。

ここら辺の設定は、内容が大きく変わっていることがあるかもしれないと気にしておいたほうが良いかもしれません。

Route53 のAレコードを、ELBエイリアスに変更 

上記、チェックが付いているAレコードを変更します。
ちなみに最後にあるCNAMEはサーバ証明書を登録した時に追加されたものです。

エイリアスのスイッチをONにして、

「ApplicationLoadBlancer」
「アジアパシフィック(東京リージョン)」
「ELBのDNS名」

を選択して、「保存」します。

ステッキ―セッション

こちらのスケーラブルWebサイトで構築して、思いがけずトラブルになったのが、Wordpressの管理画面にログインしても、管理機能がつかえなくなったり、SiteGuardプラグインのCaptcha(入力画面でのひらがな入力のアレです)が文字化けして入れなくなることが発生しました。

このトラブルの原因がロードバランシングによって、セッションが固定化されなくなることによるものでした。
そこで、ステッキ―セッションを設定して解決しました。

ステッキ―セッションについて

  • スティッキーセッション機能によって、ロードバランサーがセッションを特定ターゲット(EC2)だけに割り振るように設定できます。
  • スティッキーセッションを使用するには、クライアントが Cookie を有効化している必要があります。
  • Application Load Balancer は、期間ベースの Cookie か、アプリケーションベースの Cookie か、どちらかを選べます。
  • ロードバランサーが生成した Cookieは暗号化され、復号化または変更することはできません。
  • ALBは Expires 属性の代わりに Cookieヘッダーの Max-Age 属性を使用します。
    URL エンコードされた Cookie 値はサポートしません

スティッキーセッション の設定

EC2ダッシュボードを開きます。ナビゲーションで
[Load Balancing (ロードバランシング)] → [Target Groups (ターゲットグループ)] を選択します。

こちらの画面下部「attributes」タブの内容が設定内容にあたりますが、こちらは既に設定した後のイメージですが、「Edit」で変更できます。

「Stickiness」をチェックし、「Load balance ganerate cookie」をチェックして、ロードバランサーにセッション管理をさせることにしました。

セッション維持をここでは1時間にしましたが、こちらは運用を考えて設定です。

ロードバランサー配下のEC2に通信できているかの確認

WordPressは 「WordPress アドレス (URL)」と「サイトアドレス (URL)」 がアクセスURLと同じでないと画面表示してくれないので、設定後の最終形態では、EC2のパブリックDNSアドレスを指定して、EC2めがけてアクセスするようなことはできません。

ただし、以下の操作で、配下のEC2に向けた通信を確認することはできます。

オレンジのEC2インスタンスは通信不可ですが、青色のEC2インスタンスは通信OKです。

お疲れ様です。ここまでで、スケーラブルWebサイトで運用OKです!!