特集：事例で学ぶWindows Azure実用ポイント 業務システムでWindows Azureを使うための42の覚え書き シグマコンサルティング　橋本 圭一 2010/02/23
Page1 Page2 Page3 Page4

■3. Windows Azureでハマらないために…42の覚え書き

　筆者が今回の事例となったシステムを構築する際に、時間を割いてWindows Azureに対して行った調査や対応で得られた情報を共有させていただく。これによって、皆さんの調査時間の削減と、Windows Azureを利用した事例が増えることを願っている。

●構成と課金

◇1：Windows Azureインスタンス（コンピュート・サービス）の課金対象

　Windows Azure上にクラウド・サービスがデプロイ（Deploy：配置）された段階から課金が始まる。つまり、実行（Run）していなくても課金対象になるので注意してほしい。例えば、下の画面は、クラウド・サービスはデプロイされているが、停止されている（Stopped）状態である。この状態でも課金される。

デプロイされているが実行されていない状態でも課金対象

◇2：稼働時間の節約

　夜間など稼働させる必要がない時間帯は停止して課金対象になる時間を減らしたい場合に、それを自動化するには、

「稼働停止の時間には、実行（Run）→一時停止（Suspend）→削除（Delete）を順に実行して、デプロイされているクラウド・サービスを削除し、稼働開始の時間になる前に、デプロイ（Deploy）→実行（Run）の順に実行して、再びクラウド・サービスをデプロイして実行する」

というような対応が必要となる（これにはPowerShellで対応できる。詳細は後述の「◇18：リモート管理」で紹介する）。

◇3：本番環境（Production）とステージング環境（Staging）は別途課金

　管理画面の構成から、「本番環境（Production）とステージング環境（Staging）は2つで1つの環境」という印象を受けないこともないが、両者は異なるインスタンス（課金対象）という扱いになる。例えば次の画面では、本番環境（Production）とステージング環境（Staging）の両方で課金される。

本番環境（Production）とステージング環境（Staging）はそれぞれが課金対象

◇4：サードパーティ製コンポーネントのライセンス費用

　本番環境（Production）とステージング環境（Staging）はそれぞれ別のインスタンスであるため、サードパーティ製コンポーネントのライセンスがサーバ単位で課される場合に、どちらもライセンス費用が必要となる可能性がある（また、稼働させるインスタンスの数によっても、ライセンス費用が変わってくる可能性もある）。Windows Azure上のライセンス形態はコンポーネント・ベンダによって異なるので、該当のコンポーネント・ベンダに直接、確認していただきたい。

◇5：テスト用環境を用意するかの検討

　SQL Azureについても、ストレージについても、本番以外にテスト用のデータベース／ストレージ環境が必要であれば別途契約する必要がある。要件や予算によって対応が変わるだろうが、例えばテスト用のデータベース環境を用意する必要があるかないかで、全体的な構成内容とそれに対する課金は下記のように違ってくる。

• テスト用のデータベース環境を用意する場合（SQL Azure利用）：

Windows Azureコンピュート・インスタンス：2台、SQL Azureデータベース：2台の構成

• テスト用のストレージ環境を用意する場合（ストレージのテーブルとブロブ利用）：

Windows Azureコンピュート・インスタンス：2台の構成

• 弊社事例（Tiamat）での運用：

Windows Azureコンピュート・インスタンス：1台（一時的に2台）、SQL Azureデータベース：1台の構成

　基本的に本番環境（Production）のみ稼働させている。よってSQL Azureデータベースも1契約である。新しいバージョンをリリースする場合のみ、ステージング環境（Staging）にクラウド・サービスをデプロイし、動作を確認して問題がなければ本番環境（Production）と交換する（※この場合、SQL Azureデータベースは本番環境に1つしかないため、オンプレミスに同等のデータベース環境を用意して、そこでデータベース関連の動作確認を行っている）。

◇6：支払い時のアカウントの使い分け

