予測: クラウド

  • [アーティクル]

Windows Azure を使い始める 5 つの理由

Joseph Fultz

 

Joseph Fultz最近はどちらを向いても、クラウドの話を耳にします。クラウドは Web の進化を示す大きな一歩で、アプリケーションの開発、配置、管理のあり方を変えるといわれています。しかし、実際にクラウドを応用する方法をだれもが見つけ出しているわけではありません。これは、特に、インフラストラクチャが中～大規模で、使用率が比較的一定の組織に当てはまります。このような組織では、クラウドの運用コストを考えると、ソフトウェアを資産として保持する方が得策です。インフラストラクチャの規模が小さいか、使用率が大きく変動する環境では、考えるまでもなくクラウド (Windows Azure) に軍配が上がります。また、開発環境を運用することが連邦議会に議案を提出するかのように手続きが複雑な組織では、Windows Azure を利用することで、高速のプロトタイピングが可能なすばらしいプラットフォームが手に入ります。

今回は、思わず MSDN Magazine を脇に置き、Windows Azure を使い始めたくなるような、Windows Azure の特徴をいくつか紹介します。

すばらしいツールとの統合

Windows Azure 開発に向けて、ツールの提供や Visual Studio との統合が既に高いレベルで実現されていますが、この傾向はさらに急速に進み、非常にすばらしいレベルに向かっています。最新のツール セットについては、Windows Azure デベロッパー センター (bit.ly/xh1CAE) を参照してください。

図 1 に示すように、新しいプロジェクトに使用するロールの種類と言語を選択できます。どのロールや言語を選んでも、このツール統合をすぐに利用できます。筆者の経験では、開発エミュレーター、ランタイム デバッグ、および統合開発の 3 機能が、最も役に立つと思います。


図 1 新しいプロジェクトの作成

Windows Azure 開発環境は、配置前に、開発コンピューター上でアプリケーションの実行やデバッグを簡単に実行できる 2 種類のエミュレーターで構成されています (図 2 参照)。Windows Azure Compute Emulator を使用すると、テストおよびデバッグの目的で、サービスをローカルに実行できます。Storage Emulator では、ストレージをローカルにテストできます。

The Windows Azure Compute Emulator and Storage Emulator Running
図 2 実行中の Windows Azure Compute Emulator と Storage Emulator

ステージング環境または運用環境に配置できる状態になったら、右クリックにより簡単に配置を実行できます。これらのツールによって、ソリューション内のロールのパッケージ化、移動、および配置も処理でき、進行状況が Visual Studio によってレポートされます (図 3 参照)。

Deployment Progress for Windows Azure as Reported Back Through Visual Studio
図 3 Visual Studio によってレポートされた Windows Azure 配置の進行状況

Windows Azure の初期の大きな問題の 1 つは、ローカルではまったく問題なく実行できるのに、配置すると実行できなくなったり、パフォーマンスが非常に低下する可能性があったことです。さいわい、IntelliTrace とプロファイリングが導入されたことで、このような問題は緩和されました。これらの機能は、ソリューションの公開時に有効にできます (図 4 参照)。


図 4 Windows Azure の IntelliTrace とプロファイリングの設定

再現が難しいエラーや、運用環境でしか発生しないように思えるエラーのデバッグには、IntelliTrace ほど有効なものはありません。IntelliTrace は、基本的に、アプリケーションの実行状況を記録し、それを再生できるようにする機能です。たとえば、IntelliTrace を有効にしてロールを配置したら、IntelliTrace のログを参照して、正確にいつ何が起きたかを細かく確認できます (図 5 参照)。


図 5 Visual Studio の IntelliTrace による Windows Azure のデバッグ

スレッドにステップ インしたら、既存のコードをウォークスルーして、実行中に何が変化しているかを確認できます。サイトにバグがなくなり (または、可能な限りバグがなくなり)、パフォーマンスの問題の検出に取り組む準備ができたら、IntelliTrace を無効にし、プロファイリングを有効にします。図 4 からわかるように、実行するプロファイルの種類を選択できます。たとえば、個々のメソッドでの呼び出し時間を知りたい場合は、[インストルメンテーション] を選択します。この方法では、対象を限定した分析や、入出力パフォーマンスの問題の分析に役立つ、詳細なタイミング データが収集されます。コードの任意のセクションについての詳細なタイミング情報を収集したり、アプリケーションのパフォーマンスへの入出力操作の影響を把握したりするのに役立ちます。その後、必要なだけコード ベースを実行して、サイトをウォークスルーします。十分ウォークスルーできたら、[プロファイル レポートの表示] をクリックして、サーバー エクスプローラーでインスタンスを確認します。Visual Studio によって情報が取得され、図 6 のようなレポートにまとめられます。


図 6 プロファイル レポート

