Windows Azureプラットフォーム　現場からの報告

Cover art by Andrew Fryer

（翻訳バージョン 0.8 : 2010/07/22 dragan10 at gmail.com）

Windows Azure プラットフォーム：現場からの報告

Volume 1

編集者兼コピペ常習者：Eric Nelson と、Eric よりも賢い 15 人の著者

2010/6/22（v 0.9）

開発者達は、Windows Azure プラットフォームがクラウドコンピューティングに開いた可能性を探究

してきました。本書は、Windows Azure プラットフォームに積極的に取り組んできた大勢の開発者に

よる、誰もが成功できるようという願いのこもった素晴らしい記事をまとめたものです。この第一巻

には 20 の記事があり、Windows Azure プラットフォームの始め方から、エラスティックなアプリケ

ーションへのベストプラクティスの実装までを取り上げています。


2

目次

始めに 6

編集者から 6

将来版の作者になりたくありませんか？ 6

Windows Azure プラットフォームの紹介 8

AE - 省略語の説明 9

第 1 章始めてみよう 10

Windows Azure を始めるための 5 つのステップ 10

ステップ 1 : Azure のアカウントの作成 10

ステップ 2 : SQL Azure データベースのプロビジョニング 10

ステップ 3 : Azure 用の Web アプリケーションの構築 11

ステップ 4 : Windows Azure 用の Web アプリケーションのパッケージング 12

ステップ 5 : Azure への Web アプリケーションのデプロイ 12

Windows Azure プラットフォームでの作業に最適なツール群 16

分類：いつもの連中 16

分類 : Windows Azure ストレージ 16

Category: Windows Azure の診断 20

Category: SQL Azure 21

Category: 開発全般 22

第 2 章 WINDOWS AZURE プラットフォーム 24

Azure を対象とするアーキテクチャ - 高度にスケーラブルなアプリケーションの構築 24

Azure アーキテクチャの原則 24

データのパーティショニング 24

コロケーション 25

キャッシュ 25

ステート 26

効率の良い負荷の配分 26

リソースの最大化 27

まとめ 27

Windows Azure プラットフォームと、コスト指向アーキテクチャ 29

コストは重要です 29

考慮すべきコスト 29

結論 30

初めての Windows Azure プロジェクトにおけるリスクの回避 31

一般的なリスク 31


3

リスク低減のための非技術的戦略 32

リスク低減のための技術戦術 33

開発者の責任 35

複数人で Azure に取り組む際の挑戦と困難 36

開発環境 36

テスト環境 36

証明書 37

うまくいかない時 37

まとめ 37

継続的インテグレーションビルドを利用した、最新ビルドの自動化の実現 38

正しい “bits”の入手 38

デプロイメントのためのパッケージング 38

デプロイ 39

Windows Azure プラットフォームでの Java の利用 42

Windows Azure ストレージへの Java からのアクセス 42

Windows Azure での Java のコードの実行 43

AzureRunme 44

第 3 章: WINDOWS AZURE 46

Windows Azure のコンピュートインスタンスの自動スケーリング 46

始めに 46

基本的なアプローチ 46

Scale Agent 47

モニタリング：診断情報の取得 47

ルール：いつスケールするのかの決定 49

信頼：スケールのための承認 50

スケーリング－サービス管理 API 52

まとめ 52

Windows Azure でのコンテンツベースのルータサービスの構築 53

Azure blob ストレージを利用する Bing Maps Tile サーバー 58

Azure ドライブ 60

ゲスト OS 60

VHD 60

CloudDrive 61

開発環境 63

NOSQL データベースとしての Azure テーブルサービス 64

マスター－詳細構造 64


4

動的スキーマ 64

データとしてのカラム名 65

データとしてのテーブル名 65

まとめ 66

クエリと Azure テーブル 67

CreateQuery<T>() 67

様々な Context 68

パーティションキーや行キーに対するクエリ 68

継続 69

DataServiceQuery 69

CloudTableQuery 70

テーブルストレージの時刻及び日付フィールドの保存の小技 73

Worker ロールを使った分散キャッシュの実装 77

キャッシュの設定 77

分散キャッシュの利用 78

Windows Azure アプリケーションのロギング、診断、健全性のモニタリング 81

診断データの収集 81

診断データの保存 82

診断データの解析 82

詳細な情報 83

Windows Azure のサービスランタイム 84

ロールとインスタンス 84

エンドポイント 84

サービスのアップグレード 84

サービス定義とサービス設定 85

RoleEntryPoint 86

ROLE 86

RoleEnvironment 86

RoleInstance 87

RoleInstanceEndpoint 88

LocalResource 88

第 4 章: SQL AZURE 89

5 分でつなぐ SQL Azure 89

前提条件–SQL Azure アカウントの取得 89

SQL Azure ポータルの利用 89

Server Administration でのデータベースの生成 90

ファイアウォールの設定 90

SQL Server Management Studio を使っての接続 91


5

アプリケーションのクレデンシャル 93

覚えておきましょう– ターゲットのデータベース 94

第 5 章: WINDOWS AZURE プラットフォーム APPFABRIC 95

デスクトップから Azure Roles をリアルタイムでトレースする 95

カスタムの TraceListener 95

メッセージ送信コンソールアプリケーション 96

トレースサービス 97

サービスホストクラス 97

サービス 98

まとめ 99

著者の紹介 100

Eric Nelson 100

Marcus Tillett 100

Richard Prodger 101

Saksham Gautam 101

Steve Towler 102

Rob Blackwell 102

Juliën Hanssens 102

Simon Munro 103

Sarang Kulkarni 103

Steven Nagy 103

Grace Mollison 104

Jason Nappi 104

Josh Tucholski 105

David Gristwood 105

Neil Mackenzie 106

Mark Rendle 106


6

始めに

編集者から

みなさんこんにちは。

Windows Azure プラットフォームは、アーキテクトである私たちが、

ソリューションを実装し、デプロイし、管理する方法を変革していま

す。2010 年の初期に、Windows Azure プラットフォームは live にな

り、その後わずかに 6 ヶ月がたった時点で、提供されたサービスの

利点を活かす、驚くほど多様なソリューションがすでに開発されてい

ました。

本書は、Windows Azure プラットフォームに積極的に取り組んできた

大勢の開発者による、誰もが成功できるようという願いのこもった素

晴らしい記事をまとめたものです。この第一巻には 20 の記事があ

り、Windows Azure プラットフォームの始め方から、エラスティック

なアプリケーションへのベストプラクティスの実装までを取り上げて

います。特に始めから終わりに向かって読んでいく必要はありませ

ん。むしろ、読者の皆さんにもっとも関係のある、あるいはもっとも

おもしろそうな章や記事にまっすぐ進んでいってもらえればと思いま

す。

本書は、2010 年の 5 月から 6 月始めにかけてまとめられたので、

Windows Azure SDK のリリース 1.2 はまだ出ていませんでした。1.2 は

いくつかの素晴らしい新機能が追加されてリリースされました。中で

も、デバッグや IDE 統合に関して、Visual Studio 2010 と.NET

Framerowk 4.0 に関する新機能が追加されています。本書の第二巻で

は、これらの新機能（それ以外にも！）を取り上げることになるでし

ょう。

記事を読んだなら、是非フィードバックを

http://bit.ly/azureebook1feedback にください（1 分もかからないはず

です）。本書を読んでくださってありがとうございます。お楽しみく

ださい。

Eric Nelson

Developer Evangelist, Microsoft UK

Website: http://www.ericnelson.co.uk

Email: [email protected]

Blog: http://geekswithblogs.net/iupdateable

Twitter: http://twitter.com/ericnel

将来版の作者になりたくありませんか？

開発者は、ベストプラクティス、知識と経験－それも自分自身の－を共有することに価値を置くもの

です。もしも Windows Azure プラットフォームについて、自分なりの見識があるならば、Windows

http://www.ericnelson.co.uk/

mailto:[email protected]

http://geekswithblogs.net/iupdateable

http://twitter.com/ericnel


7

Azure プラットフォームが進化し、広まり続ける中で、あなたは本書の次巻に著者として参加するの

に十分な資格があります。

提案したい記事（複数でもかまいません）と、できれば「記事のサンプル」としてあなたのブログへ

のリンクなどを付けて、私（[email protected]）にメールしてください。


8

WINDOWS AZURE プラットフォームの紹介

Windows Azure プラットフォームには、「クラウドの中で」動作するソリューションを構築するため

に、個別にも組み合わせても使うことができる、3 つの技術が含まれています。まず最初には、

Microsoft のデータセンターでコードを実行し、データを保存してもらい、ソリューションが快適に

動作し続け、変化するビジネスの要求に応えることができるようにする責任の一部を、Microsoft に

負担してもらうことができます。ソリューションは、完全に Windows Azure プラットフォーム上で動

作させることもできますし、ソリューションの一部をオンプレミスで、あるいはインターネットの他

のどこかで動作させる、ハイブリッドとして動作させることもできます。これらの 3 つの技術とは、

Windows Azure、SQL Azure、Windows Azure AppFabric です。

Windows Azure

Windows Azure は、Windows Azure プラットフォームのためのクラウドサービスオペレーティ

ングシステムです。Windows Azure を使えば、開発者はオンデマンドのコンピュートとスト

レージを利用して、コードの実行とデータの保存を行えます。

Windows Azure は、Visual Studio 2008 及び Visual Studio 2008 との統合によって、一貫性のある

開発者の体験をサポートします。Windows Azure は、Microsoft および非 Microsoft の言語及び

技術をサポートするオープンなプラットフォームです。Windows Azure は、Eclipse、Ruby、

PHP、Python といった、サードパーティのツールや技術を受け入れます。

SQL Azure

Microsoft の SQL Azure は、Windows Azure のアプリケーションや、Windows Azure プラットフ

ォーム外で動作するアプリケーションに、Microsoft SQL Server の機能を提供します。SQL

Azure は、構造化されたデータや、半構造化されたデータ、あるいは全く構造化されていな

いデータを、複数の複製を保存することによる高可用性という利点を活かしながら、保存し

たり取得したりすることができます。SQL Azure では、リレーショナルなクエリや、検索、モ

バイルユーザーやリモートオフィス、あるいはビジネスパートナーとの同期が可能です。

Windows Azure Platform AppFabric

AppFabric は、開発者がクラウド、オンプレミス、ホストされたデプロイメントとをつなぐの

を支援する、セキュアな接続をサービスとして提供します。AppFabric はサービスバスとアク

セスコントロールから構成されます。単純なイベントを扱うシナリオから、複雑なプロトコ

ルトンネリングまで、AppFabric サービスバスは、アプリケーションが通信する方法や、ファ

イアウォール、NAT、動的 IP、様々な認証システムがもたらす問題への対応を、開発者が柔

軟に選択できるようにします。AppFabric アクセスコントロールは、様々な認証プロバイダー

間で連携する RESTful な Web サービスのための、シンプルでセキュアな認証を可能にします。

Windows Azure プラットフォームをできるだけ早く使えるようになるための、たくさんの記事、ビデ

オ、スクリーンキャストが提供されており、まず始めにアクセスのに最適な場所として、

http://bit.ly/startazure があります。本書にも、始めてみようという章があります。


9

AE - 省略語の説明

Windows Azure プラットフォームを使うのが初めてなら、本書で使われている短縮形や、業界用語に

関して尐々説明がいるかも知れません。

REST 及び RESTful - Representational State Transfer。クライアントとサービスがやり取るできる

ようにするための、ソフトウェアアーキテクチャーのスタイル。

WCF – Windows Communication Foundation。.NET Framework 3.0 とと主にリリースされた技術

で、異なる「場所」で実行されているコード同士が通信できるようにします。

Cloud Computing –コードの実行とデータの保存をオフプレミスで行うこと（この他の 100 種

類以上のクラウドコンピューティングの定義も参照すること例：

http://en.wikipedia.org/wiki/Cloud_computing）

Elastic Computing –エラスティックコンピューティング - より多くの処理能力や、より多くの

データを保存しなければならなくなった場合に、エラスティックコンピューティング（本書

の場合は Windows Azure プラットフォーム）は、それらの要求に対して素早く対応し、追加

のコンピュート及びストレージリソースをプロビジョニングします。

PaaS – Platform as a Service はクラウドコンピューティングに対するアプローチの１つで、柔

軟性よりは抽象化やシンプルさに重点が置かれています。例：Windows Azure プラットフォ

ーム。

IaaS – Infrastructure as a Service はクラウドコンピューティングに対するアプローチの１つで、

抽象化やシンプルさよりは柔軟性に重点が置かれています。例：Amazon Web Services。

コードネーム“Dallas” – Windows Azure プラットフォームの第 4 のメンバーで、現在のところ

CTP。http://www.microsoft.com/WindowsAzure/dallas/

CTP – Community Technology Preview。簡単に言えば－従来のベータほどしっかりしてはいな

いということ

http://en.wikipedia.org/wiki/Cloud_computing

http://www.microsoft.com/WindowsAzure/dallas/


10

第 1 章始めてみよう

WINDOWS AZURE を始めるための 5 つのステップ

By Jason Nappi

新しい技術に取り組み始めるのは勇気がいることですが、一般的にはいったん慣れ始めてしまえば、

学習の速度は上がっていくものです。そこで、筆者は自分自身が最近体験したいくつかの基本的なス

テップを紹介することに焦点を当て、基本的な疑問のいくつかに回答し、学習を早めるに当たっての

障害を取り除ければと思います。以下の内容は、筆者が典型的と考えるビジネスアプリケーションの

設計に関する考慮と、そういった種類のアプリケションを Azure のクラウド内で構築するという考え

に基づいています。

ステップ 1 : AZURE のアカウントの作成

最初のステップは、予想できるとおり、Azure のアカウントのセットアップです。Windows Azure は

クラウドサービスなので、アカウントはクラウド内で作成しなければならず、クラウド環境を用意し

なければなりません。Azure のアカウントは、Windows Azure Developer portal で作成できます。この

登録のプロセスは非常に単純明快で、もしまだ持っていなければ Windows Live ID を作成する必要が

あり、クレジットカードも必要です。

登録プロセスが終われば、Windoows Azure、SQL Azure、AppFabric にアクセス d けいる用になってい

るはずです。この時点ではまだクラウドのサービスは全く作成されていません。作成したのはアカウ

ントだけで、作成するサービスはこのアカウントの下でプロビジョニングされ、デプロイされること

になります。

ステップ 2 : SQL AZURE データベースのプロビジョニング

場合によってはこのステップは不要ですが、筆者がこれまで構築したアプリケーションのほとんどは、

データベースによって駆動されるものでした。そのため、新しいアプリケーションを生成するにして

も、既存のアプリケーションをクラウドに移行するにしても、どこでデータベースが動作し、どうや

ってそれに接続すればいいのかということは、非常に良くある質問になると思います。理にかなった

回答は、アプリケーションがクラウドでホストされるなら、データベスもクラウド上になければなら

ない、というものです。

Windows Azure プラットフォームは、データを保存する方法として、Windows Azure ストレージと共

に SQL Azure が用意されています。SQL Azure は、一般的なビジネスアプリケーションで使われれるリ

レーショナルデータベースにもっとも似ているので、Azure ストレージにはスケーラビリティやコス

トの面でアドバンテージがあるかも知れませんが、SQL Azure では、より慣れ親しんだパラダイムが

提供されています。当然のこととして、筆者は Windows Azure プラットフォームを始めるに当たって、

SQL Azure に注目します。

クラウドデータベースを生成するには、ステップ 1 でセットアップした Azure のアカウントに戻り、

https://sql.azure.com にあるポータルの SQL Azure セクションに進みます。SQL Azure サーバーを生成す

るには、ユーザー名とパスワードを提供してやります。これで、SQL Azure Developer ポータルは、

https://windows.azure.com/


11

crkvq7vdhu.database.windows.net というようなユニークな名前を生成し、それを使ってサーバーを生

成します。

SQL Azure サーバーが生成できたら、データベースを生成します。アクセスを許可するには、ファイ

アウォールの規則も設定しなければなりません。ここでもやはり話を単純にしたければ、ローカルマ

シンの IP アドレスから SQL Azure サーバーへのアクセスを許可しておけばよいでしょう。

最後に、筆者も迷ったように、生成した SQL Azure にいつもの SQL Server Management Studio からアク

セスできるかが心配でしょう。筆者の場合、SQL Server Management Studio 2008 R2 をダウンロードし

たら、問題なく接続することができました。

ステップ 3 : AZURE 用の WEB アプリケーションの構築

http://www.microsoft.com/sqlserver/2008/en/us/R2Downloads.aspx


12

クラウドデータベースの準備が整い、いつもの SQL Server Management Studio で接続できることが確

認でき、アプリケーションに必要なテーブルを作成できました。これで、アプリケーションを構築す

る準備ができたことになります。アプリケーションを構築するには、Windows Azure SDK と、

Windows Azure Tools for Microsoft Visual Studio 1.1 をインストールしなければなりません。嬉しいこと

に、どちらも Visual Studio 2008 と Visual Studio 2010 の両方をサポートしています。

Visual Studio を起動すると、「Windows Azure Cloud Service」用の新しいプロジェクトテンプレートが

あることに気づいたでしょう。このクラウドサービスのテンプレートを選択すると、クラウドサービ

スの「ロール」を、Web、Worker、WCF Service Role の中から選択するように求められます。

「ASP.NET Web Role」を選択した場合、クラウドサービスのプロジェクトと、いつもの ASP.NET Web

プロジェクトを含むソリューションが生成されます。通常の ASP.NET Web プロジェクトと、ASP.NET

Web Role プロジェクトとの本当の違いは、WebRole.cs というファイルの有無だけです。WebRole.cs

は、Azure のエントリーポイントとして働きます。

F5 を入力すると、Azure のアプリケーションが起動し、開発ファブリック内で実行されます。開発フ

ァブリックは、Windows Azure のクラウド環境をシミュレートし、デスクトップ上で Azure のアプリ

ケーションを実行し、テストし、デバッグできるようにするのです！

ステップ 4 : WINDOWS AZURE 用の WEB アプリケーションのパッケージング

Azure に公開するためにアプリケーションをパッケージングするのは、やってみればとても簡単です。

Visual Studio からは、クラウドサービスのプロジェクトを右クリックし、コンテキストメニューから

Publish を選択するだけ済みます。これで、Web アプリケーションは.cspkg ファイルにパッケージン

グされ、ServiceConfiguration.cscfg ファイルも生成されます。これらの 2 つのファイルが、Windows

Azure にアプリケーションをデプロイするのに必要なもののすべてです。

ステップ 5 : AZURE への WEB アプリケーションのデプロイ

これで ASP.NET Web Role をパッケージできたので、ステップ 1 で生成した Windows Azure のアカウン

トに戻り、Windows Azure のサービスを生成しましょう。Windows Azure タブの下の「new service」→

「Hosted Service」を選択し、新しいクラウドサービスの名前と説明を入力します。

サービスを生成すると、Staging と Produuction という 2 つのホストサービスの場所ができているはず

です。それぞれの下には「Deploy」ボタンがあるでしょう。Staging の下の Deploy を選択してくださ

い。これで、ステップ 4 で作成した 2 つのファイルの場所を聞いてくる画面が開きます。両方のファ

イルを提供し、デプロイしてください。パッケージと設定をデプロイすると、アプリケーションにア

クセスするためのユニークな URL が提供されます。これで、サービスを「Run」する機能も見える

ようになったはずです。

http://www.microsoft.com/downloads/details.aspx?FamilyID=dba6a576-468d-4ef6-877e-b14e3c865d3a&displaylang=en#filelist

http://www.microsoft.com/downloads/details.aspx?FamilyID=5664019e-6860-4c33-9843-4eb40b297ab6&displaylang=en


13


14

アプリケーションは、Run するまでは先ほどの URL からアクセスすることはできないので、Run を押

して、じっと、じっと、じっと待っていてください…Windows Azure のインフラストラクチャがアプ

リケーションのためのプロビジョニングをするには尐し時間がかかりますが、いったん青信号になれ

ば、もうこれで行けるはずです。


15

これらが、Windows Azure になじむために私が行った簡単なステップです。これらのステップを踏む

ことで、Windows Azure での開発は、これまでになれた開発経験とほとんど変わりないことを示すこ

とができました。しかし、Windows Azure のための開発に際して、もっと複雑な検討をしなければな

らないことの 1 つには、SQL Azure が提供するこれまで一般的だったリレーショナルデータベースの

代わりに、Windows Azure ストレージを潜在的に利用することになるかもしれないということがあり

ます。


16

WINDOWS AZURE プラットフォームでの作業に最適なツール群

By Sarang Kulkarni

「プラットフォームは、その周辺にあるツールで知られることになるんです！」とはよく言われるこ

とですが、依然として真実です。Windows Azure は生まれたばかりのクラウドプラットフォームであ

るにもかかわらず、開発を楽しいものにし、開発者の日常を楽なものにしてくれる素晴らしいツール

によって、適切にサポートされています。

いつもの連中から始めて、このあたりにおけるもっとおもしろい連中を紹介しましょう。筆者には、

なくてはならないものがほとんどです。

分類：いつもの連中

Microsoft Visual Studio 2010®

Visual Studio 2010（VS2010）は、Windows Azure 用の安定した開発プラットフォームです。VS2008 に

比べ、Azure 特有の変更はほとんどありませんが、開発体験全体としてみれば、明らかに優れたもの

になっています。Windows Azure の VM は、OS バージョン 1.2 から.NET Framework 4.0 をサポートし

ているので、クラウドで.NET 4.0 の新機能の利点を活かそうとするなら、VS2010 を使うのが合理的で

しょう。いつもの通り、Express edition は無料です。

Microsoft SQL Server Management Studio® 2008 R2

SQL Azure を扱うなら、R2 リリースがお勧めです。もっとも大きな利点は、私たちが共に成長してき

た SQL IDE の安心感です。これの必需品については、多くを語る必要はないでしょう。こちらも

Express edition は無料で、ほとんどの要求を満たせるのでお勧めです。

ダウンロードはこちらからどうぞ。

http://www.microsoft.com/downloads/details.aspx?familyid=56AD557C-03E6-4369-9C1D-

E81B33D8026B&displaylang=en.

ユーザーアカウントとローカルセキュリティポリシーコントロールパネルアプレット

これに関しては、Azure 特有のものは何もないことは分かっています。しかし、ファブリックでの実

行中に、ユーザー権限がらみで驚かされることがないように、ユーザーに対する権限を

http://msdn.microsoft.com/en-us/library/dd573355.aspx のようにレイアウトするのには、これがとても

便利なのです。

分類 : WINDOWS AZURE ストレージ

What: Cerebrata - Cloud Storage Studio

Why: Cerebrata-Cloud Storage Studio（CSS）は、Azure のストレージやホストされたアプリケーション

を管理するための WPF ベースのクライアントです。CSS は、Storage API をうまく利用し、Azure スト

レージへの直感的なビジュアルアクセスを提供するための、小さな会社による賞賛すべき努力として

始まりました。いまや CSS は、Azure ストレージの下にあるすべてのものに加え、ホストされたアプ

http://www.microsoft.com/downloads/details.aspx?familyid=56AD557C-03E6-4369-9C1D-E81B33D8026B&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=56AD557C-03E6-4369-9C1D-E81B33D8026B&displaylang=en

http://msdn.microsoft.com/en-us/library/dd573355.aspx


17

リケーション内の多くのものを管理するための、ワンストップソリューションとしての地位を確立し

ています。

図 1：Coud Storage Studio - Azure のアカウントに接続中

CSS からは、テーブルのスキーマの設計や、既存のテーブルに対する CRUD 操作、テーブルの内容の

ディスクとの間でのダウンロードやアップロード、テーブルの内容のフィルタリングが行えます。

WCF Data Services（ADO.NET Data Services と呼ばれていました）のクエリ構文をサポートする、基本

的なクエリサポートも提供されています。Linq クエリのサポートのアドオンがあるのもありがたいで

す。

blob ストレージは CSS の強いところで、blob とコンテナに対するすべての操作が可能です。コンテナ

の作成、アクセスポリシーの設定、フォルダー構造でいっぱいになったコンテナ内の blob のリスト

表示、ページ／ブロック blob のアップロード／ダウンロード、blob のコピーと移動、blob スナップ

ショットの生成と表示（非常に便利です）、blob に対するサイン済みの URL の生成といった操作が

行えます。MIME type 設定のサポートは、鬼に金棒です。筆者にとって唯一残念なところは、コンテ

ナーの構造を渡り歩いている際のパンくず表示が非常に基本的なものに過ぎないことです。

CSS はまた、シンプルながら非常に効率の良いサービス管理 UI を持っています。このデザインは、実

際の Azure の開発者ポータルのものによく似ています。同じ機能が用意されており、追加の機能もあ

ります。ホストされているサービスへの接続、サービスの表示やデプロイや削除、デプロイメントス

ロットの交換、API 証明書の管理、Affinity グループの管理といった、通常のサービス管理操作が利用

可能です。ここで筆者達が気づいた非常に便利な機能は、サービスデプロイメント生成ダイアログの

下部にある、「生成後にデプロイメントを自動的に実行する（Automatically run the deployment after

creation）」と書かれた、便利で小さなチェックボックスです－これは気が利いています。


18

図 2 : Cloud Storage Studio - サービスのデプロイ

1 ライセンスあたり 60$の価値は十分にあるでしょう。

これ以外にも注目に値するものを紹介しましょう。

