デベロッパー

デベロッパー

Microsoft Azure デベロッパーガイド

Brian Prince
2010年7月16日 / 10:00
 
 

はじめに

ルネサンス時代のバージョン2.0へようこそ。今日の開発者には数多くの新しい可能性が開けている。ここ数年の間に出てきたばかりの幅広い技術やプラットフォームが前代未聞の革新や創造性であふれる環境を作り出した。われわれは今、数年前には夢にも思わなかったアプリケーションを構築することができる。われわれは2番目のルネサンス時代の誕生を目の当たりにしているのだ。それは、90年代後半のドットコムブームを練習走行であったかのように思わせることだろう。

今回のルネサンスは、サービス指向アーキテクチャへと向かう動きや、クラウドコンピューティングの登場も要因となっている。われわれは、非常に洗練された機能を使い、インフラ全体を手作業で書くことも、すべて自腹を切ることもなく、突然、アプリケーションを作成できるようになったのだ。Skype はかなり人気の高いアプリケーションで、ユーザーがインターネット経由で電話をかけられるようにする。ここで Skype の開発方法を考えてみよう。ファイアウォールを越えて通話する方法も、データを適切に暗号化する方法も考え出す必要はない。ユーザー信用証明インフラ全体を構築する必要もない。1つの壮大なアイデアから着手し、自分のアイデアにとって重要なコードだけを書く。ファイアウォールを飛び越えたり、ユーザー名とパスワードを管理する新しい方法になるのが Skype ではない。インターネット上で簡単にコミュニケーションを取るためのものなのだ。自分にとって戦略的でないインフラ全体は他人に任せるのだ。こうすれば膨大な力と生産性が自由になる。それが今回の新しいルネサンス時代へとつながるのだ。

クラウド OS である Microsoft Azure、

単純に言えば、Windows Azure は Microsoft のクラウド用 OS であり、彼らの「Azure Services Platform」の基盤だ。「クラウド」は、最近かなり人気の高い専門用語であり、人によってさまざまな意味を持っている。

あなたにとって「クラウド」とは何? 

一般に、「クラウド」という用語はインターネット上の消費者に価値のあるサービスを配信するものを指す。これらのサービスは、一般的にインフラやプラットフォーム指向の特性を持っている。これらのサービスの多くは、あなたが今開発しているアプリケーションで何らかの役割を担っている。たとえば、写真アルバムアプリケーションを開発しているとき、すべての画像を保管する大規模ファイルストレージファームを構築するための資金や専門知識がないかもしれない。多数のハードディスク、SAN アレイ、バックアップシステムを購入したり、有能な人材を雇ってそのインフラを運営しなければならない。だが、これらすべての作業を行う代わりにストレージプロバイダーからクラウド内のストレージを購入するだけでもいい。それでアプリケーションは写真を保管することができ、細かい作業で手が離せなくなったり、必須のインフラを購入するのに手元の現金に制限されることもなくなる。

その後アプリケーションの人気が高まったら、クラウドの業者と連絡を取ってディスクスペースを増やせば良いだけだ。「インターネットスケール」という言葉は、クラウドサービスと関連して非常に多く使われる。この言葉は、あなたの依存しているサービスが大きくスケーリングし、数百万人まで行かなくとも数千人のユーザーをホスティングできるようになることを意味する。独自アプリケーションを構築中の場合、自分の依存するサービスが自分の必要とするところまでスケーリングできることが重要なのだ。

アプリケーション全体がクラウドのなかで動作すべきだ、と説得したがるクラウドプラットフォームベンダーは多い。これは可能なことであり、多くの場合はかなり現実的なアプローチだ。だが残念ながら、それでは全員のニーズを満たすことができない。ユーザーに提供したい価値や経験を提供するためには、クラウド内のサービスをいくつか活用するローカルソフトウェアの柔軟性も必要になるかもしれない。

