年末ですね。年末だからこそ大量のアクセスが発生することもありますね。コンシューマー向けのものだと、平時に比べれば多かったりしますよね。爆発的なアクセスになることもありましょう。おめーさん、容赦無いね！
特にHTTPS。コレはもうホントしんどいですよね。SSLアクセラレータとかSSLオフロードっていうか、そういう前段でさばくように構成して、実処理はHTTPのみにしとかないとHTTPSの処理に尋常じゃないCPU使用率を持っていかれたりしちゃいましょう。そーなると、本来の処理にCPUが割り当てられない。SSLハンドシェーク。悪魔のようです。でも、そんな構成すぐに取れない！そんな時の選択肢としてCDN。え？なんで？だってアクセスの総量が減ればその分処理量も減じゃない！コードチューニングより効果が高いこともあります。パフォーマンス20％アップのコードチューニングより200％アップ(することもある)のCDN。
お手軽なのはAmazon CloudFront。
- カスタムオリジンで既存サーバーをそのまま利用することで、オリジンサーバーにコンテンツを事前にアップロードしなくてもいい
- URLRewrite2.0から導入されてるOutboundRulesでのHTML書き換えで、CDNを指すようにしてしまうことで、レンダリングコードに(ほとんど)手を加えずにCDNが使えるようになる
- CNAMEでカスタムドメインでもそれなりに(HTTPSのカスタムドメインはダメだけど)
- コンテンツへのHTTPSアクセス負荷をCloudFrontに肩代わりさせれる(コレ！！)
- 使ったぶんだけ課金は、いまさらですけどやっぱり素敵ポイント
もちろんIISね。Apacheもなんか書き換えありましたよね。mod_ext_filter？IIS以外はよく知らないです。
ココはひとつ、mvcPhotos(覚えてますか？)に実験台として登場してもらいましょう。
まだ見れる状態になったままでした。そろそろ閉鎖しないと．．．。
http://mvcphotos.codeplex.com/
CloudFrontの登録とか、そういうのはいろんな人が書いてるので、その辺は省略。
こんな感じですね。コレといって何のへんてつもない設定。カスタムオリジンとProtocol PolicyをHttp Only、CNAMEでカスタムドメイン(HTTPSの時は割り当てられたドメインをそのまま使う)。
あとは、Web.configにoutboundRulesを追加(ExpressWebでURLRewrite使えると書かれてるけど、バージョンが見当たらなかったから不安だったけど、ちゃんと2.0以降が入ってる模様)。
<rewrite>
<outboundRules>
<rule name="CloudFrontContents" preCondition="html" enabled="true">
<match filterByTags="A,Img" pattern="^/Photos/Image/(.*)"/>
<action type="Rewrite" value="//cdn.mvcphotos.takepara.com/Photos/Image/{R:1}"/>
</rule>
<preConditions>
<preCondition name="html">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="text/html"/>
<add input="{REQUEST_URI}" pattern="/mobile" negate="true"/>
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
これだけ。これで、/mobile以外の時に/Photos/Imageへのアクセス(a hrefとimg src)すべてCDNへ変更します(詳しくはCreating Outbound Rules for URL Rewrite Module : URL Rewrite Module 2 : URL Rewrite Module : The Official Microsoft IIS Site )。/mobileを除外してるのには理由があります。mvcPhotosはHTTPSでのアクセスが無いので意味ないんですが、実際は有りましょう。その際、ケータイからのアクセスだとCloudFrontで使ってるワイルドカード証明書が残念なコトになります。まだまだ正常に処理できないですよね。
なので、もともと素材の少ないケータイアクセスの場合(/mobile配下へのアクセス)は、CDNを利用しないようにして、コレまで通りのアクセスにしときます。PCやスマフォでのHTTPアクセスなら処理が負担にならない、って言う場合はconditionsを以下のように追加してHTTPSの時だけCDN参照するようにするのがいいでしょう。
<rule name="CloudFrontContents" preCondition="html" enabled="true">
<match filterByTags="A,Img" pattern="^/Photos/Image/(.*)"/>
<action type="Rewrite" value="//cdn.mvcphotos.takepara.com/Photos/Image/{R:1}"/>
<conditions>
<add input="{HTTPS}" pattern="^on$"/>
</conditions>
</rule>
ただ今回、mvcPhotosのちょっと残念だったところと、Cloud Frontの制限が丁度マッチして、ちょびっとだけViewとスクリプトの変更がありました。
画像を返す部分をPhotosControllerにやらせてるんですが、そのパラメータをRoutingじゃなくてQueryStringで渡してたんです。が、Cloud FrontはQueryString無視します。なので、そこだけ変更してQueryStringでのサイズと変換方法の指定をRoutingパラメータにしました。
/Photos/Image/1?size=100&type=fit
↑こうだったものを↓こう。
/Photos/Image/1/100/fit
そのためにRoute登録。
routes.MapRoute(
"PhotoImage",
"Photos/Image/{id}/{size}/{type}",
new {controller = "Photos", action = "Image"});
コードいじってるじゃん！さーせん。でも、普通はいじる必要ないはず。あっても、ViewやScriptだけで済むはずです。サービスとして公開するならURLの設計もちゃんとするはずなので。今回の微調整もRouting以外はViewだけ。View内にknockoutで使うHtml Template埋め込んでるし、パス関連は全てそのテンプレートに展開してるから、OutboundRulesの対象になる。
これで、mvcPhotosにアクセスしてみましょう。
クリックして拡大すると見えると思いますが、/Photos/Image配下はCDNへ。その他の要求(JavaScript/CSS/Ajax)は自サーバーに行ってますね。もちろんホントはJavaScriptやCSSも持っていくのがいいでしょう。
↑こちらは/mobile配下。今度は同じ/Photos/Image配下のものもCDNに行かず、自サーバー参照のままです。
なんてお手軽。
実際HTTPSを利用してるサイトでBLOBコンテンツのダウンロードが大量に発生している場合、この方法でサーバーへのコネクションを１／１０とかに抑えられることになって、ウハウハ。もちろんお金はかかりますけど。それでもサーバー増強やSSLアクセラレーションする機器の購入に比べれば、安いし経費で落とせます！HTTPSでのカスタムドメインが使えないのは気に入らない、って言うことがあるなら他の方法をとってくださいってことになります(ARRでSSLオフロードとかね、お金貰えればなんでもいいでしょう)。
とりあえず、今回のような方法でCDNを利用する時に、こういうふうにページ(View部)作るといいかもと、思ったことを書きだしておきます。
- 素材を意味ごとに決まったフォルダに分けておく
→ パターンを増やすとその分の処理にCPU使っちゃう - スクリプトでスクリプトをロードしないほうがいいかも
→ スクリプト内のパスを書き換えるのが面倒 - スクリプト内に極力パスを書かない
→ HTMLの属性を使う。DOMにデータを持たせとく。か、クライアントサイドのHTML Templateで。 - 同じくCSSの中でimportしないほうがいいかも
→ 相対パスなら許容可能 - HTML内のsrc/hrefはルートからの絶対パスで書いておく
→ 相対パスだとパターンがぶれるし、思わぬ参照先に。どうしても相対ならCSSにする - HTML内でスタイル指定しない
→ パスの書き換え問題。同じ理由でタグ要素にstyle属性も困る。
トリッキーなことしないで、メンテナンス性を考慮したページの作り方をしてれば、CDNへの振り向けはすんなり行きやすいという感じですね。
目指せ Ultra-Fast ASP.NET！
