技術めも

ここ最近、インフラ寄りの話ばかりであるが、

GooglePlatformで使えるCloudCDNについて書いておく。

CloudCDNはawsのcloud frontなどとは違い、

ロードバランサーの一機能として利用できる。

特徴としては、

ロードバランサーと同一ドメインで利用できるところである。

イメージ的には以下のようになる（実際は違いますけど。。）

    user <--> load balancer <--> cloud cdn <--> vm instance 

この構成のよいところは、オリジンであるVMインスタンス（awsでいえばEC2）に置いてあるキャッシュさせたいコンテンツを、

ロードバランサーと同じドメインで取得できるところである。

そのため、VMインスタンスに画像等を丸々配備できるため、開発者がインフラを意識する必要がなくなるということだ。

これに対し、他CDNの場合、キャッシュさせたいコンテンツを他ドメインから取得させるよう、

HTMLをコーディングする必要がある。

しかし、CloudCDNなら、それを意識する必要はない。

これは開発者から見ると非常に大きな利点である。

（awsのcloud frontのL7機能でキャッシュの有無を調整することは可能だが、キャッシュさせないコンテンツでも瞬間的にはキャッシュされるので、

一意URLによるGETなどはあらかじめ注意して開発する必要がある）

ただし、HTTP/1.1の場合、同一ドメインから同時にアクセスできるURL数というのはブラウザで制御しているため、

実際には様々なドメインから取得させた方がユーザへの体感速度の向上が図れるのは周知の事実である。

（HTTP/2ではこの問題も多少はマシになるとは期待してますが、、）

ただ、CloudCDNの残念なところは、現状キャッシュされているものの情報や、ヒット率等の統計が取れないところである。

しかし、何度も書いたように、開発者（もっといえばコンテンツ開発者）にありがたいインフラ構成というのは、特筆すべき点かと思われる。

以上

以前の記事で、CDNについて書いてみようかなということにしていたので、

次世代CDNとうたわれるfastlyについて書いてみる。

fastlyの最大の特徴は、

0.5秒で世界中のキャッシュを消す

というインスタントパージ機能である。

これはほんとにすごい。

他のCDNでは実現できていない高機能である。

実際にキャッシュが消えたかを確認するには、

キャッシュを消す前後で、以下APIをたたいてHASHを確認することができる。

https://docs.fastly.com/api/tools#content

実際にHASHは異なっていたし、キャッシュも消えていた。

もうひとつfastlyはすごいと思ったことがある。

それはキャッシュしなかった場合でも、

選択される回線の速度が非常に速い。

実際にルータのホップ数などを見ても、とても少ない。（そのため、オリジンとfastly間の転送料金が高めだが）

広域にコンテンツを展開したいとき、

非常に有効なCDNだと思われる。

以上

awsのIPv6対応状況をまとめてみる。

■ELB

dualstackから始めるドメインであれば、IPv6対応である。

Route53を使う場合は、AAAAのaliasを貼ればよく、

他DNSを使う場合は、CNAME設定になるのかな？

dualstack.XXX.ap-northeast-1.elb.amazonaws.com

■S3

こちらもdualstackのドメインであれば対応済みということである。

https://aws.amazon.com/jp/blogs/news/now-available-ipv6-support-for-amazon-s3/

■Cloud Front

こちらは執筆時点では対応発表済みであるが、

逐次対応が進んでいる状況である。

そのため、ひょっとしたら、設定したにも関わらず、

名前解決できない可能性もある。

https://aws.amazon.com/jp/blogs/news/ipv6-support-update-cloudfront-waf-and-s3-transfer-acceleration/

その他、EC2などはIPv4を前提とした設計となっているため、

対応にはしばらくかかるだろう。

ただ、外向きの部分において、awsはIPv6対応を着実に進めているため、

appleのATS問題などは回避できそうである。

その他、私が知っている限りだと、

• さくらVPS
• さくらクラウド

はIPv6対応が結構すすんでいる。

ただし、さくらクラウドは共用ネットワークではIPv6が利用できなかったので、注意が必要。（※あくまで執筆時点）

さくらは比較的早期からIPv6対応していたので、近いうちにもろもろ対応してくれるだろう。

以上

以前の記事でnginxのIPv6対応を書いた。

しかし、設定上、

ipv6only=on

という記述は、1度しか書けないため、

virtualhostで複数運用している場合に、この設定は邪魔となる。

virtualhostで運用する場合が多いので、

最終的には以下のようにすればよいのではないだろうか。

/etc/nginx/nginx.conf

http {
    :
    :
    # serverディレクティブは書かない
    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/conf.d/default.conf

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name localhost;
    :
    :

/etc/nginx/conf.d/your-ssl-vh.conf

server {
    listen                  80;
    listen                  [::]:80;
    listen                  443 ssl;
    listen                  [::]:443 ssl;
    server_name             your-ssl-vh;
    ssl_certificate         /etc/pki/tls/certs/server.crt;
    ssl_certificate_key     /etc/pki/tls/certs/server.key;
    :
    :   

このように記載しておくと、your-ssl-vhホストでは、

ipv4、v6の、non-sslまたはsslでのlistenとなる。

non-sslサイトを生きにしつつ、sslも併用し、

念のためipv6対応も入れたいというケースはこのような対応となるだろう。

以上