従来のホスティング業者にアプリケーションをホスティングしてもらう場合、開発者はサーバの仕様をすべて定義することができる。自分の好きなようにコンフィギュレーションし、特定のパッチやコンフィギュレーションを導入することができる。クラウドサービスを使っている場合は、これらの詳細(および作業)はあなたが抽象化される。あなたの写真アルバムでクラウド内のストレージを使っている場合、あなたには彼らが使っているハードディスクのブランドも、バックアップの方法も、地理的な冗長性やスケーリングの実現方法も分からない。金曜の夜にケーブルテレビ番組の信号があなたの家にどのようにやってくるのか気にしないのと同じように、これらの詳細は気にすべきではないのだ。サービスプロバイダーがあなたを詳細から抽象化してくれるのだ。

クラウド OS とは? 

あなたは目の前で毎日 OS を使っている。パーソナルコンピュータが初めて家庭に進出してきた100万年前(インターネット暦)、開発者は PC のすべての部品に注意を払う必要があった。彼らは、さまざまな CPU、さまざまなサウンドカード、そしてドライブ性能を考慮に入れる必要があった。独自のプリント方法やユーザーデータ保存方法を提供する必要もあった。

OS はここ数年間で、開発者が書きたいものに集中して基盤のインフラは無視できるよう、これらの詳細から開発者(そしてユーザー)を抽象化する進化を遂げた。今日、ユーザーが持っているサウンドカードやプリンタはたいていは気にしないだろう。それには OS が対応してくれる。

OS は、われわれの代わりに多くの詳細に対応してくれる。リソースの共有プールを管理し、これらのリソースをその上で動作している各種アプリケーション全体に割り当てる。また、これらのリソースに対する承認やアクセスコントロールも管理する。

アプリケーションをクラウドに移動していくと、これと同じような問題に直面するようになる。抽象化レイヤを提供するのが Azure の仕事だ。それも、1台の PC だけでなく、さまざまな場所にある数十万台以上のサーバ上においてだ。Azure はこれをすべて抽象化し、それをシームレスな「ファブリック(基本構造)」に見せる。Azure にアプリケーションを導入すると、それがどのサーバ、どのノード、あるいはどのデータセンターで動作しているか全く分からない。あるコンフィギュレーションモデルに応じて自分のアプリケーションを導入するだけだ。細かい部分は Azure がすべて管理する。アプリケーションに合わせて仮想 LAN をコンフィギュレーションし、利用可能な CPU からコアを割り当て、軽量の仮想サーバを導入してアプリケーションを運用させ、DNS やネットワークロードバランサを自動的にコンフィギュレーションして作業負荷を分散させ、これらすべてを監視システムに接続して、すべてが必ずスムーズに動作するようにする。必要なのは「スタート」ボタンを押すことだけだ。

Microsoft が Azure Services Platform の構築に着手したとき、彼らは開発者が直面するかもしれないすべての可能性を考慮する必要があった。Azure には以下のような特性が必要だった。
  • 開発を容易にする。
  • オープンな標準とプロトコルをサポートする。
  • 開発者が既存の開発者用ツールを使えるようにする。
  • 「インターネットスケール」を実現する。
  • シンプルなシナリオに対応できるよう簡略化する。
  • モダンシステムの複雑性に対応できるよう洗練させる。
  • クラウドへの移行に伴う衝突を軽減する。


Microsoft Azure Services Platform を理解する

Azure Services Platform は Microsoft が提供するクラウドサービスをすべて包含する。同プラットフォームは Azure を基盤とし、そこから一連の基盤サービスを積み上げていく。


図1 Microsoft Azure OS とそれがサポートする基盤サービス

図1は Azure Services Platform を示している。クラウド用 OS の Azure は、この図の最下部に来る。そして、前述の OS の抽象化レイヤの上に来るものすべてに対して基盤を提供する。Azure は、あなたが自分独自のアプリケーションを書いて、それをクラウドに導入できるように構築されている。あなたが必要とする機能をすべて提供してくれる。Microsoft は、同社独自のサービスやアプリケーションが対応するように設計するほど、その上でユーザーが自分のアプリケーションを実行できると確信している。

メモ:Azure の開発コード名は「Red Dog」だった。Azure が CTP として公の場で初めてリリースされた PDC2008の期間中、一部のチームメンバーは、このコード名が鮮やかに書かれた赤いスニーカーを履いていた。

