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

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

Volume 1

編集者兼コピペ常習者：Eric Nelson と、Eric よりも賢い 15 人の著者
2010/6/22（v 0.9）

Cover art by Andrew Fryer

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

開発者達は、Windows Azure プラットフォームがクラウドコンピューティングに開いた可能性を探究
してきました。本書は、Windows Azure プラットフォームに積極的に取り組んできた大勢の開発者に
よる、誰もが成功できるようという願いのこもった素晴らしい記事をまとめたものです。この第一巻
には 20 の記事があり、Windows Azure プラットフォームの始め方から、エラスティックなアプリケ
ーションへのベストプラクティスの実装までを取り上げています。


目次

始めに 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

2


リスク低減のための非技術的戦略 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

3


動的スキーマ 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

4


アプリケーションのクレデンシャル 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

5


始めに

編集者から
みなさんこんにちは。
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: eric.nelson@microsoft.com
Blog: http://geekswithblogs.net/iupdateable
Twitter: http://twitter.com/ericnel

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

開発者は、ベストプラクティス、知識と経験－それも自分自身の－を共有することに価値を置くもの
です。もしも Windows Azure プラットフォームについて、自分なりの見識があるならば、Windows

6


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

提案したい記事（複数でもかまいません）と、できれば「記事のサンプル」としてあなたのブログへ
のリンクなどを付けて、私（eric.nelson@microsoft.com）にメールしてください。

7


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 があります。本書にも、始めてみようという章があります。

8


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。簡単に言えば－従来のベータほどしっかりしてはいな
いということ

9


第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 ポータルは、

10


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

SQL Azure サーバーが生成できたら、データベースを生成します。アクセスを許可するには、ファイ
アウォールの規則も設定しなければなりません。ここでもやはり話を単純にしたければ、ローカルマ
シンの IP アドレスから SQL Azure サーバーへのアクセスを許可しておけばよいでしょう。

最後に、筆者も迷ったように、生成した SQL Azure にいつもの SQL Server Management Studio からアク
セスできるかが心配でしょう。筆者の場合、SQL Server Management Studio 2008 R2 をダウンロードし
たら、問題なく接続することができました。

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

11


クラウドデータベースの準備が整い、いつもの 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」する機能も見える
ようになったはずです。

12


13


アプリケーションは、Run するまでは先ほどの URL からアクセスすることはできないので、Run を押
して、じっと、じっと、じっと待っていてください…Windows Azure のインフラストラクチャがアプ
リケーションのためのプロビジョニングをするには尐し時間がかかりますが、いったん青信号になれ
ば、もうこれで行けるはずです。

14


これらが、Windows Azure になじむために私が行った簡単なステップです。これらのステップを踏む
ことで、Windows Azure での開発は、これまでになれた開発経験とほとんど変わりないことを示すこ
とができました。しかし、Windows Azure のための開発に際して、もっと複雑な検討をしなければな
らないことの 1 つには、SQL Azure が提供するこれまで一般的だったリレーショナルデータベースの
代わりに、Windows Azure ストレージを潜在的に利用することになるかもしれないということがあり
ます。

15


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 ストレージの下にあるすべてのものに加え、ホストされたアプ

16


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

図 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）」と書かれた、便利で小さなチェックボックスです－これは気が利いています。

17


図 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 と同じようにほとんどの基本機能をカバーしており、注目に値するでし
ょう。

18


図 3 : Windows Azure MMC

19


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 ストレージのアカウントに接続し、診断情報を読み取ってそこからデプロイメントを
検索し、見つかったデプロイメントに接続するか、サブスクリプションに直接接続して、モ
ニターするホストされたサービスのリストを取得できます。

20


ダッシュボードは、収集されたすべての診断情報の大局を見せてくれます。イベントビュー
アー、トレースログ、インフラストラクチャログ、パフォーマンスカウンター、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 マイグレーションの日常的な作業を行うための素晴らしいツールで
す。

21


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 オブジェクトの可視化を

22


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

23


第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

24


ーショナルなクエリを使わないなら、これは理想的な選択肢になります。リレーションシップを取り
除き、データを非正規化すれば、パーティショニングを非常に容易にできます。基本的には、これが
4
「NoSQL」ムーブメントの前提となっています。

