CloudFrontを利用して静的コンテンツを高速化する

このブログサイトをCloudFrontを使って高速化してみた。
早くなったかどうかはちょっとわからないが、Googleからのリクエスト速度は間違いなく上がっているので、検索順位向上には寄与している(と思いたい)。
CloudFrontはCDN(Content Delivery Network)のサービスだが、EC2やLamdaなどのAWSのサービス以外にも利用できる。
昔はCDNなんてakamaiぐらいしかなく、個人が使えるようなサービスではなかった。
CloudFrontを独自ドメインで利用するメリットは下記が挙げられる。
1.全世界からのアクセスが高速化できる。(CDNの導入目的と同じ)
例えば、当ブログサイトのドメインに割り当てられているアドレスd2p33equgohrri.cloudfront.netを正引きすると以下のように8つのアドレスが返される。
このアドレスは、リクエスト元の地域(リージョン)によって変わることになる。
>nslookup -q=A d2p33equgohrri.cloudfront.net
権限のない回答:
名前: d2p33equgohrri.cloudfront.net
Addresses: 54.230.111.20
54.230.111.187
54.230.111.227
54.230.111.55
54.230.111.251
54.230.111.57
54.230.111.220
54.230.111.238
2.Webサーバへのリクエストを減らすことが出来る=負荷を軽減できる。(CDNの導入目的と同じ)
3.(D)Dos攻撃にも耐えられる。(CDNの導入目的と同じ/但し、リクエスト数が増大するので、課金がかさむことになる)
4.CloudFrontをSSL化しておいて、CloudFront→Webサーバ 間をHTTP通信にすることにより、昨今のセキュリティ要求に対応しながら、SSL通信にかかる負荷を軽減できる。
5.SSL証明書が無料で利用できる(CloudFront独自のメリット/但し、IPベースにすると毎月600ドル課金されるので注意)
6.AWSの無料枠の対象なので、気軽に試せる(CloudFront独自のメリット)
7.HTTP/2に対応できる。(CloudFront独自のメリット?/リクエストが高速になる)
SSL証明書はLet’s Encryptを利用する方法もあるが、CloudFrontを利用すると証明書の期限が13ヵ月になっているうえ、更新が自動で行われる点がビジネス目的に耐えられる点で優れている。
CloudFrontを利用するにはWebの画面だけで完結できるが、日本語化されておらず少しハードルは高い。
ただ、WordPressサイトをCloudFrontで配信するの説明が非常に分かりやすい。
上記サイトでは、WordPressサイトの登録を変更していたが、
Origin Domain Name には、CDN用のエイリアスFQDN(例:cdn.blog.development-network.net)
Alternate Domain Names には、オリジナルのFQDN(例:blog.development-network.net)
を登録し、cdn.blog.development-network.netのCNAMEに登録後に表示されるDomain Name(例:d2p33equgohrri.cloudfront.net)をDNSに登録すればよい。
SSL証明書の発行手順は、認証がメールベースになっているので、独自ドメインのメールエイリアスを登録できるようになっている必要がある。
SSL証明書を発行しても、すぐに独自ドメイン用のSSL証明書に切り替わらず、証明書エラーが表示されるので、少し焦るがCloudFrontのStatusがDeployedになるまでは待ってみることをお勧めする(焦った)

AzureDNS

先日AWSのDNSサービスを利用したmydnsからroute53へ移行するを紹介したが、Windows AzureでもAzure DNSがあるようだ。
価格を見ると、AWSとほぼ変わらないか、少し高い感じがする。
ところで2/11からzaiteku.jpドメインをroute53へ移行した金額を下記に公開する。
現時点では、mydnsと2重化している(下記Whois情報参考)ので、4/6のクエリになっていると推測される。
請求金額
請求明細.jpg
参考)Whois情報
$ whois zaiteku.jp
[ JPRS database provides information on network administration. Its use is ]
[ restricted to network administration purposes. For further information, ]
[ use ‘whois -h whois.jprs.jp help’. To suppress Japanese output, add’/e’ ]
[ at the end of command, e.g. ‘whois -h whois.jprs.jp xxx/e’. ]
Domain Information: [ドメイン情報]
[Domain Name] ZAITEKU.JP
[登録者名] Development Network
[Registrant] Development Network
[Name Server] ns-1447.awsdns-52.org
[Name Server] ns-2016.awsdns-60.co.uk
[Name Server] ns-229.awsdns-28.com
[Name Server] ns-925.awsdns-51.net
[Name Server] ns0.mydns.jp
[Name Server] ns1.mydns.jp

mydnsからroute53へ移行する

dynamic dnsサービスであるmydnsからAWSのroute53へ移行してみた。
dynamic dnsの移行なので、いろいろ考慮しないといけない点はあるものの、オンプレのDNSサーバを移行するのであれば、かなり楽に移行できそうな感覚だった。
理由は、
・mydnsサービスが昨年使用できない障害が2度発生していたこと(無料で利用させて頂いているだけに何も言えないのですが、DNSが引けなくなることでインターネットから孤立するのは辛すぎる)
・AWS移行検証に当たってまずは移行しやすい部分からやってみたかったこと
やってみて分かったこと
・route53のインターフェイスは英語。でもなんとかなる。
・1ドメイン当たりの管理コストは0.5ドル。
・IPv6をダイナミック管理しようとすると、自前で作らないと難しいかも。(後述記載のサービスの安定性に依存してしまう)
AWS route53セットアップ(2ページ目は使用しない)
Route 53でダイナミックDNSを運用する
IPアドレスを更新するスクリプト
Route53に設定したドメインをスクリプトでDDNS
なお、上記スクリプト実行のためには、下記パッケージを事前にインストールしておく必要がある。(yum installコマンド等)
curl
jq
AWS CLI
その他参考)自分のグローバルIPアドレスを返すサービス(IPv6対応サービスは見つからなかったのが残念)
curl httpbin.org/ip
curl ipinfo.ip

Amazon Route 53って

DynamicDNSサービスのmydnsと何が違うねん!という話題。
・SLAが100%らしい。
※備考)後日mydnsのサービス障害が2回発生し、インターネットから孤立したが問題になり、半年後にmydnsからroute53へ移行するを書くことになるとは、当時は予想できなかった。。。。
・AWSでシステムを組もうと思うと、Amazon EC2ではElastic IPを割り当てない限り、インスタンスを再起動するごとにパブリックIPアドレスが毎回変わってしまうので、Route 53を使って動的にIPアドレスを設定するといったこともAPIを利用して実現できる。