Windows Azure Mobile Services 高度な設定について-Windows Azure Advent Calendar 2013

皆様、大変遅くなり申し訳ございません。今回は、Windows Azure Mobile Services の高度な設定について改めて纏めます。

1.Windows Azure Mobile Services のスケールアウト

2.既存の SQL データベースの利用

3.Windows Azure Mobile Services の監視

1.Windows Azure Mobile Services のスケールアウト

サンプルアプリケーションであれば、とくに気にしないですが、実運用となると、スケールアウトが重要になってきますね。特に商用利用のバックエンドとして使う場合にはいかにしてこれに耐え得るようにするかということは重要な要素となってきます。特に重要なのはパフォーマンスですね。しかしながら、このブログでパフォーマンスについて解説するのはスコープ超えですのでやめます。どちらかというと、Mobile Services に内在しうる課題にフォーカスしたいと思います。すなわち、どのようにMobile Services をスケールさせ、このサービスが持つ膨大な機能を最大限引き出すかということに集中すべきです。
一般的には、スケールアウトのゴールは、自分で開発したMobile Services の全体的なスループットの向上になるわけですが、 現状ではMobile Services は同時実行制御ができるわけではないです。MBaaSとして実運用で使ったときに、幸いにもユーザーがぐんと増えた場合、この問題は浮上してくるでしょう。いくつかの点で、リクエストに対応するためのサービスのキャパシティはオーバーフローする可能性もあります。このような場合にどうするべきかをここでは考察します。

 

スケールアウトのパターン - 垂直なスケールアップか水平なスケールアウトか
スケールアウトにおける最初の問題は、垂直なスケールアップか水平なスケールアウトか、いずれを選択すべきかという点でしょう。これは状況によります。

垂直なスケールアップの場合

この場合には、コンピューティングノードを増やすことなく当該コンピューティングノードのパワーを増やします。コンピュータそれ自体のパワーを向上させて、さらに多くのメモリーと、高速なCPUを使い、あるいはコアを増やしということになります。しかしながらコンピューティングノード事態の数は増えません。

水平なスケールアウトの場合
スケールアウトの例は、上記の例と異なり、この場合にはコンピュータ―ノードの追加を行いロードバランシングします。コンピューター自体を大型マシンにするのではありません。

どちらがいいというわけではありませんが、スケールアップの場合にはマシンのキャパシティのリミットに到達してしまい、 多くのコアと多くのメモリーの組み合わせが一つのデバイスに詰め込まれてしまいます。幸い、Mobile Services を使う場合には、こういうことにはなりません。スケールアップもスケールアウトも選択可能ですが、基本は自動でスケールされるように設定されているので、安心です。他方で、多くの場合には、Mobile Services が使われるのは、比較的シンプルな RESTベースのリクエストに対してです。これはそれほど多くのコンピューティングパワーを必要としません。すなわち、このように選択肢が乏しくても、かなり大規模な潜在ユーザーに対して、Mobile Services は期待に応えられるキャパシティを持つということになるわけです。

どんなオプションがあるかは、下記の通り、Windows Azure 管理ポータルから見てみてください。ダッシュボードのトップのリンクから、スケールをクリックすると、Mobile Services のスケーリングに関する設定の画面を表示できます。

image

3つのエリアがあります。無料、基本、標準の、Mobile Services の層のエリアを見てください。

無料とそれ以外の最初の違いはコストです。詳しくはこちらのリンクを見てみてください。

https://www.windowsazure.com/en-us/pricing/calculator.

2つ目の違いはいくつかの制約です。たとえば、帯域における制約、CPU プロセッシングにおける制約、そして、保存できるデータ量に関する制約です。

帯域の制約は月単位です。これを超えると使えなくなる場合があります。

データの制約はもっと永続的です。無料版のMobile Services のデータストレージは 1GB に制限されています。

これを超えて使うには有償版に移行するしかありません。ポータル上でこの移行を行うのは非常に簡単です。

移行されると、スケールアップがされ、無料版の共有環境からリザーブ環境に移行されます。比較的小さなコアのCPUのクロックもそれほど高くないマシンですが、バランスよくスケールアウトされ、これによりトラフィックの急激な増加にも耐えられるコンピューティングパワーを手にすることができます。