さらなるパフォーマンスの向上のためには、データの複製を考慮するべきです。顧客を年齢統計に基
づいて、あるいは都市によって検索する機能について考えてみましょう。異なるパーティションにデ
ータの複製が 2 つあれば、クエリとデータの取り出しにかかる時間は非常に効率的になります。この
アプローチの逆の側面は、データの複数のコピーを管理するために複雑さが増してしまうという点で
す。

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

テーブルのエンティティは、パーティションキーに基づいて水平にパーティショニングされ
る。
blob はコンテナに基づいてパーティショニングされる。
キューはキュー単位でパーティショニングされる。
SQL Azure はパーティショニングをサポートしない。

一部のフィールドがほとんどのクエリで要求されず、尐量のデータがまとめて保存されるような場合
は垂直パーティショニングが有効ですが、デフォルトでは垂直パーティショニングはサポートされま
せん。

コロケーション

SQL Azure、 Azure ストレージ、 Azure コンピュートロール、AppFabric は、すべてデータセンターに
出入りするデータに対する帯域コストが設定されています。アプリケーションを構築する際には、こ
のことを念頭に置いておくべきです。Azure ではすでにデータセンターをどこにするかを選択できま
すが、より重要なのは、Affinity グループを通じてシステムの構成要素の同じ場所に配置することで、
ネットワーク上のデータのやりとりを最小限に抑え、高速化できるということです。ありがたいこと
に、これはデプロイメントの事項として考慮すべきことなので、当面の設計に関してはそれほど重要
ではありません。

キャッシュ

考慮すべきより重要な事項は、キャッシングのメカニズムを利用する様々な機会です。トランザクシ
ョンを最小限にとどめるために、様々な方法でキャッシュを活用することができます。エンドユーザ
5
ーの http リクエストから、下位層のデータストア、あるいはメモライゼーション目的などがそうで
す。プラットフォーム内のほとんどすべてのものに対して REST インターフェースでアクセスできる
場合、キャッシングには注力するだけの価値があります。検討すべきキャッシュの概念をいくつか挙
げてみましょう。

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

25


クライアントサイドの有効期限付きキャッシュ– 一定期間が経過した後は無効になるコンテ
ントで、クライアントのブラウザがページをリクエストせず、代わりにローカルコピーが提
供されるようにする。
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

26


ことで、ワーカーはロックの取得や解放を扱う必要がなくなり、作業アイテムを処理する仕事に集中
できます。こういったキューは、様々な異なる種類の処理で再利用できるもので、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 プラットフォーム上で実行されるアプリケーショ
ンのアークテクチャを設計する上で念頭に置いておくべきいくつかの重要な原則について、概要を述

27


べました。これらのガイドラインを守れば、クラウドの主たる目的である、スケーラビリティとコス
トの活用を達成できるはずです。

28


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

By Marcus Tillett

コストは重要です

コスト指向開発は、目新しいものではありません。アプリケーションや製品を構築するための低コス
トのアプローチは望ましいものですが、これを達成するための方法論は、常に洗練されたものである
とは限りません。Azure のようなクラウドプラットフォームについて考慮する場合、アーキテクチャ
の選択がコストに与える影響は大きいものになるので、より洗練されたアプローチが必要になります。

伝統的なオンプレミスのアーキテクチャや、ホストされているアークテクチャの場合、コストは重要
なファクターとは考えられないかも知れませんが、Azure の場合、コストははるかに注目される領域
になります。考慮しなければならないコストは様々です。それらのコストを考慮しなければならない
のは、Azure に関してでもありますし、開発全般に関してでもありますし、アプリケーションのライ
フサイクル管理のプロセスに関してでもあります。

考慮すべきコスト

開発プロセスは、Azure においてコストについてしっかり考慮まとめ
する必要があるかもしれないものです。Azure での開発戦略は
 これまでのオンプレミスあるいはホス
幅広く考えることができます。1 つの極論としては、Azure の
トされたソリューションに比べ、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 つの重要なトピックとして、既存のアプリケーションのマイグレーションや、新しいアプリケ
ーションに求められるデータのセットアップの考慮のための方法論があります。マイグレーションや
設定は、アプリケーションとデータの両方を含む必要があります。大量のデータや複雑なデータを転
送するのに必要となる時間やプロセスや手順は、非常に大きな仕事になり得るものです。利用中のデ

