Scott Klein による SQL Azure における Throttling 解説 ～ クラウドカバー Episode 68
今回の Cloud Cover は、SQL Azure のテクニカル エバンジェリスト Scott Klein を招き、SQL Azure のリソース最適化のための仕組み Throttling のエラー解読について、また Throttling とうまく付き合うために役立つ仕組みとして、"Topaz"（トパーズ)の愛称で Enterprise Library として提供している Transient Fault Handling Application Block の紹介を行います。
では、いつものようにニュースから。
Windows Azure の Service Bus 機能（少し前までは AppFabric Service Bus という名称でしたが、今は単純に “Service Bus” と呼んでいます）はリリース以来様々な機能強化、改善が行われてきました。一つの大きな機能強化として従来の “Relay(リレー)” 形式のメッセージ伝達に加え、”Subscription” 形式のメッセージ伝達をサポートするようになったのはご存知の通り。
今回紹介の記事はこのあたりのことを解説した Service Bus の新しいデモについての記事です。
ちなみに、Subscription の機能に関しては「Windows Azure AppFabric Service Bus の新機能 Queue と Topics の紹介 ～ クラウド カバー Episode 47」でも紹介していますので、ご参考に。
Windows Azure においてはメールサーバーの機能を持っていないため、作成したクラウドアプリケーションにおいて、メール送信の機能を追加する場合には外部のメールサーバーを利用する必要があります（たとえば Office 365 を契約いただく、といった方法も可能です）。
今回紹介するのは、SendGrid 社において、Windows Azure 上から SendGrid 社のサーバーを利用しメール送信を行うために必要となるコンポーネントのリリースと、Windows Azure ユーザー向けに 25,000通/月までの無償サービス利用のキャンペーンが行われている、ということです。
コンポーネントは、NuGet で “> Install-Package SendGrid” でOK。コードも非常に簡単に記述できます。
希望のサービス条件に合うようであればご利用を検討いただくのもありかもしれません。
C# での詳しい使い方ガイドは「How to Send Email Using SendGrid」を、その他の言語については Node、 PHP、Java の各ページを参照ください。
◆ Windows Azure and Cloud9 IDE at Node Summit
サーバーサイドにおける JavaScript 実行環境 Node.js は Windows Azure における開発環境への取り組みの中でも重要視されている分野であり、Windows Azure の Web ページでも個別に「Node.js - 概要ガイド」なるページが用意されるなど、マイクロソフトが全社的に取り組みを強化している開発環境です。
今回のニュースはサンフランシスコで行われた Node 開発者のための集まり Node Summit において発表された Windows Azure の Node.js 用機能の紹介です。
具体的には Node.js から Windows Azrue 上のストレージサービスにアクセスする手順、および Node.js におけるデファクト開発環境になりつつある Cloud9 を使用して Windows Azure 用のパッケージの作成やデプロイを行う機能が紹介されています。
Cloud9 を使った開発については「Deploying a Windows Azure App from Cloud9」を参照ください。
◆ Import/export service for SQL Azure generally available
以前「データベースの SQL Azure への移行と更新 ～ クラウドカバー Episode 61」でも紹介した SQL Server および SQL Azure におけるデータの移行を容易にする Import/Export のサービスが正式な機能としてリリースされました。
以上で今回のニュースは終了です。
では本題の、Throttling と Transient Fault Handling な話題に入る前に、時計を外しましょう！
SQL Azure はマルチテナントなサービスとして設計されており、その中で高可用性を維持するために Throttling という仕組みが取り入れられています。（「SQL Azure の高可用性の仕組み」も参照ください）。
この Throttling の仕組みにより、SQL Azure への接続において、SQL Server を使ったアプリケーションでは意識しなかったエラーのハンドリングが必要になります。
今回のクラウドカバーにおける一つ目のトピックは、このエラーの理由を、サーバーから戻ってくるコード（ナンバー）によって分析しようというものです。
そのために必要なのは、、、、電卓、です。
電卓を立ち上げたら「プログラマ」用の表示に変更しましょう。
そして Scott が用意したのは Word に書かれたコード表（この表は、Scott のブログ「Understanding SQL Azure Throttling and Implementing Retry Logic」で確認できます）。
さて、SQL Azure からエラーが帰ってきたとして、そのコードが 1311075 だとしましょう。その数字を電卓に入力し（１０進数で入力）、
これを １６進数(Hex) に変換します。
ここで出てきた数字「20003」を、先頭３文字「200」と後ろの２文字「03」に分けて、コード表を見ると、「03」は “Reject All” で、「200」が “High valume CPU activity exist” にマップされています。つまり、このエラーは、「サーバー側の CPU 負荷が高まったため、すべてのリクエストを拒否している」ために発生した、と判別できる。
このようにエラーコードを利用することで、サーバーエラーの原因をより詳細に把握することが可能です。
※ 再掲になりますが、この表は、Scott Klein のブログ「Understanding SQL Azure Throttling and Implementing Retry Logic」に掲載されています。
さて Throttling によって、SQL Azure への要求が拒否されることがあること、またその理由についてはコードをチェックすることでより深く理解できることがわかりました。
今回のクラウドカバーの次のトピックは、SQL Azure を利用したアプリケーションにおいてこのような要求拒否をうまく扱うためのテクニックについてです。
実は、そのようなアプリケーションブロック（モジュール）が Transient Fault Handling Application Block という名称で、Enterprise Library 5.0 において提供されています。
実際にこれをアプリケーションで利用するには、Visual Studio で該当プロジェクトが開かれている状態で、NuGet （にゅーげっと）を使って、Package Manager から、
PM> Install-Package EnterpriseLibrary.WindowsAzure.TransientFaultHandling
のコマンドを実行することで入手できます。
なお、Steve が言及していますが、Package Manager Console ではインテリセンスが効くので Install-Package の後に、「en」ぐらいまで打ってタブを押せば、「en」で始まるパッケージ候補一覧が出ます。
NuGet の仕組みによって Transient Fault Handling に必要なモジュールがプロジェクトに追加されました。
次は実際に Transient Fauld Handling の機能を利用したいクラスにおいて、必要なアセンブリの using を追加し、ReliableSqlConnection クラスを使って、SQL Azure とのコネクションを確立するようにします。
この ReliableSqlConnection クラスのインスタンス生成の際に、エラーが発生した場合のリトライのポリシー（戦略）を設定することが可能です（今回のデモではデフォルトのリトライポリシーを採用します）。
以下が、リトライ機能を組み込んだ SQL Azure への接続ロジックになります。
コードでご覧いただけるように、特に特別なコーディングが必要なわけではなく、Transient Fault Handling Aplication Block のほうで勝手にリトライの機能が組み込めるところがステキです。
さて、リトライのポリシーとしてはいくつかの方針があり、リトライの回数を指定したり、リトライ回数とインターバルの待ち時間を指定したり、と選択可能です。
また、作成（設定）したリトライポリシーですが、ReliableSqlConnection のコンストラクタにて、Connection に対するリトライポリシーと、Command に対するリトライポリシーとして、個別に設定することが可能です。デモでは、作成したリトライポリシー（３回リトライ）を、Connection および Command 両方に適用しています。
なお、明示的に ReliableSqlConnection を利用する以外にも、拡張メソッドにより SqlConnection に追加された OpenWithPrtry() メソッドを呼ぶことで、リトライの機能を追加することも可能です。
次に紹介すのは、Entity Framework を使用している際のリトライロジックの書き方。
Entity 周りはこれも特別なコードを書くわけではなく、myPolicy の ExcecuteAction にて、実際の Entity 周りのコーディングを行っておけば、勝手にリトライポリシーに基づいてエラーハンドリングを行ってくれる、というのがまたまたステキです。
ということで、今回は Throttling と Transient Fault Handling Appliucation Block の解説でした。
では、最後に雪のシアトルから Tip Of the Week!
Windows Azure のストレージエミュレーターはローカルPCの SQL Server(SQL Express)を利用しています。しかし、その権限設定が適切でない場合に以下のようなエラーが起こることがあります。
これを解決するためのスクリプトが Wade のブログ「Dealing with "cannot create database" in the Windows Azure storage emulator.」にて掲載されています。
このスクリプト、ユーザーに SQL Server の Admin Role を追加している、というのが基本的な動作で、これで上記のエラーに対応することが可能になります。
ということで、以上でクラウドカバー Episode 68 の紹介は終了です。
それでは！