さて Part 1. のエントリでは、業務処理の終了パターンの分類と、各アプリケーションタイプにおける基本的な実装パターンを整理しました。要点をまとめると、以下のようになります。

• 業務処理の終了パターンは、以下のように分類される。
  
• 突き合わせエラーについては、バックエンドのモジュール（BC や DAC）との連携によるチェック作業が必要になる。UI 部単体でチェックが可能なのは、単体入力エラーに限られる。

.NET Framework では、UI 開発技術として、ASP.NET, Silverlight, WPF, Windows フォームなど、様々なテクノロジが提供されています。これらの技術には、いずれにも、UI 部において、単体入力エラーチェックを効率よく実装していくための機能が備わっています。（これらの機能は、いずれも単体入力チェックを効率よく実装するための機能であり、突き合わせエラーのチェックや、システムエラーに関する対処を実装するための機能ではありません。いや無理矢理使えば使えるかもしれませんが；、それはこれらの機能が用意された目的や意図とはズレた使い方だと考えるべきだと思います。）

• ① ASP.NET Web フォーム ： 入力検証コントロール
• ② Silverlight 3, WPF 3 ： 例外ベースの双方向データバインド
• ③ Windows フォーム 2.0, WPF 3.5 ： IDataErrorInfo ベースの双方向データバインド

さてこれらの機能は、いずれも「単体入力チェックを行う」「フィールド単位のチェックとインスタンス単位のチェックを行う」という点においては違いがありません。しかし、その実装方法や、エラーチェックに対する考え方は、全くといっていいほど違います。この実装方法の特性の違いを理解しておかないと、単体入力エラーチェックをうまく実装できないばかりか、開発生産性をかえって大幅に損なう結果に繋がりかねません。特に、ASP.NET Web アプリケーション開発の入力検証コントロールの使い方に慣れた人が、Windows フォームや WPF などのテクノロジを遣うと、おそらく入力検証のやり方が全くといっていいほど違うため、相当に戸惑うことになるはずです。（というよりも私はむちゃくちゃ戸惑いましたよ．．．．orz）

本エントリの目的は、これらの各テクノロジにおける、実装パターンの違い（実装方法やエラーチェックに対する考え方の違い）を明確化することです。

• ① ASP.NET Web フォーム ： 入力検証コントロール
  検証コントロールを使って、「正しい文字列」を作成する方式
• ② Silverlight 3, WPF 3 ： 例外ベースの双方向データバインド
  双方向データバインドを使うものの、反映に失敗するケースがある方式
• ③ Windows フォーム 2.0, WPF 3.5 ： IDataErrorInfo ベースの双方向データバインド
  双方向データバインドを使うが、反映に失敗するケースがない方式

なお、以下に順番に各テクノロジの実装方式を解説していきますが、基本的にはどのテクノロジであっても、UI 部でやるべきことは以下の 3 つです。

• UI 上のテキストボックスなどから値を入力してもらう
• 入力された値を、コードビハインドのデータ変数に取り出す
• 単体入力チェックが済んだ値を、BC/DAC に送出する

実装テクノロジによる差異は、下線部のやり方の部分に出てきます。この点を意識しながら、以降の解説を読んでください。

※ （参考）なお本エントリは、各テクノロジでの単体入力エラーチェックの実装方法について、ある程度知識がある、という前提で解説を進めます。もし、各テクノロジでの単体入力エラーチェックの実装方法をまったく知らないという場合には、以下の情報を併読されることをお勧めします。

• ① ASP.NET Web フォーム ： 入力検証コントロール
  Visual Studio 2005 による Web アプリケーション構築技法 : 第 5 章 入力検証コントロール
• ② Silverlight 3, WPF 3 ： 例外ベースの双方向データバインド
  MSDN : データバインディング（Silverlight 2）
  MSDN Magazine : データ バインドと WPF でデータの表示をカスタマイズする
• ③ Windows フォーム 2.0, WPF 3.5 ： IDataErrorInfo ベースの双方向データバインド
  とあるコンサルタントの blog : スマートクライアントにおける単体入力データ検証

※ （注意）また本エントリは、各データ検証方式の考え方の違いを明確化することを狙っていますので、解説をかなり単純化しています。例えば、Silverlight 3 には、①に近いデータ検証を可能とする ValidationRule や、属性ベースでデータ検証を行う DataAnnotation などの機能が備わっていますが、これらについては触れません。詳細にデータ検証をご存じの方は「え゛ー？」とツッコミ入れたいところがたくさんあると思いますが、そこはちょっとだけ目をつぶっていただけるとうれしいです^^。

では、以下に順番に解説していきます。

［① ASP.NET Web フォームの場合：入力検証コントロール］

ASP.NET Web フォームの場合、単体入力チェックは検証コントロールを使って実装します。

• 4 種類の標準のチェックロジックが用意されています。
  （必須入力チェック、フォーマットチェック、比較チェック、範囲チェック）
• 上記の 4 種類でカバーできないチェックは、CustomValidator を使って自力で実装します。
  （インスタンス単位の単体入力チェックなどは、CustomValidator で実装します）

この場合の、UI 部のコードビハインドの制御コード（ボタン押下のイベントハンドラのコード）は以下のようになります。

このコードについて、改めてじっくり考えてみると、以下のような特徴があることがわかります。

• ASP.NET Web フォームの検証コントロールは、「テキストボックスに、適切な値を作る」ように動作します。
• 検証コントロールによるチェックを通過できていれば（IsValid = true なら）、データ変数への取り出しや型変換などで失敗したりすることは絶対にありません。つまり、コードビハインド内で値をテキストボックスから取り出す際には、すでに単体入力チェックが終わっている状態になっている、ということになります。
• ただし、UI からコードビハインド内へのデータ取り出し作業自体は、自力で記述する必要があります。

上記のような特性は、Silverlight や WPF、Windows フォームなどとは全く異なります。

まず、一般的に、Silverlight, WPF, Windows フォームといった、リッチクライアント系のアプリケーション開発技術では、通常、双方向データバインドと呼ばれるテクニックを用いて、データ検証とデータ取り出しを同時に行います。

Silverlight, WPF, Windows フォームそれぞれで、双方向データバインドの実装方法は少しずつ異なりますが、根本にある基本的な考え方は、「UI コントロールの表示と、データソースオブジェクト間の値を、双方向にリアルタイムに同期させる」というものです。このため、双方向データバインドを利用すると、UI コントロールからのデータ取り出し作業（例：string customerName = tbxCustomerName.Text; などといった取り出し作業や、decimal price = decimal.Parse(tbxPrice.Text); といったパース処理）が不要となり、バインドされているオブジェクトを、UI から入力されたデータであるとみなしてそのまま使うことができます。これが、双方向データバインドを用いたデータ入力制御の根底にある、基本的な考え方です。

しかし、双方向データバインドにおける入力データの検証方法（単体入力チェック方法）に関しては、いくつかの方法があります。.NET Framework 内で使われている双方向データバインド時のデータ検証方法は、大別すると以下の 2 つに分類されます。

• ② Silverlight 3, WPF 3 ： 例外ベースの双方向データバインド
• ③ Windows フォーム 2.0, WPF 3.5 ： IDataErrorInfo ベースの双方向データバインド

これらは、単体入力チェックロジックを持たせる場所と持たせる方法に違いがあり、また双方向データバインドの挙動についても多少の違いがあります。このため、以下に順番に解説していきます。

［② Silverlight 3, WPF 3 の場合：例外ベースの双方向データバインド］

まず、Silverlight 3, WPF 3 の場合について解説します。これらの場合には、以下のようにして単体入力チェックロジックを実装します。

• バインドするオブジェクト側に、フィールド単位のデータチェックロジックを持たせる。
  具体的には、下図 A のように、バインドオブジェクトのプロパティ setter に対して、フィールド単位のチェックロジックを持たせる。もし、UI から不適切なデータが投入された（テキストボックスから不適切な値が入力された）場合には、例外（通常は ArgumentException 例外）を throw し、値を受け取らないようにする。
• 双方向データバインドの "ValidatesOnException" 機能を使う。
  具体的には、下図 B のように、UI 部（XAML コード）にて、バインドするオブジェクトの各プロパティと、UI 項目との紐付けを行う。これにより、UI 部から入力された値が、バインドされたオブジェクトに自動反映されるようになる。ここで、ValidatesOnException 機能を有効化しておくと、バインドオブジェクトのプロパティへの反映時に失敗した場合（＝例外が throw された場合）、これをエラーメッセージとして赤枠やツールチップにより表示してくれるようになる。
  （※ エラーメッセージを赤枠やツールチップ表示するためには適切なスタイル定義が必要ですが、これについてはサンプルコードを参照してください。）

A. 例外ベース双方向データバインドで利用する、バインドオブジェクトの実装例

B. 例外ベース双方向データバインドでの、双方向データバインドの実装例（UI 部）

さて、一見するとわかりやすそうなこの実装方法ですが、実際には厄介な問題を抱えています。それが、UI 上に実際に表示されている値と、バインドされたオブジェクトが持っている値とのずれです。

例えば上記のアプリケーションに対して、下記のような操作を行った場合（オブジェクトへの反映に成功したり失敗したりするケースが混在する場合）を考えてみてください。

• 顧客 ID として “3214” を設定する。（→ 反映に成功する）
• 顧客 ID を “12345” に変更する。（→ 顧客 ID は 4 桁英数大文字のため、反映に失敗する）
• 顧客名として “Nobuyuki” を設定する。（→ 反映に成功する）
• 生年月日として “1973/06/07” を設定する。（→ 反映に成功する）
• 生年月日を “1973/55/41” に変更する。（→ 日付として正しくないため、反映に失敗する）

この場合、UI 上に表示されている値と、バインドされたオブジェクトの中に設定されている値とがずれています。このため、業務処理のために UI から入力された値を使おう、と思った場合には、まず、双方向データバインドにエラー（反映失敗）があるか否かを確認する必要があります。バインドされたオブジェクトの中に入っている値をいきなり使うと、実は UI から入力された過去の正しい値を使ってしまうことがある、ということになってしまいます。

また、次のような問題もあります。一般的なデータエントリシートの場合、最初に画面を表示した際には何も記入されていないのが普通でしょう。しかし、そのためには、バインドされたオブジェクト側が空の状態（例えば null や空文字が入っている）でなければなりません。がしかし、このようなオブジェクトは、そもそも値として、本来正しくない値を抱えている状態になっています。

また、インスタンス単位の単体入力チェックを行うロジックについては、バインドオブジェクトに持たせることができません（この例だと電話番号と電子メールアドレスの少なくとも片方が入力されている、というチェック）。なぜなら、電話番号と電子メールの入力項目は、UI からずれたタイミングでひとつずつバインドオブジェクトに反映されてくるため、バインドオブジェクト側のフィールドに持たせることが困難だからです。

こうした事情から、例外ベースの双方向データパインドでは、UI 部のボタン押下のイベントハンドラを、以下のように実装することになります。

• まず、バインドにエラーが発生していないか否かをチェックし、フィールド単位の単体入力エラーがあるか否かをチェックする。
• 次に、バインドされたオブジェクトを見て、インスタンス単位の単体入力エラーがあるか否かをチェックする。
• 最後に、バインドされたオブジェクトに含まれるデータを使って、業務処理を行う。

つまり、ここまでの解説をまとめると、例外ベースの双方向データバインドの動作イメージは以下の通りになります。

• バインドエラーがない場合に限り、UI からの入力がすべてバインドオブジェクトに反映されている、という動作になる。このためイベントハンドラ内では、まずバインドエラーのチェックが必要。
• 仮にバインドエラーがなかったとしても、インスタンス単位のチェックをイベントハンドラ内で行う必要がある。

例外ベースの双方向データバインドでは、バインドオブジェクト側に、例外を使った検証ロジックを持たせているのですが、これは、バインドオブジェクトが不正な状態になることがないようにする、という考え方に基づいています。この考え方は、それだけ見ると、一般的なオブジェクト指向設計の考え方からして特に間違ってはいません。ところが、双方向データパインドは、UI 表示とバインドオブジェクトの内容との二点間同期を保つ、という考え方に基づいているため、根本的なところで概念的な相反があります。このため、上記のような厄介な実装上の工夫を行わなければならなくなるのだろうと思います。

しかし次に解説する、IDataErrorInfo ベースの双方向データバインドでは、このような概念的な相反は発生しません。

［③ Windows フォーム 2.0, WPF 3.5 ： IDataErrorInfo ベースの双方向データバインド］

引き続き、Windows フォーム 2.0 や WPF 3.5 で導入されている、IDataErrorInfo ベースの双方向データバインドについて解説します。

IDataErrorInfo ベースの双方向データバインドでは、バインドオブジェクト側に、IDataErrorInfo というインタフェースを持たせます。このインタフェースは、オブジェクトインスタンス内部にエラーが含まれていることを、文字列情報として返すためのもので、これを使うことにより、前述の問題をきれいに解決することができます。

IDataErrorInfo インタフェースを持つバインドオブジェクトの実装例は後述しますので、まず先に概念図を示しましょう。IDataErrorInfo ベースの双方データパインドでは、以下のようにしてデータバインドを行います。

• 入力値が正しかろうと間違っていようと、とにかくオブジェクトに反映してしまう。
• オブジェクトインスタンスが不正な状態にある場合には、これを IDataErrorInfo インタフェースから公開する。
• これにより、常に UI とオブジェクト内の値とが同期される。

前述したように、双方向データバインドは、UI とバインドオブジェクトのデータを常に同期させる技術でした。この際、データとして誤りのある内容が UI から入力された場合にオブジェクトに反映させるのかどうか、が問題になったわけですが、IDataErrorInfo ベースの双方向データバインドでは、入力内容を常にオブジェクトに反映させます。すると、バインドオブジェクトが「単体入力エラーを含んだデータを抱える」ことになります。この単体入力エラーに関する情報を IDataErrorInfo インタフェースから公開させ、これを UI コントロールに拾わせて、画面上に表示を行う、ということをするわけです。

IDataErrorInfo インタフェースを持つバインドオブジェクトの実装コード例を以下に示します。

   1:using System;

   2:using System.Collections.Generic;

   3:using System.Text;

   4:using System.ComponentModel;

   5:using System.Text.RegularExpressions;

   6:  

   7:namespace WindowsFormsApplication1

   8: {

   9:publicclass CustomerInput : IDataErrorInfo

  10:     {

  11:private Dictionary<string, string> _errors = new Dictionary<string, string>();

  12:  

  13:privatestring _id;

  14:publicstring ID

  15:         {

  16:             get { return _id; }

  17:             set

  18:             {

  19:                 _id = value;

  20:if (value == null)

  21:                 {

  22:                     _errors["ID"] = "ID は必須入力項目です。";

  23:                 }

  24:elseif (Regex.IsMatch(value, @"^[0-9A-Z]{4}$") == false)

  25:                 {

  26:                     _errors["ID"] = "ID は半角英数大文字 4 文字です。";

  27:                 }

  28:else

  29:                 {

  30:                     _errors.Remove("ID");

  31:                 }

  32:             }

  33:         }

  34:  

  35:privatestring _name;

  36:publicstring Name

  37:         {

  38:             get { return _name; }

  39:             set

  40:             {

  41:                 _name = value;

  42:if (value == null || value == "")

  43:                 {

  44:                     _errors["Name"] = "名前は必須入力項目です。";

  45:                 }

  46:elseif (Regex.IsMatch(value, @"^[\u0020-\u007e]{1,40}$") == false)

  47:                 {

  48:                     _errors["ID"] = "名前は半角英数文字 40 字以内で入力してください。";

  49:                 }

  50:else

  51:                 {

  52:                     _errors.Remove("Name");

  53:                 }

  54:             }

  55:         }

  56:  

  57:privatestring _email;

  58:publicstring Email

  59:         {

  60:             get { return _email; }

  61:             set

  62:             {

  63:                 _email = value;

  64:if (value == null || Regex.IsMatch(value, @"\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*"))

  65:                 {

  66:                     _errors.Remove("Email");

  67:                 }

  68:else

  69:                 {

  70:                     _errors["Email"] = "電子メールアドレスとして有効な値を入力してください。";

  71:                 }

  72:             }

  73:         }

  74:  

  75:privatestring _phone;

  76:publicstring Phone

  77:         {

  78:             get { return _phone; }

  79:             set

  80:             {

  81:                 _phone = value;

  82:if (value == null || Regex.IsMatch(value, @"(0\d{1,4}-|\(0\d{1,4}\) ?)?\d{1,4}-\d{4}"))

  83:                 {

  84:                     _errors.Remove("Phone");

  85:                 }

  86:else

  87:                 {

  88:                     _errors["Phone"] = "電話番号は (03)1234-5678 のように入力してください。";

  89:                 }

  90:             }

  91:         }

  92:  

  93:public DateTime? Birthday { get; set; }

  94:  

  95:// 全体整合チェック

  96:publicstring Error

  97:         {

  98:             get

  99:             {

 100:if (_email == null&& _phone == null)

 101:                 {

 102:return"電子メールアドレスか電話番号かのいずれか一方は必須入力です。";

 103:                 }

 104:else

 105:                 {

 106:returnnull;

 107:                 }

 108:             }

 109:         }

 110:  

 111:publicbool HasErrors

 112:         {

 113:             get { return (_errors.Count != 0 || Error != null); }

 114:         }

 115:  

 116:publicstringthis[string columnName]

 117:         {

 118:             get

 119:             {

 120:return (_errors.ContainsKey(columnName) ? _errors[columnName] : null);

 121:             }

 122:         }

 123:     }

 124: }

コード中の 95 行目～122 行目が、IDataErrorInfo インタフェースにかかわる部分ですが、コードのポイントをピックアップすると以下のようになります。

• バインドオブジェクトの各プロパティは、たとえ単体入力エラーがあるデータであったとしても、とりあえずデータを受け取ります。かわりに、内部にエラー情報（エラーメッセージ）を蓄積しておきます。 
  
• IDataErrorInfo インタフェースには、Error プロパティ（オブジェクトインスタンス全体にかかわるインスタンス単位の単体入力エラー情報を返すためのもの）と、プロパティ名を使ったインデクサ（フィールド単位の単体入力エラー情報を返すためのもの）があります。これらを使って、単体入力エラー情報を UI 部に対して返します。 
  

Windows フォーム 2.0 を使う場合には、UI 側に ErrorProvider コントロールを張り付けておきます。このようにしておくと、ErrorProvider コントロールがバインドされたオブジェクトの IDataErrorInfo インタフェースから自動的にエラー情報を取り出し、画面上にエラーメッセージを表示してくれるようになります。（※ 実装方法の詳細は、こちらのエントリを見てください。）

また、バインドされたオブジェクトにエラーがあるか否かは、バインドオブジェクトのみを見れば簡単に調べることができます。このため、UI 部のイベントハンドラ（Button_Click イベント）のコードは、以下のように非常に簡単になります。

このように、IDataErrorInfo インタフェースベースの双方向データバインドを使うと、綺麗な形での単体入力データチェックが実装できます。全体像を示すと以下の通りになります。

スマートクライアントにおける、双方向データバインドと IDataErrorInfo インタフェースを用いた単体入力チェックロジックの実装モデルには、以下のような特徴があります。

• 単体入力チェック処理を、バインドオブジェクトに固めることができる。
  このため、モジュールの役割分担が明確になる上に、単体入力チェックロジック部分だけを重点的に単体機能テストすることもできます。
• コードビハインドの記述が簡単になる。
  コードビハインドのイベントハンドラでは、バインドオブジェクトだけを操作すればよく、UI コントロールを触る必要がなくなります。このため、コードビハインドのコードの見通しも非常によくなります。
• 入力仕掛り状態の維持が簡単にできる。
  バインドオブジェクトをそのままシリアル化して保存すれば、入力しかけのデータをそのまま保存しておくこともできます。

実装モデルが非常に綺麗になるので、ぜひ覚えておくとよいでしょう。

※ （注意） このモデルは Windows アプリケーションなどでは有効ですが、Web アプリケーションでは有効ではありません。なぜなら、Web アプリケーションでは、データが入力される場所（＝ブラウザ上）と、データを取り出す場所（＝サーバサイド）が分かれており、UI からリアルタイムでデータを取り出すことができないためです。

［3 つの単体入力チェック方式の比較］

さて、ここまでの解説を整理しつつ比較してみると、3 つの単体入力チェック方式には以下のような違いがあることがわかります。

ここで重要なのは、単体入力チェックモデルの優劣を議論することではありません。というのも、ぶっちゃけ、どのモデルを使ったところで単体入力チェックは実装できるわけで、好みの違いはあれど、どのモデルがより優れている、といった議論は宗教論争になりかねません；。そうではなくて、自分が業務アプリケーションを実装する際に、どのモデルを使って単体入力チェックを実装しようとしているのかを意識することが重要です。実際、.NET Framework の中に標準で含まれるデータ入力検証フレームワークを見ても 3 通りはあるわけで（実は私が気付いていないもっと別のモデルもあるかもしれません…とつぶやいておく；）、これらをごちゃまぜにしたような実装は避けなければなりません。

アプリケーションを実装する際は、一貫性が非常に重要です。どの方式を選ぶにせよ、ある特定のアプリケーションの中では「このパターンで実装する」といった具合に、モデルを定めて実装するようにしてください。

※ （参考） さらに追加のつぶ��きですが、よくこうした単体データ入力検証フレームワークに関して、「○○のタイミングでエラーメッセージを表示できるようにできませんか？」「○○のような方式でエラーメッセージを表示できるようにできませんか？」といったことを聞かれます。こうしたカスタマイズは、できる場合とできない場合とがあります。というのも、もともとフレームワークというものは、「動作モデルに制約を加えるかわりに、開発生産性を大きく向上させよう」というコンセプトで作られているものであって、「どんなふうに動作させるものであっても開発生産性がよくなるもの（万能薬）」ではないからです。もし、.NET Framework などが標準で備える入力検証フレームワークの動作ではお客様要件を満たせない、ということであれば、独自に単体データ入力検証フレームワークを作成するか、または既存の単体データ入力検証フレームワークにカスタマイズを加えるしかありません。一般には、こうした問題が極力発生しないように、UI 設計段階（＝業務設計段階）から、ある程度実装効率というものを意識して、フレームワークの想定している動作に併せた形での設計を行うようにします。

［まとめ］

というわけで、ここまで .NET Framework が備えている各種の単体データ入力検証フレームワークに関して、その実装モデルの違いを解説してきましたが、最も重要なポイントをまとめると、以下のようになります。

• 単体データ入力検証フレームワークを使う上では、そもそも業務エラーとシステムエラーの分類や、単体入力エラーの分類を正しく行うことが必要になる。
• .NET Framework が備えている各種の単体入力エラーチェック機能は、下図の枠線内の実装（開発効率）を高めるためのものである。
  

また、単体入力チェックに対するアプローチは、ランタイムによってかなり異なります。

• ① ASP.NET Web フォーム ： 入力検証コントロール
  検証コントロールを使って、「正しい文字列」を作成する方式
• ② Silverlight 3, WPF 3 ： 例外ベースの双方向データバインド
  双方向データバインドを使うものの、反映に失敗するケースがある方式
• ③ Windows フォーム 2.0, WPF 3.5 ： IDataErrorInfo ベースの双方向データバインド
  双方向データバインドを使うが、反映に失敗するケースがない方式

これらはそれぞれに特徴があるので、データ検証に対する考え方をよく理解した上で活用することが重要です。本エントリを参考にして、さらに優れた業務アプリケーション開発を目指していただければ幸いです。

というわけで、みなさま明けましておめでとうございます。更新が滞っているこの blog ですが、面白いネタがないとなかなかエントリを作成できないのも本音なところ。がしかし、今年最初のビックニュースはなんといっても 1 月から始まった Windows Azure の商用ラウンチ。興味がある方も非常に多いと思いますが、「そもそも Windows Azure ってなによ？」というのがなかなか分からない、という方も多いと思います。実際、いろいろなところで話を伺うと、以下のものが混同されているような場合が少なからずありました。

• クラウドコンピューティング
• S+S （Software plus Services）
• Windows Azure （コンピュートサービス／ストレージサービス）
• Windows Azure Platform

そこで今回は、技術者向けに Windows Azure Platform がどのようなものなのかについて解説したいと思います。

※ あくまで技術者向けの資料として書きますので、ビジネス寄りの話や、お茶を濁すような書き方は敢えて避けたいと思います。（その方が、現場のエンジニアにとってはわかりやすいと思いますので。）

Part 1. マイクロソフトのクラウドコンピューティング “S+S” 概要（その1, その2, その3）

• クラウドコンピューティングとは何か
• マイクロソフトの製品とサービスの分類
• インフラから見た場合のシステム形態の分類
• 利用者から見た場合のシステム形態の分類
• クラウドコンピューティング時代のビジネスチャンス
• クラウドコンピューティングに関する FAQ

Part 2. Windows Azure Platform 概要（その1, その2, その3）

• Windows Azure Platform とは何か
• Windows Azure Platform の主要構成要素
  ① Windows Azure コンピュートサービス
  ② Windows Azure ストレージサービス
  ③ SQL Azure データベースサービス
• 開発上の注意点

Part 3. Hello World, Windows Azure アプリケーションの開発（その1, その2, その3, その4）

• ローカルでの Web アプリケーション開発
• クラウドサービスプロジェクトの追加
• 開発用ファブリック上での動作確認
• Diagnostic Monitor によるアプリケーション監視
• Azure 運用環境への展開
• アプリケーションの修正と Azure 環境への再配置（アップグレード）
• Windows Azure 運用環境を安く使うためのコツ

※ なお、本エントリは 2010/01 現在の情報を元に書かれています。今後、Windows Azure Platform やマイクロソフトのクラウドコンピューティング戦略の強化や変更に伴って修正される場所も出てくると思いますが、悪しからずご了承ください。

※ また、クラウドコンピューティングに対する分類や考え方についてはまだ流動的であるため、少なからず nakama 独自の考え方や見解が含まれています。必ずしもマイクロソフトの公式見解というわけではない、ということを含みおいてエントリをお読みいただければ幸いです。

では、さっそく始めましょう。

さて、今回のエントリは Windows Azure Platform について解説するわけですが、Windows Azure Platform は実際のところ、既存のシステムの在り方をすべてリプレースするような、万能なサービスというわけではありません。このため、Azure を利用するにあたっては、そもそも Azure というものが、マイクロソフトの製品やサービスの中でどのような位置付けにあるものなのかを正しく理解することが重要です。そして、マイクロソフトの製品やサービスの中での Windows Azure の位置づけを理解するためには、マイクロソフトのクラウドコ��ピューティング戦略である “S+S” （Software plus Services）の概要と、それがもたらすコンピューティングシステムの変化を理解しなければなません。

そこで Part 1. となる本エントリでは、まず、マイクロソフトのクラウドコンピューティング戦略 “S+S” がどのようなものなのかについて、技術者向けに解説してみたいと思います。ちょっと長めのエントリですが、お付き合いいただければ幸いです。

［Agenda］

• クラウドコンピューティングとは何か
• マイクロソフトの製品とサービスの分類
• インフラから見た場合のシステム形態の分類
• 利用者から見た場合のシステム形態の分類
• クラウドコンピューティング時代のビジネスチャンス
• クラウドコンピューティングに関する FAQ

では、順番に解説していきましょう。

［クラウドコンピューティングとは何か］

非常におおざっぱに言うと、「クラウドコンピューティング」とは、ネットワークを介して提供される「サービス」を利用するシステム形態のことを指す用語です。ネットワーク（主にインターネット）の向こう側にあるサーバ群やシステムがどのような構成になっているのかはよく分からないけれど、ユーザが、そうしたサーバの中身やシステムの構成などを意識することなくサービスを享受することができる、というのがクラウドコンピューティングの肝になります。

上記は、「クラウドコンピューティング」という用語に関する教科書的な説明ですが、もう少し技術的に説明すると、以下のようになります。

一般的に、コンピュータシステムは、以下の 3 つのレイヤの積み上げにより動作します。（※ アプリ／ミドル／インフラの境界線は曖昧ですので、あくまで概念的なおおざっぱな分類だと思ってください。）

• インフラ ： ハードウェア（PC、ディスクストレージ）、収容施設など
• ミドルウェア ： OS や RDBMS、アプリケーションランタイムなど
• アプリケーション ： 業務アプリケーションやビジネスアプリケーション、ゲームアプリケーションなど

従来のコンピュータシステム（例えばみなさんが今使っているパソコン）は、これらのすべてを自前で所有します。例えば、ハードウェアを購入し、OS を買ってきて、アプリをインストールして動かす。このような形態を、オンプレミス型のシステムと呼びます（上図の一番左）。

しかし、ホビーユースならともかく、ビジネスユースを考えた場合、ハードウェアの調達からアプリケーションの運用まで、すべてを自前で見なければならない、というのはとてつもなく大変です。クラウドコンピューティングでは、これらのすべてまたは一部を、他社に任せてしまう、ということを行います。このようにすることで、その企業が本来注力したい部分のみにビジネスリソースを割くことができるようになる、というのがクラウドコンピューティングの考え方になります。

クラウドコンピューティングには、どこまでの部分を『お任せ』してしまうのか、ということに関して、大別して 3 つのチョイスがあります。

• IaaS 型（Infrastructure as a Service）
  インフラ部分のみお任せしてしまう、という方式。この方式を取った場合には、自社ではアプリとミドルのみ用意すればよく、インフラ部分（ハードウェアの調達や監視、故障対応など）は業者にお任せしてしまう、ということになります。
• PaaS 型（Platform as a Service）
  インフラとミドルウェアの部分をお任せしてしまう、という方式。この方式を取った場合には、自社ではアプリケーションのみを用意する形になります。
• SaaS 型（Software as a Service）
  インフラ、ミドル、アプリのすべてを外部委託してしまう、という方式。この方式を取った場合には、自社ではコンピュータシステムの構築や運用などについては一切気にする必要はなく、提供されるアプリケーションをそのまま使うだけ、という形になります。

……と、この説明を読んでみて、「これって従来あったサービスと何が違うの？」と思われた方も多いと思います。はい、概していえばその通りです。実は IaaS, PaaS, SaaS に関しては、似たようなサービスが従来から存在しています。例えば以下のようなものを考えてみましょう。

• ASP （アプリケーションサービスプロバイダ）
  業務用のアプリケーションをインターネットなどを介してお客様に提供したりレンタルしたりするのが ASP ですが、これは典型的な SaaS と言えます。グループウェアや財務会計ソフト、給与計算、販売管理や在庫管理など多数のアプリケーションが、利用料金さえ支払えばすぐにブラウザから使えるようになりますが、これらはまさに SaaS そのものと言えます。また、Hotmail（Windows Live メール） や GMail なども、典型的な SaaS と言えます。
• ホスティングサービス
  OS とミドルウェアが用意されたサーバを、お金を払ってレンタルし、この上に掲示板アプリなどを乗せて使うサービスが、主に Linux 系のサーバでよく見られます（例えばさくらのレンタルサーバ）。これは PaaS のようなものです。つまり、OS やランタイム（Perl や MySql など）がプリインストールされたサーバ上に、自分で作成した（あるいは他社から購入した）アプリケーション（掲示板アプリケーションやアクセスカウンタアプリケーションなど）を乗せて使うことができるようになっているわけですが、これはまさに PaaS 型のサービスであると言えます。
• レンタルサーバ
  前述のホスティングサービスの多くはコンシューマ用ですが、ビジネス用には、サーバそのものを貸し出して自由にいじれるようにしたサービスも存在します（例えばさくらの専用サーバ）。これは IaaS の一種と言えます。つまり、ハードウェアの調達や故障対応、ネットワーク回線の手配などについては、事業者側で対応してもらう形にし、自分たちはそこに OS やミドルウェアをインストールし、アプリケーションを動かす、という形になります。これはまさに「インフラをサービスとして必要な分だけ購入する」というスタイルになります。
• データセンタ
  データセンタは、「特定の会社の中の各部署にインフラサービスを提供する IaaS」である、と言えます。