29


ータソースに対する変更の管理には潜在的な複雑性があるので、選択したアプローチに必要となるビ
ジネスコストは、非常に重要なファクターになり得るのです。

プラットフォーム自身がコストに与える影響は、おそらく、明白にコスト指向アーキテクチャを必要
とする領域でしょう。例えば、データストレージにおける 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

30


初めての 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 に対しては持ち得たようなサービスの
レベルや信頼を、外部のサービス提供者に強制することはできません。データの場合と同様に、顧客

31


がベンダーロックインを避けようとし、サービスレベルを保証し、運用やセキュリティ、パフォーマ
ンスやその他の標準を管理しようとするにつれて、きわめて複雑な契約上の分岐が生じてしまうとい
う、現実の問題がここにはあります。

隠れたリスク

主流の CIO の情報ソースは、扱う範囲が広いためにリスクを広めてしまいますが、主としてより技術
的な性格を持っているために、同じように現実的なものでありながら、それほど知られていないリス
クが多く存在しています。

もっとも明白なのは、セキュアで信頼性があり、高性能なクラウドコンピューティングソリューショ
ンを生み出すのに必要な、スキルや経験が欠けているというものです。このことはまた、パフォーマ
ンスのボトルネックに対し、単純にハードウェアを投入するのに比べて、開発技術者のコストの方が
高くなってしまうという問題にも関係します。

私たちが信頼を置く、プラットフォームとツールの提供者である Microsoft でさえも、Azure が持つリ
スクを抱えています。Azure テーブルやキューといったクラウド技術の、オンプレミスでの代理技術
が欠如していることによって、Azure プラットフォームへのコミットメントは、きわめて高いものに
なってしまい（ベンダーロックインと同じようなものです）ますし、ツールはまだ未成熟で、継続的
インテグレーション（グレース・モリソンによる‘Using a CI build to achieve an automated deployment of
your latest build’を参照）のような、認知されている技術的なプラクティスをサポートすることも用意
ではありません。

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

究極的には、リスク管理の責任は、組織内のプロジェクトマネージャーやその他の人員に帰せられる
ものですが、リスクの特定は、依然としてチームのメンバー全員の責任です。本書をダウンロードす
ることで、読者はチーム内の同僚以上にクラウドコンピューティングに関する知識を得ることになっ
たので、技術的な側面に踏み込む前に、より多くの責任を背負い、リスク低減の側面の中でも、コー
ドとは関わらない部分に対処しなければならないでしょう。

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

シンプルで、クラウドコンピューティングにより適しているものを選択しましょう。それは例えば、
公開され、要求のピークがあるかもしれないようなものです。機微なデータを含んでいたり、他の多
くのシステムと統合されたり、既存のレガシーシステムからのマイグレーションであったり、多くの
伝統的なデータベースストレージやレポートを含んでいたりするアプリケーションに取り組む前に、
こういった例での成功を積み上げましょう。

早めに始める

そのプロジェクトが、目立たなくてつまらない開発を行うものだったとしても、企業における法務、
コンプライアンス、運用、財務、監査やその他の部門との関わりは、通常より早めに始めなければな
りません。通常は、既存のデータセンターに新しい Web サイトを立ち上げる心配などはしませんが、

32


仮に筋を通さずにクラウドコンピューティングのアプリケーションを立ち上げて周りの人々を驚かせ
るようなことをすれば、そのアプリケーションは信頼してもらえないことでしょう。

価格と運用モデルの理解

表面的にはシンプルに見えるかも知れませんが、クラウドコンピューティングの価格、課金、SLA や
その他の事項を深く見ていけば、法的な部分やコンプライアンス、部門間の調整などへの広範な影響
があり、それらは複雑なものかも知れません。尐なくとも、推定される要求事項を付けて Azure の価
格を記載したスプレッドシートと、注記付きの SLA のプリントアウトを、プロジェクトの出資者に渡
しておかなければなりません。

影響の理解

完全な脅威モデルを扱う必要はないかも知れませんが、アプリケーションに問題があったり、データ
が失われた場合に考えられる、財務面や風評面、あるいはその他の面でのリスクについては理解して
おく必要があります。損失の影響を理解したら、クラウドにどういったデータをどれだけの期間保存
するのか、そしてそれをオンプレミスのストレージに移動させるかどうかといったことのアプローチ
に、それを反映させるべきです。

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