このレポートには、 CPU の使用率が時系列で示されるほか、"ホット パス" も表示されます。ホット パスを参照するだけでも、取り組む対象を絞り込める可能性があります。ただし、もう少し詳しく調べたい場合は、[ホット パス] のセクション内のダイレクト リンクを使用して、関数ごとにタイミングを確認します。メイン ページには、個別作業が一番多い関数を示す便利なグラフも表示されます。Visual Studio から直接 IntelliTrace とプロファイルを利用できると、生産性の面だけでなく、製品の品質の面でも、非常に大きなメリットがあることは明らかです。

また、JavaScript、PHP、または Java で作業をしている場合は蚊帳の外で、Windows Azure プラットフォームへのアクセスを独自に用意しなければならないということはありません。マイクロソフトは、これらの言語すべてについて、SDK やリソースを提供しています (bit.ly/uGqPNh)。

パフォーマンスとスケール

この数年間はたいして動向に注意を払っていなかったとしても、クラウドが提供する重要なメリットの 1 つは、オンデマンドでスケールを変更できることです。コンピューティング仮想マシン (VM) については、多くの場合、料金を上乗せして上位のロールを契約するだけで、より多くのリソースを利用できます。ただし、Microsoft SQL Azure の場合はそれだけでなく、この最適化には、もう少し "手間" がかかります。

クラウドに配置することで、ファームのスケールを変更できるようになるのは嬉しいことですが、「必要なサイズ ロールはどれか」ということが、より差し迫った問題になることが多くあります。この答えは、トラフィックと実行する作業によって決まります。過去の経験と、ロール サイズの仕様 (図 7 参照) を基に、知識に基づいた推測が可能です。

図 7 仮想マシン サイズの仕様

仮想マシン サイズ CPU コア数 メモリ Web ロールとワーカー ロールのローカル記憶域リソースのディスク領域 VM ロールのローカル記憶域リソースのディスク領域 帯域幅割り当て (Mbps)
Extra Small 共有 768 MB

19,480 MB

(6,144 MB はシステム ファイル用に予約)

 20 GB 5
Small 1 1.75 GB

229,400 MB

(6,144 MB はシステム ファイル用に予約)

 165 GB 100
Medium 2 3.5 GB

500,760 MB

(6,144 MB はシステム ファイル用に予約)

 340 GB 200
Large 4 7 GB

1,023,000 MB

(6,144 MB はシステム ファイル用に予約)

 850 GB 400
Extra Large 8 14 GB 2,087,960 MB (6,144 MB はシステム ファイル用に予約) 1,890 GB 800

特にファーム内の他のロール インスタンスと組み合わせると、上記の構成の 1 つが、おそらくニーズに合うでしょう。これは検討事項としては二の次にされることが多いですが、利用可能なネットワーク帯域幅を含め、どの属性も増加することに注意してください。また、推測することも必要ではありません。前述のとおり、プロファイルを有効にして、インスタンス全体の実際のメトリックスを収集し、パフォーマンスを評価できます。プロファイルの結果を基に VM のサイズを調整して、再びプロファイル情報を収集するという作業を繰り返し、最適なサイズを特定します。競争力のある環境になるよう、最も適したオプションを選ぶか、代わりのソリューションを探します。たとえば、サイトのコンテンツの量が多く、あまり動的でない場合は、上位のロール仕様の 1 つを選ぶか、Windows Azure Content Delivery Network に移行します。

さて、ここで、いくつか良いニュースと悪いニュースがあります。SQL Azure では、ユーザー独自のプライベート インスタンスと同程度のパフォーマンスが得られるとは限りません。ただし、一定したパフォーマンスは得られます。可能な限り最高のパフォーマンスと実行時の動作を得るには、いくつか対策をとることができます。

  1. コンピューティングを行うデータセンターに SQL Azure を配置します。
  2. 実行するクエリに合わせて、クエリとデータ構造を最適化します。
  3. 再試行ロジックは手抜きをせず、必ずコードに再試行ロジックを実装し、テストします。
  4. 手順 2. を繰り返します。

長年目にしてきた、サイトを最適化する際に人々が犯す最大の誤りの 1 つは、ハードウェアのサイズを大きくするだけで、それ以外は何もしないことです。これが多少は功を奏する場合がありますが、本当に負荷が高くなった途端に、それまで以上に厄介な症状を伴って問題が再発します。性能が上がったことで、さらに短時間で競合が起きやすくなり、実際には真の問題を解決も緩和もしていません。ですから、手順 2. を繰り返すように書いているのは、大真面目な話です。この問題に対してさらにハードウェアを単純に追加して、問題が行き詰まらないように願うことはできません。このような状況に対処するには、SQL Azure Profiler ツールが役立ちます。クラウドへの配置に先立ってローカル インスタンスの最適化を始め、その後、SQL Azure Profiler を使って、クラウドへの配置後に必要な調整を特定および実行できます。

