CDNを使うのはキャッシュ目的であることがほとんどですが、スムースなアクセスを実現するにはキャッシュする時間を長くすべきです。もし無期限に設定したら1度オリジナルファイルを読めば後はCDNのサーバーまかせにできるので非常に効果的ですね。
しかし実際のサイトを運営していくのは必ずファイル更新作業があり、この同じファイルの更新の場面でCDNが入っていることで問題なります。キャッシュ時間を長くすることと更新を反映させることはCDN使う上では相反する行為だからですね。
世の中ではこうした問題を軽減するための手法がいくつか存在します。その一つがファイル名にバージョンを入れるRevving Filenamesという手法です。
要するに更新があったら「test.1.0.1.jpg」のようにファイル名にバージョン番号などを入れることで違うリソースとして認識させる手法のこと。これ完全に自動化されたデプロイ環境ならいいけど、手動でこれをするのは手間が多すぎしミスも発生しそう。
今回は、仮にHTML生成がアプリだとしてHTML中のパスを変えるのは簡単で、静的ファイルのファイル名を更新管理するのが難しいケースにしぼって、この問題を少しでも軽減すべくCloudFrontとEC2で試してみました。
aiCacheのユニークな機能をまとめます。
・HTTPSターミネーション
・モバイル端末対応（リダイレクト、リクエスト書き換え・TTL変更など）
・GSLB対応（Dyn.com連携）
・レスポンスによるキャッシュ削除
・セッション毎のキャッシュ管理（ログイン中もキャッシュ管理可能）
・POSTリクエストのキャッシング
・指定URLのプリフェッチ
特に「レスポンスによるキャッシュ削除」と「セッション毎のキャッシュ管理」は良いですね。
先日に引き続きaiCacheネタ。
今回はセットアップ編。
aiCacheは有償の製品です。価格モデルとしては、パッケージ型ライセンス購入もしくはクラウド（従量課金）型の2種類から選択できるようになってます。
パッケージ型の場合の費用はこちらにあるので詳細は割愛しますが、HTTPSとモバイル向け機能が含まれるEnterprise版は$18,995、QA目的でも定価は$9,995と簡単に導入できる金額ではありません。
クラウド型の課金モデルを選ぶと、Amazon PaymentでaiCacheのサブスクリプション契約（$0.71/月）をすればその後は利用料を上乗せされた形での課金方式になり、もちろん時間課金・データ量課金となるため安価に始めることが可能になります。
ということでセットアップしてみましょう。
手順は以下のような形になります。
（0. AWSアカウント作成）←必要があれば
1. aiCache利用申し込み（サブスクリプション契約）
2. aiCache初期設定ファイル作成および設置
3. aiCache AMIによりインスタンス起動
昨年秋に公式に発表されて、今年上期に利用開始予定となっていたシンガポールのデータセンターがなんと本日サービスインしました。
発表によれば、以下のサービスが利用可能になったそうです。ちなみにアメリカ西海岸のRDSは無かったのですが、先にシンガポールで対応してます。
- Amazon EC2 （Elastic IP Addresses, Amazon CloudWatch, Elastic Block Storage, Elastic Load Balancing, Auto Scaling 込み）
- Amazon S3
- Amazon SimpleDB
- Amazon RDS
- Amazon SQS
- Amazon SNS
- Amazon DevPay
- Amazon CloudFront
少し前の話になりますがお仕事の記録。
パナソニックと世界中の人々のエコアイディアを集めて共有するサイト、ecoideasnet。
クライアントはパナソニック。以前在籍していたビジネス・アーキテクツから呼んでもらってテクニカルディレクターとしてプランニングから参加しました。企画段階ではコンセプトに合うアーキテクチャと連携するサービスの提案、そして開発スケジュール策定と概算費用まとめ。設計段階では採用したプラットフォーム（Amazon Web Serives）に最適なシステム構成立案と協力な開発チームのビルドアップ。開発から納品までは工程管理および品質管理の立場で関わりました。詳細な設計〜実装はアイレットにお任せしてます。
サイトの説明はこちらにまかせるとして、個人的に紹介したいところを書いときます。
【ソーシャルサービスとの連携】
・facebook, Twitter, Google との認証連携
・facebook, Twitter へのアクティビティフィード
このサイト独自に個人情報を取得することなく、既存サービスとアカウント連携し登録が行えます。さらにサイト内での活動を外部へ告知することが可能で、サイトと外部のサービスをうまくつなぎ inbound/outbound の誘導をしやすくしてあります。
【Amazon Web Services を全面採用】
・Amazon EC2, EBS, S3, CloudFront, ELB, Elastic IPs
ウェブサーバーを多重化、アプリデータはEBS、バックアップはS3、スタティックなファイル群はCDNを利用して配信する形を基本として、サイトアクセス自然増はもちろんピークにも対応しやすい構成になってます。
なんと Amazon が Adobe Flash Media Server を使ったストリーミングサービスを開始。
Announcing Amazon CloudFront Streaming
Amazon CloudFront, the easy-to-use content delivery service, now supports the ability to stream audio and video files. Traditionally, world-class streaming has been out of reach of for many customers - running streaming servers was technically complex, and customers had to negotiate long- term contracts with minimum commitments in order to have access to the global streaming infrastructure needed to give high performance.
しかも CloudFront にストリーミング機能が追加された形になっていて、難しい設定なしに利用が可能になってる。さらに、なんと、この機能を使うことによる追加料金は一切なく CloudFront 利用時の通常料金（データ流量に対する従量課金）のみで利用可能になっている。
はて、Flash Media Server のライセンス契約はどうなっているのかしら？Amazon向けに特別なライセンス体系を準備したのでしょう、きっと。とはいえ、上乗せしてこないのは良心的。
一番の驚きは利用が簡単すぎること。まだ試してないけど、Amazon S3 にアップして該当する bucket を CloudFront 利用するよう設定しておしまい。ちょっとがんばれば Flash エンジニアがサーバー側の管理者の助け無しにストリーミングを利用した映像再生機能を実現できることになるわけだ。すごいねー。