必要とされるレベルや信頼性、そしてスケールを Azure が提供できるようになるために、Microsoft は輸送コンテナで作られたデータセンターの構築に移った。どのコンテナもサーバベンダーがあらかじめ用意した。約2500台のサーバがあらかじめ接続され、必要なものはすべて含まれていた。コンテナがトラックから降ろされると、電源、冷却システム、そしてネットワーク回線への接続が行われた。イリノイ州シカゴのデータセンターには約36万台のサーバがある。アイルランドのダブリンにあるデータセンターは同社の次世代データセンターの一部となっており、コンテナを外の屋根がなく、壁で囲まれた構内に格納している。こうすることで空調や電力需要を節約できる。もちろん、データセンターで草の刈り取りをする管理人を雇う必要も出てくるが、これはデータセンターとしては異例の予算品目だ。

Microsoft Azure のコンポーネント

コードが導入され、Azure 上で実行されたら、それはロールの中に入る。現在は、2つのロールが利用可能で、開発も進んでいる。ロールはコードの実行を統括し、参照する可能性のある Azure API のインプリメンテーションを行う。

現在利用可能な2つのロールは、「Web ロール」と「Worker ロール」だ。多くのシステムでは論理フロントエンドとバックエンドの両コンポーネントを持つことになるため、これら2つが初期ロールになっている。Azure ファブリックでプロビジョニングが行われるロールのインスタンス数を定義することで、自分のシステムをスケーリングすることができる。シンプルなシステムは単独で動くロール1つで構成することができるが、複雑なシステムには、それぞれが異なるコードを実行して一緒に動作する多くのロールが存在する場合もある。

Azure のファブリックを利用すれば、実行されているロールのインスタンス数をダイナミックに定義できるようになる。こうすることにより、融通の利く計算資源リソースを持てるようになる。システムに対する需要が高まる(営業部隊が大口の新しい顧客を獲得したとか週末が忙しくなるという場合)は、Azure にロールのインスタンスをもっと多く実行させる。こうすることでシステムの可用性が高まる。従来の IT センターがこのような急激な成長に対応するには数か月もの作業や計画が必要になってしまう。Azure なら、そのような対応もその特別に忙しい週末が終了したときのスケールダウンと同じくらい容易になる。ロールのインスタンス数を減らせば、Azure の請求額も減る。高価なハードウェアが散乱したり、十分活用されないといった状況を心配する必要はない。

ロールごとのインスタンスの割り当て変更方法はいくつかある。最初は、ポータル経由でコンフィギュレーションを変更する方法だ。さらに、サービス管理 API を使ってコード経由でインスタンスの数を変更することもできる。この管理コードは、Azure 内からロールの一部として、あるいは Azure の外から管理ツールの一部として実行することができる。

例を見てみよう。入社候補者の身元調査を行う会社を経営していて、規模の小さいクライアントを数社抱えているとする。顧客がウェブサイトにログインし、ある人物の調査依頼フォームに入力し、料金を支払う。その依頼はパッケージ化され、身元調査の未決キューに入れられる。バックエンドプロセスが依頼をピックアップし、自社保有のデータベースや、場合によっては政府や捜査当局などの第三者のシステムに対して一連の外部コールを行う。データを収集したら、プロセッサがレポートを作成し、それを共有ストレージエリアに入れる。ウェブサイトはこのレポートを見て、それをユーザーにリスト表示する。ユーザーはこのレポートを見たりダウンロードして、採用判断に役立てる。図2に示されているようなものと同様のシステムを構築することになる。


図2 - シンプルな Azure アプリケーション

Microsoft Azure のロール

Web ロールは ASP.NET アプリケーションを実行し、管理コードを IIS7内の.NET 3.5 SP1上で実行する設計になっている。このロールは、Azure ベースシステムにフロントエンド機能を提供することが想定されているが、フロントエンドタイプの作業に限定されているわけではない。Web ロールは HTTP や HTTPS とコミュニケーションを取り、ASP.NET のサブセットや WCF 機能をサポートするようになっている。

Worker ロールも多くの点で似ている。このロールは、サービスのバックエンドプロセッサになることを目指しているため、IIS を Web ロールのようには実行していない。Worker ロールは、ほかのサービスや、自社のほかのエンタープライズシステムなど、必要に応じて外部との接続を確立することができる。Worker ロールは WCF サービスをホスティングすることができ、これらをインターネットで利用可能にしたり、Azure 内のアプリケーションに限定することができる。