学術的な定義はさておき、これらはいずれもクラウドコンピューティングのはしりのようなものです。また共通的な特徴として、利用した分だけ課金が発生する、というものもあります（このような課金方式はユーティリティコンピューティングと呼ばれています）。つまり、自社のコアコンピタンスではない部分については、外部の業者に委託し、利用した分だけの対価を払ってサービスを受ける、という形にしよう、というわけです。

※ （注意） なお、この説明だけ読むと「それだったら従来型のサービスも全部クラウド型のサービスって呼んでいいんじゃないか？」と思われる方もいるかもしれません。実際、例えば従来のホスティングに対して、クラウドは共有型ホスティングと呼ばれることもあります。しかし、クラウド型と従来型を隔てる極めて重要な技術的ポイントとして、プロビジョニング（自動プロビジョング）と呼ばれる機能があります。この機能を持っていることにより、クラウド型サービスは従来型サービスに比べて、非常に安価かつスムーズにサービスが提供できるようになっています。ちなみにコスト削減に関してはこれ以外にも、仮想化をはじめとする資源の共有（マルチテナント）、運用自動化や規模の経済など、惜しみない努力を図っており、これを従来型とクラウド型の違いとみなす人もいます。プロビジョニングがどのようなものであるのかについては、最後の FAQ のところで解説します。

［マイクロソフトの製品とサービスの分類］

さて、以上がクラウドコンピューティングにおけるサービスの分類ですが、マイクロソフトのクラウドコンピューティングに対する考え方や戦略は、ある意味、「全方位的」です。というのも、他社の場合、「もともと自社サービスのために作ったものを転用してクラウド型のサービスにしました」といった派生的なサービスが割と多いのですが、マイクロソフトの場合には、もともとソフトウェアをすべて自社開発している上に、データセンタまで自社で構築し始めてしまった（！）ぐらいです。このため、シングルベンダーでありながら、極めて多彩なサービスが提供可能になっています。半面、そのサービスがあまりにも多岐に渡るために、分類や整理が非常に難しく、全体像を把握するのが難しい、というのも実際です。

厳密性を追求するとかえってわかりにくくなるので、ここでは非常に乱暴に、マイクロソフトの製品やサービスを分類してみましょう。まず、マイクロソフトが提供する主要なパッケージ製品と、オンライン型のサービスを分類すると、以下のようになります。（※ 細かいところの正確性についてはここでは議論しないことにしてください；。また、点線部で示したところのように、欠けていたり、今後リリース予定だったりするところもあります。）

このような形で書いてみるとわかりやすいのですが、マイクロソフトは、各々の製品を、以下の 2 通りの方法でリリースしようとしています。

• オンプレミス用の製品（パッケージ製品） （＝ Software）（パッケージ購入・自社保有型）
• クラウド型のサービス（オンラインサービス） （＝ Services）（従量課金・自社非保有型）

しかも、これらは IaaS, PaaS, SaaS すべての領域に広がっており、極めて全方位的なラインアップを用意している、というのがマイクロソフトのクラウドコンピューティング戦略の特徴です。これを、”S+S” 戦略（Software + Services 戦略）と呼びます。

このマイクロソフトの戦略や考え方に関しては、メディアによっては「マイクロソフトはパッケージソフトウェアの成功体験から離れられないからだ」といった論調で語られることもあります。しかし、私個人の現場エンジニア感覚からすると、将来的にすべてのソフトウェアがクラウド型サービス（オンライン型サービス）になるという考え方や論調の方が、よほど非現実的だと思います。というのも、クラウドコンピューティング（オンライン型サービス）には、以下のような課題や問題もあるからです。

• データの秘匿性や監査性
  例えば、金融機関の預金データや顧客データなどを、社外のパブリックなデータセンタ内（例えば Microsoft や Google のデータセンタ内）に置いてよいのか？ と言えば、ふつうは No でしょう。セキュリティ要件上、取り扱うデータを外部会社に委託できないようなケースは実際のビジネスではよくある話です。（※ なお、これは Microsoft や Google のデ��タセンタ運用がセキュリティ的にずさんである、という意味ではありません。これらのデータセンタは極めて高いセキュリティで運用されています。しかし、サービスを利用する側の組織的なポリシー上、そもそも社外ににデータを持ち出せないケースがよくある、ということです。）
• 極めて高い SLA （非機能要件への対応やその保証）
  詳細は後ほど解説しますが、クラウドコンピューティングは、スケーラビリティ（動的なキャパシティ調整）に関しては極めて大きなメリットがあります。しかし、「性能要件（応答時間）を保証したい」「99.999% の高可用性を保証したい」といった、極めて高い SLA 要件は保証しにくい、あるいはできない、というのが実態です。
• サーバやソフトウェアのカスタマイズ性
  上記のことと絡みますが、特に Microsoft や Google などが提供する、極めて大きなクラウド型のサービス（メガクラウドとでも呼ぶべきサービス）のほとんどは、個別要件への対応のためのカスタマイズに関して、大きな制約があることが普通です。例えば、業務アプリケーションでは .NET ランタイムのバージョンを特定のバージョン番号に固定したい、といったニーズがよくありますが、Windows Azure では、問答無用でセキュリティパッチやサービスパックなどが適用されていきます。また、サポートが英語でしか受けられない、といったこともよくありますし、サーバに自由にソフトをインストールできないといった制限もよくありますし、もっと身近なところでは、OS のタイムゾーンをいじれない（＝時刻がグリニッジ標準時から動かせない）、既定の言語が英語になっている、といったこともあります。簡単に言えば、クラウド型のサービスを購入する、というのは、カスタマイズできない（あるいはカスタマイズが著しく制限された）パッケージ製品を購入するようなもので、利用者側の個別要件には基本的に対応してくれない、と考えておく必要があります（※ 実際にどこまでカスタマイズ可能かはサービスによって異なりますが、基本的にはカスタマイズ自由度が低い、と考えておくべきです）。
• ネットワークの接続性やデータの連携性
  クラウド型サービスを利用する際によく問題になる点のひとつに、社内システムとの接続問題があります。例えば、イントラネットの業務アプリケーションの一部を社外のクラウド上に置く場合、クラウド上に置いたアプリケーションは、社内に置かれた Active Directory と連携してユーザを認証しなければならない、ということがよくあります。あるいは、クラウド上のデータベースから、定期的に社内のデータベースにデータをバックアップしなければならない、といったこともよくあるでしょう。このような場合、クラウド上のシステムと、社内システムとの接続をどのように行うか（そもそも行えるのか？）が問題になります。（※ ちなみに Microsoft の場合には、この問題に対処するために、サービスバスと呼ばれるサービス（AppFabric）や、Windows Identity Foundation による ID 連携サービスなどを提供しています。興味がある方は調べてみてください。）

つまり現実的には、クラウド型のソリューションだけではお客様要件を満たせないケースが多い、ということです。このため、実際のシステムは、オンプレミス、小型クラウドサービス（従来型に近いデータセンタのようなもの）、超大型クラウドサービス（Microsoft や Google などのデータセンタを使うもの）などを併用したシステム、すなわちハイブリッド型のシステムになるはずです。こうしたハイブリッド型のシステムを実現していくためには、ソフトウェアとサービスを上手に併用する必要がある、というのが Microsoft の “S+S” 戦略の根底にある考え方です。

（注意） クラウドコンピューティングのような新しいキーワードが出現すると、あたかもすべての既存のビジネスが新しいキーワードで書き変わるようなイメージで語られることがあります。しかし、こうした論調には十分注意が必要だと思います。クラウドコンピューティングは、よく、「蛇口をひねったら必要な分だけ水道水が出てきて、必要な分だけ水道料金を払うのと似たようなものだ」と言われます。しかし、水道水があったからといって、カミオカンデの水に水道水が使われるわけではないですし、銘酒の仕込み水が水道水になるわけでもないはずです（← 微妙に例えがわかりにくくてすみません；）。クラウドコンピューティングというパラダイムシフトは多くのビジネスやコンピューティングシステムの在り方に影響を与えるものではありますが、既存のビジネスやコンピューティングシステムをリプレースするものではない、と考えるべきです。

（注意） 前述したマイクロソフトの製品やサービスの分類図に関してですが、この図はあくまで単純な製品マッピングを示したものにすぎない、という点にも注意してください。先の図だけ見ると、あたかも BPOSというオンラインサービスが、Windows Azure Platform 上に構築されているかのように見えますが、そういうわけではありません。BPOS は BPOS の独自のインフラやプラットフォーム上にサービスが構築されています。このため、IaaS, PaaS, SaaS の正しいシステム構成図は下図のようになります。

（参考） これは個人的見解ですが、マイクロソフトテクノロジを採用する大きなメリットは、単一テクノロジで広範なシステム形態を利用することができる、というポイントだと思います。これは “S+S” 戦略などでも非常に明確に見て取れるのですが、エンジニアからすると、新たなシステム形態や技術が出現したときに、テクノロジをゼロから覚え直したり、異なるテクノロジにつなぎ合わせたりすることには多大な労力が必要になります。マイクロソフトテクノロジの場合、例えば Web アプリケーション開発であれば、オンプレミスの IIS 上でも、メガクラウド型 PaaS サービスの Windows Azure Platform 上でも、ほとんど同様のテクノロジが利用できる（ASP.NET や SQL Server/Azure など）ため、新技術が出現した場合でもそのラーニングコストや移行コストを最小限に抑えることができます（ゼロにすることは原理的に不可能ですが）。「最適なものを組み合わせて最適なソリューションを提供できるマルチベンダ方式」というのは聞こえはよいですが、現場のエンジニア感覚からすると、マルチベンダ方式の実態は、「最適なものを組み合わせるために様々なテクノロジを覚えねばならず、さらに組み合わせるための接続検証が必要になり、それらの組み合わせの動作保証までしなければならない方式」です。ソリューションが複雑化すればするほど、また新技術が多数現れてくるほど、マルチベンダ方式はかえってデメリットの方が大きくなる危険性がある、ということは覚えておいてください。（と、元 SIer にいたコンサルタントがつぶやいてみる。）

※ 次のエントリへ続きます。（長すぎてポストできなかったので分割しました。）

※ その1からの続きです。（エントリが長すぎてポストできなかったので分割しました。）

［インフラから見た場合のシステム形態の分類］

さて、前述の図は、マイクロソフトが提供する製品やサービスを示したもの（＝すなわちマイクロソフトの立場で書いたもの）ですが、今度はこれを、ユーザや SIer などの観点から見た図、すなわち利用方法や利用形態の観点から整理した図に描き直してみたいと思います。

まず、前述の図だと、システム形態としては「オンプレミスか、Microsoft が提供するサービスを使うか」の二択のように見えます。しかし、実際には、データセンタ事業者や SIer が Microsoft からパッケージ製品を購入し、これをクラウド型のサービスに仕立てて、エンドユーザや他の SIer に販売する、というモデルも考えられます。このため、インフラ的な観点からすると、クラウドコンピューティング時代におけるシステムの形態は、大まかに以下の 3 つに大別できます。

• オンプレミス型（自社保有・自社運用型）
  エンドユーザが自らソフトウェアを購入し、自社内にシステムを構築する方法。これはクラウドとは呼べないが、自社内データセンタであっても、部分的にクラウド関連技術（例えば自動プロビジョニング機能など）が適用されることにより、運用の効率化などが図られていく形になります。
• ホスタークラウド型（データセンタ事業者によるクラウド）
  データセンタ事業者が、特定の企業向けに提供するホスティング環境。オンプレミス型とメガクラウド型の中間型になりますが、業務システム構築の観点からすると柔軟性が高く、使い勝手がよいのが特徴になります。
• メガクラウド型（"超"巨大なデータセンタによるクラウド）
  数万～数十万台以上のマシンを保有してクラウド型のオンラインサービスを提供しているような「超大規模クラウド」を購入する方法。具体的には、Microsoft, Google, Amazon, Salesforce.com, Yahoo!, eBay などによるサービスが該当します。相対的には安価ですが、個別要件や要望にはほとんど応えてくれない、という問題があります。

（注意） 上記の図では、敢えて「パブリッククラウド」「プライベートクラウド」という用語を使っていませんが、これは、パブリックとプライベートクラウドの境界線の定義が曖昧であるためです。また、どこからがクラウドでどこまではオンプレミスなのか？ といったことも同様の議論で、これらは言葉の定義の問題でしかない、と考えます。これらの議論に深入りすることは技術的に見た場合には不毛だと思うので、この資料では敢えて別の用語として、「オンプレミス型」「ホスタークラウド型」「メガクラウド型」といった用語を使うことにしました。この点は、FAQ にて後述します。

さて、クラウドコンピューティングに関しては、「クラウドコンピューティングが発展すると、中小のデータセンタ事業者が最も痛手を受ける」と言われます。この発言の意図するところは、「中小のデータセンタではメガクラウドのようなスケールメリットを得ることができないため、相対的に高価になってしまい、ビジネスが縮小する」、というものだと思います。しかし、個人的にはこの考え方に懐疑的です。というのも、前述したように、メガクラウド型のサービスにはカスタマイズ性（柔軟性）に難があることが多く、コストが安くても小回りが効かないことが多いからです。特に、業務アプリケーションの世界では、既存のシステムとの連携性、3rd party 製ミドルウェアの導入、高い SLA 要件などなど、個別最適化が求められる領域が多々あり、お仕着せ型のサービスではうまくシステム構築できないケースが多いと思います。逆にいえば、こうした個別要件への柔軟かつ高度な対応性という部分がホスター型クラウドの大きな魅力であり、そうであるからこそ、今後もデータセンタ事業者に対するホスター型クラウドのニーズは多々あるのではないかと思います。ただし、データセンタ事業者にもより一層のコスト削減圧力が働くでしょうから、自動プロビジョニングをはじめとする各種のクラウド技術を適用して、より一層高度なサービスを提供していくことが求められるようになると思います。

［利用者から見た場合のシステム形態の分類］

では次に、クラウドコンピューティング時代が到来することによって、利用者側にはどんな選択肢が増えるのかを考えてみたいと思います。

例1. .NET カスタムアプリケーションを開発し、運用する場合

この場合、従来はオンプレミス型で開発するか、またはホスタークラウド型で開発するかのいずれかを使うケースが多かったと思います。しかし、ここに新たにメガクラウド型で開発する、すなわち Windows Azure Platform 上で開発する、という選択肢が加わることになります。

ただし、先に述べたように、この 3 つの方法は等価ではありません。例えば、図だけ見ると、ホスター型で作られた .NET アプリケーションはそのままメガクラウド型に移行できそうに見えます。しかし、Windows Azure Platform は、データベースや OS の設定を自由に変更できません。このため、必ずしも簡単に移行できるというわけではないはずです。

また、現実的なシステムでは、これらを併用するハイブリッド型システムになることも多々あると思います。例えば、SLA 要件の厳しいシステムでは、基本的にはオンプレミス型やホスター型の形で作成しつつも、災害対策用のバックアップシステムとして Windows Azure Platform を併用する、という形態が考えられます。必ずしもこれらの選択肢は背反的なものではない、と考えるのが適切でしょう。

例2. メールサーバ（Exchange）を使いたい場合

メールサーバを使う場合も、メガクラウド型の SaaS サービスを使う方法、すなわち BPOS （Exchange Online）を使う、という方法が追加される形になります。また、ホスター型クラウドを使う場合には、IaaS 型だけでなく、HMC（Microsoft Solution for Hosted Messaging and Collaboration）を用いて作られた SaaS サービスを使う方法が考えられます。

※ （参考） HMC とは、簡単に言えば、事業者が Exchange サーバを SaaS サービスとして再販するために提供している、マイクロソフトのソリューションのひとつです。

ホスタークラウド型の SaaS と、メガクラウド型の SaaS サービスは、図だけ見ると同様に見えます。このため、一見するとあたかもホスタークラウド型は、今後、メガクラウド型の BPOS に取って変わるように見えますが、この考え方は正しくありません。というのも前述したように、メガクラウド型のサービスの多くは事実上カスタマイズが不可能であり、これは BPOS （Exchange Online）にも当てはまります。このため、ホスター型クラウドは、BPOS では対応できないようなきめ細かなサービスにより差別化が行われる形になります。お客様への提案の際には、まず BPOS はカスタマイズできないという前提条件の元で、BPOS の提供サービスに合致するか否かをまず判断します。そして合致しない場合には、BPOS をカスタマイズしようと考えるのではなく（それは無理です；）、ホスター型クラウドやオンプレミス型のいずれが適切なのかを考えていくことになります。

というわけで、このようにメガクラウド型のサービスという選択肢が増えることにより、ユーザから見たシステム構築手法も自ずと選択肢が増えることになります。しかし、なんでもかんでもメガクラウド型サービスを使うようになる、と考えるのは誤りです。システム要件に応じて、適切な使い分けあるいは併用をしていく必要があります。

［クラウドコンピューティング時代のビジネスチャンス］

では最後に、ここまでの話をまとめる目的で、クラウドコンピューティング時代の到来により、様々な事業者にどのようなビジネスチャンスが生まれてくるのかを考えてみます。それを考えることにより、新たなビジネスチャンスも見えてくるはずです。ここではご参考までに、私が所属する、マイクロソフトコンサルティングサービス（MCS）が提供しているサービスとして、どのようなものがあるのかについても軽く触れてみたいと思います。おそらく MCS が提供しているコンサルティングサービスを見ると、ビジネス的な狙いどころも明らかになってくると思います。

① オンプレミス型が中心のエンドユーザ企業の場合

オンプレミス型で構築したシステムを運用することが中心になっているエンドユーザ企業の場合、クラウドコンピューティング時代の到来により、以下のような選択肢が新たに生じることになります。

• ホスタークラウドやメガクラウドへの移行
  インフラの自社運用を避け、ホスタークラウドやメガクラウドへ移行するパターンです。災害対策用のバックアップとして、ホスタークラウドやメガクラウドを利用する、ハイブリッド型クラウドへ移行するニーズも数多く発生してくると思います。この領域に関しては、MCS は ITAP （IT アーキテクチャ＆プラニング）と呼ばれるサービスを提供しており、クラウドサービスを適用することによってどのようなシステム最適化が図れるのかを検討することができます。
• 自社データセンタへのクラウド技術の適用（インターナルクラウドの構築）
  大量のサーバを抱えることによるスケールメリット（コスト低減メリット）は少ないですが、クラウド技術を自社データセンタに導入することにより、インフラ運用の効率化、動的かつスムーズなプロビジョニングなどを行えるようになるメリットがあります。この領域に関しては、データセンタ運用を効率化するためのツールキットである DDC Toolkit（ダイナミックデータセンタツールキット）が CodePlex から提供されていますが、このツールを用いてデータセンタ運用の効率化を図るためには、当該データセンタ運用の現状を見据えた上で、あるべき姿を模索する必要があります。このため、MCS では運用効率化のコンサルティングサービスを通じて、DDC Toolkit の適用などをコンサルティングしています。

※ （参考） DDC Toolkit というものをご存じない方も多いと思いますが、これはデータセンタ仮想化のためのツールセット（いわゆるライブラリ）であり、それ単体で導入可能なパッケージ製品にはなっていません。このため、DDC Toolkit を利用する場合には、実際には UI などの部分についてかなりの作り込みが発生します。Windows Azure Platform のような環境をポンと自社内に構築するためのお手軽ツールキットではありませんので、ご注意ください。

② データセンタ事業者の場合

クラウドコンピューティング時代の到来により、最も既存ビジネスに影響を受けるのがデータセンタ事業者である、とよく言われます。確かにそれはその通りですが、それは必ずしもビジネスの縮小を意味しないと思います。クラウドコンピューティング時代の到来により、以下のようなビジネスメリットやビジネスチャンスが生まれてくる、と思います。

• 自社データセンタへのクラウド技術の適用
  これは①で述べたものと同様の話です。スケールメリットは少ないですが、より素早いリソース割り当て、低い運用コスト（初期費用やランニングコスト）などが実現できます。この領域に関しては、MCS は先に述べた運用効率化のコンサルティングサービスを提供しています。
• IaaS から PaaS, SaaS ビジネスへの進出
  ほとんどの場合、従来からあるデータセンタの大半は IaaS 型サービスが中心でしょう。このような場合、利用者側の自由度は高いものの、半面、特にミドルウェアの運用の部分について、利用者側に大きな負担がかかります。そこで、Microsoft などからアプリを購入し、PaaS, SaaS としてサービスを販売（再販）するというモデルが考えられます。イラストだけ見ると、メガクラウド型サービスとして提供されている BPOS や Windows Azure Platform などに似ていますが、先に述べたように、メガクラウド型サービスには、小回りが利きにくいという弱点があります。そこを突く形でサービスを提供することにより、より高い付加価値をつけたサービス提供が可能になります。この領域に関しては、MCS ではデータセンタに関する IT 基盤の強化サービス、また実際に乗せることになる各製品に関する製品コンサルティングサービスを提供しています。

実際、現場のエンジニア側から見ると、ミドルウェア部分の運用監視をデータセンタ事業者側に移管できる、というのは極めて大きなメリットであることが多いです。特に、Windows サーバ系のデータセンタでは、OS のベースイメージのみが提供されるという簡易なサービス提供にとどまっている場合が多く、IIS や SQL Server などのミドルウェアの運用や監視まで含めたサービスが提供されると、利用者側にとっては大きなメリットとなるはずです。（ちなみに、どのようなサービスを作ればよいのかに関しては、Windows Azure Platform が提供する各種のサービス（例えば SQL Azure データベースサービスなど）が参考になるはずです。）

③ ISV（独立系ソフトベンダー）の場合

パッケージ製品などを作成している ISV の場合、従来から ASP 化（アプリケーションサービスプロバイダ化、すなわちオンラインサービス化）によるサービス拡販などが行われてきたかと思います。このような場合には、以下のようなビジネスチャンスが考えられるかと思います。

• メガクラウド型 PaaS サービスの利用
  自社で開発しているアプリケーションを Windows Azure Platform 上で動作できるように修正し、メガクラウドのメリットを享受する、というものです。特にインフラやミドルウェアの運用監視の部分に関して大きなメリットが得られる（例えば SQL Azure データベースサービスを使うと、非常に安価に 99.9% の高可用性データベースを使うことができる）こと、またスケーラビリティに関しても大きなメリットが得られる（必要な料金を支払えば、キャパシティをすぐに拡大できる）ことについては、ISV にとっては大きな朗報となるはずです。この領域に関しては、MCS では Visual Studio Workshopを通じて、Windows Azure Platform 上でのアプリケーション開発ノウハウのスキルトランスファーを実施したり、あるいはその開発そのものを直接支援したりします。
• 各種のマーケットプレイスの活用
  パッケージ製品のオンライン化では、サービスの販路の確保が重要になります。この点に関して、マイクロソフトではマーケットプレイスの強化を図ろうとしています。具体的には、Microsoft Pinpointと呼ばれるサイトがあり、ここで様々なオンラインサービスやアプリケーションの販売をすることが可能になっています。ちなみに日本語版の提供時期は今のところ未定ですが、こうしたマーケットプレイスは、どちらかというと日本市場における販路確保というよりも、アプリケーションを多言語対応させて海外展開するための販路としての側面の方が重要でしょう（← ビジネスアプリケーションやサービスは、iPhone などのようにエンドユーザが多いわけではないためです）。自社アプリを多言語対応させて Windows Azure Platform 上に乗せ、各種のマーケットプレイスを通じて販売することにより、ビジネスの拡大を見込むことができます。

なお、Windows Azure Platform 上で動作するアプリケーションの販売方法は 2 種類ある、ということを知っておくとよいと思います。ひとつは、自社で Azure のライセンスを購入し、アプリケーションを動作させ、これを SaaS として販売するモデル。もうひとつは、自社のアプリケーションを Windows Azure Platform 対応製品として、パッケージ製品として販売するモデルです。（後者の場合、お客様は自前で Windows Azure Platform のライセンスを購入し、そこにアプリケーションを自分で配置して使う形になります。） Windows Azure Platform では、どちらの販売方式も可能になるようにライセンス形態が設計されています。

④ SIer （システムインテグレータ）の場合

おそらく、クラウドコンピューティング時代の到来によって最も大変なのが、SIer になると思います。確かに、お客様から受注してシステムを構築する、というビジネスの在り方そのものに大きな変化はないでしょうが、システム構築の際に、クラウド型サービスを活用するという選択肢が加わることにより、設計のパターン数が非常に増えることになります。

• システム構築における、ホスター／メガクラウドの活用
  従来ですと、システム構築時にデータセンタを利用する、という一択で済んでいたものが、ホスター／メガクラウドの IaaS/PaaS/SaaS サービスの出現により、選択の幅が一気に広がることになります。具体的には、エンドユーザ向けにシステム提案をする際に、適宜、クラウドを活用する構成を含めることで、メガクラウドの利用による動的スケール調整や、ハイブリッド型システムによる安価な災害対策などのメリットを得られるようにしていくことになります。これにより、価格競争力のあるシステム提案を実施していくことができるようになる、ということです。この領域に関しては、MCS は一般的なシステム構築支援サービスを通じて、その中でクラウド技術を活用したシステムアーキテクチャ・アプリケーションアーキテクチャ提案を行っていく形になります。

以上、様々な事業者ごとのビジネスチャンスや狙いどころについて解説してみましたが、このように、クラウドコンピューティングやその周辺技術をどのように自社に生かしていくのかは、事業者の立ち位置やサービス内容によって全くといっていいほど異なります。自社のコアコンピタンス（最も強いところ）を見定めたうえで、クラウド技術をどのように生かしていくのかという、視野を一段高くした状態での検討作業が必要になる、と言えるでしょう。

※ 次のエントリへ続きます。（長すぎてポストできなかったので分割しました。）

※ その2からの続きです。（エントリが長すぎてポストできなかったので分割しました。）

［クラウドコンピューティングに関する FAQ］

ここまでで解説はひととおり終了なのですが、よくある FAQ として、以下の 4 つの点を簡単にまとめておきたいと思います。

• 従来技術とクラウド技術の違い
• プロビジョニング
• パブリッククラウドとプライベートクラウドの境界線
• マイクロソフトのクラウドコンピューティング戦略の 4 つの柱

① 従来技術とクラウド技術の違い

その昔、「フレームワーク」というキーワードが流行した際、実態としてはフレームワークとは呼べないような製品まで「フレームワーク」という名称を付与して販売されていた時期がありました。この手の Buzz Word （流行語）はどうしてもマーケティング目的で利用されてしまうことが多く、「クラウド」というキーワードもやはりそのような側面があります。実際、オンプレミスとクラウドの境界線は、厳密には定義できないこともあり、用語の使い方が曖昧になっています。例えば下図のようなケースにおいて、各種のデータセンタはいずれも IaaS の一種のようなものとみなせますが、どこからクラウドと呼ぶべきか？ 何をクラウドと呼ぶべきか？ に関しては、今のところ、厳格な定義がありません。

ただ、おおまかに言うと、従来型のものとクラウド型のものには、以下のような違いがあります。

• 仮想化 ： 各種のコンピューティングリソースが抽象化されている
• 従量課金 ： 使った分だけお金を支払う
• 動的なリソース割り当て ： 必要に応じて簡単にリソースを増やせる

この中でも、特に「動的なリソース割り当て」については、クラウド技術を特徴づける極めて大きなポイントになっていますので、これについて解説します。

② プロビジョニング

おそらく、「動的なリソース割り当て」を理解するためには、Windows Azure Platform の機能（サービス）のひとつである、Windows Azure コンピュートサービスの概要を理解するのが手っ取り早いと思いますので、これについて解説します。

先に述べたように、Windows Azure コンピュートサービスとは、Microsoft が提供する PaaS サービスで、OS とミドルウェアの部分が提供されるサービスになっています。その中身を、技術的な観点からものすごく単純に書くと、「仮想マシンの自動展開機能と、パッケージングされたアプリケーションの自動配置機能である」と説明できます。下図を見てください。

上図は、Windows Azure コンピュートサービスの内部動作をおおざっぱに示したイラストです。Windows Azure コンピュートサービスは PaaS サービスですが、具体的には以下のように動作します。

• ユーザは、開発したアプリケーションをパッケージングし、ポータルサイトからアップロードします。
• ファブリックコントローラは、データセンタ内のコンピュータリソースの空き状況を見て、IIS や .NET Framework がインストールされた OS イメージを、物理ハードウェア上に展開します。
• さらにここにアップロードされたアプリケーションを展開し、仮想マシンを起動します。

上記の一連の作業はすべて自動で行われるため、非常に素早くサービスを利用し始めることができます。また、リソースが不足した場合には、仮想マシンを追加して負荷分散することでキャパシティを増やすことができ、逆にリソースが過剰になった場合には、仮想マシンをシャットダウンすればよい、という形になっています。

このような、動的なリソース割り当ての仕組みは、一般的にプロビジョニング（Provisioing）と呼ばれています。プロビジョニングとは、「事前にリソースを用意しておき、ユーザからの要求に応じて適切な割り当てを素早く行う」ことを指す用語で、クラウドをクラウドたらしめる重要な技術要素のひとつになっています。

Windows Azure ではこれに加え、ファブリックコントローラがマシンの稼働監視やフェイルオーバなどを司っており、事実上の無人運転が行われているわけですが、ここまでの自動化が行われているクラウドサービスは、実際問題としては一部の企業に限られるでしょう。となると、何をクラウドと呼ぶのかの定義は、現実的にははっきりしない、というのが実態だと思います。

（参考） よく、「”Windows Azure” とはクラウド版の Windows OS である」という説明がなされますが、Windows Azure コンピュートサービスにおいて、実際に使われている OS は、我々がよく使っている Windows Server 2008 です。にもかかわらず、Windows Azure がクラウド OS である、と言われるゆえんは、上図のファブリックコントローラのところに肝があります。このファブリックコントローラは、データセンタ内の各物理サーバのリソースの空き状況を監視して、動的に仮想マシンをアサイン、展開する仕組みを持っています。このような仕組みは、クラウドコンピューティング特有のものである、と言えるでしょう。（つまり、Windows Azure のクラウド OS としての本体は、ファブリックコントローラである、と説明してもよいでしょう。）

（参考） Windows Azure コンピュートサービスの利用に関して、初期費用が発生しない、また「1 インスタンス・1 時間あたりの課金」という計算方式になっているのは、このような動的リソース割り当ての仕組みを持っているからでもあります。

③ パブリッククラウドとプライベートクラウドの境界線

何をクラウドと呼ぶべきかの定義がはっきりしない、というのと同様な話のひとつに、パブリッククラウドとプライベートクラウドの境界線がはっきりしない、という話もあります。本エントリでは、誤解を避けるために、オンプレミス／ホスタークラウド／メガクラウドという用語を使いましたが、これらの用語は一般的ではありません。一般的には、パブリッククラウド／プライベートクラウド／インターナルクラウドといった用語の方が有名でしょうが、これらは境界線がはっきりせず、またマーケティング的な都合から、やや解釈を広めにとって使われていることが少なくありません。

上図に示した境界線はどれが正しいと一概に言えるものではないでしょう。はっきりしていることは共用性が高いものをパブリックと呼び、低いものをプライベートと呼んでいることだけで、境界線がどこと決定しているわけではありません。Microsoft, Google, Amazon などが提供する超大規模クラウドサービスのみをパブリッククラウドと書くケースも多いようですが、ホスタークラウドでも汎用型かつ大規模であれば十分にパブリックなクラウドである、と言えると思います。このため、これらの用語を使う場合には、誤解が生じないように、意味するものが上記のどれなのかをきちんと示す必要があります。

④ マイクロソフトのクラウドコンピューティング戦略の 4 つの柱

ここまでの解説からわかるように、Windows Azure Platform とは、カスタムアプリケーションを乗せるためのインフラ（PaaS サービス）であり、”Windows Azure Platform” と “S+S（Software plus Services）” とは全くの別物であることもわかるかと思います。再度、クラウドコンピューティング時代においてマイクロソフトが提供するソフトウェアとサービスを、以下に掲載します。

この図から分かるように、ざっくり言うと、クラウド型として提供されるオンラインサービスは、以下の 3 つのブランドに大別されます。

