• [アーティクル]

Windows Azure 用アプリケーション開発 Step-by-Step チュートリアル ガイド

第 3 章 Windows Azure 運用環境への展開 (3)

目次

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

‣ 3.5.1　インスタンス数の変更
‣ 3.5.2　クラウド サービスのパッケージングと Azure 上への配置
‣ 3.5.3　Windows Azure コンピュート サービスの動作確認

3.6　アプリケーションの修正と Azure 環境への再配置

‣ 3.6.1　開発用ファブリックと本番環境の相違点
‣ 3.6.2　アプリケーションの修正
‣ 3.6.3　アップグレード
‣ 3.6.4　解決されない問題
‣ 3.6.5　構成設定の変更
‣ 3.6.6　本番環境への展開
‣ 3.6.7　サービスの停止
‣ 3.6.8　アカウントの削除

 

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

最後に、コンピュート サービスを移行していきます。

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

3.5.1 インスタンス数の変更

まず、サーバーへのアップロードを行う前に、いったん仮想マシンのインスタンス数を 1 に減らしておきます。後で解説しますが、コンピュート サービスでは、利用した仮想マシンの台数分だけ課金が発生します。このため、最初の段階ではインスタンス数を 1 に減らして配置を行い、動作確認が取れてからインスタンス数を増やすのが鉄則になります。

ページのトップへ

3.5.2 クラウド サービスのパッケージングと Azure 上への配置