あなたのサービスが利用するロールと、それがどのようにプロビジョニングされるかは、Service Definition によってコントロールされる。これはコンフィギュレーションファイルに近く、持っているロールやロールごとに実行すべきインスタンス数など、サービスに関する各種メタデータを Azure に伝える。

大体の場合、既存の ASP.NET アプリケーションは簡単に移植できるはずだ。.NET フレームワークの中には一部 Azure 環境で動かないパーツもある。たとえば、ディスクに直接書き込むようなアプリケーションは修正が必要になる。Azure がファイルシステムを抽象化する(どのサーバのどのディスクにアクセスするのかとか、コードがファブリック内のサーバで動作しているのはいつなのか、といったことはどのように知るのだろうか?)ため、Azure SDK が代替案を提供する。

この例では、Azure のストレージを活用するようにアプリケーションを変更することができる。Azure には BLOB、テーブル、そしてキューがある。また、隔離されたストレージに書き換え可能な小さいスペースを作成することもできる。制限の大半はセキュリティの制限から用意されたものだ。

ストレージファブリックへのデータの格納

先に述べたように、Windows Azure のストレージシステムには現在3つの部品がある。BLOB、テーブル、そしてキューだ。これらは、大半のシステムが必要とするストレージの基本パーツだ。ストレージシステム内に格納されたデータはすべて、3つのレプリカに格納される。これは、適切なレベルの信頼性とスケーラビリティを保証するためだ。

最初のストレージメカニズムが BLOB だ。BLOB はバイナリ・ラージオブジェクトの意味で、写真のような大きなオブジェクトのデータベースへの格納に使われているため、多くの開発者がこれに詳しい。データベースで BLOB を扱うのは難しい場合もあるが、Azure の BLOB 用 API は使いやすい。BLOB にはそれぞれに名前が与えられており、ファブリックに格納されていて、実行中のすべてのインスタンスで利用可能だ。

Azure のストレージシステムは「テーブル」と呼ばれる機能も提供する。これらを従来のデータベーステーブルと混同してはならない。1つのテーブルは最大100T バイトのデータを持つことができる。テーブルはそれぞれがエンティティを持ち、エンティティはそれぞれに専用のスキーマを持つことができる。各エンティティは「Partition Key」と「Row ID」の2つのプロパティを持つ必要がある。

Partition Key は、データをスケールの単位として使用するパーティションに分割するために使用される。パーティションが(多数のクエリを受け取って)忙しくなったら、ほかのストレージサーバに移動してレスポンスを改善することができる。そして、落ち着いたら再び集約することができる。Row ID と Partition Key の両プロパティは、テーブルの複合プライマリキーのようなものとして連動する。

エンティティは、同じテーブル内でもそれぞれ異なるプロパティを持つことができる。これは、データの処理に高い柔軟性を提供する。Azure テーブルは極めて高速に使用できるようになっており、REST や Azure SDK のストレージクライアントを使ってアクセスすることができる。

Azure のストレージの最後のパーツがキューだ。キューは各種システム間の疎結合コミュニケーションを支援するために使われることが多い。このようにシステムを設計すると、フロントエンドがバックエンドから分断されてしまう。だが、この構造ではバックエンドがキューへの配置方法を気にせず、機能するものだけ処理したら次の作業項目へと移動する。

キューは、あるシステムから別のシステムへメッセージを格納できるようにするシンプルなデータ構造だ。これらのメッセージは具体的には FIFO (先入れ先出し)で格納される。たとえると、これらのメッセージは受信箱に入っている電子メールのようなものだが、受信した順番でしか読むことができない。各キューはメッセージを何通でも持つことができるが、1つのメッセージのサイズは8K バイトに制限されている。BLOB には作業を行うデータの本体を格納し、このキューを経由して Worker ロールに作業チケットを送信するのが一般的なアプローチ(前述のシナリオなど)だ。

