WordPress を AWS 上で構築する環境には、複数の設計パターンがあります。
この設計パターンは、サイトの目的や特性、要件を検討しながら、最適なデザインパターンを決定する必要があります。
ここでは、8 つの設計パターンの、
・可用性について
・負荷対応/スケーラビリティ
・コスト
の 3 つに焦点を置いて解説を行います。
1. EC2 (単体)
EC2 で Web サーバー、PHP、MySQL サーバーなど全てを処理する構成です。
この構成の特徴をみていきましょう。
可用性について
この設計パターンは、全ての処理を EC2 で行う構成です。
そのため、EC2 の可用性がそのままシステム全体の可用性となります。
AWS 公式ページには以下のようにあります。
各 1 時間に 90% 以上の時間稼働率（時間コミットメント）を確保するよう商業
上合理的な努力を行う
https://aws.amazon.com/jp/compute/sla/
単体なので可用性は当然低く、集中的なアクセスにも弱いです。
負荷対応/スケーラビリティ
単体なので水平方向のスケーラビリティはなく、負荷分散もできません。
また、垂直方向のスケーリングは可能ですが、負荷に応じた自動的なスケールアップなどは難しいです。
手動のスケールアップは可能ですが、一度 EC2 を停止する必要があるため、単体の構成ではサイトダウンが発生してしまいます。
コスト
EC2 しか使用していないため、スペックにより多少変わりますが、最も安い構成です。
2. EC2+RDS
Web サーバ( EC2 )と、MySQL サーバ ( RDS )を分離した構成です。
この構成の特徴をみていきましょう。
可用性について
設計上の可用性は
・EC2 の可用性 x RDS の可用性
なので、EC2 単体の構成より低くなります。
ですが、RDS に MySQL サーバーを移しているため、EC2 の負担が軽くなり実際の可用性は上がります。
また、RDS のマルチ AZ 機能を使用すると冗長化が実現でき、障害発生時に自動的に正常なサーバと切り替わります。
負荷対応/スケーラビリティ
EC2 単体の構成より、EC2 の負荷は下がっています。
ED2、RDS 共にスケールは垂直方向のみ可能です。
また、RDS のスケールアップ、スケールダウンに関しては、EC2 同様に再起動が必要になります。
RDS が マルチ AZ でない場合はサイトダウンが発生する可能性があります。
コスト
EC2 単体の構成よりは、RDS 分が多くかかっていますが、まだかなり安い構成と言えます。
3. EC2+RDS(Aurora)
EC2+RDS の構成の RDS を、Aurora にした構成です。
Aurora は、AWS が独自に開発したリレーショナルデータベース管理システムで、非 Aurora に比べ高性能になっています。
可用性について
RDS は、読み取り専用のコピーであるリードレプリカをマスターに昇格させる場合、手動での対応が必要となります。
一方 Aurora では、障害発生時に自動でリードレプリカをマスターに昇格するため、非 Aurora 環境よりも可用性が高いといえます。
負荷対応/スケーラビリティ
Aurora は動的に水平方向へのスケールが可能です。
リードレプリカは、非 Aurora では最大5個なのに対し、Aurora では最大15なので2よりも負荷に強いと言えます。
コスト
Aurora は、通常の RDS の料金に加え I/O リクエスト数に応じた課金が発生します。
また、DB インスタンスタイプによる料金も、Aurora の方が高くなっています。
4. EC2+RDS+S3+CloudFront
EC2+RDS の構成に、画像などを保存するための S3、CDN である CloudFront を追加した構成です。
可用性について
キャッシュを適切に設定できれば、リクエストに対して Web サーバーの代わりにCloudFront が先に応答してくれるため、EC2 の負担が軽減され可用性が少し高くなります。
負荷対応/スケーラビリティ
CloudFront のキャッシュと、S3 に画像データを移した事により Web サーバー (EC2) の負荷が軽減されます。
S3 と CloudFront は、直接スケーラビリティには寄与しません。
コスト
S3 はそれほど高額ではありません。
CloudFront はリクエスト数、オリジンへ転送されたデータ、インターネットへ転送されるデータに対してそれぞれ課金されます。
5. EC2+RDS(Aurora)+S3+CloudFront
EC2+RDS+S3+CloudFront の構成 の RDS を Aurora にした構成。
可用性について
EC2+RDS+S3+CloudFront の構成の可用性に加え、Aurora にした事で RDS の可用性も上がっています。
負荷対応/スケーラビリティ
Aurora にすることで、EC2+RDS+S3+CloudFront の構成よりも MySQL サーバーでの負荷への耐性が上がっています。
コスト
Aurora、CloudFront をしているため、特にコストがかかります。
6. EC2(AS)+RDS+S3+CloudFront+EFS
EC2+RDS+S3+CloudFront の構成に加え、EC2 でのオートスケーリング (AS) を有効にし、そ WordPress 管理画面からの操作を複数の EC2 で共有するため、EFS を加えた構成です。
可用性について
EC2 のオートスケーリング機能により、EC2 に障害が発生しても入れ替えが行われるため耐障害性がとても向上しています。
負荷対応/スケーラビリティ
負荷に応じて EC2、EFS が水平方向のスケーリングを行います。
スケーラビリティはとても高いです。
コスト
Auto Scaling 自体に料金は発生しません。
EC2 リソースとインスタンスのモニタリングを行う CloudWatch、EFS、 ALB に料金が発生します。
7. EC2(AS)+RDS(Aurora)+S3+CloudFront+EFS
EC2(AS)+RDS+S3+CloudFront+EFS の構成内の、RDS を Aurora に変更した構成です。
可用性について
EC2、Aurora、CloudFront、EFS のスケーラビリティにより可用性が非常に高いです。
負荷対応/スケーラビリティ
EC2、Aurora、CloudFront、EFS スケーラビリティによりさまざまな負荷に対応できます。
コスト
元々コストの高い構成ではありますが、スケーラビリティが高いため、負荷によって大きく変動します。
高負荷の際は EC2、Aurora、CloudFront、EFS のスケールと共に料金は跳ね上がります。
8.EC2(AS)+RDS(Aurora)+S3+CloudFront+EFS+WAF
EC2(AS)+RDS(Aurora)+S3+CloudFront+EFS の構成に、WAF を追加した構成です。
可用性について
EC2(AS)+RDS(Aurora)+S3+CloudFront+EFS 構成の負荷への耐性に加え、WAF により攻撃への耐性も高くなっているため、可用性は極めて高いです。
負荷対応/スケーラビリティ
WAF は負荷対応、スケーラビリティには直接関係ないためEC2(AS)+RDS(Aurora)+S3+CloudFront+EFS とほぼ同じです。
コスト
WAF のコストは保護ルールの作成、WAF へのリクエストにかかってきます。
7EC2(AS)+RDS(Aurora)+S3+CloudFront+EFSの構成と同じ負荷へのコストに加え、システムの保護へのコストもかかってくるため、非常に高額となります。
まとめ
今回は、WordPress を AWS 上で構築する際の設計パターン8つを紹介しました。
しかし
「これだけでは判断できない」
「結局どうすればいいかわからない」
といった担当者もいらっしゃるかと思います。
そんな時は当社にご相談ください！
当社は設立当初から WordPress を取り扱っており、AWSに関してもセミナーへの参加や登壇、コミュニティへの貢献など、多方面の知識を持っています。
そのためお問い合わせいただければ、専門のスタッフがお客様のニーズをヒアリングさせていただき、ご希望に応えられる提案をさせていただきますので、右下のチャットボタンからお問い合わせください。
詳しくは下記ページよりご覧ください。
https://labworks.digitalcube.jp/services/
また、WordPress専用のフルマネージドホスティング「Amimoto」も提供しています。特徴は下記よりご覧ください。
