※ 本エントリは その 3 の続きです。（エントリが長すぎて投稿できなかったため分割しています）
［アプリケーションの修正と Azure 環境への再配置（アップグレード）］
さて、開発用ファブリックと Azure 本番環境では様々な相違点があります。Azure 本番環境で問題となりやすい制限事項としては、以下のようなものがあります。
この中でも、国際化対応に関連する問題はよくひっかかりやすいポイントになります。例えば、以下のような簡単な処理でも、Windows Azure 環境では、開発環境とは異なる動きをすることになります。
これらについては、基本的に以下の対策を行うとよいでしょう。
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 アプリケーションを再配置してみましょう。
以上の作業を行った上で、再度アプリケーションの動作確認をすると、以下のようになるはずです。
前者については問題ないと思いますが、後者については疑問を覚える方もいると思いますので、少し補足しておきます。一般に、GridView の選択ボタンの表記文字や、例外に含まれる詳細メッセージなどには、.NET Framework ランタイムの中に含まれる、日本語リソースファイルが使われています。しかし、現在の Windows Azure コンピュートサービスの環境には日本語のリソースファイルが含まれていません。<globalization> タグで uiCulture を “ja-jp” にしておくと、本来は日本語リソースファイルが利用されるようになるのですが、そもそもこのリソースファイルが Azure 上にインストールされていないため、英語メッセージになってしまう、ということになります。
このため、今回の GridView の選択ボタンのようなものを日本語表記にしたい場合には、以下のように対応する必要があります。（要するに、手作業で「選択」という文字が書かれたボタンを作る。）
ちょっと面倒な作業になりますが、現在の 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 のサイトに詳しくまとめられていますが、なかなかとっつきにくいのも確かだと思います。そこでここでは、課金に関するポイントを解説します。
※ （重要） ここに書かれている情報は、エントリ執筆時点での情報をまとめたものであり、またあくまで参考情報です。誤りがないように調べて書いてはいますが、万が一間違いがあった場合でも責任が持てません。必ずオフィシャルサイトの最新情報を調べるようにしてください。
トラフィック課金について
ちなみに現在は、夜間時間帯割引などもありますので、うまく活用するとよいでしょう。
Windows Azure コンピュートサービスについて
以上のことをきちんと押さえておくと、Production 環境のアプリケーションをアップグレードする正しい方法が分かってきます。具体的にまとめると、以下のような手順になります。
うっかり放置すると、Small インスタンス 1 つであっても、1 か月あたり 8,000 円程度の課金を食らいます。決して安い金額ではないので、十分注意しながら利用してください。
Windows Azure ストレージサービスについて
SQL Azure データベースサービスについて
なお、上記のいずれに関しても、課金状況は MOCP サイト（Microsoft Online Services Customer Portal サイト）から確認できますが、課金情報はリアルタイムではなく遅れがありますので注意してください。
さて、ここまで課金の仕組みなどについてざっと解説し��きましたが、実際にご自身のアプリケーションの場合にどの程度の課金となるのか？ に関しては……これは正直なところ、case-by-case としか言いようがありません。よく、「一般的な Web アプリケーションだといくらぐらいの金額になるの？」と聞かれるのですが、世の中に存在する Web アプリケーションの中身は千差万別で、必要なサーバ台数も、データ転送量も、本当にまちまちというのが実態です。
もし実際に Azure プラットフォームを使う前に、課金がどの程度になるのかを知りたければ、既存の類似アプリケーションについて、以下のようなポイントを考えてみたり調べてみたりするとよいでしょう。
サーバ台数の見積もりなどは、原理的に机上での評価が難しい領域になります。そういう観点からも、プロトタイピングなどを通して実機検証を行い、見積もり精度を高めていくことをお奨めします。
［まとめ］
というわけで、ここまで Windows Azure プラットフォーム上でのアプリケーション開発を Step-by-Step 形式で見てきましたが、キーポイントをまとめると以下の通りとなります。
Windows Azure プラットフォームのメリットは、なんといっても ASP.NET Web アプリケーションの開発スキルがあれば、ほとんど追加の学習の必要なく、クラウドコンピューティング（PaaS）の恩恵を受けることができる、という点です。今回のエントリでは紹介しませんでしたが、Worker ロールサーバも利用方法はさして難しくなく、応用次第で多彩な使い方ができるのが Windows Azure プラットフォームのよいところです。今後、Windows Azure をはじめとするクラウドコンピューティング関係のスキルは決して無視できなくなってくると思いますので、.NET の開発をされている方は、ぜひ Windows Azure プラットフォームも触ってみてください。決して損はしないと思います。