キューは、システムに対して行われたすべてのリクエストを一緒に処理するため、Worker ロールの複数のインスタンスに対してかなり簡単なメカニズムを提供する。各 Worker ロールが次のリクエストを処理できるため、次のメッセージはキューの中から取り出す。すると、Azure のキューはそのメッセージを削除せず不可視に設定する。Worker ロールがそのメッセージの処理を終えると、それが処理の成功をキューに伝え、キューがそのメッセージを削除する。メッセージを不可視にすることで、同じメッセージがロールの異なるインスタンスに何度も処理されることを回避できる。これにより、システムはメッセージを処理するコードがクラッシュしたときにメッセージをリカバリすることができる。このようにすればキューがメッセージを紛失することはなくなる。

Azure のストレージとのやりとりは REST 経由となっていて、Azure 内で動作するコードは使わないことが重要なので指摘しておきたい。また、社内にリクエストを受け取るアプリケーションを置いておくこともできる。このアプリケーションがリクエストを Azure のキューに入れて、Azure ベースの Worker ロールがメッセージをピックアップし、リクエストを処理する。

図1の1つ上のレベルには、Azure Services Platform の基盤サービスが含まれている。これらが基盤サービスと呼ばれるのは、エンドユーザーが直接使用することを想定していないためだ。これらは Azure などのクラウド内で動作するアプリケーションや、ほかの場所で動作していて、その価値を利用したいだけのアプリケーションによる使用を意図している。

これらのサービスは、必要に応じて断片的な使い方をすることもできる。インターネット上にあるクライアントに接続するためのサービスバスなど、これらを少しだけ利用する買い取り型アプリケーションを用意することもできる。

SQL Azure はアプリケーションのクラウドへの移行を容易にし、クラウド内に SQL 互換の RDB プラットフォームを提供する。SQL Server との互換性は非常に高い。SQL Server に対応する多くのツールは SQL Azure にも対応する。データベースの移行を進める場合は、SQL Azure Migration ウィザード(http://sqlazuremw.codeplex.com/の CodePlex にある)をチェックすると良いだろう。このツールはクラウドへのスキーマやデータの移行を支援する。

Windows Azure プラットフォームの AppFabric は、REST サービスを利用するための2つのサービスを提供する。最初のものは「ACS」で、これは Microsoft、Google、および Yahoo!が共同開発したオープンプロトコルコールの OAuth がベースになっている。ACS はクレームベースの承認により、REST ベースサービスのセキュリティ確保を非常に楽にする。

2つ目の AppFabric サービスが「Service Bus」で、これはホスティングされる場所に関係なく、あらゆるクライアントとあらゆるサービスの接続を容易にする。自分のクラウドベースもしくは買い取りベースのサービスをバスに登録すれば、クライアントがクラウド内のバス経由でそれに接続できるようになる。これで、クラウド経由でメッセージを中継して NAT、プロキシ、ファイアウォールといったネットワークの各種障壁を越えてコミュニケーションを取ることが簡単になる。

クラウドのまとめ

結局、アプリケーションはすべてがクラウドの中にある必要はない。アプリケーションはハイブリッドな特性へと進化し、買い取りベースとクラウドベースとの良いところを組み合わせてユーザーや企業にさらに高い価値を提供していく。ハイブリッド型のアプローチを取れば、既存のアプリケーションで理にかなうクラウド機能を簡単に導入することができる。プラットフォームが携帯電話からデスクトップ、サーバ、そしてクラウドにまで対応する Windows Azure はこれを簡単にしてくれるのだ。既存のスキルとツールを使ってクラウドを利用するアプリケーションを書き始めるのは簡単だ。恐れずに、今日からログインし、試しにアプリケーションを導入していただきたい。
【関連記事】
米 Microsoft の Azure クラウド、Dell、eBay、富士通、HP が早期採用
富士通と米 MS、富士通ブランドの Azure クラウドで世界戦略を強化
クラウド コンピューティングは長期的視点で:MS 幹部
Microsoft と HP、2億5000万ドル規模の提携を発表
Microsoft、『Windows Azure』部門をサーバー事業関連部門に統合

New Topics

Special Ad

ウマいもの情報てんこ盛り「えん食べ」
ウマいもの情報てんこ盛り「えん食べ」 「えん食べ」は、エンジョイして食べる、エンターテイメントとして食べものを楽しむための、ニュース、コラム、レシピ、動画などを提供します。 てんこ盛りをエンジョイするのは こちらから

Hot Topics

IT Job

Interviews / Specials

Popular

Access Ranking

Partner Sites