2020.08.20

バズっても安心『落ちないWordPressサイト』を実現する方法

kuni

WordPressを運営されているみなさま。こんにちは。MMM代表国本です。

Webサイトの運営を効率化するためにCMS(コンテンツ・マネジメント・システム)を導入されている企業は数多くあります。

オープンソース、商用含めて多くのCMS製品がある中でも「WordPress(ワードプレス)」は圧倒的なシェアを誇り、企業サイトの採用事例は枚挙に暇がありません。

企業の顔となるコーポレートサイトや、広告と連動させたランディング・ページ(LP)、プラグインを導入したEC(Eコマース)など、WordPressの用途は多岐にわたり、これらはシステムダウンが許容されない商用サイトとして稼働が求められるケースも少なくありません。

MMMでは企業用途を前提に、これまでシステムダウンが許容されないWordPressサイトを数多く設計・構築、そして運用している実績があります。

そこで、今回のブログでは「落ちない企業向けWordPressサイト」を実現するための方式についてご紹介したいと思います。

Contents

目次
企業サイトでの安定性・パフォーマンスの重要性
WordPressサイトが落ちる要因
『落ちないWordPress』を実現する3つのパターン
1. 設計の前提
2. WordPressデザイン・パターン
各パターンのメリット・デメリット
各パターンの比較
"落ちないWordPress" でビジネスに安心を

企業サイトでの安定性・パフォーマンスの重要性

昨今、数多くの企業がWebのテクノロジーを何かしらの形で自社のビジネスに取り入れています。

企業でのWordPressの用途も

コーポレートサイト
ビジネス向け会員サイト
Eコマース(EC)システム
ブログ・メディア
キュレーションサイト
ランディングページ

など多岐にわたっており、単なるWebサイトの役割を超え、既存顧客や潜在顧客層とダイレクトに接点を持つ重要なチャネルとなっています。

その結果、企業向けWordPressでは「24時間365日スムーズに使えること」を前提に高い信頼性とパフォーマンスが求められており、アクセス集中によるパフォーマンスの劣化やシステムダウンの頻発は、ビジネス機会損失とブランドイメージ低下に直結します。

よって、企業が運営するWordPressサイトでは顧客のニーズに応じて素早く対応可能な、柔軟かつ堅牢なシステムを作り上げることが重要です。

WordPressサイトが落ちる要因

なぜ、WordPressサイトのパフォーマンス劣化やシステムダウンが発生してしまうのか？

その要因を考えていきます。

要因1. ハードウェア障害

オンプレミス(自社保有)やレンタルサーバー、クラウドを問わず、WordPressを動作させるサーバーOSはデーターセンター上の電源装置、ネットワーク機器、専用サーバー機やストレージ装置など様々なハードウェアが連携して動作します。

これらを構成するハードウェア・パーツの劣化や物理的破損がサイトパフォーマンスへの影響やシステムダウンを引き起こすケースがあります。

要因2. OS・ミドルウェア障害

WordPressはPHPというプログラミング言語で開発されており、動作にはLinux OSやPHPが稼働するアプリケーション・Webサーバーといったミドルウェアが必要です。

これらのプロセスダウンや暴走などは、WordPressサイトの障害要因になりえます。

要因3. システムリソースの枯渇

TV放映、SNS拡散、広告によってWordPressサイトへ短時間に大量アクセス(スパイク)が発生した際に、WordPressサーバーのCPU/メモリなどのハードウェアリソースが枯渇し、パフォーマンスの劣化やシステムダウンが発生するケースがあります。

また、アクセス集中時のネットワークトラフィック増大によって回線帯域を圧迫し、サイトに影響が発生するというケースも考えられます。

要因4. 悪意を持った攻撃

WordPressは国内外を問わず高いシェアを持っているため、攻撃対象として狙われやすいCMSです。

脆弱性が公表されているバージョンのWordPressをアップデートせずに利用している企業も多く、これら脆弱性を狙った攻撃や、簡易的にセットアップされたOSやミドルウェアの設定不備を狙った攻撃事例は多数あります。

加えて、これらソフトウェアやネットワーク層の攻撃以外にも、データーセンター上で稼働するサーバー機、ネットワーク装置、ストレージ装置へのハードウェアに対する悪意を持った攻撃(盗難など)も考えられます。

これらの4つの要因をビジネス・リスクとして捉え、適切な対処を進めることが、WordPressサイトの安定性やパフォーマンス向上には欠かせません。

『落ちないWordPress』を実現する3つのパターン

では、どうすればWordPressサイトのシステム・ダウンやパフォーマンス劣化を防ぎ『落ちないWordPressサイト』を実現できるのか？