クラウドコンピューティングにはセキュリティリスクがあると見なされているので、セキュリティに
焦点を当てるということは、しばしばそのソリューションが対応するオンプレミスの部分よりもセキ
ュアであるということを意味します。クラウドコンピューティングのリスクに対応する際には、必ず
それらのリスクを、既存のオンプレミスプラットフォームにある既存の日常的なリスクと比較してく
ださい。必ずしも、すべてのソリューションやネットワーク、その他のインフラストラクチャが、実
際に約束していたとおりの可用性やセキュリティを達成しているとは限らないのです。

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

銀行などのように、追加のリスクを尐なくとも今年は取りたがらない、リスクを嫌う企業に比べ、ス
タートアップ企業は企業文化として、クラウドコンピューティングのリスクを、企業全体として持っ
ているリスクの一部として見なすことができます。より成熟した企業は、リスク管理のためのプロセ
スや委員会を持ち、最終的にはプロジェクトのスポンサーの責任になるかも知れませんが、大きなア
イデアを実現しようとする前には、その組織がリスクをとれるかどうかの感触を得ておかなければな
りません。

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

HOW EXTREME?

Microsoft は、古き良き ASP.NET Web アプリケーションを、その下位層の SQL データベースと共に、
Azure クラウドに最小限の変更で投入するのを、きわめてシンプルなことにしました。一方で、クラ
ウドコンピューティングの環境に最適化された、十分検討されたアーキテクチャを持つソリューショ

33


ンを構築することは、より難しく、手間がかかり、リスクを伴うことです。システムの構築を、リス
クを回避する環境で行い、クラウド用にする必要がないのであれば、Azure ストレージ、Worker プロ
セス、フェデレーテッド認証管理やその他のクラウド固有の技術は使わずに、web ロールと SQL デー
タベースでシンプルなソリューションを構築しましょう。どちらのアプローチを取るにしても、
Azure はそのアプローチをうまくサポートしてくれますが、魅力的な新機能が実際にはどれだけ必要
なものなのかを見極め、早めに決断を下しておかなければなりません。

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

クラウドコンピューティングのリスクに関する限り、もっとも重要で活発な問題はデータであり、こ
れに関してはソリューション設計の初期の段階で検討しなければなりません。ありがたいことに、必
要な場合はおなじみのデータベースプラットフォームを SQL Azure で利用すれば、NoSQL 的な Azure
テーブルに関する多くの問題やリスクには対処できますが、Azure を使う優れたアーキテクチャでは、
最終的には Azure ストレージやキャッシュ、あるいはその他の技術を検討する必要があるでしょう。
Azure クラウドのストレージをどう使ったとしても、依然としてそのデータはクラウドの中にあり、
構築するアーキテクチャでそのデータを扱わなければならないという問題は残ります。レポートや他
のシステムのとの統合のため、あるいはただ単にデータの安全性のために、Azure からオンプレミス
のデータベースへ、データを移動したりコピーしたりする要求があるかも知れません。

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

それなりのサイズのアプリケーションを Azure 上で構築し、それをライブ環境へデプロイするまでは、
隠れたままになっている技術的な課題があるものです。本書を読むことで、読者は正しい方向性に向
かい、他者の経験から学ぼうとしているわけですが、単なる読書や、実作業から学ぶ以上のことをや
る必要があります。まだ見ぬ落とし穴のインパクトをとにかく低減するためには、ツールをインスト
ールし、コードを書いてデプロイし、負荷をかけ、スケールアップし、スケールダウンし、デバッグ
し、診断を行い、見たことのないたくさんのパターンや技術に取り組まなければならないのです。

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

あなたの初めての Azure アプリケーションの未来は、全く不確かなものです－2 年先を考えてみても、
アーキテクチャ上の選択が正しかったかどうかははっきりせず、技術的な構成要素は追加されたり廃
棄されたりしており、規制は変更されていたり、クラウドコンピューティングに対するあなたの会社
の態度も変わっているかも知れません。安定するまでに数年もかかるような環境下では、ソフトウェ
ア職人気質からわき上がる、メンテナンス性、テスタビリティ、拡張性といった懸念は、増幅される
ものです。.NET のエコシステムにおいて、十分に確立されたプラットフォームと、新しい技術、ア
プローチ、考え方が組み合わさった Azure は、私たちが直面しているリスクを低減できるよう適切に
ソリューションを構築するための、要求とフレームワークの両方を、私たちが手にしていることを意
味しているのです。テスタビリティ、IoC、疎結合、あるいはその他のソフトウエア職人の技法
は、.NET プラットフォーム上で十分サポートされ、理解され、議論されてきており、従って（もち
ろんのこと）Azure に持ち込むこともできるのです。技術者は、一見簡単に見える単一階層のモノリ
シックなアーキテクチャとして、これらの技術を磨かなければならず、

