WordPressをAWSのスケーラブルなサーバー環境で構築しよう【構成編】

こんにちは。バックエンドエンジニアのまうみです。今回は大規模なWordPressを構築するうえで、よくお世話になるAWSのインフラ環境についての記事です。

今回は前段の知識編として、スケーラブルな環境でWordPress運用する場合のインフラ構成図をサンプルにして、よく使用されるサービスの内容をまとめました。夢のあるインフラ構築の第一歩としての初学者向けの内容となっております。最後までお付き合いいただけますと幸いです。

そもそもスケーラブルな構成とは？

VPSやレンタルサーバーと比べて、クラウド環境は柔軟で可用性のある環境がすぐに作成できるのが強みです。一体どのようにスケーラブルな環境を作っていくのでしょうか。また、「クラウド環境でスケーラブルな構成にしたい」という要望はよく聞かれますが、そもそも「スケーラブル」とはどういう意味でしょうか。

スケーラビリティ（scalability）とは利用者や仕事の増大に適応できる能力・度合いのこと[1]。電気通信やソフトウェア工学において、システムまたはネットワークまたはアルゴリズムの、持つべき望ましい特性の1つで、一種の拡張性である。より具体的には、小規模なシステムを大規模にする場合に、システム全体を交換する方法（建物で例えると大きな物件に引っ越すこと）では無く、リソース（特にハードウェア）の追加によって大規模なものへと透過的に規模拡張できる能力（建物で例えると、増築や別棟を建てること）はスケーラビリティの一種だといえる。
引用元：ウィキペディア

そのまま直訳してしまえば、「拡張性の高い環境」という意味です。ほとんどの場合、サービスは一度開発して終わりでありません。サービスが成長していくにつれ、負荷が増大していってもサーバーを安定して稼働させ続けるために様々な施策を講じる必要があります。

そのために、必要に応じて負荷分散やスペックの増強などが行える、可用性を担保したインフラ環境を整備しておく必要があります。

AWS（クラウド環境）を採用するメリット

それではクラウド環境ならではの拡張性の強みとはなんでしょうか。VPSやレンタルサーパーとはどのような違いがあるでしょうか。

例えばWordPressを運用しているシンプルな単一のサーバーを高負荷に耐えれれるようにするだけなら、VPSやレンタルサーパーでもより高性能な環境に引っ越すだけで実現できそうですよね。

スケールアップ

上記の方法は、より高性能なCPUやDBなどを備えたサーバーに引っ越しをして、性能を拡張する「スケールアップ」という方法です。

シンプルな環境の分、作業量が少なく管理もしやすいので小規模なWebサービスで非常に有用な方法です。しかし機器のスペックには限度があるため、一定以上の負荷には対応できない可能性があります。また基本的にはサーバーが単一でしか運用できないので、障害が発生した際にはサービスそのものが停止してしまうリスクもあります。

スケールアウト

サーバーやDBを複数に分けて、水平的に負荷分散していくことを「スケールアウト」といいます。クラウド環境ではスケールアップだけでなく、柔軟なスケールアウトの設定が可能です。もちろんサーバー台数を増やす分のコストがかかりますが、増設すればするほど負荷への対応ができます。

仮に一つのサーバーがダウンしても、稼働しているサーバーが残っていればダウンタイムは発生しません。ある程度大きなシステムの運用に適した方法です。

全体図を見てみよう

※ブログ用に情報を簡略化しています
スケーラブルなWordPress環境のインフラ構成図の一例を作成しました。今回の記事では、この構成図を解説しつつ、AWSの負荷分散について解説していきたいと思います。

VPC（Amazon Virtual Private Cloud）

VPCはAWSでのサービス開発には欠かせない、ネットワークを構築する機能です。AWSアカウント内に専用のネットワークを作成し、後述のEC2やRDSなどのサービスを配置することでネットワークを構築していきます。

アベイラビリティゾーン（AZ）

アベイラビリティゾーン (AZ) とは、1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている 1 つ以上のデータセンターのことです。AZ によって、単一のデータセンターでは実現できない高い可用性、耐障害性、および拡張性を備えた本番用のアプリケーションとデータベースの運用が実現されています。
引用元：AWSについて

アベイラビリティゾーン（AZ）は世界各地のリージョン内部に存在するデータセンターの集合です。AWSのデータセンターは世界各地に点在され、リージョンという単位で区分けされています。複数のAZ（Multi-AZ）にリソースを配置することでもシステムの可用性を高めることができます。

今回の構成図でも、複数のAZにEC2を配置した冗長構成を組んでいます。

サブネット

VPCのネットワークを内部で分割したのものがサブネットです。VPC内にサブネットを構成し、サブネットごとに接続要件を設定、そしてEC2などのインスタンスを配置していきます。

構成図で使用するサブネットには二種類あります。インターネットと直接接続できるパブリックサブネット。インターネットと直接接続できないプライベートサブネットです。

構成図ではパブリックサブネットにEC2を配置し、プライベートサブネットにRDSを配置しています。

CloudFront

Amazon CloudFront は、ユーザーへの静的および動的なWebコンテンツ（.html、.css、.js、イメージファイルなど）の配信を高速化するウェブサービスです。CloudFrontでは、エッジロケーションというデータセンターの世界的ネットワークを経由してコンテンツを配信します。
引用元：Amazon CloudFront とは何ですか?

