CloudFront + Lightsail + WordPress で超簡単にセキュアでハイパフォーマンスなサイト構成を作る。
何度か当サイトの構成を紹介していましたが、ちょっと構成を変えたので改めて紹介しようと思います。
以下が構成図です。非常にシンプルです。
この構成の良いところは以下の通りです。
- 全ての通信をセキュアな HTTPS 通信とする。
- HTTPS 通信に必要な SSL 証明書は自動更新・無料な Amazon Certificate Manager を使える。
- CloudFront のキャッシュによるハイパフォーマンスなサイトを実現出来る。
- CloudFront を経由しないリクエストはブロック出来る。
HTTPS 通信とは
HTTPS 通信とは簡単にいうと Web サイト間のデータが暗号化される通信です。安全なサイトを作るには欠かせないものになります。
ただ個人ブログのようなサイトで通信を暗号化させることにどれほどの意味があるのか疑問に思われるかと思います。確かにその通りだと思います。ただ HTTPS 通信を行うメリットは他にもあります。
HTTPS 通信のメリット
それは SEO 効果です。要は HTTPS 通信が出来ると Google 検索に引っかかりやすいということです。これは非常に大きなメリットです。
こうした理由から、Google では過去数か月にわたり、Google のランキング アルゴリズムでのシグナルとして、暗号化された安全な接続をサイトで使用しているかを考慮に入れたテストを実施してきました。この実験ではよい結果が得られているため、ユーザーがもっと安全にサイトを閲覧できるよう、すべてのサイト所有者の皆様に HTTP から HTTPS への切り替えをおすすめしたいと考えています。
https://webmaster-ja.googleblog.com/2014/08/https-as-ranking-signal.html
また HTTPS 通信が出来ていないとブラウザに以下のように表示されてしまいます。非常に印象が悪くサイトを訪れてくれても怖くなって離脱してしまうかもしれません。
HTTPS 通信を行うには
HTTPS 通信を行うためには SSL 証明書というものが必要になります。ただこの SSL 証明書の管理が案外面倒くさいです。
SSL 証明書というのは簡単に言うと、信頼された第３者によってこのサイトは安全ですよ、ということを証明しているものです。従って SSL 証明書というのは自分だけでは作れません。また安全性というのはいつ崩れるかも分からないので証明書には有効期限もあります。なので第３者に定期的にサイトの安全性を証明してもらう必要があるのです。はい面倒くさそうですね。
この面倒くさいのを解消するのが今回使用する Amazon Certificate Manager です。
Amazon Certificate Manager とは
Amazon Certificate Manager は AWS の SSL 証明書を作成・管理してくれるサービスです。無料です。そして定期的な更新は自動で行います。
AWS Certificate Manager を使用すれば、SSL/TLS 証明書の購入、アップロード、更新という時間のかかるプロセスを手動で行う必要がなくなります。
https://aws.amazon.com/jp/certificate-manager/
非常に便利なサービスですがデメリットもあります。Amazon Certificate Manager で作成した SSL 証明書を使える場所が限られているということです。使える場所は基本的に AWS のサービスに限られます。また Lightsail にも使えません。使えるサービスは以下の通りです。
AWS Certificate Manager なら、証明書をすばやくリクエストして、Elastic Load Balancing、Amazon CloudFront ディストリビューション、Amazon API Gateway の API など ACM に統合された AWS リソースでデプロイできます。
https://aws.amazon.com/jp/certificate-manager/
ここで今回使う CloudFront が来ました。
CloudFront とは
CloudFront とは AWS が提供する高速コンテンツ配信ネットワーク (CDN) サービスです。
Amazon CloudFront は、データ、動画、アプリケーション、および API をすべて開発者にとって使いやすい環境で、低レイテンシーの高速転送により世界中の視聴者に安全に配信する高速コンテンツ配信ネットワーク (CDN) サービスです。
https://aws.amazon.com/jp/cloudfront/
CDN とはすごく簡単に言うとサイトのコンテンツを、（物理的に）全世界に配置されているサーバーにコピーしてそのサーバーからコンテンツを配信することです。
CloudFront (CDN) のメリット
メリットは大きく二つあります。
サイトのレスポンスの向上
全世界にサイトのコピーがある状態です。そして物理的に一番近いサーバーから配信されるのでサイトのレスポンス（表示速度）が良くなります。これは今更言うまでもない非常に良いメリットです。もしサイトの表示が遅いと記事を見る前にブラウザバック余裕ですね。
サイトダウンによる機会損失を防ぐ
二つ目は、サイトの負荷分散です。サイトのコピーが全世界のサーバーにあるので、そのサーバーにアクセスが振り分けられます。オリジナルのサーバーにはアクセスが減ります。もしバズってアクセスが集中してもアクセスが分散されるのでサイトがダウンする可能性が減ります。せっかくバズったのにサイトがダウンなんて非常に勿体ないことは起こしたくないですよね。
CloudFront (CDN) のデメリット
勿論何事にもデメリットはあります。こちらも主に二つのデメリットがあります。
料金
まずは料金。世の中何事もお金が掛かります。ただし従量課金です。使った分だけの金額が発生します。悲しいことにサイトへの訪問者が全然居なければお金が掛かりませんし、訪問者が沢山居たらその分お金が発生します。ただ訪問者が沢山いるということはサイトの広告収入などの収益が狙えると思うので全然ペイ出来ると思います。
サイトのページの構成次第で変わってきますが、実際にどのくらいの料金が掛かるかを計算してみましょう。
まずサイトのページサイズを Google が推奨する 1.6MB とします。そして１ページ当たりのリクエスト数は 10 とします。こちらはあまり根拠がない数字ですがページの HTML と画像や CSS の数分だけリクエストが発生します。
この条件で10万回（10万PV）のページへのアクセスが合った場合の料金は下の計算どおり約 2,000 円。意外と高いかもしれませんが、月に 10万PV もあれば２〜３万稼げると言われています。余裕で CloudFront の料金はペイ出来ますね。
トラフィック＋リクエスト数
= 1.6MB * 100,000回 * 0.114 USD/GB + 10 * 100,000回 * 0.0090USD/10,000
= 17.8USD + 0.9USD
= 18.7USD ≒ 2,000円
https://aws.amazon.com/jp/cloudfront/pricing/
コンテンツ変更の反映
サイトのコピーを全世界のサーバーに配置しますが、オリジナルの変更が全世界に行き渡るまで時間が掛かります。例えば記事の一部を変更してもしばらくは変更前の記事が見えてしまうということです。
この変更が行き渡るまでの時間の調整がなかなか難しいのです。ただその当たりをいい具合に行ってくれるのが WordPress プラグイン AWS for WordPress です。プラグインがいい感じにその時間を調整してます。
構築手順
非常に前置きが長くなりましたが、構築手順を紹介していきます。概要は以下の通りです。順に紹介していきます。
- プラグインのインストール
- CloudFront （ディストリビューション）の作成
- CloudFront （ディストリビューション）の設定変更
- プラグイン（SSL Insecure Content Fixer）の設定
- Apache の設定変更
プラグインのインストール
以下２つのプラグインをインストールします。
AWS for WordPress
AWS が出しているプラグインです。このプラグインを使って CloudFront を設定していきます。
CloudFront をゼロから設定しようと思うと設定項目が多くて大変です。しかもキャッシュ設定を間違えるとページが更新されないなどの問題が起こります。
しかしこのプラグインを使うと CloudFront の作成は勿論、wordpress に最適化な形にキャッシュ設定をしてくれます。非常に便利です。
SSL Insecure Content Fixer
今回 HTTPS 通信の終端は CloudFront です。Lightsail (wordpress) 自体は HTTP で構成します。しかしユーザーが実際に接続しているプロトコルと wordpress の構成がズレると予期せぬ挙動となりますが、それを上手いぐらいに調整してくれるプラグインです。
設定もワンポチで済み、非常に使いやすいプラグインになっています。
CloudFront （ディストリビューション）
作成
ここが一番時間が掛かる手順になりますが、手順を進める前に一つだけ決めることがあります。それは「公開するドメイン名」と「CloudFront から接続するためのドメイン名」です。
「公開するドメイン名」とは、そのままで、サイト閲覧者にアクセスしてほしいドメイン名です。既に wordpress を公開していればそのドメイン名になります。
「CloudFront から接続するためのドメイン名」とは、CloudFront の設定時に必要になるものです。普段は人に見られることがないものなのでテキトウな名前で良いです。
なお当サイトでは以下のようにしています。
- 公開するドメイン名 -> doc-sin.life
- CloudFront から接続するためのドメイン名 -> org.doc-sin.life
２つのドメイン名が決まったらこちらの公式手順を参考に進めてください。手順にある「オリジナルドメイン名」が「CloudFront から接続するためのドメイン名」で、「CloudFront 代替ドメイン名」が「公開するドメイン名」になります。ちょっと勘違いしやすいので注意です。
設定の変更
CloudFront の作成が終わったら二箇所だけ設定を変更します。
一つ名は「Origin Protocol Policy」を “Match Viewer" から “HTTP Only" に変更します。Lightsail には SSL 証明書を置かないので、オリジンへの通信を HTTP に固定させます。
二つ名は「Origin Custom Headers」の「Header Name」と「Value」に値を入力します。 ここで入力した値は後の手順で使います。
ここでは「Header Name」に”FromCloudFront”、「Value」に”true”と入力しています。
以上二つの設定を変更したら保存しましょう。設定の反映には２０分程度掛かるので手順を進めておきましょう。
プラグイン（SSL Insecure Content Fixer）の設定
こちらもワンポチで終わります。下の赤枠のものを選択するだけです。
Apache の設定変更
最後の手順です。この手順を実行しなくてもサイトは既に正常に見える状態ですが、この手順を実行しないと CloudFront を経由しない、つまり https://<CloudFront から接続するためのドメイン名> でページが表示されてしまいます。
Lightsail 内の /opt/bitnami/apps/wordpress/conf/htaccess.conf というファイルの末尾に下記を追記します。ここで先の CloudFront の設定で入力した文字列を指定します。
<Location />
SetEnvIf <「Header Name」の文字列> "<「Value」の文字列>" fromcloudfront
require env fromcloudfront
</Location>「Header Name」に”FromCloudFront”、「Value」に”true” であれば以下の通りになります。
<Location />
SetEnvIf FromCloudFront "true" fromcloudfront
require env fromcloudfront
</Location>追記したら下記コマンドで反映させます。
$ sudo /opt/bitnami/ctlscript.sh restart apache動作確認です。先に設定した「CloudFront から接続するためのドメイン名」、ここでは org.doc-sin.life ですが、https://org.doc-sin.life にアクセスしページが表示されないことを確認してみましょう。