• BPOS : SharePoint Online, Exchange Online, OCS Online など（ビジネスユーザ向け）
• Windows Live : Live Mail, Live Map, Live Messenger など（コンシューマユーザ向け）
• Windows Azure Platform : Windows Azure ストレージサービス、コンピュートサービス、SQL Azure （アプリケーション開発プラットフォーム）

これらに加えて、既存データセンタ（オンプレミス型）に対してクラウド関連技術を適用しようとする、ダイナミックデータセンタの 4 つが、マイクロソフトのクラウドコンピューティング戦略において重要な柱である、と説明できるかと思います。（ちなみにこれ以外にも、Windows Mobile や Dynamics CRM Online などもあります。興味のある方は調べてみてください。）

［まとめ］

というわけでここまでいろいろと説明してきましたが、要点をまとめると以下の通りとなります。

• マイクロソフトは、クラウドコンピューティング世代に対して全方位的なソリューションを展開している。これを¨"S+S" 戦略と呼ぶ。すなわち、オンプレミスソフトウェアとクラウドサービスの両方を併用することにより、柔軟かつ高度なソリューションを提供できるようになっている。
• インフラレベルから見るとシステム形態は 3 つに大別できる。
  ① オンプレミス型
  ② ホスタークラウド型
  ③ メガクラウド型
  オンプレミス／クラウドはトレードオフの関係を持つため、適切な選択を行うことが非常に重要になる。
• マイクロソフトの提供するサービスのうち、特に重要なのは以下の 4 つである。
  1. ダイナミックデータセンタ（既存データセンタのクラウド化）
  2. BPOS （マイクロソフトの企業向けオンラインサービス）
  3. Windows Live （マイクロソフトのコンシューマ向けオンラインサービス）
  4. Azure Platform（開発者向けの PaaS プラットフォーム）
• 今後は、オンプレミス向け技術と、クラウド向け技術の両方について、その特性や技術的差異をよく理解し、これらを併用したソリューション検討が必要になる。

なかなか全体像が掴みにくい “S+S” 戦略ですが、全体の枠組みを正しく理解した上で、適切な場所にクラウド技術を適用するようにしてください。

さて、Part 1. のエントリでは、マイクロソフトのクラウドコンピューティング戦略である “S+S” の全体像、そしてその中での Windows Azure Platform の位置づけについて解説しました。要点をまとめると、以下のようになります。

• マイクロソフトのクラウドコンピューティング戦略は、オンプレミス型のソフトウェアと、クラウド型のサービスとを上手に組み合わせて、最適なシステムを構築する、というものである。
• Windows Azure Platform とは、マイクロソフトによる PaaS サービスである。
• ユーザは、Windows Azure Platform 上に、ユーザアプリケーションを載せて動作させることができる。

Part 2. となる本エントリでは、Windows Azure Platform の概要について解説します。おおまかなトピックは以下の通りです。

• Windows Azure Platform とは何か
• Windows Azure Platform の主要構成要素
  ① Windows Azure コンピュートサービス 
  ② SQL Azure データベースサービス 
  ③ Windows Azure ストレージサービス
• 開発上の注意点

では、順番に見ていきましょう。

［Windows Azure Platform とは何か］

Windows Azure Platform とは、ユーザが開発したカスタムアプリケーションを動作させることができる、PaaS サービスです。Web, DB から構成される典型的な Web アプリケーションを乗せて使うことができる他、TCP/IP 通信を受け付けることが可能なアプリケーションサーバなどとしても利用できるように作られています。概念図を以下に示します。

Windows Azure Platform の主要な構成要素は以下の 3 つです。

• Windows Azure コンピュートサービス
• SQL Azure データベースサービス
• Windows Azure ストレージサービス

さらに、これら以外の周辺的なサービスとして、Windows Azure AppFabric があり、さらに今後、Windows Azure VM Role や System Center Azure などの提供が計画されています（詳細や時期については不明）。これらのサービスを総称して、Windows Azure プラットフォームと呼びます。

※ （注意） 単純に “Windows Azure” または “Azure” という用語を使った場合には、① Windows Azure コンピュートサービスのみを指す場合、② Windows Azure コンピュートサービスと Windows Azure ストレージサービスの組み合わせを指す場合、③ Windows Azure Platform 全体を指す場合、の 3 通りの意味があり、混乱を招きます。本エントリでは混乱や誤解を避けるため、”Windows Azure” または “Azure” といった簡略用語を避け、きちんとした用語で解説したいと思います。

さて、自社開発アプリケーションを乗せるプラットフォームとして Windows Azure Platform を見た場合には、以下のような特徴（メリット）があります。

• .NET Framework や Visual Studio を使った開発ができる。
  もちろん、 Windows Azure 特有の開発ルールや作法を守る必要はありますが、開発言語やツールなどをゼロから覚え直す必要はありません。これは大きなメリットです。
• 煩わしいハードウェア／ミドルウェア運用から解放される。
  PaaS 型サービスなので当たり前なのですが、実際のところ、SQL Server などのミドルウェアの高可用運用は非常に大変です。特に SQL Azure データベースサービスに関しては、容量制限などはあるものの、99.9% （月間ダウンタイムが約 5 分）のデータベースを安価に利用できるというメリットは大きいと言えるでしょう。
• 利用に応じた課金がなされる。
  これも PaaS 型サービスなので当たり前ですが、初期コストゼロ、繁忙期や混雑時間帯のみリソース増強を行うことができる、というのが大きな特徴です。例えばピザ屋さんなどの Web サイトでは、土日、あるいは夕方などにトラフィックが集中しますが、ピークトラフィックに併せてインフラを設計・保有すると、TCO が肥大化しやすくなります。Windows Azure Platform を利用すると、動的にサーバ数の増減を行うことができ、さらに利用時間に応じた課金となるため、相対的に安価にシステムを構築・運用できます。

もちろん、Windows Azure Platform にも弱点や難点はありますし、現在はできないことも多数あります。これらについては、「開発上の注意点」の項で解説することにしたいと思います。

なお、CTP の頃はデータセンタがアメリカ 2 拠点にしかありませんでしたが、2010 年からはアジア 2 拠点、ヨーロッパ 2 拠点がオープンしました。これに加えて、CDN （Content Delivery Network）が利用可能です。

※ （参考） 大規模システムやミッションクリティカルシステムに Windows Azure Platform を利用したい場合、設計上、Windows Azure コンピュートサービスと SQL Azure データベースに関しては、Geo-Replication （拠点またがりの自動複製）が行われない、という点に注意しておく必要があります。つまり���データセンタのディザスタ対策が自動的に行われるわけではありませんので、必要であれば自力で対処する必要があります。一方、Windows Azure ストレージサービスに関しては、同一地域内の 2 つのデータセンタ間（例えば香港とシンガポール間）での Geo-Replication が行われるようになっています。同一地域内とはいえ、物理的な距離としてはかなり離れていますので、ディザスタ対応がなされているとみなせるでしょう。

［Windows Azure Platform の主要構成要素］

さて、Windows Azure Platform 上に自社アプリを開発して乗せる場合には、主に以下の 3 つのサービスを利用します。

• Windows Azure コンピュートサービス（Web ロール、Worker ロール）
• SQL Azure データベースサービス
• Windows Azure ストレージサービス

ものすごくおおざっぱに言うと、以下のように理解するとよいと思います。（と、こんな乱暴に書くとマイクロソフトの中の人たちに怒られそうですが…；）

• Windows Azure コンピュートサービス ： 要するに「Web サーバ」
• SQL Azure データベースサービス ： 要するに「DB サーバ」
• Windows Azure ストレージサービス ： 要するに「ネットワークファイル共有」

一般に、Web アプリケーションを動作させる場合には、Web サーバと DB サーバが必要になりますが、それぞれに対応するものが Windows Azure コンピュートサービスと、SQL Azure データベースサービスになります。そして、それとは別に、ログファイルを記録したり、巨大なデータファイルなどを格納しておくディスク領域（ネットワークファイル共有）が必要になる場合がありますが、それを担うのが Windows Azure ストレージサービスである、と考えてください。

※ （参考） Windows Azure Platform には、これらのサービス以外にも、Windows Azure AppFabric と呼ばれるサービスがあります。実際のシステム構築では、AppFabric に含まれる .NET サービスバスと呼ばれる機能が非常に重要になるのが、今回のエントリでは解説しません。

※ （参考） Windows Azure コンピュートサービスには、大別すると、PaaS 型のサービス（Web ロールおよび Worker ロール）と、IaaS 型のサービス（VM ロール）の 2 種類があります。VM ロールに関しては、現時点ではリリースされておらず、また現時点では詳細な仕様も明らかにされていないこと、また本エントリでは PaaS 型サービスのみを取り扱いたいと思いますので、VM ロールについては除外して解説します。

以下に、それぞれの構成要素についての概要を解説していきます。

※ エントリが長いので分割しました。その 2に続きます。

※ その 1のエントリからの続きです。（エントリが長すぎてポストできなかったため、分割しています。）

［① Windows Azure コンピュートサービス］

Windows Azure コンピュートサービスとは、カスタムアプリケーションのホスティングサービスです。OS とミドルウェアがプリインストールされたマシンが提供されますので、そこにカスタムアプリケーションを乗せて実行する、という形になります。利用可能なサーバタイプとして、以下の 2 種類が用意されています。

• Web Role サーバ ： .NET Framework と IIS がインストールされた Web サーバタイプのサーバ
• Worker Role サーバ ： .NET Framework のみがインストールされたバッチアプリケーション用のサーバ

実際のシステムでは、この 2 種類のサーバを組み合わせて、ひとつのシステムを構成します。例えば、Web アプリケーションと Web  サービスとバッチアプリケーションから構成されるシステムは、上記の 2 タイプのサーバを組み合わせて、以下のように組み上げることができます。

※ （注意） 上記の図では各サーバがあたかも物理マシンであるかのように書かれていますが、実際にはデータセンタ内では Hyper-V を使った仮想マシン（VM, Virtual Machine）として配置されます。

※ （参考） Worker Role サーバは、もともとバッチアプリケーション動作用のサーバを想定して開発されたために上述のような書き方をしました。しかし現在では、ポートをあけることによって、インターネット上から直接 TCP/IP 通信を受け付けることができるようになっているため、このタイプのサーバは比較的汎用性の高いサーバとして使うことができます。例えば、バッチアプリケーションに WCF ランタイムをホストさせれば、このサーバはアプリケーションサーバ化して使える、ということになります。

さて、Windows Azure コンピュートサービスは、「OS やミドルがプリインストールされており、アプリをそこに転送してインターネット上で動作させられる」という点において、各種のコンシューマ向け Unix/Linux 系レンタルサーバ（共用ホスティングサービス）に似ています。しかし決定的に異なるのが、各ユーザのアプリケーションが仮想マシンレベルで分離されている、という点です。

実際に Windows Azure コンピュートサービスを利用する場合には、以下の手順で利用します。

• 起動する仮想マシンのベースとなる OS イメージを選択する。
  （※ 現在は Web Role サーバと Worker Role サーバの 2 種類のみが利用可能。）
• そこに、パッケージ化されたアプリケーションをアップロードして動作させる。

Part 1. のエントリの FAQ の項で解説したように、このアプリケーション展開は、ファブリックコントローラと呼ばれるシステムにより行われます。こちらにも図を再掲しますが、Windows Azure コンピュートサービスの実態は、要するに仮想マシン（VM）のイメージのコピーと、アプリケーションを自動展開するシステムです。展開された各仮想マシンは、CPU やメモリとバインドされて動作する（通常は 1 インスタンスあたり 1 CPU がバインドされる）ため、サービスレベルの保障がしやすい形で動作することになります。

※ （参考） この割り当ての仕組みをプロビジョニング（Provisioning）と呼ぶのですが、プロビジョニングを司っているシステムがなぜ「ファブリックコントローラ」と呼ばれるのかも、この仕組みを知っているとわかりやすいと思います。「ファブリック（Fabric）」とは「織物」という意味なのですが、Windows Azure コンピュートサービスでは、「空いている物理マシンを探してそこに VM イメージのコピーを行い、Web Role サーバや Worker Role サーバなどを起動し、ひとつのシステムを組み立て上げる」という作業を行います。これはまさに、織物を組み立て上げるような作業と言えるでしょう。

なお、Windows Azure コンピュートサービスに関して真っ先に知っておくべき点として、ユーザが各マシン（仮想マシン）に直接デスクトップログオンして操作することができない、ということがあります。一般的な Unix/Linux 系のコンシューマ向けホスティングサービス（レンタルサーバ）では、

• FTP を使って、1 つずつファイルをアップロードしたり、書き換えたりすることができる。
• リモートシェルを使って、ファイルを読み書きしたりすることができる。

といったことが可能ですが、これらは Windows Azure コンピュートサービスでは一切できません。理由は様々にあるのでしょうが、一番大きな理由は、VM インスタンス数を簡単に増減できるようにするため、でしょう。一般的な Unix/Linux 系のコンシューマ向けホスティングサービスでは、1 台の Web サーバを複数のユーザが共有する、という形を取ります。このため、複数の Web サーバに負荷分散させるといったことはまったくできません。しかし、Windows Azure コンピュートサービスでは、各マシンにログインしたり、各マシンを個別にいじったりすることができないかわりに、以下のようなことができます。

• システムの処理キャパシティを上げたくなったら、VM インスタンス数を増やす。
• システムの処理キャパシティを下げたくなったら、VM インスタンス数を減らす。

特に、大規模トランザクションを処理するようなオンラインシステムの場合には、ピーク時のトラフィックと平常時のトラフィックに大きな違いがあるようなシステムが少なくありません。このようなシステムでは、従来ではピーク時のトラフィックに併せてサーバ台数を決定する、という設計を行っていましたが、これではお金がかかりすぎます。このため、その時点時点に見合ったリソースを用意すること、すなわちトラフィック量に併せて処理キャパシティを動的に増減させる（＝繁忙期や繁忙時間帯のみ、仮想マシンの数を増やして処理キャパシティを一時的に増やす）ことでコストを抑えることがとても重要になります。このようなユーティリティコンピューティングを簡単に実現できるように設計されているのが、Windows Azure コンピュートサービスです。

※ （参考） これは私個人の感想なのですが、最初にこの仮想マシン割り当ての仕組みを見たときには、「なんて乱暴なシステムなんだ；；」と思ったのが正直なところです。というのも、オンプレミス型の Windows Server （IIS）の場合には、1 つの OS 上に複数のアプリケーションを配置する際、様々な配置オプションを提供していました（Web アプリケーション化による分離、アプリケーションプール／ワーカプロセスによる分離、CPU とワーカプロセスのバインド、Hyper-V、などなど）。ところが、Windows Azure コンピュートサービスは、「1 個の Web アプリケーションには 1 個の OS、1 個のワーカプロセス、1 個の CPU を割り当てる」（※ 厳密には VM サイズが指定できるのですが）、という極めて割り切られた設計がなされています。この結果、例えばスケーラビリティを向上させようと思った場合、オンプレミス型では非常に多くのオプション（スケールアップ、スケールアウト、プロセス数増加、スレッド数増加、etc.）が存在するのですが、Windows Azure コンピュートサービスでは、基本的に仮想マシンのインスタンス数を増加させるというオプションしか存在しません。この割り切り設計は非常に乱暴ですが、半面、極めて単純なスケーラビリティ調整システムが実現できるというメリットがあり、なるほどそう考えると極めてよく出来たシステムだなぁと思いました。（スケーラビリティに限らず、いろんなところにこの割り切り設計の良さが表れていますので、考えてみるとよいと思います。）

［② SQL Azure データベースサービス］

さて、Web アプリケーションの多くは RDBMS を利用しますが、Windows Azure Platform データセンタの場合には、SQL Azure データベースサービスと呼ばれる RDBMS を利用することができます。

※ （注意） SQL Azure データベースサービスで利用されるマシン群は、Windows Azure コンピュートサービスで使われるマシン群とは別物です。イメージとしては、同一データセンタ内の別のマシングループを使っている、と考えるとよいでしょう。（実際のところはどうなっているのかは私も知りませんが．．．．） Windows Azure コンピュートサービスのインフラ上に、SQL Azure データベースサービスが乗っているわけではないので、ご注意ください。

（細かい違いを言い出せばキリがないですが、ざっくり言えば）SQL Azure データベースサービスは、物理的には、オンプレミス版の SQL Server 2008 に対して、いくつかのカスタマイズと制限事項を加えることによって作られたものです。このため、以下のような特徴があります。

• 通常のオンプレミス型の ASP.NET Web アプリケーションと同様に、ADO.NET を使って SQL Azure データベースにアクセスすることができる。
• SQL Server Management Studioから、Azure データセンタ内にある SQL Azure データベースサービスにつないで、データベースを管理することができる。（※ 現時点ではツールに一部制限あり）

非常に面白いのは、データベースアプリケーションの開発スタイルが従来の方式とほとんど変わらないという点です。例えばオンプレミス型の SQL Server に接続する場合やファイルアタッチデータベースを使う場合は、

• Server=sqlsvr2008;Initial Catalog=pubs;User Id=sa;Password=xxxxxxxx;Trusted_Connection=false;
• Server=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\pubs.mdf;Integrated Security=True;User Instance=True

といった接続文字列を使います。これに対して、SQL Azure を利用する場合には、これを

• Server=tcp:mbkz90u87g.database.windows.net;Database=pubs;User ID=nakama@mbkz90u87g;Password=xxxxxxxx;Trusted_Connection=False