次にクラウド サービスを発行し、それを、Windows Azure 上へと配置する手順を説明します。

  1. クラウド サービス プロジェクトを右クリックして、[発行] をクリックしてください。
    • すると、サービス パッケージの作成 (パッケージング) のみか、Azure 上へのサービス パッケージの配置も行うか、聞かれます。
    • Visual Studio でパッケージングのみを行い、ポータルから手動でサービス パッケージを配置するということも可能です。
    • しかし今回は、Visual Studio でパッケージングと配置の両方を行う方法をとります。
      Note: Visual Studio から配置が行えるのは、Azure 開発ツールキットのバージョンが 1.2 からになっております。以前のバージョンを使用する場合には Visual Studio で発行を行い、ポータルから、手動で配置する必要があります。
  2. まず、[Deploy your Cloud Service to Windows Azure] を選択します。
  3. そして、[Credentials:] のドロップダウン リストから、<Add…> を選択します。
  4. [Cloud Service Management Authentication] の画面が表示されます。

    (図をクリックすると拡大図が表示されます)
    　
  5. [1. Create or select an existing certificate for authentication:] ドロップダウン リストで、先ほど作成した証明書を選択します。
  6. 次に、[3. Copy the subscription ID for your account from the Developer Portal:] のテキスト ボックスに、メモしておいた Subscription ID (ポータル サイト (https://windows.azure.com (英語)) からプロジェクトを選択し、[Account] タブから取得できます) を貼り付けます。
  7. そして、[Name these credential:] のテキスト ボックスに、適当な証明書の名前を付与し、[OK] ボタンをクリックします。
  8. すると、[Publish Cloud Service] 画面に戻ります。
  9. デプロイするサービス スロットとして Staging 環境を選択し、Storage Account を選択します。
  10. 最後に、ラベルにアプリケーションのバージョン番号 (ビルド番号) を付与し、 [OK] ボタンをクリックしてください。
    Note: 今回は 2010 年 7 月 1 日の最初のバージョンということで "1.0.00701.0" を付与します。管理上、わかりやすい名前を付与してください。デフォルトで付与されている名前をそのまま使っていただいても問題ありません。

すると、クラウド サービス (Web アプリケーション) が発行され、Azure 上に配置されます。その配置の進行状況や作業のログは、Visual Studio から確認することができます。


(図をクリックすると拡大図が表示されます)

ポータル サイトからも進行状況が変化していくのが確認できます。


(図をクリックすると拡大図が表示されます)

Visual Studio からは [Complete] と表示されたら、ポータル サイトからはステータスが Ready となったら、Azure 上への配置が終了となります。

以下では、パッケージングと配置の処理で、具体的にはどのようなことが行われているか解説します。

A. パッケージング

パッケージング処理により、Visual Studio から、以下 2 つのファイルが出力されます。

  1. サービス パッケージ ファイル (CloudService1.cspkg)
    • 実際の Web アプリケーションが含まれるパッケージ ファイルです。
  2. サービス構成設定ファイル (ServiceConfiguration.cscfg)
    • 配置後も変更可能な構成設定データが記述されたテキスト ファイル (XML ファイル) です。

B. 配置

配置では、以下 3 つの処理が行われます。

  1. コンピュート サービスのハードウェア インフラ上に、仮想マシンのイメージ (この例の場合には、Web ロールの VM イメージ) がコピーされる
  2. この仮想マシンに対して、指定した VM サイズのリソース (この場合には Small なので 1 個の CPU と 1.75 GB のメモリ) が割り当てられる
  3. この仮想マシンに、アップロードしたアプリケーション パッケージが配置され、実行される


(図をクリックすると拡大図が表示されます)

ページのトップへ

3.5.3 Windows Azure コンピュート サービスの動作確認

しばらくすると、コンピュート サービスが起動します。Staging 環境では、配置されたアプリケーションにダミーの URL が付与されます。画面上にある URL にアクセスして、Web アプリケーションの動作を確認してください。

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

A. 現在時刻の表示

表示されている時刻が、現在時刻とずれてしまっています。これは、コンピュート サービスのコンピューターが、UTC 時刻 (グリニッジ標準時) で動作しているためです。UTC と東京時刻には 9 時間の時差があるため、表示時刻は 9 時間ずれて表示されてしまいます。

B. コントロールの英語表記

GridView の [選択] ボタンが英語表記の "Select" となってしまっています。これは、コンピュート サービスのサーバー OS が、データ カルチャ、UI カルチャともに "en-us" (英語) で動作しているためです。このため、例えば int a = 30; というデータを通過表記すると、￥30 ではなく $30 となってしまいます。

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

ページのトップへ

3.6 アプリケーションの修正と Azure 環境への再配置

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

3.6.1 開発用ファブリックと本番環境の相違点

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

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

ページのトップへ

3.6.2 アプリケーションの修正

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

A. web.config ファイルへの、データ カルチャと UI カルチャの修正設定の追加

.NET ランタイムは、内部的に、データの国際化対応と UI メッセージの国際化対応の 2 つの機能を持っています。これらは、web.config ファイルで切り替えることが可能です。日本語圏と同じように動作させたければ、以下のように指定を行います。

<configuration>
   <system.web>
     <globalization culture="ja-jp" uiCulture="ja-jp" />
   </system.web>
</configuration>

B. アプリケーション中の時刻処理を、タイム ゾーンを意識したコードに変更

DateTime.Now プロパティによって取得される時刻は、Azure 環境では UTC 時刻となります。このため、日本の時刻を取得したい場合には、時差補正を行う必要があります。具体的には、以下のようにコードを修正してください。

// 従来であれば、以下のように実装していたコードを、
DateTime now = DateTime.Now;
// 以下のように修正します。
DateTime now = TimeZoneInfo.ConvertTimeBySystemTimeZoneId (DateTime.Now.ToUniversalTime (),"Tokyo Standard Time");

ページのトップへ

3.6.3 アップグレード

これらの修正を加えたら、Azure 上の Web アプリケーションをアップグレードします。アップグレードについては Visual Studio 2010 + Azure Tools 1.2 から直接操作できないため、Visual Studio からパッケージング作業を行い、ポータル サイトからアップグレードします。以下の手順でアップグレードしてください。

  1. まず、先ほどと同様に CloudService1 プロジェクトを右クリックし、[発行] を選択します。
  2. そして、発行のみを行う [Create Service Package Only] を選択し、[OK] をクリックしてください。
    • すると、Visual Studio から、サービス パッケージ ファイル (CloudService1.cspkg) とサービス構成ファイル (ServiceConfiguration.cscfg) が出力されます。
  3. 次に、ポータル サイトの Staging 環境の [Upgrade…] ボタンをクリックし、発行された 2 つのファイルをアップロードしてください。
    • 配置の際には、ラベルとして、先とは異なる名称を付与しておくとよいでしょう。その他の項目 (Operating System Settings など) は既定値のままで構いません。

ページのトップへ

3.6.4 解決されない問題

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

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

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

このため、今回の GridView の選択ボタンのようなものを日本語表記にしたい場合には、以下のように対応する必要があります。

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

少し面倒な作業ですが、現在の Azure プラットフォームの制約として覚えておく必要があります。

ページのトップへ

3.6.5 構成設定の変更

次に、ポータル サイトから構成設定を変更してみます。

  • ポータル サイト上で、[Configure…] ボタンをクリックしてください。
    ※ サービス構成設定ファイルを編集できます。
  • このファイルの中ほどに、<Instances count="1" /> という設定があるので、これを適宜増やします。
    ※ ここでは 3 にしてみることにします。
  • 修正後、"Save" ボタンをクリックしてください。
    ※ インスタンス数増加には多少時間がかかります。しばらくお待ちください。

しばらくすると、インスタンス数が 3 になります。

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


(図をクリックすると拡大図が表示されます)

ページのトップへ

3.6.6 本番環境への展開

最後に、いよいよこのアプリケーションを本番環境 ("Production") へと展開しましょう。このためには、ポータル サイトのスワップ機能 (入れ替え機能) を利用します。この画面の真ん中のボタンを押すと、2 つの環境が入れ替わり、運用環境にアプリケーションが配置されます。Staging 環境ではダミーの URL が付与されていますが、Production 環境に移すことにより、通常の URL (http://<アカウント名>.cloudapp.net) アドレスでアクセスすることができるようになります。

Staging 環境と Production 環境の入れ替えは、ロード バランサーのみで行われるため、すぐに終了します。

作業が終了したら、運用環境用の URL (http://<アカウント名>.cloudapp.net) にアクセスを行い、Web アプリケーションが動作することを確認してください。

ページのトップへ

3.6.7 サービスの停止

アプリケーションの動作を確認し、テストが完了したら、サービスを停止します。具体的には、Windows Azure ポータル サイトの画面内にて、以下の作業を行ってください。

  • ポータル サイト上の "Suspend" のボタンを押す。
  • さらに、ポータル サイト上の "Delete" のボタンを押す。

以上の作業により、コンピュート サービスが停止し、コンピュート サービスの利用にかかわる課金が停止します。注意すべき点として、アプリケーションを "Suspend" させるだけではコンピュート サービスの課金が停止しません。これは、Suspend 状態であっても、仮想マシンがリソースを占有し続けているためです。課金を停止させるために、利用が終了したら必ずサービスを "Delete" するようにしてください。

以上で、Windows Azure 上でのアプリケーション開発の演習は終了です。

ページのトップへ

3.6.8 アカウントの削除

Windows Azure のアカウントが今後もう必要ない、ということであれば、Windows Azure アカウントの削除を行ってください。アカウントを削除するには、Windows Azure のカスタマー サポートに電話し、削除してもらいます。

なお、課金状況は MOCP サイト (Microsoft Online Services Customer Portal サイト) から確認できます。課金情報はリアルタイムではなく遅れがあるため、注意してください。

MOCP サイト
https://mocp.microsoftonline.com/site/default.aspx

ページのトップへ