Cerebrata 自身の CSS/e https://onlinedemo.cerebrata.com/cerebrata.cloudstorage/default.aspx こ

れは非常に基本的ながら、役に立つストレージサービスの管理機能を提供する、Silverlight の

アプリケーションです。

オープンソースの Azure Storage Explorer http://azurestorageexplorer.codeplex.com/

最後に、完璧にはほど遠いものの、それでも便利なオープンソース版の Azure MMC スナップ

インである http://code.msdn.microsoft.com/windowsazuremmc. Azure MMC はバージョン 2 で、

Cloud Storage Studio と同じようにほとんどの基本機能をカバーしており、注目に値するでし

ょう。

https://onlinedemo.cerebrata.com/cerebrata.cloudstorage/default.aspx

http://azurestorageexplorer.codeplex.com/

http://code.msdn.microsoft.com/windowsazuremmc


19

図 3 : Windows Azure MMC


20

What: LINQPad http://www.linqpad.net/

Why: Joseph Albahari による LINQPad は、Linq 用のクエリのスクラッチパッドとして、最高のものだと

言っても言い過ぎにはならないでしょう。LINQPad は、様々なデータソースの集合に対してクエリを

実行できます。ここでの議論で特に関心を引くのは、SQL Azure や WCF Data Services（コードネーム

"Dallas"のことを考えてみてください）、そして Windows Azure のテーブルストレージでしょう。そう、

テーブルストレージです！LINQPad は、Cloud Storage Studio が対応するのを止めた部分に踏み込んで

いるのです－クエリ機能は素晴らしく、インターフェースはさらに強力です。

図 4 : LINQPad - WADPerformanceCounters テーブルに対するクエリのサンプル

いつもの通り、最高のツールの中にはフリーのものがあり、LINQPad はまさにこれに当てはまります。

オートコンプリートや Visual Studio との統合機能などが追加された、Pro バージョンもあります。

CATEGORY: WINDOWS AZURE の診断

What: Cerebrata – Azure Diagnostics Manager

http://www.cerebrata.com/Products/AzureDiagnosticsManager/Default.aspx

Why: Azure の診断が、今日のようになるまではに尐し時間がかかっています。イベントビューアーの

ような感触のツールや、診断データを扱うための包括的な管理ダッシュボードといったツールがあり

ますが、Azure Diagnostic Manager（執筆時点では公開ベータです）は、まさにこういったことを実現

しようとするものです。

Azure Diagnostics Manager は、以下の機能を含む包括的な機能セットを持っています。

Azure ストレージのアカウントに接続し、診断情報を読み取ってそこからデプロイメントを

検索し、見つかったデプロイメントに接続するか、サブスクリプションに直接接続して、モ

ニターするホストされたサービスのリストを取得できます。

http://www.linqpad.net/

http://www.cerebrata.com/Products/AzureDiagnosticsManager/Default.aspx


21

ダッシュボードは、収集されたすべての診断情報の大局を見せてくれます。イベントビュー

アー、トレースログ、インフラストラクチャログ、パフォーマンスカウンター、IIS ログ、IIS

の失敗したリクエストのログ、クラッシュダンプ、オンデマンド転送などを選択して見るこ

とができます。

サービスをデプロイしただけで何も収集は行っていない場合でも、心配はいりません。Azure

Diagnostics monitor は、ユーザーのロールや、個別のロールインスタンス内の診断モニターに、

リモート診断 API を通じてのアクセスを提供します。これによって、任意の診断情報の収集

の有効化／無効化や、冗長度や頻度を変更できます。

図 5 : Azure Diagnostics Manager - パフォーマンスカウンターのグラフ

CATEGORY: SQL AZURE

What: SQL Azure migration wizard http://sqlazuremw.codeplex.com/

Why: クラウドのソリューションに取り組む技術者の多くがすでに気づいているのは、システムイン

テグレーターに来る仕事の最大の部分は、既存のアプリケーションのクラウドへのマイグレーション

だということです。SQL Azure migration wizard は、データベースのマイグレーションがシンプルにな

るよう支援します。SQL Azure migration wizard を使えば、スクリプトが SQL Azure に適合しているかど

うかを分析し、スクリプトを生成してデータベース－スキーマとデータ－を移行できます。サポート

されているマイグレーションは、SQL Server から SQL Azure、SQL Azure から SQL Server、そして SQL

Azure から SQL Azure です。

バージョン 3.2.2 においても、なおおかしなところが残ってはいますが、SQL Azure migration wizard は

非常に改善されてきており、DB マイグレーションの日常的な作業を行うための素晴らしいツールで

す。

http://sqlazuremw.codeplex.com/


22

CATEGORY: 開発全般

What: Fiddler http://www.fiddler2.com/fiddler2/

Why: Fiddler は Web デバッギングプロキシです。Fiddler を使えば、マシンが送受信する HTTP（S）の

トラフィックを調べることができます。これは、Azure ストレージや Azure サービス管理 API、リモー

ト管理マネージャーAPI、そして REST なものならなんであれ、それらを利用して作業している場合に

特に便利です。HTTP トラフィックを見ておけば、どのようにリクエスト／レスポンスが構成され、

どんなレスポンスが受信され、あらゆる Web サービスの開発者／利用者が見つける他の情報のホス

トといったことに関する内部的な情報が、容易に得られるのです。

図 6 Fiddler - 統計情報

Fiddler のスクリプティングエンジンを使えば、入出力のリクエストやレスポンスをフィルタリングし

たり、事前に設定されたレスポンスを返すことができます。Fiddler はまた、特定のプロセスだけをタ

ーゲットとし、そのプロセスからのトラフィックだけをフィルタリングすることもできます。

Fiddler が提供する API を.NET アプリケーション内で使えば、プログラム的にネットワークトラフィッ

クを追跡したり、ほぼすべての Fiddler の機能を利用したりできます。これによって、受動的なセキ

ュリティ監査ツールの Watcher http://websecuritytool.codeplex.com/、キャプチャした http のリクエス

トを発行するリクエストコードを提供する Chad Oswald の Request to Code

http://www.chadsowald.com/software/fiddler-extension-request-to-code、JSON オブジェクトの可視化を

http://www.fiddler2.com/fiddler2/

http://websecuritytool.codeplex.com/

http://www.chadsowald.com/software/fiddler-extension-request-to-code


23

行う JSON Viewer http://jsonviewer.codeplex.com/ といった、便利な Fidder のエクステンションが登

場しています。

http://jsonviewer.codeplex.com/


24

第 2 章 WINDOWS AZURE プラットフォーム

AZURE を対象とするアーキテクチャ - 高度にスケーラブルなアプリケーションの構築

By Steven Nagy

クラウドに企業が移行する 2 つの主要な理由は、コストの削減と、規模の経済の利用です。残念なこ

とに、すべての種類のアプリケーションがクラウドに向いているわけではありませんし、通常の場合、

クラウドに向いているアプリケーションも、スケーラビリティを考慮したアーキテクチャにはなって

いません。さらに、Windows Azure プラットフォームの価格モデルは、アーキテクチャの検討フェー

ズで考慮に入れられていなかった場合、当初期待していた、クラウドへの移行によるコスト面でのメ

リットを帳消しにしかねません。この記事では、Azure プラットフォームに対してコストが最適化さ

れた、高度にスケーラブルなアプリケーションのアーキテクチャを検討するに当たって、考慮すべき

重要な事項を取り上げます。

AZURE アーキテクチャの原則

Windows Azure プラットフォームは、動作している分散プラットフォームからもたらされるエラステ

ィック性、冗長性、抽象化をすでに提供しています。これによって、利用者はクラウド用のシステム

の設計から始めることができますが、それでも依然として、アプリケーション自身が自分にとって最

悪の敵になることがないよう、見積もっておかなければならない大切な項目があります。以下に、プ

ロジェクトの設計及び実装フェーズにおいて、念頭に置いておくべき 5 つの教義を定めることにしま

しょう。

データのパーティショニング

データのパーティショニングは、新しい概念ではありません1。これまでデータのパーティショニン

グは、大規模なデータベースをより管理しやすい小さな部分に分割し、関連性のないデータ同士を

別々のパーティションに分割することで、クエリのパフォーマンスを改善するために使われてきまし

た。スケーラブルなアプリケーションでも同じ理由からパーティショニングは重要ですが、さらに効

率的にスケールすることが可能になります。単独のデータベースで毎分 500 リクエストを処理するの

と、10 インスタンスのデータベースで毎分 50 リクエストずつを処理することを考えてみてください。

さらに、ストレージは安価です。1GB のストレージに対する SQL Azure の価格と、Azure テーブルス

トレージ2の価格とを考えてみましょう。それぞれ、月当たり$10 と$0.15 なのです。どちらも最低で

も 3 回分の冗長性を持っています。とはいえ、Azure テーブルストレージは安価なだけでなく、パー

ティショニングのメカニズムが組み込まれており、個々のデータのエントリ（行）を、すべて指定し

たパーティションキーに基づく水平パーティション（あるいはシャード3）に割り当てることができ

るのです。テーブルストレージでは、それぞれのパーティションは物理的に異なるストレージノード

になるので、クエリやリクエストは、きわめて効率的にスケールできることになります。複雑なリレ

1 http://msdn.microsoft.com/en-us/library/ms190787%28v=SQL.100%29.aspx

2 http://www.microsoft.com/windowsazure/pricing/

3 http://en.wikipedia.org/wiki/Shard_%28database_architecture%29

http://msdn.microsoft.com/en-us/library/ms190787%28v=SQL.100%29.aspx

http://www.microsoft.com/windowsazure/pricing/

http://en.wikipedia.org/wiki/Shard_%28database_architecture%29


25

ーショナルなクエリを使わないなら、これは理想的な選択肢になります。リレーションシップを取り

除き、データを非正規化すれば、パーティショニングを非常に容易にできます。基本的には、これが

「NoSQL」ムーブメント4の前提となっています。

さらなるパフォーマンスの向上のためには、データの複製を考慮するべきです。顧客を年齢統計に基

づいて、あるいは都市によって検索する機能について考えてみましょう。異なるパーティションにデ

ータの複製が 2 つあれば、クエリとデータの取り出しにかかる時間は非常に効率的になります。この

アプローチの逆の側面は、データの複数のコピーを管理するために複雑さが増してしまうという点で

す。

Azure におけるパーティショニングのサポートは、以下のようにまとめられます。

テーブルのエンティティは、パーティションキーに基づいて水平にパーティショニングされ

る。

blob はコンテナに基づいてパーティショニングされる。

キューはキュー単位でパーティショニングされる。

SQL Azure はパーティショニングをサポートしない。

一部のフィールドがほとんどのクエリで要求されず、尐量のデータがまとめて保存されるような場合

は垂直パーティショニングが有効ですが、デフォルトでは垂直パーティショニングはサポートされま

せん。

コロケーション

SQL Azure、 Azure ストレージ、 Azure コンピュートロール、AppFabric は、すべてデータセンターに

出入りするデータに対する帯域コストが設定されています。アプリケーションを構築する際には、こ

のことを念頭に置いておくべきです。Azure ではすでにデータセンターをどこにするかを選択できま

すが、より重要なのは、Affinity グループを通じてシステムの構成要素の同じ場所に配置することで、

ネットワーク上のデータのやりとりを最小限に抑え、高速化できるということです。ありがたいこと

に、これはデプロイメントの事項として考慮すべきことなので、当面の設計に関してはそれほど重要

ではありません。

キャッシュ

考慮すべきより重要な事項は、キャッシングのメカニズムを利用する様々な機会です。トランザクシ

ョンを最小限にとどめるために、様々な方法でキャッシュを活用することができます。エンドユーザ

ーの http リクエストから、下位層のデータストア、あるいはメモライゼーション5目的などがそうで

す。プラットフォーム内のほとんどすべてのものに対して REST インターフェースでアクセスできる

場合、キャッシングには注力するだけの価値があります。検討すべきキャッシュの概念をいくつか挙

げてみましょう。

4 http://en.wikipedia.org/wiki/Nosql

5 http://en.wikipedia.org/wiki/Memoization

http://en.wikipedia.org/wiki/Nosql

http://en.wikipedia.org/wiki/Memoization


26

クライアントサイドの有効期限付きキャッシュ– 一定期間が経過した後は無効になるコンテ

ントで、クライアントのブラウザがページをリクエストせず、代わりにローカルコピーが提

供されるようにする。

エンティティタグ6（ETags） - http のヘッダーフィールドで'version'を指定できるようにしま

す。サーバーはバージョンが変わっておらず、その他のデータも変更されていないことを提

示できます。そうでない場合には、リクエストされたデータをすべて返すことができます。

ASP.NET のページレベルキャッシュ。

分散キャッシュ7 -同じコンテントを共有する複数のノードが持つ（shared everything）か、そ

