AWS初心者向けAWS環境のWordPress基本パターン8つ作ってみた

こんにちは。「クロジカサーバー管理」コンサルティングチームの三谷です。

一般的によく活用されているWordPressを動かすためのAWSの構築パターンを、WordPress使用時に使われるAWSサービスの説明と共に構成のメリット・デメリットを紹介します。

AWSへの移行・構築作業費無料

サーバー管理
クロジカガイドブック

「クロジカサーバー管理」の詳しい内容がわかる資料をご用意しました。

• WebサイトをAWS上で構築する際の課題
• 構築・移行の対応範囲
• 導入事例
• 導入までの流れ

資料を無料ダウンロード

そもそもAWSにWordPressを置くメリットは？

クラウドサーバーのAWSとオンプレサーバーを比較した場合のメリットは、

• 初期費用が安い
• 維持費がトータル安いし、壊れた時の対応が楽
• 規模を大きくするのも小さくするのも楽
• テスト(複製)環境も簡単に作れる

などがあります。そしてAWSとXserverなどのレンタルサーバーで比較した場合、

• セキュリティを高めることができる
• マシンスペックを自分で選べる
• 今までできなかった細かい設定ができるようになる
• WordPress以外に動かしたいものも動かせる

のように自由度が上がるメリットがあります。但し、一般的に料金は上がることが多いです。さらにAWSとしてのメリットを挙げると、SSM（AWS Systems Manager）やLambda、Amazon SESやRoute53などWordPressを動かすサーバー周りの様々なことをAWSが楽にしてくれることです。

【初心者向け】AWS環境のWordPress基本パターンを紹介

AWSのサービスを利用して、WordPressを運用する場合にはどのパターンが良いのでしょう。よく使われる構成のメリット・デメリットを紹介します。

パターン1　EC2インスタンス1台

こちらは一番シンプルで簡単な構成です。EC2（仮想サーバー）１台に、WordPressを動かすために必要なものを載せて動作させます。

メリット

管理が楽

全てのことは、1台のサーバーで完結させています。何か問題が起きた場合は、このサーバーを調査すればOKです。

価格が安い

使用するものは、EC2 1つのみのため価格を抑えることができます。
仮にメモリ・CPU・HDD容量などが足りなくなった場合はインスタンス（仮想サーバー）のスペックを選ぶ変更することができ、簡単にスペックアップが可能です。
^{※ アプリやサービスの可用性要件によっては、無停止での変更が難しい場合もあるので注意が必要です}

テスト環境を作るのが楽

WordPressバージョンアップや大規模変更の検証には、現行EC2インスタンスの設定やデータを丸ごと保存するテンプレートであるAMI（Amazon Machine Image）を作成し、新規インスタンスを起動するだけでテスト環境を複製できるため、手間が省けます。

デメリット

落ちた場合に問題が発生する

１台の構成のため、サーバーが停止したらWordPressも当然落ちます。防ぐためには複数台で冗長化した構成を採用する必要があります。

集中アクセスに弱い

１台が処理できる限界以上のアクセスが来た場合は落ちます。そのためアクセスが多く、タイミングによって増減する可能性がある場合は、後述する自動でスケールアウトをさせる構成を推奨します。

情報が一箇所に集まっている

もし、外部からサーバーに進入した場合は、DBなどもサーバー上で動かすことになるため、全てのデータの閲覧が可能です。そのため１箇所だけに全てのデータがあることは、セキュリティリスクが高いといえます。

パターン2　Webサーバー1台、DBサーバー1台

続いては、先ほどのパターン1の構成からDBを分けて、２つの仮想サーバーで動かすパターンです。

メリット

DBへのアクセスを制限できる

Webサーバーは分けて稼働しているため、一般の方が見るものはwebサーバーになり、DBサーバーには強い制限を設けるなど設計ができます。セキュリティ的にDBを別に持つことを要求されるケースは、このように分けて動作させます。

