SQL Azure

Azure SQL Database Elastic Scale のプレビューが発表されました!
何かと言うと、Azure SQL Database の組み込みのシャーディング(データ分割、分散)サービスです。

同様のサービスとして、Azure SQL Database Federation がありました。
Federation は正直失敗だった。
だから、Azure SQL Database Federation は、新しい提供モデルでは廃止されることが発表されていました。

なのに、今再びのシャーディングサービス。
でも、Federationでの失敗、およびAzure SQL Database の支援を通して培った経験を元に、
今度は期待できるサービスとなっています。

Federationと何が違うの?

結構、いろいろあるのですが個人的に大きい!っと思うものをピックアップ。

1. ライブラリ提供

Federationではライブラリが提供されておらず、各自でFederation用の中間コードを書く必要があり、使い勝手が悪かったのです。そのため、Federationサービスを使用せず、各自でシャーディングロジックを書くケースがありました。
Federationの成功可否は、ライブラリ提供!っと思っていました。

今回は初めから提供されています!
まずは、APIインターフェイスがあるのが大きい。
APIがあるので、クライアントライブラリがる。

Nugetで、Azure SQL Database Elastic Scale Clientが公開されています。
また管理用に、PowerShell(Shard Elastic PowerShellファイル)がサンプルですが提供されています。つまり、Azure Automationサービスとの組み合わせが可能。

2. 参照テーブルのレプリケーション

FederationでもElastic Scaleでも、参照テーブルが提供されます。
マスターテーブルなどシャーディング不要、もしくはシャーディングしたいくないテーブルは、参照用テーブルとして各分散データベースに配置することができました。

Federationでは、splitした後に参照用テーブルを更新するには、全シャーディングデータベースの参照用テーブルに対して更新する必要がありました。

Elastic Scale の参照テーブルでは、レプリケーションされます!素敵!
(レプリケーション頻度や、パフォーマンス、同期レプリケーションにできるのかは要確認)

10/3 11:12 修正:勘違い。そんな機能無かった…。

3. 複数シャードへのクエリ発行

Federationでは、特定シャードへのクエリ発行しかサポートされていませんでした。
複数のシャードにまたがるクエリを発行したい場合は、
アプリケーション側で、それぞれのシャードに個別にクエリを発行し取得した結果をアプリケーション側でマージする必要がありました。
ライブラリも提供されていないので、ユーザーが作りこむ必要がありました。

Elastic Scale では複数シャードへのクエリ発行がサポートされます!
UNION ALLを使用して結果セットを返してくれるので、とても楽になりましたね。

4. シャーディングルールがRangeに加えListも可能

Federationで提供されていたシャーディングルールは、Rangeだけでした。
Rangeパーティションですね。
シャーディングキー何番から何番までっと区切っていく方法ですね。

Elastic Scale では、リストシャードマップを作成できます。
何番と何番は、データベースAみたいに指定できるようになり、柔軟なシャーディングが実現できるようになりましたね。

5. シャーディングのセキュリティ強化

Elastic Scale では、シャーディングの実行(マージやスプリット)をできるユーザー、
シャーディングマップを参照だけできるユーザーというように、セキュリティ制御できるようになりました。

Windows Azure

channel9で公開されているde:code2014のセッション動画で、エヴァの井上さんが話された「Azure Mobile Services & Notification Hubs で全てのデバイスにプッシュ通知を送る」をまとめた投稿です。

プッシュ通知とは?

image

アプリが非アクティブでもバックエンドでデバイスに新しい情報を表示することができる機能が、プッシュ通知です。好きなタイミングで好きなメッセージを送れる機能です。プッシュ通知によって、アプリケーションの起動きっかけを作るのです。

プッシュ通知の仕組み

image

バックエンドのアプリケーションから直接、端末のアプリケーションに通知を送っているわけではないのです。

image

バックエンドから、各ベンダーが提供するPNS(Platform Notification Services)経由で端末にプッシュ通知します。Windows 8の場合はWNS、iOSの場合はAPNs、Androidの場合はGCMとそれぞれおベンダーごとにPNSが異なり、プロトコルも異なります。

バックエンドからPNSには、ハンドルごとにリクエストをします。ハンドルは端末固有のトークンで、端末1つにつき1リクエスト送信する必要があります。たとえば、10万台のデバイスに通知する場合には、10万回リクエストを送信しないといけないのです。あるお客さんの例では、リクエストを送信し始めてから送信終了まで、4時間かかったケースもあります。