れともキャッシュのユニークな部分だけを持たせるようにするのか(shared nothing）。容易に

使い捨てできるコモディティハードウェアと、スケールしやすいことから、shared everything

型の分散キャッシュは Azure でうまく動作します。

ステート

ステートは、しばしば並行プログラミングの敵と見なされてきましたが、複数のコンピュートインス

タンスのような、より高い抽象度においても同じことが言えます。ミュータブルなステートを使う場

合、ロックと並立している環境の追跡が必要になるので、アプリケーションにオーバーヘッドと複雑

さが加わってしまいます。従って、ステートを減らす、あるいはいっそ無くしてしまうことは、説得

力のある観念です。

ステートは、セッションのステートのように、単一のユーザーに対するものであることもあります。

Azure のデータセンターのロードバランサーはラウンドロビンなので、1 つ以上の Web のフロントエ

ンドを使えば、それでもうセッションステートをプロセスに保存することはできなくなります(これ

がデフォルトです)。アプリケーションにとってセッションステートが重要な場合、それを SQL Azure

やテーブルストレージに移すことを考えましょう。とはいえ、セッションステートは、通常乱用され

てしまっており、使われている場合でも概して実際には不要なのです。セッションの代わりになるモ

ノとしては、クレームベースのセキュリティを検討し、リクエストされたぺージにクレームの集合が

付くようにしましょう。AppFabric のアクセスコントロールサービスは、この方法を支援します。

効率の良い負荷の配分

通常、複数のソースがあるリソースにアクセスしなければならない場合、ある程度の競合が生じます。

ロックとリリースを行い、他のスレッドは競合が収まるまでブロックされることになります。ステー

トがある場合、この問題はどんな形態の並行プログラミングにも存在するもので、複数のインスタン

スが作業を共有するシナリオにおいては重要なことになります。Worker ロールは処理の対象となる

アイテムを選択しなければなりませんが、同じ Worker ロールの複数のインスタンスがある場合、ど

うすればそれぞれのインスタンスが同じ作業アイテムを選択しないことを保証できるでしょうか？

「非同期ワーカーキューパターン」は、この問題に対するソリューションの 1 つです。作業アイテム

をユニークに配分することを保証する、頑健かつ冗長性のあるキューイングのメカニズムを用意する

6 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

7 http://msdn.microsoft.com/en-us/magazine/dd942840.aspx

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

http://msdn.microsoft.com/en-us/magazine/dd942840.aspx


27

ことで、ワーカーはロックの取得や解放を扱う必要がなくなり、作業アイテムを処理する仕事に集中

できます。こういったキューは、様々な異なる種類の処理で再利用できるもので、Windows Azure の

Storage Queue はそのための理想的な候補です。

構成要素を分離できるようにしてくれるメッセージングアーキテクチャは他にもあります。例えば、

AppFabric は Publish/Subscribe 型のシナリオに対して、‘NetEventRelayBinding’を可能にします。

リソースの最大化

CPU が 100%使われていない場合、それは十分活用されていないと考えることができます。Azure では、

利用状況にかかわらずコアに対して支払いをすることになるので、払った分はできる限り活用しよう

とするのは理にかなっています。

Worker ロールを使っている場合、マルチスレッドアーキテクチャが忘れられてしまっていることが

よくあります。インスタンスをもう 1 つ足せば、時間あたりのコストが追加されることになるので、

まずは現在のインスタンスを確実に使い切るようにしましょう。ワーカー（あるいは場合によっては

Web ロールも）が大量の IO 処理をしなければならないのであれば、複数のスレッドを使う意味があ

ります。

自動スケーリングリソースも、調べてみる価値があります。通常の場合、IT 部門は負荷がピークにな

る期間に備えられるだけのサーバーを管理しますが、そうする代わりに、最低限の容量から始めて、

動的にインスタンスを追加するために自動スケーリング機能を使うことを検討してください。負荷が

下がってきたら、スケールダウンし始めれば、それに連れてコストが削減されることになります。

今日では、特定の場所に対して blob をプッシュするために、コンテンツ配信サービス（CDN）を利用

することができます。これは、顧客のレイテンシーの改善に役立つでしょう。また、blob ストレージ

にどんなものが向いているかも検討してみてください。原則として、静的な内容ならどんなものでも

考慮の対象になるでしょう。

PDF、 Word のドキュメント

ビデオ s

Web サイトのイメージ

Web サイトの CSS や JavaScript ライブラリ

静的な HTML で書かれたあらゆる Web サイトのページ

Silverlight のファイル（XAP）

blob ストレージでは、現在のところルートコンテナーに blob を保存できます。この機能が特別に組

み込まれているのは、blog ストレージから実行される Silverlight のアプリケーションが、クロスドメ

インポリシーファイルを URL の名前空間のルートに置ける（これはクロスドメインポリシーファイル

の必要条件です）ようにするためです。

まとめ

多くはありませんが、この記事では Windows Azure プラットフォーム上で実行されるアプリケーショ

ンのアークテクチャを設計する上で念頭に置いておくべきいくつかの重要な原則について、概要を述


28

べました。これらのガイドラインを守れば、クラウドの主たる目的である、スケーラビリティとコス

トの活用を達成できるはずです。


29

WINDOWS AZURE プラットフォームと、コスト指向アーキテクチャ

By Marcus Tillett

コストは重要です

コスト指向開発は、目新しいものではありません。アプリケーションや製品を構築するための低コス

トのアプローチは望ましいものですが、これを達成するための方法論は、常に洗練されたものである

とは限りません。Azure のようなクラウドプラットフォームについて考慮する場合、アーキテクチャ

の選択がコストに与える影響は大きいものになるので、より洗練されたアプローチが必要になります。

伝統的なオンプレミスのアーキテクチャや、ホストされているアークテクチャの場合、コストは重要

なファクターとは考えられないかも知れませんが、Azure の場合、コストははるかに注目される領域

になります。考慮しなければならないコストは様々です。それらのコストを考慮しなければならない

のは、Azure に関してでもありますし、開発全般に関してでもありますし、アプリケーションのライ

フサイクル管理のプロセスに関してでもあります。

考慮すべきコスト

開発プロセスは、Azure においてコストについてしっかり考慮

する必要があるかもしれないものです。Azure での開発戦略は

幅広く考えることができます。1 つの極論としては、Azure の

環境自体で開発を行うこともできますし、反対の極論としては、

Azure を全く考慮することなく開発することもできます。

この開発戦略の幅の中でどういった選択をするのかによって、

コストは影響されますし、大きなメリットもデメリットも生じ

ます。例えば、ソフトウェアファクトリーの利用を考えてみま

しょう。厳密な構築プロセスを採用するソフトウェアファクト

リーを採用する場合、生産プラットフォームを利用するための

コストは、必要なプラットフォームとトレーニングの双方にか

かる出費のため、まかないきれないほど高いものになってしま

うかも知れません。こういった懸念によって、コスト指向アー

クテクチャの選択が進むことになるでしょう。コスト指向アー

キテクチャでは、Azure 固有のすべてのコンポーネントは、

These concerns would drive a cost-oriented architecture where all Azure specific components are abstracted

from the developer or potentially replaced with non-Azure components. While this may be an extreme

example, it does highlight one of several areas to be considered.

もう 1 つの重要なトピックとして、既存のアプリケーションのマイグレーションや、新しいアプリケ

ーションに求められるデータのセットアップの考慮のための方法論があります。マイグレーションや

設定は、アプリケーションとデータの両方を含む必要があります。大量のデータや複雑なデータを転

送するのに必要となる時間やプロセスや手順は、非常に大きな仕事になり得るものです。利用中のデ

まとめ

これまでのオンプレミスあるいはホス

トされたソリューションに比べ、Azure

ではアーキテクチャに関する考察がコ

ストに大きく影響する。

アーキテクチャの選択が、コストに与

える影響は大きなものになり得る。

コストは、開発全体、そしてアプリケ

ーションのライフサイクル管理のプロ

セスを考慮に入れて検討すべきであ

る。

選択したアーキテクチャのコストはモ

デル化しなければならないが、さら

に重要なのは、そのモデルをテスト

することである。


30

ータソースに対する変更の管理には潜在的な複雑性があるので、選択したアプローチに必要となるビ

ジネスコストは、非常に重要なファクターになり得るのです。

プラットフォーム自身がコストに与える影響は、おそらく、明白にコスト指向アーキテクチャを必要

とする領域でしょう。例えば、データストレージにおける SQL Azure と Windows Azure ストレージと

の劇的な価格差に注目するのは自然なことです。アプリケーションによっては、これはきわめて重要

なことですが、より優先すべきは、しっかりとしたアークテクチャを構築するためのバランスをとる

ことです。そうすることによって、初期のコストにだけ注目するのではなく、長期的に見た場合の裁

量のアプローチが得られるのです。そのためには、アプリケーションのすべての構成要素のコストを

モデル化するべきですが、より重要なのは、アプリケーションのコスト的にもっとも重要な側面によ

ってそのモデルをテストし、アプリケーションの設計と、Azure の課金メカニズムがコストモデルに

どのように影響するかを理解することです。この情報があれば、大幅なコスト削減という観点から、

アーキテクチャをレビューすることができます。コストが重要な部分では、常に最終的なアプリケー

ションにモニタリング機能を持たせておき、Azure とアプリケーションの進歩がコストに与える明確

な影響をしっかりと分析しながら、そのモニタリング機能を使ってシステムをチューニングしましょ

う。実際のところ、コストと SLA を検証する手段として、システム全体をモニタリングすることは、

もう 1 つのアークテクチャ上の考慮点なのです。

完全なコストモデリングプロセスの拡張へ至る道筋としては、プラットフォームのコストがコスト指

向アーキテクチャを示唆するようなシナリオがいくつもあります。その中の 1 つは、アプリケーショ

ンを、大量のテナントを抱えるマルチテナント化するというものです。一組のサーバーからなる、基

本的なオンプレミスあるいはホストされたサーバーモデルでは、それぞれのテナントに対して個別の

IIS Web サイトと SQL Server のデータベースを生成できます。このモデルは、数十から、おそらくは

数百までのテナントを、単一のテナントとほぼ同様のコストでサポートします。同じアーキテクチャ

を Azure に移行すれば、テナントは 1 つの Windows Azure Web ロールと、1GB の SQL Azure データベ

ースからなるでしょう。これはおよそ、テナント毎に一ヶ月あたり 100$ほどになりますが、この

Azure アーキテクチャのコストはテナント数に対して線形にスケールします。ここでは Azurega マル

チテナントアプリケーションに不向きだと主張したいわけではありませんが、アプリケーションにと

ってコストが重要なファクターである場合は、異なるアークテクチャ上のアプローチが必要になるこ

ともあるのです。

結論

本稿で考察したものは、コスト駆動8あるいはコスト指向アーキテクチャ

9,10と名付けることができる

かも知れませんが、用語よりも重要なのは、これまでのオンプレミスあるいはホストされたソリュー

ションに比べて、Azure ではアーキテクチャに関する考察がコストに及ぼす影響が大きいことを理解

することなのです。

8 Lessons Learned: Building Multi-Tenant Applications with the Windows Azure Platform

http://microsoftpdc.com/Sessions/SVC33 9 Thinking of... Delivering Solutions on the Windows Azure Platform? http://www.amazon.co.uk/Thinking-

Delivering-Solutions-Platform-Questions/dp/0956155634/ 10

Windows Azure Platform for Enterprises http://msdn.microsoft.com/en-us/magazine/ee309870.aspx

http://microsoftpdc.com/Sessions/SVC33

http://www.amazon.co.uk/Thinking-Delivering-Solutions-Platform-Questions/dp/0956155634/

http://www.amazon.co.uk/Thinking-Delivering-Solutions-Platform-Questions/dp/0956155634/

http://msdn.microsoft.com/en-us/magazine/ee309870.aspx


31

初めての WINDOWS AZURE プロジェクトにおけるリスクの回避

By Simon Munro

Azure に基づくソリューションの構築に傾ける開発者の熱意は、必ずしも企業に共有してもらえると

は限りません。クラウドが「未来への道」であることは素晴らしいこと（そしておそらく私たちには

明白なこと）ですが、個人や企業、ベンダーの中には、この変化に対応する準備ができているものも

あれば、できていないものもあります。すべてのベンダーがクラウドのための技術を持っているわけ

ではありませんし、多くの企業、製品、産業や職が、クラウドの波によって海の向こうに流されて行

ってしまうことになるでしょう。ベンダーは我先に注意を引こうとし、そのバイアスのかかったマー

ケティングに毒された意見を押しつけています。このバイアスは、もっとも巨大な恐竜によって与え

られたものです。この恐竜－すなわち紙媒体のメディアは、自身の持つ文化のために、インターネッ

トがもたらした変化に対応することすらできないのです。クラウドに反対し、ベンダーを非難する意

見の多くは、恐れと、業界の仲間の抱えるリスクからくるもので、（現在の）リスク回避型の環境に

おける地位を保ちたいためのものなのです。私たち自身の組織の中で、クラウドコンピューティング

に関する決断を下してもらわなければならない人たちが、自分たちのソリューションを Azure 上で動

作させるという最新の考え方に対してコミットするということに対し、混乱し、二の足を踏んでいる

のは、驚くべきことではありません。「クラウド」という言葉は、「Web」という言葉の同義語にな

り、私たちが関心を持っている「クラウドコンピューティング」プラットフォームとの境界もはっき

りしないものになっています－

The term ‘the cloud’ has become synonymous with ‘the web’ and is indistinct from ‘cloud computing’

platforms that we are interested in – the unfortunate side effect being that the behaviour of Google, Facebook,

Apple and other web-consumer facing properties that willy-nilly change terms of service and sell personal data

for profit casts a shadow over business oriented cloud computing services.

この粉塵は、将来のどこかの時点で落ち着くことでしょうが、近い将来に Azure 上でソリューション

を構築したいのであれば、私は企業からの支援を得るため、この問題を企業が理解する手助けをする

責任を負わなければなりません。私たちが技術的な問題だけを扱っていたくても、ほとんどの環境に

おいて、現時点での現実の中では、予想されるリスクについて前もって議論しておき、Microsoft と

Windows Azure プラットフォームがそうしているのと同じように、私たちがが積極的にリスクを管理

し、低減していることを示さなければならないのです。

一般的なリスク

現在のところ、リスクについては非常に広く知られています。これは、データがいったんその組織内

に隔離されているデータセンターの外にあるデータベースに置かれてしまえば、データに対するコン

トロールや権限がうしなわれてしまうからです。共学の寮で暮らす学生とは異なり、データは実家を

出たとたんに酔っ払って自分の写真を Facebook にアップしたりはしませんが、オフプレミスのデー

タは高リスクであるという疑いは残ります。とはいえ、データに関するリスクは増大するかも知れま

せんが、実際のリスクは多くの場合ひどく誇張されており、管理することは可能です。

プロセスに関するリスクもよく知られており、これは主にソリューションの運用面において、他者が

参加することからくるものです。企業はもはや、自社内の IT に対しては持ち得たようなサービスの

レベルや信頼を、外部のサービス提供者に強制することはできません。データの場合と同様に、顧客


32

がベンダーロックインを避けようとし、サービスレベルを保証し、運用やセキュリティ、パフォーマ

ンスやその他の標準を管理しようとするにつれて、きわめて複雑な契約上の分岐が生じてしまうとい

う、現実の問題がここにはあります。

隠れたリスク

主流の CIO の情報ソースは、扱う範囲が広いためにリスクを広めてしまいますが、主としてより技術

的な性格を持っているために、同じように現実的なものでありながら、それほど知られていないリス

クが多く存在しています。

もっとも明白なのは、セキュアで信頼性があり、高性能なクラウドコンピューティングソリューショ

ンを生み出すのに必要な、スキルや経験が欠けているというものです。このことはまた、パフォーマ

ンスのボトルネックに対し、単純にハードウェアを投入するのに比べて、開発技術者のコストの方が

高くなってしまうという問題にも関係します。

私たちが信頼を置く、プラットフォームとツールの提供者である Microsoft でさえも、Azure が持つリ

スクを抱えています。Azure テーブルやキューといったクラウド技術の、オンプレミスでの代理技術

が欠如していることによって、Azure プラットフォームへのコミットメントは、きわめて高いものに

なってしまい（ベンダーロックインと同じようなものです）ますし、ツールはまだ未成熟で、継続的

インテグレーション（グレース・モリソンによる‘Using a CI build to achieve an automated deployment of

your latest build’を参照）のような、認知されている技術的なプラクティスをサポートすることも用意

ではありません。

リスク低減のための非技術的戦略

究極的には、リスク管理の責任は、組織内のプロジェクトマネージャーやその他の人員に帰せられる

ものですが、リスクの特定は、依然としてチームのメンバー全員の責任です。本書をダウンロードす

ることで、読者はチーム内の同僚以上にクラウドコンピューティングに関する知識を得ることになっ

たので、技術的な側面に踏み込む前に、より多くの責任を背負い、リスク低減の側面の中でも、コー

ドとは関わらない部分に対処しなければならないでしょう。

正しいアプリケーションの選択

シンプルで、クラウドコンピューティングにより適しているものを選択しましょう。それは例えば、

公開され、要求のピークがあるかもしれないようなものです。機微なデータを含んでいたり、他の多

くのシステムと統合されたり、既存のレガシーシステムからのマイグレーションであったり、多くの

伝統的なデータベースストレージやレポートを含んでいたりするアプリケーションに取り組む前に、

こういった例での成功を積み上げましょう。

早めに始める

そのプロジェクトが、目立たなくてつまらない開発を行うものだったとしても、企業における法務、

コンプライアンス、運用、財務、監査やその他の部門との関わりは、通常より早めに始めなければな

りません。通常は、既存のデータセンターに新しい Web サイトを立ち上げる心配などはしませんが、


33

仮に筋を通さずにクラウドコンピューティングのアプリケーションを立ち上げて周りの人々を驚かせ

るようなことをすれば、そのアプリケーションは信頼してもらえないことでしょう。

価格と運用モデルの理解

表面的にはシンプルに見えるかも知れませんが、クラウドコンピューティングの価格、課金、SLA や

その他の事項を深く見ていけば、法的な部分やコンプライアンス、部門間の調整などへの広範な影響

があり、それらは複雑なものかも知れません。尐なくとも、推定される要求事項を付けて Azure の価

格を記載したスプレッドシートと、注記付きの SLA のプリントアウトを、プロジェクトの出資者に渡

しておかなければなりません。

影響の理解

完全な脅威モデルを扱う必要はないかも知れませんが、アプリケーションに問題があったり、データ

が失われた場合に考えられる、財務面や風評面、あるいはその他の面でのリスクについては理解して

おく必要があります。損失の影響を理解したら、クラウドにどういったデータをどれだけの期間保存

するのか、そしてそれをオンプレミスのストレージに移動させるかどうかといったことのアプローチ

に、それを反映させるべきです。

オンプレミスのリスクに精通する

クラウドコンピューティングにはセキュリティリスクがあると見なされているので、セキュリティに

焦点を当てるということは、しばしばそのソリューションが対応するオンプレミスの部分よりもセキ

ュアであるということを意味します。クラウドコンピューティングのリスクに対応する際には、必ず

それらのリスクを、既存のオンプレミスプラットフォームにある既存の日常的なリスクと比較してく

ださい。必ずしも、すべてのソリューションやネットワーク、その他のインフラストラクチャが、実

際に約束していたとおりの可用性やセキュリティを達成しているとは限らないのです。

リスクへの欲求を理解する

銀行などのように、追加のリスクを尐なくとも今年は取りたがらない、リスクを嫌う企業に比べ、ス

タートアップ企業は企業文化として、クラウドコンピューティングのリスクを、企業全体として持っ

ているリスクの一部として見なすことができます。より成熟した企業は、リスク管理のためのプロセ

スや委員会を持ち、最終的にはプロジェクトのスポンサーの責任になるかも知れませんが、大きなア

イデアを実現しようとする前には、その組織がリスクをとれるかどうかの感触を得ておかなければな

りません。

リスク低減のための技術戦術

HOW EXTREME?

Microsoft は、古き良き ASP.NET Web アプリケーションを、その下位層の SQL データベースと共に、

Azure クラウドに最小限の変更で投入するのを、きわめてシンプルなことにしました。一方で、クラ

ウドコンピューティングの環境に最適化された、十分検討されたアーキテクチャを持つソリューショ


34

ンを構築することは、より難しく、手間がかかり、リスクを伴うことです。システムの構築を、リス

クを回避する環境で行い、クラウド用にする必要がないのであれば、Azure ストレージ、Worker プロ

セス、フェデレーテッド認証管理やその他のクラウド固有の技術は使わずに、web ロールと SQL デー

タベースでシンプルなソリューションを構築しましょう。どちらのアプローチを取るにしても、

Azure はそのアプローチをうまくサポートしてくれますが、魅力的な新機能が実際にはどれだけ必要

なものなのかを見極め、早めに決断を下しておかなければなりません。

データへのアプローチの決定

クラウドコンピューティングのリスクに関する限り、もっとも重要で活発な問題はデータであり、こ

れに関してはソリューション設計の初期の段階で検討しなければなりません。ありがたいことに、必

要な場合はおなじみのデータベースプラットフォームを SQL Azure で利用すれば、NoSQL 的な Azure

テーブルに関する多くの問題やリスクには対処できますが、Azure を使う優れたアーキテクチャでは、

最終的には Azure ストレージやキャッシュ、あるいはその他の技術を検討する必要があるでしょう。

Azure クラウドのストレージをどう使ったとしても、依然としてそのデータはクラウドの中にあり、

構築するアーキテクチャでそのデータを扱わなければならないという問題は残ります。レポートや他

のシステムのとの統合のため、あるいはただ単にデータの安全性のために、Azure からオンプレミス

のデータベースへ、データを移動したりコピーしたりする要求があるかも知れません。

エンジニアリングコストの管理

それなりのサイズのアプリケーションを Azure 上で構築し、それをライブ環境へデプロイするまでは、

隠れたままになっている技術的な課題があるものです。本書を読むことで、読者は正しい方向性に向

かい、他者の経験から学ぼうとしているわけですが、単なる読書や、実作業から学ぶ以上のことをや

る必要があります。まだ見ぬ落とし穴のインパクトをとにかく低減するためには、ツールをインスト

ールし、コードを書いてデプロイし、負荷をかけ、スケールアップし、スケールダウンし、デバッグ

し、診断を行い、見たことのないたくさんのパターンや技術に取り組まなければならないのです。

優れたエンジニアリングプラクティスの下での実装

あなたの初めての Azure アプリケーションの未来は、全く不確かなものです－2 年先を考えてみても、

アーキテクチャ上の選択が正しかったかどうかははっきりせず、技術的な構成要素は追加されたり廃

棄されたりしており、規制は変更されていたり、クラウドコンピューティングに対するあなたの会社

の態度も変わっているかも知れません。安定するまでに数年もかかるような環境下では、ソフトウェ

ア職人気質からわき上がる、メンテナンス性、テスタビリティ、拡張性といった懸念は、増幅される

ものです。.NET のエコシステムにおいて、十分に確立されたプラットフォームと、新しい技術、ア

プローチ、考え方が組み合わさった Azure は、私たちが直面しているリスクを低減できるよう適切に

ソリューションを構築するための、要求とフレームワークの両方を、私たちが手にしていることを意

味しているのです。テスタビリティ、IoC、疎結合、あるいはその他のソフトウエア職人の技法

は、.NET プラットフォーム上で十分サポートされ、理解され、議論されてきており、従って（もち

ろんのこと）Azure に持ち込むこともできるのです。技術者は、一見簡単に見える単一階層のモノリ

シックなアーキテクチャとして、これらの技術を磨かなければならず、


35

You need to hone these skills as single layered, monolithic architectures that seem easy at first and are

encouraged by Microsoft marketing and tooling will result in an approach with high and unnecessary risk in an

already risky space.

開発者の責任

技術者は、クラウドコンピューティングによってもたらされる技術的な可能性に興奮するかも知れま

せんが、企業やその他の方針決定者は、おそらく他の（最近の）どのコンピューティング技術の波と

比べても、クラウドコンピューティングに対して警戒心を抱いています。彼らは、ベンダーのマーケ

ティング担当者達や、クラウドの自称エキスパートの矛盾するメッセージに目を通しており、一方で

既存の仕事を守ろうとする彼らのスタッフからは、廊下で雑音をささやかれているのです。従って、

リスク管理やアーキテクチャの売り込みは、もっともエキサイティングな開発者のスキルではないか

も知れませんが、クラウドコンピューティングに必要なのは、私たちがクラウドコンピューティング

を企業に持ち込み、恐れを静める責任を負うことなのです。


36

複数人で AZURE に取り組む際の挑戦と困難

By Grace Mollison

開発開始からクライアントに手渡すまでに 7 週間を要した Azure プロジェクトの See the Difference に

携わったのは、大変楽しいことでした。

使われた技術スタックは、Windows Azure ホスティング、Windows Azure ストレージ、SQL Azure、

ASP.Net MVC、N2CMS、Spark View Engine、Castle Windsor、xVal、 PostSharp です。

問題の 1 つに、Azure の開発体験は、開発者のチームのために設計されいないということがあり、そ

れをなんとかする必要がありました。何から始めれば良かったでしょうか？

もちろんリストからです。以下が、大枠のチケットアイテムです。

開発、テスト、UAT の 3 つの環境を構築できるようにする。テストと UAI は、チームの

全メンバーが利用可能とする。

ホストされた環境への共有アクセス。

CI ビルドの一部として、クラウドへのデプロイメントを自動化する。結局のところ、プ

ライドのある開発チームが、継続的インテグレーションのビルドをやらないなんてこと

はあり得ない。

開発環境

開発環境としては、私たちは Visual Studio 2008 SP1 を使い続けました。開発の開始時点では Visual

Studio 2010 はベータ 2/RC で、Azure に関するポテンシャルが全く不明な状態では、その一歩は踏み

出し難いものでした。Azure の開発ツールは各開発者のワークステーションに、そして Azure の SDK

はビルドサーバーにインストールされていました。開発サイクルの期間中には Azure SDK のアップデ

ートがあり、これは開発チームによると必要なものでした。これはすなわち、手作業で構成された環

境を持っている様々なマシンをアップデートしなければならないということです（残念ながら、

WSUS はなかったのです）。幸運なことに、こういったことがあったのは、開発期間中に一度だけ

でした。

開発環境には、Visual Studio に加えていくつかのツールが追加されており、これによってより完全な

開発体験がもたらされていました。

テスト環境

テスト環境については、より難しい問題があることが分かりました。もっとも現実的な解決策は、開

発ファブリックを動作させるもう 1 つの開発用ワークステーションを展開することでした。しかし

（いつでも「しかし」が出てくるのはご存じですよね）開発ファブリックは、ローカルのループバッ

クアドレスに対して動作するものです。これを回避するには、ターゲットマシンと、ターゲットマシ

ンにアクセスするクライアントマシンとの間で、SSH トンネルを設定しなければなりませんでした。

残念なことに、これは尐々ユーザーフレンドリーとは言えないことに加えて、ローカルストレージフ

ァブリックに対するランダムなポート割り当てを、新しい開発作業の度に解決しなければならないた

め、基本的には使い物にならないことが分かりました。開発ファブリックと Azure ファブリックとの

http://www.microsoft.com/windowsazure/evidence/archive/

http://n2cms.com/

http://sparkviewengine.codeplex.com/

http://www.castleproject.org/container/gettingstarted/index.html

http://xval.codeplex.com/

http://www.sharpcrafters.com/postsharp


37

違いもまた、最終的に動作の違いが見つかったりしたり、ステージング環境で特定の機能のテストし

かできなかったりしたため、チームでできることに影響しました。私たちは、Azure ストレージをテ

スト環境として使わざるを得ませんでした。

ここからは楽になると予想していましたが、しかし…そう、これはいくつもの「しかし」の内の 1 つ

でしかありません。

証明書

チームのメンバーは、自分自身の自己証明書を使うか、私が生成して Azure にアップロードした証明

書を使うかしなければなりませんでした。チームが小さくて流動的なことから、私が生成した証明書

を使うということが決定されました。これは、良い判断だったということが分かりました。というの

は、チームのメンバーの中には時折証明のための接続がタイムアウトしているように見える現象を体

験している者がおり、その理由がはっきりしなかったのです。問題のある証明書は 1 つだけだったの

で、その利用に関する問題を解決するのはそれほど苦痛ではありませんでした。こういった方法で証

明書を共有するのは良いやり方ではありませんが、その時点では実利主義を優先せざるを得なかった

のです。チームがより大きく、長い開発サイクルのためのものだったなら、私としては、容易に削除

することができる、個人証明書を使うように各開発者に呼びかけていたことでしょう。

私たちがすぐに学んだのは、開発の初期段階においては、新しいパッケージをデプロイするためのも

っともの安全なアプローチは、まずサスペンドし、続いて削除をするということでした。これによっ

て生ずる URL の変更は、チームが小さいおかげで容易に通達できました。

うまくいかない時

Azure が Dr.Watson に吐くのを待つことしかできなかったり、Azure がロールを立ち上げようとしてい

る間、何のフィードバックもなかったりするのは、本当に頭の痛い体験です。

残念なことに、UAT を使い始めるとすぐに、私たちはステージング環境を放棄し、クライアントとサ

ードパーティの両方に URL が分かるように、ステージングの URL への変更を最小限にとどめなけれ

ばなりませんでした。システムテストのためのこの環境がなくなったということは、すなわち私の個

人的な Azure のアカウントを、ステージング環境として使わざるを得なくなったということでした。

最終的には、私たちはデプロイメントを自動化しましたが、それはこの記事で書くには長すぎる物語

です。

まとめ

Windows Azure プラットフォームは、そのままではチーム開発に向いているとは言えないかも知れま

せんが、対処しなければならないことが分かりさえすれば、チーム開発に対する障壁は容易に克服で

きます。いつものチーム開発ツールを使った普段のアプリケーション開発と同様に、事前にちょっと

した準備をしておけば、Windows Azure プラットフォームでの開発はうまくやることができるのです。


38

継続的インテグレーションビルドを利用した、最新ビルドの自動化の実現

By Grace Mollison

この記事は、タスクやプロパティといった Team Foundation Buidl と MSBuild の概念に読者が慣れてい

ることを前提として書かれています。

継続的インテグレーション（CI）ビルドを設定し、成功したビルドパッケージを直接 Azure に自動的

に送信するのは、最初から簡単にできることではなく、多尐の作業を必要とします。この記事では、

Windows Azure プラットフォームを使い、See the Difference プロジェクトを完成させるにあたって採

用したアプローチの概要を述べます。

正しい “BITS”の入手

私たちが最初に行ったのは、ビルドサーバーがコマンドラインからターゲットの Windows Azure ポー

タルにアクセスするのに必要なコンポーネントをそろえ、設定することでした。

そのためには、Azure Service Management API を使うことが必要でした。この API を使うには、x.509

証明書が必要です。私は Windows SDK にある makecert ツールを使って自己証明書を生成しました。

やり方の例を以下に示します。

"c:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\makecert" -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss My -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 MySelfSignedCert.cer.

Creating and using Self Signed Certificates for use with Azure Service Management API という Blog のポスト

では、ターゲットの Azure のポータルおよびそのポータルと通信するマシン上で証明書を設定する方

法について、詳細に説明されています。

私は Windows Azure Service Management PowerShell CmdLets と Windows Azure Service Management API

Tool をダウンロードしました。これらはどちらも、Service Management API を通じて Azure のポータ

ルにリモートアクセスするのに便利なものです。この段階では、どちらを使うかはまだ何も決めてい

ませんでした。私は、Build の一部として両方を使ってみた結果、Service Management API ツールの

csmanage の方を（PowerShell の大ファンであるにもかかわらず）気に入りました。先に挙げた Blog

のポストには、Azure のステージング環境へのデプロイに、x.509 証明書や API および Powershell を使

う方法が示されています。

デプロイメントのためのパッケージング

次に、私はデプロイメントのためのアプリケーションのパッケージングについて調べました。コマン

ドラインからアプリケーションをパッケージングするにあたって、重要なことが 2 つあります。

パッケージの構築に必要になるので、ロールの種類と名前を取得する

サービス定義ファイルの場所が分かっていることを確認する

ServiceDefintion.csdef ファイルには、Windows Azure のコマンドラインツールである cspack を使って

パッケージを構成するのに必要となる、ロールの種類と名前が含まれています。以下に示す

http://www.microsoft.com/windowsazure/evidence/archive/

http://consultingblogs.emc.com/gracemollison/archive/2010/02/19/creating-and-using-self-signed-certificates-for-use-with-azure-service-management-api.aspx

http://code.msdn.microsoft.com/azurecmdlets

http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=windowsazuresamples&ReleaseId=3233

http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=windowsazuresamples&ReleaseId=3233


39

ServiceDefintion.csdef ファイルの一部は、web ロールが一つだけあるシンプルな例を示しています。

インスタンス数は、cspack には関係ありません。

<ServiceDefinition name="SeeTheDifference.Cloud"

xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">

<WebRole name="SeeTheDifference.Web" enableNativeCodeExecution="true">

<InputEndpoints>

cspack が正しい場所から実行されなかった場合は、パッケージは正しく構築されません。これが、

ServiceDefinition.csdef ファイルの場所がとても重要な理由です。

デプロイ

この段階で、アプリケーションをパッケージングして、Azure のポータルに MSBuild からデプロイで

きるようになりました。このアプローチに関しては、パッケージングがデプロイメントに影響してし

まうという点で、懸念がありました。特に、多尐の注意事項があるような場合に、顧客への納品後に

どうすればよいのかが気になっていました。そのため、計画を変更することにしたのです。

新しい計画は、パッケージを blob ストレージに保存しておき、クライアントの都合が良いときにデ

プロイしてもらえるようにすることでした。

パッケージを blob ストレージに保存するために、MSBtuild のスクリプトから呼び出すことができる

LoadBlob という C#のコンソールアプリケーションが作成されました。このアプリケーションは、パ

ッケージを事前に決められたコンテナに保存するものでした。

設定（.csfg）ファイルを blob ストレージに保存するのも、製品版でない設定ファイルが使われてし

まうリスクを下げることができるので、良いアイデアだとされました。テストの期間中には、保存さ

れた設定ファイルをサービス管理 API から使うことができませんでした。サービス管理 API からは、

ローカルシステムに保存された設定ファイルしか使うことができなかったのですが、実装しているデ

プロイメントのプロセス全体として、Azure のステージングあるいは実働環境への投入の前には、一

息間を置く必要があったので、この問題は CI ビルドプロセスの実装には影響しませんでした。

最終的に、すべての構成要素のテストが終わった後に、それらの要素は CI ビルドの一部として取り

込まれました。

以下のスニペットは TFSbuild.proj ファイルからの者で、ターゲットの AfteDropBuild をオーバーライ

ドしています。

AfterDropBuild タスクは、ビルドされたバイナリがドロップされると呼ばれるタスクで、私はこれを

使って、クラウドサービスのパッケージを作成するためにビルド中で cspack（dll や設定ファイルを

zip するのと同じです）を使うためのコマンドをいくつか挿入しました。そして、クラウドサービス

のパッケージは blog ストレージに保存され、ステージングあるいはプロダクション環境へのデプロ

イを待つことになるわけです。

<PropertyGroup>

<PathToAzureTools>c:\Program Files\Windows Azure SDK\v1.0\bin\cspack.exe</PathToAzureTools>


40

<cPkgCmd>"$(PathToAzureTools)" SeeTheDifference.Cloud.csx\ServiceDefinition.csdef

/role:SeeTheDifference.Web;seeTheDifference.Cloud.csx\roles\SeeTheDifference.Web\approot;SeeTheDiffere

nce.Web.dll</cPkgCmd>

<LoadblobPath>c:\TOOLS\AzureDeployment</LoadblobPath>

<LoadBlobCmd>$(LoadblobPath)\Loadblob.exe </LoadBlobCmd>

</PropertyGroup>

<Target Name="AfterDropBuild" DependsOnTargets="DeriveDropLocationUri" Condition="

'$(IsDesktopBuild)'!='true' ">

<Message Text=" cspack creating a package for deployment"/>

<Exec Command="$(cPkgCmd) /out:c:\Drops\SD_Deploy\$(BuildNumber).cspkg"

WorkingDirectory="c:\Drops\test\$(BuildNumber)\Release\SeeTheDifference" />



<Message Text =" Copying '$(BuildNumber)'.cspkg to deployment container in Azure " />

<Exec Command ="$(LoadBlobCmd) -upload $(BuildNumber).cspkg"

WorkingDirectory="c:\Drops\SD_Deploy" />

</Target>

以下のスクリーンショットは、blob ストレージにアップロードされた cskpg です。


41

あとは、Cerebreta Cloud Storage Studio などのユーザーフレンドリーなツールを使って、デプロイメン

トを完了させることができます。


42

WINDOWS AZURE プラットフォームでの JAVA の利用

By Rob Blackwell

Windows Azure といった名前を聞けば、Microsoft のクラウドコンピューティングで利用できるのは、

Microsoft の技術だけだと思うのも当然です。実際には、Microsoft のクラウドコンピューティングに

は、オープンな標準や RESTful API を通じて Java の開発者が利用できるものがたくさんあるのです。

WINDOWS AZURE ストレージへの JAVA からのアクセス

WindowsAzure4J は、Windows Azure ストレージに対し、Windows Azure あるいはその他のプラットフ

ォームで実行されている Java アプリケーションからアクセスするための、オープンソースライブラ

リです。JAR ファイルは、http://www.windowsazure4j.org/からダウンロードしてください。依存する

者もいくつか入手する必要があります。

commons-collections-3.2.1.jar

commons-logging-1.1.1.jar

dom4j-1.6.1.jar

httpclient-4.0-beta2.jar

httpcore-4.0.jar

httpcore-nio-4.0.jar

httpmime-4.0-beta2.jar

jaxen-1.1.1.jar

log4j-1.2.9.jar

WindowsAzure4J を使い始めるためには、Windows Azure ポータルからアカウント名とアカウントキー

を入手しなければなりません。blob やキュー、テーブルを使ってみるには、WindowsAzure4j と共に

提供されているサンプルコード中に、それらを貼り付けてください。Eclipse を使っているなら、

Windows Azure Tools for Eclipse http://www.windowsazure4e.org/ もインストールできます。

http://www.windowsazure4j.org/

http://www.windowsazure4e.org/


43

Eclipse で Windows Azure Storage Explore を実行しているところです。

WINDOWS AZURE での JAVA のコードの実行

Windows Azure 上で Java のアプリケーションをホストしたいのであれば、考慮すべきことはたくさん

あります。

まず注意しなければならないのは、利用したい Java アプリケーションが Web アプリケーションだと

しても、Azure の Web ロールを使うことにはならないだろうということだ。Web ロールと Worker ロ

ールとの原則的な違いは、Internet Information Services （IIS）が含まれているかどうかです。ほとんど

の Java の開発者は、Java 用の Web サーバーあるいはフレームワークを使いたいでしょうから、通常

は Worker ロールを利用し、使いたい Web サーバーをデプロイメントパッケージに収めておくのが良

いでしょう。

また、Process.Start 呼び出しによって Java のランタイムを起動するだけの小さな.NET のプログラムか

ら Java をブートストラップしてやる必要もあるでしょう。

Web ロールも Worker ロールもロードバランサーの背後にプロビジョニングされるので、どちらも共

に Web アプリケーションのホストに適しています。Worker ロールでは、ロードバランスされた適切

な Input End Point に Web サーバーを接続する作業が必要になります。従って、例えば公開される

yourapp.cloudapp.net のポート 80 が、Worker ロールのポート 5100 にマップされたりすることになり

ます。


44

以下のコードは、このポートを実行時に決定します。

RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["Http"].IPEndpoint.Port

ありがたいことに、Tomcat Solution Accelerator と AzureRunMe は、どちらもこれらの細かい作業をす

べてやってくれます。

Tomcat Solution Accelerator は、伝統的な Java ベースの Web アプリケーションを利用したい場合に向

いており、Java Servlet と Java Server Pages アプリケーションをサポートしています。これらのアプリ

ケーションは、WAR ファイルとしてパッケージングされていてもかまいません。Tomcat Solution

Accelerator は、http://code.msdn.microsoft.com/winazuretomcat からダウンロードできます。このツー

ルは、アプリケーションとともに Tomcat サーバーと Java のランタイムを含む、Azure クラウドサー

ビスパッケージの生成のプロセス全体を案内します。必要な設定は、自動的に処理されます。できあ

がった cspkg ファイルは、Windows Azure にアップロードして、デプロイが行われるのを待つだけで

す。あとはブラウザを立ち上げて、http://yourapp.cloudapp.com にアクセスしてみましょう。

AZURERUNME

AzureRunme （http://azurerunme.codeplex.com/）は、特定の Web サーバーやフレームワークは想定し

ていません。実際、目に見えるユーザーインターフェースを持たない、単純なコマンドラインアプリ

ケーションだけでも実行できるのです。とはいえ、私は AzureRunme を使って、Restlet

（http://www.restlet.org/）と Jetty（http://jetty.codehaus.org/jetty/）をうまく動かすことができました。

アプリケーションを、USB ドライブから実行することを考えてみましょう。マシンには、何もインス

トールすることができません－Java Runtime Executive（JRE）やすべてのライブラリ JAR ファイル、そ

してあらゆるデータを USB メモリのサブディレクトリに納めておかなければならないのです。おそ

らくは、何かを実行するためには、トップレベルのディレクトリに.BAT ファイルを作成することにな

るでしょう。こんな具合です。

cd MyApp

..\jre\bin\java -cp MyApp.jar;lib\* Start %1

AzureRunme のアプローチは、これに似ています－必要なすべてのファイルを一つの ZIP ファイルに

まとめ、blob ストレージにアップロードします。AzureRunMe cspkg ファイルをダウンロードし、それ

を Java のコードのブートストラップとして利用してください。

バッチファイルがパラメータ%1 を取ることに注意してください－これは、Web サーバーを立ち上げ

たい場合に使われるポートになります－ロードバランサーは、アプリケーションへのすべての HTTP

トラフィックを、このポートに転送します。

AzureRunme には、サービスバスを使って標準出力とすべての log4j のメッセージを、AzureRunme の

利用者のデスクトップマシンのコマンドウィンドウに中継してくれる、Trace listener が含まれていま

す。これを使えば、トレースメッセージを見たり、アプリケーションの処理の進行状況を見たり、例

外メッセージを見たいするのが簡単になります。

http://code.msdn.microsoft.com/winazuretomcat

http://yourapp.cloudapp.com/

http://azurerunme.codeplex.com/

http://www.restlet.org/

http://jetty.codehaus.org/jetty/


45

これは、AppFabric のサービスバスを通じて中継されたメッセージを表示している AzureRunMe の

Trace Listener です。

Microsoft のプラットフォームの相互運用性に関するより詳しい情報については、

http://www.interoperabilitybridges.com/を参照してください。

http://www.interoperabilitybridges.com/


46

モニタリングルール

信頼指示

Scale Agent

第 3 章 : WINDOWS AZURE

WINDOWS AZURE のコンピュートインスタンスの自動スケーリング

By Steven Nagy

始めに

アプリケーションがスケールしなければならない理由はたくさんあります。アプリケーションの中に

は、バッチ処理の走る期間・止まる期間があるもの（例えば夜間にレンダリングを行う会社）もあり、

予想可能なピーク負荷を持つアプリケーションもあり（例えば共有のマーケットアプリケーションで

は、マーケットのオープン時とクローズ時がそうです）、ピーク負荷が予想できないもの（例えば、

Slashdot にリンクされた Web サイト）もあります。

予想可能なピーク負荷を持っている場合、Windows Azure ポータルにログオンして、設定ファイルを

調整して Web ロールや Worker ロールのインスタンス数を増やすことは簡単です。しかし、アプリケ

ーションの負荷が予想外のピークを迎えた場合、アプリケーションには即座に対応してもらわなけれ

ばなりません。世界中から使われるようなアプリケーションの場合、予想もしなかったタイミングで

こういったことが起こります。適切なモニタリングのテクニックを使わなければ、リクエストの処理

にどの程度失敗したかということすら分かりません。一方では、私たちは利用している CPU コアに

対して、時間毎に支払いをしています。従って、遊んでいるインスタンスはスケールダウンできるよ

うにしたいところです。

私たちが知りたいのは、自動スケールを行う方法です。アプリケーションを、賢くしてやらなければ

ならないのです。

基本的なアプローチ

自動スケーリングの絵を描くには、組み合わせなければならないジグソーパズルのピースがたくさん

あります。1 つ目のピースはモニタリングで、これは自動スケールさせなければならないロール群か

ら情報を引き出します。次のピースは、ルールの決定と、スケールアップやスケールダウンの境界値

に対する測定に関するものです。3 番目のピースは、モニタリングを行うサービス（これ以降「Scale

Agent」と呼びます）と、モニタの対象となるロール群との間の信頼関係を確立します。最後に、

Scale Agent は、Windows Azure ポータルに対して、必要に応じてインスタンスの追加や削除を指示し

ます。


47

SCALE AGENT

Scale Agent は、アプリケーションのモニタリングとルールの適用、そして API に対するロールのスケ

ールの指示に対して責任を負うもので、様々な方法でホストすることができます。このエージェント

をホストする方法の一つは、既存の Azure のロール内の個別のプロセスとしてホストするという方法

ですが、あるロールには同じインスタンスがたくさん存在しうるので、エージェントを実行するイン

スタンスをどれにするかを決めなければなりません。そして、エージェントはいくらかの CPU リソ

ースを消費するので、同じロール上で実行されている他の処理を計測する能力に影響が生じるかも知

れません。従って、Scale Agent は標準的な負荷には影響を与えない個別の場所へ移動させ、それ自身

の負荷が負荷の統計を混乱させないようにするのが良いでしょう。

このエージェントは、アプリケーションが処理するメインの処理とは別の Worker ロールとしてホス

トすることもできます。この Worker ロールはスケールする必要がなく、モニタリングの対象となる

コンピュートインスタンス群に、地理的にもデータセンター的にも近いところに配置できると良いで

しょう。そうすれば、ネットワークに対するコストが無駄に発生することなく、処理や計測も高速に

行えます。

エージェントは、完全なオフサイト、例えば自社内のデータセンターで、Windows のサービスとして

ホストすることもできます。これはすなわち、エージェントをより制御しやすくなるということです

が、エージェントとインスタンスとの通信や、パフォーマンスカウンタログの取得、スケールの湖面

どの発行には、やや時間がかかるようになります。

通常は、専用の Worker ロールを使うのが最も優れた選択肢ですが、この後見ていくように、これは

またもっとも信頼関係の設定が難しい選択肢でもあります。

モニタリング：診断情報の取得

スケーリングに関する判断を下せるようになるには、スケールさせたいサービスに関する簡単な統計

情報を知らなければなりません。そうすれば、これらの統計情報に基づいて、状況を知った上で判断

を下すことができます。

診断ヘルパープロセスは、パフォーマンスカウンターの情報をテーブルや blob ストレージに保存し

てくれるので、使うためには Azure ストレージのプロジェクトが必要です。選択できるカウンターは

たくさんありますが、通常はメモリの利用状況、CPU の利用状況、毎秒のリクエスト数をモニターし、

閾値を超えたらスケールアップを行いたいその他の値があれば、それもモニターします。

自動スケールさせたいロールは、自分自身のパフォーマンス情報の収集と、その情報のストレージテ

ーブルへの出力に責任を持たなければなりません。これは、Microsoft.WindowsAzure.Diagnostics 名前

空間にある設定クラスで行えます。

var perfConfig = new PerformanceCounterConfiguration();

perfConfig.CounterSpecifier = @"\Processor(0)\% Processor Time";

perfConfig.SampleRate = TimeSpan.FromSeconds(5);


48

ここでは、追跡したいパフォーマンスカウンター用の設定アイテムを生成します－この例では、CPU

の利用状況に関する情報が必要です。平均利用率は、5 秒毎に収集されます。

続いて、DiagnosticMonitor に追跡させたいアイテムのリストに、このパフォーマンスカウンターを追

加します。DiagnosticMonitor は、仮想マシン上の個別のプロセス内で動作するので、通常のアプリケ

ーションのコードの邪魔はしません。毎分毎に、新しいパフォーマンスカウンター情報が

「DiagnosticsConnectionString」で指定されたストレージアカウントの「WADPerformanceCountersTable」

というテーブルに書き戻されます。テーブルに書き込まれたパフォーマンスカウンターの情報は、サ

ードパーティのツールを使って調べることができます。

var config = DiagnosticMonitor.GetDefaultInitialConfiguration();

config.PerformanceCounters.DataSources.Add(perfConfig);

config.PerformanceCounters.ScheduledTransferPeriod =

TimeSpan.FromMinutes(1);

DiagnosticMonitor.Start("DiagnosticsConnectionString", config);



49

CPU の利用状況を示す「CounterValue」というプロパティを持つエンティティを含むテーブルがある

のが分かるでしょう

すでに良いドキュメントがあるので11、テーブルストレージ内のエンティティを見るのに必要なコー

ドについては、ここでは触れません。Scale Agent は、これらの値を定期的にテーブルをポーリングし

て取得し、利用状況を追跡し、必要であればスケーリングを行います。

ルール：いつスケールするのかの決定

これで Scale Agent は、様々なロールがどのようなレベルにあるのかを、パフォーマンスカウンター

の情報に基づいて知ることができるようになりました。しかし、いつスケールアップ／ダウンするの

かを決めるのは難しいことで、高度な数学の演習課題にさえ簡単になり得ることです。アプリケーシ

ョンによってルールは異なりますが、一般的に考慮すべきことを以下に示します。

通常、Scale Agent がインスタンスを増やす前に負荷が唐突に跳ね上がった場合に備えて、

ある程度の余裕を見ておく必要があります。

スケールアップした直後には、元々いたインスタンス群は、依然として閾値を超え続け

ている可能性があります－もっとスケールしなければならないことがはっきりするだけ

の時間が経過するまでは、エージェントが急いでスケールアップし直さないようにしま

しょう。

すべてのインスタンスからの利用状況を集約しましょう－ある単一のインスタンスの負

荷が突発的に上がったものの、他のインスタンスの負荷が通常の状態なのであれば、実

際にはスケールする必要はありません。

より大奥のインスタンスが必要になった場合、現在利用中のインスタンスの数に基づい

てスケールアップしましょう。例えば、使っているインスタンスが 5 つだけなのであれ

ば、サイドのチェックの前に 2 つのインスタンスを追加すればよい（40%の増加）かも

知れません。50 のインスタンスを使っているのであれば、10 だけ追加すれば良いかも

知れません（20%の増加）。

動作のパターンに基づいて、負荷状況を予測してみましょう。例えば、直近の 15 分間

において、毎秒 5%ずつ負荷が増大し続けているなら、おそらく X 分で閾値を超えるだ

ろうといったことが分かります。スケールする前に、過負荷になって接続の失敗が起こ

るのを、手をこまねいて待っている必要があるでしょうか？この種のパターンを分析す

れば、「ぴったりのタイミングで」スケールアップすることも可能です。

パターンの予測は非常に複雑なことかも知れません－仮に毎日午後 4 時に負荷が増大す

る用であれば、自動スケールが起こるまえに事前にスケールして備えておきましょう。

長時間実行されているリクエストは、誤った判定をもたらす可能性があることに注意し

てください－すべての Web のスレッドがあるインスタンスのために使われており、それ

らのスレッドが IO リクエスト待ちになっている場合、CPU の利用率は低いままになって

しまうので、アプリケーションの性格やアーキテクチャに応じたパフォーマンスカウン

ターに種類について考慮が必要です。

11 http://blogs.msdn.com/jnak/archive/2010/01/06/walkthrough-windows-azure-table-storage-nov-2009-and-later.aspx

http://blogs.msdn.com/jnak/archive/2010/01/06/walkthrough-windows-azure-table-storage-nov-2009-and-later.aspx


50

絶対的な上限－平均的には 3 つのインスタンスだけを使っている場合、そのインスタン

スが 500 インスタンスにまで自動スケールアップできるようにしたいでしょうか？そん

なクレジットカードの請求は受けたくないでしょうか、スケールに関する何らかの絶対

的な上限の設定を設けておくか、適切に警告を出して（SMS やメールなど）、仮にアプ

リケーションが 500 インスタンスにまでスケールしてしまったら、なぜなのかを即座に

オンラインになって確かめられるようにしましょう。

信頼：スケールのための承認

Windows Azure のプロジェクトをコントロールできるように、豊富な管理 API が用意されています。

とはいえ、コマンドを発行するためには、Scale Agent とロール群をホストしているアカウントの API

との間には、信頼関係が結ばれていなければなりません－この信頼関係は、X.509 証明書で確立され

ます。

証明書の生成に関しても、しっかりとしたドキュメントがあります。証明書が生成できたら、3 カ所

に配置しなければなりません。

Windows Azure のアカウント－サービス管理 API が要求に対するチェックを行えるよう

に

コマンドを発行する仮想マシン－この場合、Scale Agent がホストされているところです。

Scale Agent プロジェクトのサービスの設定と定義

管理したいアカウントの Windows Azure ポータルに「Account」タブがあり、拡張子として.CER を持

つ、DER エンコードされた証明書をそこからアップロードできます。

また、拡張子.PFX を持つ個人情報交換フォーマットの証明書と、それに対応するパスワードを、サー

ビスプロジェクトにアップロードし、そのプロジェクトからプロビジョニングされた任意の仮想マシ

ンのインスタンスでその証明書を利用可能にしなければなりません。これは、サービスデプロイメン

トの Certificates セクションにあります。


51

「Manage」をクリックし、.PFX バージョンの証明書をアップロードしてください。これは、サービ

スが利用しているロールのインスタンスに証明書をインストールしているわけではないことは、しっ

かり理解しておいてください。ここでやっているのは、証明書を要求するロールが、この証明書を使

えるようにすることです。リクエストを発行するには、3 番目のステップを完了させて、Scale Agent

のロールに対し、証明書が必要になることを伝えてやらなければなりません。

必要な XML は手入力することもできますが、プロパティペ

ージを使う方がはるかに簡単でしょう。証明書を必要とす

るロール（例えば Scale Agent のロール）をクラウドサービ

スプロジェクトで探し、右クリックしてプロパティを選択

します。プロパティのページで、左側の証明書（Certificate）

部を見つけてください。

先頭の「証明書の追加」を選択し、詳細を入力してください。ここで重要なのは、証明書を正しい

Store Location および Name の下で見つけることです。この画面では、ローカルマシンのストアを使っ

て証明書を検索したので、証明書がローカルにインストールされていることを前提としています。証

明書をローカルにインストールしていないのであれば、サムプリントを手作業でペーストできます。


52

これで、証明書の 3 つの処理が終わりました。ロールを Windows Azure にデプロイすると、そのロー

ルは仮想マシンにインストールされた証明書を、指定されたサムプリントを使って要求します。

スケーリング－サービス管理 API

スケールする必要があることは分かっており、信頼関係も確立できたので、後はコマンドを発行する

だけです。スケールせよ！

すべての API 呼び出しは RESTful ですが、スケールアップやダウンのための API は存在しません。そ

の代わりに、サービスのデプロイメントとは別に管理されているサービス設定ファイルを使ってスケ

ールを行うことができます。ポータルを使えばデプロイメントに対する設定はいつでも変更できます

が、API は単にこの機能に対する機能拡張に過ぎません。

必要なステップは以下の通りです。

1. サービスデプロイメントに対する設定ファイルを要求する

2. スケールしたいロールに対するインスタンス数の XML 要素を見つける

3. 変更を加える

4. サービス API に設定ファイルを投入し直す

自分で直接 REST API を操作したくない場合、Microsoft から提供されているコードサンプルの中に、

スケール12やサービス管理 API

13に関するものがあります。

まとめ

この短い記事では、アプリケーションを状況に応じてスケールアップさせる方法論を紹介しました。

状況に応じたスケーリングだけでなく、ここで紹介したのと同じテクニックを使って、スケジュール

に従ったスケールアップ／ダウンも自動化できますし、予測によるスケールも可能です。

この記事では、自動スケーリングの方法を一つだけ紹介しましたが、派生的な方法や別のアプローチ

もあります。例えば、Scale Agent は診断情報をロールから取得するのに、ロールから情報を送信させ

るのではなく、診断マネージャークラスから取得することもできます。オープンソースのフレームワ

ークである Lokad.Cloud14は、ロール自身が自動スケールできるようにするという、別のアプローチを

取っています。自分の状況に適したアプローチを見つけて、今日から規模の経済を活用しましょう！

12 http://code.msdn.microsoft.com/azurescale

13 http://code.msdn.microsoft.com/windowsazuresamples

14 http://code.google.com/p/lokad-cloud/

http://code.msdn.microsoft.com/azurescale

http://code.msdn.microsoft.com/windowsazuresamples

http://code.google.com/p/lokad-cloud/


53

WINDOWS AZURE でのコンテンツベースのルータサービスの構築

By Josh Tucholski

アプリケーションの中には、リクエストの内容に応じた処理の優先順位付けを必要とする性格のもの

があります。そういったシナリオでは、クライアントからのリクエストを特定のビジネスコンポーネ

ントにルーティングして処理してもらうようなアプリケーション層を開発するのが一般的です。これ

を Windows Azure 上で実装するのは、ロードバランサーが組み込まれていることから、単純には行き

ません。Windows Azure のロードバランサーは、クライアントからアクセス可能な外部へのエンドポ

イントを一つだけしか公開しません。従って、その処理を行っているインスタンスのユニークな IP

アドレスを知る必要があるのです。IP アドレスは、internal とマークされている場合（Web ロールの

プロパティで設定されます）、Windows Azure API で発見可能です。

このチュートリアルは、Windows Azure というよりは WCF の練習課題のように見えるかも知れません

が、キューを使わずにロール間通信をする方法を理解するのは重要なことです。

リクエストをその内容に基づいてフィルタリングするために、内部的な LoadBalancer クラスを作成し

ます。このクラスは、リクエストが生きているエンドポイントにルーティングされ、死んでいるノー

ドには行かないことを保証します。LoadBalancer は、エンドポイントの障害を考慮に入れていなけれ

ばならず、ルーティングテーブルを更新し、処理を行える他のノードにリクエストを渡すことで、洗

練された回復処理が行われることを保証しなければなりません。以下に示す LoadBalancer のクラス定

義は、エンドポイントの検出と、予期しない障害の発生からの回復を行います。

public class LoadBalancer

{

public LoadBalancer()

{

if (IsRoutingTableOutOfDate())

{

RefreshRoutingTable();


54

}

}

private bool IsRoutingTableOutOfDate()

{

//Retrieve all of the instances of the Worker Role

var roleInstances = RoleEnvironment.Roles["WorkerName"].Instances;

//Check current amount of instances and confirm sync with the LoadBalancer’s //record

if (roleInstances.Count() != CurrentRouters.Count())

{

return true;

}

foreach (RoleInstance roleInstance in roleInstances)

{

var endpoint = roleInstance.InstanceEndpoints["WorkerEndpoint"];

var ipAddress = endpoint.IPEndpoint;

if (!IsEndpointRegistered(ipAddress))

{

return true;

}

}

return false;

}

private void RefreshRoutingTable()

{

var currentInstances = RoleEnvironment.Roles["WorkerName"].Instances;

RemoveStaleEndpoints(currentInstances);

AddMissingEndpoints(currentInstances);

}

private void AddMissingEndpoints(ReadOnlyCollection<RoleInstance> currentInstances)


55

{

foreach (var instance in currentInstances)

{

if (!IsEndpointRegistered(instance.InstanceEndpoints["WorkerEndpoint"].IPEndpoint))

{

//add to the collection of endpoints the LoadBalancer is aware of

}

}

}

private void RemoveStaleEndpoints(ReadOnlyCollection<RoleInstance> currentInstances)

{

//reverse-loop so we can remove from the collection as we iterate

for (int index = CurrentRouters.Count() - 1; index >= 0; index--)

{

bool found = false;

foreach (var instance in currentInstances)

{

//determine if IP address already exists set found to true

}

if (!found)

{

//remove from collection of endpoints LoadBalancer is aware of

}

}

}

private bool IsEndpointRegistered(IPEndpoint ipEndpoint)

{

foreach (var routerEndpoint in CurrentRouters)

{

if (routerEndpoint.IpAddress == ipEndpoint.ToString())

{

return true;

}


56

}

return false;

}

public string GetWorkerIPAddressForContent(string contentId)

{

//Custom logic to determine an IP Address from one of the CurrentRouters

//that the load balancer is aware of

}

}

LoadBalancer は、エンドポイントの自動検出を行うことができ、ルーティングのための残りの作業は

WCF です。ルーターは、その定義上、任意のインバウンドのリクエストを受け付け、転送できなけ

ればなりません。IRouterServiceContract は、ベースレベルメッセージクラスですべてのリクエストを

受け付け、すべてのアクションの処理と、それに対するリプライを行います。このクラスのインター

フェースは以下のようになっています。

[ServiceContract(Namespace = "http://www.namespace.com/ns/2/2009", Name = "RouterServiceContract")]

public partial interface IRouterServiceContract

{

[OperationContract(Action = "*", ReplyAction = "*")]

Message ProcessMessage(Message requestMessage);

}

IRouterServiceContract の実装は、これ以降の調査（例えば、メッセージの送信者や、優先順位が付蹴

られているかどうかなど）のために、MessageBuffer クラスを使ってリクエストメッセージのコピー

を生成します。LoadBalancer の GetWorkerIPAddressForContent が呼ばれると、ターゲットのエンドポ

イントが要求されます。エンドポイントを取得すると、ルーターは ChannelFactory を初期化して、そ

のエンドポイントへの接続を生成し、汎用の ProcessMessage メソッドが呼ばれます。最終的には、

ルーターがリクエストを転送するエンドポイントは、メッセージ処理を完了させることができる、詳

細なサービスコントラクトを得ることになります。

public partial class RouterService : IRouterServiceContract

{

private readonly LoadBalancer loadBalancer;

public RouterService()

{

loadBalancer = new LoadBalancer();


57

}

public Message ProcessMessage(Message requestMessage)

{

//Create a MessageBuffer to attain a copy of the request message for inspection

string ipAddress = loadBalancer.GetWorkerIPAddressForContent("content");

string serviceAddress = String.Format("http://{0}/Endpoint.svc/EndpointBasic", ipAddress);

using (var factory = new ChannelFactory<IRouterServiceContract>(new BasicHttpBinding("binding")))

{

IRouterServiceContract proxy = factory.CreateChannel(new EndpointAddress(serviceAddress));

using (proxy as IDisposable)

{

return proxy.ProcessMessage(requestMessageCopy);

}

}

}

}

エンドポイントがアクティブであることを検出し、保証するだけでは道半ばです。残りの半分は、正

しいエンドポイントへリクエストをフィルタリングする際に、どういったパーティショニングの枠組

みが効果的に動作するかを決めることです。あるクライアントからのリクエストが、同じバックエン

ドのコンポーネントで一貫して処理されることが保証されるような何らかの方法を実装するか、ある

いはメッセージの優先順位に基づいてルーティングを行うようにするかを決断しなければなりません。

ここまでに述べたアプローチは、障害に関連するシナリオも考慮し、クライアントからは中断が感じ

られないようにするよう試みています。ハードウェア障害のために、バックエンドのコンポーネント

が突然シャットダウンしてしまったとしても、このロードバランサーの実装は、他のエンドポイント

が利用可能なことを保証します。


58

AZURE BLOB ストレージを利用する BING MAPS TILE サーバー

By Steve Towler

2009 年の初頭を振り返ってみれば、私は顧客の Web サイト用の情報マッピングソリューションの構

築を行うプロジェクトにアサインされていました。このマッピングソリューションは、このプロジェ

クトのための特別に発注された、イギリスのカスタムタイルを提供するものでした。

この地図はイギリスだけをカバーするもので、ズームのレベルは 6 から 11 に限定しなければなりま

せんでしたが、タイルのそれぞれの集合（12 の集合がありました）には、約 4500 のタイルがあり、

サイズは平均 80 メガバイトでした。

1 ギガバイト以下のタイルは、今日気軽に使うことができる莫大なストレージ容量に比べれば、全く

たいしたことがないように思えます。しかし、状況が違ったとすればどうでしょう？顧客が、ヨーロ

ッパ全体をカバーして欲しいと言い出したり、もっと多くのズームレベルも欲しいと言い出したら？

ネットワーク帯域に与える影響や、地図に対する莫大な要求に関連する潜在的なコストはどうなるで

しょう？

Windows Azure は「live」になった今、もし同じプロジェクトが私の本にやってきたら、blob ストレー

ジがこういったタスクには理想的なことから、違った方法で地図のタイルを提供しようとするでしょ

う。ストレージは無限にスケールでき、安価で、RESTful なインターフェースからクリーンかつシン

プルにリクエストすることができるのです。

Bing Map タイルサーバーを、Windows Azure の blob ストレージを使って構築するのは、驚くほど容易

であり、わずかすうステップで、独自のタイルサーバーを立ち上げることができるのです。

最初にやらなければならないことをやりましょう。タイルの処理をしなければなりません。これは、

カスタムの地図の画像を持ってきて、それらをタイルに分割し、マッピングアプリケーションで使え

るようにする処理です。このやり方については、Web 上に多くのチュートリアルがあり、この作業

をするのによく使われるツールには Microsoft MapCruncher があります。

これで「処理済みタイル」ができ、ローカルマシンのディレクトリにそれらを保存できたので、次の

ステップはこれらのタイルをクラウドに持ち込むことです。

簡単にやってしまいたいので、CloudXplorer を使いましょう。これは、Web から入手可能なたくさん

の Windows Azure ストレージ管理ツールの一つです。

CloudXplorer を使って、blob ストレージ中に tiles という公開コンテナを生成します。すべての「処理

済みタイル」を、ローカルマシンから blob ストレージ中の新たに作成したコンテナにコピーしまし

ょう。

http://bit.ly/hdMcs

http://bit.ly/11J6P3


59

コピーが終了したらタイルは以下のような URL で公開されているはずです。

http://myaccount.blob.core.windows.net/tiles/0313131311133.png

（あるいは、ローカルの開発ストレージを使っているのであれば

http://127.0.0.1:10000/devstoreaccount1/tiles/0313131311133.png）

これで、作成するタイルサーバーから、Bing Maps を使ってタイルを利用できます。

MSDN には piece of code（JScript タブを選択してください）があり、これを見れば、Bing マップへの

カスタムタイルのレイヤーの追加方法が分かります。このコードは、必要に応じて修正することがで

きますが、必ず覚えておかなければならないのは、VETileSourceSpecification パスを修正し、

新たに作成する自分のタイルサーバーを指すようにしておくことです。

var tileSourceSpec = new VETileSourceSpecification("lidar",

"http://myaccount.blob.core.windows.net/tiles/%4.png");

この記事の先頭で触れたプロジェクトは成功し、上機嫌の顧客は、積極的に潜在的な顧客に対して、

イギリスにおける自分たちの存在を知らせています。

Windows Azure は CTP を脱しましたが、このプロジェクトはどのように変化するでしょうか？タイル

を利用するプログラムは変わりませんが、タイルを提供するインフラストラクチャがどうなるかは、

間違いなく雲の彼方です。

http://bit.ly/aWC6Ru


60

AZURE ドライブ

By Neil Mackenzie

Azure ドライブは、Azure ストレージのページ blob として永続化された NTFS フォーマットの仮想ハー

ドディスク（VHD）に保存されたデータへのアクセスを提供する、Windows Azure の機能です。1 つ

の Azureno インスタンスは、Azure ドライブとして読み書きするために 1 つのページ blob をマウント

できます。Azure ストレージ blob のリース機能は、2 つ以上のインスタンスが同時に 1 つのページ

blob をマウントしないようにするために使われます。Azure クラウドや開発ファブリックにいないア

プリケーションからは、Azure ドライブをマウントすることはできません。

適切に生成され、フォーマットされた VHD は、それを Azure ドライブとしてマウントする Azure サー

ビスのインスタンスのある場所から、ページ blog にアップロードできます。同様に、ページ blob は

ダウンロードして、ローカルシステムに VHD としてアタッチすることもできます。

Azure SDK は、Microsoft.WindowsAzure.StorageClient 名前空間に Azure ドライブをサポートする 3 つの

クラスを提供しています。

CloudDrive

CloudDriveException

CloudStorageAccountCloudDriveExtensions

CloudDrive は、Azure ドライブのコアの機能を提供する小さなクラスです。CloudDriveException は、

Azure ドライブのエラーを捕捉できるようにします。CloudStorageAccountStorageClientExtensions クラ

スに似ている CloudStorageAccountCloudDriveExtensions は、CloudDrive を構築できるようにする拡張メ

ソッドを CloudStorageAccount に提供します。

ゲスト OS

Azure ドライブを使うには、サービス設定ファイルの osVersion 属性が、WA-GUEST-OS-1.1_201001-01

あるいはそれ以降に設定されていなければなりません。例を以下に示します。

<ServiceConfiguration serviceName="CloudDriveExample" xmlns= "http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osVersion="WA-GUEST-OS-1.1_201001-01">

VHD

Azure ドライブ用の VHD は、単一の NTFS ボリュームとしてフォーマットされた固定サイズのハード

ディスクイメージでなければなりません。この VHD のサイズは、16MB から 1TB の間である必要があ

ります。VHD は、後に 512 バイトのフッターが付けられたデータ部分からなる、単一のファイルです。

例えば、名目上 16MB の VHD は、0x1000000 バイトのデータと 0x200 バイトのフッターからなる

0x1000200 バイトを占めます。VHD をアップロードする際には、フッターのアップロードを忘れない

ようにしましょう。さらに、ページ blob のページ群は 0 で初期化されるので、すべてのバイトが 0

になっているページはアップロードする必要がありません。これによって、大きな VHD をアップロ

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddriveexception.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudstorageaccountclouddriveextensions.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudstorageaccountstorageclientextensions.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.cloudstorageaccount.aspx

http://msdn.microsoft.com/en-us/library/ee758710.aspx


http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration

http://technet.microsoft.com/en-us/virtualserver/bb676673.aspx


61

ードするのにかかる時間が大幅に節約できます。VHD の作成とフォーマットは、Windows サーバー管

理ツールのディスク管理コンポーネントで行えます。

CLOUDDRIVE

CloudDrive オブジェクトは、コンストラクタか、CloudStorageAccount の CreateCloudDrive 拡張メソッ

ドを使って生成できます。例えば以下のようにすれば、cloudDriveUri の URI で指定されるページ blob

リソース内に格納されている VHD から、CloudDrive オブジェクトを生成できます。

CloudStorageAccount cloudStorageAccount = CloudStorageAccount.Parse( RoleEnvironment.GetConfigurationSettingValue("DataConnectionString")); CloudDrive cloudDrive = cloudStorageAccount.CreateCloudDrive(cloudDriveUri.AbsoluteUri);

これで、Azure ドライブのメモリ内のイメージが生成されますが、使うにはそれをマウントしなけれ

ばならないことに注意してください。

Create()は、指定された細部 s の VHD を生成し、ページ blob に保存します。Microsoft が課金するのは、

ページ blob 内の初期化されたページだけなので、VHD の名目上の容量が大きい場合でも、空の VHD

のページ blob には、最小限の課金だけが成されるはずです。Delete()メソッドは、Azure ストレージ

から VHD のページ blob を削除するのに使うことができます。Snapshot()は、VHD を含む VHD ページ

blob のスナップショットを作成しますが、CopyTo()は指定された URL に、VHD ページ blob の物理的

なコピーを作成します。

VHD ページ blob の内容にアクセスするには、Azure のインスタンスがそれをマウントしなければなり

ません。一つの VHD ページ blob は、一度に 1 つのインスタンスからしかマウンドできません。しか

し VHD のスナップショットは、リードオンリーのドライブとしていくつのインスタンスからでも同

時にマウントできます。つまり、スナップショットは大量の情報を複数のインスタンス間で共有する

ための便利な方法なのです。例えば、あるインスタンスがある VHD ページ blob に書き込みのアクセ

ス権を持っている状態で、他のインスタンスにはそのスナップショットにリードオンリーのアクセス

権を持たせることができます－最新のデータにインスタンスがアクセスできるように、定期的に作成

されたスナップショットを使うこともできるのです。

VHD ページ blob をマウントする前には、そのインスタンスのローカルストレージに、いくらかの読

み取りキャッシュ領域を割り当てておく必要があります。これは、キャッシュの機能を使わない場合

でも必要です。

指定したサイズと場所でキャッシュを初期化するには、InitializeCache()を呼びます。以下に、

CloudDrives という名前のローカルストレージの最大のサイズで、Azure ドライブ用のキャッシュを初

期化する例を示します。

public static void InitializeCache() { LocalResource localCache = RoleEnvironment.GetLocalResource("CloudDrives"); Char[] backSlash = { '\\' }; String localCachePath = localCache.RootPath.TrimEnd(backSlash); CloudDrive.InitializeCache(localCachePath, localCache.MaximumSizeInMegabytes); }

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.cloudstorageaccountclouddriveextensions.createclouddrive.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.create.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.delete.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.snapshot.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.copyto.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.initializecache.aspx


62

末尾のスラッシュをキャッシュへのパスから取り除いているのは、Storage Client ライブラリのバグの

回避策です。

インスタンスは、Mount()を VHD ページ blob に対して呼ぶことで、書き込み可能な Azure ドライブを

○とします。Azure ストレージサービスは、ページ blob のリース機能を使って、その VHD ページ

blob への排他的アクセスを保証します。インスタンスは、VHD スナップショットに対して Mount()を

呼ぶことで、リードオンリーの Azure ドライブをマウントします。この場合はリードオンリーなので、

複数のインスタンスが同時に同じ VHD スナップショットをマウントできます。Unmount()を呼べば、

インスタンスは Azure ドライブをアンマウントすることができ、VHD ページ blob は他のインスタン

スから書き込みアクセス可能な状態でマウントできるようになります。

Mount()の cacheSize パラメータは、キャッシュのどれだけをこの Azure ドライブ用にするかを指定し

ます。このドライブにはキャッシュを使いたくない場合、cacheSize は 0 にしなければなりません。

異なる Azure ドライブを一つのインスタンスがマウントした場合、それぞれに異なるキャッシュサイ

ズを指定することができますが、それらのドライブに割り当てたキャッシュサイズの合計は、ローカ

ルストレージで利用可能なキャッシュの量を超えないようにしなければなりません。options パラメ

ータは、列挙値の DriveMountOptions フラグを取ります。このフラグは、ドライブのマウントを強制

するため－例えば、インスタンスが VHD ページ blob のリースを保持したままクラッシュした場合－

あるいは、ファイルシステムを修復するために使うことができます。Mount()は、その Azure ドライ

ブのドライブレターか LocalPath－例えば"d:"など－を返します。この値は、そのドライブ上の任意の

パスにアクセするために使うことができます。

以下のサンプルは、使い始める前に cloudDriveUri で指定された VHD ページ blob からマウントされた

Azure ドライブを表示し、その後にアンマウントします。

public void WriteToDrive( Uri cloudDriveUri ) { CloudStorageAccount cloudStorageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString"); CloudDrive cloudDrive = cloudStorageAccount.CreateCloudDrive(cloudDriveUri.AbsoluteUri);

String driveLetter = cloudDrive.Mount(CacheSizeInMegabytes, DriveMountOptions.None);

String path = String.Format("{0}\\Pippo.txt", driveLetter); FileStream fileStream = new FileStream(path, FileMode.OpenOrCreate); StreamWriter streamWriter = new StreamWriter(fileStream); streamWriter.Write("that you have but slumbered here"); streamWriter.Close();

cloudDrive.Unmount(); }

GetMountedDrives()を使えば、そのインスタンスがマウントしているすべての Azure ドライブのドラ

イブレターのリストにアクセスできます。

DriveInfo クラスは、マウントされた Azure ドライブの情報を取得するのに使えます。この情報のエン

トリポイントは、インスタンスにマウントされているすべてのドライブを表す、DriveInfo オブジェク

トの配列を返すスタティックメソッドの DriveInfo.GetDrives() です。

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.mount.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.unmount.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.drivemountoptions.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.localpath.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.getmounteddrives.aspx

http://msdn.microsoft.com/en-us/library/system.io.driveinfo.aspx

http://msdn.microsoft.com/en-us/library/system.io.driveinfo.getdrives.aspx


63

開発環境

開発環境は、Azure ドライブをクラウド上の実装とは異なるやり方でシミュレートします。さらに、

開発用のストレージのシミュレーションは、Azure ドライブのシミュレーションのことは知らないの

で、Storage Client API の標準的な blob 操作メソッドは、Azure ドライブシミュレーションが利用する、

VHD ページ blog と VHD スナップショットを扱うことができません。その代わりに、CloudDrive クラ

スの blob 管理メソッドを使わなければならないのです。

Azure ドライブシミュレーションは、Azure ドライブを VHD ページ blob からではなく、well-known デ

ィレクトリのサブフォルダー（例えば drivecontainername）中のフォルダー（例えば drivename）に対

して subst を使うことでマウントします。

%LOCALAPPDATA%\dftmp\wadd\devstoreaccount1\

この subst による表現によって表される Azure ドライブのフォルダのフルパスは、以下の用になりま

す。

%LOCALAPPDATA%\dftmp\wadd\devstoreaccount1\drivecontainername\drivename

CloudDrive.Create()あるいは CloudDrive.Snapshot()を呼び出せば、VHD ページ blob あるいは VHD スナッ

プショットの名前で、このディレクトリにフォルダが生成されます。CloudDrive.Delete()は、VHD ペー

ジ blob あるいは VHD スナップショットを削除するのに使えます。VHD ページ blob あるいは VHD ス

ナップショットは blob として保存されるわけではないので、Azure ファブリックからは見えるものの、

開発ストレージの blob のリストには表示されないことに注意してください。結果として、開発スト

レージにアップロードされた VHD ファイルは、Azure ドライブとしてはマウントできません。

回避策としては、VHD を well-knows ディレクトリ内の空のフォルダーにアタッチするという方法が

あります。そこであれば、クラウドの場合と同様にマウントが可能です。Windows サーバー管理ツー

ルのディスク管理コンポーネントを使えば、well-known ディレクトリのサブフォルダー（例えば

drivecontainername）中の空フォルダー（例えば drivename）に対して VHD をアタッチし、クラウドの

場合と同様に、その VHD をマウントすることができます。

これで、Azure ドライブ API を使って、drivename という名前の VHD ページ blob が drivecontainername

というコンテナにある場合と同じように Azure ドライブをマウントできます。Create()メソッドを呼

ぶ必要はありません。開発ストレージには、この blob のエントリはありません。現在マウントされ

ている Azure ドライブのリストを見るためには、コマンドウィンドウから subst を呼べばよいことに

注意してください。

開発環境での Azure ドライブのマウントとアンマウントは、クラウドの場合と同じように行えます。

ただし、開発環境では DriveMountOptions.Force は実装されていません。

Azure ドライブは、Azure ファブリック内でのみ利用可能－それがクラウドであれ、開発環境下であ

れ－であり、通常の Windows アプリケーション内ではマウントできないということは、しっかり覚

えておかなければなりません。


64

NOSQL データベースとしての AZURE テーブルサービス

By Mark Rendle

Windows Azure SDK は、Azure プラットフォームを他の「クラウド」プラットフォーム以上のものにし

ている要素の一つです。特にテーブルサービス SDK は、非常にスケーラブルなストレージサービスを、

LINQ-to-SQL や Entity Framework を使ったことのある人なら誰でもすぐになじむことのできる API にま

とめています。カラム名としては CLR のプロパティ名が使われ、クラス名は（デフォルトでは）テー

ブル名になります。しかし、このシンプルさは、本来スキーマレスであるデータストアに対して、ス

キーマの概念を強制します。

Azure テーブルを生成する場合、カラムは指定しません。テーブルそのものは、カラムを使うような

形で構造化されているわけではありません。カラム名はテーブルに保存されるエンティティ（行）の

一部であり、一つのテーブル内の別々のエンティティは、異なるカラム名を持つことができます。こ

のことから、永続化層についての計画や設計に関して、おもしろい可能性の扉が開かれるのです。

マスター－詳細構造

テーブルサービスは、プライマリー／外部キー、クエリでの結合、あるいは複数テーブル感での修正

を調停するトランザクションといった、リレーショナルな機能はサポートしません。しかし、同じパ

ーティションキーを持つテーブルサービスのエンティティはストア内でまとめて保存され、一つのク

エリによって非常に高速に取得でき、エンティティグループトランザクション15内でまとめて修正す

ることができます。

行はそれぞれ異なる構造を持つことができるので、同じパーティションキーを持つ 2 つ（以上）の種

類の異なるオブジェクトを、同じテーブルに保存することができます。例えば、任意の行数のアイテ

ムを持つ請求書を保存するとしましょう。パーティションキーを請求書番号、空の文字列値を請求書

のエントリの行キー、そしてシーケンシャルな番号を LineItem エンティティの行キーとして使えば、

この「マスター－詳細」データは単一のトランザクション内で生成でき、一つのクエリできわめて高

速に取り出すことができます。

図 1: 単一の Azure テーブルに保存されている、請求書と行アイテム

動的スキーマ

今日のデータベースアプリケーションでは、初期のデータモデルにエンドユーザーが独自のフィール

ドを拡張できるようになっていることがよくあります。リレーショナルデータベースの場合、これは

15 http://msdn.microsoft.com/en-us/library/dd894038.aspx



65

通常複雑なメタデータテーブルのシステムを使って実現されており、従ってこういったカスタムフィ

ールドに対するクエリはひどいものになってしまいます。

Azure では、各エンティティに対して追加のカラム名と値を挿入操作で指定してやれば、これらのフ

ィールドを追加できます。そうすれば、それらのカラムに対するクエリは、元々のアプリケーション

が持っていたカラムに対するのと全く同じ方法で行えます。

しかし注意しなければならないのは、エンティティ毎に完全にカラム名を制御できる REST API では、

このアプローチのために汚い作業をしなければならなくなることです。また、エンティティ毎のプロ

パティ数には、パーティションキーや行キー、タイムスタンプなどのシステムカラムを含めて、255

という絶対的な上限があることにも注意しなければなりません。

データとしてのカラム名

関連する数千行のデータを保存したいことがあります。例えばアクティビティログや、ソーシャルネ

ットワーキングデータベースのユーザー間の関係などがそうです。Azure のテーブルは、この量のデ

ータを非常に容易に扱うことができますが、クエリ操作は結果セット毎に 1,000 行のデータしか返す

ことができず、それらをすべて取得するにはサーバーとのラウンドトリップが何回か必要になるため、

とらんざくしょん操作にかかる時間やコストが増加してしまいます。

ただし、データが単一の文字列やバイナリの blob として保存できれば、カラム名を間に合わせの副

キーとして、250 の「行」をまとめて一つのエンティティに保存しておくことができます。これが可

能なのは、テーブル内で利用可能な異なるカラム名の数には、全く制限がないからです。

これをするのにもっとも良い方法は、空の行キーを使って「アクティブ」なエンティティ、すなわち

データを追加するための予備のカラムを持つエンティティを特定する方法です。加えて、「UniqueId」

という名前で追加のカラムを持たせ、タイムスタンプあるいは Guid の値を保存します。このエンテ

ィティに対して MERGE っこうしんを実行することで、新しい「行」を追加することができます

MERGE 操作が「too many values」で失敗した場合は、同じ UniqueId の値を行キーとして持つそのエ

ンティティのコピーを生成し（行キーは更新できません）、アクティブなエンティティのすべての値

をクリアし、新しい UniqueId を設定することで、アクティブなエンティティをリセットします。こ

うすれば、2 つの並行する操作がこのエンティティの複製を生成してしまうのを避けることができま

す。

図 2: カラム名をデータとして使い、大量のデータを持つテーブルの行数を削減する

データとしてのテーブル名


66

制限のないもう 1 つのものは、アカウントあるいはプロジェクト内に生成できるテーブル数です。そ

して、テーブルにはスキーマを指定する必要はないので、数百のテーブルを作っても問題はありませ

ん。

このことのわかりやすい活用方法の一つは、短期間だけ利用する、大量のデータを持つテーブルが必

要な場合です。おそらくは、数週間でアーカイブされ、クリアされる（ストレージのコストを下げる

ため）ような分析的なデータを保存する場合が相当するでしょう。数百の DELETE 操作を一つのテー

ブルに対して実行するのは、スケーラビリティの問題を引き起こし、トランザクションのコストも高

くなります。しかし、日付を名前の一部として持つ複数のテーブルを持たせ、ある日のデータをクリ

アするのをテーブルの削除だけの問題にしてやれば、すぐ終わる一度の操作で済ませることができて

しまいます。

図 3: テーブル名をデータスキーマの一部として使う

まとめ

おわかりの通り、Azure テーブルストレージにおけるクリエイティブなスキーマ設計の対象範囲は膨

大ですこれは、NoSQL 系データベースのもっとも優れた点の一つです。これまで、厳密に構造化され

たリレーショナルデータベースを使う場合に取り組まなければならなかった問題の多くに対して、構

造化の度合いが低いパラダイムでは、よりシンプルで、直接的なソリューションがあるのです。

公式の Microsoft Azure SDK は、多くの領域におけるモデリングの素晴らしいツールであり、Azure ス

トレージスタックの強力な機能に対して、慣れ親しんだ LINQ の DataContexts やクエリプロバイダー

を持つ非常に使いやすいインターフェースを提供します。この短い記事で、この SDK により深く踏み

込めば可能になる、いくつかのことを照らし出すことができていれば嬉しく思います。あるいは、そ

ういったことは全く無視して、Azure テーブルストレージの NoSQL 的な性質を REST API を使って完全

に利用する方法を学ぶのも良いでしょう。


67

クエリと AZURE テーブル

By Neil Mackenzie

CREATEQUERY<T>()

Azure テーブルに対して、Azure Storatge Client ライブラリを使ってクエリを実行するには、いくつか

のクラスが必要になります。しかし、クエリの処理で中心的な役割を果たすのは 1 つのメソッドで、

それは DataServiceContext クラスの CreateQuery<T>()です。

CreateQuery<T>() の宣言は以下の通りです。

public DataServiceQuery<T> CreateQuery<T>(String entitySetName);

このメソッドは、Storage Client ライブラリを使って Azure テーブルにクエリを実行する際には、暗黙

的あるいは明示的に必ず使われています。CreateQuery<T>()の返す型は DataServiceQuery であり、これ

には IQueryable<T>インターフェースと IEnumerable<T>インターフェースの両方が実装されています。

LINQ は、クエリの結果をフィルタリングする演算子によるクエリの修飾をサポートしています。完

全な LINQ の実装には多くの修飾演算子がありますが、Storage Client ライブラリに実装されているの

は以下のものだけです。

Where

Take

First

FirstOrDefault

これらは、DataServiceQuery<T>クラスの拡張メソッドとして実装されています。クエリが実行される

と、これらの修飾演算子は Azure テーブルサービスに送信される Azure Table Service REST API の$filter

及び$top オペレーターに変換されます。

以下の例は、Songs テーブルから 10 レコードを取得する、CreateQuery<T>() 及び Take()演算子の簡単

な使用例を示しています。

protected void SimpleQuery(CloudTableClient cloudTableClient) { TableServiceContext tableServiceContext = cloudTableClient.GetDataServiceContext();

tableServiceContext.ResolveType = (unused) => typeof(Song);

IQueryable<Song> songs =

(from entity in tableServiceContext.CreateQuery<Song>("Songs") select entity).Take(10);

List<Song> songsList = songs.ToList<Song>(); }

http://msdn.microsoft.com/en-us/library/system.data.services.client.dataservicecontext.aspx

http://msdn.microsoft.com/en-us/library/cc679540.aspx


http://msdn.microsoft.com/en-us/library/bb351562.aspx

http://msdn.microsoft.com/en-us/library/9eekhta0.aspx








68

他の LINQ の実装と同じように、クエリはその結果が列挙されるまでは Azure テーブルサービスには

送信されません。テーブル名がクラス名と異なる場合のパフォーマンスの問題を回避するために、

ResolveType が使われていることに注意してください。

MSDN の Azure のドキュメンテーションには、様々なデータ型－文字列型、数値型、論理型、日付時

刻型など－のプロパティに対するフィルタリングの方法を示す LINQ クエリの例が掲載されているペ

ージがあるので、ここではそれらを繰り返すことはしません。その代わりに、この記事ではクエリを

実行するための様々な方法に焦点を当てていきます。

様々な CONTEXT

SimpleQuery の例は、以下のように TableServiceContext.CreateQuery()を使っています。

tableServiceContext.CreateQuery<Song>("Songs")

この構文は、TableServiceContext の導出クラスを使って以下のように単純化できます。

public class SongContext : TableServiceContext { internal static String TableName = "Songs";

public SongContext(String baseAddress, StorageCredentials credentials) : base(baseAddress, credentials) { }

public IQueryable<Song> Songs { get { return this.CreateQuery<Song>(TableName); } }

public void AddSong(Song song) { this.AddObject(TableName, song); this.SaveChanges(); } }

このクラスは、Songs という名前の Azure のテーブルに格納されたエンティティを表す Song モデルク

ラスに固有のものです。Songs プロパティは、先に使用した

tableServiceContext.CreateQuery<Song>(“Songs”)の代わりに、どんな LINQ クエリの核としても使うこと

ができます。こうすることで、LINQ クエリが単純になり、読みやすさがまします。例えば、次の

LINQ クエリ

from entity in tableServiceContext.CreateQuery<Song>("Songs") select entity

は、songContext が SongContext のオブジェクトだとして、次のように書き換えることができます。

from entity in songContext.Songs select entity

パーティションキーや行キーに対するクエリ

http://msdn.microsoft.com/en-us/library/system.data.services.client.dataservicecontext.resolvetype.aspx




69

Azure テーブルのエンティティの主キーは、パーティションキーと行キーからなります。Azure テー

ブルサービスにおいてもっとも性能の出るクエリは、パーティションキーと行キーを両方指定して、

1 つのエンティティを変えさせるクエリです。パーティションキーを指定し、行キーを指定しないク

エリを処理する場合、Azure テーブルサービスはそのパーティション内のすべてのエンティティをス

キャンしますが、行キーを指定してパーティションキーを指定しないクエリの場合は、それぞれのパ

ーティションに対して個別にクエリを実行しなければなりません。

継続

パーティションキーと行キーの両方を指定するクエリは、結果のすべてが 1 つのレスポンスで返され

るのが保証される唯一のクエリです。クエリに関するその先の制限は、1 つのリクエストに対するレ

スポンスとして返されるのは、最大で 1,000 までだということです－クエリフィルターに適合するエ

ンティティがいくつあっても、これは変わりません。Azure テーブルサービスは、レスポンスヘッダ

に継続トークンを挿入し、継続トークンをパラメータとして使う追加のリクエストによって取得でき

る、まだ取得されていない結果があることを示します。

DATASERVICEQUERY

DataServiceQuery は、Azure テーブルサービスへのクエリを表す WCF Data Services のクラスです。

DataServiceQuery は、Azure テーブルサービスへクエリを送信するための、以下のメソッドを提供し

ます。

public IAsyncResult BeginExecute(AsyncCallback callback, Object state); public IEnumerable<TElement> EndExecute(IAsyncResult asyncResult); public IEnumerable<TElement> Execute();

Execute()は、Azure テーブルサービスへクエリを送信する同期メソッドで、クエリの結果が返される

まではブロックします。BeginExecute()と EndExecute()はペアになるメソッドで、Azure テーブルサー

ビスへの非同期アクセスのための AsyncCallback Delegate モデルの実装に使われます。

Execute()の例を以下に示します。

protected void UsingDataServiceQueryExecute(CloudTableClient cloudTableClient) { TableServiceContext tableServiceContext = cloudTableClient.GetDataServiceContext(); tableServiceContext.ResolveType = (unused) => typeof(Song); DataServiceQuery<Song> dataServiceQuery = (from entity in tableServiceContext.CreateQuery<Song>("Songs") select entity).Take(10) as DataServiceQuery<Song>; IEnumerable<Song> songs = dataServiceQuery.Execute(); foreach (Song song in songs) { String singer= song.Singer; } }

クエリは、IQueryable<Song>を DataServiceQuery<Song>に明示的にキャストしなければならないことに






http://msdn.microsoft.com/en-us/library/ms228975.aspx


70

非同期モデルの実装は、スタティックなコールバックのデリゲートを渡して BeginExecute()を呼び出

します。このとき、呼び出しのコンテキストを提供するオブジェクトを、オプションとしてコールバ

ックのデリゲートに渡すことができます。実際、このオブジェクトには、BeginExecute()の呼び出しの

対象となった DataServiceQuery オブジェクトを含めなければなりません。BeginExecute()は、クエリの

送信を始め、クエリの完了を待つ IO Completion Port をセットアップします。クエリが完了すると、

コールバックのデリゲートが、ワーカースレッド上で呼び出されます。コールバックのデリゲート中

でクエリの結果にアクセスするためには、EndExecute()を呼ばなければなりません。さらに、

EndExecute()の呼び出しが失敗した場合、リソースリークが起こるかも知れません。EndExecute()は、

IEnumerable<T>インターフェースを実装した QueryOperationResponse<T>型のオブジェクトを返します。

QueryOperationResponse<T>は、レスポンスの HTTP ステータスを含む、クエリのリクエスト及びレス

ポンスに関する情報を公開します。

Azure で現在使用されているバージョンの WCF Data Services では、サーバーサイドページングがサポ

ートされておらず、従って DataServiceQuery は継続トークンを処理することができません。次のバー

ジョンは、まだ Azure の環境にはリリースされていません。従って、DataServiceQuery.Execute()は、

1,000 以上の結果がある場合には、リクエストされたすべてのエンティティを取り出せないかも知れ

ません－ただし、実際のところ、パーティションキーと行キーの両方を指定していないクエリで、継

続トークンの必要性はあるのでしょうか？

CLOUDTABLEQUERY

CloudTableQuery<T>クラスは、継続トークンをサポートしています。CloudTableQuery<T>オブジェクト

は、以下の 2 つのコンストラクタから生成されます。

public CloudTableQuery<TElement>(DataServiceQuery<TElement> query,

RetryPolicy policy);

public CloudTableQuery<TElement>(DataServiceQuery<TElement> query);

あるいは、TableServiceExtensionMethods クラスの拡張メソッドの AsTableServiceQuery()を使うことも

できます。

public static CloudTableQuery<TElement> AsTableServiceQuery<TElement> ( IQueryable<TElement> query )

CloudTableQuery<T>クラスは、Azure テーブルサービスへのクエリの送信を処理する、以下の同期メソ

ッドを持っています。

public IEnumerable<TElement> Execute(ResultContinuation continuationToken); public IEnumerable<TElement> Execute();

Execute()は、継続を自動的に処理し、すべての結果が返されるまで、Azure テーブルサービスにクエ

リを送信し続けます。Execute(ResultContinuation)は、以前に取得した、継続トークンをカプセル化し

ている ResultContinuation を含めてリクエストを開始し、すべての結果が取得できるまでクエリの実

行を続けます。クエリが連続した場合、返されるデータの量が莫大になり得るので、どちらの形の

Execute()も実行には注意が必要です。

http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx


http://www.microsoft.com/downloads/details.aspx?familyid=79d7f6f8-d6e9-4b8c-8640-17f89452148e&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=79d7f6f8-d6e9-4b8c-8640-17f89452148e&displaylang=en


http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.tableserviceextensionmethods.aspx



http://msdn.microsoft.com/en-us/library/ff361726.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.resultcontinuation.aspx


71

以下の例は、すべてのレコードをテーブルから取得する Execute()です。

protected void UsingCloudTableQueryExecute(CloudTableClient cloudTableClient)

{

TableServiceContext tableServiceContext =

cloudTableClient.GetDataServiceContext();

tableServiceContext.ResolveType = (unused) => typeof(Song);

CloudTableQuery<Song> cloudTableQuery =

(from entity in tableServiceContext.CreateQuery<Song>("Songs")

select entity).AsTableServiceQuery<Song>();

IEnumerable<Song> songs = cloudTableQuery.Execute();

foreach (Song song in songs)

{

String singer = song.Singer;

}

}

CloudTableQuery<T>クラスには、同等の非同期メソッド群が宣言されています。

public IAsyncResult BeginExecuteSegmented(ResultContinuation continuationToken, AsyncCallback callback, Object state); public IAsyncResult BeginExecuteSegmented(AsyncCallback callback, Object state); public ResultSegment<TElement> EndExecuteSegmented(IAsyncResult asyncResult);

これらは、Storage Client ライブラリの他の部分でも使われているメソッドの命名スタイルに従ってお

り、Segmented というサフィックスは、そのメソッドがデータをバッチで取ってくることを示してい

ます－この場合は、継続トークンを次々と使っていくということになります。これは、クエリの修飾

オペレータの Take()で指定された値か、あるいは単一のリクエストで取得可能な最大レコード数の

1,000 をサイズとするバッチを単位に、結果をページングしていくための便利な方法を提供します。

同期の Execute()メソッドの場合と同じく、2 つの BeginExecuteSegmented()メソッドの違いは、片方は

結果の取得をクエリ結果の先頭から始めるのに対し、もう片方は ResultContinuation パラメータ中の

継続トークンで示されたエンティティから取得を始めるという点です。

以下に示すのは、BeginExecuteSegmented()及び EndExecuteSegmented()を使い、一度に 10 エンティテ

ィずつクエリの結果セットをページングしていく例です。

protected void QuerySongsExecuteSegmentedAsync( CloudTableClient cloudTableClient) { TableServiceContext tableServiceContext = cloudTableClient.GetDataServiceContext(); tableServiceContext.ResolveType = (unused) => typeof(Song);

CloudTableQuery<Song> cloudTableQuery = (from entity in tableServiceContext.CreateQuery<Song>("Songs").Take(10) select entity ).AsTableServiceQuery<Song>(); IAsyncResult iAsyncResult = cloudTableQuery.BeginExecuteSegmented( BeginExecuteSegmentedIsDone, cloudTableQuery); }



72

static void BeginExecuteSegmentedIsDone(IAsyncResult result)

{

CloudTableQuery<Song> cloudTableQuery = result.AsyncState as

CloudTableQuery<Song>;

ResultSegment<Song> resultSegment =

cloudTableQuery.EndExecuteSegmented(result);

List<Song> listSongs = resultSegment.Results.ToList<Song>();

if (resultSegment.HasMoreResults) { IAsyncResult iAsyncResult = cloudTableQuery.BeginExecuteSegmented( resultSegment.ContinuationToken, BeginExecuteSegmentedIsDone, cloudTableQuery); } }

以降の結果を、BeginExecuteSegmented()を ResultContinuation パラメータと合わせて使う代わりに、

ResultSegment<T>クラスの GetNext()メソッドを使ってイテレートしていくこともできます。

上の例で、cloudTableQuery を次のように置き換えることによる違いは、見ておくと良いでしょう。

It is worth noting the difference made by replacing the cloudTableQuery in the above example with:

CloudTableQuery<Song> cloudTableQuery = (from entity in tableServiceContext.CreateQuery<Song>("Songs") select entity).Take(10).AsTableServiceQuery<Song>();

ここで、Take(10)は LINQ のクエリ定義の外にあります。このクエリの結果は、10 レコードだけが取

り出されることになり、先ほどの例とは異なり、10 エンティティ毎のテーブル内のページングは行

われません。

コールバックのデリゲートにおいては、通常のコードに比べて例外処理がより重要になることには注

意してください。これは、それらの例外がユーザーコードから起こされるものではなく、エラーはメ

ソッドの外では捕捉できないためです。従って、すべてのエラーはコールバックのデリゲート内で捕

捉し、処理しなければならないのです。




73

テーブルストレージの時刻及び日付フィールドの保存の小技

By Saksham Gautam

Windows Azure テーブルストレージは、クラウド中のきわめてスケーラブルなテーブルへの、莫大な

量のデータの保存をサポートしています。テーブルには、数十億のエンティティを持つ、何テラバイ

トものデータを保存することができます。このレベルのスケーラビリティを持つために、Windows

Azure テーブルストレージは複数のストレージノードに渡ってエンティティを分散させる、スケール

アウトモデルを採用しています。それぞれのアプリケーションは、エンティティのパーティションキ

ーを選択することで、パーティションの枠組みを決定しなければなりません。加えて、1 つのパーテ

ィション内の各エンティティは、行キーでユニークに識別されなければなりません。この記事では、

この 2 種類のエンティティキーを使って、日付に基づくクエリがより効率的なものになるよう、タイ

ムスタンプの降順のシミュレートする方法について議論します。

パーティションキーと行キーというエンティティキー群は、最大 1KB の文字列です。これらは文字列

なので、すべての比較は純粋に辞書の並び順、例えば“100” < “20” < “9”というように行われます。一

見、時刻からキーを生成するのは単純なことに思えます。「‘yyyyMMddHHmmssfffff’みたいなパター

ンを DateTime に使えばいいだけじゃないか」と読者は言うかも知れません。時刻のそれぞれの構成

要素を固定長にしておけば、辞書順の比較が DateTime の比較と等しいことを保証できるのは確かで

す。しかし、エンティティ群は、テーブル内で昇順に並べられることになります。現実のアプリケー

ションの多くでは、もっとも最近のエンティティから取得していくことが多いので、そういったクエ

リはこの単純な方法を使った場合、どうしても非効率的になってしまいます。例を使って、このこと

をもう尐し詳しく調べてみましょう。

モバイルのユーザーが定期的に Windows Azure の Worker ロールに対して位置情報を送信し、Worker

ロールがテーブルストレージにレポートを記録するような、位置情報ベースのサービスアプリケーシ

ョンを構築することを考えてみましょう‘PositionReport’エンティティは、表 1 のようになるでしょう。

Property DataType

PartitionKey String

RowKey String

DeviceId String

ReportedOn DateTime

Latitude Double

Longitude Double

表 1 PositionReport エンティティのプロパティ

また、ほとんどのクエリは、位置情報を地図に表示するための「デバイス X の最新 100 個の位置情報

レポートを取得する」といったものになるでしょう。昇順のモデルを採用している場合、このクエリ

はまずテーブル（あるいはパーティション）からすべてのエンティティをフェッチし、そして最後の

100 このエンティティを返すことになるでしょう。しかし、必要な 100 個のエンティティだけをフェ

ッチする方法はあるのです。

その手がかりは、ReportedOn プロパティにあります。デバイスがレポートしてきた時刻を、以下の

簡単な方法で「反転タイムスタンプ」に変換しましょう。


74

ここでは、時刻中の‘ticks’の数値を反転させ、固定長にしてやることで、新しいエンティティに対し

て、辞書順では古いエンティティよりも小さくなるようなキーを割り当てる仕組みを作っています。

エンティティの行キーに対してこの方法を使うことができます。そうすれば、デバイスが位置情報レ

ポートを送信してきた時刻を保存するための別のプロパティを持たせる必要はありません。その時刻

は、以下のように RowKey をから簡単に計算できます。結果的に、帯域もいくらか節約できることに

なるわけです。

パーティションキーの第 1 候補は、1 つのデバイスに関するすべてのエンティティが同じパーティシ

ョンに格納されるように、デバイスの ID とするべきでしょう。しかし、仮にデバイスが時間の経過

と共に大量の位置情報レポートを送信してきたとすれば、そのパーティションは非常に大きなものに

なってしまうかも知れません。パーティションキーの選択は、複数サーバー間でエンティティをロー

ドバランスさせる機会です。従って、固定のパーティションキーを選択するより良い方法が、必ずあ

るはずです。RowKey に対して使ったのと同じようなテクニックを、ここでも使うことができるでし

ょう。一般性は失われてしまいますが、あるデバイスの 1 ヶ月のレポートを 1 つのパーティションに

置くことができると仮定しましょう。そうすれば、パーティションキーのための反転タイムスタンプ

は容易に構成できます。以下のようにすればよいでしょう。

これで、デバイスの ID に、デバイスが報告してきた時刻に基づく反転タイムスタンプを連結してや

れば、識別子を生成できます。しかし、まずはデバイス ID が実行したいクエリ中でもっとも重要な

のか、それとも ReportedOn プロパティの方が重要なのかを決めなければなりません。言い換えれば、

クエリのほとんどが「デバイス X の位置情報レポートを取得する」というようなものになるのか、あ

るいはむしろ「一定期間内にレポートを送信してきたデバイスを取得する」といったものになるのか、

ということです。それに基づいて、タイムスタンプあるいはデバイス ID のどちらをパーティション

キーの先頭にするのかを決めることになります。ここでは、デバイス ID を先頭に置くと決めたとし

ましょう。パーティションキーが分かれば、デバイス ID は容易に求められます。こういった連結方

法によるエンティティキーの生成は、デバイス ID が固定長の場合にしかうまくいかないことに注意

してください。

(DateTime.MaxValue.Ticks - reportedOn.Ticks).ToString().PadLeft(19)

new DateTime(DateTime.MaxValue.Ticks - Int64.Parse(RowKey))

DateTime temp = new DateTime(reportedOn.Year, reportedOn.Month, 1);

long ticks = (DateTime.MaxValue.Ticks - temp.Ticks).ToString().PadLeft(19);


75

これで、PositionReport エンティティは表 2 のようになります。

Property DataType

PartitionKey String

RowKey String

Latitude Double

Longitude Double

GetReportedOn() Returns DateTime

GetDeviceId() Returns String

表 2 修正された PositionReport のエンティティ

時間に基づくクエリに関しては、以下の例に示すように、最低でもエンティティキーのどちらか、で

きれば（常に）パーティションキーを含めておくことができます。

1. あるデバイスの当月の最新の 100 個のエンティティ。

A) 当月の初日を基に、デバイス ID と反転タイムスタンプから、複合あーティション