DB側の負荷、Web側の負荷を別に考えられる

WordPressのサーバー負荷は、配信の負荷とDBの処理に分けることができます。それぞれ分けることで、負荷が高い方のスペックを上げるなどを検討することができます。

将来的に拡張する事ができる。

上記の負荷を分けるメリットと似ていますが、将来的に「DBのバックアップサーバーをもちたい」「Webサーバーを冗長構成にしたい」などの場合に、1台構成に比べて簡単に実現することができます。

バージョンをこちらで指定できる

見方によってはデメリットになりますが、続くパターン3で紹介するケースと違い、自分でDBを入れるためバージョン管理を自分自身で行うことになります。例えばマイナーバージョンまで固定したい場合には、後ほど触れるAmazon RDSでは選択出来ない場合があるため、こちらのパターンを使用する場合があります。

デメリット

メンテナンスの手間が増える

WordPressを正常に動作させるために、WebサーバーとDBサーバーの両方が正常に稼働している必要があります。AWSのメンテナンスでインスタンスをやむ終えずリスタートさせる必要がある場合があるため、落とさずに稼働させるためには、メンテナンスの手間が増えます。また、セキュリティのためにDBサーバー、Webサーバーともにミドルウェアのアップデートを定期的に行う必要があります。

リソースを無駄にする可能性がある

1台のときに比べて2台で動作させることにより、負荷を分けて計算することは簡単になりましたが、正しく設計が出来ていないと、Web側の負荷は限界まで高くてDBサーバーはリソースに余裕があるなど、リソースを無駄にする可能性があります。また、パターン1と同じく集中アクセスに弱い点は変わりません。

パターン3　Webサーバー1台、RDS1台

こちらは、パターン2のDBサーバーをRDSにしたパターンです。RDSは、mysqlなどDBのみを使えるAWSのサービスです。

メリット

DBのセキュリティを高められる

管理画面をWebサーバー側に置く必要がありますが、RDSが動いているサーバーのセキュリティは、AWS側が行うため非常に強固なものです。さらにパターン2と同じく、DBへのアクセスを制限できます。

DBの整備をAWSに任せられる

RDS はデータベースエンジンのインストールやパッチ適用、バックアップ設定、スケーリングなど運用タスクをAWSが自動実行するため、自社で常時稼働を維持する手間を省けます。

冗長性を持たせることもできる

Multi-AZ（マルチAZ） 配置やリードレプリカの作成がコンソール上の操作やAPI呼び出しだけで可能なため、可用性向上や障害時の迅速な切り替えを簡単に実装できます。

デメリット

片方が落ちればWordPressは動かない

DBの処理のみ分けて行っているため、配信の処理をRDSで肩代わりすることは出来ません。そのため仮に、RDSの処理能力が余っていても、Web側がパンク状態になるとWordPressは正しく動作しなくなります。つまりパターン1、2と同じく何かが壊れた、停止した場合にはWordPressサイトへはアクセスできなくなります。

パターン4　Webサーバー2台、RDS(MySQL)1台

続いてのパターン4は、Webサーバー側を冗長構成にしたパターンです。

メリット

冗長構成なので片方停止でもWordPressは動く

予期せぬ何かの理由で片方のWebサーバーがダウンした場合、もう片方のWebサーバーでアクセスができるため、問題なくWordPressサイトを運用することが出来ます。

デメリット

DB側が停止したらWordPressも止まる。

冗長化してあるのはWeb側だけなので、DBが正常に動かなくなった場合には、WordPressは動作しなくなります。

AWSへの移行・構築作業費無料

サーバー管理
クロジカガイドブック

「クロジカサーバー管理」の詳しい内容がわかる資料をご用意しました。

• WebサイトをAWS上で構築する際の課題
• 構築・移行の対応範囲
• 導入事例
• 導入までの流れ

資料を無料ダウンロード

パターン5　Webサーバー2台、Multi-AZのRDS

