こんにちは。2019年も1月が終わろうとしているのに衝撃を受けているohnoです。
年始め、ということで初心を思い返すため書き初めのように、今までで多かったWordPressを動かすためのAWSの構築パターンを紹介します。
こちらの記事はAWSについて詳しくない人向けに作っていますので、WordPress使用時に使われるAWSサービスの説明とともに構成のメリット・デメリットを紹介します。
詳しい人なんかは
・ぼくのかんがえた さいきょうの AWS 向け WordPress 環境を構築してみた
上の記事とかが面白いかと思います。
各構成の作り方を個別に記事にしてつくってありますので参考にしてください。
目次
そもそもAWSにWordPressを置くメリットは？
クラウドサーバーとして答えます。(GCPと比較したら？という人はこの記事を読むレベルではないと思うので。)
専用サーバーとの比較はすでに記事があります。
ざっくりいうと、AWSとオンプレサーバーの比較の場合には
・初期費用が安い
・維持費がトータル安いし、壊れた時の対応が楽。
・規模を大きくするのも小さくするのも楽。
・テスト(複製)環境も簡単に作れる
などがあると思います。
ロリポップなどでWordPressを利用している人だと、
・セキュリティを高めることができる。
・マシンスペックを自分で選べる。
・今までできなかった細かい設定ができるようになる。
・WordPress以外に動かしたいものも動かせる
と、自由度が上がるメリットがあります。そのかわり、料金は上がることが多いです。
AWS独自でいうと、SSMやLambda、SESやRoute53など
WordPressを動かすサーバー周りのいろいろをAWSが楽にしてくれることでしょうか。
AWSにWordPressを置く場合のパターン
ここからが本題です。AWSのサービスを利用して、WordPressを置く場合にはどのパターンが良いのでしょう。
Web担当者向け、AWSでWeb構築する際の見積もり5パターン
こちらの５パターンと、プラスで3つ、よく使われる構成のメリット・デメリットを紹介しましょう
パターン1 EC2インスタンス1台
一番簡単といっていい構成です。EC2インスタンス=仮想サーバー１台にWordPressを動かすのに必要なものを載せて動作させます。
WordPress基本構成パターン1-EC2インスタンス1台
メリット
管理が楽
全てのことは1台のサーバーで完結させていますから、何か問題が起きた場合にはこのサーバーを調査すればOKです。
価格が安い
使うのがEC2インスタンス1つのみなので、価格的にかなり安いです。
とはいえ、インスタンスのスペックは選ぶことができますし、メモリ・CPU・HDD容量などが足りなくなった場合には、簡単にスペックアップが可能です。
テスト環境を作るのが楽
WordPressのバージョンを上げたり、大規模な変更のためにテスト環境を作りたい場合があると思います。 現行のサイトをそのままコピーしてテスト環境を用意する場合、このマシンをコピーすれば完了するので、非常に楽です。
デメリット
落ちた場合に問題が発生する
１台の構成ですからこのサーバーが停止したらWordPressも当然落ちます。
これを防ぐためには複数台で冗長化した構成をとる必要があります。
集中アクセスに弱い
１台がさばける限界以上のアクセスが来た場合には落ちます。
アクセスが多く、タイミングによって増減する可能性がある場合には後述の自動スケールアウトする構成がいいでしょう。
情報が一箇所に集まっている
もしこのサーバーに入られた場合にはDBなどもサーバー上で動かすことになるので、全てのデータを見られてしまいます。 １箇所のみに全てのデータがあるというのはセキュリティリスクが高いといえます。
パターン2 Webサーバー1台、DBサーバー1台
さっきの構成からDBを分けて、２つの仮想サーバーで動かすパターンです。
WordPress基本構成パターン2-Webサーバー1台、DBサーバー1台
メリット
DBへのアクセスを制限できる
Webサーバーは別で稼働していますので、一般の人が見えるのはwebサーバーで、
DBサーバーには強い制限を設けるなども設計できます。
セキュリティ的に別に持つことを要求されるケースはこのように別で動作させます。
DB側の負荷、web側の負荷を別に考えられる
WordPressのサーバー負荷は、配信の負荷とDBの処理にざっくり分けることができます。
なので、それぞれに分けることで負荷が高い方のスペックを上げるなどを検討することができます。
将来的に拡張する事ができる。
上の負荷を分けると似ていますが、将来的に「DBのバックアップサーバーをもちたい」「webサーバーを冗長構成にしたい」
などの要求が出た場合に１台構成に比べて簡単に実現することができます。
バージョンをこちらで指定できる
こちらは見方によってはデメリットになりますが、パターン3で紹介するケースと違い、
自分でDBを入れますので、バージョン管理を自分で行うことになります。
マイナーバージョンまで固定したい場合にはRDSでは選択出来ない場合がありますのでこちらを使用する場合があります。
デメリット
メンテナンスの手間が増える
WordPressを正常に動作させるためにwebサーバーとDBサーバーの両方が正常に稼働している必要があります。
AWSのメンテナンスなどでインスタンスをやむ終えずリスタートさせる必要がある場合などもあるので、
もし落とさずに稼働させるためにはメンテナンスの手間が増えるでしょう。
また、セキュリティのためにDBサーバー、webサーバーともにミドルウェアのアップデートなどを定期的に行う必要があります。
リソースを無駄にする可能性がある
１台のときに比べて２台で動作させることにより、負荷を別で計算することは簡単になりましたが、
正しく設計が出来ていないとweb側の負荷は限界まで高いのにDBサーバーはリソースに余裕があるなど、リソースを無駄にする可能性があります。
パターン１と同じく集中アクセスに弱いのはそのままです。
パターン3 Webサーバー1台、RDS1台
パターン２のDBサーバーをRDSにしたパターンです。RDSはmysqlなどDBのみを使えるAWSのサービスだと思って下さい。
WordPress基本構成パターン3-Webサーバー1台、RDS1台
メリット
DBのセキュリティを高められる
管理画面をwebサーバー側に置く必要がありますが、RDSが動いているサーバーのセキュリティはAWS側が行ってくれるのでかなり強固なものです。
パターン２と同じくDBへのアクセスを制限できます。
DBの整備をAWSに任せられる
RDSはDBのサービスですから、こちらはDBを使えるように維持する必要はありません。
冗長性を持たせることもできる
将来的にDBを物理的に離れた地点に保管しておきたい場合やスレーブDBをもちたいとなった場合には設定から簡単に実装することが可能です。
デメリット
片方が落ちればWordPressは動かない
DBの処理のみ別で行っていますので当然ですが配信の処理などをRDSで肩代わりすることは出来ません。
たとえRDSの処理能力が余っていてもweb側がパンク状態にあったらWordPressは正しく動作しなくなります。
パターン１、２と同じく何かが壊れた、停止した場合にはWordPressサイトへはアクセスできなくなります。
パターン4 Webサーバー2台、RDS(MySQL)1台
webサーバー側を冗長構成にしたパターンです。
WordPress基本構成パターン4-Webサーバー2台、RDS(MySQL)1台
メリット
冗長構成なので片方停止でもWordPressは動く
予期せぬ何かの理由で片方のwebサーバーがダウンした場合、もう片方のwebサーバーでアクセスが出来ますので問題なくWordPressサイトを運用することが出来ます。
デメリット
DB側が停止したらWordPressも止まる。
冗長化してあるのはweb側だけなので、DBがなにかしらで正常に動かなくなった場合にはやはりWordPressは動作しなくなります。
パターン5 Webサーバー2台、Multi-AZのRDS
webサーバー・DB両方を冗長構成にしたパターンです。
WordPress基本構成パターン5-Webサーバー2台、Multi-AZのRDS
メリット
災害が起きたとしても問題ない。
アベイラビリティゾーン(データセンター)がわかれていますので、災害などでデータセンターが停止としても問題なく動作させることが出来ます。 また、webサーバ側・DB側の片方が何らかの理由で動かなくなってもWordPressサイトが落ちることはありません。
デメリット
スレーブ側RDSのリソースが非常時以外あまり活躍しない
web側はロードバランサが両側に割り振ってくれますが、RDSは一つのみが使われるのが基本になります。 そのため、スレーブ側のDBリソースは通常時使われない構成になるので、少し無駄が生まれます。
アクセス過多で片方が停止した場合には両方停止する。
アクセスが多すぎて捌ききれなくなり、片側のwebサーバーがダウンした場合には、もう片側に今度は全て流れることになるので結局は両方倒れます。 大量のアクセスが来ても大丈夫なようにするには後述するオートスケーリングを使いましょう。
パターン6 CloudFront＋ec2インスタンス
ここからはCloudFrontを使った場合の紹介です。最初の構成にCloudFrontを足したパターンで考えてみましょう。
CloudFrontは配信を高速化するAWSのウェブサービスです。
WordPress基本構成パターン6 CloudFront＋ec2インスタンス
メリット
キャッシュを適切にできればかなりの高速化を図れる
キャッシュを利用して複数の地点からユーザーに近い位置でレスポンスを返すことができるため早いアクセスが可能です。
各国に高速で配信可能
本来置いたリージョンにアクセスする必要があるのですが、CloudFrontは各国に配置されているため、国をまたいでも高速にコンテンツを配信することが可能です。
落ちにくくなる可能性もある
本来webサーバーが配信するべきものをCloudFrontが先に返してくれるので、webサーバー側の負担は少し減ります。
デメリット
適切にキャッシュを設定しなければいけない
WordPressサイトへ早いwebアクセスのために全部をキャッシュするわけにはいきません。 キャッシュの設定を適切に行えないとコンテンツが更新されない、デザインが崩れるなどの問題が発生する可能性があります。 自分のWordPressサイトの中でキャッシュしていいものだけを正しく設定するには知識が必要になります。
サイトによってはアクセスが早くならない。
キャッシュ利用による高速配信になるため、キャッシュをほとんど利用出来ないサイトによってはアクセスは早くならずお金だけ高くなります。
パターン7 AWS WAF+CloudFront＋ec2インスタンス
パターン６のCloudFrontにWAFを導入した構成です。
AWS WAFは悪意あるアクセスに対してのブロックを行うことができ、AWSではWordPress用のルールなどを有償で用意してありますので、それらを利用することが出来ます。
WordPress基本構成パターン7-AWS WAF+CloudFront＋ec2インスタンス
メリット
WAFを安価に利用できる
AWS WAFを使いたい場合にはそれ単体では利用できず、ロードバランサかCloudFrontを利用しなければなりません。
小規模であれば、CloudFrontはロードバランサよりは料金安く利用が可能で、１台でも利点が多くあります。
高速配信も可能
CloudFrontのキャッシュ利用を適切にできれば各国に高速配信が可能です。 ただし、パターン６と同じくサイトによっては無理な場合があります。
デメリット
適切にキャッシュを設定しなければいけない
パターン６と同じく間違った設定を入れるとサイト自体がおかしくなります。 キャッシュしない場合にはCloudFrontの料金を払いながらも使っていない状態になってしまうのでもったいないです。
パターン8 ロードバランサ＋オートスケーリングインスタンス
オートスケーリング入れて、ロードバランサの分配先をそのインスタンス達にする構成
AWSでは、負荷を測定する機能があり、一定負荷以上になった場合に自動的にスケールアウトする機能があります。
これを活用して負荷に応じてインスタンスを増やす事ができます。
ただし、DBの整合性を保つためにはDBは別に必要になるため、RDSを使用します。
WordPress基本構成パターン8-ロードバランサ＋オートスケーリングインスタンス
メリット
高負荷にも耐えられる
自動的にスケールアウトすることで大量なアクセスがきたとしてもさばくことが出来ます。
負荷が高い期間が決まっているWordPressサイト、一時期的に高負荷になりやすい合格・当選発表のサイト・キャンペーンサイトなどに適しています。
都度増減させるので安く済む
必要な時に必要な分だけのリソースを借りるように構成するので、常時高スペックなマシンを借りるより安く抑える事ができます。
デメリット
適切に設定を入れないと無駄が生まれる
どのくらいの負荷になったら増やすべきかを考えて設定する必要があります。 アタックなどのことも考えて、適切に設定しないと増え続けて高額になってしまうケースもあるでしょう。
ログ管理など、他のしくみもちゃんと作る必要がある
オートスケーリングで増減させる場合にはアクセスログなどをインスタンスに残している場合、そのログごと消えてしまいます。 統括するログ管理システムなどはちゃんと入れましょう。
まとめ
AWSで単純にWordPressを使用する場合に使われることの多い構成のメリットとデメリットをざっくりと説明致しました。
全てを紹介する都合でおおまかにしか説明できませんでしたので、気になった各構成の詳しい特性に関してはそれぞれで調べてみるとよいでしょう。
実際にどの構成にすべきかは、
・アクセス数がどれくらいあるのか
・ピークタイムとアイドルタイムでどれくらいのアクセスに差があるのか
・WordPressサイトにアクセスできない時間が生まれることを許容されるか否か
・セキュリティがどれほど要求されているのか。
これらと費用を考えた上でどの構成にするかを決める必要があります。
また、構築後もサーバーに置いてあるミドルウェアをアップデートしたり、正常に動作するように保ったり、
正しくバージョン管理を行ったりする必要があります。
今回紹介したのは基本的な構成パターンですので、ほかシステムを同居させる場合、
また特殊な構成などもありますので、興味があればハックノートのサイトでも紹介しているのでぜひ見てみてください。
でもうちって結局どうしたらいいの？と思った方は、お気軽に相談ください。