具体的なアプローチとして、MMMで提案している3つの企業向けWordPressデザイン・パターンをご紹介します。

設計の前提

初めに、全パターンで共通する設計前提を記載します。

設計前提1. Amazon Web Services(AWS)を採用

WordPressサイトを稼働させる基盤にAWSを採用することで、自前設備やレンタルサーバーでは実現が困難であるハードウェアレイヤーでの非常に高い耐障害性や物理的セキュリティを担保します。

AWS採用によってハードウェアレイヤーの維持・運営をAWSに移管でき、企業は上位のレイヤーに投資・人的資源を集中できます。

設計前提2. 『Design for failure』 "障害は発生するもの"

AWSではサーバーやデータベースそしてデータセンター機器を含め、システムを構成する全ての要素で「必ず障害は発生するもの」として考えます。

よって、各構成要素の一部に何らかの障害が発生してもシステム全体としてサービス稼働を担保できる設計が必要です。

これは『Design for failure』と呼ばれ Architecting for the Cloud: Best Practices としてクラウド利用のベストプラクティスとしても提唱されています。

設計前提3. CDN(Content Delivery Network)の活用

AWSが提供するコンテンツ配信サービス『Amazon CloudFront』によって高速なキャッシュ配信を実現します。

CloudFrontキャッシュ機構をWordPressサイトに適用することで、スパイクが起こってもサイトが「落ちる」「重くなる」ことを原理的に避けることが可能です。

※ちなみに MMMはAWSよりCloudFrontのサービスデリバリープログラム(AWS Service Delivery Program)認定を受けています

WordPressデザイン・パターン

共通する設計前提を把握した上で、次に3つのWordPressパターンを見ていきましょう。

パターン1. サーバー冗長化 + Auto Scaling(オートスケーリング)

WordPress(PHP)を稼働させる仮想サーバー(EC2)とデータベースを冗長構成とし、仮想サーバー間で共有が必要なWordPressファイルを共用ストレージ(EFS)に配備するパターン。

加えて、スパイク発生時の拡張性を担保するため、仮想サーバーへAuto Scaling(オートスケーリング)というサーバー負荷をトリガーとした自動的なサーバー増減が可能な機構も導入します。

パターン2. コンテナ向けサーバーレス(AWS Fargate)

WordPressを仮想サーバーではなく「コンテナ(Docker)」技術を用いて実行させるパターン。

コンテナの採用により仮想サーバーと比較して、リソース利用の効率化、より柔軟性の高いインフラを実現し、スパイク時のオートスケーリングの対応速度や耐障害性を引き上げることができます。

パターン3. WordPress静的化

通常のWordPressは動作環境として「PHPが実行できる動的Webサーバー」が必要です。

PHPが実行できるWebサーバーによって、サイト閲覧者がWordPressサイトへアクセスする度にリアルタイム(動的)にページを生成してブラウザに表示する仕組みとなっています。

一方この静的化では、WordPressサイトのページ・コンテンツを専用のプラグインで事前に生成させ、専用のWebサーバーに配置しておくことでリアルタイムでのページ生成処理を不要とします。

よって、閲覧者のアクセスによる負荷を軽減でき、かつ静的Web環境(CloudFront + S3)はAWSがスパイク時の拡張含めて管理するため、非常に堅牢で安定したパフォーマンスを実現できます。

各パターンのメリット・デメリット

各パターンはそれぞれトレードオフがあり、特性と制約を把握した上で、自社のWordPressサイトにフィットする方式を選択する必要があります。

	メリット	デメリット(制約)
パターン1. サーバー冗長化	一般的な仮想サーバーベースのため、WordPress利用時の制約がなく、他のVPSやオンプレミスからの移行が容易	OSやミドルウェアのアップデート運用が必要となり、運用工数・コストが他パターンと比較して高くなる。また、スパイク発生時のスケーリング(仮想サーバー増減)が最も遅い
パターン2. コンテナ	仮想サーバー同様にWordPress利用時の制約がない。仮想サーバーよりスケーリングが速く、かつコンテナ運用をAWSに移管できるため、運用コストを抑えられる	Dockerコンテナ技術の習得が必要(学習コストが発生する)
パターン3. 静的化	3パターンの中で最も堅牢性が高い。静的コンテンツ運用となるためスパイク発生時もパフォーマンス劣化が発生しづらい。	閲覧者がアクセスするWebサーバーではPHPが動作しないため、動的処理が必要なプラグインやカスタマイズしているWordPressサイトは適用できないケースがある