Part 3. Hello World, Windows Azure アプリケーションの開発 その 4


※ 本エントリは その 3 の続きです。(エントリが長すぎて投稿できなかったため分割しています)

[アプリケーションの修正と Azure 環境への再配置(アップグレード)]

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

image

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

image

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

  • web.config ファイルに、データカルチャと UI カルチャを変更するための設定を追加する。
  • アプリケーションの中の時刻処理を、タイムゾーンを意識したコードに変更する。
   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 アプリケーションを再配置してみましょう。

  • パッケージファイルを作り直す。

    上記の修正を Web アプリケーションに加えたのち、再度、クラウドサービスプロジェクトを発行してください。
  • ポータルサイトから Staging 環境のアプリケーションを “Upgrade” する。

    ポータルサイト上から “Upgrade” を選択し、作成したパッケージファイルなどをアップロードします。

    image

    アップグレードの際には、”Automatic Upgrade” と、”Yes, I want to …” を選択し、ラベルとして新しいアプリケーションのバージョン番号(ここでは 1.0.00301.1)を指定してください。 
    image

    ※ (参考) アップグレード時には、自動アップグレードと手動アップグレードの 2 つの方法が選択できます。これは、サービスに含まれる各ロール(Web ロールや Worker ロール)を自動的にすべてアップグレードするか、手動でひとつずつアップグレードしていくかを選択するものです。ステージング環境などのアプリケーションをアップグレードする場合には、通常はまとめて自動アップグレードすれば十分でしょう。

    ※ (参考) アップグレードは、サービスの構成(=サービスに含まれるロールの種類やエンドポイントの構成など)が同一でないと行うことができません。サービスの構成が変更された場合には、いったん配置(Deployment)を削除した上で、再度新しく Deploy 作業を行ってください。

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

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

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

このため、今回の GridView の選択ボタンのようなものを日本語表記にしたい場合には、以下のように対応する必要があります。(要するに、手作業で「選択」という文字が書かれたボタンを作る。)

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

ちょっと面倒な作業になりますが、現在の Azure プラットフォームの制約として知っておいていただければと思います。

さて、ここまでの修正や動作確認が済んだら、次にインスタンス数を増やしてみましょう。ポータルサイトから ”Configure” ボタンを押し、構成設定ファイルを表示します。(この構成設定ファイルは、アプリケーション配置時にクライアントからアップロードした ServiceConfiguration.cscfg ファイルです)

image

このファイルの中ほどに、<Instances count=”1” /> という設定がありますので、これを適宜増やします。(ここでは 3 にしてみることにします。) 修正後、”Save” ボタンを押していただくと、インスタンス数が増加することになります。(※ インスタンス数増加には多少時間がかかりますので、しばらく待ってください。)

image

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

image image

最後にいよいよこのアプリケーションを本番環境(”Production”)へと展開しましょう。このためには、ポータルサイトのスワップ機能(入れ替え機能)を利用します。

image

この画面の真ん中のボタンを押すと、二つの環境が入れ替わるようになっています。これにより、運用環境にアプリケーションを配置し、通常の URL アドレスでアクセスすることができるようになります。

image

※ (参考) Windows Azure では、アプリケーションに対して http://○○○.cloudapp.net/ という形式の URL が付与される形になりますが、独自のドメイン名を付与したい場合には、DNS サーバの機能の一つである CNAME エントリ機能を使うとよいと思います。詳細は各種の Web サイトを参照してください。

※ (参考) なお、この入れ替え作業は、実態としては「フロントにあるロードバランサのリクエスト転送先を切り替える」というものです。このため、時間もさしてかかりませんし、また Production 環境にアプリケーションがアップロードされている場合でも利用することができます。

image

以上で、基本的な Azure の使い方はおしまいですが、最後に、Windows Azure の課金を安く抑えるためのコツについても解説しておきましょう。

 

 

 

 

 

 

 

 

[Windows Azure 運用環境を安く使うためのコツ]

まず、Windows Azure プラットフォームでは、基本的に、「サービス」と「トラフィック」が課金対象になります。

image

 

 

 

