Windows Azure の Technical Evangelist Team 紹介～ クラウドカバー Episode 76
今回のクラウドカバー「Episode 76 - Meet our new additions to the Windows Azure Technical Evangelist Team」は、マイクロソフト本社の Windows Azure の Technical Evangelist チームに最近加入してきたメンバー紹介です。
えーっと、技術ネタはあまりありませんので、さくっと行きます。
まずはいつものようにニュースから。
◆ Announcing New Datacenter Options for Windows Azure
最初のニュースは、北米における新しいデータセンター２か所のオープンのお知らせ。
「West US」と「East US」が加わり、コンピューティング サービスと、ストレージサービスにおいて、このデータセンター選択ができるようになっています。
また、SQL Azure に関しては、もうしばらく後、追加予定で、そのあたりに依存しているということで Service Bus などのサービスも SQL Azure の提供開始後に追加される予定です。
◆ Windows Azure Trust Center Launched
Windows Azure におけるセキュリティや、アプリケーション開発におけるセキュリティ上のプラクティスなどの情報を集めた “Trust Center” という Web ページが Windows Azure のホームページおいて追加されています。
現在は英語のみの情報提供となっています。日本語での情報提供開始はもうしばらくお待ちください。
◆ Announcing the refresh of the Service Bus EAI and EDI Labs
Service Bus の新機能として、EAI(Enterprise Application Integration)と EDI(Electronic Data Interchange) 機能がプレビューとして公開されています。
この機能には、オンプレミスの SQL Server や Oracle データベース、SAP や Siebel eBusiness Application といった LOB システムとの連結のためのコネクター(Service Bus Connect)が用意されているほか、システム間のメッセージ連携を行う際にメッセージ内容の検証や変換を行うといったことが可能です(Message Processing Bridge)。
ということで、ここからが本日の本題のエバンジェリスト紹介。
一人目の Haishi Bai は中国出身で、Y2K に関わったあたりから e-Business や Web、Windows Client、あるいは Identity 周りのプロジェクトに加わり、その後 Microsoft に加わったそうです。
Service Bus や ACS に関しては、例えば Service Bus において読み取り専用のアカウントを用意するための方法を書いた「Window Azure Service Bus: Use read-only credentials for your Service Bus clients 」などのエントリがあるようです。
お次は、元カナダの MVP であった Cory Fowler。
Microsoft には最近入社したという事で、それまではコンサルタントとして様々なプロジェクトに関わってきており、その中で Azure に関しても技術スキルを蓄積したそうです。Microsoft ではオープンソース系で、PHP や、node.js 周りを担当したいねー、ということです。
続く３人目は、San Diego からリモート（オンライン）で Cloud Cover に参加の Jon Galloway。
Web 系で 15年の経験があり、OSS にも関わってきたという事。
Microsoft に入社して２年という事で、イベントでのスピーカーや、テクニカル ドキュメントの作成などに関わってきたという事で、今後は APS.NET 系のスキルを活かして Windows Azure の技術訴求に関わるという事です。
最後に登場したのは Brady Gaster。
Microsoft に入社したのは４か月前で、３カ月のリモートでの仕事を経て、現在は Redmond で勤務中という事で、入社前には .net 系のコンサルタントをしていたという事で Codemash で行った SignalR のセッションは人気だったようです。
という事で、Windows Azure の Technical Evangelist の紹介は終了。
さっくりと Tip of the Week へ！
今回の Tip of the Week は、Windows Azure における Async および Parallel プログラミングにおけるパフォーマンスのブログ エントリの紹介です。
このエントリでは、Windows Azure において VM サイズと非同期プログラミングのパターン選択により、どのようなパフォーマンス変化があるかをテストしています。
ちなみに、パフォーマンステストのサンプルとして用いたのは、エンロン社の e-mail データ。エンロン社は米国において電力自由化のシンボル的企業で、2001年には粉飾決算で破たんしてしまうわけですが、前職でシリコンバレーに駐在していた際にはカルフォルニアの大停電があったりと、いろいろな思い出があり、なんだか胸があったかくなります。てか、メール情報自体がオープンになっている（事件の検証という事なんでしょうか）あたりがすごいですね、米国。
っと、話はそれましたが、テスト前の予想では、CPUを共有で使用する Extra-Small とコア数としては１コアが割り当てられている Small では、Async を使ったプログラミングモデルが、コア数が複数割り当てられる Medium と Large では Parallel のプログラミングモデルが相対的に良い結果になるのでは、という予測でした。
実際の結果的には、どの VM サイズでも、Async と Parallel の違いはあまりなく、基本的には Async を利用したプログラミングが良い結果になりました。特にコア数が増えると Parallel なアプローチが有効になるのでは、という予測でしたが、Async のアプローチでも VM サイズ向上に伴う利得が得られたようです。
なお、今回のテストでは同時接続数を設定する ServicePointManager の値を 12 としています（デフォルトでは 2)。この値に関しては、Nathan いわく「コア数の 12倍がおススメの値」という事ですので、VM を挙げた際の結果に関しては、このあたりにも影響を受けている可能性があります。
また、今回のテスト結果は、今回のテスト内容に依存するものであり、一般的な Windows Azure における Async および Parallel のパフォーマンス全般に当てはまるものではないという事にご注意ください。このあたりは実際に利用するパターン（ワークロード）にあわせて、個別にテストいただくのが良いかと思います。
全体的な学びとしては、Windows Azure においても非同期なアプローチは有用である、という点で Async あるいは Parallel いずれのモデルを使用するにしても、スケーラビリティを考えた際に時間がかかりそうな I/O 操作には非同期アプローチを採用するのが良いですね。
ということで、クラウドカバー Episode 76、Windows Azure の Technical Evangelist Team の新メンバーの紹介、の簡単解説でした。
Enjoy!