SQL Azure と Cosmos DB をメインにWindows Azureの情報を発信
TechED 2014で、Microsoft Azureの機能追加がいくつか発表されました。その中に、仮想マシン作成時にカスタムスクリプトを実行させられる機能が追加されました。
IISの役割をインストールするpowershellスクリプト（.ps1）を用意し、ローカルディスクかAzureストレージに保存します。
install.ps1 Add-WindowsFeature Web-Server –IncludeAllSubFeature
次に、ポータルからスクリプトを使用するように設定します。
VMエージェントのインストールを選択し、「カスタムスクリプト」オプションを選択し、インストールスクリプトを選択します。他に必要な対応として、Firewallのポートを開けたり、websaiteのパスを変更があるので、それらもスクリプト化すると良いかも。
参考情報：Auto Install IIS in the Microsoft Azure VM that you are creating
Windows Azure Virtual Machine上のSQL ServerのTempDBのデータファイル数とディスク数はいくつにするのがベストなのかをWindows Azure CATチームがBlogに「Scaling-out SQL Server disks and data files on Windows Azure Virtual Machines…a real-world example」投稿してくれています。詳細や検証データは、元記事を参照してください。
使用する仮想マシンは、エクストララージ（XL / 8コア）でWindows Server 2008 R2とSQL Server 2012の組み合わせの仮想マシンです。ストレージアカウントは、デフォルト設定でジオレプリケーションを有効にしたままにしています。
［Windows Azure Storage Scalability and Performance Targets］によると、Windows Azure ストレージBlobは、書き込み性能として、［最大60MB/秒、最大500トランザクション/秒］と定義されています。
データファイル数は8個に分割し、4つのディスクに2つずつ配置するのがベストなDisk I/O性能となります。
この設定でDisk以外のところに性能ボトルネックが発生するので、Disk数を増やしても効果が無いことがわかりました。
SQL Server Customer Advisory TeamのBlogに投稿された「Be aware of the difference in isolation levels if porting an application from Windows Azure SQL DB to SQL Server in Windows Azure Virtual Machine」をベースにした投稿です。
Windows Azure SQL DatabaseからWindows Azure Virtual Machine上のSQL Server（オンプレミスのSQL Server）に移行する際に、性能問題に遭遇することがあります。
原因として、分離レベルの違いからロック待ち事象（lock wait）が高くなっている可能性があげられます。
Azure SQLでは、デフォルトで、READ COMMITTED SNAPSHOTとSNAPSHOT ISOLATIONが有効になっています。
SQL Serverでは、デフォルトで、READ COMMITTED SNAPSHOTとSNAPSHOT ISOLATIONが無効になっています。
参考：確認用SQL
select name, snapshot_isolation_state, is_read_committed_snapshot_on from sys.databases
READ COMMITTED SNAPSHOT ISOLATION (RCSI)を前提にしたアプリケーションをそれぞれの環境でロードテストして見たところ次のような結果になりました。
| データ格納先 | アプリケーションレスポンスタイム | アプリケーションスループット |
| Azure SQL | 0.83 | 38 |
| WinVM上のSQL Server | 2.94 | 13.9 |
これだけの差がついた原因は、パフォーマンスカウンター（“Lock Waits” under object => “SQL Server:Wait Statistics”, instance => “Average wait time (ms)”）を確認すると判明しました。ロックのwait平均時間が1秒程度かかっていました。
RCSIを有効にして、ロック待ち時間を数ミリセカンドにまで減らすと次のような結果になり、性能改善できました。
| データ格納先 | アプリケーションレスポンスタイム | アプリケーションスループット |
| WinVM上のSQL Server：既定 | 2.94 | 13.9 |
| WinVM上のSQL Server：RCSI | 1.14 | 34.8 |
RCSIを有効にすると、SQL ServerではバージョンストアをTEMPDBに格納するため、TMPDBに注意する必要があります。たとえば、あるシナリオでは、次のようなTEMPDBのディスクI/Oスループットに差がでました。
| データ格納先 | Disk Read Bytes/sec | Disk Writes Bytes/sec |
| WinVM上のSQL Server：既定 | 403,031 | 1,504,410 |
| WinVM上のSQL Server：RCSI | 26,570,531 | 58,219,559 |