Azure の課金の詳細については、Windows Azure のサイトに詳しくまとめられていますが、なかなかとっつきにくいのも確かだと思います。そこでここでは、課金に関するポイントを解説します。

※ (重要) ここに書かれている情報は、エントリ執筆時点での情報をまとめたものであり、またあくまで参考情報です。誤りがないように調べて書いてはいますが、万が一間違いがあった場合でも責任が持てません。必ずオフィシャルサイトの最新情報を調べるようにしてください。

トラフィック課金について

  • 同一拠点(≠ 同一地区)の Azure データセンタ内の通信に関しては課金対象とはなりません。

    つまり、同一データセンタ内に配置された、Web ロールと Worker ロールのサーバ間の TCP/IP 通信などは課金対象とはなりません。
  • トラフィック課金の単価は、データセンタの場所によって決まります。

    クライアントユーザがどこにいるかではなく、サービスがどのデータセンタに配置されているのかによって課金が決まります。(ちなみにアジアはトラフィック課金の単価が多少高めです。)
  • トラフィック課金は比較的膨らみがちなので、予めよく設計するようにしてください。

    単価だけ見ると小額なのですが、実際の Web サイトではそれなりの金額になります。例えば、約 500kB の Web ページが 5,000 回/日のペースで呼び出されたとしても、500kB x 5,000 回 x 30 日 = 75GB の転送量になり、決して無視できないデータ転送量になりますので、注意してください。

ちなみに現在は、夜間時間帯割引などもありますので、うまく活用するとよいでしょう。

Windows Azure コンピュートサービスについて

  • マシン占有課金=単価 × VM サイズ × デプロイ時間 × インスタンス数 です。

    「CPU の利用時間」ではなく、「サーバリソースの占有量と時間」により課金が決まるところがポイントです。つまり、下図のように “Stopped” 状態の仮想マシンについても課金が行われます

    image_60 
    実際の利用時には、“Stopped” 状態でサーバを放置しない(必ず “Delete” し、空っぽの状態にする)ようにしてください。

  • “Production” 環境と “Staging” 環境に課金上の違いはありません。

    仕組みを考えてみれば明らかだと思いますが、Staging 環境といっても、ここにアップロードしたアプリケーションはしっかりと Windows Azure インフラの CPU やメモリリソースを占有しています。このため、”Staging” 環境に置いたアプリケーションについても、課金が行われます

    通常、Staging 環境は、Production 環境のアプリケーションをアップグレードする前の最終動作確認環境として利用されますが、利用が済んだらこれも必ず “Delete” するようにしてください。

  • 課金時間は、「デプロイ~削除」までを 1 時間単位で繰り上げする形で計算されます。

    つまり、1 分しか配置していなかったとしても、1 時間分の課金が行われる、ということになります。よって、以下のような操作は避けてください。

    例1. 新規アプリケーションパッケージをデプロイしたあと、1 分後に削除する。

    例2. 最初から大量のインスタンス数(例 : 30 インスタンス)でデプロイする。(→ 万が一デプロイに失敗した場合には削除してやり直すことになりますが、この場合、30 時間分の請求が発生します)

以上のことをきちんと押さえておくと、Production 環境のアプリケーションをアップグレードする正しい方法が分かってきます。具体的にまとめると、以下のような手順になります。

  • まず Staging 環境に、インスタンス数 = 1 で新規デプロイする。
  • 動作確認し、問題なければ、Staging 環境でインスタンス数を増やす。
  • Production と Staging を入れ替える。
  • しばらく様子を見る。(※ 問題があった場合にはロールバックするため)
  • 問題がなければ、Staging 環境を削除(Delete)し、インスタンスを消す。

うっかり放置すると、Small インスタンス 1 つであっても、1 か月あたり 8,000 円程度の課金を食らいます。決して安い金額ではないので、十分注意しながら利用してください。

Windows Azure ストレージサービスについて

  • トラフィック課金に特に注意してください。

    Windows Azure ストレージサービスでは、「ストレージ利用量」「トランザクション数」「トラフィック量」の 3 つにより課金が決まります。執筆時点の場合、ストレージ利用課金は $0.15/GB・月、トランザクション課金は 10,000 トランザクションあたり $0.01、トラフィック課金は北アメリカで $0.15/GB。これらの数字から考えると、ストレージサービスの課金の大半はトラフィック課金になるはずです。特に、マルチメディアファイルなどの巨大な BLOB データをストレージに置いて配信するような場合には十分な注意が必要です。