image

ハンドルは、アプリケーションがPNSから取得して、それをバックエンドのサーバーに保存して使用するという流れになります。

image

ハンドルは上記例のように、単なる文字れるです。一番上がAndroid、二つ目がWindowsのハンドルです。

image

一般的な課題としては、4つです。

プラットフォームごとに対応をしないといけないので、マルチプラットフォーム対応が必要になります。また、正常に送信できたのか失敗したのかをトレースしたいのでエラー処理が必要です。さらに、端末はどんどん買い換えていくのでハンドルが変わっていくので、サーバーにゴミデータがたまるので、データのライフサイクル管理が必要です。そして、大量の宛先に素早く送信するためのリアルタイム大量通知が課題になります。

Azureの2つの通知サービス

Microsoft Azureには2つの通知サービスが提供されています。
2種類の通知サービスが提供されているので、度々理解の混乱のもととなっています。

image

最初に登場したのが、BaaSの機能の一つとしてMobile Servicesの中でプッシュ通知を提供していました。その後に登場したのが、プッシュ通知に特化した通知ハブ(Notification Hubs)と言うサービスが提供されました。

image

Mobile Servicesの通知も改良されています。
管理ポータルでMobile Servicesのプッシュタブを見ると、上記画像のように表示されます。今は、通知ハブのAPIを使うように改良されているのです。
今後、通知の機能を使う場合には、通知ハブを意識していただければOKです。

image

通知ハブになると、いろいろな課題が改良されました。Mobile ServicesはBaaSの一部だったので、通知だけ欲しい顧客には大きすぎたり、あまり課題が改良されていなかったのです。

通知ハブのプッシュ通信

通知ハブはREST APIで操作します。
.NET、Node.jsのSDKが提供されており、直接REST通信をしなくても良いようになっています。

image

通知ハブは、プッシュ通知のハブとなるサービスです。
バックエンドとPNSの間にあって、様々な処理を受け持ちます。

バックエンドから通知ハブにリクエストを送り、通知ハブにデータベースがありハンドル情報を保持しているので、通知ハブから並列にPNSにリクエストを送信します。

image

通知ハブにリクエストを送信すると、ゲートウェイノードが受信しキューに登録します。通知ノードがキューを取得し、データストアからハンドルを取得します。ハンドルを取得して、数万とかある大量の通知だと判明すると、自動的に通知ノードがスケールします。通知ノードが自動的に何台も立ち上がって、並列に通知してくれます。

image

通知が失敗すると、PNSからエラーを受け取って、データストアに格納してくれます。また、ハンドルがどんどん新しいものに変わっていきますので、それも管理してくれます。期限切れしたハンドルは勝手に削除してくれます。

image

プッシュ通知の課題をしっかりと解決してくれています。
50万通で2040円ぐらいです。
これを自前で実装するには相当の開発と運用工数がかかるため、自前で用意するのが割にあわなくなっています。

image

どれぐらいスケールするのか。
Bingニュースの事例では、300万台以上の端末に2分以内で通知できています。

通知サービスの実装とテスト

image

提供されているSDKは、サーバーサイドは.NETとJavaScript、クライアントサイドはだいたい通常使われる端末は用意されています。

image

重要なクラスが2つあります。

NotificationHubClientクラスは、管理用のクラスです。通知ハブのデータべースの読み書きや通知の送信ができたり、なんでもできるサーバサイドのクラスです。

NotificationHubクラスは、PNSからハンドルをとってきて、通知ハブにハンドルを登録する、フロントのクラスです。

image

NotificationHubClientクラスは、Microsoft.ServiceBusの中に含まれているので、最初にNuGetで取得してきてください。

image

クライアントのほうは、Microsot.WindowsAzure.Messaging.Managedに、NotificationHubクラスが含まれているのでインストールしておいてください。

image

PushNotificationChannelManager.CreatePushuNotificationChannelForApplicationAsyncを呼ぶとPNSからハンドルを取得してきます。
NotificationHubで、通知ハブの名前を設定し、通知ハブの接続情報を指定します。
RegisterNativeAsyncで、ハンドルの情報を渡すと通知ハブのデータベースにハンドルを登録します。

 

image

image

Andoroidの場合も、同様の流れで操作できます。これはSDKが提供されているからです。
NotificationHubは同じで、Androidの場合はm、gcmからハンドルを取得してきて、通知ハブのデータベースにハンドル情報を登録します。