続いては、Webサーバー・DB両方を冗長構成にしたパターンです。

メリット

災害が起きたとしても問題ない。

アベイラビリティゾーン(データセンター)が分かれているため、災害などでデータセンターが停止しても問題なく動作させることが出来ます。また、Webサーバー側・DB側の片方が何らかの理由で動かなくなってもWordPressサイトが落ちることはありません。

デメリット

スレーブ側RDSのリソースが非常時以外あまり活躍しない

Web側は、ロードバランサによって両側に割り振られますが、RDSは、一つのみ使われることが基本になります。スレーブ側のDBリソースは、通常時に使用しない構成になるため少し無駄が生じます。

アクセス過多で片方が停止した場合には両方停止する。

アクセスが多すぎて処理をしきれなくなり、片側のWebサーバーがダウンした場合には、もう片側に全て流れることになるため結果的には両方倒れることになります。そのため、大量のアクセスが来ても大丈夫なようにするためには、後述するオートスケーリングを使用します。

パターン6　CloudFront＋ec2インスタンス

続いては、Amazon CloudFrontというCDNを使った場合の紹介です。ここでは最初に紹介したパターン1の構成にCloudFrontを足したケースで考えてみます。CloudFrontは、配信を高速化するAWSのウェブサービスです。

メリット

キャッシュを適切にできればかなりの高速化を図れる

キャッシュを利用して、複数の地点からユーザーに近い位置でレスポンスを返すことができるため、ユーザーに速いアクセスを提供することが可能です。

各国に高速で配信可能

本来はコンテンツのオリジンサーバーを置いたリージョンにアクセスする必要がありますが、CloudFrontは各国に配置されているため、国をまたいでも高速にコンテンツを配信することが可能です。

落ちにくくなる可能性もある

本来、Webサーバーが配信するべきものをCloudFrontが先に返すため、Webサーバー側の負担は少し減ります。

デメリット

適切にキャッシュを設定しなければいけない

WordPressサイトへ速くWebアクセスするために、全部をキャッシュするわけにはいきません。キャッシュの設定を適切に行わないとコンテンツが更新されない、デザインが崩れるなどの問題が発生する可能性があります。WordPressサイトの中で、キャッシュして良いものだけを正しく設定するためには専門知識が必要になります。

サイトによってはアクセスが早くならない。

キャッシュ利用による高速配信になるため、キャッシュをほとんど利用できないWebサイトは、アクセスが早くならずコストだけ高くなります。

パターン7　AWS WAF+CloudFront＋ec2インスタンス

こちらは、パターン6のCloudFrontに、WAFを導入した構成です。AWS WAFは、悪意のあるアクセスに対してブロックを行うことができセキュリティ体制を強化することができます。AWSではWordPress用のルールなどを有償で用意してあるため利用することが出来ます。

メリット

WAFを安価に利用できる

AWS WAFを使いたい場合には、単体では利用できずロードバランサか、CloudFrontを利用しなければなりません。小規模サイトの場合、CloudFront＋AWS WAF 構成のほうが ロードバランサ＋AWS WAF の構成よりも月額費用を抑えられるため、コストを抑えつつ同等のWeb攻撃対策が行えます。

高速配信も可能

CloudFrontのキャッシュ利用を適切にできれば、各国に高速配信が可能です。但し、パターン6と同じくWebサイトによっては不可能な場合があります。

デメリット

適切にキャッシュを設定しなければいけない

パターン6と同じくCloudFrontで誤ったキャッシュ設定をすると、Webサイトの表示や動作が崩れる恐れがあります。また、キャッシュを有効にしないままではリクエストごとに料金が発生し続け、無駄なコストがかかってしまいます。

パターン8　ロードバランサ＋オートスケーリングインスタンス

最後にご紹介するのは、AWS Auto Scalingを使い、ロードバランサが複数のEC2インスタンスへトラフィックを分散する構成です。