最後に、スケールの拡張や SQL Azure データベースのサイズ増大の戦略の 1 つに、フェデレーションがあります。これは、一般に "データ シャーディング" と呼ばれ、複数の物理サーバーにまたがってデータを水平方向にパーティション分割することで、アプリケーションをスケールアウトする手法です。これにより、各クエリ時間が短縮されますが、ターゲット インスタンスにクエリを分散して送り、クエリの処理が完了したら、結果を収集する必要があるため、複雑さは増します。たとえば、読み取り、更新、削除 (CRUD: Create、Read、Update、Delete) 操作と小さなデータセットを並列処理するメリットが得られます。その代償としてに、アクセスを調整してすべてのシャードに分散させる必要があります。それでも、最大規模のサイトの中には、シャーディングを採用し、プリフェッチとキャッシュを使ってクエリを管理しているものがあり、ユーザーは、このようなサイトを日々、特にパフォーマンスについて不満に感じることもなく使用しています。

管理しやすいインフラストラクチャ

以前は、Windows Azure 配置内で実行されている処理を簡単に把握できない場合もありましたが、そのような時代はとうの昔に終わりました。マイクロソフトから、進化を続ける管理ポータルが提供されているだけでなく、System Center Operations Manager (SCOM) の管理パックによって、インフラストラクチャ全体を一元的に管理できます。

Windows Azure は、すべての診断データを、ストレージ コンテナーに書き出します。ログを直接使用して、レポートを生成したり、カスタム操作を実行できます。ただし、Windows Azure アプリケーションの監視にも SCOM を使用することができます。企業のインフラストラクチャの管理担当者は保守的で、あらゆる機能を備えたツールを監視に使おうとする傾向があります。SCOM のようななじみのあるソリューションを使うことは、クラウドソリューションの配置に対してインフラストラクチャ管理チームが抱いているに違いない抵抗感の解消に役立つでしょう。SCOM を使うと、すべての Windows Azure 配置の正常性を監視でき、ホステッド サービス、ロール、およびロール インスタンスにドリルダウンできます。管理パックにはサービスおよびパフォーマンス用の通知が組み込まれていますが、重要なメリットの 1 つは、配置およびデータ収集に関して、独自のルールと通知を作成できることです。さらに便利なのは、ログの整理に使用できるルールが組み込まれていることです。もちろん、ログのデータは途中で整理しないと、管理できないほどログが大きくなる可能性はあります。それに対処するため、管理パックには定義済みのルールが組み込まれています。

• .NET Trace Grooming (.NET トレースのクリーンアップ)

• Performance Counter Grooming (パフォーマンス カウンターのクリーンアップ)

• Event Log Grooming (イベント ログのクリーンアップ)

これらを有効にして、領域の使用量を管理可能な範囲に抑えることができますが、タスクを実行するトランザクションの数を踏まえ、バランスを考える必要があります。System Center Monitoring Pack for Windows Azure Applications は bit.ly/o5MW4a (英語) からダウンロードできます。

コードを既に記述しているも同然

新しいテクノロジが登場すると、かなりのトレーニングを受け、経験を積まないと、使いこなせないことが非常に多くあります。たとえば、Windows フォームから Windows Presentation Foundation や Silverlight に移行する場面や、ASP.NET か SharePoint、さらには手続き型とオブジェクト指向開発など、もっと基本的なテクノロジについてどちらを使用すべきかを選択する場面を考えてみてください。特にツールを利用できるクラウドの場合に、このことが言えます。既にサイトやサービスを作成している場合、.NET のスキルと投資をできるだけ無駄にすることなく、そのままクラウドに移行できます。

これは、学ぶべきベスト プラクティスがないということではなく、設計や開発を完了するために既に実行していることと大きくかけ離れてはいないということです。また、プラットフォームには、必要に応じて学習できる追加の機能が多数あります。これらの機能を利用することで、ソリューションを安全で堅牢なものにし、機能やフレームワークを手動で作成しなくても最高のパフォーマンスを実現できます。

クラウドは未来

すぐに始めてください。それが今回のアドバイスです。azure.com にアクセスし、ツールをダウンロードして、始めてください。プロジェクトで Windows Azure を使用して、プロトタイプを作成してください。Windows Azure をプロジェクトで使用して、Windows Azure を使用しなければ得難いリソースを提供してください。用途は何であれ、とにかく Windows Azure を使ってください。クラウドは、私たちすべてが生きる未来であり、水や電気のようにどこからでも利用できるようになるでしょう。クラウド テクノロジは、従来の形から、必要な場所で、必要なときに、必要な方法でコンピューティング機能を提供するモデルへと、コンピューティングのあり方を拡大するべく、進化を続けています。ぜひこの世界に足を踏み入れることをお勧めします。

Joseph Fultz は、Hewlett-Packard Co. のソフトウェア アーキテクトで、HP.com Global IT グループの一員として仕事をしています。以前は、マイクロソフトのソフトウェア アーキテクトとして、一流企業や ISV の顧客のためにアーキテクチャの定義とソリューション設計を行っていました。

この記事のレビューに協力してくれた技術スタッフの Bruno Terkaly に心より感謝いたします。