　Windows Azure Platformの各種サービス（※従量課金やサブスクリプションなど）の購入手続きの中で、支払いを行う「アカウント所有者」と、実際にサービスを作成・管理する「サービス管理者」を設けることができる。よって、アカウント所有者に支払いをまとめ、サービス管理者はそれぞれ別の担当を立てるといったことが可能である。具体的にこれらの設定は、Microsoft Online Servicesカスタマー・ポータルで行える。次の画面は、弊社のアカウント所有者とサービス管理者の設定例だ。

Microsoft Online Servicesにおけるアカウント所有者とサービス管理者の設定例

◇7：請求書払い

　Windows Azure Platformのサブスクリプション・サービスの（※現在、期間限定の開発促進キャンペーン（Development Accelerator）のCoreプランやExtendedプランとして大幅な割引が行われている）を複数購入して月間250米ドル相当以上になると、請求書払いが可能になる。

●デプロイ

◇8：アプリケーションの起動失敗とその解決方法

　デプロイされたクラウド・サービスを実行（Run）すると、ロール・インスタンスの起動までに5〜15分ほど待つことになる。これだけ長いと普通はほかの作業を行いながら結果を待つことになると思うが、見ていない間に、［Initializing］（初期化中）→［Busy］（ビジー状態）→［Stopping］（停止中）を繰り返している場合がある。この場合は、アプリケーション（以下、アプリ）の起動時に障害が発生している可能性が高い。

　このようなアプリ起動時のエラーは、新しい参照や機能の追加を行った際に発生しやすい。よって、開発中にWindows Azureへのデプロイ検証用の簡易なアプリを、機能別に用意しておいた方がよい。例えば、下記の4種類を順番にデプロイして、それぞれで動作を確認・検証することによって、「何が問題となっているか」の切り分けが行える。

（1）Hello Worldアプリ
（2）データベースへのアクセス処理アプリ
（3）ストレージへのアクセス処理アプリ
（4）外部コンポーネント（Silverlightなど）を含むHello Worldアプリ

　このほかに、Web.configファイルに不要なアセンブリの読み込みや不要なセクションがないかなどを確認するとよい。

◇9：外部アセンブリはすべてローカル・コピー

　.NET Framework 3.5 SP1の基本クラス・ライブラリに含まれない外部アセンブリ（.DLLファイル）を参照・使用する場合（例えばサードパーティ製コンポーネントを使用する場合など）、Windows Azure上にデプロイする際にその.DLLファイルもコピーする必要がある。これには、［ソリューション エクスプローラ］で［参照設定］しているアセンブリ項目を選択して、［プロパティ］ウィンドウで［ローカル コピー］を「True」に設定する必要がある。

◇10：デプロイするパッケージの中身は確認できる

　.DLLファイルのローカル・コピーの設定をし忘れるなどして、デプロイ後に起動できない場合がある。このような場合には、発行済みのパッケージの中身を参照して、その.DLLファイルが含まれているかどうかを確かめるとよい。パッケージの内容はWindowsエクスプローラで簡単に参照できる。

　具体的には、クラウド・サービスのパッケージを発行した後に、「Publish」フォルダが自動的にWindowsエクスプローラで開かれる。その「Publish」フォルダの1つ上の階層に「＜プロジェクト名＞.csx」フォルダが存在し、その中にパッケージの内容が存在する。ここで、想定している.DLLファイルが正しく含まれているかなどを確認できる。

　次の画面は、「Publish」フォルダの1つ上の階層をWindowsエクスプローラで開いているところだ。

「Publish」フォルダの1つ上の階層をWindowsエクスプローラで開いているところ

INDEX
	特集：事例で学ぶWindows Azure実用ポイント
	業務システムでWindows Azureを使うための42の覚え書き
	1．一般的なクラウドのメリットとデメリット／事例の紹介
	2．42の覚え書き：構成と課金／デプロイ
	3．42の覚え書き：ログなどの環境依存の機能
	4．42の覚え書き：SQL Azure／システム移行時の注意点／そのほか

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）