キーを計算する。

B) 行キーに対する大なり演算子 (>)と、1.A で計算した値に対する等号演算子 (=)で、テ

ーブルに対してクエリを行う。

2. あるデバイスの最新の 100 個のエンティティ。

A) あるデバイスに属するエンティティのすべてのパーティションキーは、そのデバイ

ス ID にサフィックスを追加することで生成できることに注意する。従って、テー

ブルストレージにパーティションキーに対する大なり演算子（>）を使ってクエリ

を行う。

B) デバイスの位置情報レポートは 100 に満たないかも知れないので、クエリが返して

くるエンティティには、他のデバイスのものが含まれているかも知れない。それら

は、アプリケーションが結果を利用する前に、データアクセス層で取り除かなけれ

ばならない。

C) テーブルストレージそのものでは、（>）や（<）演算子を使った結果のフィルタリ

ングはせず、その代わりにコード中で結果をフィルタリングするようにしたことに

注意する。これは、この記事の執筆時点では、範囲を指定するクエリをパーティシ

ョンキーに対して実行した場合、すなわちクエリに‘AND’あるいは‘OR’キーワードが

含まれている場合、フルテーブルスキャンが生じてしまうからである。

3. 指定した期間内の、特定のデバイスの最新の 100 個のエンティティ。

