コンシューマー向けの大規模ポータルサイトを運営するお客さまのコーポレートサイト運用事例をご紹介します。CMSはWordPressを採用し、スペックの高いEC2インスタンス1台構成で運用しています。
概要
- 一部上場企業のコーポレートサイトの運用
- CMSはWordPressによる
- WordPressのアップデートや改修時のメンテナンスによる、ダウンタイムは極力避けたい
- ELBによるマシンの入れ替え運用で対応
構成
今回構築したコーポレートサイトはクライアントがお持ちのセキュリティアプライアンスを経由したアクセスを可能とする必要がありました。セキュリティアプライアンスを通過した後も、HTTPSの暗号化通信を行う必要があったためWebサイト側のELBにもSSL証明書を組み込んでいます。
構成解説
セキュリティアプライアンス
クライアントが準備されたセキュリティ製品です。通信内容に異常がないかを確認するため、SSLターミネーションの処理を行っています。その後、再度SSL化をしてWebサーバーへHTTPS通信を行っています。
ELB（ロードバランサ）
ELBを配置している理由は2点あります。1つ目は、WordPressのアップデート作業や改修時にサイトのダウンタイムなく、EC2インスタンスを入れ替えるためです。 2つ目はSSL証明書はクライアントから提供いただいているのですが、秘密鍵を共有することを避けたいポリシーがありました。そこで、AWSのACMを利用することで秘密鍵を預かることなく証明書の運用を行うこととしました。
EC2インスタンス
WordPressが稼働しているEC2インスタンスです。個人情報の取扱いもなく、大きな負荷も見込まれないことからコスト抑えるためにEC2の1台構成としています。 セキュリティアップデートを行う際は、本番環境のコピーを作成してアップデートおよび動作検証を行います。その後、本番マシンと付け替えを行うことでサイトのダウンタイムをなくしています。
構築の効果
メンテナンスによるダウンタイムゼロ
WordPressは脆弱性が発見されることも多く、メンテナンス頻度が高いCMSです。検証および本番反映フローを確立することで、サイトのダウンタイムをなくすことができました。
セキュリティの強化
WordPressの手前にセキュリティアプライアンスをかますことで、セキュリティを高めています。既にお持ちの資産を有効に活かすことができました。
セキュリティポリシーへの対応
クライアントのセキュリティポリシー上、SSL証明書の利用に必要な秘密鍵を受領することが難しい状況でした。構築および運用フローが複雑化する懸念がありましたが、AWS Certificate Managerを利用することで、秘密鍵を受領することなく、SSL証明書を複数配置することができました。
おわりに
ダウンタイムを極力なくすよう設計したWordPressの構築事例をお伝えしました。WordPressのアップデートは頻繁に発生しますが、運用体制をしっかり準備しておけば問題ありません。
また、SSL証明書の秘密鍵を受領できないポリシーに対し、ACMがよい対策となりました。既に持っている資産を有効に活用できるツールがたくさん揃っているAWSの良さが実感できた事例でした。
