Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

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

Volume 1



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




Cover art by ...
Windows Azure プラットフォーム:現場からの報告


目次


始めに                                                  6
    編集者から                    ...
Windows Azure プラットフォーム:現場からの報告


    リスク低減のための非技術的戦略                         32
    リスク低減のための技術戦術                         ...
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
Loading in …3
×

Check these out next

1 of 106 Ad

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

Download to read offline

Eric Nelsonさんの'Windows Azure Platform: Articles from the Trenches Volume 1'(http://geekswithblogs.net/iupdateable/articles/windows-azure-platform-articles-from-the-trenches-volume-1.aspx)の翻訳です。

一部まだ手直ししたいところがありますが、まずは公開。誤字脱字、誤訳等ありましたらコメントください。少しずつ直していきたいと思ってます。

Eric Nelsonさんの'Windows Azure Platform: Articles from the Trenches Volume 1'(http://geekswithblogs.net/iupdateable/articles/windows-azure-platform-articles-from-the-trenches-volume-1.aspx)の翻訳です。

一部まだ手直ししたいところがありますが、まずは公開。誤字脱字、誤訳等ありましたらコメントください。少しずつ直していきたいと思ってます。

Advertisement
Advertisement

More Related Content

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

Advertisement

More from Ryuji Tamagawa (20)

Advertisement

Recently uploaded (20)

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

  1. 1. 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 プラットフォームの始め方から、エラスティックなアプリケ ーションへのベストプラクティスの実装までを取り上げています。
  2. 2. 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
  3. 3. Windows Azure プラットフォーム:現場からの報告 リスク低減のための非技術的戦略 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
  4. 4. Windows Azure プラットフォーム:現場からの報告 動的スキーマ 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
  5. 5. Windows Azure プラットフォーム:現場からの報告 アプリケーションのクレデンシャル 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
  6. 6. Windows Azure プラットフォーム:現場からの報告 始めに 編集者から みなさんこんにちは。 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
  7. 7. Windows Azure プラットフォーム:現場からの報告 Azure プラットフォームが進化し、広まり続ける中で、あなたは本書の次巻に著者として参加するの に十分な資格があります。 提案したい記事(複数でもかまいません)と、できれば「記事のサンプル」としてあなたのブログへ のリンクなどを付けて、私(eric.nelson@microsoft.com)にメールしてください。 7
  8. 8. Windows Azure プラットフォーム:現場からの報告 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
  9. 9. Windows Azure プラットフォーム:現場からの報告 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 はクラウドコンピューティングに対するアプローチの1つで、柔 軟性よりは抽象化やシンプルさに重点が置かれています。例:Windows Azure プラットフォ ーム。 IaaS – Infrastructure as a Service はクラウドコンピューティングに対するアプローチの1つで、 抽象化やシンプルさよりは柔軟性に重点が置かれています。例:Amazon Web Services。 コードネーム“Dallas” – Windows Azure プラットフォームの第 4 のメンバーで、現在のところ CTP。http://www.microsoft.com/WindowsAzure/dallas/ CTP – Community Technology Preview。簡単に言えば-従来のベータほどしっかりしてはいな いということ 9
  10. 10. Windows Azure プラットフォーム:現場からの報告 第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
  11. 11. Windows Azure プラットフォーム:現場からの報告 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
  12. 12. Windows Azure プラットフォーム:現場からの報告 クラウドデータベースの準備が整い、いつもの 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. 13. Windows Azure プラットフォーム:現場からの報告 13
  14. 14. Windows Azure プラットフォーム:現場からの報告 アプリケーションは、Run するまでは先ほどの URL からアクセスすることはできないので、Run を押 して、じっと、じっと、じっと待っていてください…Windows Azure のインフラストラクチャがアプ リケーションのためのプロビジョニングをするには尐し時間がかかりますが、いったん青信号になれ ば、もうこれで行けるはずです。 14
  15. 15. Windows Azure プラットフォーム:現場からの報告 これらが、Windows Azure になじむために私が行った簡単なステップです。これらのステップを踏む ことで、Windows Azure での開発は、これまでになれた開発経験とほとんど変わりないことを示すこ とができました。しかし、Windows Azure のための開発に際して、もっと複雑な検討をしなければな らないことの 1 つには、SQL Azure が提供するこれまで一般的だったリレーショナルデータベースの 代わりに、Windows Azure ストレージを潜在的に利用することになるかもしれないということがあり ます。 15
  16. 16. Windows Azure プラットフォーム:現場からの報告 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
  17. 17. Windows Azure プラットフォーム:現場からの報告 リケーション内の多くのものを管理するための、ワンストップソリューションとしての地位を確立し ています。 図 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
  18. 18. Windows Azure プラットフォーム:現場からの報告 図 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
  19. 19. Windows Azure プラットフォーム:現場からの報告 図 3 : Windows Azure MMC 19
  20. 20. Windows Azure プラットフォーム:現場からの報告 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
  21. 21. Windows Azure プラットフォーム:現場からの報告 ダッシュボードは、収集されたすべての診断情報の大局を見せてくれます。イベントビュー アー、トレースログ、インフラストラクチャログ、パフォーマンスカウンター、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
  22. 22. Windows Azure プラットフォーム:現場からの報告 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
  23. 23. Windows Azure プラットフォーム:現場からの報告 行う JSON Viewer http://jsonviewer.codeplex.com/ といった、便利な Fidder のエクステンションが登 場しています。 23
  24. 24. Windows Azure プラットフォーム:現場からの報告 第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
  25. 25. Windows Azure プラットフォーム:現場からの報告 ーショナルなクエリを使わないなら、これは理想的な選択肢になります。リレーションシップを取り 除き、データを非正規化すれば、パーティショニングを非常に容易にできます。基本的には、これが 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
  26. 26. Windows Azure プラットフォーム:現場からの報告 クライアントサイドの有効期限付きキャッシュ– 一定期間が経過した後は無効になるコンテ ントで、クライアントのブラウザがページをリクエストせず、代わりにローカルコピーが提 供されるようにする。 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
  27. 27. Windows Azure プラットフォーム:現場からの報告 ことで、ワーカーはロックの取得や解放を扱う必要がなくなり、作業アイテムを処理する仕事に集中 できます。こういったキューは、様々な異なる種類の処理で再利用できるもので、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. 28. Windows Azure プラットフォーム:現場からの報告 べました。これらのガイドラインを守れば、クラウドの主たる目的である、スケーラビリティとコス トの活用を達成できるはずです。 28
  29. 29. Windows Azure プラットフォーム:現場からの報告 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
  30. 30. Windows Azure プラットフォーム:現場からの報告 ータソースに対する変更の管理には潜在的な複雑性があるので、選択したアプローチに必要となるビ ジネスコストは、非常に重要なファクターになり得るのです。 プラットフォーム自身がコストに与える影響は、おそらく、明白にコスト指向アーキテクチャを必要 とする領域でしょう。例えば、データストレージにおける 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
  31. 31. Windows Azure プラットフォーム:現場からの報告 初めての 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
  32. 32. Windows Azure プラットフォーム:現場からの報告 がベンダーロックインを避けようとし、サービスレベルを保証し、運用やセキュリティ、パフォーマ ンスやその他の標準を管理しようとするにつれて、きわめて複雑な契約上の分岐が生じてしまうとい う、現実の問題がここにはあります。 隠れたリスク 主流の CIO の情報ソースは、扱う範囲が広いためにリスクを広めてしまいますが、主としてより技術 的な性格を持っているために、同じように現実的なものでありながら、それほど知られていないリス クが多く存在しています。 もっとも明白なのは、セキュアで信頼性があり、高性能なクラウドコンピューティングソリューショ ンを生み出すのに必要な、スキルや経験が欠けているというものです。このことはまた、パフォーマ ンスのボトルネックに対し、単純にハードウェアを投入するのに比べて、開発技術者のコストの方が 高くなってしまうという問題にも関係します。 私たちが信頼を置く、プラットフォームとツールの提供者である Microsoft でさえも、Azure が持つリ スクを抱えています。Azure テーブルやキューといったクラウド技術の、オンプレミスでの代理技術 が欠如していることによって、Azure プラットフォームへのコミットメントは、きわめて高いものに なってしまい(ベンダーロックインと同じようなものです)ますし、ツールはまだ未成熟で、継続的 インテグレーション(グレース・モリソンによる‘Using a CI build to achieve an automated deployment of your latest build’を参照)のような、認知されている技術的なプラクティスをサポートすることも用意 ではありません。 リスク低減のための非技術的戦略 究極的には、リスク管理の責任は、組織内のプロジェクトマネージャーやその他の人員に帰せられる ものですが、リスクの特定は、依然としてチームのメンバー全員の責任です。本書をダウンロードす ることで、読者はチーム内の同僚以上にクラウドコンピューティングに関する知識を得ることになっ たので、技術的な側面に踏み込む前に、より多くの責任を背負い、リスク低減の側面の中でも、コー ドとは関わらない部分に対処しなければならないでしょう。 正しいアプリケーションの選択 シンプルで、クラウドコンピューティングにより適しているものを選択しましょう。それは例えば、 公開され、要求のピークがあるかもしれないようなものです。機微なデータを含んでいたり、他の多 くのシステムと統合されたり、既存のレガシーシステムからのマイグレーションであったり、多くの 伝統的なデータベースストレージやレポートを含んでいたりするアプリケーションに取り組む前に、 こういった例での成功を積み上げましょう。 早めに始める そのプロジェクトが、目立たなくてつまらない開発を行うものだったとしても、企業における法務、 コンプライアンス、運用、財務、監査やその他の部門との関わりは、通常より早めに始めなければな りません。通常は、既存のデータセンターに新しい Web サイトを立ち上げる心配などはしませんが、 32
  33. 33. Windows Azure プラットフォーム:現場からの報告 仮に筋を通さずにクラウドコンピューティングのアプリケーションを立ち上げて周りの人々を驚かせ るようなことをすれば、そのアプリケーションは信頼してもらえないことでしょう。 価格と運用モデルの理解 表面的にはシンプルに見えるかも知れませんが、クラウドコンピューティングの価格、課金、SLA や その他の事項を深く見ていけば、法的な部分やコンプライアンス、部門間の調整などへの広範な影響 があり、それらは複雑なものかも知れません。尐なくとも、推定される要求事項を付けて Azure の価 格を記載したスプレッドシートと、注記付きの SLA のプリントアウトを、プロジェクトの出資者に渡 しておかなければなりません。 影響の理解 完全な脅威モデルを扱う必要はないかも知れませんが、アプリケーションに問題があったり、データ が失われた場合に考えられる、財務面や風評面、あるいはその他の面でのリスクについては理解して おく必要があります。損失の影響を理解したら、クラウドにどういったデータをどれだけの期間保存 するのか、そしてそれをオンプレミスのストレージに移動させるかどうかといったことのアプローチ に、それを反映させるべきです。 オンプレミスのリスクに精通する クラウドコンピューティングにはセキュリティリスクがあると見なされているので、セキュリティに 焦点を当てるということは、しばしばそのソリューションが対応するオンプレミスの部分よりもセキ ュアであるということを意味します。クラウドコンピューティングのリスクに対応する際には、必ず それらのリスクを、既存のオンプレミスプラットフォームにある既存の日常的なリスクと比較してく ださい。必ずしも、すべてのソリューションやネットワーク、その他のインフラストラクチャが、実 際に約束していたとおりの可用性やセキュリティを達成しているとは限らないのです。 リスクへの欲求を理解する 銀行などのように、追加のリスクを尐なくとも今年は取りたがらない、リスクを嫌う企業に比べ、ス タートアップ企業は企業文化として、クラウドコンピューティングのリスクを、企業全体として持っ ているリスクの一部として見なすことができます。より成熟した企業は、リスク管理のためのプロセ スや委員会を持ち、最終的にはプロジェクトのスポンサーの責任になるかも知れませんが、大きなア イデアを実現しようとする前には、その組織がリスクをとれるかどうかの感触を得ておかなければな りません。 リスク低減のための技術戦術 HOW EXTREME? Microsoft は、古き良き ASP.NET Web アプリケーションを、その下位層の SQL データベースと共に、 Azure クラウドに最小限の変更で投入するのを、きわめてシンプルなことにしました。一方で、クラ ウドコンピューティングの環境に最適化された、十分検討されたアーキテクチャを持つソリューショ 33
  34. 34. Windows Azure プラットフォーム:現場からの報告 ンを構築することは、より難しく、手間がかかり、リスクを伴うことです。システムの構築を、リス クを回避する環境で行い、クラウド用にする必要がないのであれば、Azure ストレージ、Worker プロ セス、フェデレーテッド認証管理やその他のクラウド固有の技術は使わずに、web ロールと SQL デー タベースでシンプルなソリューションを構築しましょう。どちらのアプローチを取るにしても、 Azure はそのアプローチをうまくサポートしてくれますが、魅力的な新機能が実際にはどれだけ必要 なものなのかを見極め、早めに決断を下しておかなければなりません。 データへのアプローチの決定 クラウドコンピューティングのリスクに関する限り、もっとも重要で活発な問題はデータであり、こ れに関してはソリューション設計の初期の段階で検討しなければなりません。ありがたいことに、必 要な場合はおなじみのデータベースプラットフォームを SQL Azure で利用すれば、NoSQL 的な Azure テーブルに関する多くの問題やリスクには対処できますが、Azure を使う優れたアーキテクチャでは、 最終的には Azure ストレージやキャッシュ、あるいはその他の技術を検討する必要があるでしょう。 Azure クラウドのストレージをどう使ったとしても、依然としてそのデータはクラウドの中にあり、 構築するアーキテクチャでそのデータを扱わなければならないという問題は残ります。レポートや他 のシステムのとの統合のため、あるいはただ単にデータの安全性のために、Azure からオンプレミス のデータベースへ、データを移動したりコピーしたりする要求があるかも知れません。 エンジニアリングコストの管理 それなりのサイズのアプリケーションを Azure 上で構築し、それをライブ環境へデプロイするまでは、 隠れたままになっている技術的な課題があるものです。本書を読むことで、読者は正しい方向性に向 かい、他者の経験から学ぼうとしているわけですが、単なる読書や、実作業から学ぶ以上のことをや る必要があります。まだ見ぬ落とし穴のインパクトをとにかく低減するためには、ツールをインスト ールし、コードを書いてデプロイし、負荷をかけ、スケールアップし、スケールダウンし、デバッグ し、診断を行い、見たことのないたくさんのパターンや技術に取り組まなければならないのです。 優れたエンジニアリングプラクティスの下での実装 あなたの初めての Azure アプリケーションの未来は、全く不確かなものです-2 年先を考えてみても、 アーキテクチャ上の選択が正しかったかどうかははっきりせず、技術的な構成要素は追加されたり廃 棄されたりしており、規制は変更されていたり、クラウドコンピューティングに対するあなたの会社 の態度も変わっているかも知れません。安定するまでに数年もかかるような環境下では、ソフトウェ ア職人気質からわき上がる、メンテナンス性、テスタビリティ、拡張性といった懸念は、増幅される ものです。.NET のエコシステムにおいて、十分に確立されたプラットフォームと、新しい技術、ア プローチ、考え方が組み合わさった Azure は、私たちが直面しているリスクを低減できるよう適切に ソリューションを構築するための、要求とフレームワークの両方を、私たちが手にしていることを意 味しているのです。テスタビリティ、IoC、疎結合、あるいはその他のソフトウエア職人の技法 は、.NET プラットフォーム上で十分サポートされ、理解され、議論されてきており、従って(もち ろんのこと)Azure に持ち込むこともできるのです。技術者は、一見簡単に見える単一階層のモノリ シックなアーキテクチャとして、これらの技術を磨かなければならず、 34
  35. 35. Windows Azure プラットフォーム:現場からの報告 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
  36. 36. Windows Azure プラットフォーム:現場からの報告 複数人で 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
  37. 37. Windows Azure プラットフォーム:現場からの報告 違いもまた、最終的に動作の違いが見つかったりしたり、ステージング環境で特定の機能のテストし かできなかったりしたため、チームでできることに影響しました。私たちは、Azure ストレージをテ スト環境として使わざるを得ませんでした。 ここからは楽になると予想していましたが、しかし…そう、これはいくつもの「しかし」の内の 1 つ でしかありません。 証明書 チームのメンバーは、自分自身の自己証明書を使うか、私が生成して Azure にアップロードした証明 書を使うかしなければなりませんでした。チームが小さくて流動的なことから、私が生成した証明書 を使うということが決定されました。これは、良い判断だったということが分かりました。というの は、チームのメンバーの中には時折証明のための接続がタイムアウトしているように見える現象を体 験している者がおり、その理由がはっきりしなかったのです。問題のある証明書は 1 つだけだったの で、その利用に関する問題を解決するのはそれほど苦痛ではありませんでした。こういった方法で証 明書を共有するのは良いやり方ではありませんが、その時点では実利主義を優先せざるを得なかった のです。チームがより大きく、長い開発サイクルのためのものだったなら、私としては、容易に削除 することができる、個人証明書を使うように各開発者に呼びかけていたことでしょう。 私たちがすぐに学んだのは、開発の初期段階においては、新しいパッケージをデプロイするためのも っともの安全なアプローチは、まずサスペンドし、続いて削除をするということでした。これによっ て生ずる URL の変更は、チームが小さいおかげで容易に通達できました。 うまくいかない時 Azure が Dr.Watson に吐くのを待つことしかできなかったり、Azure がロールを立ち上げようとしてい る間、何のフィードバックもなかったりするのは、本当に頭の痛い体験です。 残念なことに、UAT を使い始めるとすぐに、私たちはステージング環境を放棄し、クライアントとサ ードパーティの両方に URL が分かるように、ステージングの URL への変更を最小限にとどめなけれ ばなりませんでした。システムテストのためのこの環境がなくなったということは、すなわち私の個 人的な Azure のアカウントを、ステージング環境として使わざるを得なくなったということでした。 最終的には、私たちはデプロイメントを自動化しましたが、それはこの記事で書くには長すぎる物語 です。 まとめ Windows Azure プラットフォームは、そのままではチーム開発に向いているとは言えないかも知れま せんが、対処しなければならないことが分かりさえすれば、チーム開発に対する障壁は容易に克服で きます。いつものチーム開発ツールを使った普段のアプリケーション開発と同様に、事前にちょっと した準備をしておけば、Windows Azure プラットフォームでの開発はうまくやることができるのです。 37
  38. 38. Windows Azure プラットフォーム:現場からの報告 継続的インテグレーションビルドを利用した 、最新ビルドの自動化の実現 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

×