これから Windows Azure を始める 開発者の皆様に知っていただきたい 8 つの真実 【Reloaded】～ いつつめ
さて、いつつめにお伝えしたい真実、それは Windows Azure が “PaaS” である、ということです。
PaaS とは、Platform as a Service(プラットフォームをサービスとして提供する）の略で、Windows Azure ではこれまでにお話しした障害からの自動回復や、セキュリティ、あるいはロードバランシングやスケールの仕組み、アプリケーション更新のための機能等、アプリケーションを稼働させるために必要となる様々な要件を “プラットフォーム” の機能として提供しています。この点が、他社が提供するクラウドサービスと一線を画する Windows Azure のユニークさであり、強みとなっています。
また、これまで紹介した機能以外にも、”PaaS” らしいサービスとして、レスポンスタイムを短くしたい、認証機能を付加したい、オンプレミスとのハイブリッドを構築したい、といったようなアプリケーション構築においてよくある要望に応える機能を提供しています。
まず、一つ目の「レスポンスタイムを短くしたい」といった要望。
これについては、コンピューティングサービス、およびストレージの最適化、といった正攻法以外に、ネットワーク的なレイテンシを解決することでレスポンスを早くする、という方法があります。
「ハイパフォーマンス Web サイト」(オライリージャパン ISBN 978-4-87311-361-6) においては、パフォーマンス改善の鉄則として、エンドユーザーへの応答時間のうちサーバーサイドで費やされる時間は 10% ～ 20% であり、残りの時間はコンポーネントのダウンロードに消費される（よって、クライアントサイドでのパフォーマンス改善が重要である）、という話が紹介されています。
実際にこのクライアントサイドでの時間（コンポーネントのダウンロードにかかる時間）の削減に関しては様々な手法があり、同書籍においていくつかの手法が紹介されていますが、それら手法の２番目に紹介されているのが CDN (Content Delivery Network)の利用です。
著者は Yahoo! のエンジニアとして、様々なパフォーマンス改善手法を提案していますが、CDN の利用に関しては、Yahoo! Shopping サイトの実績値として、おおよそ 20% のレスポンス向上効果があった、とあります。
この CDNですが、Windows Azure においてもサービスとして提供を行っています。
具体的には、Windows Azure の CDN サービスでは、各種静的コンテンツ(画像、CSS、JavaScript 等）の CDN を可能としています。
また、日本という地域性を考えると CDN の重要性はさらに増します。
現在、Windows Azure のデータセンターは残念ながら日本にはまだないのですが、CDN 拠点としては日本に存在しています。したがって、例えば Web サイトにおいて必要になる CSS や 画像を、Web Role とともにコンピューティングサービスに配置するのではなく、Windows Azure Storage に保存しておき、さらに CDN によってそのコンテンツを日本の CDN 拠点にキャッシュするようにすれば、ネットワークレイテンシを小さくすることが可能になります。
また、CDNとは異なるアプローチとして、Windows Azure には Traffic Manager と呼ばれる機能があります。
Traffic Manager では、ユーザーが Windows Azure 上のサービスにアクセスする際に、そのネットワーク的な距離に基づき、もっとも近いデータセンターに対して、そのユーザーリクエストを振り分けることが可能なサービスです。
具体的には、アジアのデータセンター、北米のデータセンター、および欧州のデータセンターを利用し、全世界に向けたサービス展開を行っているサービスがあったとします。
実際にはこれらのサービスは、各データセンターごとに異なる名前空間（ XXXXX.cloudapp.net の “XXXXX” の部分）を使うことになるのですが、Traffic Manager を利用すると、共通の名称（現在のところ trafficmanager.net ドメインのサブドメインとして）を使うことができるようになります。
サービス事業者は、この共通の名前 (YYYYY.trafficmanager.net) をユーザーに通知しておくと、この名前でアクセスしてきたユーザーは、Traffic Manager によってネットワーク的に最も近いデータセンターに誘導されることになります。
たとえば、アジアからアクセスしてきたユーザーであればアジアのデータセンターに、北米からアクセスしてきたユーザーであれば北米のデータセンターにそのリクエストを割り振ることが可能です。
この Traffic Manager と呼ばれる機能、今回は「レスポンスタイムを短くしたい」、というコンテキストでその機能を紹介しましたがこれは、Traffic Manager が持つ３つの負荷分散のストラテジーの一つである “パフォーマンス” に基づく機能です。
Traffic Manager ではこれ以外にデータセンターをまたがる負荷分散を可能にする “ラウンドロビン” (ユーザーリクエストは均等に分配される）と、サービス異常時に予備系のサービスへユーザーリクエストを振り分けるための ”フェールオーバー” の２つのストラテジーを利用可能です。
（”フェールオーバー” は、本番のサービスと別に、異常時にユーザーにその旨を伝えるためのサービスを用意しておき、本番サービス異常時には、ユーザーがその状況を知ることができるようにする、といった利用を想定しています。たとえば、Twitter の “くじら” のようなイメージです。）
また、Traffic Manager においては、サービスの稼働状況の確認を行っているため、あるデータセンターのサービスが不調な場合やメンテナンスのためにサービスを止めている、といった場合に、Traffic Manager 側がその状況を把握し、ユーザーのリクエストを他のアクティブなサービスに対して振り分ける、といった動きもデフォルトで用意されています。
つづいて、二つ目の「認証機能を付加したい」という要望。
これに関しては、Windows Azure では Access Control Service (ACS)というサービスを提供しています。
通常、サービスにおいて認証情報を付加する場合、独自のユーザーDBを構築するか、外部の認証機関との連携を行うかの２つの方法があるかと思います。
Windows Azure の ACS は、この後者の方法（外部認証機関との連携）を容易にするための仕組みです。
具体的には、あるクラウドサービス（クラウドアプリ）において外部の認証機関(ID プロバイダー）との連携を行おうとすると、組み込みたい認証機関ごとに、個別にやり取りを行うためのロジックを書く必要があります。
しかし、各認証機関においては用意されている連携機能は、それぞれ個別のプロトコル、フォーマットで提供されていることがほとんどで、また、技術的な要件が変更されることもあります。
ACS を利用すると、各認証機関との仲介を ACS が行うようになり、クラウドサービスからは、ACSとのやり取りのみを記述すればよいようになります。
この 「仲介」機能の中には、各認証機関にあわせた認証プロトコルの用意、および各認証機関から渡される認証情報（セキュリティ トークン）のフォーマット変換、などの機能が含まれます。
ACS は 「認証/認可」の分野が概念的に容易でなく、また現実世界での「認証/認可」に係る技術進歩や状況の変化も継続的にあるため、Windows Azure の中でも “使うのが難しい” サービスと思われがちですが、実際には管理ポータルにおける設定と、WIF(Windows Identity Foundation)を使ったアプリサイドへの ACS 組み込み（基本的にはウィザードベース）でお手軽に利用いただけ、かつ、有用性の高い機能の一つだと思います。
ご興味があれば、以下のクラウドカバー等もご参照ください。
- Windows Phone 7 における Access Control Service の活用 ～ クラウドカバー Episode 49
- Blob Share ～ Windows Azure を使ったセキュアなファイル共有 ～ クラウドカバー Episode 63
- Windows Identity Foundation と ACS 用の新ツール ～ クラウドカバー Episode 72
また、マイクロソフトにおいては Admiral Identity(アイデンティティ提督。旧名は Captain Identity :-))Vittorio が数多くの素晴らしいブログを書いていますので、さらにご興味があればぜひ。
最後に、三つ目の「オンプレミスとのハイブリッドを構築したい」という要望。
このような要望に対しては、Service Bus の機能を利用いただくことが可能です。
Windows Azure の Service Bus は、簡単に言うと Windows Azure 上に情報伝達のためのパイプを作成する機能です。
このパイプには HTTP/HTTPS 接続の口が用意されており、HTTP/HTTPS が使用できる環境であれば、ファイヤーウォール等に特別な設定変更を行うことなしに、このパイプに接続可能です。
例えば、オンプレミス上にあるサービスを提供している既存システムがあるとします。そのサービスはオンプレミスの環境でのみ提供していて、外部インターネットからはファイヤーウォール等の制約で直接接続できないようなサービスだとしましょう。
このような状況にあるとき、オンプレミス上でそのサービスと、Windows Azure の Service Bus つなぐための仲介役のサービスを構築します（仲介役サービスもファイヤーウォールの内部で構築します。またこの中継サービスを動作させるサーバーからは外部インターネットへの接続が可能、つまり、外部 Web ページの参照が可能である環境、とします）。
すると、クラウド上からは、Service Bus を経由し、既存システムに接続できるようになります。
さて、この Service Bus ですが接続のタイプとして、次の２つのタイプを用意しています。
- サービスの公開と中継を手伝う
- メッセージの伝達を手伝う
前者の「サービスの公開と中継を手伝う」パターンでは、公開したいサービスに対して Service Bus 上で “Service Path” と呼ばれる公開のためのパスを作成し、そのサービスを利用したいアプリケーションは、その Service Path を利用してコネクションを開き、サービスを利用するイメージになります。動作的には同期呼び出しのような形です（クライアントが リクエストを投げると、それに対する返信が返ってくる）。
一方で、後者の「メッセージの伝達を手伝う」パターンでは、あらかじめメッセージ伝達を行うためのパイプに名前を付けておき、メッセージの送り手はそのパイプに対してメッセージを送り、また、受け取る側はそのパイプに対してメッセージが届いていないか確認をしに行き、メッセージがあれば受け取る、といったようなイメージになります。動作的には非同期呼び出しのような形での利用になります。
また、このパターンの具体的な利用法としては、”Queue” と “Topic” という２つの方法があります。
Queue はその名の通り、いわゆるキューで、イメージしていただきやすいかと思います。
Topic は Queue の発展形で、Queue の情報をさら細かく制御できるようにしたものです（Queue の情報に対して、興味ある情報のフィルタリングを行い、必要な情報のみを取得できるようにしたイメージ）。
Queue と Topic については、以下のクラウドカバーもご参照ください。
Windows Azure においては、PaaS としての基本機能といえる障害回復やスケールの仕組み以外にも、このような様々な機能の提供によって、開発者の皆様がアプリケーションの本質機能にその労力を注ぐことができるようにデザインされた “PaaS” なクラウド プラットフォームなのです。
それでは、Enjoy Azure!