A) 1.A と同じように、その期間に対する複合パーティションキーを構築する。

B) その期間に対する反転タイムスタンプを使って、行キーを構築する。

String deviceId = PartitionKey.Substring(0, PartitionKey.Length - 19);


76

C) 2.C で述べたとおり、すべてのキーを単一のクエリ中で使うのは非効率的なので、2

つのクエリを作成し、片方でパーティションキーを使い、もう片方で行キーを使う。

D) 2 つのクエリを実行し、それらをアプリケーションで使う前に結合（union）する。

多くの場合、反転 ticks をエンティティキーで使えばことは足りるはずです。とはいえシナリオによ

っては、あまりに大量のデータが生成され、ここで述べた方法でエンティティキーを計算すると、同

じキーを保つエンティティが複数できてしまうかも知れません。‘Events’テーブルに‘Event’エンティテ

ィを追加する複数のプロセスを持つアプリケーションの例を考えてみましょう。‘Event’エンティティ

は、表 3 のようになるでしょう。

Property DataType

PartitionKey String

RowKey String

EventType Int

Description String

GetEventSource() Returns String

GetEventTime() Returns DateTime

表 3 Event エンティティの構造

パーティションキーにはイベントの発生源に基づく、例えばイベントを発生させたプロセスの名前を

使い、行キーにはイベントの発生時刻を使います。全く同じ時刻にテーブルに対して書き込みを行う

