はじめに
Windows Azureも今年1月に正式提供が開始されて、そろそろ業務で本格的な活用を検討されている方も増えてきていると思います。ただ、実践的なノウハウはまだ集積されておらず、日本のMSDNフォーラムなどでも質問数がポツポツと出てきたかなという感じです。おそらく試行錯誤している段階ではないかと思います。
その点、USは活況なようでUSのMSDNフォーラムには週に60件以上の質問と回答が交わされています。私は米国のMSDNフォーラムをウォッチしていますが、質疑応答のなかには目を引くような面白いアイディアやFAQになると思うようなハマリどころがたくさんありました。
本連載では、その中から筆者がこれは面白いと判断したものや、FAQとしてぜひ日本で紹介したいものを独断と偏見でレベル分けをしたうえで、質問を再構成して内容やポイントを解説していきます。
MSDNフォーラムの内容や回答は正確性が保証されたものではありません。筆者側でできる限り内容の精査を行って紹介していますが、著者、MSDNフォーラムともに正確性を保証するものではないことをご承知おきください。
1）incremental deployment process.
- 質問：
コンピュートサービスでデプロイしたアプリケーションの一部だけを変更したいけど、再デプロイ以外の手段がないでしょうか？［上級］［配置］
- 回答：
静的なファイル（cssファイルなど）をブロブに配置する設計をすれば、かなり再デプロイが回避できます。
- 解説：
Windows Azureでは、Azureアプリケーションを1つにまとめたアーカイブであるパッケージファイルをホスティングサービスに転送して稼働させます。この行為をデプロイと言います。Azureアプリケーションはパッケージファイル単位で管理されるため、1ファイルのみを変更したい場合も同じようにパッケージファイルを転送して再デプロイを行いアプリケーション全体を差し替えなければいけません。
しかし、残念ながら現状では再デプロイに時間が掛かるため、かなりの時間ロスが発生してしまいます。また、再デプロイを実施した場合、各ロールのインスタンスが一時的に停止するためサービスのレベルが一時的に落ちてしまいます。そのため、できるだけ再デプロイしない設計も保守の面で重要になってきます。
米国のフォーラムでは、画像、jsファイル、cssファイルなどの静的なファイルをアプリケーションに含めるのではなく、ブロブに配置して参照させる提案がされていました。
コードビハインドが必要なファイルなどは再デプロイしなければなりませんが、こうすることにより、再デプロイの回数が減って保守が容易なアプリケーションの構築が可能になります。
2）Development Fabric "Port walking"
- 質問：
- 回答：
Development Fabricでは、デフォルトでポート番号を80番から使用します。しかし、80番が他で占有されている場合などで使えないケースでは番号がインクリメントされて空いているポートを使用します。
- 解説：
Development Fabricとは、Windows Azureをローカルでエミュレートする環境です。Development Fabricは、デバッグ時にのみポートを確保しますが、時折、デバッグ終了時に使用していたポートが開放されないことがあり、その場合、以降のデバッグでは80番以降のポートが利用されます。その場合は、デバッグ終了後に手動でDevelopment Fabricを再起動してポートを開放することで固定化できます。また、80番ポートを占有しているアプリケーション（例えばskypeなど）がある場合は、そのアプリケーションが使用するポートを変更する必要があります。
フォーラムではコマンドで環境のクリーンとDevelopment Fabricのシャットダウンをすることを勧めていました。最初に、以下のコマンドで、Development Fabricに関連づいている情報を削除します。
"C:\Program Files\Windows Azure SDK\v1.3\bin\csrun.exe" /devfabric:clean
関連情報の削除で解決しなかった場合に、以下のコマンドで1回シャットダウンを行います。
"C:\Program Files\Windows Azure SDK\v1.3\bin\csrun.exe" /devfabric:shutdown
上記2つのコマンドを使用することで、環境をリフレッシュしてデバッグをやり直すことが可能になります。
3）SQL Exception
- 質問：
- 回答：
ADO.NETのコネクションプールが5分間使用がなければ切断される仕様だからです。
- 解説：
SQL AzureのFAQとしてトップに来そうな質問です。回答は以上の通りですが、アプリケーション側の対策としてSQL Azureではリトライ処理の実装が必須になります。最近、切断時間が30分に延長されたそうですが、サーバのダウンなどが原因で切断は発生するためSQL Azureを使用する際はリトライ処理を実装することをお勧めいたします。USのフォーラムでも実装例が紹介されていました。
SQL Azureに対する接続では回線の問題による接続遅延が発生することと、SQL Azureのサーバ自体が冗長性を持っていてサーバダウンが発生することによるリトライを考慮に入れなければならない点などの、コネクションプール以外にも接続遅延というキーワードでの大まかな概要がメインで記載されていました。
また、MSDN Blogsでは、ADO.NETを使用した際のリトライ処理のサンプルなどが記載されています。