といった接続文字列に変更します。たったこれだけの作業で、SQL Azure データベースにアクセスすることができます。ですから、コンソールアプリケーションから SQL Azure データベースサービス上に作成した pubs データベースにアクセスするためには、以下のようなコードを使うだけで OK です。従来のコードとほとんど変わりがないことがわかるかと思います。

   1: SqlConnection sqlcon = new SqlConnection(

   2:"Server=tcp:mbkz90u87g.database.windows.net;Database=pubs;

   3:      User ID=nakama@mbkz90u87g;Password=xxxxxxxx;Trusted_Connection=False;");

   4: SqlDataAdapter sqlda = new SqlDataAdapter("SELECT * FROM authors", sqlcon);

   5: DataSet ds = new DataSet();

   6: sqlda.Fill(ds, "authors");

   7: Console.WriteLine(ds.GetXml());

通常の業務アプリケーション開発の場合には、まずファイルアタッチデータベースを使って開発を進めておき、運用環境に移行するタイミングになったら、接続文字列を上記のような SQL Azure データベースサービス用のものに変更する、という形にすればよいでしょう。

※ （注意） 実際に SQL Azure データベースサービスにアクセスするためには、SQL Azure に対して TCP/IP 接続ができなければなりません。このため、① SQL Azure データベースサービス側のファイアウォール設定を変更する、② （イントラネットからアクセスしたい場合には）社内のファイアウォールを超えられるように設定をしたりツールをインストールしたりする、という作業が必要になります。自宅などで検証作業を行う場合には②の点は問題にならないでしょうが、多くの企業では、社内から社外に対する直接の TCP/IP 通信を認めていません。このため、みなさんの会社の中（イントラネット）から SQL Azure データベースサービスを使いたい場合には、何らかの対処が必要になることが多いです。

さて、SQL Azure データベースサービスに関してまず知っておくべきポイントとしては、以下の 2 つがあります。

• 1 アカウント（1 インスタンス）あたりの容量上限が比較的厳しい。
• データが 3 台のマシンに複製されており、99.9% のサービス可用性が保障されている。

まず、1 つ目のポイントに関してですが、ユーザは 1 つのアカウント（SQL Server でいうところのインスタンスに対応）内に複数のデータベースを作成できますが、その最大容量は Business Edition でも 10GBとなっています。このため、データ量が多いシステムの場合には、以下のような対処が必要になります。

• 直近取り扱うデータのみを SQL Azure 上に置き、履歴データなどはオンプレミスの SQL Server 上に移すようにする。
• 取り扱うデータを分割し（例：顧客 ID 1,000 人ごとにグループ化し）、別々の SQL Azure データベースで取り扱う。（＝アプリケーションレベルからデータをパーティショニングする。）

また 2 つ目のポイントですが、SQL Azure データベースサービスでは、ひとつのデータベースのデータを、物理的には 3 台のマシンに複製した形で保持します。これにより、どこか 1 台のマシンが破損しても、他のサーバで処理を引き継ぐことが可能になっており、99.9% のサービス可用性（ひと月あたりのダウンタイムが約 5 分）が保障されるようになっています。内部的には、以下のように動作しています。

• 外部からの TCP/IP 接続（SQL Server のネイティブ通信プロトコロである TDS プロトコルによる接続）は、いったん SQL TDS と呼ばれるサーバが受け付ける。このサーバがロードバランサとなり、特定のマシン（当該データベースを持っているマシン）に接続をルーティングする。（※ フェイルオーバ時は、この SQL TDS による接続ルーティング先が変更される。）
• クライアントから行われる更新処理に関しては、更新内容が 3 台のマシンに自動的に複製される。
• データ複製には、Microsoft がカスタムに作り込んだ特殊なレプリケーションシステムが使われている。（＝ログシップやデータベースミラーリング、あるいは従来のデータベースレプリケーションなどを使ってデータが複製されているわけではない）

※ （参考） なお上記のデータ複製は、同一データセンタ内で行われます。このため、ディザスタ時（災害時、例えばデータセンタが地震で潰れた等）にはデータがロストすることになります。ディザスタを回避するためのデータバックアップや、別拠点へのデータバックアップについては、現時点では自力で行う必要があります。（将来的には同一データセンタ内またはデータセンタまたがりでデータベースを簡単にコピーできるようなツールやコマンドが提供される予定です。）

※ （参考） ちなみに、従来からあるデータベースレプリケーションの場合には、データ更新が別マシンに遅延反映されますが、SQL Azure データベースサービスで利用されているデータ更新はリアルタイムに行われます（＝アプリケーションに対してコミット応答を返したときには 3 台のマシンに反映が終わっている）。このため、マシンクラッシュ時であっても、コミットされたトランザクションがロストすることはありません。となると、データベースエンジンとしての性能が気になるところですが、実際には、① データは同一データセンタ内の別マシンへ複製されている（＝極端に離れたところに複製しているわけではない）、② データベースの最大容量が 10GB に制限されている、などの理由により、それほど大きな性能劣化にはなりません。

※ （参考） これらのことから分かるように、そもそも SQL Azure データベースサービスのようなクラウド型のデータベースサービスというものは、極めて高い性能要件（特に応答速度要件）を満たすことが原理的に難しいものです。SQL Azure データベースサービスはそもそも SAN のような高価なディスクストレージを利用していないでしょうし（おそらくただの 2.5” HDD でしょう）、さらにデータベースサーバ自体、複数のユーザによって共用されています。こうしたことを考えると、応答速度の保障が求められるようなシステム（例えばオンライントレードシステムのようなもの）には、クラウド型データベースは原理的に不向きである、と言えるでしょう。（ちなみに、極端に負荷の高い処理をしているユーザを強制的に遮断・切断する仕組み（スロットリングシステム）は持っていますので、タチの悪い他のユーザによってデータベースが使えなくなる、といったことがないようにはなっています。）

これ以外にも、データベースに関して様々な制約事項（分散トランザクションが使えない、ヒープテーブルが使えない、etc.）がありますが、これらについては後ほど記述します。ただ、制約事項はそれなりにありますが、一般に、高可用性データベースの運用というのは非常に難しく、コストもかかるものです。SQL Azure データベースでは、99.9% のサービス可用性を持つデータベースを、月額 10,000 円程度＋トラフィック課金で利用できるわけですが、このサービスを使えば、データベースの監視もフェイルオーバ対策もぜんぶ Microsoft にお任せ可能。これは TCO 的な観点からすると激安である、と考えられるのではないでしょうか？ 制限事項はあれど、使える部分には積極的に使っていきたいサービスではないかと思います。

では最後に、Windows Azure ストレージサービスについて解説します。

※ エントリが長いので分割しました。その 3に続きます。

※ その 2のエントリからの続きです。（エントリが長すぎてポストできなかったため、分割しています。）

［③ Windows Azure ストレージサービス］

Windows Azure ストレージサービスとは、大規模・大容量の、高信頼性データストレージサービスです。内部的には、データを複数のサーバで分散・冗長化して保持するようになっているのですが、外から見た場合にはこれが巨大な一つのストレージシステムに見えるようになっている、というのが、この Windows Azure ストレージサービスです。SQL Azure データベースサービスと同様、実際のデータは少なくとも 3 つのノードに複製格納されているため、ひとつのサーバがクラッシュしても、データは生き残ることが可能になっています。

※ （注意） ”Windows Azure” という名を冠していますが、前述の Windows Azure コンピュートサービスとは全くの別物なので注意してください。

※ （参考） 現状では、Windows Azure ストレージサービス、SQL Azure データベースサービスのいずれも、Geo-Replication （データセンタまたがりのデータ複製）には対応していません。

通常、こうしたストレージシステムに対しては、ローカル HDD であれば普通の Windows エクスプローラで、リモート HDD であればファイル共有を通してアクセスすることになります。しかし、この Windows Azure ストレージサービスでは、HTTP REST プロトコルと呼ばれる、特殊な HTTP プロトコルでデータの読み書きを行います。

この HTTP REST プロトコルを直接ハンドリングするのは大変ですが、幸い、C# や VB などでアプリケーションを開発する場合には、Windows Azure ストレージサービスへアクセスするためのライブラリを使うことができます。このため、このライブラリを利用すれば、HTTP REST プロトコルを知らなくても、Windows Azure ストレージサービスへのデータの読み書きを実施することができます。例えば、コンソールアプリケーションから、Windows Azure ストレージサービスを読み書きするには、以下のようなコードを利用します。（※ このサンプルコードは特に理解しなくても大丈夫です。興味がある方は読んでください。本論からは逸れるため、今回はコードの詳細は説明しません。）

   1: CloudStorageAccount storageAccount = new CloudStorageAccount(

   2:new StorageCredentialsAccountAndKey("nakama000", 

   3:"sLyGGvOHJszS9wABrog4HhrxN+8ICH0A/diyMp.....JS/6Cm4S9c3TDH+CRRo8Tj5vIpgYfB7yArq1+xWjDSg=="),

   4:new Uri("http://nakama000.blob.core.windows.net"),

   5:new Uri("http://nakama000.queue.core.windows.net"),

   6:new Uri("http://nakama000.table.core.windows.net"));

   7:  

   8: CloudTableClient tableClient = storageAccount.CreateCloudTableClient();

   9: CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

  10: CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();

  11:  

  12:// コンテナへの接続

  13: CloudBlobContainer blobContainer = blobClient.GetContainerReference("pictures");

  14:// コンテナの作成

  15:bool created = blobContainer.CreateIfNotExist();

  16: Console.WriteLine((created ? "コンテナを作成しました。" : "コンテナはすでに存在します。"));

  17:// コンテナに対して、public アクセスを認めるように設定（http://.../Container/BlobName でアクセス可に）

  18: var permissions = blobContainer.GetPermissions();

  19: permissions.PublicAccess = BlobContainerPublicAccessType.Container;

  20: blobContainer.SetPermissions(permissions);

  21: Console.WriteLine("権限設定しました。");

  22:  

  23:// ファイルのアップロード

  24:string path = @"C:\Users\Public\Pictures\Sample Pictures";

  25:foreach (string fullPathFilename in Directory.GetFiles(path, "*.jpg"))

  26: {

  27:string filename = fullPathFilename.Substring(fullPathFilename.LastIndexOf("\\") + 1);

  28:     byte[] data = File.ReadAllBytes(fullPathFilename);

  29:  

  30:     // まずファイルポインタを作成

  31:     CloudBlob blob = blobContainer.GetBlobReference(filename);

  32:     // すでに存在していたら削除

  33:     bool delete = blob.DeleteIfExists();

  34:     if (delete) Console.WriteLine("すでにデータがあったため、いったん削除しました。");

  35:     // そこに書き込みを行う ※ アップロード時にエラーがあってもちゃんと報告してくれないので注意

  36:     blob.UploadByteArray(data);

  37:     // クライアントに送り返すヘッダー情報を設定

  38:     blob.Properties.ContentType = "image/jpeg";

  39:     blob.SetProperties();

  40:     // サーバ側で保持するファイルのメタデータを記録

  41:     blob.Metadata["OriginalFilename"] = fullPathFilename;

  42:     blob.SetMetadata();

  43:     Console.WriteLine("ファイルを書きこみました。" + filename);

  44: }

  45:  

  46: // ファイルの一覧

  47: var blobs = blobContainer.ListBlobs();

  48: int i = 0;

  49: foreach (var b in blobs)

  50: {

  51:     // 各ファイルのメタデータを取得

  52:     CloudBlob cb = blobContainer.GetBlobReference(b.Uri.AbsoluteUri);

  53:  

  54:     // 属性データをサーバから取得

  55:     cb.FetchAttributes();

  56:     Console.WriteLine("{0} {1} {2}", 

  57:     cb.Uri.AbsoluteUri, 

  58:     cb.Properties.LastModifiedUtc, 

  59:     cb.Attributes.Metadata["OriginalFilename"]);

  60:  

  61:     // データの読み取り（直接ファイルにダウンロードすることも可能）

  62:     cb.DownloadToFile(@"C:\temp\" + (i++).ToString() + ".jpg");

  63: }

前述した Windows Azure コンピュートサービスを利用する場合、この Windows Azure ストレージサービスは、ログデータの転送先として非常に重要なものになります。これは以下のような理由によります。

Windows Azure コンピュートサービスを利用する場合、各仮想マシンは、インスタンス数の増減やサービスのフェイルオーバなどによって、簡単に起動したりシャットダウンさせたりすることができます（というより、それが Windows Azure コンピュートサービスの大きなウリです）。この結果、ローカルマシンに記録した内容（イベントログやパフォーマンスログ、ローカル HDD 上に記録したデータなど）は簡単に消え去ったり初期化されたりすることになります。このため、Windows Azure コンピュートサービスでは、基本的にはローカルマシンやローカルリソース（例えばローカル HDD など）にデータを記録・保存すべきではありません。……が、これではログファイルなどの記録や保存を行うことが全くできなくなってしまうため、困ってしまいます。

このため、各種のデータを残しておく目的で、以下の 2 つのストレージシステムを使います。

• SQL Azure データベースサービス ： 主にトランザクショナルな業務データの保存に利用
• Windows Azure ストレージサービス ： 主に各種のログファイルの保存に利用

このようにしていただければ、Windows Azure コンピュートサービスの仮想マシンインスタンスが増減したとしても、業務データやログデータが消失することはありません。

とはいえ、正直なところ、各種のログデータの出力先をすべて Windows Azure ストレージサービスにするようにアプリケーションを作ったり書き換えたりするのはなかなか大変です。この問題についても以下のような対処方法が用意されています。

応用的な内容になるため今回の一連のエントリでは解説しませんが、Windows Azure コンピュートサービス内の各仮想マシンには、Diagnostic Monitor ランタイムと呼ばれるサービスがインストールされています。このサービスは、イベントログやパフォーマンスログ、フラットファイルなどを定期的に監視・データ収集し、Windows Azure ストレージサービスへとデータを転送するようになっています。このサービスが存在するため、各アプリケーションから直接 Windows Azure ストレージサービスへデータを書き込む必要はなく、従来通り、イベントログやパフォーマンスログなどにデータを出力しているだけで済むようになっています。

ただし、既定ではこれらのサービスは動作していません。このため、構成設定や起動処理を行うことによって、このデータ転送機能を有効化する必要があります。Diagnostics Monitor が既定で転送できるデータの種類は以下の通りです。（転送処理を自力で作り込むこともできるようになっています）

※ （参考） Diagnostic Monitor ランタイムの使い方についてはここでは紹介しませんが、このサイトが非常に詳しいので、興味がある方は読んでみてくださ���。（おそらく Diagnostic Monitor ランタイムを作っているチームの人だと思います）

※ （参考） なお、残念ながら現時点では Windows Azure ストレージサービスに転送されたログデータを簡単に見る方法（ビュアー）が提供されていないため、それらについては自作する必要があります。というか RTM したらログビュアーが提供される、という話だったような気がするんですがまだ提供されていないような……；

※ （注意） Diagnostic Monitor ランタイムによるログデータの転送機能は、遅延転送での動作になっています。このため、仮想マシンのクラッシュが発生した場合には、ログのとりこぼしが発生する危険性があります（通常の Web サーバでもマシンがクラッシュした際にはデータロストが発生するので当たり前のことですが；）。欠損してはならないデータの場合には、このログ転送の仕組みを使うのではなく、業務ログとして、SQL Azure データベースサービスなどに書き込むように設計してください。

さて、Windows Azure ストレージサービスでは、予め 4 種類のデータ構造が定義されており、それぞれの構造を持つデータを簡単に出し入れすることができるように設計されています。

• BLOB （巨大なバイナリデータ） : メディアファイルなどの格納に最適
• Table （ハッシュテーブル的なデータ） : キー付きのデータの保存に最適
• Queue （メッセージキュー） : Azure サーバ間の通信に利用
• Drive （NTFS ドライブ） : あたかも NTFS ドライブのように扱えるストレージ

これらについては比較的誤解があったり、わかりにくい資料も多いため、どんなものなのかを簡単に解説しておきたいと思います。

A. BLOB （巨大なバイナリデータ）

.wmv, .wav, .mp3, .jpg, .zip, .vhd などなど、主にマルチメディア系のファイルや巨大なデータファイルなどを格納するのに適したストレージ形式です。IIS ログファイルのようなただのテキストファイルに関してももちろん保存可能で、外から見た場合には 1 階層のファイルシステムであるかのように取り扱うことが可能です。

通常の Web サーバの場合には、FTP プロトコルでファイルをアップロードすることが多いと思いますが、この Windows Azure BLOB ストレージの場合には、HTTP REST プロトコルでファイルをアップロードすることになります。以下に概念図を示します。

なお、重要なポイントとして、各フォルダには public / private の設定を行うことができ、public 設定にした場合には、読み取りに関しては通常の HTTP-GET によるデータ取得ができるようになっています。（ファイル書き込みに関しては、HTTP-REST プロトコルでしか行うことができません。）

※ （参考） アクセス権限設定については、public / private の 2 択で、細かいアクセス可否設定はできません。残念；。

B. Table （ハッシュテーブル的なデータ）

Table ストレージは、プレインオブジェクト（POCO、プロパティ値のみを持つようなオブジェクト）を、お皿のようなものに入れて分散格納することができるストレージです。下図のようなイメージでとらえていただくとわかりやすいでしょう。

Windows Azure Table ストレージを利用するためには、各オブジェクトに対して、必ず以下の 2 つのキーを付与する必要があります。（正確にはこの 2 つに加えてデータ更新時の楽観同時実行制御用の Timestamp フィールドも必要になるのですが、まあとりあえずそれは置いておくとすると。）

• PartitionKey : データを複数のグループに分割するためのキー
• RowKey : 当該パーティションの中での一意識別キー

同一の PartitionKey を持つオブジェクトは必ず同一ノード（同一物理サーバ）で保持されるようになっていますが、異なる PartitionKey を持つオブジェクトは別ノードに保持されます。このため、データ検索処理を行うと、下図のように、複数のノードで分散検索処理が行われるようになります。

このことからもわかるように、Windows Azure Table ストレージを利用する場合には、PartitionKey の設計が極めて重要になります。うかつな PartitionKey を利用すると、検索速度などが極端に劣化することがあるため、注意してください。

なお、Windows Azure Table ストレージは、「テーブル」という名前がついているものの、いわゆる RDBMS のテーブルとは全くといっていいほど異なるものです。確かに、オブジェクトインスタンスを「行」、プロパティを「列」と捉えれば、確かにテーブル的な構造を持っているといえなくもありません。

しかし、以下のような点は全く異なります。

• テーブル間にリレーションシップを定義できない
• Join 処理も不可（単独テーブルへの出し入れのみ）
• トランザクション処理が基本的に不可（一連のデータの読み書きを 1 トランザクションに束ねることができない）
• 任意の列にインデックスを付与することができない
• 1 つのテーブルに、異なる構造のオブジェクトを格納できる

中でも最後の特徴は極めて重要です。Windows Azure Table ストレージでは、ストレージに対してスキーマの指定ができません。これは、Azure Table ストレージでは、（RowKey さえ異なれば）同一のテーブルに異なる構造を持ったオブジェクトを格納することができるためです。例えば、Author オブジェクトと Title オブジェクトという、異なる構造を持ったデータを同一テーブルに格納した場合を以下に示します。

この様子を無理矢理に表形式に書き直すと「穴空き表」になりますが、ストレージ内部で隙間だらけのデータとして格納しているわけではありません。実際には、左の図のように、「異なるオブジェクトがひとつのお皿の上に乗っているだけ」という状態になります。このような状態は、RDBMS のテーブルでは考え難いことですが、Windows Azure Table ストレージではごく当たり前のこととして扱われます。「テーブル」という名前にあまり惑わされないようにしていただければと思います。

C. Queue （メッセージキュー）

Windows Azure Queue ストレージは、その名の通り、メッセージキューシステムになります。以下のようなシンプルな機能を持ったメッセージキューシステムを提供します。

• やり取りできるデータ → string 型と byte[] 型のみ
• 送達保障・順序制御 → Exactly-Once のみ、In-Order なし
• リトライキュー・デッドキュー → なし
• メッセージ暗号化 → なし（キューに対する接続時の認証のみ）

機能は限定的ですが、その分、プログラミングは非常に単純です。

この Windows Azure Queue ストレージは、現在では利用シナリオが非常に限定的です。これは次のような理由によります。

• もともと Queue ストレージは、Windows Azure コンピュートサービスにおいて、Web Role サーバと Worker Role サーバを連携させるための通信経路として使うことを念頭において設計されていた。
• ところが現在では、Worker Role サーバが TCP/IP 通信を直接受け付けることができるようになっている。このため、Web Role サーバから Worker Role サーバへの単純な通信は、TCP/IP 直接通信で行えば済む。 （＝一般的に非同期接続は設計・実装が大変になるので、わざわざ Queue ストレージを使って非同期接続する必要性はない）

すなわち、Windows Azure Queue ストレージを利用するのは、Web Role サーバと Worker Role サーバ間をキュー型接続（＝非同期接続）しなければならない場合に限られる、ということになります（と書くとやや言いすぎですが、とりあえずはそう理解しておいても差し支えないでしょう）。実際にはそのようなケースはほとんどない（キュー型トランザクション処理が求められるケースは少ない）でしょうから、簡単なアプリケーションやシステムではほとんど使われることがない、と思っていただいてよいと思います。

D. Drive （NTFS ドライブ）

これは、中身としては Windows Azure BLOB ストレージなのですが、それをあたかも NTFS ドライブであるかのようにして使うことができる、という特殊な形式になります。アプリケーションから見た場合にはただの NTFS ボリュームであるかのように見えるため、通常のファイル I/O の API を使ってアクセスすることができる（ただし通常のローカル HDD に比べると若干アクセスが遅い）というものになります。現時点ではまだ未リリースのため詳細は不明ですが、今後、明らかになってくることでしょう。

というわけで、4 種類のWindows Azure ストレージサービスについて概要を解説してきましたが、重要なのは、どのようなケースでどのストレージサービスを使うのか、という点です。それぞれに適切な使い分けが必要になりますので、よく覚えておいていただければと思います。

［開発上の注意点］

さて、ここまで Windows Azure Platform の提供する主要サービスの概要を解説してきたわけですが、Windows Azure Platform の大きなメリットは、なんといっても

• オンプレミス型の Web アプリケーションの開発と、ほとんど同じ技術を使うことができる。
  ��Web アプリ → ASP.NET で開発、DB サーバ → SQL Server で開発）

という点でしょう。しかしこのことは、オンプレミス型の Web アプリケーションをそのまま Azure プラットフォーム上に移植できるということではありませんし、Azure プラットフォーム上での開発を、���ンプレミス型の Web アプリケーションと完全に同じように捉えられる、ということでもありません。やはり、それ相応に相違点や注意点があります。

基本的に、Windows Azure Platform は PaaS プラットフォームです。このため、オンプレミス型の開発と異なり、ハード／ミドルなどのインフラに関わる設定や運用をほとんど考えなくて済むという利点があります。半面、Web サーバや DB サーバの設定やバージョンを自由に決められない・変更できないという注意点もあります。メリットとデメリットを比較する形で書くと、以下のようになります。

• 主なメリット
  セキュリティパッチの適用、ハード障害時の対応、SQL Server や IIS の構成設定などを考えなくて済む。（すべてデータセンタ側にお任せすることができる）
• 主なデメリット（利用上の注意点）
  タイムゾーン設定、言語設定、照合順序（並び順）、IIS や .NET の構成設定などが変更できないことが多い。ミドルウェアやパッケージ製品の追加インストールにも制限があり、配置するアプリケーションそのものにも制限事項がある。

主だった注意点を以下にまとめます。中でも、特に日本語まわりの注意点は、日本ローカルでアプリケーションを開発していたときとは大きく異なる部分になります。十分に注意して取り組むようにしてください。

このため、実際に Windows Azure Platform 上で動作するアプリケーションを開発する場合には、Azure のインフラ特性などをきちんと理解し、Windows Azure Platform の特性に併せた形でアプリケーション開発を行う必要があります。以上のような背景を考えると、Azure プラットフォームに適したアプリケーションと、適していないアプリケーションとがあると言えます。具体的には以下のようになります。

Windows Azure Platform に適したアプリケーション（クラウド化が適しているもの）

• 一般的なインターネットアプリケーション
• トラフィックが、時期、曜日、時間帯などにより大きく変動するアプリケーション
• ASP サービスとして展開しているアプリケーション
• 自社でインフラを持たないソフトウェア会社が開発するアプリケーション

Windows Azure Platform に不向きなアプリケーション（オンプレミス型が適しているもの）

• セキュリティポリシー上、社外に持ち出すことのできないデータを取り扱っているアプリケーション
• Windows Azure Platform の SLA （サービスレベル）では不十分なミッションクリティカルシステム
• SP や QFE などのソフトウェアバージョンを固定したいアプリケーション

Windows Azure Platform は、一般的な PaaS サービスに比べると敷居が低く、またハイブリッド型（オンプレミスとクラウドを併用する形態）などを取りやすいといったメリットがあります。しかし、あらゆるアプリケーションが Windows Azure Platform 上での動作に適しているというわけではありません。適切なシステム及び適切な部分に対して、上手にWindows Azure Platform を適用するようにしてください。

［本エントリのまとめ］

というわけで、本エントリをまとめる目的で、もう一度、Windows Azure Platform の主要構成要素を俯瞰図的にまとめておきたいと思います。

• ① Windows Azure コンピュートサービス
  Web Role サーバ ： IIS と .NET Framework がインストールされた Web サーバ
  Worker Role サーバ ： .NET Framework がインストールされた汎用サーバ
• ② SQL Azure データベースサービス
  10GB の容量制限を持つデータベース、主に業務データを保存する
  カスタムレプリケーションによる 3 多重化により 99.9% の高可用性を保障してくれる
• ③ Windows Azure ストレージサービス
  主にログデータやバイナリデータを保存するためのストレージシステム
  A. BLOB （巨大なバイナリデータ） : メディアファイルなどの格納に最適
  B. Table （ハッシュテーブル的なデータ） : キー付きのデータの保存に最適
  C. Queue （メッセージキュー） : Azure サーバ間の通信に利用
  D. Drive （NTFS ドライブ） : あたかも NTFS ドライブのように扱えるストレージ

また、これらを利用した典型的な Web-DB アプリケーションの構成は、下図のようになります（コンピュートサービスは主に Web Role サーバを利用、ストレージサービスは主に BLOB, Table を利用）。

また、Windows Azure Platform は PaaS 型プラットフォームであるが故に、オンプレミス型と比べて、ランタイムやミドルウェアの設定を自由に変更できないという問題点があります。このため、ASP.NET Web アプリケーションであれば、どのようなアプリケーションでも Windows Azure Platform 上に移植できる、というわけでもありません。Part 3. のエントリでは実装の詳細に触れていきたいと思いますが、「なんでもかんでもクラウド化」といった考え方をしないように、十分注意してください。

というわけで Part 2. のエントリのアップからしばらく時間が空いてしまってすみません；。実は社内に引きこもってひたすら Azure の Workshop コンテンツを開発していたためなのですが、難産の末、ようやく開発が終了したのでこちらの blog に取り組めるようになった次第だったりします。先日の Tech Days 2010 で正式リリースされたこともあり、ちょうど Windows Azure を学ぶにはよい時期……に図らずもなってしまったので^^、ぜひこちらのコンテンツで、Windows Azure を体験してみていただきたいと思います。

さて、Part 2. のエントリでは、Windows Azure Platform の概要について解説しました。その要点は以下の通りとなります。

• Windows Azure Platform とは、Microsoft による PaaS プラットフォームである。
• 主要構成要素としては、以下の 3 つがある。
  ① Windows Azure コンピュートサービス ： おおまかにいうと「Web サーバ」
  ② SQL Azure データベースサービス ： おおまかにいうと「DB サーバ」
  ③ Windows Azure ストレージサービス ： おおまかにいうと「ネットワークファイル共有」

この Part 3. のエントリでは、いよいよ実際に、Windows Azure 上で動作する Web アプリケーションを開発してみることにします。

• ローカルでの Web アプリケーション開発
• クラウドサービスプロジェクトの追加
• 開発用ファブリック上での動作確認
• Diagnostic Monitor によるアプリケーション監視
• Azure 運用環境への展開
• アプリケーションの修正と Azure 環境への再配置（アップグレード）
• Windows Azure 運用環境を安く使うためのコツ

なお、以降の解説では、Windows Azure SDK 1.1 を利用するため、以下の環境で執筆しています。Visual Studio 2010 の正式版でもほぼ同じになるだろうと思いますが、多少異なる点が発生するかもしれません。予めご容赦ください。

• Windows 7 Enterprise （日本語版）
  ※ IIS 7.5 を追加インストールする必要あり。オプションとして、ASP.NET, WCF HTTP アクティブ化を追加してください。
• Visual Studio 2010 Ultimate RC（英語版）
• SQL Server 2008 R2 November CTP（英語版）
• Windows Azure Tools for Microsoft Visual Studio 1.1 (February 2010)（英語版）

本エントリでは、ASP.NET, SQL Server などに関しての基本的なスキルは一通り持っているものとして解説を行います。もしこれらについてご存知ない場合は、まず ASP.NET や SQL Server に関する通常の書籍を学習した上で、こちらのエントリをお読みいただければ幸いです。

また、本エントリのサンプルコードはこちらになります。必要に応じてお使いください。

それでは早速ですが、解説を進めていきましょう。

［ローカルでの Web アプリケーション開発］

さて、Windows Azure Tools for Microsoft Visual Studio をインストールすると、Visual Studio に Azure アプリケーション開発用のプロジェクトである “Cloud Service Project” が追加されます。こちらを最初から使っても構いませんが、ここでは既存 Web アプリケーションを Azure 上へ移行するようなシナリオも想定して、まずは通常のローカル Web アプリケーションを開発し、これを Azure 上へアップロードする、というシナリオで解説を進めましょう。以下の手順で作業を進めます。

• 新規に Web アプリケーションプロジェクトを作成する。
  Web サイトプロジェクトは不可。また、現在の Windows Azure 上にはまだ .NET Framework 4.0 は搭載されていませんので、.NET Framework 3.5 を選択します。 
  
  
• 1 つ目の Web ページを作成する。
  今回はサンプルとして、① 一般的な Web ページと、② データベース入出力をする Web ページの 2 つを作成することにしましょう。まずは Default.aspx ページに以下のような画面とロジックを作成します。（※ Label3 については後で利用します。）
  
   
  
    
  
• 2 つ目の Web ページを作成する。
  次に、Web プロジェクトに新しく “Default2.aspx” ページを追加し、ここにデータベースアプリケーションを作成します。App_Data フォルダに pubs.mdf ファイルを追加し、SqlDataSource と GridView を用いて、authors テーブルを一覧表示するアプリケーションを作成します（サーバエクスプローラから authors テーブルを Default2.aspx ページ上にドラッグ＆ドロップすると簡単です）。
  この後、以下の 2 つの作業を行ってください。① オートフォーマット機能を使って、適当に色をつける。② GridView の行選択機能を有効化する。
  
  

• ASP.NET 開発サーバ上で動作確認を行う。
  以上の作業が終了したら、Ctrl + F5 キーでアプリケーションを起動し、実行してみてください。特に問題がなければ、ASP.NET 開発サーバが起動し、下図のようにアプリケーションが動作するはずです。 
   
    

では引き続き、このアプリケーションを WIndows Azure 用（Web ロールサーバ用）に修正していくことにします。

［クラウドサービスプロジェクトの追加］

Windows Azure Tools （開発ツールキット）によりインストールされるクラウドサービスプロジェクトは、簡単にいうと、以下の 2 つを行うためのプロジェクトです。

• 開発用 PC の中で、開発用ファブリック（Windows Azure エミュレータ）を起動し、その上でアプリケーションを実行・デバッグできるようにする。
• 作成したアプリケーションのファイルを、Windows Azure 本番環境にアップロードできるようにパッケージ化する。

後者については後回しにして、まずは前者から説明します。まず、Visual Studio のソリューションファイルに対して、クラウドサービスプロジェクトを追加します。具体的には以下のようにします。

• ソリューションに対して、Windows Azure Cloud Service プロジェクトを追加する。
• 次の「New Cloud Service Project」の画面で、何も選択せずに OK ボタンを押す。

  
※ この画面では何も選択せずに OK ボタンを押すこと（Cancel するとプロジェクトが追加されないため注意する）

• クラウドサービスプロジェクト内の “Roles” ノードに対して、”Web Role Project in solution” を追加する。
• 先ほど作成した、”WebApplication1” プロジェクトを、Web Role プロジェクトとして追加する。

以上の作業により、”Roles” ノードの中に、”WebApplication1” プロジェクトが追加されます。これによって、この “WebApplication1” プロジェクトは、Web ロールサーバ上に展開されて実行されるようになります。

（注意） 1 つの Web ロールサーバの上には、1 つの Web アプリケーションのみが展開可能です。複数の Web アプリケーションを、同一の Web ロールサーバ上にインストールして実行することはできません。複数の Web アプリケーションを同時に展開したい場合には、複数の種類の Web ロールサーバを使う必要があります。（下図参照）

次に、各ロール（サーバ）についての構成設定を行います。クラウドサービスプロジェクトの “Roles” 下にある各ロールをダブルクリックすると、構成設定画面が現れます。こちらを使うと、以下のような項目が設定できます。

• 利用する仮想マシン（VM）のサイズ（仮想マシンに割り当てる CPU やメモリリソースのサイズ）
• 利用する仮想マシンのインスタンス数
• CAS （Code Access Security）の設定
• 利用する通信の種類（エンドポイントの定義）
• 構成設定データ

ここではまず最も簡単な設定として、”WebApplication1” を動作させる仮想マシンを 3 つに変更しておきます。

※ （注意） 実際の運用環境に配置する場合には、インスタンス数や仮想マシンのサイズをむやみに引き上げないようにしてください。むやみに引��上げると、その分だけ課金が増えるからです。

ここまで設定したら、いよいよ Windows Azure エミュレータ上でこのアプリケーションを動作させてみましょう。（→ その 2へ続く）

※ 本エントリはその 1の続きです。

［開発用ファブリック上での動作確認］

引き続き、”CloudService1” プロジェクトをスタートアッププロジェクトに変更し、Ctrl + F5 キーで実行します（※ サーバエクスプローラが pubs.mdf を握っているとエラーが発生するので、デタッチしてから実行してください）。すると、タスクトレイに “Development Fabric” と呼ばれる Windows Azure エミュレータ環境が起動し、この中でアプリケーションが起動します。

一見すると、先ほどと変わりなく動作しているように見えますが、実際にはかなり異なる環境で Web アプリケーションが動作しています。これについて以下に解説します。

開発用ファブリックのランタイム構成

最終的な運用環境では、このアプリケーションは、ファブリックコントローラによって Windows Azure コンピュートサービスのインフラ上に展開され、複数の仮想マシン（VM, Virtual Machine）が起動します。

通常、IIS 7 ではワーカプロセスとして w3wp.exe が利用されますが、Windows Azure コンピュートサービスでは、専用のワーカプロセスとして WaWebHost.exe というものが用意されており、これが起動します。この WaWebHost.exe には、以下の特徴があります。

• IIS 7 のモジュールをロードして動作するため、内部動作は w3wp.exe とほぼ同じ。
• 内部では、ASP.NET ランタイムが統合パイプラインモードで動作している。
• 1 仮想マシン（サーバ）あたり 1 ワーカプロセスが起動する。（＝1 つの VM の中で、複数のワーカプロセスが起動することはない）

これに対して、開発用ファブリックでは、運用環境で利用される VM と同じ数だけのホストプロセス（WaWebHost.exe）がローカルコンピュータ内で起動します。

この開発環境におけるエミュレーション動作の特徴は、以下の通りです。

• 運用環境と同一のワーカプロセスが複数個使われる。
  この開発用ファブリックでは、1 つのコンピュータ内で、複数のロール、複数の仮想マシンをまとめてエミュレーションする必要があります。このため、開発用マシンの中では、複数の WaWebHost.exe （Worker ロールを使っている場合には WaWorkerHost.exe）が起動する形になります。ワーカプロセスは比較的軽量ですが、とはいえたくさんの VM を利用しようとする場合にはそれなりにマシンのリソース（特にメモリ）を食いますので、注意してください。なお、開発環境と運用環境で利用されるワーカプロセスは基本的にほぼ同じですが、開発環境では 32 ビット版が、運用環境では 64 ビット版が利用される、という点は大きく異なります。.NET のみでアプリケーションを開発している際には問題になりませんが、Unmanaged Code を利用している場合には注意してください。
• リクエストはロードバランサがいったん受け付ける。
  このワーカプロセスは、クライアントブラウザからのリクエストを直接受け付けるわけではありません。いったん、ロードバランサのエミュレータである DFloadbalancer.exe がリクエストを受け付け、それが各ワーカプロセスにルーティングされる、という仕組みになっています。これは運用環境でも同様で、運用環境でもリクエストはいったんロードバランサが受け付け、それが各マシンにルーティングされる形になります。 
    
  
• ポート番号は、運用環境で利用する予定のポート番号とはずれることがある。
  上図を見てわかる通り、運用環境では、各 VM マシンに対してプライベート IP アドレスと、乱数によるポートが定められ、フロントエンドのロードバランサからのリクエストがルーティングされる形になっています。これに対して開発用ファブリック（開発環境）では、各ワーカプロセスに対して乱数によるポートが定められ、フロントエンドのロードバランサからリクエストがルーティングされてくる、という形になっています。
  いずれにおいても、ワーカプロセスが直接リクエストを受け付けるわけではないのですが、注意すべき点として、ロードバランサがリクエストを受け付けるポート番号が、開発環境ではずれてしまうことがある、という点に注意してください。例えば、このサンプルアプリケーションを動作させるとブラウザはポート番号 81 上でこのアプリケーションを呼び出します。これは、開発マシン上では、すでにポート番号 80 が IIS 7.5 にアサインされているために使えないからです。このため、DFloadbalancer.exe は 80 のかわりに 81 （次の空きポート）を利用し、これをリスンする、という形になっています。 
    

さて、このままだと、このアプリケーションが実際にどのワーカプロセスで処理されているのかがわかりません。そこで、このアプリケーションの Default.aspx.cs ファイルに以下のような修正を加えてください。

• Microsoft.WindowsAzure.ServiceRuntime への参照設定を加える。
• using キーワードを追加。（using Microsoft.WindowsAzure.ServiceRuntime;）
• Page_Load() メソッド内に、インスタンス番号を解決して表示するロジックを追加。（Label3.Text = RoleEnvironment.CurrentRoleInstance.Id;）

以上を行った上で、再度 Ctrl + F5 キーで実行すると、Web 画面上にサーバ ID が表示されるようになります。この状態で、リロードやポストバックなどを繰り返していると、ロードバランス機能により、複数のサーバ（ワーカプロセス）に分散処理されることがわかると思います。（※ リロードやポストバックだけでは別サーバインスタンスに振りなおされないケースもありますので、その場合は別の Web ブラウザを起動するなどしてテストしてみてください。）

開発用ファブリックと配置の仕組み

では次に、この開発用ファブリックの動作の仕組みについて、もう少し詳しく見てみましょう。まず、タスクトレイの ”Windows Azure Simulation Environment” のアイコンを右クリックし、メニューから “Show Development Fabric UI” を選択します。これにより、開発用ファブリックの UI が表示されます。

前述したように、Visual Studio からクラウドサービスプロジェクトを実行すると開発用ファブリックが動作し、その上でアプリケーションが動作するわけですが、この動作はより厳密には以下のようになっています。

• Visual Studio からクラウドサービスプロジェクトを実行すると、開発用ファブリック上にアプリケーションが展開される。
  この作業を「配置」と呼びます。配置の際には、一意の配置 ID（Deployment ID）が採番されるようになっています。ちなみに配置 ID は、開発環境と運用環境では全くフォーマットが異なっており、以下のようになっています。
  開発環境 → “deployment(21)” のように、一意連番が振られる。
  運用環境 → “6f4d99b8b339413ea3dac24ce71929af” のように、ランダムな GUID 値が振られる。
• 開発環境では、ローカルマシンの特殊なフォルダにアプリケーションが展開される。
  例えば上記のアプリケーションの場合、”WebApplication1” ロールのインスタンス #0 のアプリケーションは、”C:\Users\nakama\AppData\Local\dftmp\s0\deployment(21)\res\deployment(21).CloudService1.WebApplication1.0” というパスの下側にアプリケーションが展開されて動作しています（このような動作は、ASP.NET 開発サーバによる動作とは全く異なります）。また、このフォルダの下側には、実際に利用する Web アプリケーションの他に、ASP.NET テンポラリファイル、IIS ログ、Diagnostic Monitor によるログファイル、IIS 圧縮キャッシュなど様々なデータが、ロールインスタンス（＝運用環境における仮想マシン）ごとに保存されるようになっています。（ちなみに、このフォルダは、下図のように Development Fabric UI から選択して簡単に開くことができます。） 
  
• 各ワーカプロセスの状況を、このツールからモニタできる。
  このツールはコンソール出力をモニタできるようになっているので、Diagnostic トレースなどを簡単に見たりすることができるようになっています。また、サービスの停止や、配置したアプリケーションの除去などもこのツール上からできるようになっています。
  ただし、このツールから得られる各サーバ（各ロールインスタンス）の情報については非常に限られており、また、運用環境ではこのモニタツールを使うことはできません。例えば、CPU 稼働率やメモリ利用率の監視、IIS ログの確認などといった内容については、このツールからでは確認できません。これらに関しては、次に述べる Diagnostic Monitor による監視が必要になります。

以上で、基本的な開発用ファブリックの利用方法に関しては終わりです。引き続き、これらのサーバをモニタリングする機能を追加していくことにしましょう。

［Diagnostic Monitor によるアプリケーション監視］

前回 Part 2 のエントリでご紹介したように、Windows Azure コンピュートサービス上の仮想マシンのモニタリングを行うためには、Diagnostic Monitor ランタイムと呼ばれるサービスを利用する必要があります。このサービスは、イベントログやパフォーマンスログ、フラットファイルなどを定期的に監視・データ収集し、Windows Azure ストレージサービスへとデータを転送するために導入されているものです。

さて、この Diagnostic Monitor ランタイムでは様々なログデータを転送できるようになっているのですが、実際にはちょっとクセがあります。Diagnostic Monitor ランタイムのドキュメント類を参照すると、以下のようなログファイルが転送できると書かれています。

が、この転送は、転送先が Table ストレージになるものと、Blob ストレージになるものとで、仕組みがかなり異なっています。

• 転送先が Table ストレージになっているもの
  ログファイルは、構造を持ったテーブルデータとして、特定の Table ストレージに転送・追記されていきます。
• 転送先が Blob ストレージになっているもの
  ログファイルは、バイナリファイルとして Blob ストレージに転送・保存されます。

つまり、トレースログやパフォーマンスカウンタのデータは、スキーマを持ったデータとして Table ストレージに分解・整理・転送されるのですが、IIS ログファイルや FREB ログファイルなどは、ただのバイナリファイルとして Blob ストレージに転送される、という形になっています。

※ （参考） 上記の分類では、アプリケーションクラッシュダンプや IIS ログ、FREB ログなどが個別の仕組みとして転送できるように書かれているのですが、実際には、これらはすべて「特定ディレクトリ下のファイルをまとめて転送する」という共通の仕組みによりデータ転送が行われています（＝仕組みとしては同一で、転送対象となるディレクトリがそれぞれについて指定されている）。このため、例外ログのように独自のログファイル出力機能を持っているアプリケーションの場合には、対象フォルダをこの仕組みに乗せてやれば、独自ログファイルを Azure Blob ストレージに転送させることができるようになります。ただし、独自ログファイルを使う場合、Windows Azure コンピュートサービス上ではセキュリティ制約により、特定のフォルダ（ローカルストレージ（RoleEnvironment.GetLocalResource()））以外への書き込みが認められなくなっているため、この点についてのコード修正が必要になります。ここではこれ以上の深掘りはしませんので、興味がある方は調べてみてください。

※ （参考） また、ローカルで収集されたデータを Windows Azure ストレージサービスに転送する方法は、① 一定時間間隔で自動的に行う方法と、② オンデマンドで指示を出して行わせる方法の 2 通りがあります。②の方法はやや作り込みが必要になるため、ここでは①の方法についてのみ解説します。

さて、Diagnostic Monitor を使うためには、以下の作業が必要になります。

• Windows Azure ストレージ側の事前準備
  転送先となる Blob ストレージ、Table ストレージなどに、それぞれコンテナやテーブルなどを作成しておく。
• 収集するログファイルに関する設定方法
  WebRole.cs ファイルの起動処理メソッドの中に、収集方法を指定する。
• ログファイルの確認方法
  Windows Azure ストレージにアクセスして、データを読み出す。

これらについて順に解説します。

Windows Azure ストレージ側の事前準備

まず、Windows Azure ストレージ側に、データを格納するための Blob コンテナや Table ストレージを作成します。データ転送先となる Blob や Table の名称の多くは固定的に定められていますので、以下のような名称でコンテナやテーブルを作成します。

具体的な作業手順は以下の通りです。

• 開発用ストレージサービスを起動する。
  タスクトレイの ”Windows Azure Simulation Environment” を右クリックし、”Start Development Storage service” を選択して開発用ストレージサービスを起動します。
  
  ※ （参考） この開発用ストレージサービスは、内部的には SQL Server Express Edition のファイルアタッチデータベースを利用しているため、SQL Server Express Edition がインストールされていないとうまく起動しません。
  ※ （参考） 開発用ストレージにゴミがたまってしまった場合には、”Show Development Storage UI” から Reset ボタンを押下すると、簡単に初期状態（空の状態）に戻すことができます。 
  
• Blob コンテナやテーブルを作成する。
  次に、コンテナやテーブルを作成します。作成する際は、① ツールを使って手作業でコンテナやテーブルを作成していく方法と、② コンソールアプリケーションなどを使ってコンテナやテーブルを作成する方法の 2 通りがあります。どちらの方法でも構いませんが、ここでは②の方法について示すと、以下のような簡単なコードで作成することが可能です。

   1:using System;

   2:using System.Collections.Generic;

   3:using System.Linq;

   4:using System.Text;

   5:  

   6:// Microsoft.WindowsAzure.ServiceRuntime.dll と Microsoft.WindowsAzure.StorageClient.dll へ参照設定

   7:using Microsoft.WindowsAzure;

   8:using Microsoft.WindowsAzure.StorageClient;

   9:  

  10:namespace ConsoleApplication1

  11: {

  12:class Program

  13:     {

  14:staticvoid Main(string[] args)

  15:         {

  16:// 開発環境の場合（運用環境の場合には適宜コードを修正）

  17:             CloudStorageAccount storageAccount = CloudStorageAccount.DevelopmentStorageAccount;

  18:  

  19:// 作成するコンテナ、テーブル、キューの名称一覧

  20:string[] containerNamesToCreate = newstring[] {

  21:"wad-iis-failedreqlogfiles", "wad-iis-logfiles", "wad-crash-dumps" };

  22:string[] tableNamesToCreate = newstring[] {

  23:"WADLogsTable", "WADDiagnosticInfrastructureLogsTable",

  24:"WADPerformanceCountersTable", "WADWindowsEventLogsTable", "WADDirectoriesTable" };

  25:string[] queueNamesToCreate = newstring[] { };

  26:  

  27:// コンテナ、テーブル、キューを作成

  28:             CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

  29:foreach (string containerName in containerNamesToCreate)

  30:             {

  31:                 CloudBlobContainer blobContainer = blobClient.GetContainerReference(containerName);

  32:bool created = blobContainer.CreateIfNotExist();

  33:if (created) Console.WriteLine("{0} : コンテナを作成しました。", containerName);

  34:             }

  35:             CloudTableClient tableClient = storageAccount.CreateCloudTableClient();

  36:foreach (string tableName in tableNamesToCreate)

  37:             {

  38:bool result = tableClient.CreateTableIfNotExist(tableName);

  39:if (result) Console.WriteLine("{0} : テーブルを作成しました。", tableName);

  40:             }

  41:             CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();

  42:foreach (string queueName in queueNamesToCreate)

  43:             {

  44:                 CloudQueue queue = queueClient.GetQueueReference(queueName);

  45:bool result = queue.CreateIfNotExist();

  46:if (result) Console.WriteLine("{0} : キューを初期化しました。", queueName);

  47:             }

  48:         }

  49:     }

  50: }

ストレージの準備が済んだら、今度は Web アプリケーションに、ログデータ収集と自動転送を行わせるための設定コードを追加します。

収集するログファイルに関する設定方法

Diagnostic Monitor による監視を行うためには、① データをローカルマシン内で収集させるための設定と、② それを Azure ストレージに自動転送させるための設定の 2 つが必要です。収集するログの種類ごとに、設定可能な項目が少しずつ異なりますが、ざっくり書くと、以下のような項目が設定できます。

設定を行うためには、以下の作業を行います。

• Web アプリケーションに WebRole.cs という名前のファイルを追加する。
• 参照設定として、Microsoft.WindowsAzure.ServiceRuntime, StorageClient, Diagnostics の 3 つの DLL を追加する。
• using キーワードで、Microsoft.WindowsAzure, StorageClient, ServiceRuntime, Diagnostics の 4 つの名前空間を導入する。
• WebRole.cs クラスを RoleEntryPoint クラスの派生クラスにする。
• OnStart() メソッドを実装する。

まずここまでの作業結果を以下に示します。

   1:using System;

   2:using System.Collections.Generic;

   3:using System.Linq;

   4:using System.Web;

   5:  

   6:using Microsoft.WindowsAzure.StorageClient;

   7:using Microsoft.WindowsAzure.Diagnostics;

   8:using Microsoft.WindowsAzure.ServiceRuntime;

   9:using Microsoft.WindowsAzure;

  10:  

  11:namespace WebApplication1

  12: {

  13:publicclass WebRole : RoleEntryPoint

  14:     {

  15:publicoverridebool OnStart()

  16:         {

  17:// ここに初期化処理を実装する

  18:  

  19:returnbase.OnStart();

  20:         }

  21:     }

  22: }

そしてこの OnStart() メソッドに、Diagnostic Monitor の初期化処理を記述します。

   1:using System;

   2:using System.Collections.Generic;

   3:using System.Linq;

   4:using System.Web;

   5:  

   6:using Microsoft.WindowsAzure.StorageClient;

   7:using Microsoft.WindowsAzure.Diagnostics;

   8:using Microsoft.WindowsAzure.ServiceRuntime;

   9:using Microsoft.WindowsAzure;

  10:  

  11:namespace WebApplication1

  12: {

  13:publicclass WebRole : RoleEntryPoint

  14:     {

  15:publicoverridebool OnStart()

  16:         {

  17:// 構成設定ファイルの変更を自動追尾するための処理（詳細は後述）

  18:             CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>

  19:             {

  20:                 configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

  21:                 RoleEnvironment.Changed += (sender, arg) =>

  22:                 {

  23:if (arg.Changes.OfType<RoleEnvironmentConfigurationSettingChange>()

  24:                         .Any((change) => (change.ConfigurationSettingName == configName)))

  25:                     {

  26:if (!configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)))

  27:                         {

  28:                             RoleEnvironment.RequestRecycle();

  29:                         }

  30:                     }

  31:                 };

  32:             });

  33:  

  34:             DiagnosticMonitorConfiguration dmc = DiagnosticMonitor.GetDefaultInitialConfiguration();

  35:  

  36:// トレースログ (※ web.config への設定も必要)

  37:             dmc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(2);

  38:             dmc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Warning;

  39:  

  40:// Diagnostic Monitor ログ

  41:             dmc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = TimeSpan.FromMinutes(2);

  42:             dmc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Critical;

  43:  

  44:// イベントログ

  45:             dmc.WindowsEventLog.DataSources.Add("Application!*");

  46:             dmc.WindowsEventLog.DataSources.Add("System!*");

  47:             dmc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(2);

  48:             dmc.WindowsEventLog.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

  49:  

  50:// パフォーマンスカウンタ

  51:             dmc.PerformanceCounters.DataSources.Add(

  52:new PerformanceCounterConfiguration()

  53:                 {

  54:                     CounterSpecifier = @"\Processor(_Total)\% Processor Time",

  55:                     SampleRate = TimeSpan.FromSeconds(60)

  56:                 });

  57:             dmc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(2);

  58:  

  59:// カスタムファイルログ (※ IIS ログ, FREB ログ, クラッシュダンプは設定済み)

  60:             dmc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);

  61:  

  62:// Diagnostic Monitor をスタートさせる

  63:             DiagnosticMonitor.Start("DiagnosticsConnectionString", dmc);

  64:  

  65:returnbase.OnStart();

  66:         }

  67:     }

  68: }

