どうも。
伊藤です。
WordPressで構築したメディア規模が大きくなってきたため、リニューアルと合わせてインフラ面を色々と改善したい！という相談を最近いただきました。WordPressだけでなくMovable TypeなどCMSでサイトを構築する場合は手軽さもあり、今回の相談のように1台のサーバーでサイトを構築している事が多いように思います（最低でも両輪は欲しい！）。
メディアなどアプリケーションの類が少なければ「小さく産んで大きく育てる」という事で1台構成でスタートする事も多いですが、規模が大きくなってくるとどうしても色々な事が心配になってきます。
今回相談のあったWordPress製サイトがAWSクラウド（Amazon Web Services）で構築されていたため、AWSのサービスの紹介と合わせて対策した内容の一部を記載します。
Route53
スタンドアローン構成となるとSPOF（単一障害点）どころかいつ障害が起きても文句を言えない状況のため、まずは可用性など信頼性の向上のためにドメインを取得した会社のDNSからAWSのDNSサービス「Route53」でドメインを管理するように変更しました。
Route53はルーティングなどレコードの管理だけでなく、ヘルスチェックやフェイルオーバーなど可用性や耐障害性を向上させる機能が備わっています。
※可用性や耐障害性の向上以外の理由
ネイキッドドメイン（Zone APEX）でCDN（CloudFront）を利用したかったのも管理をRoute53に変更した理由の1つです。CDNを利用するためにCNAMEレコードの設定が必要になりますが、ネイキッドドメインにはCNAMEは利用できず、ALIASレコードを使えるDNSサービスが必要だったからです（Route53はALIASレコードを利用できます）。
ELB（Elastic Load Balancing） & Auto Scaling
次にRoute53とWebサーバーの間に「ELB」というロードバランサーを追加し、Webサーバーを1台から冗長構成に変更しました。冗長構成の台数はコスト最適化を考慮し、「Auto Scaling」でアクセス数や利用状況など需要に合わせて伸縮できるようにします。サーバーを増やす事で1台の時よりコストは嵩みますが、需要に合わせて増減させる事で無駄なコストは発生させず、且つユーザーにもストレスを与えないようにする事ができます。
ELBは耐障害性に長けており、デフォルトでアベイラビリティーゾーン間（数キロメーター以上離れたデータセンター間）で冗長化されます。またWebサーバーも冗長構成のためどこかで障害が起きてもサイトの稼働は維持できるため、単一障害点もなくなり安全です。ELBは昨年末までWebサーバへの接続にHTTP/1.1しか利用できないという課題がありましたが、今ではHTTP/2とgRPCプロトコルもサポートされたため、End to EndのHTTP/2通信も可能です（低レイテンシー、データ転送コストの節約が可能）。
EFS（Elastic File System）
Webサーバーを冗長化する事でWordPressの管理画面で管理するコンテンツやメディア、モジュールなどは各Webサーバーから同じ内容を参照できるようにするため、共有領域で管理するように変更が必要です。
ファイル関連だと画像などのメディア（ディレクトリだと/wp-content/uploads）、モジュール関連のプラグイン（ディレクトリだと/wp-content/plugins）が対象になります。
AWSには様々なストレージサービスがありますが、既に構築・運用されているサイトの改善という事もあり、プラグインやソフトウェア（プログラム）部分の改修は一切せずに済む「EFS」を採用しました。
後述する理由にもあるようにEFSはファイルI/Oのパフォーマンスに若干の不安はありましたが、今年の1月末に読み取りスループットが3倍になったという点を信じる事にしたのと、そもそもファイルへのアクセスを減らす（キャッシュなど）事で対策する事にしました。
※以下、主なストレージサービスからEFSを選択した理由概要
S3：耐久性や可用性の高さなど魅力的だが、API利用における改修が必要になるのとマウント利用は不向き。
EFS：今回のサイトのOSがLinuxだったのと、NFSマウントするだけで済む。パフォーマンスだけ若干不安。
FSx：Linuxでも利用できるがWindows向き（SMBプロトコル、AD連携など）。
EBS：複数のWebサーバー（EC2）にアタッチできない（一部リージョンでは可能ですが、東京では不可）。
※画面テンプレートやテーマ（ディレクトリだと/wp-content/themes）も場合によっては共有領域で管理する必要がありますが、今回のサイトの場合はテーマをWordPress以外で管理していたため、Deploy時に各サーバーへ配布しています。
RDS（Relational Database Service）
Route53やELB、Auto Scalingのように可用性や耐障害性向上のため、さらにはEFSで対応した冗長化構成における共有領域の確保のため、データベースをRDB on EC2（スタンドアローン）から「RDS」に変更しました。
パフォーマンスや耐久性向上のためリードレプリカを適用し、マルチAZ（アベイラビリティーゾーン）とする事で更に耐障害性を向上させます。
今回に限らず、OSレベルでの調整や細かなオプション指定が必須でない限りはRDB on EC2ではなくフルマネージドサービスのRDSを採用する方が望ましいと思いますし、圧倒的に運用コストや負荷は下がります。セキュリティパッチやハードウェアの監視は結構な重労働ですからね・・・冗長化やレプリケーションもRDSであれば管理画面から簡単に作成できますが、これを1から構築するとなるとかなり大変です。
CloudFront（Edge Location）
冗長化する事による負荷分散、機能毎の専用化（RDSなど）によるリソース分散など、これまでに上げたサービスでもパフォーマンスの改善には繋がっておりますが、更にパフォーマンスを改善するためにコンテンツ配信ネットワーク「CloudcFront」を導入しました。
CloudFrontはエッジロケーション（Edge Location）アクセスとなるため、物理的な通信距離が近くなります（CloudFrontを利用せずにWebサーバーにアクセスした時より、物理的に近くの場所にキャッシュがある状態）。キャッシュサーバ・プロキシサーバのようにWebサーバーの負荷を軽減してくれ、クライアント（サイト利用者）とWebサーバー間の無駄な通信も減らしてくれます。メディアなどコンテンツが多いサイトで採用しない選択肢はないのでは？と個人的には思っていますが、未導入だったため追加しました。
最後に
1台のサーバーからの改善として信頼性（可用性など）、パフォーマンスの効率化、コスト最適化にフォーカスしてサービスや対策を挙げてきましたが、1台構成複数台構成に関わらず「運用のしやすさ」や「セキュリティ」も非常に重要です。
今回のサイトにおいても運用面やセキュリティの対策として、上述していない様々なサービスを追加採用しており、本当にAWSには便利なサービスが豊富に備わっています。
現状は1台のサーバーで運営しており少し不安を感じている・・・どんどんサイトのレスポンスが遅くなってる・・・運用面やセキュリティ面を改善したいと感じた方は是非弊社までご相談ください。
逆に、スモールスタートの対応も可能です。1台構成でも様々なやり方があり、AWSにはLightsailなどある程度拡張性もあるWordPress製サイトを10～15分程度で簡単に作成できるサービスもあります（もちろん、AWS以外でも対応可能です）。
不安や不満を飛ばすため 窓を開けたHigh Way（強化しようぜInfra）～♪♪
ではでは。
