George Huey による SQL Azure Federation 概要 ～ クラウドカバー Episode 69
Windows Azure の最新情報をお届けする Channel 9 の人気番組、クラウドカバー。
今回はエバンジェリストの George Huey をゲストに SQL Azure の新機能 Federation について解説します。なお、George は今回のクラウドカバーで登場する SQL Azure Migration Wizard および SQL Azure Federation Data Migration Wizard の開発メンバーでもあります。
なお、日本語における SQL Azure Federation の情報としては以下をお勧めいたします。
・SE の雑記：はじめての SQL Azure フェデレーション その 1
・SE の雑記：はじめての SQL Azure フェデレーション その 2
ぜひご参照ください。
では、いつものようにニュースから。
Wade とともにクラウドカバーのメイン解説者として、また数多くの OSS を Azure で稼働させるための Tips やナレッジを提供してくれた Steve Marx がマイクロソフトを卒業し、起業することになったというニュース。
ASP.NET の開発チームから GitHub に移った Phil Haack といい、さみしくもありますが OSS とマイクロソフトとの新しい関わり方が出てきた感じです。
今後の活躍にも期待です！
※ Windows Azure のソリューションパートナーである Aditi 社において、Chief Windows Azure Architect として参加するということが決まったようです。一方で、起業についても並行して(Aditi 社もＯＫだそうで）進めるようです。
◆ 8 Essential Best Practices in Windows Azure Blob Storage
Windows Azure の Blob ストレージは自由度が高い分、コストと可用性のバランスを取りながら、どのような設計方針で使用するかしっかり考える（あるいは運用の中で最適化を図っていく）必要があります。
このエントリでは、Blob ストレージの利用にあたって基本的な８つのプラクティスについて説明しています。
◆ Using Windows Azure Access Control Service from a Node Express App
サーバーサイドの JavaScript 実行環境として注目を浴びている Node.js。
このエントリでは、Node.js を利用した Web アプリケーションにおいて、Windows Azure の認証サービスである Accecc Control Service(ACS)を利用した認証機能の組み込みを行うための手順とコードを紹介しています。
Node.js は Windows Azure においても力を入れている Web アプリケーション実行環境であり Windows Azure のホームページにおいても、.NET や PHP と並んで Node.js 専用のページが用意されていたりします。
Windows Azure という PaaS のメリットを最大限に活用するうえでも、Node.js と ACS の組み合わせは面白いかもしれません。
◆ How Much Overcapacity Are You Running with Today?
サービス開発におけるキャパシティプランニングは時にサービスの成長スピードとインフラの拡張スピード（主にハードウェア調達と設定等による）のギャップによって、キャパシティが十分でないためにサービスレベルが低下したり、あるいはキャパシティが過剰になり(Overcapacity)運営コストが余計にかかったり、といった問題に直面します。
クラウドを利用するメリットの一つが、柔軟な拡張性によりこのようなギャップを最小化し、適切なサービスレベルと運営コストのバランスを確保することにあります。
このエントリでは、SQL Azure の新機能である Federation（フェデレーション）機能を使うことでキャパシティの最適化が行えるということ、また具体的な Federation 機能の使い方記事の紹介が行われています。
ということで、本日の本題は、SQL Azure の Federation 機能の概要と、オンプレミスで利用しているデータベースを SQL Azure Federation を利用したクラウド環境へどのように移行するか、についてになります。
冒頭に書いたように、George は Wade も愛用中の SQL Azure Migration Wizard の開発メンバーであり、また今回のクラウドカバーで紹介するもう一つのツール SQL Azure Federation Data Migration Wizard に関しても関わっています。
これらのツールを利用することで、オンプレミスのデータをクラウド上の SQL Azure へ簡単にマイグレート（移行）できるわけですが、まずは SQL Azure のFederation について学んでいきましょう。
SQL Azure の Federation は、スケールアウトを行うための機能で、シャーディングによるデータベース分割を行えるようにする機能です。
Windows Azure では、フロントエンドおよびミドル層のスケールアウト機能として、Web Role および Worker Role (そしてそれをつなぐキューや Service Bus など）によって、必要な量のコンピューティングリソースを必要な時に使用できる環境を用意しています。
SQL Azure の Federation 機能を用いると、シャーディング パターンに基づき、データ層においても同様に容易なスケールアウトが可能になります。
具体的には SQL Azure の Federation を利用すると、あるデータベースに含まれているデータを、複数のデータベースに分散（シャーディング）することができます。この際、PaaS な Windows Azure においては分散を行うためのキーの指定と、各データベースにデータを割り振るためのキーの値の範囲を指定（たとえば 最小値から500万までと、500万からそれ以上、をいった指定）することで、あとは自動的にデータの分散（分割）が行われます。
では実際にデモ、ということでまずは SQL Azure の Migration Wizard でオンプレミスのデータベースから、SQL Azure にデータを移行するための機能を見ていきましょう。
最初のデモでは、SQL Server から SQL Azure に移行したいデータの選択を行っていますが、この際に Migration Wizard がいくつかの警告を出してくれています。
実は、SQL Server と SQL Azure では若干の機能差が存在しています。この Migration Wizard では実際にデータの移行を行う際に問題となる機能差について検証を行い、差異に当たる部分に関しては警告してくれます。この情報を基に、データの移行前にデータベースに対して必要な変更を行うことが可能です。
次に、このような機能差については対応を行ったと仮定して、Migration Wizard で SQL Azure に対応したデータベースの移行の検証を行います。
ただし、今回は Wizard において移行のターゲットを SQL Azure Federation とします。
すると今度は SQL Azure Federation に特有の警告が２種類（Identity と Timestamp)が出ました。
このように Migrration Wizard を利用すると、SQL Azure （あるいは SQL Azure Federation）の環境へデータを移行する場合に必要となる論理検証を行ってくれます。
では最後に、SQL Azure Federation に移行しても問題ないデータベースを使って実際のデータの移行を行っていきます。
まずは Migration Wizard で移行のためのスクリプトを生成します。
Migration Wizard はこのように簡単な操作でデータの移行のためのスクリプト生成を行うことが可能です。データの移行に関しては内部的には BCP (一括データコピー）の機能を使用しています。Migration Wizard は CodePlex にてオープンソースとして提供されていますので、そのあたりの仕組みが気になる方は、ぜひソース コードも参照ください。
さて、Migration Wizard が生成するスクリプトにおいて、実際に Federation を行いたい（分散させたい）テーブルに対して、FEDERATED ON の宣言と、分散を行う際のキー（今回は “Customer ID”）を追加します。
Federation を利用する際、この分散に使用するキーは１つのみ、指定可能です（複数のキーを指定することはできません）。
さて、実際にこのスクリプトを動作させる前に、SQL Azure に接続し、Federation のためのデータベースを用意しましょう。
Federation のもととなるデータベースとして、”fedRoot” を作成します。
この際に、Collation や、エディション、サイズを選択しますが、この選択は Federation における子供のデータベース（分散されたデータが実際に格納されるデータベース）にも反映されるようになっており、初期状態では同じ値でデータベースが作成されます（後程変更することは可能です）。
さて、Federation の Root (親)となるデータベースができましたら、次にサーバーへの再接続を行います。今回の接続では “Server Type” として、”SQL Azure Federation” を指定し、接続するデータベースとして先ほど作成した “fedRoot” を選択します。
すると Wizard が、SQL Azure Federation に最適化された画面が表示されます。
ここで、”Create” ボタンを押し、新しい Federation の設定情報を入力します。
必要な情報は、作成する Federation の名称と、Federation を行う際に分散させるためのキーの情報並びにキーの型を入力します。
すると CustomerFederation という名称で新たな Federation が作成されました。またこの時点では、分散を行うための値の範囲を決めていませんので、単一の Federation Member (子供のデータベース) に対して、すべての情報が格納されるように条件が設定されているのがわかります（cid の範囲が “Mix to Max” に設定されています）。
ここでさらに処理を進めると、実際に SQL Azure Federation においてスキーマの作成と、データのアップロードが始まります。この際データのアップロードは、実行を行っているマシンの環境に最適化された形で並行で行われます。
さて、次に Federation Member を増やすため、Federation において、データを分散させる条件を設定します。今回、分散のキーとなる cid は BigInt 型でしたが、この値が 150 を敷居としてデータを分散させます。
Wizard で条件を入力し、しばし待っていると、、、、
分割が終了したようです。
では、実際に SQL Azure Federation へ接続し、データを確認してみたいと思います。利用しているのは、SQL Server 2012 の RC0 の Management Studio です(SQL Server 2008 R2 SP1 でも接続は可能ですが、見え方に違いがあります。詳しくは前出「SE の雑記：はじめての SQL Azure フェデレーション その 1」を参照ください）。
ちなみに、先ほど分割が終了したデータベースですが、Wizard において確認すると cid の値によって２つのデータベースに分割されている（シャーディングされている）のがわかります。
この状態で実際には SQL Azure 上で３つのデータベース、ルートとなる fedRoot データベースと、Federation Member となる２つのデータベースが作成されています。
Wiazrd で、SQL Azure としてデータベースサーバーに接続すると、２つのデータベースが新たに作成されているのが確認できます。
さて、Management Studio を利用し、実際に問い合わせを行ってみましょう。
まず、Federation を利用した問い合わせでは、”USE FEDERATION” によって、Federation を使用した問い合わせであることを明示する必要があります。
また、次のオプションとして、FILTERING の ON/OFF を指定します。
FILTERING を ON にした場合、”USE FEDERATION” にてしていしている cid の条件によって絞り込みが行われます。そのため、上記の画面では、その後に実行した SELECT 文での結果が１件のみ(cid=200)になっています（SELECT 文にて、where 句がありますが、実行の際にこれを選択していないので、この条件指定は無視されています）。
以下は FILTERING を OFF にした場合の結果です。cid=200 の条件を満たすデータベースに対して、SELECT 文が発行され、cid が 150 以上のデータが全件取得できています（ここでも where 句は選択していません）。
なお、”USE FEDERATION” におけるキー値の指定（今回なら “cid=200”）は省略することができません（少なくとも現バージョンでは）。これは基本的に Federation がシャーディングによるデータ分散（およびそれによる並行アクセス）を前提とした機能であり、Federation Member であるデータベースを複数にわたって横断する検索はそもそもその思想を考えた場合、避けるべきだからです。
さて、この状態(cid=200 で Federation Member として使用するデータベースが指定されている状態）で、cusotomerid=50 で検索を行ってみましょう。
すると、cid=200 のデータが含まれるデータベースには、cid=50のデータが存在しないので結果が返ってきません。
一方、Federation による分散を行っていない Address テーブルに対して問い合わせを行うと、これまでと同様に全件検索を行うことが可能です。
さて、SQL Azure Federation では、スケールアウトを行う際（Split を行う際）は Wizard やあるいは SQL 文として以下のようなコマンドを利用することで、Federation Member を増やすことが可能です。
ALTER FEDERATION blogs_federation SPLIT AT(cid=100)
Split プロセスが行われている際にデータベースアクセスがあった場合には、SQL Azure のほうでよきに計らってくれ、リアルタイムでのデータ操作が可能になっています。
一方、逆にスケールダウンのためのコマンド（Merge のためのコマンド）やプロセスは用意されていません（現在取り組んではいます）。実際にスケールダウンを行う場合は、Federation Member の削除を行うことになりますので、①削除を行う Federation Member (データベース)に入っているデータをバックアップ、② Federation Member を削除、③バックアップしていたデータを他の Federation Member にインポート、といった手順になります。また、この作業を行う際には、データベースに対するユーザーアクセスを一旦止めてから行うようにしてください。
この手順、ならびに Migration Wizard を使った自動化については George が「Scaling Out with SQL Azure Federation」にて解説していますので、ご参照ください。
さて、次のデモに入る前に一旦 SQL Azure Federation 上のデータ/テーブルを削除します（ただし、Customer テーブルと、Address テーブルはデータのみ削除し、テーブルは残しています）
次に、George の作成したもう一つのツール、SQL Azure Federation Data Migration Wizard を立ち上げ、オンプレミスの SQL Server に接続します。
オンプレミスの SQL Server に接続し、データベース情報が表示されたら、SQL Azure Federation に移行したいテーブルを選択します。
この Federation Data Migration Wizard は、既に SQL Azure の Federation 環境が存在することを前提に、データの移行を助けてくれるツールです。引き続き、オンプレミスからのデータをインポートしたい SQL Azure Federation を選択します（今回の画面では、唯一出てくる “CustomerFederation” を利用）。
この状態で Wizard の “Next” を押すと、Federation Member に分散すべきテーブル、あるいは分散しなくてもよいテーブル等判断を行い、移行を行ってくれます。
以下は、実際の実行結果より、CustomerID=150 を境にデータ分散を行いながら移行を行ってくれている様子です。
このように、SQL Azure Migration Wizard もしくは SQL Azure Federation Data Migration Wizard を利用することで、オンプレミスのデータベース環境を、SQL Azure Federation の環境へ手軽に移行することが可能になります。
ということで、最後にお届けするのは Tip of the week！
今回の Tip は、「SQL Azure Federation を行う際は、スキーマ変更を極力しないように」というお話。
SQL Azure Federation により分散したデータはそれぞれ Federation Member となるデータベースに格納されていますが、個々のデータベースのスキーマは、他の Federation Member と独立にスキーマ変更を行うことが可能です。
例えば、今回の例で出てきた Customer テーブルを使用している際に、とある特別な顧客のためにスキーマ変更を行いたい、といったニーズが出るかもしれません。
しかしながら、一旦スキーマを変更してしまうと、将来的にデータベースの統合（スケールダウン）が必要になった際に作業が複雑になってしまいます。
可能な限り、スキーマ変更は行わず、シンプルな状態を保ちましょう、という Tip でした。
以上、クラウドカバー Episode 69、SQL Azure Federarion の解説でした！