コードの意味については見れば概ねわかると思いますが、基本的には、① データ収集に関する条件と、② データ自動転送に関する条件を指定しています。おおまかにいえば、データ転送に関する条件を .ScheduledTransferPeriod プロパティや .ScheduledTransferLogLevelFiler プロパティにより設定し、その他の .DataSource プロパティなどでデータ収集条件を設定します。ここでは 2 分間隔でデータ転送する形にしましたが、実際のシステムでは転送間隔はもう少し長くてもよいでしょう。

※ （参考） データの転送間隔については、むやみに短くしないことをおすすめします。これは、転送間隔をむやみに短くすると、それだけシステムに負荷がかかってしまうためです。「仮想マシンがクラッシュするとログデータが吹き飛ぶので、極力転送間隔を短くしておきたい」と考える人もいると思います（し、それは確かに正しいのです）が、通常のシステムでも、ローカルマシンに出力されたファイルを監視マシンに吸い上げるときにはある程度の時間間隔を置いてチェックおよび吸出しを行っているはずです。それと同様に考えればよいでしょう。

さて、上記のサンプルコードについては、いくつかの注意点があります。要点を説明すると、以下の通りです。

• コードの先頭に書かれている、.SetConfigurationSettingPublisher() メソッドは、サービス構成設定の変更を動的に追いかけるためのコードです。が、ここではまだ意味が分からないと思いますので、とりあえず「呪文」だと思っておいていただければ結構です。（詳細はこのあとでまた解説します。）
• 「トレースログ」と書かれているのは、System.Diagnostics トレース（System.Diagnostics.Trace.
  WriteLine() などの命令により出力される Win32 トレースログ）ですが、この機能を使うためには、web.config ファイルに以下の記述を追加する必要があります。このコードを追加することにより、Win32 トレースログの情報が、Azure の Diagnostic Monitor ランタイムの方に転送され、記録されるようになります。

   1:<?xml version="1.0"?>

   2:<configuration>

   3:  

   4:   ... (前略) ...

   5:  

   6:<system.diagnostics>

   7:<trace>

   8:<listeners>

   9:<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

  10:             name="AzureDiagnostics" />

  11:</listeners>

  12:</trace>

  13:</system.diagnostics>

  14:  

  15:   ... (後略) ...

  16:  

  17:</configuration>

• 「Diagnostic Monitor ログ」とは、Diagnostic Monitor ランタイム自身から発生するログですが、これに関しては必ずフィルタリング条件を設定してください。（少なくとも Warning 以上） Verbose レベルでデータ収集を行うと、大量（数秒間に数十エントリ）のデータが出力されてとんでもないことになります；。基本的には Critical などに設定しておけば十分でしょう。
• （参考） イベントログのデータ収集・転送に関しては、運用環境では問題なく動作するのですが、開発環境ではどうもうまく動作しないようです。私自身、原因がどこにあるのかまだわかっていませんが、運用環境では動くので、開発環境で動作しないことについては目をつぶっていただけると助かります；。（と、つぶやいてみる；。）
• 最後の DiagnosticMonitor.Start() メソッドによって Diagnostic Monitor ランタイムを起動していますが、このメソッドの第 1 パラメータ（ここでは “DiagnosticsConnectionString”）で、転送先となる Windows Azure ストレージへの接続情報を設定しています。この接続情報は、クラウドサービスプロジェクト側の “Settings” セクションに設定されており、既定では “UseDevelopmentStorage=true” （開発ストレージにログ情報を転送する）という設定になっています。（運用環境に持っていく場合には、この設定値を、本番環境の Windows Azure ストレージサービスへの接続文字列に書き換えます。）

※ （参考） 最後の Windows Azure ストレージサービスへの接続文字列情報に関してですが、以下のようなコードを使えば、直接、データ転送先のストレージを指定することができます。が、この方法を使うと、環境切り替えが大変になるため、通常は、上記のような方法を使って、構成設定情報として接続先ストレージの情報を切り出しておきます。

   1:// CloudStorageAccount クラスを使って指定する方法もあるが、環境切り替えが大変。

   2: CloudStorageAccount storageAccount = new CloudStorageAccount(

   3:new StorageCredentialsAccountAndKey("devstoreaccount1",

   4:"Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw=="),

   5:new Uri("http://127.0.0.1:10000/devstoreaccount1"),

   6:new Uri("http://127.0.0.1:10001/devstoreaccount1"),

   7:new Uri("http://127.0.0.1:10002/devstoreaccount1"));

   8: DiagnosticMonitor.Start(storageAccount, dmc);

以上で設定は完了です。この状態で、アプリケーションを実行してみてしばらく使い、その後、放置（5 分程度）してみてください。これにより、ログデータが適宜 Azure ストレージに転送されているはずです。

ログファイルの確認方法

最後に、転送されたログファイルを確認してみることにします。一番手っ取り早い方法は、各種のツールを使って Windows Azure ストレージに接続し、その中を確認してしまう方法です。残念ながら現在のところは Microsoft の便利なオフィシャルツールが存在しないため（っつーか誰か作ってほしい．．．．とつぶやいてみる；）、3rd party 製のツール（例えば Cerebrata 社の Cloud Storage Studio など）を使う必要があります。

ですが、このようなツールを入手したり使ったりすることが困難な場合には、コンソールアプリケーションなどを書いておくと便利でしょう。ここでは、Azure ストレージに保存された IIS のログファイルをダウンロードするためのコードを以下に示します。

   1:using System;

   2:using System.Collections.Generic;

   3:using System.Linq;

   4:using System.Text;

   5:  

   6:using Microsoft.WindowsAzure;

   7:using Microsoft.WindowsAzure.StorageClient;

   8:using System.IO;

   9:  

  10:namespace ConsoleApplication2

  11: {

  12:class Program

  13:     {

  14:staticvoid Main(string[] args)

  15:         {

  16:// Diagnostic Monitor のログデータ一括転送

  17:// 開発環境の場合（運用環境の場合には適宜コードを修正）

  18:             CloudStorageAccount storageAccount = CloudStorageAccount.DevelopmentStorageAccount;

  19:  

  20:// 転送先となるローカルパス

  21:string localRootPath = @"C:\temp\" + DateTime.UtcNow.ToString("yyyyMMdd_HHmmss");

  22:             bool willFileDelete = true; // 転送したファイルを消すか否か

  23:  

  24:             // ① Blob データのダウンロード

  25:             CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

  26:             foreach (string containerName in new string[] {

  27:"wad-control-container", "wad-iis-failedreqlogfiles", "wad-iis-logfiles", "wad-crash-dumps" })

  28:             {

  29:                 CloudBlobContainer blobContainer = blobClient.GetContainerReference(containerName);

  30:                 var blobs = blobContainer.ListBlobs(new BlobRequestOptions() { UseFlatBlobListing = true });

  31:  

  32:                 foreach (var blob in blobs)

  33:                 {

  34:                     CloudBlob cb = blobContainer.GetBlobReference(blob.Uri.AbsoluteUri);

  35:                     string localFilePath = localRootPath + @"\Blob" + blob.Uri.PathAndQuery.Replace('/', '\\');

  36:                     Console.WriteLine(blob.Uri.AbsoluteUri + "→ " + localFilePath);

  37:                     Directory.CreateDirectory(localFilePath.Substring(0, localFilePath.LastIndexOf('\\')));

  38:                     cb.DownloadToFile(localFilePath);

  39:if (willFileDelete) cb.Delete();

  40:                 }

  41:             }

  42:         }

  43:     }

  44: }

実行すると、Windows  Azure ストレージに蓄積された IIS ログを、ローカルマシンにダウンロードすることができるようになります。あとはこれを Excel や各種のログ解析ツールなどに読み込ませて分析していただければよいでしょう。

というわけで Windows Azure コンピュートサービスの監視方法について解説しましたが、これらの説明からわかるように、現時点では、Azure コンピュートサービスの監視 API は比較的剥き出しのような状態で、残念ながら、使いやすいツール類が充実しているとはちょっと言い難い状況です。3rd party 製ツールとしては Cerebrata 社の Azure Diagnostics Managerなどのツールが出てきていますが（デモ見る限りは恐ろしくよくできてますねこれ．．．．；）、このあたりについては今しばらくは手作業で頑張らないといけなさそうな気配です。ただ、Diagnostic Monitor ランタイムの基本動作やその考え方については、今のうちにきっちり理解しておいてよいと思いますので、一度はぜひ触ってみてください。

ではいよいよ、ここまで作成したアプリケーションを、Windows Azure の本番環境に配置していきましょう。（その 3に続く…）

※ 本エントリは その 2の続きです。（エントリが長すぎて投稿できなかったため分割しています）

［Azure 運用環境への展開］

さて、開発用ファブリック上で Web アプリケーションを開発・デバッグし終えたら、いよいよこれを本番環境である Windows Azure 運用環境へとアップロードします。この運用環境への配置（デプロイ）のためには、主に以下の作業が必要になります。

• Windows Azure プラットフォームのアカウントの取得
• SQL Azure データベースサービスへの移行
• Windows Azure ストレージサービスへの移行
• Windows Azure コンピュートサービスへの移行

このうち、1 点目のアカウント取得に関しては、すでに様々な blog などで紹介されていること、また人によって利用可能なオプション（例えば MSDN 特典など）が異なると思いますので、本エントリでは解説しません。利用可能なオプションについては、Windows Azure の PM （プロダクトマネージャ、要するに製品担当）である馬田さんの blogや、クラウド系エバンジェリストとして有名な砂金さんの blogなどを参考にしてください。ここでは、アカウントを取得した後の作業を中心に解説していくことにします。

SQL Azure データベースサービスへの移行

まずはデータベースの移行です。SQL Azure データベースサービスを管理するには、まず管理サイトである https://sql.azure.com/にアクセスし、以下の作業を行います。

• SQL Azure プロジェクトを作成し、管理者アカウントを作成する。
  作成時にデータセンタを選択することになりますが、通常は東南アジアのデータセンタを選択すればよいでしょう。
  
  （ってあれ．．．．今、地図を見たら東アジアの香港の方が近い気がする．．．．orz）
• ファイアウォールの設定を緩和する。
  SQL Azure にアクセスするためには、TCP/IP 1433 ポートでの直結が必要になります。SQL Azure の管理のためには、SQL Server Management Studio から SQL Azure データベースにつなぐ必要がありますので、① 会社内からアクセスする場合には、自社の IT 部門にお願いしてポート 1433 を開けてもらい、② SQL Azure データベースサービス側については、管理サイト（https://sql.azure.com/）の管理画面から、ファイアウォール設定の緩和を行います。
  
  
  ※ （参考） SQL Azure 側のファイアウォールについては、設定変更の反映に約 5 分ほどの時間がかかります。すぐに設定が反映されなくても、しばらく待っていただければ設定が反映されます。
  ※ （参考） 実際のシステム開発では、自社側のポート 1433 を開けることが難しいことが多いと思います。このような場合には、（このあとに述べる初期作業なども含めて）一時的に自宅から作業するなどの工夫を行ってください。
• SQL Azure のサーバ名称などをメモしておく。
  作成した SQL Azure サーバには、ランダムな名称が付与されますので、これをメモしておいてください。ちなみに下図の例では、サーバに対して “mbkz89u87g” という名称が付与されたため、この SQL Azure にアクセスする際には、”mbkz89u87g.database.windows.net” という名称を使う形になります。（ちなみにこのサーバ名称については自分で決めることはできません；。悪しからず；。）
  
• データベースを作成する。
  次に、SQL Azure ポータルサイトからデータベースを作成します。作成時には、データベース名と最大容量を指定しますので、ここでは pubs データベースを 1GB で作成します。
  
  ※ （注意） 後述しますが、SQL Azure データベースの課金は、このデータベースごとに発生します。このため、むやみにデータベースの数を増やさないようにしてください。また、1GB のもの（Web Edition）と、10GB のもの（Business Edition）では課金額が異なりますので、こちらも併せて注意してください。
• SQL Server Management Studio から接続する。
  次に、SQL Server Management Studio から SQL Azure データベースに接続します。接続の際には、① サーバ名として、先のサーバ名（xxx.database.windows.net）を使う、② SQL Server 認証を使う、③ オプション画面において、接続先とするデータベースを選ぶ、を行ってください。
   
  ※（重要） ③の作業（接続時に接続先のデータベースを選択する）は極めて重要です。一般に、通常の SQL Server では、どこかのデータベースに接続したあと、use コマンドを利用して、同一インスタンス内の別データベースに切り替えることができましたが、SQL Azure データベースサービスではこれができません。つまり、SQL Azure では、接続のときに接続先となるデータベースを決める必要があり、一度接続すると、use コマンドで接続先データベースを切り替えることができません。これは SQL Azure データベースサービス特有の制限事項なので注意してください。
  ※（参考） 利用する SQL Server Management Studio のバージョンにより、利用できる機能範囲が変わります。2008 R2 November CTP 以降では、サーバエクスプローラを使ってテーブル一覧などを表示することができるようになりましたが、それ以前のバージョンのものだと、クエリの発行しかできません。サーバエクスプローラなどを使いたければ、最新の Management Studio を使うようにしてください。
• テーブルを作成する。
  次に、SQL Azure データベースサービス上にテーブルを作成します。クエリウィンドウから CREATE TABLE 命令などを発行���、テーブルを作成してください。（今回は簡単のため、authors テーブル、publishers テーブル、titles テーブル、titleauthor テーブルの 4 つだけ作成することにします。）
  なお、SQL Azure データベースはアーキテクチャ的な特徴から、SQL Server データベースに比べてテーブルに関して仕様上の制限がいくつかあります。例えば、① ユーザ定義型が使えない、② クラスタ化インデックスを持たないテーブル（ヒープと呼ばれます）は作成できない、などです。今回、サンプルで利用している pubs データベースはこれらの制限に一部ひっかかるところがありますので、そのまま SQL Azure データベース上に移行することができません。このため、スキーマなどを一部修正したテーブルを利用します。作成時は以下のスクリプトを利用してください。

   1:CREATETABLE authors

   2: (

   3:    au_id          varchar(11)

   4:CHECK (au_id like'[0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9]')

   5:CONSTRAINT UPKCL_auidind PRIMARYKEYCLUSTERED,

   6:    au_lname       varchar(40)       NOTNULL,

   7:    au_fname       varchar(20)       NOTNULL,

   8:    phone          char(12)          NOTNULL

   9:DEFAULT ('UNKNOWN'),

  10:    address        varchar(40)           NULL,

  11:    city           varchar(20)           NULL,

  12:statechar(2)               NULL,

  13:    zip            char(5)               NULL

  14:CHECK (zip like'[0-9][0-9][0-9][0-9][0-9]'),

  15:    contract       bitNOTNULL

  16: )

  17:GO

  18:  

  19:CREATETABLE publishers

  20: (

  21:    pub_id         char(4)           NOTNULL

  22:CONSTRAINT UPKCL_pubind PRIMARYKEYCLUSTERED

  23:CHECK (pub_id in ('1389', '0736', '0877', '1622', '1756') OR pub_id like'99[0-9][0-9]'),

  24:    pub_name       varchar(40)           NULL,

  25:    city           varchar(20)           NULL,

  26:statechar(2)               NULL,

  27:    country        varchar(30)           NULL

  28:DEFAULT('USA')

  29: )

  30:GO

  31:  

  32:CREATETABLE titles

  33: (

  34:    title_id       varchar(6)

  35:CONSTRAINT UPKCL_titleidind PRIMARYKEYCLUSTERED,

  36:    title          varchar(80)       NOTNULL,

  37:    type           char(12)          NOTNULL

  38:DEFAULT ('UNDECIDED'),

  39:    pub_id         char(4)               NULL

  40:REFERENCES publishers(pub_id),

  41:    price          money                 NULL,

  42:    advance        money                 NULL,

  43:    royalty        intNULL,

  44:    ytd_sales      intNULL,

  45:    notes          varchar(200)          NULL,

  46:    pubdate        datetime          NOTNULL

  47:DEFAULT (getdate())

  48: )

  49:GO

  50:  

  51:CREATETABLE titleauthor

  52: (

  53:    au_id          varchar(11)

  54:REFERENCES authors(au_id),

  55:    title_id       varchar(6)

  56:REFERENCES titles(title_id),

  57:    au_ord         tinyint               NULL,

  58:    royaltyper     intNULL,

  59:CONSTRAINT UPKCL_taind PRIMARYKEYCLUSTERED(au_id, title_id)

  60: )

  61:GO

• データを移行する。
  最後に、各テーブルのデータを SQL Azure データベース上にコピーします。データのコピーの方法は SSIS （SQL Server Integration Service）などを使っていただくのが正しいやり方になりますが、ここでは簡単のために、非接続型データアクセスを使ったコンソールアプリケーションを書いて、さくっとアップロードしてしまいましょう。以下のようなコードを使っていただければ、比較的簡単にデータをコピーすることができます。（※ サーバ名などは適宜、ご自身のものに変更してください。）

   1:using System;

   2:using System.Collections.Generic;

   3:using System.Linq;

   4:using System.Text;

   5:using System.Data;

   6:using System.Data.SqlClient;

   7:  

   8:namespace ConsoleApplication3

   9: {

  10:class Program

  11:     {

  12:staticvoid Main(string[] args)

  13:         {

  14:// 手元のファイルアタッチデータベースの SQL Server 上の

  15:// データを、SQL Azure 上にコピーする

  16:             SqlConnection sqlcon1 = new SqlConnection(@"Server=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\pubs.mdf;Integrated Security=true;User Instance=true");

  17:             SqlConnection sqlcon2 = new SqlConnection(@"Server=tcp:mbkz89u87g.database.windows.net;Database=pubs;User ID=nakama@mbkz89u87g;Password=xxxxxxxx;Trusted_Connection=False;");

  18:  

  19:             DataSet ds = new DataSet();

  20:  

  21:// データ読み取り

  22:             SqlDataAdapter sqlda1 = new SqlDataAdapter("SELECT * FROM publishers", sqlcon1);

  23:             SqlDataAdapter sqlda2 = new SqlDataAdapter("SELECT * FROM titles", sqlcon1);

  24:             SqlDataAdapter sqlda3 = new SqlDataAdapter("SELECT * FROM authors", sqlcon1);

  25:             SqlDataAdapter sqlda4 = new SqlDataAdapter("SELECT * FROM titleauthor", sqlcon1);

  26:             sqlda1.Fill(ds, "publishers");

  27:             sqlda2.Fill(ds, "titles");

  28:             sqlda3.Fill(ds, "authors");

  29:             sqlda4.Fill(ds, "titleauthor");

  30:  

  31:// データ書き込み

  32:             SqlDataAdapter sqlda5 = new SqlDataAdapter("SELECT * FROM publishers", sqlcon2);

  33:             SqlDataAdapter sqlda6 = new SqlDataAdapter("SELECT * FROM titles", sqlcon2);

  34:             SqlDataAdapter sqlda7 = new SqlDataAdapter("SELECT * FROM authors", sqlcon2);

  35:             SqlDataAdapter sqlda8 = new SqlDataAdapter("SELECT * FROM titleauthor", sqlcon2);

  36:// 更新クエリ生成

  37:             SqlCommandBuilder scb5 = new SqlCommandBuilder(sqlda5);

  38:             SqlCommandBuilder scb6 = new SqlCommandBuilder(sqlda6);

  39:             SqlCommandBuilder scb7 = new SqlCommandBuilder(sqlda7);

  40:             SqlCommandBuilder scb8 = new SqlCommandBuilder(sqlda8);

  41:// 行ステータスを変更

  42:foreach (DataTable table in ds.Tables)

  43:             {

  44:foreach (DataRow row in table.Rows)

  45:                 {

  46:                     row.SetAdded();

  47:                 }

  48:             }

  49:// データアダプタ経由で INSERT 処理を実施

  50:             sqlda5.Update(ds.Tables["publishers"]);

  51:             sqlda6.Update(ds.Tables["titles"]);

  52:             sqlda7.Update(ds.Tables["authors"]);

  53:             sqlda8.Update(ds.Tables["titleauthor"]);

  54:  

  55:             Console.WriteLine("データをコピーしました。");

  56:         }

  57:     }

  58: }

• アプリケーションの接続文字列を変更し、動作確認を行う。
  現在の Web アプリケーションはファイルアタッチデータベースを利用していますが、SQL Azure データベースを利用するように変更するには、接続文字列を書き換えるだけで済みます。以下のように web.config ファイル内の接続文字列を書き換えて、動作確認を行います。

   1:<configuration>

   2:  

   3:   ... (前略) ...

   4:  

   5:<!-- 変更前 -->

   6:<!--<connectionStrings>

   7:<add name="pubsConnectionString1" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\pubs.mdf;Integrated Security=True;User Instance=True"

   8:         providerName="System.Data.SqlClient" />

   9:</connectionStrings>-->

  10:  

  11:<connectionStrings>

  12:<add name="pubsConnectionString1" connectionString="Server=tcp:mbkz89u87g.database.windows.net;Database=pubs2;User ID=nakama@mbkz89u87g;Password=xxxxxxxx;Trusted_Connection=False;"

  13:         providerName="System.Data.SqlClient" />

  14:</connectionStrings>

  15:  

  16:   ... (後略) ...

  17:  

  18:</configuration>

以上を行ったあとでクラウドサービスプロジェクトを Ctrl + F5 により実行し、Default2.aspx ページを呼び出すと、SQL Azure データベースからデータを読み出して画面に表示するようになります。

以上でデータベースの移行は終了です。続いて、ストレージサービスの移行を行います。

Windows Azure ストレージサービスへの移行

開発用ストレージサービスから、本番環境の Windows Azure ストレージサービスに移行するには、まず Windows Azure ポータルサイト（https://windows.azure.com/）から、ストレージサービスを作成します。

• Windows Azure ストレージサービスを作成する。
  Azure ポータルサイトの “Create a new service” から、”Storage Account” を選択し、サービスを作成します。
  
  サービスのラベルを指定する画面がありますが、ここで指定したラベルはポータルサイト上でのみ利用されるラベルなので、適当に付与して OK です。 
  
  次の画面で指定する “Public Storage Account Name” は、このストレージにアクセスする際の URL になるものなので、わかりやすい名前を付与します。また、ストレージサービスの場所を指定する際には、アフィニティグループを作成しておきます。
  
  ※（参考） アフィニティグループとは、Windows Azure のコンピュートサービスやストレージサービスを作成する際に、同一のアフィニティグループに属するサービスを極力近づけて配置してもらうための機能です。この後、Windows Azure コンピュートサービスを作成する際に利用します。
• Primary Key と Secondary Key のうち、好きな方をメモする。
  以上の作業を行うと、Windows Azure ストレージサービスにアクセスするためのキーが 2 つ発行されます。”Primary Key” と “Secondary Key” と書かれていますが、実際にはこの 2 種類のキーはどちらを使っても同じようにストレージにアクセスできますので、どちらか好きな方のキーをメモしておいてください。
  
  ※ （参考） Primary Key と Secondary Key については、様々な使い分けが考えられます。例えば、① 片方の鍵は Web アプリケーション内に組み込む鍵とし、もう片方の鍵は管理者がツールから使う鍵とする、といった使い分���や、② どちらか一方を普段使いのキーにしておき、もう片方をスペアキーとしておく（もし普段使いのキーが盗まれた場合には、こちらの鍵のみを再生成し、スペアキーの方についてはそのままにしておく）、などの使い方が考えられます。
• ストレージ接続文字列を設定する。
  次に、クラウドサービスプロジェクトのプロパティ画面の “Settings” タブを開き、Diagnostic Monitor の接続先となるストレージを、開発用ストレージ（development storage）から、運用環境の方に変更します。下図のように、”Account Name” と “Account Key” を設定し、さらに接続方法として HTTPS プロトコルを設定してください。
  
  以上の設定ののち、OK ボタン（ウィンドウの端にボタンが微妙に隠れてしまっているのですが．．．．） を押すと、Windows Azure ストレージ接続文字列が作成され、”DiagnosticsConnectionString” という名称で保存されます。以下のような感じの文字列になりますが、この文字列を次に利用しますので、コピーしておいてください。
  ”DefaultEndpointsProtocol=https;AccountName=nakama;AccountKey=…（== という文字で終了する文字列）…”
• Windows Azure ストレージサービス内に、Diagnostic Monitor で利用する Blob コンテナやテーブルを作成する。
  少し前の「Diagnostic Monitor によるアプリケーション監視」の「Windows Azure ストレージ側の事前準備」の項で示したサンプルプログラムを一部修正し、本番環境に Blob コンテナやテーブルを作成します。以下にフルソースコードを示しますが、変更するのはソースコード中の 17 行目～19 行目のみです。ここに、先に作成した接続文字列をペーストしてください。
  コードを修正したらこれを実行すると、本番環境に Diagnostic Monitor 用の Blob コンテナやテーブルなどが作成されます。

   1:using System;

   2:using System.Collections.Generic;

   3:using System.Linq;

   4:using System.Text;

   5:  

   6:// Microsoft.WindowsAzure.ServiceRuntime.dll と Microsoft.WindowsAzure.StorageClient.dll へ参照設定

   7:using Microsoft.WindowsAzure;

   8:using Microsoft.WindowsAzure.StorageClient;

   9:  

  10:namespace ConsoleApplication1

  11: {

  12:class Program

  13:     {

  14:staticvoid Main(string[] args)

  15:         {

  16:// 開発環境の場合（運用環境の場合には適宜コードを修正）

  17://CloudStorageAccount storageAccount = CloudStorageAccount.DevelopmentStorageAccount;

  18:// 運用環境の場合

  19:             CloudStorageAccount storageAccount = CloudStorageAccount.Parse("DefaultEndpointsProtocol=https;AccountName=nakama;AccountKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==");

  20:  

  21:// 作成するコンテナ、テーブル、キューの名称一覧

  22:string[] containerNamesToCreate = newstring[] {

  23:"wad-iis-failedreqlogfiles", "wad-iis-logfiles", "wad-crash-dumps" };

  24:string[] tableNamesToCreate = newstring[] {

  25:"WADLogsTable", "WADDiagnosticInfrastructureLogsTable",

  26:"WADPerformanceCountersTable", "WADWindowsEventLogsTable", "WADDirectoriesTable" };

  27:string[] queueNamesToCreate = newstring[] { };

  28:  

  29:// コンテナ、テーブル、キューを作成

  30:             CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

  31:foreach (string containerName in containerNamesToCreate)

  32:             {

  33:                 CloudBlobContainer blobContainer = blobClient.GetContainerReference(containerName);

  34:bool created = blobContainer.CreateIfNotExist();

  35:if (created) Console.WriteLine("{0} : コンテナを作成しました。", containerName);

  36:             }

  37:             CloudTableClient tableClient = storageAccount.CreateCloudTableClient();

  38:foreach (string tableName in tableNamesToCreate)

  39:             {

  40:bool result = tableClient.CreateTableIfNotExist(tableName);

  41:if (result) Console.WriteLine("{0} : テーブルを作成しました。", tableName);

  42:             }

  43:             CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();

  44:foreach (string queueName in queueNamesToCreate)

  45:             {

  46:                 CloudQueue queue = queueClient.GetQueueReference(queueName);

  47:bool result = queue.CreateIfNotExist();

  48:if (result) Console.WriteLine("{0} : キューを初期化しました。", queueName);

  49:             }

  50:         }

  51:     }

  52: }