同じ名前のプロセスが複数あった場合、どちらのパーティションキーと行キーも同じになってしまう

ので、問題が生じます。こういったエンティティキーの衝突を回避する方法は、グローバルユニーク

識別子（GUID）を行キーの末尾に追加することです。行キーはそのように計算すればよいでしょう。

クエリを実行する際には注意が必要です。行キーは直接 ticks には対応しなくなってしまっているの

で、行キーに対して<=や>=といった演算子を使うのは正しくありません。時刻 T に発生したすべての

イベントを取得するには、行キーに変換した T と(t + 1 tick)をクエリ中の where 条件で使います。

すでに行キーとして反転タイムスタンプだけを使っているテーブルに対して、このテクニックが使え

るかを疑問に思う人があるかも知れません。短い答は、使えます！というものです。すでに議論した

とおり、エンティティキーの比較は純粋に辞書の並び順に基づいています。3 つの文字列 A、B、C が

ある場合、辞書の並び順で A < B < C が成立しているなら、それぞれにサフィックスを付けたとしても、

並び順には影響しないのです。

String revTicks = (DateTime.MaxValue.Ticks – eventTime.Ticks).PadLeft(19);

RowKey = revTicks + Guid.NewGuid().ToString();


77

WORKER ロールを使った分散キャッシュの実装

By Josh Tucholski

意欲的なアプリケーションにもっとも求められるゴールの 1 つである爆発的な成長は、アプリケーシ

ョンが実際に予期せずその状態になったときに、もっとも簡単に失敗する展開の 1 つでもあります。

Windows Azure は、爆発的成長の問題に対して、スケーラブルなインフラストラクチャによってスケ

ールし、素早く追加のサービスインスタンスを必要に応じて割り当てることで対処します。しかし、

トラフィックとアプリケーションの利用頻度が高まるにつれて、何らかのキャッシュ層なしでは、デ

ータベースに問題が生ずることは避けられません。

小さな環境では、効率よくデータを取り出すにはサーバーに組み込まれているキャッシュを使うだけ

で事足りますが、Windows Azure の場合はそうはいきません。Windows Azure は、透過的なロードバ

ランサーを提供しているので、特定のサーバーにデータを配置するのは、各ユーザーが同じ Web サ

ーバーに対して継続的に通信することを保証しない限り、実際的ではないのです。分散キャッシュを

装備し、うまく構築されたデータアクセス層があれば、あらゆるクライアントから発行される同じデ

ータリクエストに対して、データベースからの取得は一度だけしか行われず、それ以降はキャッシュ

されたデータが使われることを保証することで、この問題に対処できるのです（更新は別です）。

キャッシュの設定

もっとも普及している分散キャッシュの実装は、YouTube、Facebook、Twitter、Wikipedia で使われて

いる memcached です。memcached は、実行可能なプログラムとしてコマンドラインから実行するこ

ともできるので、Windows Azure の Worker ロールでも完璧に利用できます。memcached が動作して

いる間、データはメモリ内に保存されているので、Worker のインスタンス数を増やせば、キャッシ

ュのサイズも大きくなります。

以下のコードスニペットでは、Worker ロールが memcached のプロセスを初期化し、必要なパラメー

タを定義して、ユニークなインスタンスの IP アドレスと、MB 単位でキャッシュの最大サイズを指定

しています。

注意：このプロセスを Windows Azure の AppFabric で起動するのに、memcached の実行ファイルを持

たせる必要はありません。

//Retrieve the Endpoint information for the current role instance

IPEndPoint endpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["EndpointName"].IPEndpoint;

string cacheSize = RoleEnvironment.GetConfigurationSettingValue(CacheSizeKey);

//memcached arguments

//m = size of the cache in MB

//l = IP address of the cache server

//p = port address of the cache server

string arguments = "-m " + cacheSize + " -l " + endpoint.Address + " -p " + endpoint.Port;

http://jehiah.cz/projects/memcached-win32/


78

ProcessStartInfo startInfo = new ProcessStartInfo()

{

CreateNoWindow = true,

UseShellExecute = false,

FileName = "memcached.exe",

Arguments = arguments

};

//The worker role’s only purpose is to execute the memcached process and run until shutdown

using (Process exeProcess = Process.Start(startInfo))

{

exeProcess.WaitForExit();

}

分散キャッシュの利用

分散キャッシュのインスタンスがアクティブになったら、Enyim のようなクライアントライブラリを

使ってキャッシュの内容にアクセスできます。Enyim を分散キャッシュに統合するにあたって、もっ

とも難しいのは、アクセス可能なキャッシュのエンドポイントをすべて特定することです。ありがた

いことに、Windows Azure の API を使えば、内部的なエンドポイントは Worker ロールの名前で発見可

能です。クライアントの知っている値と、実際の Worker ロールのインスタンス数が、ある時点で同

期できていないことを判別するためのフックを設定し、自動的にリフレッシュさせることもできます。

Windows Azure Memcached Solution Accelerator にある Web ロールには、うまく書かれた Enyim クライ

アントの実装があり、それを見れば設定の検出方法が分かるでしょう。以下のコードスニペットは、

設定インターフェースが実装できてしまえば、キャッシュのデータの取得と設定が非常に簡単になる

ことを示しています。

