AWS再入門2018 WordPress on AWS編

こんにちは、池田です。ついにAmazon Echo Plusの購入招待メールが届きました。それはもう、宝くじで100,000円以上に当選したくらいにテンションがあがりました（実際には、宝くじで5桁以上の当選をしたことがないので想像なんですけれど）。

2018/07/13 追記：EFSが東京リージョンでも提供開始されたので、一部追記しています。

今回もAWSホワイトペーパーからのネタとなります。WordPress:Best Practices on AWSを読み、紹介されていたベストプラクティスについて筆者なりにまとめてみましたのでご紹介したいと思います。興味のある方はぜひ原文にも目を通してみてください。

もくじ

• AWSでWordPressを構築する3つの基本的な方法
• Amazon Lightsail
• 複数サーバでの運用
• AWS上にWordPressを構築するメリット
• ステートレスな構成を維持するために
• 更なる負荷対策
• ステートレスなデータベース
• まとめ

AWSでWordPressを構築する3つの基本的な方法

• Amazon Lightsail
• Amazon EC2
• AWS Marketplace

Lightsailによる構築が（単一サーバによるWordPress構築の場合）推奨されています。

Amazon Lightsail

AWS re:Invent 2016のキーノートで発表されたVPSサービス。リリース後はストレージの追加ができるようになったり、Windows Serverやロードバランサの利用が可能となるなど機能が強化されています。 単一サーバによるWordPressの運用なら低コストながらも、非常に簡単な手順でデプロイできる手頃なサービスです。 参考: 【速報】VPSサービスであるAmazon Lightsailが発表されました #reinvent

複数サーバでの運用

単一サーバでのWordPress運用では不十分な場合は、各種AWSリソースをうまく組み合わせたアーキテクチャによる構築が必要となります。 GitHubに公開されているベストプラクティスにはCloudFormationテンプレートが含まれているので、すぐに利用が可能です。 このベストプラクティスは以下のような構成になっています。 Figure 2: Reference architecture for hosting WordPress on AWS

この図を簡単に説明するとおよそ以下の通りです。

• Amazon CloudFrontにエンドユーザが頻繁にアクセスするコンテンツをキャッシュさせています。
• CloudFrontは、S3バケットから静的コンテンツ、Application Load Balancerを経由してWebサーバから動的コンテンツを取得しています。
• WebサーバはAuto Scaling groupで実行されたAmazon EC2インスタンスで構成されます。
• 頻繁にリクエストされるデータはElastiCacheにキャッシュさせ、レスポンスを向上させます。
• WordPressのデータベースはAmazon Aurora MySQLを利用します。
• EFSファイルシステムを利用し、異なるAZに配置されたEC2インスタンスがWordPressのデータを共有できるようマウントしています。
• EFSはまだ利用可能なリージョンが限られています。ご注意ください。提供リージョンはこちらでご確認ください。→ 2018/07 東京リージョンでも提供が開始されました。
• VPC内に配置された各リソースがインターネットと通信できるよう、インターネットゲートウェイを配置しています。
• NATゲートウェイを配置することにより、プライベートサブネットに配置されたEC2インスタンスがインターネットと通信できるようにしています。
• VPC内にはパブリックサブネットと2つのプライベートサブネット（アプリケーションサブネットとデータサブネット）が配置されています。
• パブリックサブネットにはApplication Load Balancerと管理用の踏み台サーバが配置されています。
• プライベートサブネットのうちアプリケーションサブネットには、WordPressが実行されるEC2インスタンスが配置されています。
• データサブネットには、ElastiCache、Aurora MySQLとEFSマウントターゲットが配置され外部からの通信より保護されています。

AWS上にWordPressを構築するメリット