AWSのオートスケーリング機能は、Amazon CloudWatch等でサーバー負荷を監視し、設定した閾値を超えると自動的にインスタンスを追加／削除することができます。これにより、アクセス増減に合わせてサーバー台数を動的に調整でき、常に最適なリソースを確保できます。

なお、ステートレスなWebサーバー群でデータベースの整合性を保つには、別途RDS等のマネージドDB サービスを利用するのが一般的です。

メリット

高負荷にも耐えられる

自動的にスケールアウトすることで、大量なアクセスがきたとしても処理をすることが出来ます。活用ケースとしては、負荷が高い期間が決まっているWordPressサイト、一時期的に高負荷になりやすい合格・当選発表のWebサイト・キャンペーンサイトなどに適しています。

都度増減させるので安く済む

必要な時に必要な分だけのリソースを借りるように構成するため、常時高スペックなマシンを借りるより安く抑える事ができます。

デメリット

適切に設定を入れないと無駄が生まれる

どのくらいの負荷になったら増やすべきかを考えて設定する必要があります。アタックなどのことも考えて、適切に設定しないと、増え続けて高額になってしまうケースもあります。

ログ管理など、他のしくみもちゃんと作る必要がある

オートスケーリングで増減させる場合には、アクセスログなどをインスタンスに残している場合、そのログごと消えてしまいます。統括するログ管理システムなどは、しっかりと入れておきましょう。

まとめ

AWSで、WordPressを使用する場合に使われることの多い構成のメリットとデメリットを説明しました。全てを紹介する都合で大まかな説明になりますので、気になった各構成の詳しい特性については、調べてみると良いでしょう。実際にどの構成にすべきかは

・アクセス数がどれくらいあるのか
・ピークタイムとアイドルタイムでどれくらいのアクセスに差があるのか
・WordPressサイトにアクセスできない時間が生まれることを許容されるか否か
・セキュリティがどれほど要求されているのか

これらと費用を考えた上で、どの構成にするか決める必要があります。また、構築後もサーバーに置いてあるミドルウェアをアップデートすることや、正常に動作するように保つなど、正しくバージョン管理を行う必要があります。今回は、基本的な構成パターンの紹介ですので、システムを同居させる場合は特殊な構成などもあります。興味をお持ちの方は、お気軽に相談ください。

---

WordPressをAWSに無料で構築・移行するならクロジカへ

2004年よりサーバー運用を行い、250社以上の構築・運用実績を誇るクロジカが培った、運用保守のノウハウを活かしてWordPressをAWS環境へ無料で構築・移行いたします。AWSへ移行後は、ログ調査・定期的なアップデート（CMS本体とプラグイン）、IPアドレス制限、セキュリティアップデート情報の早期案内など網羅的にセキュリティ対策を行います。

クラウドサーバーに特化した専門家が、WordPressに最適化したAWS構築を行います。また、別サーバーからWordPress移行作業も代行します。そもそもAWSに構築するメリットがわからないといったお客様も、お気軽にご相談ください。豊富な実績から様々なメリットをご案内いたします。

初期構築・移行費用を無料でAWS環境のWordPressをはじめませんか？

▶︎ WordPressをAWSに無料で構築・移行するならクロジカへ

監修者：クロジカサーバー管理編集部

コーポレートサイト向けクラウドサーバーの構築・運用保守を行うサービス「クロジカサーバー管理」を提供。上場企業や大学、地方自治体など、セキュリティ対策を必要とするコーポレートサイトで250社以上の実績があります。当社の運用実績を踏まえたクラウドサーバー運用のノウハウをお届けします。

コーポレートサイトをクラウドでセキュアに

サーバー管理
クロジカガイドブック

「クロジカサーバー管理」の詳しい内容がわかる資料をご用意しました。

• コーポレートサイト構築・運用の課題を解決
• クロジカサーバー管理の主な機能
• 導入事例
• 導入までの流れ

資料を無料ダウンロード