//See the Windows Azure Memcached Solution Accelerator for instructions on implementing

//the AzureMemcachedClientConfiguration class

private static AzureMemcachedClientConfiguration _configuration;

//MemcachedClient is provided through Enyim

private static MemcachedClient _client;

private static MemcachedClient Client

{

get

{

EnsureClientUpToDate();

return _client;

http://github.com/enyim/EnyimMemcached/downloads

http://code.msdn.microsoft.com/winazurememcached


79

}

}

private static void EnsureClientUpToDate()

{

//If a configuration exists, confirm that the endpoints it is

//aware match the ones in Windows Azure

if (_client == null || _configuration == null || _configuration.IsOutOfDate)

{

_configuration = new AzureMemcachedClientConfiguration();

_client = new MemcachedClient(_configuration);

}

}

public object Get(string key)

{

//The client serves four key purposes: retrieval, storage, removing, and flushing the cache

object val = Client.Get(key);

return val;

}

public void Put(string key, object value)

{

//Stores the key/value pair in the distributed cache using the client

//Available StoreMode operations

//Add – adds the item to the cache only if it does not exist

//Replace – replaces an item in the cache only if it does exist

//Set – will add the item if it does not exist or replace it if it does

if (!Client.Store(StoreMode.Set, key, value, DateTime.UtcNow.AddSeconds((double)_expiry)))

{

Console.WriteLine("MemcachedCache - could not save key " + key);

}

}

いったんクライアントが実装できてしまえば、アプリケーション中でそのクライアントにアクセスす

る部分は、分散キャッシュと統合できます。例えば nHibernate のような、ある種のオブジェクト－リ

レーショナルマッピングツールは、キャッシュプロバイダーのサポート機能まで持っています。この

点からは、新しいキャッシュプロバイダーを構築し、Windows Azure の分散キャッシュと統合するの


80

がシンプルです。他のライブラリを分散キャッシュと結合する場合、名前の衝突を避けるためにオブ

ジェクトのキーはハッシュして置くことをお勧めします。

分散キャッシュの実装は、アプリケーションがデータの入出力を制御している限り、ほとんどのシナ

リオでメリットがあることが証明されています。外部のリソースがデータベースに直接通信してデー

タを修正する場合は、分散アプリケーションのアーキテクチャを再考するか、せめてキャッシュの内

容の無効化を頻繁に行い、その内容が古くならないことを保証する必要があるでしょう。Windows

Azure では、インスタンスを追加したり、システム障害からの回復が行われたりしても、分散キャッ

シュは高い可用性を保ち、動作が中断することは決してないでしょう。


81

WINDOWS AZURE アプリケーションのロギング、診断、健全性のモニタリング

By David Gristwood

アプリケーションの健全性のモニタリングは、アプリケーションを動作状態に保ち、もし問題があれ

ばその解決を支援するためのキーです。多くの開発者は、オンプレミスのアプリケーションであれば、

一般的なアプリケーションやサーバーのメンテナンスの一部として、それをどうやったらいいのかを

ある程度知っています。しかし、クラウド内で実行される Azure のアプリケーションに関しては、モ

ニタリングや診断の実行のやり方は、伝統的なアプリケーションの場合とは多くの理由で大きく異な

ります。まず、アプリケーションは、Windows Azure ファブリックによって管理される複数のマシン

の集合によって実行され、動的かつ利用時間に対して課金が行われるので、単一のマシンの場合に比

べて問題ははるかに複雑になるのです。次に、マシンを自分で保有し、管理している場合のような形

態では、Windows Azure で動作しているマシン群に対する直接的なシステム管理のアクセスはできま

せん－ロールやマシンのデプロイや管理の複雑な処理のほとんどをまかなっているのは Windows

Azure ファブリックであり、Windows Azure ファブリックはリソースへの低レベルのアクセスは提供

していないのです。そして最後に、クラウドにデバッガをアタッチして、コードをステップ実行する

といったことは、単純にはできないのです。

ありがたいことに、Windows Azure には診断機能があり、Azure のアプリケーションを構成する様々

なロールにまたがってアプリケーションの健全性をモニターすることができます。これは、新しい

API が作成されたというようなことではありません－むしろこれは、多くの開発者がすでに慣れ親し

んでいる、Windows プラとフォームの既存のロギング及びトレース機能と、それらを使ったモニタリ

ング方針を構築することによる、デバッギングやトラブルシューティング、パフォーマンス、リソー

スの理世状況のモニタリング、トラフィック解析、キャパシティプランニング、監査といったシナリ

オへの対処に関することなのです。

Windows Azure の診断機能の利用には、主要な段階が 3 つあります。まず、収集したい診断データを

決定します。次に、いつどの診断データを解析のために Windows Azure から保存するかを決定します。

そして最後に、Windows Azure からデータをダウンロードして解析します。

診断データの収集

収集すべきもっとも一般的な診断データの 1 つは Windows Azure ログで、アプリケーションに組み込

まれている System.Diagnostics.Trace メッセージがここに出力されます。これらのトレースメッセージ

は、アプリケーションの動きと状態のログを記録するための中心的な方法で、既存の Event Tracing

for Windows （ETW）機能の上に構築されています。デフォルトでは、このトレースデータと、IIS 7.0

のログ、そして Windows Diagnostic インフラストラクチャのログは、診断機能を有効にすればいずれ

も収集されます。Windows Diagnostic インフラストラクチャのログは、Windows の構成要素に関する

一般的な問題の検出やトラブルシューティング、解決を支援します。

診断機能は、ロールの OnStart()メソッドによって初期化されます。

public override bool OnStart()

{

var config = DiagnosticMonitor.GetDefaultInitialConfiguration(); // Get default initial configuration


82

// add any other data sources here that need to be tracked are added here


追加のデータソースは、Start()メソッドが呼ばれる前であれば DiagnosticsMonitor に追加できます。診

断に関しては、クラッシュダンプや Windows のイベントのログの価値は計り知れません。精密なチ

ューニングや、キャパシティプランニングに関しては、パフォーマンスカウンター（CPU、メモリ、

ページングなどが含まれます）が欠かせません。

診断データの保存

収集されたすべての診断データは、Windows Azure ファブリック内の仮想マシンのローカルファイル

ストアに保存されています。マシンがリサイクルされたり再構築されたりすると、ローカルファイル

ストアは失われてしまうので、診断データは Windows Azure ストレージのような永続化ストアに転送

しておかなければなりません。この転送は、通常のスケジュールイベントとして、おそらくは 10 分

程度ごとに実行することもできますし、必要に応じて実行することもできます。

スケジュール転送の設定は簡単で、DiagnosticMonitor.Start()を呼び出す前に、適切なデータソースの

ScheduledTransferPeriod プロパティを設定するだけです。

// schedule transfer of basic logs to Azure storage

diagConfig.Logs.ScheduledTransferPeriod = System.TimeSpan.FromMinutes(1.0);


必要に応じた転送は、Windows Azure のアプリケーションの外から行うこともできるので、ダッシュ

ボードやシステムサポート用のアプリケーションからデータの永続化の制御ができます。

診断データの解析

転送された診断データは、デフォルトでは一連の「wad」（Windows Azure Diagnostics）が先頭につい

た Windows Azure のテーブルと blob コンテナーに（クラッシュダンプは blob ストレージに、

Windows Azure ログはテーブルに、といった具合です）保存されます。これらはその後、Cerebrata の

Azure Diagnostic Manager（スクリーンショットを参照してください）のようなツールを使ってオンラ

インで調べたり、REST ベースの API を通じてダウンロードし、ローカルで内容を見て解析したりする

ことができます。


83

より複雑な問題の解析、チューニング、解決のためには、ログやトレース情報を SQL Server に保存す

ることで、関連する情報のフィルタリングや、プロセスの流れや例外の検出を容易にできます。デバ

ッギングやモニタリングのシナリオに関して重要なのは、高品質の情報をアプリケーションに埋め込

んでおくことです。特に、複数のマシンやロールにまたがる流れの追跡を支援するための情報は重要

です。

詳細な情報

Matthew Kerner の素晴らしい PDC09 のセッション http://microsoftpdc.com/Sessions/SVC15 と、そこで

のデモが http://code.msdn.microsoft.com/WADiagnostics からダウンロードできます。MSDN のドキュ

メンテーションは http://msdn.microsoft.com/en-us/library/ee758705.aspx にあります。

http://microsoftpdc.com/Sessions/SVC15

http://code.msdn.microsoft.com/WADiagnostics



84

WINDOWS AZURE のサービスランタイム

By Neil Mackenzie

ロールとインスタンス

Windows Azure は、ロールという概念を通じて Platform as a Service の実装しています。ロールには、

IIS とともにデプロイされる Web ロールと、Windows のサービスに似た Worker ロールの 2 種類があ

ります。Azure は、複数のロールのインスタンスをデプロイすることで、サービスの水平なスケーリ

ングを実現しています。ロールの各インスタンスには、いくつかのサイズ－1 コアの小さなインスタ

ンスから、8 コアの非常に大きなインスタンスまで－の中から選択された VM が専用に割り当てられ

ます。メモリやローカルのディスク領域も、インスタンスサイズに合わせて大きくなります。

すべてのインバウンドのネットワークトラフィックは、ステートレスなロードバランサーを通過しま

す。このロードバランサーが、ロールのインスタンスからインバウンドのコールを渡すロールを選択

するためのアルゴリズムは、公開されていません。ここのインスタンスは公開 IP アドレスは持って

おらず、インターネットから直接特定することはできません。インスタンスは、同じサービス内の他

のインスタンスには、TCP および HTTP を通じて直接接続できます。

Azure は、ライブ環境でのテスト用のステージングと、実働サービスのためのプロダクションという、

2 つのデプロイメントスロットを提供しています。公開エンドポイントを持つロールは、恒久的な

URL をプロダクションスロットに、一時的な URL をステージングスロットに持ちます。それ以外には、

この 2 つのスロットに実際の違いはありません。

エンドポイント

Azure のロールは、公開されている入力エンドポイントと、インスタンス間の通信のためのプライベ

ートな内部エンドポイントという、2 種類のエンドポイントを持ちます。入力エンドポイントと内部

エンドポイントは、サービス定義ファイル内の指定によって、Azure のロールと関連づけられます。

Web ロールは、HTTP 入力エンドポイントと、HTTPS 入力エンドポイントをそれぞれ 1 つだけ持つこ

とができます。Worker ロールは、それぞれが異なったポート番号に関連づけられている限りにおい

て、HTTP、HTTPS、TCP の入力エンドポイントをいくつでも持つことができます。外部のサービスは、

ロールの仮想 IP アドレスと、サービス定義ファイルでロールに指定された入力エンドポイントのポ

ートへ、接続要求をすることができます。これらの接続要求はロードバランスされ、ロールのインス

タンスの 1 つに Azure が割り当てたポートに転送されます。

Web ロールが持てる HTTP 内部エンドポイントは 1 つだけです。Worker ロールは、HTTP および TCP

の内部エンドポイントをいくつでも持つことができます。唯一の制限は、それぞれの内部エンドポイ

ントはユニークな名前を持たなければならない、ということだけです。

サービスのアップグレード

Azure サービスの upgrade の方法には、インプレースアップグレードと、Virtual IP（VIP）スワップの

2 種類があります。インプレースアップグレードは、デプロイメントスロットの内容を、新しい



85

Azure のアプリケーションパッケージと設定ファイルで置き換えるものです。VIP スワップは、プロ

ダクション及びステージングスロットに割り当てられた仮想 IP アドレスを、単純に交換するもので

す。注意しなければならないのは、新しいアプリケーションパッケージでサービス定義ファイルが修

正されている場合、インプレースアップグレードはできないことです。その代わりに、どちらかのス

ロットにある既存のサービスを、新しいバージョンをアップロードする前に削除しておかなければな

らないのです。VIP スワップは、サービス定義ファイルの修正をサポートしません。

Azure の SLA は、サービスがロール毎に最低 2 つのインスタンスを使わない限りは有効ではありませ

ん。Azure は、SLA への準拠のために、アップグレードドメインとフォールトドメインを使用します。

Azure ファブリックは、いくつかのアップグレードドメインに対してインスタンスをデプロイします。

Azure ファブリックは、ある単一のアップグレードドメイン内のすべてのインスタンスを停止させ、

アップグレードし、再起動するしてから次のアップグレードドメインへ処理を進めることで、1 つの

ロールのインプレースアップグレードを実行します。アップグレードドメイン数は、サービス定義フ

ァイルの ServiceDefinition ルート要素の upgradeDomainCount 属性（デフォルトは 5 です）によって設

定できます。Azure ファブリックは、アップグレードドメインへのインスタンスの割り当てを完全に

制御しますが、Azure のサービスからは、RoleInstance.UpdateDomain プロパティを通じてサービスの

各インスタンスの属するアップグレードドメインを見ることができます。

Azure のインスタンスがデプロイされると、Azure ファブリックはそれらを異なるフォールトドメイ

ンに分散させます。これは、一台のハードウェアの障害が、すべてのインスタンスをダウンさせてし

まうことがないようにデプロイするということです。Azure ファブリックは、フォールトドメインへ

のインスタンスの配分を完全に制御しますが、Azure のサービスからは、RoleInstance.FaultDomain プ

ロパティを通じてサービスの各インスタンスの属するアップグレードドメインを見ることができます。

サービス定義とサービス設定

Azure のサービスは、そのサービス定義ファイルとサービス設定ファイルによって定義及び設定され

ます。サービス定義ファイルは、サービス内に含まれるロールを指定します。それぞれのロールには、

以下の項目も指定されます。

upgradeDomainCount - サービスのアップグレードドメイン数

vmsize - Small から ExtraLarge の間で指定するインスタンスサイズ

ConfigurationSettings - サービスを設定するのに使われる設定情報の定義

LocalStorage- ローカル VM 上のディスク領域の容量と名前の指定

InputEndpoints - ロールの外部エンドポイントの定義

InternalEndpoint - ロールの内部エンドポイントの定義

Certificates - X.509 証明書ストアの名前と場所の指定

サービス設定ファイルは、以下の設定値を提供します。

osVersion - デプロイされたサービスに対する Azure の guest OS version の指定

Instances - ロールのインスタンス数の指定

ConfigurationSettings - ロール固有の設定パラメータの指定

Certificates - ロールの X.509 証明書の指定

http://www.microsoft.com/downloads/details.aspx?FamilyID=72193dd2-eeaa-4054-93f6-f6b725cf76af&displaylang=en


http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.updatedomain.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.faultdomain.aspx







86

サービス設定ファイルは、サービスアプリケーションパッケージの異なる 2 つの部分の内の 1 つを含

んでおり、従ってインプレースアップグレードで修正できます。サービス設定ファイルはまた、

Azure ポータルから直接修正することもできます。

ROLEENTRYPOINT

RoleEntryPoint は、Azure ファブリックに対してロールへのエントリーポイントを提供するベースクラ

スです。すべての Worker ロールは、RoleEntryPoint から導出されたクラスを持たなければなりません

が、Web ロールはその代わりに ASP.Net ライフサイクルマネージメントを使うことができます。標準

的な Visual Studio のロールテンプレートは、必要な導出クラスのスターター実装を提供しています。

RoleEntryPoint は以下のように宣言されています。

public abstract class RoleEntryPoint { protected RoleEntryPoint();

public virtual Boolean OnStart(); public virtual void OnStop(); public virtual void Run(); }

Azure ファブリックは、オーバーライドされた OnStart()メソッドを呼び出して、ロールを初期化しま

す。この呼び出しが行われる前は、ロールのステータスは Busy になっています。Web ロールでは、

OnStart()の代わりに Application_Start に初期化のコードを置けることに注意してください。オーバー

ライドされた Run()は、OnStart()が成功して終了した後に起動され、ロールのメインの処理スレッド

を提供します。インスタンスは Run()が終了した時点で自動的にリサイクルされてしまうので、Run()

メソッドが終了したりしないよう、例えば Thread.Sleep()を使うといった注意が必要です。Azure は、

ロールの通常の一時停止状態において、オーバーライドされた OnStop()を呼びます。Azure ファブリ

ックは、OnStop()が 30 秒以内に制御を戻さなければ、自動的にロールを停止させます。Web ロール

では、OnStop()の代わりに Application_End 中にシャットダウンのコードを置けることに注意してくだ

さい。

ROLE

Role クラスは、Azure サービスのロールを表します。このクラスは、ロールの名前と、そのロールに

デプロイされたインスタンス群のコレクションを公開します。

ROLEENVIRONMENT

RoleEnvironment クラスは、インスタンスが Azure ファブリックとやりとりする機能を提供します。

加えて、サービス設定ファイルへのアクセスと、サービス定義ファイルへの限定的なアクセスを提供

する機能も提供します。

RoleEnvironment は、以下のように宣言されています。

public sealed class RoleEnvironment { public static event EventHandler<RoleEnvironmentChangedEventArgs> Changed; public static event EventHandler<RoleEnvironmentChangingEventArgs> Changing; public static event EventHandler<RoleInstanceStatusCheckEventArgs>

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleentrypoint.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleentrypoint.onstart.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleentrypoint.run.aspx

http://msdn.microsoft.com/en-us/library/system.threading.thread.sleep.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleentrypoint.onstop.aspx

http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/6632bb55-1b3d-4323-87a4-12a70a72b2ab/

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.role.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.role.name.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.role.instances.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.aspx


87

StatusCheck; public static event EventHandler<RoleEnvironmentStoppingEventArgs> Stopping; public static RoleInstance CurrentRoleInstance { get; } public static String DeploymentId { get; } public static Boolean IsAvailable { get; } public static IDictionary<String,Role> Roles { get; }

public static String GetConfigurationSettingValue( String configurationSettingName); public static LocalResource GetLocalResource(String localResourceName); public static void RequestRecycle(); }

IsAvailable プロパティは、Azure の環境が利用可能かどうかを示します。DeploymentId は、現在のデ

プロイメントを識別し、Roles は現在のサービスを含むロール群を特定し、CurrentRoleInstance は現在

のインスタンスを表す RoleInstance オブジェクトです。Roles は、現在のインスタンスと、内部エン

ドポイントを持つインスタンス以外は、すべてのインスタンスをサイズが 0 であると報告することに


GetConfigurationSettingValue()は、現在のロールの設定を、サービス設定ファイルから取得します。

GetLocalResource()は、サービス定義ファイルで定義された、現在のロールの任意のローカルストレー

ジのルートパスを指定する LocalResource オブジェクトを返します。RequestRecycle()はリサイクルを

開始します。すなわち、現在のインスタンスの停止と起動を行います。

RoleEnvironment クラスは、Azure の環境に関する様々な変化を通知するコールバックメソッドをロー

ルが登録できる、4 つのイベントを提供します。ロールは通常、自分の OnStart()メソッド内でこれら

のイベントに対してコールバックメソッドを登録します。

StatusCheck イベントは、15 秒毎に発生します。インスタンスは、RoleInstanceStatusCheckEventArgs ク

ラスの SetBusy()メソッドを使って、自分がビジーであり、ロードバランサーのローテーションから除

外されるべきであることを示すことができます。Stopping イベントは、インスタンスが制御されたシ

ャットダウンの実行中になると発生するイベントですが、処理されないエラーのためにインスタンス

がシャットダウンされる場合には、このイベントが生ずる保証はありません。Stopping イベントは、

オーバーライドされた OnStop()が呼ばれる前に発生することに注意してください。

Changing イベントは設定変更がロールに適用される前に、Changed イベントは適用された後に発生し

ます。Changing イベントのコールバックメソッドは、設定情報の古い値にアクセスでき、設定の変更

に応じてインスタンスを再起動するかどうかを制御するために使うことができます。Changed イベン

トのコールバックメソッドは、設定情報の新しい値にアクセスすることができ、変更に応じてインス

タンスを再設定するために使うことができます。Changing および Changed コールバックメソッドは、

ロールのインスタンス数の変更を伴う、サービスに対するトポロジーの変更を処理するのにも使うこ

とができます。

ROLEINSTANCE

RoleInstance クラスは、ロールのインスタンスを表します。宣言は以下の通りです。

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.isavailable.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.deploymentid.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.roles.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.currentroleinstance.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.getconfigurationsettingvalue.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.getlocalresource.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.localresource.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.requestrecycle.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.statuscheck.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstancestatuscheckeventargs.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstancestatuscheckeventargs.setbusy.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.stopping.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changed.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changed.aspx


88

public abstract class RoleInstance { public abstract Int32 FaultDomain { get; } public abstract String Id { get; } public abstract IDictionary<String,RoleInstanceEndpoint> InstanceEndpoints { get; } public abstract Role Role { get; } public abstract Int32 UpdateDomain { get; } }

FaultDomain と UpdateDomain は、それぞれこのインスタンスのフォールトドメインとアップグレー

ドドメインです。Role は、ロールとロールのインスタンスをユニークに識別する Id を特定します。

InstanceEndpoints は、サービス定義ファイルで指定されているインスタンスの各エンドポイントに、

実際の RoleInstanceEndpoint の定義をリンクする IDictionary<>です。ロールの各インスタンスは、サー

ビス定義ファイル中で定義されている個々のインスタンスエンドポイントに対して、個別に実際の

RoleInstanceEndpoint を持っていることに注意してください。

ROLEINSTANCEENDPOINT

RoleInstanceEndpoint クラスは、インスタンスに関連づけられた入力エンドポイントあるいは内部エ

ンドポイントを表します。このクラスは、エンドポイントに関連づけられたインスタンスを特定する

RoleInstance と、インスタンスのローカル IP アドレスおよびエンドポイントのポート番号を含む

IPEndpoint の、2 つのプロパティを持ちます。

LOCALRESOURCE

LocalResource は、ロールに対してサービス定義ファイル中で定義された、インスタンスのファイルシ

ステム上にある、ローカルストレージを表します。各インスタンスは独自のローカルストレージを持

っていますが、このストレージには他のインスタンスからはアクセスできません。

LocalResource は、リードオンリーのプロパティを 3 つ公開しています。Name はユニークにローカル

ストレージを識別します。MaximumSizeInMegabytes は、利用可能な最大の容量です。RootPath は、

ローカルファイルシステム中のローカルストレージのルートパスです。

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.faultdomain.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.updatedomain.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.role.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.id.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstance.instanceendpoints.aspx

http://msdn.microsoft.com/en-us/library/s4ys34ea.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstanceendpoint.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstanceendpoint.roleinstance.aspx

http://msdn.microsoft.com/en-us/library/system.net.ipendpoint.aspx



http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.localresource.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.localresource.name.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.localresource.maximumsizeinmegabytes.aspx

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.localresource.rootpath.aspx


89

第 4 章 : SQL AZURE

5 分でつなぐ SQL AZURE

By Juliën Hanssens

「データをクラウドに置くんだ！」考えてみましょう…クライアントサイドへのデータベースのデプ

ロイも、サーバーの設定も不要なのに、データはミラーリングされ、SQL Server の開発者が慣れてい

るやり方でアクセスできるのです。それが SQL Azure です。この記事を読めば、たったの 5 分以下で

自分用の SQL Azure インスタンスを立ち上げられるのです！

前提条件–SQL AZURE アカウントの取得

ここでは、SQL Azure のアカウントは取得済みとします。もしまだなら、Azure.com[1]で Microsoft が提

供している、無料の Introductory Special や、MSDN Premium サブスクライバーに提供されているよう

な、特別割引のいずれかを無料で試すことができるでしょう。

SQL AZURE ポータルの利用

SQL Azure のアカウントが使えるようになったら、まずは SQL Azure Portal[2]にログインしなければな

りません。ここが、自分のサーバーのインスタンスを管理するダッシュボードになります。最初に

SQL Azure ポータルにログインし、使用許諾を承認すると、次の図のように SQL Azure のサーバーイン

スタンスを生成するよう求められます。

1: SQL Azure ポータルでのサーバーの生成

ユーザー名とパスワードの入力は単純明快です。これらのクレデンシャルは、SQL Server での「sa」

アカウントと同じものになることに、十分に注意してください。このパスワードには、従って強力な

パスワードのルールが適用されます。また、セキュリティ上の理由から、ある種のユーザー名は利用

できません。location を利用すれば、このサーバーインスタンスがホストされるデータセンターの物


90

理的な所在地を選択できます。あなたの－あるいはエンドユーザーの－要求に合わせて地理的な位置

を選択すると良いでしょう。

Create Server ボタンを押すと、新しいまっさらなサーバーが 1～2 秒で用意され、Server Administration

セクションへリダイレクトされます。おめでとうございます！これで、「SQL Server のクラウドへの

インストール」ができました。

SERVER ADMINISTRATION でのデータベースの生成

SQL Azure Portal[2]

Server Administration セクションでは、接続文字列で使われる名前などのサーバーの

詳細や、データベースのリストが表示されています。デフォルトでは、後者には「master」データベ

ースがあるだけです。この特別なデータベースには、SQL Server と全く同じように、システム設定情

報やログインアカウントなどといった、システムレベルの情報が含まれます。

マスターデータベースには触らずに、Create Database ボタンを押して新しいデータベースを生成しま

しょう。

2: SQL Azure ポータルでのデータベースの生成

確認の後、データベースは「瞬きする間に」生成されます。これが便利すぎると思う人は、同じこと

を以下のような小さなスクリプトでもやれます。

CREATE DATABASE SqlAzureSandbox GO

とはいえデータベースにスクリプトを与えられるようになるためには、セキュリティの設定をして、

管理ツールを使う必要があります。後者に関しては、私たちが「通常」の SQL Server のインスタンス

への接続に日々使っているツール、SQL Server Management Studio R2 (SSMS)を使わない手はありませ

ん。

ファイアウォールの設定


91

初期状態では、SSMS のようなツールから SQL Azure へ接続できないのがデフォルトです。最低でも、

明示的に SQL Azure のインスタンスに対して、特定の IP アドレスからすべての管理者権限付きでの接

続を許可するまでは接続できません。

接続を可能にするには、公開 IP アドレスを SQL Azure ポータルの Firewall Settings タブに入力し、ル

ールを追加します。

3: SQL Azure ポータルの Server Administration でファイアウォールのルールを追加する

「Allow Microsoft Services access to this server」チェックボックスに注意してください。これを有効に

すると、他の Windows Azure サービスが、このサーバーインスタンスにアクセスできるようになりま

す。

SQL SERVER MANAGEMENT STUDIO を使っての接続

SSMS でデータベースを管理できるようにするために必要な設定ができたら、早速使い始めてみまし

ょう。まだなら、まず SSMS の最新の R2 リリース[3]をインストールしてください。古いバージョンで

は、エラーメッセージに悩まされることになるだけなので、時間を無駄にしないようにしましょう。

インストールできたら、SSMS のアプリケーションを立ち上げ、完全なサーバー名と認証情報を入力

してください。


92

4: SQL Server Management Studio で SQL Azure のインスタンスに接続する

何も難しいことはありません。オプションで、接続する特定のデータベースインスタンスを指定する

こともできます（詳細は後ほど）。接続できてしまえば、「通常」の SQL Server のインスタンスの場

合ととてもよく似た環境で、SQL Azure と SSMS を使うことができます。ただし、現時点では、いつも

のダイアログボックスなしでやりくりしなければならないことを覚えておいてください。これはつま

り、T-SQL のスキルを磨かなければならないと言うことです。SQL Azure では、ご存じの T-SQL の機能

のサブセット（サブセットと言ってもかなりのものですが）と、SQL Server で使い慣れたコマンドが

使えます。これは、SQL Azure が Windows Azure プラットフォーム用に設計されていることからくる

ものです。

簡単に言えば、これは、スクリプトを使ったテーブル、ビュー、ログイン、ストアドプロシージャな

どの生成が、ほぼ T-SQL と同じ書き方でできるものの、欠けている（オプションの）パラメータもい

くつかある、ということです。

適当なテーブルを作成して、このことを確かめてみましょう。SSMS で、SqlAzureSandbox データベー

スのテーブルセクションを右クリックし、「新しいテーブル...」を選択してください。そうすると、

きれいなフィールドが並んだダイアログボックスは表示されませんが、基本的な SQL スクリプトが編

集できるようになっています。実際のところ、修正した後は平均的な SQL Server のスクリプトと異な

るところはありません。例を以下に示します。

-- =========================================

-- Create table template SQL Azure Database

-- =========================================

IF OBJECT_ID('[dbo].[Beer]', 'U') IS NOT NULL

DROP TABLE [dbo].[Beer]

GO


93

CREATE TABLE [dbo].[Beer]

(

[Id] int NOT NULL,

[BeerName] nvarchar(50) NULL,

[CountryOfOrigin] nvarchar(50) NULL,

[AlcoholPercentage] int NULL,

[DateAdded] datetime NOT NULL,

CONSTRAINT

[PK_Beer] PRIMARY KEY CLUSTERED ( [Id] ASC )

)

GO

実行すればテーブルが生成されます。これは注意すべきことの 1 つです。つまり、デフォルトでは、

テーブルは SSMS で作成しなければならないのです。ただし、いったん使えるようになってしまえば、

単に Visual Studio を起動し、サーバーエクスプローラーを使うだけで、プロジェクト内のテーブルに

アクセスできるようになります。実際、設計時のサポート機能を持つ、LINQ to SQL、ADO.NET

DataSets あるいは Entity Framework といったいつものツールを使って、生産性を向上させることすら

できるのです。

アプリケーションのクレデンシャル

最後になりましたが、セキュリティに関する助言です。ここまででは、神同様のマスタークレデンシ

ャルを使ってデータベースを管理してきました。アプリケーションにはこれらのクレデンシャルを含

めたくないので、アプリケーションで使うための、もっと軽いカスタムのユーザー／ログインを生成

しましょう。

-- 1. Create a login

CREATE LOGIN [ApplicationLogin] WITH PASSWORD = 'I@mR00tB33r'

GO

-- 2. Create a user

CREATE USER [MyBeerApplication]

FOR LOGIN [ApplicationLogin]

WITH DEFAULT_SCHEMA = [db_datareader]

GO

-- 3. And grant it access permissions

GRANT CONNECT TO [MyBeerApplication]

GO


94

覚えておきましょう– ターゲットのデータベース

気づいているかも知れませんが、ここでのサンプルには、例えば“USE [SqlAzureSandbox]”といった

USE 文が全く使われていません。これは、USE <database>コマンドがサポートされていないからです。

SQL Azure では、それぞれのデータベースは別々のサーバー上にあり、従って個別の接続が必要にな

るかも知れないことを、念頭に置いておかなければなりません。これは、SSMS ではサーバーへの接

続ダイアログボックスのオプションを使えば簡単です。

5: 特定のデータベースへ SQL Server Management Studio で接続する

データベース間で頻繁に切り替えを行うなら、このことには注意が必要です。このことを覚えていれ

ば、空の高さには限度がありません。それは、雲の中でも同じです。

1. Microsoft Windows Azure Platform http://www.azure.com

2. SQL Azure Portal

http://sql.azure.com

3. SQL Server 2008 R2 Management Studio Express (SSMSE) http://tinyurl.com/ssmsr2rtm

http://www.azure.com/

http://sql.azure.com/

http://tinyurl.com/ssmsr2rtm


95

第 5 章 : WINDOWS AZURE プラットフォーム APPFABRIC

デスクトップから AZURE ROLES をリアルタイムでトレースする

By Richard Prodger

Azure でホストされるデプロイ済みロールを扱う上での大きな課題の 1 つは、トレース情報へのアク

セスをどうやるか、ということです。そう、Azure Diagnostics を使ってテーブルストレージ内にデー

タを収集することはできますが、これはデータを読み出す必要があり、リアルタイムの情報を得られ

るわけではないので、理想からはほど遠いものです。もっと良い方法があるんです！.NET Framework

には、多くの読者におなじみの TraceListener がすでに用意されています。独自のカスタム

TraceListener を作成すれば、トレースメッセージをどこへでも送信できます。そして、サービスバス

が提供する、ファイアウォール越えのマジックを使えば、それらのトレースメッセージを自分のデス

クトップ上で実行しているアプリケーションで拾い上げることができるのです。

カスタムの TRACELISTENER

必要なのは、メッセージを送信するクライアントと、それを受信するサーバーです。Azure クライア

ントから始めましょう。まずやらなければならないのは、カスタムの TraceListener の実装です。

public class AzureTraceListener : TraceListener

{

ITrace traceChannel;

public AzureTraceListener(string serviceNamespace, string servicePath, string issuerName, string

issuerSecret)

{

// Create the endpoint address for the service bus

Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, servicePath);

EndpointAddress endPoint = new EndpointAddress(serviceUri);

// Setup the authentication

TransportClientEndpointBehavior credentials = new TransportClientEndpointBehavior();

credentials.CredentialType = TransportClientCredentialType.SharedSecret;

credentials.Credentials.SharedSecret.IssuerName = issuerName;

credentials.Credentials.SharedSecret.IssuerSecret = issuerSecret;

// Create the channel and open it

ChannelFactory<ITrace> channelFactory = new ChannelFactory<ITrace>(new NetEventRelayBinding(),

endPoint);

channelFactory.Endpoint.Behaviors.Add(credentials);

traceChannel = channelFactory.CreateChannel();

}


96

public override void WriteLine(string message)

{

traceChannel.WriteLine(message);

}

public override void Write(string message)

{

traceChannel.Write(message);

}

}