• パフォーマンスとアクセス負荷、コストの両面から適したインスタンスタイプを選択し、自由に変更できます。
• コンピューティングに最適化されたC4系などは、WordPressを利用する場合の良い選択肢であると紹介されています。
• 複数AZにインスタンスを配置することによる可用性の向上、システム全体の信頼性向上が期待できるようになります。
• EC2インスタンスをroot権限で管理できることで、必要なコンポーネント、ソフトウェアの導入やカスタマイズが行えます。
• 構築、カスタマイズを終えたインスタンス構成をAMIとして保存することで、同一構成のインスタンス複製が容易になります。
• Application Load Balancerを利用することにより、アクセス負荷の分散が実現できます。
• 必要に応じてHTTPとHTTPSコンテンツを異なるドメイン、EC2インスタンスで運用することも可能になります。
• もしEC2インスタンスに障害が発生した場合にも、ヘルスチェック機能により自動的な障害インスタンスの切り離しと、健全なインスタンスの起動/追加が行えるようになります。
• Auto Scalingの機能によって、負荷状況や運用計画に合わせたEC2インスタンスの増減を自動的に行えるようになります。
• 適切な条件設定により、機会損失を回避しつつもコストの最適化を実現できます。

ステートレスな構成を維持するために

Auto Scalingによって複数のWebサーバを利用する上で、セッション情報を保持せず、どのWebサーバへアクセスしても問題が生じないことは重要な要素になります。 WordPressにおいて、通常のユーザセッションはCookieに依存するため問題はありませんが、ネイティブPHPセッションに依存しないWordPressプラグインの導入やカスタマイズを行なう場合には注意が必要となります。 しかし、もともとWordPressは単一サーバでの運用を前提として設計されているため、いくつかのファイルはWebサーバのローカルに保存されるほか、複数サーバ運用を行なった際に発生する、いくつかの矛盾が原因のトラブルがあります。

アップロードされた画像ファイルの行方問題

複数サーバでWordPressを運用する上で生じる代表的な問題として、ユーザがアップロードした画像ファイルがあります。 これは、複数サーバで構成されていても、ユーザはその中のひとつのWebサーバと通信を行う中でファイルを転送し、そのWebサーバのみがファイルを受け取ることにより発生するものです。 WebサーバとしてのEC2インスタンスの負荷を軽減しつつ、受け持つWeb層をステートレスにする必要があります。 ベストプラクティスとして紹介した構成をよく見ると、この矛盾を回避するためにAuroraやEFSを利用しています。

ステートレスなWebサーバとするには

つまり、WordPress本体やプラグインなどインストールディレクトリ全体をEC2インスタンス間で共有できるEFS領域に保存することで、ユーザリクエストを受け付けたEC2インスタンスに依存しない処理を実現しています。 さらに、この構成としたことにより、新しいインスタンスを起動するたびにプラグインやテーマのインストールをする必要もなくなり、障害発生からのリカバリやスケールアウトも迅速に行えるようになっています。 ※最適なパフォーマンスを確保するには、AWS Reference Architecture on WordPressのAmazon EFSおよびOPcacheの推奨設定を確認してください。

更なる負荷対策

運用するWordPressサイトが多くのアクセスを受け取るようになると、ここまでに紹介した負荷分散やスケーリング対応だけでは間に合わなくなることがあるかもしれません。 しかし、このホワイトペーパーでは更なる負荷対策が紹介されています。

you can offload the work associated with serving your static assets to Amazon S3 and CloudFront, thereby allowing your web servers to focus on generating dynamic content only and serve more user requests per web server

静的コンテンツに加え、画像ファイルやCSS、JacaScriptファイルもS3およびCloudFrontに任せることで、EC2インスタンスは動的コンテンツの処理にリソースを集中させることが可能です。

データベースはどうする？

このホワイトペーパーではAuroraを利用する方法が紹介されています。 Aurora MySQLはSSDベースの分散ストレージによりパフォーマンスが向上されたデータベースエンジンで、高可用性を維持できるように設計されているため今回の要件にマッチしていると思います。 Aurora MySQLのレプリカを作成し、クラスタ構成によるプライマリインスタンスの障害にも自動的にフェイルオーバー可能となるようにしておくことで、より可用性の高い構成となります。併せて、ElastiCacheも複数のAZで動作するよう構成しておく必要があります。

まとめ

従来のWordPressをそのままに高可用性を得るには、AWSが提供している各種サービス、リソースを上手に構成する必要があること、それにより得られる多くのメリットを知ることができました。また、ECサイトなど他のシステムを利用する際にも、工夫次第で応用できる構成だと感じました。 個人ブログに利用しているなら大げさに思えるかもしれませんが、コーポレートブログなど自社の情報発信源としてWordPressを利用しているなら、うまく取り入れることで負荷対策や費用削減に繋がるかもしれません。