34


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.

開発者の責任

技術者は、クラウドコンピューティングによってもたらされる技術的な可能性に興奮するかも知れま
せんが、企業やその他の方針決定者は、おそらく他の（最近の）どのコンピューティング技術の波と
比べても、クラウドコンピューティングに対して警戒心を抱いています。彼らは、ベンダーのマーケ
ティング担当者達や、クラウドの自称エキスパートの矛盾するメッセージに目を通しており、一方で
既存の仕事を守ろうとする彼らのスタッフからは、廊下で雑音をささやかれているのです。従って、
リスク管理やアーキテクチャの売り込みは、もっともエキサイティングな開発者のスキルではないか
も知れませんが、クラウドコンピューティングに必要なのは、私たちがクラウドコンピューティング
を企業に持ち込み、恐れを静める責任を負うことなのです。

35


複数人で 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 ファブリックとの

36


違いもまた、最終的に動作の違いが見つかったりしたり、ステージング環境で特定の機能のテストし
かできなかったりしたため、チームでできることに影響しました。私たちは、Azure ストレージをテ
スト環境として使わざるを得ませんでした。

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

証明書

チームのメンバーは、自分自身の自己証明書を使うか、私が生成して Azure にアップロードした証明
書を使うかしなければなりませんでした。チームが小さくて流動的なことから、私が生成した証明書
を使うということが決定されました。これは、良い判断だったということが分かりました。というの
は、チームのメンバーの中には時折証明のための接続がタイムアウトしているように見える現象を体
験している者がおり、その理由がはっきりしなかったのです。問題のある証明書は 1 つだけだったの
で、その利用に関する問題を解決するのはそれほど苦痛ではありませんでした。こういった方法で証
明書を共有するのは良いやり方ではありませんが、その時点では実利主義を優先せざるを得なかった
のです。チームがより大きく、長い開発サイクルのためのものだったなら、私としては、容易に削除
することができる、個人証明書を使うように各開発者に呼びかけていたことでしょう。

私たちがすぐに学んだのは、開発の初期段階においては、新しいパッケージをデプロイするためのも
っともの安全なアプローチは、まずサスペンドし、続いて削除をするということでした。これによっ
て生ずる URL の変更は、チームが小さいおかげで容易に通達できました。

うまくいかない時

Azure が Dr.Watson に吐くのを待つことしかできなかったり、Azure がロールを立ち上げようとしてい
る間、何のフィードバックもなかったりするのは、本当に頭の痛い体験です。

残念なことに、UAT を使い始めるとすぐに、私たちはステージング環境を放棄し、クライアントとサ
ードパーティの両方に URL が分かるように、ステージングの URL への変更を最小限にとどめなけれ
ばなりませんでした。システムテストのためのこの環境がなくなったということは、すなわち私の個
人的な Azure のアカウントを、ステージング環境として使わざるを得なくなったということでした。

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

まとめ

Windows Azure プラットフォームは、そのままではチーム開発に向いているとは言えないかも知れま
せんが、対処しなければならないことが分かりさえすれば、チーム開発に対する障壁は容易に克服で
きます。いつものチーム開発ツールを使った普段のアプリケーション開発と同様に、事前にちょっと
した準備をしておけば、Windows Azure プラットフォームでの開発はうまくやることができるのです。

37


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

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 FilesMicrosoft SDKsWindowsv6.0Abinmakecert" -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 を使って
パッケージを構成するのに必要となる、ロールの種類と名前が含まれています。以下に示す

38

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

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

Similar to Windows Azureプラットフォーム　現場からの報告 (20)

More from Ryuji Tamagawa

More from Ryuji Tamagawa (20)

Recently uploaded

Recently uploaded (9)