以上の作業で、利用するストレージが開発用ストレージから運用環境の Windows Azure ストレージサービスへと変更されます。クラウドサービスプロジェクトを Ctrl + F5 キーで実行し、動作確認をしてみてください。先ほどと特に見た目は変わりませんが、内部の動作は以下のように変更されることになります。

各種のログファイルが正しく Windows Azure ストレージサービスにデータ出力できているか否かを確認するには、各種の 3rd party 製ツール（例えば Cerebrata 社の Cloud Storage Studio など）を使ってもよいですが、マイクロソフトのサンプルアプリケーションである myAzureStorage （http://myazurestorage.cloudapp.net/）を使っていただくのもよいと思います。このツールは Blob や Table ストレージの中をブラウジングすることができる Web アプリケーションになっており、簡単に Windows Azure ストレージサービスの中を確認することができます。

※（参考） このツールは Microsoft が提供する非常に手軽なツールなのですが、開発用ストレージの中を見ることができない、データのダウンロードやアップロードができないなど、実際に利用するには機能不足というのが正直なところです；。取り急ぎでざっくりデータを確認したい、という場合に利用すると便利でしょう。

では最後に、いよいよ Web アプリケーションを Windows Azure コンピュートサービス上へと移行しましょう。

Windows Azure コンピュートサービスへの移行

Windows Azure コンピュートサービスを利用する場合には、ストレージサービスと同様に、まずポータルサイト（https://windows.azure.com/）からコンピュートサービスを作成する必要があります。以下の手順でサービスを作成してください。

• 新しいサービスとして、”Hosted Service” を追加する。
  まず、ポータルサイトから “Create a new service” を選択し、Hosted Service を選択します。
  
  次に、サービスのラベルや説明を設定します。（このラベルはポータルサイトでの管理用途にのみ使われますので、適当に付与してかまいません。）
  
  次に、サービスの URL を決定するとともに、サービスを配置するデータセンタを選択します。このとき、ストレージサービス作成時に作成したアフィニティグループ名を指定します。これにより、ストレージサービスとコンピュートサービスが、同一データセンタ内でも極力近い場所に配置されるように努力されます（※ 何かを保障してくれるわけではなく、「極力近づけるように努力する」という努力目標です；）。
  

以上の作業により、コンピュートサービスが作成されます。サービスを作成すると、アプリケーションをアップロードするための 2 つの環境が用意されます。ひとつは “Production” 環境（運用環境）、もうひとつが “Staging” 環境（最終動作確認環境）です。

基本的に、Windows Azure コンピュートサービスにアプリケーションを展開する場合には、まず Staging 環境にアプリケーションを配置して最終動作確認を行ったのち、これを Production 環境と置換します。まずは Staging 環境へのアプリケーションのアップロード方法について、以下に解説します。

• Visual Studio のクラウドサービスプロジェクト上で、インスタンス数を 1 に変更する。
  まず、サーバへのアップロードを行う前に、いったん仮想マシンのインスタンス数を 1 に変更します。後で解説しますが、Windows Azure コンピュートサービスでは、利用した仮想マシンの台数分だけ課金が発生すます。このため、まず最初の段階ではインスタンス数を 1 としておいて配置を行い、動作確認が取れてからインスタンス数を増やすのが鉄則になります。
  
• 「発行」処理を行い、クラウドサービスプロジェクトをパッケージングする。
  次に、クラウドサービスプロジェクトを右クリックして発行処理（Publish）を行います。これにより、Visual Studio から以下の 2 つのファイルが出力されます。
  ① サービスパッケージファイル（CloudService1.cspkg）
  実際の Web アプリケーションが含まれているパッケージファイル
  ② サービス構成設定ファイル（ServiceConfiguration.cscfg）
  配置後も変更可能な構成設定データが記述されたテキストファイル（XML ファイル）
  
  
• Windows Azure ポータルサイトからこの 2 つのファイルをアップロードする。
  これらの 2 つのファイルを、ポータルサイトからアップロード（配置、Deploy）します。（配置の際には、パッケージファイルをいったん Blob ストレージにアップロードしてから展開する方法も用意されていますが、ここではファイルが小さいため、直接 Web ブラウザからアップロードすることにします。）
  
  Deploy 時には、ラベルを付与することができるようになっていますが、通常、このラベルにはアプリケーションのバージョン番号（ビルド番号など）を付与しておきます。（※ 一般的なバージョン番号付与ルールについては、各種の書籍を参照してください。ここでは、「バージョン 1.0 のアプリケーションの、2010 年 3 月 1 日の最初のビルド」という意味で、“1.0.00301.0”（＝”1.0” + ”2010/03/01” + ”0”） という番号を付与しています。）
  以上により、以下の作業が行われます。
  ① Windows Azure コンピュートサービスのハードウェアインフラ上に、仮想マシンのイメージ（この例の場合には Web ロールサーバの VM イメージ）がコピーされる。
  ② この仮想マシンに対して、指定した VM Size のリソース（この場合には Small なので 1 個の CPU と1.75GB のメモリ）が割り当てられる。
  ③ ここに、アップロードしたアプリケーションパッケージが展開され、インストールされる。
  
• コンピュートサービスの仮想マシンの電源を入れる。
  配置が完了すると、下図のような “Stopped” 状態の仮想マシンが出来上がります。この状態は、仮想マシンの電源が落ちている状態ですので、”Run” ボタンを押下して、仮想マシンを起動します。
  
  ※ （注意＆参考） 画面上に赤字で書かれているのは課金に関する警告メッセージです。 詳細は後述しますが、Windows Azure コンピュートサービスでは、マシンが Stopped 状態でも（さらには Staging 環境であっても）課金が発生します。これは、Stopped 状態であったとしても、仮想マシンはリソース割り当て（CPU やメモリのリソース割り当て）を受けているためです。もし課金を完全に止めたいのであれば、”Delete” ボタンを押下して、仮想マシンを完全に削除してください。うっかり Staging 環境などに仮想マシンを置き去りにしておくと、Stopped 状態であったとしても課金を食らいますので、十分に注意してください。
• コンピュートサービスの動作を確認する。
  しばらくするとコンピュートサービスが起動します。Staging 環境では、配置されたアプリケーションにダミーの URL が付与されますので、画面上に書かれている URL にアクセスして、Web アプリケーションの動作を確認してください。
  
   
  

以上で Windows Azure コンピュートサービス環境への Web アプリケーションの配置と基本的な動作確認は終了しました……が、残念ながらこのままではいくつかの問題があります。

• 現在時刻の表示がおかしい。
  このアプリケーションを実際に動作させているのは “2010/03/01 PM11:21:49” なのですが、画面表示上は “3/1/2010 2:21:49 PM” と、9 時間のズレがあります。これは、Windows Azure コンピュートサービスのコンピュータが UTC 時刻（グリニッジ標準時）で動作しているためです。UTC は東京と 9 時間の時差があるため、時刻表示がずれてしまうことになります。
• GridView コントロールの “選択” ボタンが、”Select“ と英語表記になっている。
  これは、Windows Azure コンピュートサービスのサーバ OS が、データカルチャ、UI カルチャともに “en-us” （英語）で動作しているためです。このため、例えば int a=30; というデータを通貨表記すると、￥30 とはならずに、$30 となってしまいますし、上に記述するように、”選択” ボタンの表記も英語表記になってしまいます。

このように、Windows Azure コンピュートサービスの本番環境は、ローカルコンピュータの開発用ファブリックとは、いくつか環境的に異なるところがあります。このため、実際に既存のアプリケーションを Azure 上に移植する場合、あるいは新規に Azure 用のアプリケーションを開発する場合には、このような環境の違い（特に国際化対応の問題）を意識する必要があります。

では、実際にアプリケーションを修正して、Windows Azure コンピュートサービスの環境に適応させてみることにします。（その 4に続く…）

※ 本エントリは その 3の続きです。（エントリが長すぎて投稿できなかったため分割しています）

［アプリケーションの修正と Azure 環境への再配置（アップグレード）］

さて、開発用ファブリックと Azure 本番環境では様々な相違点があります。Azure 本番環境で問題となりやすい制限事項としては、以下のようなものがあります。

この中でも、国際化対応に関連する問題はよくひっかかりやすいポイントになります。例えば、以下のような簡単な処理でも、Windows Azure 環境では、開発環境とは異なる動きをすることになります。

これらについては、基本的に以下の対策を行うとよいでしょう。

• web.config ファイルに、データカルチャと UI カルチャを変更するための設定を追加する。
• アプリケーションの中の時刻処理を、タイムゾーンを意識したコードに変更する。

   1:<configuration>

   2:<system.web>

   3:<globalization culture="ja-jp" uiCulture="ja-jp" />

   4:</system.web>

   5:</configuration>

   1:// 従来であれば以下のように実装していたところを...

   2:// DateTime now = DateTime.Now;

   3:// 以下のように実装する

   4: DateTime now = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.Now.ToUniversalTime(), "Tokyo Standard Time");

では実際に、これらの修正を加えて Web アプリケーションを再配置してみましょう。

• パッケージファイルを作り直す。
  上記の修正を Web アプリケーションに加えたのち、再度、クラウドサービスプロジェクトを発行してください。
• ポータルサイトから Staging 環境のアプリケーションを “Upgrade” する。
  ポータルサイト上から “Upgrade” を選択し、作成したパッケージファイルなどをアップロードします。
  
  アップグレードの際には、”Automatic Upgrade” と、”Yes, I want to …” を選択し、ラベルとして新しいアプリケーションのバージョン番号（ここでは 1.0.00301.1）を指定してください。 
  
  ※ （参考） アップグレード時には、自動アップグレードと手動アップグレードの 2 つの方法が選択できます。これは、サービスに含まれる各ロール（Web ロールや Worker ロール）を自動的にすべてアップグレードするか、手動でひとつずつアップグレードしていくかを選択するものです。ステージング環境などのアプリケーションをアップグレードする場合には、通常はまとめて自動アップグレードすれば十分でしょう。
  ※ （参考） アップグレードは、サービスの構成（＝サービスに含まれるロールの種類やエンドポイントの構成など）が同一でないと行うことができません。サービスの構成が変更された場合には、いったん配置（Deployment）を削除した上で、再度新しく Deploy 作業を行ってください。

以上の作業を行った上で、再度アプリケーションの動作確認をすると、以下のようになるはずです。

• 日時の表示については、正しい表示に変更される。（東京の日時が表示される）
• しかし、GridView の選択ボタンについては、依然として “Select” 表示のままである。

前者については問題ないと思いますが、後者については疑問を覚える方もいると思いますので、少し補足しておきます。一般に、GridView の選択ボタンの表記文字や、例外に含まれる詳細メッセージなどには、.NET Framework ランタイムの中に含まれる、日本語リソースファイルが使われています。しかし、現在の Windows Azure コンピュートサービスの環境には日本語のリソースファイルが含まれていません。<globalization> タグで uiCulture を “ja-jp” にしておくと、本来は日本語リソースファイルが利用されるようになるのですが、そもそもこのリソースファイルが Azure 上にインストールされていないため、英語メッセージになってしまう、ということになります。

このため、今回の GridView の選択ボタンのようなものを日本語表記にしたい場合には、以下のように対応する必要があります。（要するに、手作業で「選択」という文字が書かれたボタンを作る。）

• テンプレート列を作成し、LinkButton コントロールを配置する。
• 手作業でこれに “選択” という文字を設定し、CommandName プロパティに “Select” を指定する。

ちょっと面倒な作業になりますが、現在の Azure プラットフォームの制約として知っておいていただければと思います。

さて、ここまでの修正や動作確認が済んだら、次にインスタンス数を増やしてみましょう。ポータルサイトから ”Configure” ボタンを押し、構成設定ファイルを表示します。（この構成設定ファイルは、アプリケーション配置時にクライアントからアップロードした ServiceConfiguration.cscfg ファイルです）

このファイルの中ほどに、<Instances count=”1” /> という設定がありますので、これを適宜増やします。（ここでは 3 にしてみることにします。） 修正後、”Save” ボタンを押していただくと、インスタンス数が増加することになります。（※ インスタンス数増加には多少時間がかかりますので、しばらく待ってください。）

この状態で動作確認してみると、インスタンス ID が時折切り替わったりすることが確認できると思います。

最後にいよいよこのアプリケーションを本番環境（”Production”）へと展開しましょう。このためには、ポータルサイトのスワップ機能（入れ替え機能）を利用します。

この画面の真ん中のボタンを押すと、二つの環境が入れ替わるようになっています。これにより、運用環境にアプリケーションを配置し、通常の URL アドレスでアクセスすることができるようになります。

※ （参考） Windows Azure では、アプリケーションに対して http://○○○.cloudapp.net/ という形式の URL が付与される形になりますが、独自のドメイン名を付与したい場合には、DNS サーバの機能の一つである CNAME エントリ機能を使うとよいと思います。詳細は各種の Web サイトを参照してください。

※ （参考） なお、この入れ替え作業は、実態としては「フロントにあるロードバランサのリクエスト転送先を切り替える」というものです。このため、時間もさしてかかりませんし、また Production 環境にアプリケーションがアップロードされている場合でも利用することができます。

以上で、基本的な Azure の使い方はおしまいですが、最後に、Windows Azure の課金を安く抑えるためのコツについても解説しておきましょう。

［Windows Azure 運用環境を安く使うためのコツ］

まず、Windows Azure プラットフォームでは、基本的に、「サービス」と「トラフィック」が課金対象になります。

Azure の課金の詳細については、Windows Azure のサイトに詳しくまとめられていますが、なかなかとっつきにくいのも確かだと思います。そこでここでは、課金に関するポイントを解説します。

※ （重要） ここに書かれている情報は、エントリ執筆時点での情報をまとめたものであり、またあくまで参考情報です。誤りがないように調べて書いてはいますが、万が一間違いがあった場合でも責任が持てません。必ずオフィシャルサイトの最新情報を調べるようにしてください。

トラフィック課金について

• 同一拠点（≠ 同一地区）の Azure データセンタ内の通信に関しては課金対象とはなりません。
  つまり、同一データセンタ内に配置された、Web ロールと Worker ロールのサーバ間の TCP/IP 通信などは課金対象とはなりません。
• トラフィック課金の単価は、データセンタの場所によって決まります。
  クライアントユーザがどこにいるかではなく、サービスがどのデータセンタに配置されているのかによって課金が決まります。（ちなみにアジアはトラフィック課金の単価が多少高めです。）
• トラフィック課金は比較的膨らみがちなので、予めよく設計するようにしてください。
  単価だけ見ると小額なのですが、実際の Web サイトではそれなりの金額になります。例えば、約 500kB の Web ページが 5,000 回／日のペースで呼び出されたとしても、500kB x 5,000 回 x 30 日 = 75GB の転送量になり、決して無視できないデータ転送量になりますので、注意してください。

ちなみに現在は、夜間時間帯割引などもありますので、うまく活用するとよいでしょう。

Windows Azure コンピュートサービスについて

• マシン占有課金＝単価 × VM サイズ × デプロイ時間 × インスタンス数 です。
  「CPU の利用時間」ではなく、「サーバリソースの占有量と時間」により課金が決まるところがポイントです。つまり、下図のように “Stopped” 状態の仮想マシンについても課金が行われます。
   
  実際の利用時には、“Stopped” 状態でサーバを放置しない（必ず “Delete” し、空っぽの状態にする）ようにしてください。
• “Production” 環境と “Staging” 環境に課金上の違いはありません。
  仕組みを考えてみれば明らかだと思いますが、Staging 環境といっても、ここにアップロードしたアプリケーションはしっかりと Windows Azure インフラの CPU やメモリリソースを占有しています。このため、”Staging” 環境に置いたアプリケーションについても、課金が行われます。
  通常、Staging 環境は、Production 環境のアプリケーションをアップグレードする前の最終動作確認環境として利用されますが、利用が済んだらこれも必ず “Delete” するようにしてください。
• 課金時間は、「デプロイ～削除」までを 1 時間単位で繰り上げする形で計算されます。
  つまり、1 分しか配置していなかったとしても、1 時間分の課金が行われる、ということになります。よって、以下のような操作は避けてください。
  例1. 新規アプリケーションパッケージをデプロイしたあと、1 分後に削除する。
  例2. 最初から大量のインスタンス数（例 : 30 インスタンス）でデプロイする。（→ 万が一デプロイに失敗した場合には削除してやり直すことになりますが、この場合、30 時間分の請求が発生します）

以上のことをきちんと押さえておくと、Production 環境のアプリケーションをアップグレードする正しい方法が分かってきます。具体的にまとめると、以下のような手順になります。

• まず Staging 環境に、インスタンス数 = 1 で新規デプロイする。
• 動作確認し、問題なければ、Staging 環境でインスタンス数を増やす。
• Production と Staging を入れ替える。
• しばらく様子を見る。（※ 問題があった場合にはロールバックするため）
• 問題がなければ、Staging 環境を削除（Delete）し、インスタンスを消す。

うっかり放置すると、Small インスタンス 1 つであっても、1 か月あたり 8,000 円程度の課金を食らいます。決して安い金額ではないので、十分注意しながら利用してください。

Windows Azure ストレージサービスについて

• トラフィック課金に特に注意してください。
  Windows Azure ストレージサービスでは、「ストレージ利用量」「トランザクション数」「トラフィック量」の 3 つにより課金が決まります。執筆時点の場合、ストレージ利用課金は $0.15/GB・月、トランザクション課金は 10,000 トランザクションあたり $0.01、トラフィック課金は北アメリカで $0.15/GB。これらの数字から考えると、ストレージサービスの課金の大半はトラフィック課金になるはずです。特に、マルチメディアファイルなどの巨大な BLOB データをストレージに置いて配信するような場合には十分な注意が必要です。

SQL Azure データベースサービスについて

• サービスの課金は、データベースの数とエディションにより決まります。
  例えば下図の例の場合には、Business Edition のデータベースが 1 つ、Web Edition のデータベースが 1 つで、それぞれに対して課金が発生します。SQL Azure の場合、容量制限があるためにデータベースの数を増やしたくなるわけですが、むやみに増やせばそれ相応に課金額も増えていく、ということに注意してください。
  
• オンプレミス SQL Server などとの連携を行う場合は、トラフィック課金に気を付けてください。
  特にデータベースのデータの一括転送などは、どうしても容量がかさみがちになります。トラフィック課金がかなりの額になることも想定されますので、十分注意してください。

なお、上記のいずれに関しても、課金状況は MOCP サイト（Microsoft Online Services Customer Portal サイト）から確認できますが、課金情報はリアルタイムではなく遅れがありますので注意してください。

さて、ここまで課金の仕組みなどについてざっと解説してきましたが、実際にご自身のアプリケーションの場合にどの程度の課金となるのか？ に関しては……これは正直なところ、case-by-case としか言いようがありません。よく、「一般的な Web アプリケーションだといくらぐらいの金額になるの？」と聞かれるのですが、世の中に存在する Web アプリケーションの中身は千差万別で、必要なサーバ台数も、データ転送量も、本当にまちまちというのが実態です。

もし実際に Azure プラットフォームを使う前に、課金がどの程度になるのかを知りたければ、既存の類似アプリケーションについて、以下のようなポイントを考えてみたり調べてみたりするとよいでしょう。

• ネットワークトラフィックはどの程度あるのか？（これは IIS ログから調べられます）
• 現在の Web サーバのマシンスペックと台数はどの程度か？（Azure プラットフォームでは Small インスタンスの CPU が 1.6GHz 相当なので、これからざっくりとした計算はできます）
• 必要となる SQL Azure データベースの容量はどの程度か？

サーバ台数の見積��りなどは、原理的に机上での評価が難しい領域になります。そういう観点からも、プロトタイピングなどを通して実機検証を行い、見積もり精度を高めていくことをお奨めします。

［まとめ］

というわけで、ここまで Windows Azure プラットフォーム上でのアプリケーション開発を Step-by-Step 形式で見てきましたが、キーポイントをまとめると以下の通りとなります。

• Windows Azure のアプリケーションを配置するためには、クラウドサービスプロジェクトを利用する。
• クラウドサービスプロジェクトでは、主に 2 つのことができる。
  ① 開発用ファブリックを利用した、ローカル PC での Azure 環境のシミュレート
  ② 運用環境にアップロードするためのパッケージファイルの作成
• 開発環境から運用環境へと移行する際には、以下のように移行を行う。
  ① SQL Server データベース → SQL Azure データベースサービス
  ② 開発用ストレージ → Windows Azure ストレージサービス
  ③ 開発用ファブリック → Windows Azure コンピュートサービス
• サーバの動作情報を収集する場合には、Diagnostic Monitor ランタイムを使う。
• 運用環境を管理する際には、Windows Azure ポータルサイトを利用する。
• 運用環境を利用する際には、課金に注意する。
  特に、”Stopped” 状態（サスペンド状態）になっていても、課金が発生することに注意して利用する。

Windows Azure プラットフォームのメリットは、なんといっても ASP.NET Web アプリケーションの開発スキルがあれば、ほとんど追加の学習の必要なく、クラウドコンピューティング（PaaS）の恩恵を受けることができる、という点です。今回のエントリでは紹介しませんでしたが、Worker ロールサーバも利用方法はさして難しくなく、応用次第で多彩な使い方ができるのが Windows Azure プラットフォームのよいところです。今後、Windows Azure をはじめとするクラウドコンピューティング関係のスキルは決して無視できなくなってくると思いますので、.NET の開発をされている方は、ぜひ Windows Azure プラットフォームも触ってみてください。決して損はしないと思います。

※ 2011/10/31 追記：バージョンアップ版を公開しました。こちらのエントリもご参照ください。

というわけで皆様、大変ご無沙汰しております；。1 月に Windows Azure のエントリを書いて以来���Azure 案件で忙しい日々が続いており、とても blog どころではなかった．．．．というのが正直なところ；。現在はホントに Azure 一色な日々を送っているのですが、おかげさまでついに！ というかようやく！ Windows Azure の実装ガイドラインとなるコンテンツを公開することができました！（嬉）

• Visual Studio Workshop #451 Windows Azure 上での Web アプリケーション開発基礎
• こちらのリンクから辿ってダウンロードしてください。 

TechEd Keynote セッションなどでちらっとご紹介して以来、本当に長らくお待たせしてしまったのですが、マイクロソフト社内の様々な関係者のご協力でついに公開することができました！ この場を借りてお礼申し上げます。本当にありがとうございました。

こちらのスライドは、ppt ベースで 324 ページから構成されるもので、現時点での Azure 開発用マテリアルとしては、おそらく全世界レベルで見ても最も情報がまとまっているコンテンツではないかと思います。このマテリアルですべての開発の疑問が解決するわけではないと思いますが、たいていの質問には答えられると思います。

なお、こちらのマテリアルの利用にあたっては、以下の点にご注意いただければと思います。

• このマテリアルは、あくまで現場の開発者の皆様の、セルフトレーニング（勉強）用にご提供するものです。複製、転載、商用利用はご遠慮下さるよう、お願いいたします。（例：この内容を社内で製本して配布するとか、このマテリアルを使って社内向けトレーニングを実施するとか、設計書や社内資料、お客様向け資料に引用したりコピペするとかしてはいけません。）
• 内容については、私が独自に調査しているものを多分に含んでおります。技術情報に関しては誤りがないように全力で調査をしていますが、万が一、間違いがあった場合には、こちらの blog などで報告をしていきたいと思います。
• Azure のアップデートなどによりこちらの情報が古くなる可能性もありますが、現時点ではマテリアルの更新について行う予定はありません。申し訳ありませんが、差分情報については各自で調査をお願いできればと思います。（基本はこれからもそんなに変わらないと思いますが。）

Windows Azure 開発に携わっているすべての方のお役にたてるマテリアルだと思いますので、ぜひこのコンテンツを学習して、Azure 開発を進めていただければと思います。（というかこれだけの情報を公開している PaaS サービスは他にはないんじゃないかと思う……^^）

と、これだけでは何ですので、ここでは少し裏話を……

［このマテリアルはいったい何か？］

今回、公開したこの ppt マテリアルは、MCS（マイクロソフトコンサルティングサービス）が企業向けに提供している有償 Workshop である、Visual Studio Workshop コースのひとつ（#451 コース）を、ほぼそのままの形で社外に公開したものになります。この Visual Studio Workshop は、マイクロソフトコンサルティングサービスの開発系コンサルタントの社内トレーニングにも利用されており、実際のコンサルティング案件のベースラインになるとともに、実案件で出たノウハウを吸収してコンテンツがどんどん強化されていく、という仕組みになっています。文字通り、コンサルティングサービスの中枢の開発ノウハウがそのまま凝縮されたものになっています。

ちなみに、今まで赤間が執筆してきたすべての書籍（開発技術大全シリーズや Web アプリケーション構築技法など）は、すべてこの Visual Studio Workshop をベースとして執筆されており、いわば赤間が出版してきた書籍のオリジナル版とも言えるものです。

［なぜ今回、このマテリアルを公開したのか？］

この MCS の Workshop シリーズは、コンサルティングサービスのノウハウの集大成ともいえるもので、過去、このような形でダウンロード提供するものではありませんでした。しかし、昨今のクラウドの大きな盛り上がりもあり、お客様からは Windows Azure に関する技術情報提供を求められることが多くなってきました。

これはマイクロソフトの見解というわけではなく、あくまで私自身の考えなのですが、もともと私は SIer 出身ということもあり、本来、SI に関わるノウハウ的な部分（見積もり手法や設計手法、あるいはテクノロジの活用方法の検討など）に関しては、SIer が開発するべきものである（＝もしそれをマイクロソフトが提供するのであれば有償サービスであるべきである）、という考え方を持っています。しかし、プラットフォームベンダーであるマイクロソフトから適切な技術情報が提供されなければ、そうした設計手法や見積もり手法を作ることはできません。そういう観点から見ると、現在の Windows Azure 上での開発に関する情報は、一通りの情報が Web 上に出ているとはいえ、

• 情報が様々な場所に散在してしまっており、調べるのに時間がかかる。
• 多くの情報リソースがまだ英語であるため、日本人だと読むのがつらい。
• 自力でいじったり調べてみたりすればわかる部分は多いが、その手間がかなりかかる。

といった問題がある、と感じていました。また、実はこれに並行して、いくつかの出版社さんから書籍執筆の話を持ちかけられていたのですが、現実的に私の執筆時間が現在全く取れないこと、またなにより、出版までそれ相応のリードタイムがかかってしまうという問題がありました。

Azure に先行して取り組んでいただけているお客様の「現在の pain」を今すぐ取り除くには、MCS Workshop の Azure 実装編コースの ppt マテリアルを直接公開することが最もストレートな解決方法である、ということから、社内 Azure V-Team による検討作業が行われ、様々な部門からのご協力のもと、今回の企画が実現しました。

［MCS Workshop や Azure コンサルティングサービスの全貌について］

今回公開した Power Point 資料は全部で 324 ページに及ぶ膨大な資料になっているのですが、MCS Workshop や Azure 関連コンサルティングサービスの全体像、という観点からすると実は氷山の一角にすぎません。例えば、Azure 関係の Workshop やコンサルティングサービスとしては、以下のようなものがあります。（メインとなっているのは #821 アセスメント編、#811 設計編、#451 実装編の 3 つです。）

※ ちなみに #301, #341, #411（の一部）, #431 あたりが VS2005 以降の書籍のオリジナル版にあたるものです。

先に申しあげたとおり、これらの多くはコンサルティングサービスによる有償サービスになります。コンサルティングサービスに依頼する上で、やはりクォリティが心配になる部分も多いかと思いますが、今回、こうした形で Workshop マテリアルのひとつを全面的に公開できましたので、ひとつの参考にしていただくことはできるかと思います。上記にあるように、設計ノウハウやアセスメントなどに関しては有償のサービスメニューとしてご用意しておりますので、以下のような方は、弊社の担当営業までお声掛けいただければと思います。

• 社内システムへのクラウド技術の適用・活用を検討したいと考えている。
• 社内システムを Azure 化したいが、費用対効果が全く読めずに困っている。
• Azure に関する設計・実装ノウハウを入手したい。
• 社内のエンジニアに対して、Azure の設計・実装技術のトレーニングを実施したい。
• 既存システムの Azure 化を行う予定だが、設計・実装に自信がなく、有識者にレビュー・支援して欲しい。

［Consulting Express for Azure について］

なお、特に SIer や ISV などシステム開発に関わる企業様は、上記の Workshop マテリアルを含んだパッケージ商品（技術移転プログラム）である、Consulting Express for Azureのご利用をぜひご検討ください。今回、ダウンロード提供させていただくものは、#451 の実装編のみであり、しかも個人の学習用途に絞られていますが、Consulting Express であれば、アセスメントや設計編までパックになっており、さらに（ある程度条件は限定されますが）SI ビジネスなどで活用していただけるような社内利用権も付与されます。通常のカスタムのコンサルティングサービスよりも安価に Azure のノウハウを一気に入手できますので、ぜひご検討ください。

［最後に…］

最後に、ちょっと愚痴まじりですが、私のつぶやきを聞いてください；。

最近、Azure 関連で様々なお客様（主にシステム開発系の企業様）とお会いしているのですが、どこのお客様でも共通的に感じることが、とにかくみんな忙しい、ということ。昨今の恐ろしいまでのコスト削減圧力により、現場にはかつてない重圧がのしかかっているわけですが、そうしたしわ寄せは、まず最初に「技術調査や勉強時間の削減」というところに現れます。しかしこれはその場の付け焼刃であって、長期的にそれを繰り返せば、SIer や ISV、個人としての実力低下、ひいては衰退に繋がっていくものです。こうした状況に陥らないようにするためには、やはり私は、どんなに忙しくても、勉強することが欠かせないのだと思います。

昨今の不況、そしてグローバル化の波を乗り越えていくためには、みんなで頑張らないとダメなのだと思います。我々ベンダーも、SIerも、ISVも、お客様も。そのために最低限必要になるであろう Azure に関する情報を、今回ご提供させていただいたつもりです。300ページ超えのマテリアルともなると簡単に読み切れるものではないと思いますが、それでも普通に学習するよりは圧倒的にラクになるはずだと思います。10ページずつでもいいので毎日読み進めていき、ぜひ、この情報を Azure の開発現場で生かしてください。どうぞ、よろしくお願いいたします。