image

Microsoft Azureの管理ポータル上から、サーバーサイドの実装をしてなくてもプッシュ通知のテストをしたりすることができます。

サーバーサイドの実装です。
NotificationHubClient.CreateClientFromConnectionStringで、管理者用の接続情報を設定します。

image

メッセージ本文を設定し、送信します。メッセージ本文は、それぞれの端末の通知の従って記述します。そして、送信メソッドで送信します。
Androidは、SendGcmNativeNotificationAsync
iOSは、SendAppleNativeNotificationAsync
windowsは、SendWindowsNativeNotificationAsync

image

image

タグを使用して、特定のユーザーやグループだけに通知を送ることができます。通知ハブにタグを登録しておいて、タグでフィルタリングして送信できます。

image

image

タグは文字列です。
タグの登録には、RegisterNativeAsyncで、ハンドルとタグを指定します。

image

送信には、送信メソッドSendGcmNativeNotificationAsyncに、タグを渡してあげるだけでOKです。

タグのほかの使い方としては、アクセスログから長期間アクセスしていないユーザー全員にプッシュ通知をするというような使い方もできます。

image

image

image

テンプレート機能で一斉に複数プラットフォームにメッセージを変更して、データ送信することもできます。

image

大量配信のテストをしたいという要望があります。
その場合に裏技として、通知ハブに同じハンドルを大量に登録しておく方法があります。
同じハンドルを100件登録しておけば、100件の送信テストができます。
(同じ端末に100個通知されます…。)

Azure Search

Configure Search in the Azure Preview portalを意訳した投稿です。

価格体系

始める前に価格体系を確認しておきましょう。
価格体系は、[Azure Search PREVIEW Pricing Details]で説明されています。

Azure Searchは、[Search units]の組み合わせで販売されます。
秒間クエリ(queries-per-second/QPS)ベンチマークとドキュメントカウント(インデックスストレージ)ベンチマークによって、Unitが定義されます。

もっとQPSを増やしたい、もっとドキュメント数を増やしたい、もしくはその両方をしたい場合、Unitを増やすことになります。Unitを増やすことで、高可容性と性能を得られます。36スタンダードUnitオファーよりも性能が必要な場合は、[azuresearch_contact@microsoft.com]に連絡をする必要があります。

現在、プレビュー中なので、50%のプレビューディスカウント価格で提供されます。

  Free スタンダード
ストレージ 50MB 25GB/unit
秒間クエリ数 N/A 15/Unit
ドキュメント数 10,000ドキュメント
3インデックス
15,000,000/unit
50インデックス
スケールアウト制限 N/A 最大36nit
Unitあたりの時間単価 無料 17.14円/時間
データ転送 通常の転送料 通常の転送料

Azure Searchのチュートリアル

Azure PrevieポータルでAzure Searchの設定

Microsoft Azure Search(Public Preview)は新しいPreview Portalで提供されています。

学習目的や簡易テスト、小さな検索プロジェクト開発の為に使用できるマルチテナントの共有型の無償サービスが提供されています。

1.Azure Preview ポータルにアクセスします。

2.ページの下部にある[New]ボタンをクリックします。

 

3.ページ上部の[Everything]をクリックします。

 

4.ギャラリーから、[Data, storage, cache, + backup]をクリックします。

 

5.全てのデータ関連サービスを一覧表示するために、[See All]をクリックします。

 

6.Data Servicesから、Searchをクリックします。

7.Searchページの下部で、CREATEをクリックします。

8.サービスURLに私用するサービス名を小文字で入力します。ダッシュ、スペースを避けて、15文字以内の文字を入力します。

9.[Pricing Tier]をクリックし、価格オプションを選択します。FREEを選択肢、ページ下部のSELECTをクリックします。

10.Resource Groupをクリックし、既存のグループか新しいグループを選択します。

11.複数のサブスクリプションを持っていて、別のサブスクリプションでAzure Searchで使用したい場合は、Subscriptionをクリックし、選択します。

12.データセンターリージョンを選択するためにLocationを選択します。プレビュー中は、West US、East US、North Europe、Southeast Asiaから選択できます。複数のデータセンターをまたがってリソースを分散させることは、Public Preview中には設定が提供されていません。

URLとAPIキーの確認

数分で、サービスが作成されます。サービスに接続するには、URLとAPIキーが必要です。