CloudForntはAWSのCDN（コンテンツデリバリーネットワーク）のサービス名です。サイトデータのキャッシュを本体のサーバーではなく、世界各地に配置された専用のキャッシュサーバーに割り振ることで、サイトのレスポンスを高速化することができます。安定したコンテンツの配信には、キャッシュの効率的な運用は必須です。

爆発的なアクセスの増加の際にも、キャッシュサーバーからコンテンツが配信されるので本体のサーバーの負荷軽減に大きな貢献をしてくれます。

ELB（Elastic Load Balancing）

ELB (Elastic Load Balancing) は、アプリケーションへのトラフィックを、1 つまたは複数のアベイラビリティーゾーン (AZ) 内の複数のターゲットおよび仮想アプライアンスに自動的に分散します
引用元：Elastic Load Balancing

ELBはAWSのロードバランサーのサービス名です。少し聞き慣れない単語ですが、ロードバランサーはその名の通り「負荷分散」には欠かせない機能です。

あらかじめ設定しておいた複数のサーバーに、自動でトラフィックを分散してくれます。ロードバランサーのおかげで、アプリケーションを監視しつつ、システムの可用性を向上させることができます。

EC2（Amazon Elastic Compute Cloud）

EC2はAWSの仮想サーバー構築サービス名です。今回のインフラ構成ではEC2のインスタンスにWordPressを設置します。AWSでWebサービスを構築するほとんどの場合EC2は触れることになると思います。できるだけ早めに仲良くなりたいですね。

複数のAZにEC2配置する

直前で紹介しました、ELBで別々のAZに配置したEC2インスタンスに負荷分散を設定しています。ELBの設定で、アクセスを振り分ける際に正常なインスタンスかどうかヘルスチェックを行います。もしヘルスチェックで不合格となれば、そのインスタンスにはアクセスしないように設定します。

こうして図解してみると、より具体的にAWSのスケールアウトのイメージが湧いてきますね。

また、負荷が超過した際にはEC2のインスタンス台数を自動で増減させる、オートスケーリングを設定することも可能です。その場合、負荷のピーク時のみにサーバーの数を増減することで監視の負担を減らしコスト削減することができます。

RDS（Amazon Relational Database Service）

RDSはAWSのリレーショナル型のデータベースのサービス名です。わかりやすいですね。容量の増減を管理画面の操作で完結することができます。必要量に応じた料金のみの支払いで、急なデータ容量の追加にも対応できます。

図ではWordPressのデータベースとして、RDSを使用します。EC2を増設していっても、単一のデータベースを参照するので管理が容易になります。

RDSもマルチAZで高可用性を担保した運用が可能です。プライマリインスタンス（メインのRDSサーバー）にもし障害が発生しても、あらかじめスタンバイしているインスタンスに自動でフェイルオーバーするように設定します。

S3（Amazon Simple Storage Service）

Amazon Simple Storage Service (Amazon S3) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。あらゆる規模や業種のお客様が、データレイク、クラウドネイティブアプリケーション、モバイルアプリケーションなど、事実上あらゆるユースケースで、あらゆる量のデータを保存、保護することができます。コストパフォーマンスに優れたストレージクラスと使いやすい管理機能により、コストの最適化、データの整理、特定のビジネス、組織、コンプライアンスの要件を満たすきめ細かなアクセスコントロールの設定を行うことができます。
Amazon S3

公式の文章だとややこしいですが、画像や動画など静的なメディアファイルを置いておくためのストレージだと捉えてください。

通常のWordPressの構造ではサーバー内の/wp-content/uploadsにディレクトリを確保しメディアファイルを保管しますが、

今回の設計ではWordPressにアップロードしたメディアファイルをサーバー内に画像を配置するのではなく、S3のストレージに保存しています。これにより以下のメリットが得られます。

• 大量のメディアファイルをアップロードしても、サーバー内の容量を圧迫しない
• メディアのアクセスを外部に振り分けることで、サーバー負荷を分散する
• メディアの保存場所を外部に持たせることで、サーバー冗長化を管理しやすくする

また、メディアファイルへの参照はClound Front経由にすることで、より配信の速度を向上させます。

ちなみに、WordPressとS3の連携にはプラグインを使用することが多いです。設定方法に関して、またあらためてご紹介していけたらと思います。簡単な設定手順で、WordPressにアップロースするメディアをS3に保存してくれます。

世界には本当に便利なプラグインがたくさんありますね……開発者の皆様ありがとうございます。

まとめ

本記事ではスケーラブルな環境でWordPress運用する場合のインフラ構成図をサンプルに、よく使用されるサービスの内容をまとめました。

AWSはサービスは非常に種類が多く、どんなサービスにも対応できる柔軟性がある一方で、初学者にとってはとっつきにくい印象を覚えるかと思います（実際に私もそうです）。

今後の記事では、スケーラブルな状態でのミスが起こりにくいデプロイ環境の構築方法や、初学者向けのAWSの学習方法についてブログで紹介していきます。どなたかの参考になれば幸いです。

ではまた。

LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。