AWS運用〜WordPress編〜

WordPressを自社サーバーやレンタルサーバーからAWSへ移行したい、というお問い合わせを年間通していただきます。

移行元と同じ動作環境（Apache, MySQL, PHP 等）であれば問題なく動作するように思えます。
ですがAWSでは利用するサービスによっては

「アクセス出来ない！」
「コンテンツを更新したはずなのに旧コンテンツが表示されている！」

というような障害が発生します。

今回はAWS運用について、移行前に注意すべき点を一部解説していきたいと思います。

AWS運用でWordPress等が失敗する原因

レンタルサーバーからAWSへ移行する際、レンタルサーバーと比べAWSのほうが検討事項が多いため失敗する（しやすい）のではないのかと考えています。

レンタルサーバーサービスは提供業者によって異なりますが、以下のような項目の有無と増減を選択します。

ストレージ容量
ストレージのタイプ（SSD, HDD）
転送量（xxxGB/日）
サブドメイン数
サポート体制

基本的にはプラン式となっており、料金を増額するほどスペックが上がります。

AWSでは上記の項目に加え、より詳細に要件を決めることが出来ます。

コンテンツをキャッシュさせたい（CloudFront）
高可用でスケーリング可能な環境にしたい（ELB）
セキュリティ強化したい（WAF）

ユーザー（AWS利用者）は技術的な要件から、AWSサービスを取捨選択します。サービスの概要レベルで導入が決まり、ベストプラクティスや注意事項を把握していないと障害が起きる可能性があります。

WordPressをAWSで運用する際、よく使われるAWSサービスごとにまとめました。

WordPressでのAWS運用パターンその1 （CloudFront導入)

CloudFrontはAWS以外のクラウドサービスでもよく耳にするCDNサービスです。目的はいくつかありますが、Webサービスであれば以下2パターンが主な利用目的です。

◎ コンテンツをキャッシュさせたい

通常HTTPリクエストはWebサーバーが返却しますが、CloudFrontが指定されたファイルをキャッシュし、同じリクエストに対してはCloudFrontが応答します。そのためWebサーバーが都度リクエストに応える必要がなくなり、負荷軽減が見込めます。

◎ AWS発行の無料SSL証明書を使用したい

AWSにはACMと呼ばれるSSL証明書を管理するサービスがあります。CloudFront, ELB を使用していると無料で使用でき、SSL証明書の維持費や管理コスト減が見込めます。

CloudFrontを導入する場合、各AWSサービスの通信プロトコルは以下のようなイメージになります。

各サービス間の通信プロトコルが異なり、失敗するというケースがあります。

具体的にはクライアントはHTTPSでやり取りしていますが、EC2ではHTTPで通信しているような挙動をするためEC2からHTTPからHTTPSへリダイレクト要求します。クライアントはその要求通りHTTPSで通信しますが、再度EC2にはHTTP通信となり何度もリダイレクト要求が行われます（リダイレクトループ）。

この問題を解決する方法はいくつかありますがWordPressのDBに保存されている値（サイトURL）を調整するのも方法の一つです。

WordPressでのAWS運用パターンその2 （ELB導入）

ELBは高可用構成等に用いられるロードバランサーです。目的はいくつかありますが、Webサービスであれば以下2パターンが主な利用目的です。

◎ サイトのダウンタイムを限りなく減らしたい（高可用にしたい）

ELBを導入すると、クライアントとの通信はELBが行い、記事表示など実際の処理はEC2（バックエンド）が行うようになります。EC2を複数台用意することで、一つのEC2が故障しても残りのEC2が稼働しているため、ダウンタイムを削減することが可能です。

◎ クライアントとEC2を直接通信させたくない

EC2のみで構成されたWebサイトの場合、EC2がHTTPリクエストを受けるためパブリックサブネットに配置する必要があります。外部にさらされるため、セキュリティ要件上問題があるWebサイトはELBを導入する場合があります。

ELBを導入する場合、以下のような構成になります。

上記構成でも問題ないシステムはありますが、WordPressの場合以下のような問題点があります。
※基本的にデータ整合性に関する問題です。

◎ DBの整合性が取れない

WordPressは記事情報等、動的コンテンツに使用するデータはDBに保存されます。EC2にDBをインストールしている場合、DB間の同期が取れていないと正しい記事が表示出来ません。

DBの同期ツールは製品として存在しますが、WordPress等の中・小規模のシステムにはコストに見合いません。そのためDB用のサーバを用意して一元化させます。DBサーバ用のEC2を用意しても良いですが、一般的にRDSの利用が推奨されています。

このような構成にすることで、DBの整合性が取れないという事態を防ぐことが出来ます。

◎ セッションの整合性が取れない

PHPのセッションは通常、一時ファイルとしてWebサーバ（今回はEC2）に保存されます。ELBを導入すると、どのEC2にリクエストをするか選択することが出来ず、以前のセッションを利用出来ない可能性があります。
※スティッキーセッションを使用することで、ある程度固定化出来ますが推奨されていません。

セッションを利用したシステムの場合

急にログインしていない状態になる
正常に処理が終了しない

などの問題が発生します。

そのためDBと同様セッション用のなにかを用意する必要があります。複数方法はありますが、ターン・アンド・フロンティアではElastiCacheを推奨しています。

このような構成にすることで、セッションの整合性が取れないという事態を防ぐことが出来ます。
※PHP側の設定変更（session.save_path 等）も必要となります。

◎ ファイルの整合性が取れない

WordPressでメディアを追加すると、EC2のuploadsフォルダにデータが保存されます。処理自体は正常に終了しますが、記事参照する際保存されていないEC2のほうが画像に関するリクエストを受けると、メディアが存在しないため404エラーを返却します。

今回深く触れませんが、メディアをEC2ではなくオブジェクトストレージのS3に保存するプラグインがあるようです。

WordPressでのAWS運用パターンその3 （WAF導入）

IDS, IPS として用いられるWAFにも注意が必要です。

AWS WAFでは以下のような内容を検知・ブロック出来ます。

悪意のある可能性が高いスクリプト。攻撃者は、ウェブアプリケーションの脆弱性を悪用できるスクリプトを埋め込みます。これはクロスサイトスクリプティング（XSS）と呼ばれます。

リクエストの発生元の IP アドレスまたはアドレス範囲。

リクエスト送信元の国または地理的場所。

クエリ文字列など、リクエストの指定した部分の長さ。

悪意のある可能性が高い SQL コード。攻撃者は、ウェブリクエストに悪意のある SQL コードを埋め込むことで、データベースからデータを抽出しようとします。これは SQL インジェクションと呼ばれます。

リクエストに表示される文字列。たとえば、User-Agent ヘッダーに表示される値、またはクエリ文字列に表示されるテキスト文字列です。正規表現を使用してこれらの文字列を指定することもできます。

WAF 開発者ガイド

基本的にWAFはWordPressに影響を与えませんが、XSSのみ影響が出やすいと報告があります。管理画面（wp-admin内）の制御にXSSに該当するような処理が入っているらしく、もしXSSを検知・防御したい場合、管理画面は例外的に検知しない設定が必要となります。