さて、先週 Azure の実装ガイドラインを Web で公開したわけですが、おかげさまでかなりのブックマークをいただいたり、資料のダウンロードをしていただけた様子。しかし、そもそも Azure を全く触ったことがない、という方には、あちらの資料ではややハードルが高いのも実際のところ。また、Azure に関しては情報が散逸しているので、「どこから手をつけていいのかわからない」という方も多いと思います。一昨日に、MCS の若手メンバの一人である増田さんが書いてくださった、初学者向けのAzure アプリ開発の Step-by-Step ガイドも公開されましたので、今回は、「今から Azure を勉強したい、触り始めたい」と思っているエンジニアの方々向けに、（激しく手前味噌ですが）学習用のロードマップ情報をお伝えしようと思います。これらを使えば、最短距離で Azure をかなりハイレベルに利用できるようになると思います。こちらのページをぜひ、Azure をこれから学習したい！という方にお勧めしてください。

［Azure を全く知らない方向け］

• マイクロソフトのクラウドコンピューティング “S+S” 概要
  マイクロソフトのクラウドコンピューティングの全体像を 15 分でさらっと理解するためのコンテンツ。マイクロソフトのクラウドコンピューティング戦略の全体像や、マイクロソフトのクラウドサービスのブランディング（BPOS, Live, Azure）の位置づけなどを理解することができます。まずはここから。
• Windows Azure Platform 概要
  Windows Azure の主要な構成要素がどのようなものかを、「超ざっくりと」説明した資料。コンピュートサービス、SQL Azure、ストレージサービスの 3 つをざっくりと説明しています。
• 既存業務システムの Windows Azure への移行
  既存業務システムを Windows Azure へ移行する際に、「どんなシステムがクラウド（Azure）に向いているのか？」「移行する場合に、特にどのへんに考え方のギャップが生じるのか？」を説明したもの。TechEd 2010 のセッション（70 分）です。（同じ場所で他にも良いコンテンツが公開されているのでそちらもどうぞ。）

［Azure を全く触ったことがない方向け］

• Windows Azure 用アプリケーション開発 Step-by-Step チュートリアルガイド
  Windows Azure 上でのアプリケーション開発を、完全な Step-by-Step でひととおり学習できるもの。
  すべて評価版を使う形で書かれているので、Visual Studio のライセンスをお持ちでない方でも取り組むことが可能です。
• 無償 Windows Azure Platform セミナー＆ハンズオントレーニング
  実機を使った演習を手っ取り早くやってみたい、という方向け。マイクロソフトの新宿本社ビルで毎週開催しています。半日程度でさくっと触れるのでこれもお奨め。
• Visual Studio 2005 による Web アプリケーション構築技法
  マイクロソフトの Web 開発技術を全く知らない、という方は、Azure の理解と並行して、マイクロソフトの開発技術を理解することも必要です。その場合には、こちらの書籍を 1 冊読んでいただくのがお奨め。オンプレ向けの本ですが、Azure でもほぼそのまま利用することができます。（違うのはせいぜいデータベースが SQL Azure になることぐらいです。）

［Azure や .NET をそこそこ触った・使ったことがある方向け］

• Windows Azure 実装ガイドライン（MCS Workshop #451 Windows Azure 上での Web アプリケーション開発基礎）
  マイクロソフトコンサルティングサービスが、開発者向け有償サービスとして実施している、Visual Studio Workshop のテキストを、個人学習用途として使えるようにダウンロード可能にしたもの。かなり詳しく書かれているため、読むのは大変ですが、これ一冊読めばだいたいのことはわかります。あれこれ複数の資料を読むよりも、まずこれを読んでしまった方が結果的にはたぶんラクです。また、Azure の購入の仕組みがよく分からないという方は、まずこちらの資料の Module 5 を見てください。
• Windows Azure Platform トレーニングキット
  Windows Azure の個々の技術要素に関して、深掘りした学習をしたい方向けのコンテンツ。例えば、「AppFabric サービスバスの使い方についてもうちょっと詳しく学習したい」という方向けに便利です。

ちなみに、もっと簡単なところから……という場合には、MSDN スキルアップセンターなどが役に立ちます。また、ここまで学習が終わった後は、砂金さんの blogやホワイトペーパー、さらには各種イベントのセッション情報などで、最新情報を追いかけたり、さらに知識を深掘りしていくのがよいと思います。まだ Azure を知らない、触ったことがないという方は、ぜひこれらの資料で学習を進めてみてください。

東北地方太平洋沖地震、時間が経つにつれて目を覆うばかりの甚大な被害が明らかになりつつあります。被災地の皆様には本当にお悔み申し上げると共に、亡くなられた方々のご冥福と、皆様のご無事と安全を本当にお祈りしております。社内でも何か手伝えることはないかという動きが出ておりますが、このエントリでは Azure 関連の各種の動きをまとめて随時お伝えしようと思います。

• ミラーサイト構築支援（New! 2011/03/18）
  今回の地震に関連して、一部の Web サイトが高負荷でダウンする、という状況が発生しています。この問題を解決するため、Azure 上にミラーサイトを構築する（技術的には Azure 上にリバースプロキシキャッシュを構築する）支援をマイクロソフト側で始めています。お手を煩わせないようにするため、info311a@microsoft.com (電子メール)までメールで連絡をいただければ、構築そのものをマイクロソフト側で実施します。（← この件は私や MCS のコンサルタントも技術協力・構築協力しています。） 構築作業費用はもちろんかかりませんので、まずはとにかくご連絡を。福島県などの Web サイトがすでにこれを利用しています。概念的には下図のようなキャッシュサーバを構築する支援です。
  
• Windows Azure Platform 無料パス
  クレジットカードの登録なしに、90 日間分の Azure （S インスタンス× 3、1GB SQL Azure Web Edition × 2）が利用できるというものです。様々なサイト立ち上げにご利用ください。アクティベーション作業も早急に行われているようです。
  http://go.microsoft.com/?linkid=9766038
• オープンソースソフトウェアの Azure 上へのインストール方法のまとめ
  上記で立ち上げたサイトへオープンソースソフトウェア（WordPress, Movable Type, PukiWiki など）をインストールする方法をまとめたサイトです。インストールマニアクスに参加された方々により取りまとめられた情報です。（PHP に関しては、こちらが詳しいです。）
  http://maniax.jp/installmaniax/4/report/docs
• Azure Blob ストレージを簡易 Web サイトとして利用する
  静的なファイル群から構成される情報提供サイトであれば、以下の方法によりミラーサイトを簡単に Azure 上に立ち上げることができます。CDN を有効化することにより、大規模なサイトをミラーすることも可能です。
  http://blogs.msdn.com/b/naokis/archive/2011/03/12/azure-blob-web.aspx
• Twitter
  #jazug #azurejp でも様々な情報が交換されていますので、こちらもご参照ください。途中で作業に困った場合などはこれらのタグで Tweet して頂くとよいかと思います。

このページは可能な限り、随時 update していこうと思いますが、もし掲載をご希望される内容がありましたらメールなどでご連絡いただければと思います。よろしくお願いいたします。

※ （追加情報 2011/07/25） SQL Azure データベースの課金に関して、米国本社の担当者も交え、最終的な確認を行いました。結論としては、定義上の最大容量（MAXSIZE）ではなく、実際のデータ容量（Current Size）に基づく課金が行われるという、当初通りの情報が正しい、ということになりました。弊社内の一部の担当者が誤解しており、社内で情報が錯綜したのが誤りの原因でした。謹んでお詫びすると共に、修正した情報を以下に掲載します。なお、本件については SQL Azure の課金に関する FAQ として、近日中に Windows Azure のホームページに掲載される予定です。そちらも併せてご確認ください。

［SQL Azure の課金に関する基本的なポイント］

• SQL Azure の課金は、Web Edition と Business Edition とで分かれている。
• 例えば、Business Edition を含んだコミットメントプランを購入したサブスクリプションで、Web Edition データベースを利用すると、コミットメントプランに含まれないデータベースを使ったものとみなされ、従量課金されてしまう。
• データベースは、実際のデータベースサイズ（Current Size）に基づき、日割りで課金される。
• 料金表は月あたりの金額で書かれているが、課金は日割りで行われる。（日割り計算の詳細なロジックは後述）
• master データベース、temp データベースなどは課金対象外。
• ユーザデータベースのみが課金対象になる。
• データ量は、テーブル内のデータの量だけでなく、インデックスデータの量なども含まれるが、ログデータは含まれない。（簡単に言えば .mdf データファイルの容量であり、.ldf ログファイルの容量は含まれない）

［具体例その1］

上記のようにデータが含まれている場合の課金は、以下のようになります。

［課金の日割り計算に関するキーポイント］

• 従量課金の場合
• その日のピークデータ量（Current Size）に基づいて、日割りで課金される。（データベース定義上のMAXSIZEではない）
• どの月であっても、常に”31”で日割り計算が行われる。（30日以下の月であっても、31で日割り計算が行われる）
• コミットメントプランの場合
• 基本的には、従量課金と同じ方式で計算が行われる。
• しかし、その月の利用量が購入ユニット数よりも少なかった場合には、購入ユニット数まで繰り上げが行われる。
• この繰り上げ計算は「月」単位で行われる。

［具体例その2.］

以下のような場合を考えてみます。（※ 課金サイクルが 1日～翌月 1 日であるとして説明します）

• コミットメントプランを使い、Business Edition 10GBデータベースを（同一サブスクリプション内で）2ユニット購入。
• 最大サイズ30GBのBusiness Editionデータベースを1つ作成する。
  CREATE DATABASE Sample (EDITION=’BUSINESS’, MAXSIZE=30GB)
• 1日～24日は5GBのデータを格納し、25日～30日には25GBのデータを格納した。

この場合の課金は、以下のようになります。

• 利用量は、1 x (24/31) + 3 x (6/31) = 1.35 ユニット。
• 1日～24日は、5GB < 10GB なので、1 ユニット分の日割り課金。
• 25日～31日は、25GB < 30GB なので、3 ユニット分の日割り課金。
• 1.35 < 2.00であるため、月締めのタイミングで繰り上げが行われ、2.00ユニットとして請求が行われる。
• 超課金請求は発生しない。

なお、この例からもわかるように、例えば Business Edition データベースについてコミットメントプランを 5 ユニット分購入しておき、20GB と 30GB のデータベースを作成して利用する、といった形も可能です。（10GB データベースを 5 個作らなければならない、というわけではありません。）

また、データベース内のデータ容量が変化するようなケースでは、適宜、ALTER DATABASE コマンドで MAXSIZE を変更しなくても大丈夫です。例えば、こちらの blogで説明されている以下のようなシナリオの場合でも、特に MAXSIZE を変更しなくても、きちんとその日のピークサイズに合わせて課金が減る仕組みになっています。

ちなみに本件なのですが、本当に社内でえらい目に遭いまして；、会う人会う人みんな言うことがちょっとずつ違う、というひどい状況に��いました；。最終的に上記の情報にたどり着くまでに 2 ヶ月近くもかかってしまう、という事態になり、皆様には本当にご迷惑をおかけしました。やり取りしたメールスレッドが 100 通超えてるってどうよ……状態です；。ホントに；；。

なにはともあれ、一時的とはいえ誤った情報で皆様を混乱させてしまったこと、本当に申し訳ありませんでした。謹んでお詫びすると共に、上記の通り訂正します。オフィシャルな情報としての FAQ への掲載については、現在、弊社製品部が対応中ですので、今しばらくお待ちください。よろしくお願いいたします。

というわけで本当にまた久しぶりなエントリなわけですが；、なぜこれほどまでに忙しいのかはまた今度改めて書くことにしまして、まずはひとつご報告を。社内関連部署の多大なる協力によって、昨年公開した Windows Azure 実装ガイドを、最新情報にリニューアルして公開することができました！（嬉）

• Visual Studio Workshop #451 Windows Azure 上での Web アプリケーション開発基礎
  こちらのリンクから辿ってダウンロードしてください。 

なんとページ数は前回から大幅増量の 600 ページ！（前回が 324 ページなので実に倍増……多すぎます；orz） マイクロソフトのコンサルタント陣が、実際の Windows Azure 案件でお客様から受けたツッコミ内容や、失敗なども含めて得られたノウハウ情報をかたっぱしから盛り込んで加筆修正したものになります。

以前のバージョンでも十二分に世界レベルで戦えたと思うのですが、今回のバージョンは他国のコンテンツの追随を許さない内容になっています^^。しかも内容も最新情報ベースでまとめていますので、VM Role や Traffic Manager などについても詳細に説明してます。ぜひ、現場の皆様でご活用ください！

なお、こちらのマテリアルの利用にあたっては、以下の点にご注意いただければと思います。（お約束^^）

• このマテリアルは、あくまで現場の開発者の皆様の、セルフトレーニング（勉強）用にご提供するものです。複製、転載、商用利用はご遠慮下さるよう、お願いいたします。（例：この内容を社内で製本して配布するとか、このマテリアルを使って社内向けトレーニングを実施するとか、設計書や社内資料、お客様向け資料に引用したりコピペするとかしてはいけません。）
• ◦内容については、私が独自に調査しているものを多分に含んでおります。技術情報に関しては誤りがないように全力で調査をしていますが、万が一、間違いがあった場合には、こちらの blog などで報告をしていきたいと思います。
• Azure のアップデートなどによりこちらの情報が古くなる可能性もありますが、現時点ではマテリアルの更新について行う予定はありません。申し訳ありませんが、差分情報については各自で調査をお願いできればと思います。（基本はこれからもそんなに変わらないと思いますが。）

開発秘話（？）については、以前の blog エントリもぜひお読みになっていただければ嬉しいです。

なお、Windows Azure 関連ではもうひとつ、そのうちご報告できる内容があるかも？ なので、またそのときにでも blog エントリを書こうと思います。なにはともあれ、600 ページという膨大な量のコンテンツで恐縮ですが、パラパラとめくって Windows Azure の世界をお楽しみください！^^

ここ最近、組織改変などの影響もあって忙しい日々が続いている今日この頃。なかなか  blog エントリ書きも滞ってしまっていて申し訳ないのですが；、最近はコンサルの現場を離れて、少しバックエンド系のお仕事をしていたりします。といっても、プロジェクトの技術レビューや提案活動は以前と変わらず実施しているのですが、そんな中、営業支援でお手伝いをしていた案件のひとつが、全社開発標準の整備・強化プロジェクト。簡単に言えば、SIer のコアコンピテンスのひとつともいえる全社開発標準を整備・強化していくことで、より強い SIer を目指していきたい、という話です。

全社開発標準の整備・強化プロジェクト、確かに SIer の強化のために開発標準のような「モノ」が重要な役割を占めるのは間違いないのですが、けれどもそれだけではダメで、それを作り、回していく「ヒト」の強化、つまり人材育成にもかなりの力を注がないと、なかなかうまくいかないものです。こうした組織強化の中でも特に人材育成の話は、私自身がずっとこだわって携わってきた領域でもあったりします。おそらく現場の開発系エンジニアにとって、ひとつ参考になる考え方になるのではとも思いますので、今回、blog エントリとして取り上げてみることにしたいと思います。

※ なお、このエントリの内容は、ITSS などの標準的なスキルマップを使ったものでもなければ、マイクロソフトとしての標準的なスキルロードマップというものでもありません。私自身が現場の『肌感覚』として、開発系エンジニアがどうやってスキルアップし、生き残っていくべきなのか？ というものを考えてきた結果としての、一つの考え方にすぎません。その点についてはあらかじめご了承ください。

［Agenda］

• システム開発の在り方の変質と、開発系エンジニアへの要求の変質
• SIer にとってのテクニカルスキルの重要性
• 開発系エンジニアのスキルアップの難しさ
• 座学（トレーニング）と OJT のバランス
• システム開発プロセスの基本とエンジニアの分類
• システム開発のフェーズとエンジニアの対応関係
• スキルタイプごとのトレンドと育成ポイント
• キャリアパスとしての技術コンサルタント

［システム開発の在り方の変質と、開発系エンジニアへの要求の変質］

昨今の開発系エンジニアは、開発現場で過酷な労働を強いられていることが多いと思います。一昔前は花形産業としてもてはやされていた IT 産業は、今や 21 世紀の新しい “3K” （キツい、帰れない、給料が安い）と揶揄されるような状況。中でも SI （システム開発）の仕事の厳しさは、私が改めてここで書くまでもないことと思います。なぜこんなひどいことになってしまったのか？ それを総合的に語ることは簡単ではありませんが、私自身が開発現場にコンサルタントとして携わっていて強く感じることのひとつに、「開発技術の理解や習得（テクニカルスキル）が相対的に軽んじられてしまっている」ことがあります。実際、「スキル不足」「スキルの低さ」が開発のトラブルや失敗を招いているケースは後を絶たず、現場のトラブルを見てみると、そもそもどうしてこんなことをしたのか？と言いたくなることもしばしば。今の時代ほど、テクニカルスキルが重要な時代はないとすら私は思うのですが、なぜテクニカルスキルが重要なのか、どうしてそうなったのかについては、あまり理解されていないように思います。

テクニカルスキルが従来以上に重要になったのは、現在のシステム開発が、数十年前に見られたような労働集約型のビジネスとは言いづらくなってきたことに起因しています。システム開発における SIer のゴールは、システムを「早く・安く・上手く」作ることであり、それを実現するために、以下のような考え方とアプローチをとっていました。

• 開発標準化を行い、プロセスと開発方法を標準化し、「誰でも彼でも作れる」ようにする。
• これにより、スキルの低いエンジニアや単価の安いエンジニアでも、品質の高いアプリケーションを作れるようにする。

端的に言えば、「エンジニアのスキルの低さ」を「開発標準化」でカバーする、という方法だったと言えますが、この考え方は、残念ながら現在ではなかなか通用しなくなっています。

従来の考え方が通用しなくなった最大の理由、それは昨今の開発ツールやフレームワークなどの技術進化です。例えば今から約 10 年前、VB6 の時代に、データベースからデータを取得しようと思った場合には、以下のようなコードを記述する必要がありました。（※ コードを理解する必要はありません、なんとなく見てください）

Dim con As ADODB.Connection

Dim cmd As ADODB.Command

Dim rs As ADODB.Recordset 

Set con = CreateObject("ADODB.Connection")

Set cmd = CreateObject("ADODB.Command")

Set rs = CreateObject("ADODB.Recordset")

' データベース接続を開きます。

con.Open "Provider=SQLOLEDB;Data Source=sqlsrv00;Initial Catalog=pubs;Trusted_Connection=yes" 

' Commandオブジェクトで利用するコネクションを指定します。

Set cmd.ActiveConnection = con

' コマンドタイプをSQL文実行として指定し、SQL文をセットします。

cmd.CommandType = adCmdText

cmd.CommandText = "SELECT * FROM authors"

' 読み出し専用の切断レコードセットのためのオプションを指定します。

rs.CursorLocation = adUseClient

rs.CursorType = adOpenStatic

rs.LockType = adBatchOptimistic 

' レコードセットを取得します。

rs.Open cmd

' 切断レコードセットにするため、コネクションを切断します。

' また同時に、不要となったオブジェクトを破棄していきます。

Set cmd.ActiveConnection = Nothing

Set cmd = Nothing

Set rs.ActiveConnection = Nothing

' データベース接続を切断し、解放します。

con.Close

Set con = Nothing

ところが、今の時代、例えば ADO.NET や LINQ to Entity Framework を使うと、上記の処理は数行で書けてしまいます。

using (pubsEntities pubs = new pubsEntities())

{

    var query = from a in pubs.authors select a;

    List<author> result = query.ToList();

}

ひと昔前であれば、数 10 行～数 100 行のコードを書かなければいけなかった作業が、今や本質的な作業を表す数行のコードを記述するだけで済むようになった、ということなわけですが、この変化は、以下の 2 つを意味します。

• ブルーカラー的な単純労働作業がなくなった、端的に言えばコピペ作業はなくなった、ということ。
• 設計と実装の距離が非常に短くなった、端的に言えば設計者がその内容を直接コードとして表現できるようになった、ということ。

つまり、現在の開発技術のトレンドは、手を動かすだけの労働集約的な作業は少なくなり、ホワイトカラー的な設計者が直接かつ素早くモノ作りをしていくことができる方向に進化している、ということを意味します。結果として、現在の技術トレンドは、シニアな開発メンバによる、少数精鋭の SWAT チーム的な開発に適したものに進化してきている、ということになります。

これは .NET、Java を問わず、昨今の開発技術全般について言えることですが、現在の開発技術（言語やツール）の怖いところは、ジュニアなコピペエンジニアの仕事をなくしてしまう、ということです。実際、現在の .NET Framework や Visual Studio は極めて高い生産性ツールであるものの、誰もがその高生産性を十分に引き出せるというわけではありません。設計スキルやアーキテクト的な素養があればあるほど、その高開発生産性をうまく引き出すことができる、という類のツールです。その結果、スキルの高い人はますます稼ぎ、スキルの低い人は簡単に淘汰され価格競争に巻き込まれる、という構図ができあがります。こうしたことからも、特にデベロッパーにとってスキルが極めて重要であることがわかるかと思います。

［SIer にとってのテクニカルスキルの重要性］

このテクニカルスキルの重要性は、直接、内部設計や実装などの開発作業に携わらない SIer にも当てはまります。なぜ SIer においてもテクニカルスキルが重要なのかは、以下のようなことを考えてみればすぐにわかります。

SI では、たくさんの人がプロジェクトに関与します。こうした中で、開発にかかる総コストを低減し、自社の付加価値を高めていくために SIer が行ったことは、実装作業やテスト作業といった、比較的ブルーカラー色の強い業務を、協力会社やオフショアに移転していくことでした。すなわち、自社のプロパー要員を、極力、リーダーやプロジェクト管理業務に注力させ、自社のコアコンピテンスを、単価の高い高付加価値業務にシフトしていくことで、企業価値を高めていこうと考えたわけです。

この考え方自体はごく普通の話ですし、市場原理に基づけば、ごく当たり前の流れともいえます。しかし問題なのは、コアコンピテンスにリソースを集中させすぎると、かえってコアコンピテンスを失う結果につながってしまう、というポイントです。例えば、F1 レーサーを考えてみてください。F1 レーサーのメインの仕事は F1 カーを走らせることであり、その部分がお金を生み出しています。ですが、だからといってそればかりに注力して、日々の筋トレを怠ってしまったらどうなるでしょうか？ しばらくの間は高付加価値業務を維持できるかもしれませんが、その後は筋力を失い、結果として F1 カーをドライブできなくなり、仕事を失うことにつながっていきます。筋トレで稼いでいるわけではありませんが、だからといって筋トレをやめたら F1 カーを走らせられなくなる、という側面があるわけです。

この例からも明らかなように、コアコンピテンスというのは、それが単体で存在しているわけではありません。実際には、コアコンピテンスを支えているベースラインスキルというものが存在します。ベースラインスキルというものは、それ単体では価値を生み出すものではなく、またそれ自体を専門にする必要性のあるものではありませんが、それを失ってしまうとコアコンピテンスを維持できなくなる、という類のものです。コアコンピテンスを考える場合には、それがベースラインスキルとは不可分であることを意識することが重要であり、日々、ベースラインスキルを維持すること（簡単に言えば基礎トレ）も同時に考えなければなりません。

SIer の場合、プロジェクト管理やチームリードを専門として行���ことで付加価値を守っており、自ら実装や内部設計を行うわけではありません。これは今後も同じでしょう。ですが、だからといって技術のことを知らなくてもよいということではないはずです。自ら開発をしなくても、技術の肝を理解していなければ、協力会社やオフショアに依頼したものをレビューすることすらできなくなってしまいます。「自分ができないから外注する」のか、「自分でもできるけれどもコストが安いから外注する」のか、どちらであるのかは天と地ほどの違いがあります。SIer のコアコンピテンスを守るためには、やはりテクニカルスキルがベースラインスキルとして求められるのだと思います。

そういう意味において、SIer の場合、協力会社やオフショアなどの外注に依存しきらないようにすることが大切です。例えば、小規模案件であれば自社のみで開発したり、大規模案件であっても若手のプロパーメンバーを実作業員として参画させて現場経験を積ませたりすることで、実作業の『勘所』を見失わないようにすることが重要です。そうすることで、本当の意味での自分たちのコアコンピテンスを守っていかないと、企業価値が損なわれていってしまいます。

プログラマーではなく SE、SE ではなく PM、PM ではなくコンサル……といった具合に、名前を付け替えていったとしても、中身が伴わなければいつかは破綻します。我々エンジニアが自分たちの市場価値を守っていくためには、足腰をきちんと鍛え、地に足の着いた、本当の意味での実力を身に着け、発揮していかなければなりません。そのベースラインとして、テクニカルスキルが極めて重要であることを、今一度改めて認識することが大切なのだと思います。私自身、コンサルタントをしているときは、（別にコーディングを業務として行うわけではないのですが）折に触れてコーディングの訓練をしていましたし、マネージャ業務をやっている現在でも、折に触れて最先端技術を学習するようにしています。勘所がわからなければ、コンサルティング業務もマネージャ業務もきちんとできないからです。

［開発系エンジニアのスキルアップの難しさ］

……などと、とりあえず理屈をこねてみたわけですが、現場にいる開発系エンジニアの実感としては、「理屈は分かるけど実際にはムリでしょ；；；」というのが偽らざる本音だと思います。実際、開発現場のエンジニアのスキルアップや育成を拒む要因はたくさんあります。代表的なものという意味だと、以下のようなものでしょうか。

• 技術要素が多すぎて、とても追いつけない。
• 勉強しようにも、どこからどうやって勉強していけばよいのか、ロードマップがない。
• そもそも物理的に時間が取れない。

こうした厳しい状況の中で、羅針盤もなしに「勉強しろ」と命じたところで回るわけがないですし、意欲的なエンジニアもどうやって勉強すればよいのか途方に暮れてしまうと思います。自分で勉強するにせよ、会社として育成するにせよ、しっかりと基本に立ち返った考え方をする必要があります。そのための要点は、以下の 2 つです。

• 座学（トレーニング）と OJT のバランスを取ること
• 「開発系エンジニア」を適切にタイプ分類し、それぞれに適した学習ロードマップを持つこと

それぞれについて、説明していきたいと思います。

［座学（トレーニング）と OJT のバランス］

スキル強化を考える際、昨今は OJT （現場で業務をしながら仕事を覚える）が非常に重視されるようになりました。なぜなら、IT 業界では座学では学べないノウハウがたくさんあり、それは現場の実務経験からしか学ぶことができないからだ、だから新入社員のトレーニングは最小限で済ませて早く現場に送り出すのだ……などと言われていますが、私自身の肌感覚からすると、それはトレーニング予算を削減するための、体（てい）の良い言い訳ではないか？ と正直思います。というのも、現場の OJT 経験だけでは、確たる実力が身につかない、あるいは身についたとしてもとてつもなく効率が悪くて時間がかかりすぎるからです。

小学生や中学生の頃の勉強を思い返して欲しいのですが、勉強するときに、教科書もろくに読まずにいきなり問題集に取り掛かる方法は、どう考えても学習効率が悪いです。仮にその方法で問題集を丸暗記して直近の期末試験を何とか乗り越えたとしても、ほとんど定着しませんし、ちょっと角度を変えた応用問題を出されたとたんに解けなくなるものです。言うまでもなく、「理論」と「実践」の両方が伴って、初めて応用力のある実力、すなわち現場での実力となるものですが、昨今のシステム開発の現場では、こうした基礎トレーニングが思ったようにできていないのが実際ではないでしょうか？

特にここ最近は、教育に対する投資を後ろ向きに考えがちな風潮があるようにも思います。トレーニングを受講してもらって人を育成しても、すぐに辞めてしまうのではないか？ そもそも多忙を極める現場からトレーニングに人を出したら現在のプロジェクトが回らなくなるのではないか？ などなど、心配事項は尽きません。確かに、座学で理論ばっかり勉強していても頭でっかちになるばかりですが、かといって OJT だけでは基礎学力は身に付きませんし、基礎学力が身についていないと、場当たり的・その場しのぎのパッチ的な解決策に走りやすくなります。例えば、インターネットから検索したソースコードを、意味も理解せずにそのままコピペしたようなアプリケーションコードを現場で見かけたりしませんか？ そうしたアプリケーションコードは、潜在バグも多いものです。こうしたことを防ぐためには、まずトレーニングや座学で幹を作り、そこに OJT で枝葉を補い、応用力をつけていくことが大切です。枝葉だけかき集めても、しっかりとした幹を持った大木にはなりません。

私自身の肌感覚としては、座学（業務時間外での学習や書籍などでの自習も含む）と OJT とのバランスは、だいたい 1 : 4～5 ぐらいではないかと思います。座学ばっかりやっている必要はないけれども、最低でも時間ベースで 10～15% ぐらいは基礎トレをしていないと、現場で力を発揮できないという印象を持っています。私自身、コンサルタントをやる上では、意識的にこうした学習時間を取るようにしていました。

ただし、座学での学習は、やみくもに時間をかければよいというものではありません。きちんとした学習・成長ロードマップを持ち、「どこを目指すのか？」（＝自分の専門性）を意識した学習が必要になります。この部分に関しては、日本の考え方は少し遅れているように感じていますので、少し深掘りしてみたいと思います。

［開発系エンジニアのタイプ分類］

開発系エンジニアがスキルアップを考える際に重要なのは、自分の専門性をどのように捉えるのか？という点です。日本の場合、開発系エンジニアに関しては比較的考え方が古く、今でもゼネラリスト的な考え方を取ることが多いです。もう少し説明すると、下図にあるように、

• まず新入社員は、情報工学の基礎や、ネットワーク、DB、プログラミングなどの基礎を学習する。
• 次に、システム開発プロセスや運用管理、セキュリティなどを学習する。
• それが終わったら、業界業種知識などを伸ばす。
• さらにプロマネスキルやコンサルティングスキルを伸ばしていく。

のように、ひとつのロードマップで成長していくようなモデルを取っていることが多いと思います。実際、日本の場合、プロジェクトマネージャ、SE、プログラマー、テスターの間には明確な職位的上下関係があり、まるで昔の士農工商制のように扱われていることも多いと思います。新人はまずテスターを経験し、頭角を現した場合にはプログラマーを経験させ、そこでさらに頭角を現した人には SE になってもらい……といった具合です。

しかし、米国などでは、より専門性の強い職種への細分化が進んでいます。新卒エンジニアはまず基礎学力をつける、というところは変わりがないでしょうが、ある程度の経験を積んだあとは、業務 SE やアーキテクト、デベロッパー、テスター、プロジェクトマネージャーなどに職種が分かれ、それぞれの職種の専門スキルを深めていくことになります。

もちろん米国などにおいても、小規模な組織や開発においては、一人が複数の職種を兼任することは当然あるでしょう。しかし、少なくともそれぞれの職種には専門性がある、と考えているところが重要なポイントです。簡単に言えば、上級のテスターには上級のテスターとしてのスキルやノウハウや専門知識というものが存在するし、上級のアーキテクトには上級のアーキテクトとしてのスキルやノウハウや専門知識が存在する、ということが認知されているというところがポイントです。このため、特に高度な専門性を要求する会社の場合、中途採用の枠などは、最初から個別に分かれています。例えばこちらはマイクロソフトの採用ページですが、募集されている職種を見てみると、ソフトウェアエンジニアリングにおいて、製品計画、開発、製品テストなどが最初から分かれていることが確認できると思います。

開発系エンジニアの職種（＝専門性・専門分野）をどのように細分化するのか？ に関しては、様々な方法があります。例えば、Visual Studio にも組み込まれている MSF（Microsoft Solution Framework）と呼ばれる方法論でよく使われるロール（職種）としては、① プロダクト管理、② プログラム管理、③ アーキテクチャ、④ 開発、⑤ テスト、⑥ リリース管理、⑦ ユーザーエクスペリエンス、があります。が、開発対象となるシステム規模によってもこの細分化の程度は変わってくるため、私自身はこれをもう少し簡素化した以下の 5 つのロールを、基本的な開発系エンジニアの専門分野と捉えるとよいと思っています。これぐらいの方が覚えやすいし、使いやすいでしょう。

• 業務 SE（要件定義や業務設計を担当）
• アーキテクト（方式設計などの設計・実装標準化を担当）
• デベロッパー（内部設計や実装を担当）
• テスター（テストと品質評価を担当）
• プロジェクトマネージャ（プロジェクト管理を担当）