またデータベースもスケールすることができます。これはMobile Services のバックエンドになるものです。

Web または ビジネスのいずれかの選択が可能です。デフォルトは、Web エディションで1GB のサイズに制約されています。

ビジネスエディションを選択すると、データベースが150GBのストレージスペースを使うように構成できます。

 

2.既存の SQL データベースの利用

Mobile Services のバックエンドには SQL Database が使われています。Mobile Services を作成するときに、新しいデータベースを構成するか(デフォルト)、あるいは既存のデータベースを使用するか、を選択できます。実はこれ、Mobile Services 作成時だけでなく、既にサービスが構成され稼働中でも選択できます。

既存のデータベースを活用するには、Windows Azure 管理ポータルから、モバイルサービスを選択し、ページ上部の構成のリンクを開きます。

image

ページの中央で、データベースとデータベースサーバーが指定されているのがわかります。当該名前をクリックすると、当該データベースまたはサーバーの管理画面に遷移します。そこで、下部にある

 image

ボタンをクリックすると下記のダイアログが出ますので、ここで様々な設定が変更可能です。

image

既存のデータベースを使う場合には、それを選んで、ID/Passwordを入力したり、新規のデータベースを使うには、適切なオプションを選択してデータベースサーバーとデータベース名を指定して作成します。

設定の継承方法

この時に、注意点としては、データベース接続は十分ではないので、このデータベースがモバイルサービスと連携できるように構成する必要があります。そこでいくつかの変更を行う必要があります。
(1) 当該データベーステーブル群が当該Mobile Services と同じ名前のスキーマを持つように構成する

(2) 当該データベーステーブル群がクラスタ化された整数型のプライマリキーを持つように構成する

(3) 当該データベースコネクションが確立されたら当該Mobile Services 内のデータベーステーブル群を手動で追加する

Mobile Services が特定のテーブルと関連付けらえたデータベースを探すとき、Mobile Services は検索する範囲を決めるためにスキーマを使います。したがって、もし当該Mobile Services の名前が、musicshop であれば、当該テーブル群は musicshop スキーマ内に入っていなければなりません。 もしMobile Services の名前の中にハイフンが入っていた場合(たとえば music-shop)、スキーマ名ではアンダースコアに変換されます(music_shop)。

T-SQL 構文

このスキーマを生成するための T-SQL 構文はシンプルです。

    1: CREATE SCHEMA musicshop

スキーマがいったん生成されたら、今度は各々のテーブルを当該Mobile Services の一部として追加します。

    1: ALTER SCHEMA musicshop TRANSFER dbo.TableName

このコマンドにより、musicshop が当該Mobile Services の名前になり、dbo.TableName が完全に検証されます。これで当該Mobile Services の中でこのテーブルを使用することが可能になります。

 

もう一点、プライマリキーの件です。当該カラムは、”id”と命名される必要があります。しかもこれは小文字のみと決まっています。

したがって、下記のように書きます。

 

    1: [id] [int] IDENTITY(1,1) NOT NULL

これで、接続が確立されテーブルが適切に構成されたら、最後はこれらを手動で、当該Mobile Services に追加する必要があります。

これは、Windows Azure 管理ポータルで、モバイルサービスに移動し、トップメニューバーからデータオプションに移動します。

そして、サービスの中の下の方にあるテーブルのリストから、作成アイコンをクリックしてこれを行います。

注意点は、当該テーブルの名前はデータベース内のテーブルと同じでなくてはならないことです。

いったんテーブルが生成されたら、当該Mobile Services のインターフェースを経由して、データにアクセスし更新可能です。

 

3.Windows Azure Mobile Services の監視

監視については、Windows Azure 管理ポータルから監視タブを開いて行います。無料では不可能で、有償エディションにする必要があります。

image

詳しくはこちらをご覧ください。

image

 

以上です。次は、20日の、Windows ストアアプリの Advent Calender です。こちらは遅れないように気を付けます!

 

鈴木章太郎