SQL Azure データベースサービスについて

  • サービスの課金は、データベースの数とエディションにより決まります。

    例えば下図の例の場合には、Business Edition のデータベースが 1 つ、Web Edition のデータベースが 1 つで、それぞれに対して課金が発生します。SQL Azure の場合、容量制限があるためにデータベースの数を増やしたくなるわけですが、むやみに増やせばそれ相応に課金額も増えていく、ということに注意してください。

    image

  • オンプレミス SQL Server などとの連携を行う場合は、トラフィック課金に気を付けてください。

    特にデータベースのデータの一括転送などは、どうしても容量がかさみがちになります。トラフィック課金がかなりの額になることも想定されますので、十分注意してください。

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

image

さて、ここまで課金の仕組みなどについてざっと解説してきましたが、実際にご自身のアプリケーションの場合にどの程度の課金となるのか? に関しては……これは正直なところ、case-by-case としか言いようがありません。よく、「一般的な Web アプリケーションだといくらぐらいの金額になるの?」と聞かれるのですが、世の中に存在する Web アプリケーションの中身は千差万別で、必要なサーバ台数も、データ転送量も、本当にまちまちというのが実態です。

もし実際に Azure プラットフォームを使う前に、課金がどの程度になるのかを知りたければ、既存の類似アプリケーションについて、以下のようなポイントを考えてみたり調べてみたりするとよいでしょう。

  • ネットワークトラフィックはどの程度あるのか?(これは IIS ログから調べられます)
  • 現在の Web サーバのマシンスペックと台数はどの程度か?(Azure プラットフォームでは Small インスタンスの CPU が 1.6GHz 相当なので、これからざっくりとした計算はできます)
  • 必要となる SQL Azure データベースの容量はどの程度か?

サーバ台数の見積もりなどは、原理的に机上での評価が難しい領域になります。そういう観点からも、プロトタイピングなどを通して実機検証を行い、見積もり精度を高めていくことをお奨めします。

[まとめ]

というわけで、ここまで Windows Azure プラットフォーム上でのアプリケーション開発を Step-by-Step 形式で見てきましたが、キーポイントをまとめると以下の通りとなります。

  • Windows Azure のアプリケーションを配置するためには、クラウドサービスプロジェクトを利用する。
  • クラウドサービスプロジェクトでは、主に 2 つのことができる。

    ① 開発用ファブリックを利用した、ローカル PC での Azure 環境のシミュレート

    ② 運用環境にアップロードするためのパッケージファイルの作成

  • 開発環境から運用環境へと移行する際には、以下のように移行を行う。

    ① SQL Server データベース → SQL Azure データベースサービス

    ② 開発用ストレージ → Windows Azure ストレージサービス

    ③ 開発用ファブリック → Windows Azure コンピュートサービス

  • サーバの動作情報を収集する場合には、Diagnostic Monitor ランタイムを使う。
  • 運用環境を管理する際には、Windows Azure ポータルサイトを利用する。
  • 運用環境を利用する際には、課金に注意する。

    特に、”Stopped” 状態(サスペンド状態)になっていても、課金が発生することに注意して利用する。

Windows Azure プラットフォームのメリットは、なんといっても ASP.NET Web アプリケーションの開発スキルがあれば、ほとんど追加の学習の必要なく、クラウドコンピューティング(PaaS)の恩恵を受けることができる、という点です。今回のエントリでは紹介しませんでしたが、Worker ロールサーバも利用方法はさして難しくなく、応用次第で多彩な使い方ができるのが Windows Azure プラットフォームのよいところです。今後、Windows Azure をはじめとするクラウドコンピューティング関係のスキルは決して無視できなくなってくると思いますので、.NET の開発をされている方は、ぜひ Windows Azure プラットフォームも触ってみてください。決して損はしないと思います。

Comments (0)

Skip to main content