なぜ開発系エンジニアがこのような 5 つの専門職種に分類されるのかは、システム開発のプロセスを理解すれば自ずと理解できます。これについて解説します。（次回に続く……；）

（このエントリは Part 1からの続きです。）

［システム開発プロセスの基本とエンジニアの分類］

業務システムの開発には様々な人が関与しますが、どのような規模のシステム開発であったとしても、少なくとも以下のような役割（ロール）のメンバーが必要になります。そして、それぞれのロールには、他のロールとは異なる専門性が求められます。この 5 つのロールを理解することは、開発系エンジニアが自らの専門性を深めていく上で極めて重要な指針となるものですので、これらについて解説します。

① 業務 SE

業務 SE とは、お客様から業務要件をヒヤリングし、その情報を元に、実装可能な業務仕様を取りまとめていくエンジニアです。上流寄りの業務 SE はどちらかというと業務コンサルに近く、下流寄りの業務 SE はどちらかというと開発者に近いロールになりますが、いずれにしても、お客様の業務内容を理解し、それを仕様や設計に落とし込んでいくというのがポイントになります。このため、業務 SE の人たちには、業務に関する専門知識（ドメインエキスパート）や、モデリングに関する専門知識（データモデリングなど）が要求されます。

② アーキテクト（アプリケーションアーキテクト）

アーキテクトとは、アプリケーションやシステムインフラに関する方式設計（アーキテクチャ設計）を行うエンジニアです。簡単に言うと、どのような方式（アーキテクチャ）でその業務システムを実現するのかを決定する役割になります。このため、この作業を行うためには、業務に関する知識と理解、そして開発技術に関する、幅広く深い知識と理解が必要になります。また、（後述しますが）業務 SE とデベロッパーの橋渡しをすることも、重要なロールの一つになります。

③ デベロッパー

デベロッパーとは、業務 SE のまとめた業務仕様に基づいて、内部設計と実装作業を行うと共に、テストチームに引き渡し可能な品質のアプリケーションを作り上げる人たちです。ひと昔前であれば、「プログラマー」と呼ばれていた人たちに相当します。ただし、現在のプログラム開発は、前回のエントリに書いた通り、いわゆるブルーカラー的なコピペ作業ではなくなっています。つまり、業務 SE から渡された業務仕様書を元に、プログラムの内部設計を書き起こし、それをコードとして組み立てられるスキルが求められているわけです。このような、内部設計作業からプログラミング（実装作業）、そしてプログラムコードから実際のバイナリファイル（成果物）を作り上げていく人たちを、デベロッパーと呼びます。ですので、デベロッパーの人たちには、プログラミングに関する深い専門知識が求められるだけではなく、業務仕様を理解し、プログラム内部設計を書き起こせるスキルも求められています。

④ テスター

テスターとは、デベロッパーの人たちが作ったアプリケーションを体系的・網羅的にテスト・評価する方法を考え、バグの発見と、アプリケーション品質の定量化を行っていく人たちになります。「テスター」というと、テスト計画やテストケースに基づいて、実際にアプリケーションの操作を行う人、というイメージがありますが、実際にテストを行う場合には、優れたテスト計画やテストケースを作成することの方が圧倒的に重要であり、この部分には極めて高いスキルが要求されます。こうした、優れたテスト計画の立案やテストケースの設計を行い、得られたテスト結果から各種の品質指標数値データを算出していく役割を担うのがテスターです。（このため、テスターは QA （Quality Assurance、品質保証）担当と呼ばれることもあります） ですので、テスターの人たちには、業務仕様や各種テストツールに関する深い知識はもちろんのこと、各種の統計解析・統計分析スキルを持っていることが要求されます。

⑤ プロジェクトマネージャー

プロジェクトマネージャーとは、前述したような各種のロールのメンバーが最大限の能力を発揮できるように各種の調整を行うと共に、プロジェクトの全体進行の進捗管理などを行う人になります。（小規模開発でロールを兼任せざるを得ない場合でなければ）プロジェクトマネージャー自身はシステム開発作業を直接行うことはなく、チームメンバーやステークホルダーとのコミュニケーションに力を注ぐことになります。このため、求められる専門知識やスキルも、技術知識というよりは、コミュニケーション能力、リーダーシップ、交渉力、問題解決力など多岐に渡ることになります。開発系エンジニアという枠組みで捉えるべきか否かは難しいところですが、開発系エンジニアとしてのスキルや知識がないと、システム開発のプロジェクトをうまく回すことは難しいのもまた事実なため、ここで取り上げておくことにしました。

なお、この 5 種類のロールに関して誤解されやすいポイントが 2 つありますので、少し補足説明を加えておきます。

• アーキテクトとデベロッパーは別物
• デベロッパーとテスターは別物

アーキテクトとデベロッパーの違い

システム開発において、チーム内にアーキテクト（アプリケーションアーキテクト）を置くのは、アプリケーションの作り方を一定化させて品質を安定させるためです。これについて説明します。

一般に、アプリケーションは、業務 SE が行った業務設計に基づいて、デベロッパーが作成していく、という流れになります。この際、統一的な設計思想のないまま業務要件定義書に基づいて実装が行われると、場所ごとに作り方がまちまちになってしまって保守できなくなったり、性能の出ないアプリケーションができてしまったり、セキュリティの確保の方法が一貫していないアプリケーションになってしまう危険性が高くなります。これを防ぐために、チーム内にアーキテクトを配し、アーキテクトの人が方式設計、すなわちアプリケーションの実現方式に関するプランを固め、これを徹底します。このようにすることで、複数人のデベロッパーが関わっても、同じようなアプリケーションが出来上がり、各種品質が担保されるようになります。

「アーキテクト」と聞くと、非常に華々しくカッコいい職種を思い描かれる方も多いかと思いますが、そうした方は、アーキテクトという職種を誤解しています。アーキテクトを設置する『目的』は、たくさんいるデベロッパーの方々に、一貫した設計思想に従った、品質の高いアプリケーションコードを書いてもらうことです。そのためにアーキテクトは、日常的にはかなり地味くさい ＆ 泥臭い仕事をたくさんします。例えば…

• 業務 SE の人たちに頭を下げて、業務のことを教えてもらう。
• 日々、開発技術を一生懸命勉強して、その要点をきっちり理解する。
• そのシステムをどんなふうに作るのがベストなのかを考え、それをアーキテクチャとしてまとめる。
• 自分が考えたアーキテクチャをデベロッパーの人たちに理解してもらうために、解説書（開発標準書）をまとめる。
• デベロッパーの人たちにその開発標準書を理解してもらうために、頭を下げてまわって一生懸命説明する。
• デベロッパーの人たちが作ったアプリケーションコードをレビューして、定着度を確認したり、修正を依頼したりする。

などです。編成された開発チームのデベロッパーのスキルが高くない場合には、「本当はこうするといいんだけど……」というところを断念して、意識的にアーキテクチャを簡単化するようなこともしばしばあります。この話からも分かるように、難しくてかっちょいいアーキテクチャを書いて、それを開発チームに丸投げして放置し、自分の書いたアーキテクチャが理解できないのはデベロッパーのスキルが低いのが悪いんだ！ などと思ってしまうような人は、アーキテクトには全く向いていません……というよりむしろ害悪です；。日々鍛錬に励み、他人に頭を下げることを厭わず、最終的に出来上がってくるアプリケーションの品質を高めるために何でもやろう！ という気概を持って、プロジェクトの最後まで面倒を見る覚悟のある人だけが、アーキテクトを名乗る資格があるのだと私は思います。

……と、ちょっと話が逸れましたが、アーキテクトのこのような業務内容を意識すると、アーキテクトはプロジェクトメンバ全体に対して 10～15 % 程度必要だろうと思います。もちろん、すべてのアーキテクトがハイスキルである必要はなく、一部のアーキテクトがリードを務め、残りのアーキテクトはサブの位置づけでアーキテクチャの定着に努めるメンバ、といった形にすることも多いと思います。が、いずれにしても開発現場を見てみると、このアーキテクトロールの人員が不足しているケースは多いです。このような場合には、適宜、社内の関連他部署や社外のコンサルティングサービスなどを活用し、アーキテクトロールの不足を補うようにすることをおすすめします。

デベロッパーとテスターの違い

デベロッパーとテスターも、日本では極めて混同されやすい職種ですが、やはりこの二つも、専門性が全く異なります。一言で言えば、デベロッパは「作ることの専門家」、テスターは「品質評価の専門家」です。これは、実際の作業を意識しないとわかりにくいので、こちらの図を使って説明します。

例えば、マイクロソフトにおいてあるパッケージ製品（例えば Office 2010）を開発する場合を想定してみます。この場合、デベロッパーチームは、単純にコーディングをするだけではなく、それをビルドし、バイナリパッケージ（簡単に言えば半完成品）を作成します。テストチームはこの半完成品を受け取り、品質検査（テスト）を行い、品質評価を行います。品質に問題がある場合（すなわちバグがたくさん見つかってしまった場合）には、バグ報告票を起票してバグの修正を依頼し、デベロッパーチームに修正を要求する、という形になります。そして再度、デベロッパーチームから完成品を渡してもらい、これを再度、品質評価する、という流れを繰り返します。

この一連の流れにおいて重要なのは、テストチームのメンバーは、ソースコードを見たり触ったりせず、またバグの原因追究も行わない、という点です。あくまで完成品をエンドユーザと同様に触ったり使ってみたりして、問題がないかどうか、品質を検査します。そして問題があった場合には、その問題を的確に報告する（＝バグの再現手順をデベロッパーチームに報告する）ことを行いますが、そのバグの原因追及や修正作業はテストチームは一切行いません。バグの原因を追究し、それを修正するのはデベロッパーの責任だからです。というか、バグの修正方法などに中途半端にテスターが首を突っ込むと、「アプリの作りもよく知らないのに、適当な修正方法を言ってくれるな！」とケンカになります；。デベロッパーは料理人、テスターは料理評論家のようなものです。料理評論家は「おいしくないから修正すべき」ということだけを伝えるべきで、料理法やら素材やらを論じてうっかり踏み込むと、ケンカになってしまいます；。

このように、デベロッパーとテスターの間には、明確な役割の違いがあります。まとめると、以下のようになります。

日本の場合、テストとデバッグ作業が区別されていないことが多く、また、「完成品」を通して、デベロッパーチームとテストチームが連携する、という考え方が取られていないことも多いです（いやそれどころか、テストチームが独立していないことの方が多いでしょう）。しかし、『作ること』と『それを評価すること』とは全く異なるスキルセットが要求されますし、どちらが偉いという性質のものでもありません。実際、米国などでは、テスターとデベロッパーとの間に職位的上下関係はありません。

なお、稀に、バグ出しはテストチームの責任だと考えている人がいますが、これも誤りです。なぜなら、そもそもテストチームがテスト作業を始める前（すなわちテストフェーズに入る前）に、デベロッパーチーム側で十分な単体機能テストとデバッグを行い、ふつうに使ったぐらいではバグが出たりすることはない程度まで品質を高めておくことが必要だからです。というのも、テストフェーズに入った後、テストチームがバグを見つけた場合には、バグ報告票を起票してきちんとバグ管理をしなければならなくなりますが、バグの数があまりにも多い場合には、バグ管理そのものがまともに機能しなくなります。つまり、テストフェーズでバグ管理を適切に行うためには、管理できる程度までバグの数が減っていることが必要です。このためには、テストフェーズに入るまでに、デベロッパーチームが十二分にデバッグを行い、バグを摘出しておくことが必要です。

ちなみに、マイクロソフトの製品開発の場合には、テストフェーズに入ったのち、テストチームが一定期間以内に一定数以上のバグを発見した場合には、テスト不能として、テストチームがデベロッパーチームに対してフェーズの差し戻しを要求することができるルールになっています。

デベロッパーチームがきちんとデバッグしたものを、エンドユーザ視点で品質検査して、わずかに残っているバグを徹底的に摘出し、さらに品質を評価することが、テストチームのテスターには求められているわけです。かなりの高いスキルが要求されること、またデベロッパーとは全く違う視点やスキルが求められることが、容易に想像できるかと思います。

［システム開発のフェーズとエンジニアの対応関係］

さて、ここまで、システム開発に必要となる基本的な 5 つのロールを説明しました。

• 業務 SE
• アーキテクト
• デベロッパー
• テスター
• プロジェクトマネージャ

この 5 つのロールの人たちが、システム開発の各フェーズにおいて様々な作業を行い、システムを開発・リリースしていきます。プロジェクトのサイズや状況によって実施すべきタスクや期間はかなり変わってきますし、大型のプロジェクトでは構成管理チームやインフラチーム、運用チームなども編成される形になってきますが、おおざっぱには以下のような形になります。

……とまあ、こんな感じのイラストをよく見かけると思います。が、正直なところこうした作業図はとてもじゃないけれども覚えられない、というのが実際のところだと思います。私としてはこの図を暗記するよりも、以下のような形で勘所を覚えておくことをおすすめしたいです。

一般に、システムは「要求されたものを作る」わけですが、要件は以下の 2 つに大別されます。

• 機能要件：「どんな機能が必要なのか？」「何を作るのか？」
• 非機能要件：「各機能をどの程度の品質で作るのか？」

この二つの要件を明らかにし、それを満たすようにシステムを開発していくのがシステム開発です。このように考えると、システム開発の流れと大まかなタスクは、以下のようにまとめることができます。

この 2 つの流れにおける各タスクを実践していく際には、当然、得手不得手に応じたスペシャリストを割り当てることが必要です。先ほどの 5 つのロールとのマッピングを考えると、以下のようになります。

もちろん、実際の作業では、ここに示した人たちだけが各タスクを実施するわけではありません。例えば、結合機能テストを実施している最中は、当然、デベロッパーの人たちがバグの修正作業を行っているはずです。また、業務設計が終わった後、業務 SE の人たちはマニュアルを書いたり、場合によってはテスターロールとなってテスト計画やテストケース設計をしていることもあるでしょう。ですので、ここに書いたのはあくまで開発プロセスにおける骨組みで、ここに枝葉を補って、最終的には WBS やスケジュールを作成していく必要がありますが、こうした骨組みの部分を理解しておくことは極めて重要です。このような形で開発プロセスを理解しておくと、なぜ前述の 5 つのロールが開発において極めて重要な意味を持つのかがお分かりいただけるかと思います。

では、こうした作業を実践していくために、各ロールがどのようなスキルを持っているべきなのかについて考えていきたいと思います。（次エントリに続く。）

（このエントリは Part 2からの続きです。）

さて、Part 2 のエントリでは、開発系エンジニアの 5 つの分類を示しました。この 5 つのロールに関して、昨今のトレンド及び育成ロードマップがどのようなものであるべきか、自身のスキルを高め、市場価値を高めるためにはどうならなければいけないのかについて考えてみたいと思います。

［① 業務 SE （要件定義・業務設計）について］

私がこの IT 業界に飛び込んだ頃は、まだ要件定義や業務設計に関してはあまり情報が整理されていませんでした。しかし、最近は要件定義手法に関する研究が進んできており、書店にも多数の書籍が並ぶようになりました。「要求開発」といった手法や考え方が出てきたり、また特に品質特性（非機能要件）の領域に関する研究の深化などにより、従来に比べてかなり方法論が整ってきた感があります。また、パッケージ製品や SaaS が適用できる領域も増えつつあり、メールなどの IT インフラ領域だけでなく、販売管理や顧客管理などの領域でも、パッケージ製品や SaaS 利用ができるようになってきています。こうした中で、「業務」のことだけを見て、技術のことを知らずに業務設計を行うと、「実現不可能な」システムになってしまったり、「コストがかかりすぎる」システムになってしまう危険性もあります。

こうしたことを踏まえると、業務 SE のスキルロードマップとしては以下のようなものが考えられます。すなわち、まず入社直後は一般的なモデリング技術や業務分析手法を習得して基本的なスキルを身に着け、その後、技術スキルをベースとして、業界・業種知識を伸ばしていきます。最後には、業界・業種に関する深い造詣を元に業務コンサルティング領域へと踏み出していき、業務の To-Be モデルの策定や、実現可能な業務システムの提案・設計ができるようになっていくことが一つのゴールとなってくるでしょう。

［② アーキテクト（方式設計）について］

前述したように、アーキテクトはシステムの実現方式やアプリケーションの作り方を決定し、それを開発チームで実践する役割を担っています。このため、アーキテクトロールは開発チームの中で非常に重要な役割を担っていますが、アーキテクトを取り巻く環境は厳しくなる一方です。特に厳しいのは、昨今の開発技術の複雑化です。UI の多様化（Web, RIA, スマクラ, モバイル）、クラウドコンピューティングなど、システムのプラットフォームが一気に複雑化してきており、こうした多種多彩な技術に深い造詣を持つエンジニアの希少性が一段と高くなってきています。このため、どこの会社もアーキテクト不足に悩んでいる、というのが実情でしょう。

また、アーキテクトの重要性が頻繁に語られる割には、「アーキテクチャ」の詳細に関する業界標準がないのも大きな課題です。例えば、何を以て「アーキテクチャ」とするのか？ また標準化としては何をすべきか？ に関しては、業界内で統一的な見解がなく、例えば SIer 各社がノウハウを持っていたとしても、社外に対して公開されたり share されたりすることがなく、ノウハウを外部から入手することが困難、という難しさもあります。また、方式設計（アーキテクチャ設計）は「机上の空論」ではなく「実践可能」でなければなりませんので、高度なテクニカルスキルも求められます。簡単に言えば、多種多彩な開発技術に対して深い造詣を持つと共に、そこからアーキテクチャに関して自分なりの見解を組み立てるスキルが求められるのが、アーキテクトというロールだと言えます。

ただし、最終的なゴールは前述したように、自分でアーキテクチャを考えるだけではなく、それを流布させ定着させていくことです。ここまで含めて考えると、アーキテクトとして目指すべき最終的なゴールは、教育的視点まで含んだ開発標準化の実践、というところになっていくでしょう。

［③ デベロッパー（内部設計・実装）について］

Part 1 にて解説したように、昨今のアプリケーション開発の特徴は、内部設計と実装の距離が大きく縮まっていることです。すなわち、実装の手間が軽減されることで、内部設計がダイレクトに実装に直結するスタイルに近づいてきており、内部設計者がそのまま実装することが可能になってきています。このことは、裏を返せば、内部設計スキルのないエンジニアがツールやフレームワークを誤用すると、品質に大きな難のあるアプリケーションが出来やすいということでもあります。このため、デベロッパーの人たちは、コーディングのスキルだけでなく、内部設計のスキルを高めていくことが非常に重要になっていると言えます。

ところが現場の実情を見ると、特に若手デベロッパーに、基礎スキルの不足の傾向がみられます。これは、ウィザードやツールを多用した開発の練習ばかりしているためで、内部の動きや作業の意味を理解しないまま、技術の勉強を進めているためでしょう。ひどいケースになると、変数定義やインスタンス生成などの基本的な意味がわかっていないことすらありましたが；、こうしたことを避けるためには、単に表面的なツールの使い方やコーディング方法を勉強するのではなく、裏側の動きまで含めた、一歩踏み込んだ学習をしていかなければなりません。そうしたことを怠ると、その場しのぎの作業がどんどん増えていき、最後にはインターネットからコードをコピペしまくる「Copy & Paste」デベロッパーになってしまいます。でも、こうしたデベロッパーは確実に淘汰されます。オフショアなどとの価格競争に巻き込まれな���ようにするには、デベロッパーとしての生産性や付加価値をどのように守っていくのか、どのようにそれらを向上させていくのかを、真剣に考える必要があります。なぜなら、今でもフレームワークや共通部品群、アプリケーションの中核部分は開発が難しく、スキルの高いデベロッパーにしか作れないからです。基本的には、デベロッパーが自身の市場価値を維持・向上する方法は以下の 2 つのいずれかだと思います。

• ツールを最大限に生かし、開発生産性を大幅に高めること
• 他の人には作れないような高度なコードを開発できるようになること

要するに、「早く・安く・上手く作れる」ことが、デベロッパーの目指すゴールとなります。

［④ テスター（結合機能テスト・システムテスト）について］

システム開発の世界におけるテスターというのは、以前は肩身の狭い職種だったように思いますが、最近になって、テストはデバッグとは違うということ、すなわちテストとは品質評価であることが、ようやく認知され始めてきました。米国では、ここ 5～10 年ほどで現場での研究ノウハウがようやく結実し始め、書籍などの形で入手しやすくなってきています。実際、マイクロソフトも Visual Studio 2010 でようやく本格的なテストツール Microsoft Test & Lab Manager （略称 MTLM）をリリースし、科学的なアプローチに基づく「品質評価」を実践しやすい環境が、ツール面でも整ってきました。

しかし残念なことに、日本の開発現場の多くは旧態依然としたテストが実践されており、KKD （勘と経験と度胸）でテストが行われてしまっていることが多いと思います。システム開発を生業としている SIer ですら、製造業のような高度な品質管理はほとんど実践されておらず、テストの専門性が認知されていないことすらあるのではないでしょうか？ 先進的な企業ではこうした部分にメスが入りつつありますが、米国に比べるとまだまだ遅れは大きい状況ではないかと思います。実際、日本ではテスターの人数や品質評価作業の工数が削られがちで、例えばテスト工数の削減となると、すぐさま「ツールによる自動化」に飛びついて解決を図ろうとする安直な考え方が目立ちます。テスト工数を削減する際には、まず テスト実施計画の最適化やテストケース設計の見直しを行うべきなのですが、このような考え方では、せっかくツールがあってもそれを使いこなしたり生かしたりすることは難しいでしょう。

こうしたことから、今のシステム開発の世界においてテスターの専門家を目指そうとするのは、日本の場合、かなり茨の道になる可能性もあります。しかしその一方で、今後さらに重要性を帯びてくる領域でもあるため、この分野のスキルを伸ばしておくことは非常に重要になってくると思います（実際、この領域に関する問い合わせはここ最近非常に増えてきています）。この分野のスキルを伸ばそうとする場合には、まず正しいテストの考え方を理解すること、そしてテストケース設計やテスト実施に関するノウハウを身に着けていくことが大切です。テストツールを使った自動化などは最後に学ぶべきことで、確たる知識ベースラインに基づいて学習しないと、ツールに振り回されることになるため注意が必要です。最終的には、テスト実施計画、テストケース設計、テスト結果分析を通して、システムの品質を可視化・定量化できるようになることがテスターとしてのゴールです。

［⑤ プロジェクトマネージャー（プロジェクトマネジメント）について］

プロジェクトマネジメントを取り巻く環境については、ここ 10 年で大きく変化しました。特に大きいのは、PMBOK のようなプロジェクトマネジメントに対する知識体系の整理や、Team Foundation Server （TFS）に代表されるような、高度なプロジェクト管理システムが安価・容易に入手できるようになったことだと思います。後者は非常に重要で、従来、「プロジェクト管理のため」に行われていた手作業の報告作業や集計作業が、一部とはいえ自動化できるようになったところは非常に大きいと思います。Agile 型（XP, RUP, Scrum など）のような開発プロセスであっても数値ベースでプロジェクトを管理できるようになったのは、こうした開発管理システムがあったからこそ、ではないかと思います。

しかしその一方で、プロジェクト管理においてプロジェクトを数値ベースで管理できるようにすること、すなわちプロジェクトの「見える化」をするためには、それ相応の「仕掛け」が必要になります。つまり、プロジェクトメンバに、「データ収集を意識させない」仕組みを作り、日常作業を普通にこなしているだけでデータが収集されるような仕組みを組み立てておく必要があります。そのために、プロジェクトマネージャは以下のような仕組みを組み立て上げておかなければなりません。

プロジェクトマネジメントの世界では、コミュニケーションスキルに代表されるようなスキルが重要視されます。こうした部分のスキルロードマップの考え方については、PMBOK やそれに関連する部分で十分に体系化されていると思いますのでここでは述べませんが、実務レベルで見た場合、上記のような「プロジェクトマネジメントのために必要なプロジェクトの計測手法」を考え出し、「プロジェクト状況の計測システム」を作り込むことも重要です。実際のシステム構築は、アーキテクトやデベロッパーの手を借りながら進めることになりますが、こうした作業が必要であることも、ぜひ意識していただければと思います。

［T 字型スキルの必要性と重要性］

なお、ここまで話を簡単にするために、5 つの開発系エンジニアのスキルを完全に個別にものとして紹介してきましたが、実際にはこの 5 つのスキルエリアは排他なものではなく、どちらかというと、どこかに高い専門性を持ちつつも、他のスキルエリアについてもある程度は広く知っているようにするべきものだと思います（いわゆる「T 字型スキル」と呼ばれるもの）。私自身は、②のアーキテクトとしてのスキルをメインとしながら、③ デベロッパースキルや④ テスタースキルもある程度掛け持ちしている、という感じですが、例えば SIer の人であれば、①④⑤あたりの掛け持ちが必要になってくるのではないかと思います。どんなスキルがどの程度求められるのかは、プロジェクト規模や企業規模などによって随分状況が異なると思いますが、こうした考え方のフレームワークを持っていると、何かと考えやすいのではないかと思います。

［キャリアパスとしての技術系コンサルタント］

さて、ここまで開発系エンジニアのタイプとそれぞれのスキルロードマップについて解説してきましたが、それとは別にひとつ、悩ましい課題について考えておく必要があります。それは、企業の中でのキャリアパスの問題です。

Part 1. のエントリの中でも触れたことですが、日本企業の場合、開発系エンジニアには、ひとつのロードマップ（＝ひとつのキャリアパス）しか与えられていないことがしばしばあります。専門職としてのキャリアはある程度のところで頭打ちとなり、それ以上に昇級していきたければ、管理職（マネジメント）になるしかない……といったような企業は、残念ながら日本の場合は少なくないと思います。これに対して外資系の企業、例えばマイクロソフトなどでは、（製品を作る会社だからという理由も大きいのでしょうが）エンジニアとして高いレベルまで昇級していくことが可能になっており、例えば私自身、自分のマネージャよりも自分の方が（年齢も若いのに）職位が高いという逆転現象を起こしたこともありました。要するに、専門職には専門職のキャリアパスが、管理職（ピープルマネージャ）には管理職のキャリアパスが用意されているということであり、管理職の方が専門職よりも必ず偉いという仕組みにはなっていません。無論、そうした上級専門職の人には、給料に見合った高いアウトプットを出すことが求められるので非常に大変ではあるのですが；、少なくとも制度として、専門職の職位に関して上限（キャップ）が低く設定されているようなことはないわけです。日本企業でも、ハイスキルな人材の流出を防ぎ、社内にキープできるようにするよう、専門職でありながら管理職と同等、あるいはそれ以上の職位を設けるといった動きが出てきてはいるものの、こうした動きはまだまだ全体としては少ない状況だと思います。日本だと、現実にはもっと基本的なこととして、年功序列制度が色濃く残っているようなケースの方が多いのではないでしょうか？

年功序列制度や、専門職・管理職の上下関係などについては、当然、良い面・悪い面があり、是非や功罪を一側面的に論じられるものではないのでここでは立ち入りませんが、ある個人として会社を見た場合、人によってはこうした仕組みが足かせのように感じられるケースはあると思います。開発系エンジニアとしてのスキルを思いっきり伸ばしたいとか、あるいはまだまだ専門職で自分の力を伸ばしていきたいとか、そういった人たちにとって、こうした仕組みはもしかしたら邪魔に感じられるかもしれません。このような場合には、状況によっては、社外へ転職する（技術系コンサルタントへの転職）というのも、キャリアパスのひとつの選択肢として考えるべきだと私は思います。社外に出ることによって得られる経験や知見は、それはそれで高い価値があるからです。

その一方で、安易な考え方（例えば今の会社がイヤだとか上司とそりが合わないとか；）で社外への転職を考えることは、あまりお奨めできません。私自身、マイクロソフトのコンサルタントになるにはどうすればいいんですか？ といった相談を受けることがあります。これは別にマイクロソフトの技術コンサルタントに限った話ではないのだと思いますが、外資系企業の技術系コンサルタントを目指そうとする場合には、① 技術力がちゃんとあって、② その技術力を現場で駆使して、③ それを他の人に伝えていける、という高いベースラインスキルを持っているだけではなく、さらに厳しい環境に身を置く覚悟が必要とされるからです。後ろ向きな気持ちではなく、前向きな気持ちで「もっと上を目指したい！」と意欲的に考えられるときに、ひとつの候補として挙げられるものではないかと思います。

実は私が所属しているコンサルティングサービス統括本部では、現在、開発系コンサルタントの募集を行っていて、採用枠もあるのですが、こういうものを見ても、なかなか怖くて食指が動かなかったり、あるいは逆に安易な気持ちや後ろ向きな気持ちで応募したりすることが現実的には多いのではないかと思います。しかしどちらのケースも、応募する側・される側両方にとって不幸なことだと思います。いきなり応募！の前に、もうちょっとカジュアルに、自分のキャリアのことを考えたり、仕事の実情を知ることはとても大切なことです。今回、そんな話を人事の担当者と話したら、だったら小さめのカジュアルなセミナーを開いてみては？ という話をもらいました。マイクロソフトのコンサルタントという職種に興味はあるんだけど、自分が応募すべきかどうかが分からない、そもそもコンサルタントってどんな仕事をしてい���んだろう？ といった興味を持っている方向けにセミナーを開いてみたいと思いますので、よかったらこちらのページから応募してみてください。（万が一好評だったらリピート開催してみようかと思います。すでにセミナーが終わっていたら、私にメールで個別にコンタクトしてみてください^^。）

＃ ちなみに同様の話として、女性のエンジニアとしてのキャリアについて悩んでいる方もいるかと思います。
＃ そういった方には、女性向けのセミナーもあるそうなので、よかったら参加してみてください。何かヒントが得られるかもしれません。

実際に社外に応募する・しないにかかわらず、そうした職種の選択肢の存在を知っておくことも大切ではないかと思います。エンジニアとしてのキャリアに迷われている方や、技術系コンサルタントという職種に興味のある方は、参加してみていただければと思います。

［まとめ］

というわけでいろいろと説明してきましたが、要点をまとめると以下のようになります。

• 昨今の開発技術の深化により、ブルーカラー的な単純労働は非常に少なくなってきている。
• スキルの高い人でないと、Visual Studio などの高い開発生産性ツールの良さを十分に引き出すことができない。
• このため、デベロッパーは自分たちのスキルを維持・向上させることが極めて重要。
• 直接、内部設計や実装などを行わない SIer においても、やはりテクニカルスキルは重要である。
• プロジェクト管理やチームリードなどの「単価の高い」業務へのリソース集中は重要だが、やりすぎるとコアコンピテンスを失う。
• コアコンピテンスを維持するためにも、ベースラインスキルを維持すること（日々の基礎トレ）は欠かしてはならない。
• スキル強化を考える場合には、座学（トレーニング）と OJT のバランスを意識する。
• 基礎学力を応用問題（OJT）だけで身に着けるのは効率が悪すぎる。
• 基礎学力なしで応用問題（OJT）を学ぼうとすると、場当たり的・その場しのぎのパッチ的な解決策に走りやすくなる。
• 開発系エンジニアのスキルを考える場合には、5 つの専門分野に分けて捉えると分かりやすい。
• 業務 SE（要件定義や業務設計を担当）
• アーキテクト（方式設計などの設計・実装標準化を担当）
• デベロッパー（内部設計や実装を担当）
• テスター（テストと品質評価を担当）
• プロジェクトマネージャ（プロジェクト管理を担当）
• スキルアップを考える場合には、自分がどの専門分野を特に得意とするのか、どこを特に伸ばしたいのかを意識するとよい。

会社にとって、社員の市場価値を守ることは会社の価値を守るために必要ですが、だからといって個々人が自分の市場価値を守ることを会社にまかせっきりにしてはいけない、と私は思います。自分の市場価値を維持し向上していくことは、基本的には自分の責任、ではないでしょうか？ この話は正解や結論のない話ではありますが、本エントリが、ご自身のスキルや市場価値、キャリアなどに悩まれている方の、何らかのヒントになることを願っています。