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

今まで多かったWordPressを動かすためのAWSの構築パターンを、WordPress使用時に使われるAWSサービスの説明と共に構成のメリット・デメリットを紹介します。

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

クラウドサーバーとして捉えた時、AWSとオンプレサーバーの比較の場合には、

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

などがあります。ロリポップなどWordPressを利用している方は、

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

のように自由度が上がるメリットがあります。但し、料金は上がることが多いです。AWS独自では、SSMやLambda、SESやRoute53などWordPressを動かすサーバー周りのいろいろをAWSが楽にしてくれることでしょうか。

AWSにWordPressを置く場合のパターン

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

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

一番簡単な構成です。EC2 = 仮想サーバー1台に、WordPressを動かすために必要なものを載せて動作させます。

メリット


管理が楽

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

価格が安い

使用するものは、EC2 1つのみのため価格的にかなり安い。
但し、インスタンスのスペックを選ぶことができ、メモリ・CPU・HDD容量などが足りなくなった場合は、簡単にスペックアップが可能です。

テスト環境を作るのが楽

WordPressのバージョンを上げたり、大規模な変更のためにテスト環境を作りたい場合があると思います。
現行のWebサイトをそのままコピーしてテスト環境を用意する場合、このマシンをコピーすれば完了するため、非常に楽です。

デメリット


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

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

集中アクセスに弱い

1台がさばける限界以上のアクセスが来た場合は落ちます。アクセスが多く、タイミングによって増減する可能性がある場合は、後述の自動スケールアウトさせる構成が良いと思います。

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

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

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

パターン1の構成からDBを分けて、2つの仮想サーバーで動かすパターンです。

メリット


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

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

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

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

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

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

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

見方によってはデメリットになりますが、パターン3で紹介するケースと違い、自分でDBを入れるためバージョン管理を自分で行うことになります。マイナーバージョンまで固定したい場合には、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は、DBのサービスのため、DBを使えるように維持する必要はありません。

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

将来的にDBを物理的に離れた地点に保管しておきたい場合やスレーブDBをもちたいとなった場合には設定から簡単に実装することが可能です。

デメリット


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

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

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

Webサーバー側を冗長構成にしたパターンです。

メリット


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

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

デメリット


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

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

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

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

メリット


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

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

ディザスタリカバリを考慮したクラウド構成例

デメリット


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

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

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

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

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

CloudFrontを使った場合の紹介です。最初の構成に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はロードバランサより料金を安く利用することが可能なため、1台でも利点が多くあります。

高速配信も可能

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

デメリット


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

パターン6と同じく間違った設定を入れると、Webサイト自体がおかしくなります。キャッシュしない場合には、CloudFrontの料金が発生しながら、使わない状態になるため無駄になります。

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

オートスケーリング入れて、ロードバランサの分配先をそのインスタンス達にする構成

AWSでは、負荷を測定する機能があり一定負荷以上になった場合に、自動的にスケールアウトする機能があります。これを活用して負荷に応じてインスタンスを増やす事ができます。但し、DBの整合性を保つためには、DBは別に必要になるためRDSを使用します。

メリット


高負荷にも耐えられる

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

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

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

デメリット


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

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

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

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

まとめ

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

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

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

Webサイト におけるセキュリティのことなら、私達にご相談ください。

私たちは、Webサイトに必要な クラウド・CMS・セキュリティ対策 を提供するWordPressプラットフォーム「SiteCloud」を提供しています。
豊富な知見を活かし、企業が管理・運営するコーポレートサイト をはじめとしたWebサイトの安全な環境をご提案します。
Webサイト管理・環境におけるセキュリティでお悩みの企業の方は、お気軽にご相談ください。

関連する解決策

最新記事

詳しい資料をご覧いただけます

SiteCloudのサービス内容を記載した資料をダウンロードできます。
SiteCloudの機能や事例が分かる
無料資料ダウンロード