As you can see, there is some setup stuff for WCF and the service bus, but basically all you have to do is

override the Write and WriteLineMethods. The ITrace interface is simple as well:

[ServiceContract]

public interface ITrace

{

[OperationContract(IsOneWay=true)]

void WriteLine(string text);

[OperationContract(IsOneWay = true)]

void Write(string text);

}

メッセージ送信コンソールアプリケーション

さて、メッセージを送信するアプリケーションも必要です。この記事のために、シンプルなコンソー

ルアプリケーションを作成しましたが、これは何らかの Azure のロールでもかまいません。

static void Main(string[] args)

{

string issuerName = "yourissuerName";

string issuerSecret = "yoursecret";

string serviceNamespace = "yourNamespace";

string servicePath = "tracer";

TraceListener traceListener = new AzureTraceListener(serviceNamespace, servicePath, issuerName,

issuerSecret);

Trace.Listeners.Add(traceListener);

Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));

while (true)

{

Trace.WriteLine("Hello world at " + DateTime.Now.ToString());

Thread.Sleep(1000);

}

}


97

このシンプルなアプリケーションは、新しいカスタムの TraceListener を生成し、それを TraceListener

のコレクションに追加し、タイムスタンプを 1 秒毎に送信します。送信内容を見ることができるよう

にするため、もう 1 つのリスナーとして Console.Out も追加しました。

トレースサービス

これで Azure 側はできましたが、デスクトップ側はどうすればよいでしょうか？最初にやらなければ

ならないのは、カスタムリスナーが呼び出す TraceService の実装です。

public class TraceService : ITrace

{

public static event ReceivedMessageEventHandler RecievedMessageEvent;

void ITrace.WriteLine(string text)

{

RecievedMessageEvent(this, text);

}

void ITrace.Write(string text)

{

RecievedMessageEvent(this, text);

}

}

public delegate void ReceivedMessageEventHandler(object sender, string message);

イベントデリゲートは、このクラスをホストしているアプリケーションにメッセージを送るためのも

のです。

サービスホストクラス

次に、サービスをホストするクラスを生成しなければなりません。

public class AzureTraceReceiver

{

ServiceHost serviceHost;

public AzureTraceReceiver (string serviceNamespace, string servicePath, string issuerName, string

issuerSecret)

{

// Create the endpoint address for the service bus

Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, servicePath);

EndpointAddress endPoint = new EndpointAddress(serviceUri);

// Setup the authentication

TransportClientEndpointBehavior credentials = new TransportClientEndpointBehavior();

credentials.CredentialType = TransportClientCredentialType.SharedSecret;

credentials.Credentials.SharedSecret.IssuerName = issuerName;


98

credentials.Credentials.SharedSecret.IssuerSecret = issuerSecret;

serviceHost = new ServiceHost(typeof(TraceService));

ServiceEndpoint endpoint = serviceHost.AddServiceEndpoint(typeof(ITrace), new NetEventRelayBinding(),

serviceUri);

endpoint.Behaviors.Add(credentials);

}

public void Start()

{

serviceHost.Open();

}

public void Stop()

{

serviceHost.Close();

}

}

これは基本的な WCF のコードで、特別なことは何もありません。やらなければならないのは、サー

ビスバスの認証のためのクレデンシャルを生成し、エンドポイントを生成し、クレデンシャルを追加

してサービスホストを立ち上げることだけです。

サービス

後は、デスクトップアプリケーションを実装するだけです。ここでもまた、話を単純にするために、

シンプルなコンソールアプリケーションを作成しました。

static void Main(string[] args)

{

Console.Write("AZURE Trace Listener Sample started.\nRegistering with Service Bus...");

string issuerName = "yourissuerName";

string issuerSecret = "yoursecret";

string serviceNamespace = "yourNamespace";

string servicePath = "tracer";

// Start up the receiver

AzureTraceReceiver receiver = new AzureTraceReceiver(serviceNamespace, servicePath, issuerName,

issuerSecret);

receiver.Start();

// Hook up the event handler for incoming messages

TraceService.RecievedMessageEvent += new ReceivedMessageEventHandler(TraceService_myEvent);

// Now, just hang around and wait!

Console.WriteLine("DONE\nWaiting for trace messages...");


99

string input = Console.ReadLine();

receiver.Stop();

}

static void TraceService_myEvent(object sender, string message)

{

Console.WriteLine(message);

}

このアプリケーションは、単純にレシーバークラスをインスタンス化し、サービスホストを起動しま

す。イベントハンドラーが登録され、メッセージを待ちます。クライアントがトレースメッセージを

送信すると、イベントハンドラーが起動され、メッセージがコンソールに書き出されます。

サービスバスには、NetEventRelayBinding を使っていることに気がついたかも知れません。これは、

複数のサーバーエンドを扱い、クラシックな pub/sub パターンでメッセージを受信できるように考慮

したのです。つまり、このサーバーの複数のインスタンスを複数のマシン上で動作させても、それら

がすべて同じメッセージを受信できるのです。必要であれば、他のバインディングを使うこともでき

ます。このバインディングのもう 1 つの利点は、アプリケーションがリスニングしている必要がない

ということですが、アウトバウンドの帯域には費用が発生しないとはいえ、リスニングしているかど

うかにかかわらず、接続には費用がかかるということを忘れないようにしてください。WCF とサー

ビスバスのセットアップは、すべてコード中で行っていますが、設定ファイルを使うようにするのも

簡単でしょう。私は、XML で書かれた WCF の設定を読むのが苦手でいつも間違えてしまうので、こ

の方法が好みなのですが、この方法を使うということは、バインディングを変更するには再コンパイ

ルが必要になるということです。

まとめ

スレッド安全性や、エラー処理、利用時のサービスバスチャネルの確認など、TraceListener クラスを

改善するためにできることはたくさんありますが、それらは読者の皆さんにお任せしましょう。この

コードが最初にまとめ上げられたのは、AppFabric サービスバスがプライベートベータの頃です。

Microsoft は、このコードを SDK のサンプルに収録しているので、そちらを参照してみてください。

この記事はこれで終わりです。これで読者のみなさんは、どこからでも Azure のロールをモニタリン

グできるようになったのです。


100

著者の紹介

ERIC NELSON

After many years of developing on UNIX/RDBMS (and being able to get

mortgages) Eric joined Microsoft in 1996 as a Technical Evangelist (and

stopped being able to get mortgages due to his new 'unusual job title'

in the words of his bank manager). He has spent most of his time

working with ISVs to help them architect solutions which make use of

the latest Microsoft technologies - from the beta of ASP 1.0 through to

ASP.NET, from MTS to WCF/WF and from the beta of SQL Server 6.5

through to SQL Server 2008. Along the way he has met lots of smart

and fun developers - and been completely stumped by many of their

questions! In July 2008 he switched role from an Application Architect

to a Developer Evangelist in the Developer and Platform Group.



Website: http://www.ericnelson.co.uk


Blog: http://geekswithblogs.net/iupdateable

Twitter: http://twitter.com/ericnel

MARCUS TILLETT

Marcus Tillett is currently the Head of Technology at Dot Net Solutions,

where he currently heads the technical team of architects and

developers. Having been building solutions with Microsoft

technologies for more than 10 years, his expertise is in software

architecture and application development. He is passionate about

understanding and using the latest cutting-edge technology. He is

author of “Thinking of... Delivering Solutions on the Windows Azure

Platform?” (http://www.bit.ly/a0P02n).

Head of Technology at Dot Net Solutions

Twitter: @drmarcustillett

Blog: http://www.dotnetsolutions.co.uk/blog

http://www.ericnelson.co.uk/


http://geekswithblogs.net/iupdateable

http://twitter.com/ericnel

http://www.bit.ly/a0P02n

http://twitter.com/drmarcustillett

http://www.dotnetsolutions.co.uk/blog


101

RICHARD PRODGER

Richard Prodger is a founding Technical Director of Active Web

Solutions with more than 25 years experience in the R&D and

computing sectors. Richard’s primary responsibilities are technical

strategy and systems development. Richard is the Director responsible

for the AWS Technology Centre.

Prior to joining AWS, Richard managed BT's Web Services unit. At BT,

Richard was responsible for implementing large scale e-commerce and

web based systems and for translating emerging technology into

practical business solutions.

Richard was the principal architect and technical design authority for

the multi-award winning RNLI Sea Safety system. More recently,

Richard has been working closely with Microsoft on their cloud services

platform, Windows Azure.

Technical Director of Active Web Solutions

www.aws.net

SAKSHAM GAUTAM

Saksham Gautam started working with Windows Azure right from the

early stages of the development of the platform. He is an MCTS on

WCF, and he graduated with Bachelors in Computer Science in 2007.

Since then, he has been working as a Software Developer for AWS.

Saksham is one of the architects and the lead developer for porting the

existing on-premise sea safety system to Windows Azure. Apart from

Azure and .NET, he is interested in distributed systems composed of

heterogeneous components. He presented his work on interoperability

in Windows Azure at the Architect Insight Conference 2010. He is

currently based in Prague and builds interesting software, particularly

using C#.NET.

Software Developer/Architect, Active Web Solutions

Twitter: @sakshamgautam

Blog: http://sakshamgautam.blogspot.com

http://www.aws.net/

http://sakshamgautam.blogspot.com/


102

STEVE TOWLER

Steve Towler is a Senior Software Developer for Active Web Solutions

in Ipswich and has been working with Windows Azure since April 2009.

In that time he has helped develop a number of applications hosted in

Windows Azure including a CAD drawing collaboration tool and a

location based services application. Steve has also been conducting a

number of Azure Assessment Days in conjunction with Microsoft and

promoting the benefits of cloud computing.

Senior Software Developer, Active Web Solutions

Blog: http://www.stevetowler.co.uk

ROB BLACKWELL

Rob Blackwell is R&D Director at Ipswich based Active Web Solutions.

He was part of a team that won an unprecedented three British

Computer Society awards in 2006 and was a Microsoft Most Valuable

Professional (MVP) in 2007 and 2008. Rob is a self-confessed language

nerd and freely admits that the real reason he’s interested in running

Java on Azure is so that he can host his spare-time Clojure Lisp

experiments.

R&D Director, Active Web Solutions

Blog: www.robblackwell.org.uk

Twitter: http://twitter.com/RobBlackwell

JULIËN HANSSENS

Juliën Hanssens is a Software Engineer and Technical Consultant in

software technologies at Securancy Intelligence, a Dutch IT company.

He can be contacted at [email protected]

Software Engineer at Securancy Intelligence


http://www.stevetowler.co.uk/

http://www.robblackwell.org.uk/

http://twitter.com/RobBlackwell




103

SIMON MUNRO

Simon Munro, a senior consultant at London-based EMC Consulting,

has been designing and developing commercial applications for two

decades. Despite this, he still has a deep-rooted need to write

production code every day. Branded as a thought-leader, Simon enjoys

stirring things up and pushing conformity by challenging acceptable

norms and asking difficult questions. His current endeavors include

assisting developers and customers understand the underlying

architectural concepts around cloud computing.

Senior consultant at EMC Consulting

Blog: http://simonmunro.com

Twitter: @simonmunro

SARANG KULKARNI

Sarang is an Analyst Programmer with Accenture-Avanade during work

hours and a technology nomad after that. He has been coding for food

and gadgets for the past 8 years around all things Microsoft including

ATL/COM, VB6, .Net Framework 2.0 onwards, Winforms, WCF,

ASP.Net, WIF and now Windows Azure; targeting varied assignments

ranging from run off the mill enterprise LOB applications to Astrometry

APIs and media transcoding solutions in the cloud. He dwells at Pune,

India with daughter Saee and wife Prajakta.

Analyst Programmer with Accenture-Avanade

Blog: http://geekswithblogs.net/iunknown


STEVEN NAGY

By day, Steven is a .Net consultant who likes diving deep into the

technologies he is passionate about, and has been learning, teaching,

and presenting on Azure since its first public release at PDC 08. By

night he cackles gleefully basking in the glow of his laptop screen as

thousands of Azure worker roles carry out his evil bidding.

.NET Consultant

Blog: http://azure.snagy.name/blog/

Twitter: snagy

http://simonmunro.com/

http://geekswithblogs.net/iunknown


http://azure.snagy.name/blog/


104

GRACE MOLLISON

Grace’s role as a Platform Architect at EMC bridges the gap between

Infrastructure and Development. Activities range from supporting the

development teams throughout the development life cycle, liaising

between the client, 3rd parties ( e.g Hosting partners) and EMC

Consulting as required. Advising on and architecting the platform.

Grace has a lot of enthusiasm for Public cloud solutions and has been

dabbling with Azure from early betas. Grace was part of the team that

developed the’ See The Difference ‘solution which was built using

Windows Azure and SQL Azure.

Grace is a CISSP (Certified Information Systems Security Professional).

Grace joined EMC in 2008 from Hogg Robinson where she was

responsible for the design, implementation and ongoing maintenance,

support and evolution of their eCommerce platform which has BizTalk

at its core.

Platform Architect at EMC

Blog: http://consultingblogs.emc.com/gracemollison/

JASON NAPPI

Jason is a Software Architect at SmartPak, where he advances their

eCommerce engine and line-of- business applications. He has 14 years

experience as a developer mainly on the Microsoft stack, developing

applications beginning with VB 6, MTS/COM+, ASP, through each

successive version of the .NET framework and even picked up a

certification along the way. He’s held roles in variety of industries in

the Boston area including, health care, web hosting, financial services,

and eCommerce. Most recently Jason’s been struggling to keep pace

with the Entity Framework, Silverlight, Azure, ASP.NET MVC, WCF Rest,

WCF Data Services, and the myriad of other technologies pouring out

of Redmond and elsewhere.

Software Architect, SmartPak

Blog: http://blog.nappisite.com

http://consultingblogs.emc.com/gracemollison/

http://blog.nappisite.com/

http://public.bay.livefilestore.com/y1pFwfMe15weqSluWRidgM3hOkkuL1duxfMx4V46UPVMR9U-DPXHWlOH75s9zljvvbE_nofmp2D7ULXX7yFrNk09g/pic.jpg?download


105

JOSH TUCHOLSKI

Josh works for Rosetta as a Senior Technology Associate in the

Microsoft Solution Center where he takes part in helping Rosetta

deliver interactive marketing solutions to clients in the financial,

ecommerce, B2B, and healthcare sectors. He has experience working

with small teams to large enterprise environments and focuses on WCF

service development, RIA apps, and middle-tier component

integration. He strives to produce simple solutions that create sound

technical architectures and can tell a great story at the end of the day.

Outside of development, he enjoys meeting with students in computer

science and software engineering to pick their brain and help them

prepare for their professional careers. Josh lives in Ohio with his wife

Andrea.

Senior Technology Associate

LinkedIn: http://www.linkedin.com/in/joshtucholski

Twitter: http://www.twitter.com/jtucholski

Blog: http://www.dontforgetyourtodos.com/

DAVID GRISTWOOD

Ever since he wrote his first ‘10 ? “hello world” : goto 10‘ program on a

PET computer in the late 70s he has been hooked, and has worked

with computers ever since. During his career, David has secured a

Distinction in Computing Science at Newcastle University, worked as a

freelance computer journalist, visiting lecturer in Computer Science, a

director of a software company, as well has having designed and

developed a wide range of software, and computer systems.

For the last 15 years David has worked at Microsoft, firstly in its

fledgling consultant service section, then in EMEA as a technical

evangelist. Since Microsoft’s launch of .NET, he has been focused on

the .NET platform, helping design and build a wide range of systems,

from smart clients to web applications, and more recently, cloud

computing with the Windows Azure platform. He currently works

mainly with partner and startups, and runs and delivers regular

technical briefings around the Microsoft platform, including TechEd

Europe, TechDays, BizSpark Camp, etc.


Twitter: @scroffthebad

http://www.rosetta.com/

http://www.linkedin.com/in/joshtucholski

http://www.twitter.com/jtucholski

http://www.dontforgetyourtodos.com/


106

NEIL MACKENZIE

Neil Mackenzie has been programming since the late Bronze Age. He

learned C++ when the only book available was written by Bjarne

Stroustrup. He has been using SQL Server since v4.2.1 on Windows NT.

However, he is only a recent convert to the joys of .Net Framework and

C#. He has been using Windows Azure since PDC 2008 and regrets the

demise of the Live Framework API. Neil spent many years working in

healthcare software and is currently involved in a stealth data-analytics

startup. Neil lives in San Francisco, CA having noticed the weather

there is somewhat better than it was in Scotland.

Blog: http://nmackenzie.spaces.live.com/blog/

Twitter: @mknz

MARK RENDLE

Mark is currently employed as a Senior Software Architect by Dot Net

Solutions Ltd, creating all manner of software on the Microsoft stack,

including ASP.NET MVC, Windows Azure, WPF and Silverlight.

His career in software design and development spans three decades

and more programming languages than he can remember. C# has been

his favourite language pretty much since the first public beta, when

you had to write the code in a text editor and compile it on the

command line. Those were the days. You kids today, with your

IntelliSense and your ReSharpers, don’t know you’re born...

Things vying for Mark’s attention lately include functional

programming, internet-centric applications, the Azure cloud platform

and NoSQL data stores.

Senior Software Architect, Dot Net Solutions Ltd

Blog: http://www.dotnetsolutions.co.uk/blogs/markrendle

http://nmackenzie.spaces.live.com/blog/

http://www.dotnetsolutions.co.uk/blogs/markrendle

Technology

Windows Azureプラットフォーム 現場からの報告

Windows Azureプラットフォーム　現場からの報告