そうだ、Azureを使ってみよう!と考えて一番に思いついたこと。
最近、Microsoft Azureを身近に感じることが結構ありまして、無償体験枠で遊んでみようかなーと感じていたところ、今何を使うのが一番幸せかなー・・・・と考えた結果、「CDNを入れ替える」と言うのが一番面白そうだという結論に達しました。
これまでCloudFlareの無償枠を使用してきたのですが、いくつか不便な点があって
- 生のアクセスログが手に入らない(Google Analytics頼り)
- サイドがダウンした時、キャッシュを見せてくれるようになっているが、そもそも「サイトが堕ちてますよー」て表示がでかでか為されてしまい、あまり意味がない・・・
- DNS管理をCloudFlareに寄せなければならなくて、若干Route53が使えてないのが寂しい
というところを改善できたりしないものかと。そこで、AzureのCDNサービスを使ってみることにした感じです。あと、有償サービスにした場合、当方ブログはどれほどのコストがかかるのかを試算したいという意図もありました。
Azure CDNのラインナップと選択したもの
Azure CDNは元々、オリジナルのサービスというのはなく、AkamaiとVerizonからサービスをOEM提供してもらっているような感じになってます。
- Akamai Standard
- Verizon Standard
- Verizon Premium
ただ最近、これに独自サービスとなる「Microsoft Standard」というものも加わりました。で、私はこれを選択しています。理由は至極単純で、「手持ちの証明書を使えるCDNサービスはこれだけだったから」というものになります。
他のサービスの場合、DigiCertというところの証明書を使用することになるんですが、これの手続きが何故かうまくいかない。加えてWhoisの問い合わせ先アドレスも隠蔽されていたりするので、このやり取りに時間がかかる。
自前の資産で手っ取り早くできるところは手っ取り早くしたいということで、Microsoft Standard一択となりました。
Azure CDN Microsoft Standardの構成概要
Azure CDNの大体の構成は上図のような感じです。リバースプロキシの集まりであるPOPをキャッシュサーバとし、それがリージョン毎に存在しています。構成要素は上図ツリー状になっており、まずはCDNプロファイル、次にエンドポイント・・というふうに構成をしていきます。
なお、プロファイル作成時にエンドポイントも一緒に構成できます。
ただ、一緒に構成させた後、エンドポイントの修正が多分必要になると思います。
事前作業
いくつか事前作業を実施します。それが、CDNサービスのアカウントをAzure AD上で認識させることです。これをやっておかないと、証明書を登録する際に、Azure CDNが証明書等の参照ができずに、作業が途中で止まっちゃいます。
私は端末にAzure PowerShellを組み込むことで対応しました。
以下のように進めることで、Azure用PowerShellが使えます。
そして、以下のようにしてMicrosoft.Azure.Cdnを登録します。
続いて、証明書の登録を行います。Microsoft版CDNでは、自分の手持ちの証明書を使用することが可能です。そのために、まずはKey Vault(キーコンテナー)を作成する必要があります。以下の流れで作っていきました。
証明書の登録に関しては、「.pfxファイル」を使用する必要があります。所謂PKCS-12形式の証明書で、秘密鍵、証明書、中間証明書を含んだオールインワン形式です。これを証明書として組み込むことで、後のカスタムドメイン設定で証明書の取り込みが可能となります。
CDNプロファイルの作成
CDNプロファイルを構成する前に、例えば私の場合、CloudFlare上のDNSにwwwのレコードをA/AAAAレコードで構成していました。Azureでは、権威DNSサーバに予め定められたEdgeServerのFQDNをCNAMEとして登録する方法を採用しています。
そのため、予め権威DNSに対してwwwレコードを削除し、オリジンサーバとしての別のAレコードを別途構成しておきます。その上で、CDNプロファイルを構成します。
CDNプロファイルで、「価格レベル」には「標準 Microsoft」を指定、CDNエンドポイントは任意の名前、配信先の種類はカスタム、ホスト名は変更した、オリジンサーバのAレコードに基づくホスト名を指定します。
名前解決設定の変更
ここで、名前解決設定の変更を行っておきます。プロファイルを構成した時点で、CDNアクセス先URLが決定します。その決定内容に基づいて、「本来のFQDN」と「CDNアクセス先FQDN」を対応付けるCNAMEを作成する必要があります。
TTLはこの作業をする前の段階で確認する必要があります。TTLが異様に長い場合、TTLを短い値に変更の後、設定前のTTL時間が切れるのを待つしかありません。このあたりはきちんと事前調査したほうが良いと思います。
なお、CloudFlareではTTLはAutomaticになっており、おそらくはデフォルト300secぽいです。
Google Public DNS等で変更が反映されたかどうかを確認します。
カスタムドメイン設定
カスタムドメインの設定を行います。
カスタムドメインとは、所謂「ユーザがアクセスする先のFQDN」のことです。以下の流れで作っていきます。
キモになるのは、証明書の適用です。
事前に作成したKeyVault内にある証明書を選択して、「保存」をクリックすると、証明書の要求が発行され、続いてPOP内のサーバに対して手持ちの証明書のデプロイメントが行われます。
図にもあるように、この証明書のデプロイメントは最大2時間かかると言われています。実際やってみた感じでは、書いてあるとおりピッタリ2時間程度かかったように見えます。というわけで、実際適用されるまではそれなりに粘り強く待ったほうが良さそうです。
配信先(オリジンサーバ)設定
オリジンサーバである、エンドポイントの「配信元」はプロファイルを作成した時に自動的に構成されていたと思います。ただこの時点では、「配信元のホストヘッダー」が「配信元のホスト名」と同一になっていると思います。
これでは、例えばWAFやReverse Proxyを構成している場合、意図したとおりにオリジンサイトへアクセスしてくれず、想定外の結果が表示される可能性があります。そのため、ちゃんと「www.bluecore.net」としてアクセスできるように、ホストヘッダーの設定を変更します。
また、オリジンサーバの構成によりけりですが、プロトコルとポートの設定を行います。
なんとなく・・・なところですが、どうもここで指定するプロトコルをそのままスルーしてオリジンサーバにアクセスするようです。つまり
- HTTPアクセスに対しては、オリジンサーバへHTTPプロトコル/HTTPポートでアクセス
- HTTPSアクセスに対しては、オリジンサーバへHTTPSプロトコル/HTTPSポートでアクセス
という感じになるようで、実はここが一番苦労しましたー。どっちで待ち受けとけば良いのか分からなくて。
動作確認
ネットワークを宅内LANではなく、インターネット直通に変更し、外部からサイトアクセスできるかどうかを試したところ、きちんとアクセスできることを確認しました。証明書の動作に関しても問題なさそうです。
ざっくりした感想
CloudFlareと比較して気になったのは以下の点です。
- 統計・ログ・解析系の機能を動かすのに結構ハードルが高い&そこにコストがかかる
- どうもログをそのまま取得等はできないようで、調査ログを有効にする必要があるようです。しかもこのログ、取得するには別途Azureサービスの一部を使用する必要が出てくるため、その分コストがかかることになります。
- Verizon版の場合、レポートがある程度できるようになってるみたいなのですが、Microsoft版の場合、Azureサービスと連携してなんぼと言う考え方があるみたいです。
- ただ、その肝心な連携サービスの扱いが難しいというのが難点ですかね。未だにOperations Managerの扱いが理解できておりません・・勉強あるのみですかね。
- キャッシュルールの記載ができないのは少々つらい
- キャッシュルールに関して、CloudFlareだと結構細く設定ができた(数に制約はあるが)のに対して、AzureCDN(MS)の場合、ルールはたった3つ、クエリパートに対するルールしかありません。
- キャッシュの最適化パターンも静的ページを前提としているようで、動的ページには対応しきれてないor有償オプション追加と言う形になりそうです。
- DNSサーバを委託せずに済む、CloudFlareのDNSを使っていながら適用ができるので、切り戻しはすこぶるしやすいです。そういう意味ではこのCDNサービスは扱いやすいなーと思います。
- 東西日本両リージョン、そんなに思ったほど高くないっぽい
- 現在西日本リージョンを使用していますが、GB単価は15.46円が最大となっています。
- どの程度のPV数があるか次第ではありますが、そこの見極めをこれから1ヶ月間でやってみようかなと思っています。
- MS版はパブリックプレビュー版らしいので、半額とのこと。まだしばらくはお安く使えるんじゃないかという淡い期待もあったり。
最終的には、見極め完了してみて使えそうだったら、DNSをRoute53に戻したいなーと考えています。場合によってはAzureDNSにするのもありだなーと考えておりますれば。果たしてどうなることやら・・と言う感じです。
Comments are closed