1.Browser – Everything – Data, storage, cache, + backup – S Everything – Data, storage, cache, + backup – See All – Search Servicesの順にクリックし、Searchサービスのダッシュボードを開きます。

 

2.サービスダッシュボード上で、PROPERTIESとKEYSを見ます。

PROPERTIESには、サービスURLが記載されています。

KEYSには、ユーザー人商用のAPIキーが記載されています。

USAGEでは、ドキュメント数、提供リソース、ストレージ制限が記載されています。

動作確認

Search設定の最後に、クライアントアプリケーションからサービスにアクセスできるかを確認します。このテストには、Fiddlerを使用します。

インデックスの作成

1.Fiddlerを起動します。Fileメニューで、Capture Trafficをオフにします。Composerタブで、次のようにリクエストを記述します。

2.PUTを選択します。

3.Propertiesページに記載されているサービスURLをURLに指定します。

  • HTTPSプレフィックスを使用します
  • /indexes/hotels属性にリクエストします。これは、インデックス名[hotel]をSearchに作成します。
  • APIバージョンは小文字で、[?api-version=2014-07-31-preview"]と指定します。

(例)https://my-app.search.windows.net/indexes/hotels?api-version=2014-07-31-Preview

4.リクエストヘッダーを指定します。APIキーは自分のものに書き換えてください。

User-Agent: Fiddler
host: my-app.search.windows.net
content-type: application/json
api-key: 1111222233334444

5.リクエストボディーで、インデックス定義をします。

{
"name": "hotels",  
"fields": [
  {"name": "hotelId", "type": "Edm.String", "key":true, "searchable": false},
  {"name": "baseRate", "type": "Edm.Double"},
  {"name": "description", "type": "Edm.String", "filterable": false, "sortable": false, "facetable": false, "suggestions": true},
  {"name": "hotelName", "type": "Edm.String", "suggestions": true},
  {"name": "category", "type": "Edm.String"},
  {"name": "tags", "type": "Collection(Edm.String)"},
  {"name": "parkingIncluded", "type": "Edm.Boolean"},
  {"name": "smokingAllowed", "type": "Edm.Boolean"},
  {"name": "lastRenovationDate", "type": "Edm.DateTimeOffset"},
  {"name": "rating", "type": "Edm.Int32"},
  {"name": "location", "type": "Edm.GeographyPoint"}
 ] 
}

6.Executeをクリックします。

数秒で、HTTP 204レスポンスをセッション一覧で受け取ります。インデックスが作成されます。HTTP 504を受け取った場合は、HTTPSURLが間違っています。もしHTTP404の場合は、構文を確認してください。HTTP 400は、APIキーに問題があることを示しています。

ドキュメントの読み込み

Composerタブで、次のようにドキュメントをポストします。Bodyには4つのホテルの情報を記載しています。

1.POSTを選択します

2.HTTPSで次のようにURLを指定します。[/indexws/<index名>/docs/ndex?api-version=2014-07-31-preview]

(例)https://my-app.search.windows.net/indexes/hotels/docs/index?api-version=2014-07-31-Preview

3.リクエストヘッダーは前の手順と同じものを指定します。

User-Agent: Fiddler
host: my-app.search.windows.net
content-type: application/json
api-key: 1111222233334444

4.リクエストBodyには、ホテルインデックスに追加する4つのドキュメントが含まれています。

{
"value": [
{
    "@search.action": "upload",
    "hotelId": "1",
    "baseRate": 199.0,
    "description": "Best hotel in town",
    "hotelName": "Fancy Stay",
    "category": "Luxury",
    "tags": ["pool", "view", "wifi", "concierge"],
    "parkingIncluded": false,
    "smokingAllowed": false,
    "lastRenovationDate": "2010-06-27T00:00:00Z",
    "rating": 5,
    "location": { "type": "Point", "coordinates": [-122.131577, 47.678581] }
  },
  {
    "@search.action": "upload",
    "hotelId": "2",
    "baseRate": 79.99,
    "description": "Cheapest hotel in town",
    "hotelName": "Roach Motel",
    "category": "Budget",
    "tags": ["motel", "budget"],
    "parkingIncluded": true,
    "smokingAllowed": true,
    "lastRenovationDate": "1982-04-28T00:00:00Z",
    "rating": 1,
    "location": { "type": "Point", "coordinates": [-122.131577, 49.678581] }
  },
  {
    "@search.action": "upload",
    "hotelId": "3",
    "baseRate": 279.99,
    "description": "Surprisingly expensive",
    "hotelName": "Dew Drop Inn",
    "category": "Bed and Breakfast",
    "tags": ["charming", "quaint"],
    "parkingIncluded": true,
    "smokingAllowed": false,
    "lastRenovationDate": null,
    "rating": 4,
    "location": { "type": "Point", "coordinates": [-122.33207, 47.60621] }
  },
  {
    "@search.action": "upload",
    "hotelId": "4",
    "baseRate": 220.00,
    "description": "This could be the one",
    "hotelName": "A Hotel for Everyone",
    "category": "Basic hotel",
    "tags": ["pool", "wifi"],
    "parkingIncluded": true,
    "smokingAllowed": false,
    "lastRenovationDate": null,
    "rating": 4,
    "location": { "type": "Point", "coordinates": [-122.12151, 47.67399] }
  }
 ]
}

5.Executeをクリックします。

HTTP200レスポンスを数秒で受け取ります。その場合、ドキュメントの作成は成功です。207を取得した場合は、1つ以上のドキュメントのアップロードに失敗しています。404の場合は、ヘッダーやBodyを確認してください。

インデックスへのクエリ発行

インデックスとドキュメントの取り込みが完了しました。Composterタブで、GETコマンドを実行します。

1.GETを選択します。

2.URLに次のようなURLを指定します。

(例)https://my-app.search.windows.net/indexes/hotels/docs?search=motel&facet=category&facet=rating,values:1|2|3|4|5&api-version=2014-07-31-Preview

この検索クエリは、motelという単語とレーティングを指定しています。

3.リクエストヘッダーは前のものと同じものを使用します。

User-Agent: Fiddler
host: my-app.search.windows.net
content-type: application/json
api-key: 1111222233334444

レスポンスコードは、200いなるはずです。

クエリについては、http://msdn.microsoft.com/en-us/library/dn798927.aspxを参照してください。クエリにスペースが含まれる例が多いですが、Fiddlerでは許可されていません。スペースを+に置換してください。

オリジナル

GET /indexes/hotels/docs?search=*&$orderby=lastRenovationDate desc&api-version=2014-07-31-Preview

+に変更

GET /indexes/hotels/docs?search=*&$orderby=lastRenovationDate+desc&api-version=2014-07-31-Preview

Windows Azure

AzCopyを、お前らがもっと使えるようにガイドライン的なチュートリアルを用意してやるぜ!ってマイクロソフトがおっしゃって、ドキュメントがででで~んっと公開されています。

とりあえず、これを見ればAzCopyの全てがわかるって感じです。ここにかかれていない情報は、他にも書かれてないぜ!ぐらいの勢いで、大量の文章が用意されています。素敵。ぜひ日本語版も用意して!

主な使用例を抜粋。

 

  • 特定パターンに当てはまったBlobをアップロード
  • 別のストレージアカウントにBlobをコピーしてスナップショットをする
  • 複数のレスポンスファイルを指定する
  • ジャーナルファイルパスの指定
  • AzCopyのリジューム
  • 任意の場所にログ出力
  • 新しいファイルをBlobから取り除く
  • 古いファイルをBlobから取り除く
  • ストレージエミュレーターのBlobリソースに対してAzCopyの実行
  • Azure File共有からファイルシステムにファイルをダウンロード
  • Azure File共有からファイルシステムにファイルとディレクトリをダウンロード
  • ファイルシステムからファイルとディレクトリをAzure File共有にアップロード
  • 特定パターンにマッチしたファイルをAzure File共有にアップロード

Windows Azure

AzCopyの最新バージョンがリリースされました。
このバージョンでは、パフォーマンスや使用勝手の重要な改善が含まれています。

いくつか抜粋して紹介します。
アップデートの全体像は、原文を参照してください。

  • デフォルトでジャーナルファイルが生成されるようになりました。
    従来は、[/z]オプションが必要でしたが、今回のバージョンから指定しなくても生成されるようになりました。ジャーナルファイルは、デフォルトでは、%localAppData%\Microsoft\Azure\AzCopy\に格納されます。格納先パスは、/zオプションで宇和がクコとができます。
  • AzCopyの実行ログのデフォルトフォルダーが、%localAppData%\Microsoft\Azure\AzCopy\になりました。
  • インストールウィザードで、AzCopyのインストール先を指定できるようになりました。