"Internet of Things" (モノのインターネット)

Windows Azure サービス バスを "モノ" に使用する

Clemens Vasters

最近、品揃えの良い電気店をぶらついてみると (または Web で閲覧すると)、ネットワークに接続できる "モノ" がずらりと並んでいるのを目にします。携帯電話、タブレット、ノート PC やデスクトップはもちろん、テレビやブルーレイ プレイヤー、セットトップ ボックスに限った話ではありません。コーヒー メーカー、冷蔵庫、フォトフレームや車庫の開閉機、エアコン、警報装置などもあります。オフィスビルなどの産業環境や商業環境でカバー パネルの周りや裏を見ると、温湿度計、モーション センサー、監視カメラなど、さまざまなセンサーやコントロール スイッチが見つかります。

こうした装置の多くは、温度、コーヒーを入れる数、コーヒー豆を挽くときの粗さ、会議室にだれもおらず、消灯できることを示す赤外線画像など、役に立つデータを生成しています。

同様に、子供 (ペット) の最近の写真を祖母の食器棚の上にあるフォトフレームに送るといった、なんらかのデータを "モノ" にアップロードするシナリオや、遠くからスイッチを操作して家の温度を 1 度上げるといったシナリオも簡単に想像できます (遠くというのが 3G/4G の携帯電話会社のネットワークに携帯電話を接続するだけのことであっても)。ネットワーキングの点では、新しい時代に入ったと言えますが、消費者の目線からは、家でスイッチを操作するのと、2 週間の休暇が終わり空港からタクシーで帰る途中に操作するのとではたいした違いはありません。

接続型のデバイスには、大きな可能性があります。先見性のあるクラウドの開発者は、携帯電話、タブレット、さまざまなフォーム ファクターの PC など、人が操作することを前提とした汎用の画面付きデバイス用にアプリケーションを作成するよりも、特殊な目的のデバイスにサービスを提供する方が多くの収益を上げられる可能性があります。特にこうしたサービスを、"ビッグ データ" の分析に関連するクラウド テクノロジと組み合わせると効果が高まります。

シナリオ

アーキテクチャを説明するために、エアコン用にサービスとしてのソフトウェア (SaaS) を提供することを考えてみます。このシナリオは架空ですが、数値、パターン、および規模は Windows Azure チームがパートナーや顧客と話し合う実際のシナリオに非常に近いものです。

ビジネスの点から見てエアコンがすばらしいところは、十分な需要があり、地球の気候変動からして近い将来不要になることはないということです。反面、電気を大量に消費し、高温地域では送電網に過負荷がかかり、電圧の低下が余儀なくされるという欠点もあります。

ここでアーキテクチャの概要を示す SaaS ソリューションは電力会社が対象です。この電力会社は、エアコンの容量を管理し、送電網が機能不全に陥りそうなときに空調管理システムを広範かつ緊急に調整できるしくみを作るための分析レポートを求めています。

顧客は、送電網が停止し、摂氏 38 度 (華氏 100 度) の屋外の焼け付くような暑さになんの防御もなくなるよりは、まだ居心地が良いと感じられる摂氏 27 度 (華氏 80 度) まで室温が強制的に調整される方を望むでしょう。

さらに、この SaaS を多くの空調機器メーカーと連携させて必要なハードウェアやプロトコルを統合することも想定します。いったんエアコンを取り付けサービスに接続したら、利用者が携帯電話やタブレットからエアコンを監視して管理できるアプリを、電力会社や空調機メーカーのブランドでモバイル アプリ ストアから販売するチャンスが生まれます。図 1 に、このシナリオの概要を示します。

図 1 SaaS ソリューションの概要

ソリューションを設計する際、メッセージ トラフィックの 2 つの方向を取り決める必要があります。着信 (クラウドから見て) では、エアコンからメトリックとイベントを収集し、データを集約して、分析システムに渡します。発信では、エアコンに制御コマンドを送信します。

それぞれのエアコンは、必要に応じて 1 時間に 1 回から 10 分に 1 回までの範囲で、湿度、温度、エアコン状態の情報を送信します。また、エアコンの状態変化は、イベントを発生させて送信します。制御コマンドの頻度は少なく、おそらくエアコン 1 台につき 1 日に多くて 1 回か 2 回です。

立ち上げ 1 年目は 25 万台のエアコンを目標にし、3 年目には 250 万台に増やすことを考えます。この規模から、1 年目は 1 時間あたり 25 万から 150 万のイベントの発生が予想され、3 年目からは 1 時間あたり約 250 万から 1,500 万のイベントの発生が予想されます。

ソリューションを設計する

アーキテクチャでは、プロビジョニング、イベントのファンイン、およびコマンドのファンアウトの 3 つの主要懸案分野に取り組む必要があります。

プロビジョニングでは、新しいエアコンの設定、システム内での一意 ID の割り当て、各エアコンへのその ID を証明する手段の提供が必要です。さらに、エアコンをシステム内の特定のリソースに関連付ける必要があり、エアコンはこうした情報をすべて含む構成ドキュメントを受け取る必要があります。

イベントのファンインでは、イベント取り込みに必要なスループットを処理できるようにシステムを設計する必要があります。1 時間あたり 1,500 万個のイベントは、1 秒あたり 4,200 個のイベント (四捨五入) に相当することから、システムをパーティション分割する方法についてよく考える必要があります。これらのイベントはそれぞれの利用者がリモート接続する 4,200 の別々のソースから発生し、新しいセッションの確立には潜在的に大きなネットワーク待機時間を伴うことを特に考慮する必要があります。

特定の住居単位のイベントと結果の統計は、マクロ レベルでも使用しますが、このモバイル アプリを購入し、正確な使用傾向のグラフを求める住人にも提供する必要があるため、集約したデータを分析に回すだけでなく、1 日あたり 3 億 6 千万のイベントを保持する方法を明らかにする必要があります。

コマンドのファンアウトは、エアコンへのコマンドのフローを処理します。コマンドは、エアコンに構成の変更を指示したり、エアコンに状態イベントを生成するように指示する状態問い合わせになります。電力会社が送電網への負担を軽減するためにエアコンを一括調整する必要がある場合は、すべてのエアコンに 1 回で可能な限り迅速に単一のコマンドを送信するのが望ましいでしょう。住民が快適な温度に調節したいときに携帯電話を使う場合のコマンドは、特定のエアコンか、住居内のすべてのエアコンを対象にします。

イベントのファンイン

図 2 に示すのは、エアコンのシナリオ用ファンイン モデルの一般的なレイアウトです。

図 2 ファンイン モデル

このアーキテクチャから明らかになる第 1 の点は、パーティションが存在することです。接続された数百万台のエアコンを全体として捉えるのではなく、エアコンの台数を細分化して、数千台のエアコンを単位とする管理しやすいパーティションにします。ただし、パーティションを導入するのは管理を容易にするためだけではありません。

まず、分散システムの各リソースにはスループットとストレージの容量の限界があります。そのため、単一のサービス バス トピックに関連付けられるエアコンの台数を制限し、エアコンから送信されるイベント数がトピックのスループットの容量を超えないようにして、一時的に構築されるメッセージのバックログがトピックのストレージ容量を超えないようにします。次に、適切なコンピューティング リソースを割り当て、書き込みが多すぎてストレージのバックエンドに過大な負荷をかけないようにします。そのため、パフォーマンスの特徴を十分把握している比較的小さなリソースのセットを、自立した、多くの場合分離された "スケールユニット" にまとめます。

それぞれのスケールユニットが最大数のエアコンをサポートします。これは立ち上げ時のスケーラビリティのリスクを軽減するために重要です。スケールユニットを導入する効果の良い面は、システム全体が停止するリスクが大幅に軽減されることです。システムが 1 つのデータ ストアに依存していると、そのストアの使用に問題があったら、システム全体に影響が及びます。システムを 10 個のスケールユニットから構成し、それぞれが独立したストアを管理していれば、1 つのストアの問題はシステム全体の 10% にしか影響しません。

図 2 で示したアーキテクチャでは、エアコンはソリューションが直接提供するサービス エッジではなく、Windows Azure サービス バスのトピックにすべてのイベントをドロップします。Windows Azure サービス バスには、送受信用にスケールアウトされセキュリティが確保されるネットワーク サービス ゲートウェイが既に存在するため、できる限りその機能を活用するのが当然です。

今回のシナリオでは、エアコンに HTTPS をサポートする機能があり、そのため既存のプロトコルのサポートで Windows Azure サービス バスと直接やり取りできることを想定しています。ただし、エアコンが安価で小型になり、メモリを数キロバイトしか搭載せず、プロセッサも遅いため、SSL (および HTTPS) のサポートは大きな課題になり、HTTP さえ非常に重くなります。カスタム プロトコルか業界特有のプロトコルを使用して、カスタム ネットワーク ゲートウェイを構築、実行する方が適している場合もあります (図2 の右端参照)。

それぞれの取り込みトピックは、3 つのサブスクリプションから構成されます。最初のサブスクリプションは受け取ったイベントをイベント ストアに書き込むストレージ ライター用、2 つ目のサブスクリプションはイベントをまとめてグローバル統計システムに渡す集計コンポーネント用、3 つ目のサブスクリプションはエアコン管理システムへのメッセージ ルーティング用です。

これらのトピックごとにスループットの制限があるため、エンティティ レベルで 1 秒あたり平均 100 件のメッセージを想定します。送信されたイベントごとにコピーを 3 つ作成してルーティングするとすると、各トピックに 1 秒あたり最大約 33 件のメッセージを取り込めます。これは、明らかに (非常に) 控えめな数字です。このように慎重な想定にしている理由は、1 時間ごとにメッセージを送信する分散デバイスに対応し、1 時間に送信されるイベントが完全にランダムな分布で発生するとは考えにくいためです。イベントの間隔が 10 分で、エアコンごとに 1 時間あたり 1 つの追加の制御操作フィードバック メッセージが送信される最悪のシナリオを考えると、エアコン 1 台あたり 1 時間にメッセージを 7 件送信すると予想でき、端数を切り捨てると各トピックに約 5 万台のエアコンを関連付けらることになります。

このレートはストレージのスループットには何も問題ありませんが、イベント ストアのストレージ容量と管理の容易さは問題です。5 万台のエアコンを 1 時間に処理すると、エアコン 1 台のイベント データは、1 年あたり約 4 億 3,800 万件記録されることになります。このような記録をパッキングし、たとえば記録ごとに 50 バイトしか使用しない方法を考えだしたとしても、ペイロード データはスケールユニットごとに 1 年あたり 22 GB になります。これでもまだ管理可能ですが、同時にスケールユニットの大きさを検討する際にはストレージ容量とストレージ数の増加に注意すべきことは明らかです。

1 年目の立ち上げ予測を基にすると、1 年目には 5 つ、3 年目以降は 50 のスケールユニットが必要です。

イベントを格納、取得、および集計する

発生するイベントを処理して使用する方法をさらに詳しく見ていきます。この方法を示すため、1 つのスケールユニットに注目します (図 3 参照)。

図 3 スケールユニット

エアコンが発信するメッセージは、制御への返信とイベントの 2 つに大きく分けられます。制御への返信は、制御システムのサブスクリプションによってフィルター処理されます。イベントには、エアコンの現在状態とセンサーの読み取り情報が含まれ、別のサブスクリプションを通じてストレージ ライターとアグリゲーターにルーティングされます。

ストレージ ライターは、サブスクリプションから受け取ったイベントをイベント ストアに書き込みます。

イベントの格納先には Windows Azure テーブル ストレージが適しています。パーティション分割モデルをサポートするため、ストレージ アカウントをシステム内のすべてのパーティションで共有し、パーティションごとに 1 つテーブルを用意します。テーブル ストアはデータ行をストレージ セクションに割り当てるのにパーティション キーが必要で、そのキーにエアコンの ID を使用すると、統計の履歴からグラフを作成するときのルックアップのパフォーマンスが向上します。行のキーには、単に簡潔な YYYYMMDDHHMMSS 形式で文字列にエンコードしたタイムスタンプを使用し、これを時系列での並べ替えと、グラフの作成範囲のクエリに使用します。また、この場合、各エアコンが 1 秒未満の間隔でイベントを送信することはないため、競合の可能性について心配する必要はありません。タイムスタンプは、Windows Azure サービス バスのブローカーが受信するメッセージに自動的にスタンプする、メッセージの EnqueuedTimeUtc プロパティから導き出します。そのため、エアコンのタイマーを使用することはありません。競合の可能性があり、スループットの高いソリューションを構築する場合は、ブローカーが各メッセージにスタンプする、一意で連続する 64 ビット ID としてメッセージの SequenceNumber プロパティも活用できます。

アグリゲーターは、受信するイベントを受け取って集約し、分析インフラストラクチャをフィードするシステム全体の統計トピックの 1 つに渡します。これは多くの場合、特定の期間の一連のイベントを平均するか合計し、その結果の値のみを渡すことで行います。今回の場合、近隣の住居を単位として 15 分間隔で消費電力や温度の情報の傾向を把握します。そのためアグリゲーターは、それぞれがデータの約半分を処理する 2 つの Web ロールをまたがって実行され、近隣住居のエアコンの地図を管理し、エアコンからイベントが着信したときに、近隣の住居をまとめてデータを集計し、15 分間隔で算出した集計を添えてイベントを発生します。それぞれのアグリゲーター インスタンスはイベントの半分しか見ないので、統計トピックの分析バックエンドは最後に 2 つのイベントをまとめて、近隣全体の情報を取得します。

MSDN Magazine のこのシリーズ 1 回目の記事「"Internet of Things" (モノのインターネット) をビルドする」(msdn.microsoft.com/magazine/hh852591) では、デバイスの文脈における Microsoft StreamInsight の使用について説明しました。これは情報をまとめる段階を示す良い例で、そのとき取り上げた例をこのアーキテクチャのアグリゲーターの代わりに使用できます。

コマンドのファンアウト、ターゲットの指定、および応答の収集

図 4 に示すように、制御システムはトピックにコマンドを送信し、エアコンはコマンドのファンアウト用にサブスクリプションからメッセージを受け取ります。

図 4 ファンアウト モデル

エアコン別にサブスクリプションを使用する主な理由は信頼性です。コマンドを送信するときにエアコンの電源が入っていなかったり、一時的に接続されていない場合でも、最終的にはコマンドがエアコンに到着する必要があります。そこで、エアコンのメールボックスに相当するものが必要です。

信頼性と柔軟性が追加される代わりに、いくらか複雑になります。前半でエンティティごとのスループットの制限について触れましたが、これは Windows Azure サービス バスが各トピックで許容するサブスクリプションの数にも表されています。現在、システム クォータはトピック 1 つにつきサブスクリプションが 2,000 までに制限されています。ファンアウト シナリオでトピックごとにサブスクリプションを実際にいくつ割り当てるかは、メッセージ フローの希望レートによって決まります。メッセージをフィルター処理して選択しサブスクリプションに追加するのにかかるコストは、コピー操作と考えられます。そのため、サブスクリプションを 1,000 個含むトピックは、エンティティあたり 1 秒間に 1,000 通のメッセージを処理するスループットを想定すると、メッセージ フローは 1 秒につき 1 通というレートになります。

緊急のコマンドの場合、ブロードキャスト方式で、接続しているすべてのエアコンに 1 つのコマンドを送信する必要があります。ユーザーが 3G に接続されたアプリケーションを使用して特定のエアコンや特定の住居の温度を調整するといった、ターゲットを指定するコマンドの場合、調整は数秒以内に実行する必要があります。

ターゲットを指定するコマンドの場合にも 1 秒につき 1 通のメッセージでうまく機能するかを確かめるため、住民が空調管理システムの調整や現在状態の問い合わせをあまり行わないものとします。ほとんどのコマンドは、特定の気象状況で発行されると予想できます。最悪のケースを想定し、すべてのエアコンが 1 日に 1 回調整され、多くの調整が午前 7 時から午後 7 時までの間に行われるとします。ブロードキャスト方式を採用し、トピックのサブスクリプションが 1,000 個に制限される場合を考えると、このようなコマンドは 1 分間に 1.4 通のメッセージを処理することになります。全員が同じ １ 時間の間にエアコンの電源を入れた場合でも、1 分間に約 16 通のメッセージを処理すれば大丈夫です。このようなスケールとスループットを考慮すると、それぞれのファンアウト トピックのサブスクリプションを 1,000 個に制限し、スケールユニットごとにファンアウト トピックが 50 個必要になります。

メッセージの対象を特定のエアコン単位や住居単位に送るか、サブスクリプションのフィルターを使用して、すべてのエアコンにブロードキャスト方式でメッセージを送ることができます。図 5 は、メッセージが特定の DeviceId または特定の HousingUnit のプロパティか、true に設定したカスタムの Broadcast プロパティを伴うようにする単純なフィルターを示しています。これらの条件のいずれかが true の場合、メッセージはそのサブスクリプション用に選択されます。そのため、制御システムはブロードキャストされるメッセージとターゲットが指定されるメッセージのどちらにもまったく同じトピックを使用でき、メッセージに対応するルーティング プロパティを設定してターゲットを選択できます。

図 5 メッセージのターゲット指定

制御システムは、ファンイン側のサブスクリプションを介してコマンドへの応答を取得でき、コマンド応答は同様の方法で処理される特殊なフィルター プロパティを返信します。

名前空間の構造、プロビジョニング、およびエアコンの ID

Windows Azure サービス バスは、名前空間の概念を使用してリソースを整理し、それらのリソースへのアクセスを管理します。名前空間は Windows Azure ポータルで作成され、特定のデータセンターの地域に関連付けられます。ソリューションが複数の地理的に広大な地域をまたがる場合、名前空間を複数作成して特定の Windows Azure データセンターにリソースとクライアントを結びつけると、ネットワークのルートが短くなるという明らかなメリットがあります。このソリューションでは、北部中央アメリカ地域 (clemensv-ac-ncus-prod.servicebus.windows.net) と南部中央アメリカ地域 (clemensv-ac-scus-prod) に名前空間を 1 つずつ作成するか、特定の顧客用に名前空間を作成します (clemensv­ac-myenergy-prod)。"prod" というサフィックスは、製品の名前空間を、起こり得る平行テストやステージングの名前空間と区別するために付けています。

スケールユニットの設定と管理を簡単にするため、名前空間の階層構造を活用します。スケールユニット内のすべてのエンティティへの基本パスを形成するスケールユニット名は、ただの数字でも、特定の顧客 (/myenergy-3) と関連付けてもかまいません。単一の取り込みトピックを用意しているため、その直下に配置でき (/myenergy-3/fan-in)、トピックに番号を付けるだけで、別のセグメントの下にファンアウト トピックを配置できます (/myenergy-3/fan-out/01)。個々のエアコン用のファンアウト サブスクリプションはこの構造の従い、エアコンの ID をサブスクリプション名に使用します (/myenergy-3/fan-out/01/subscriptions/0123456)。

新しいスケールユニットを作成するのは、(Windows Azure サービス バス API を使用する) 事実上管理スクリプトで、この形状の新しい構造を作成します。エアコン用のサブスクリプションとフィルターの規則は、エアコンのプロビジョニングの間に作成します。当然ながら、対応するストレージとコンピューティングのリソースを作成、配置、および構成することも必要です。前述のように、このイベント ストアではスケールユニットごとに新しいテーブルを設定します。

プロビジョニングとは、住居単位に取り付けるときに、工場から新たなエアコンを製造することです。今回は、エアコンの非アクティブ化などの詳細は省き、工場で一意な ID を持つエアコンを設置するためのプロビジョニング モデルについてのみ説明します。もう 1 つのモデルでは、まったく初期化していないエアコンを工場で製造し、Netflix、Hulu、Twitter などのサービスで行われているのと似た方法を実装します。つまり、Web サービスに接続した新しいエアコンは、コードを取得して表示し、ユーザーはそのコードを入力することでユーザー登録サイトにログオンします。

図 6 に示すのは、事前に ID が割り当てられたエアコンをプロビジョニングするフローです。エアコンを設定する最初の手順は示されておらず、有線の Ethernet、Wi-Fi、またはなんらかの無線の通信ネットワークを介して行われる、ネットワーク上でのデバイスの取得を処理します。

図 6 プロビジョニング モデル

プロビジョニングでは、システムは設定と、デバイスの ID と構成の管理を処理する特殊な Web サービスを実行します。パーティションのアロケーターは、ユーザー登録されたエアコンの数と、どのエアコンがどのスケールユニットに割り当てられるかを追跡します。エアコンがスケールユニットと関連付けられたら、そのエアコンはそのスケールユニットにプロビジョニングされます。

手順 1. で、エアコンは ID を提示してプロビジョニング サービスと接続を確立します。このモデルでは、発行されたエアコン ID はすべて許可リスト (手順 2.) に配置され、エアコンのユーザー登録を 1 回許可します。エアコンのユーザー登録が可能だと確認されたら、プロビジョニング サービスはアクセス制御サービス (ACS) を呼び出し、新しいサービス ID とエアコンのキーを作成します (手順 3.)。さらに、取り込みトピック用の "Send (送信)" 許可規則を作成し、手順 4. ですぐに作成されるファンアウト サブスクリプション用の "Listen (リッスン)" 規則を作成します。これらを使用して、エアコンのアカウントはシステムにアクセスするのに必要な唯一適切な権利を取得します。手順 4. を完了すると、エアコンが操作するすべてのリソース URI のコレクションと、エアコンがトークンを取得するために ACS に対する認証に使用するアカウントとキーの準備が整います。これらの情報はすべて、エアコンのユーザー登録呼び出しへの応答にまとめられ、エアコンがその情報を恒久的な構成ストレージに書き込みます。

今回は相当量のスケールアウト パーティショニングを紹介しましたが、アクセス制御の ID はここの例ではパーティションに分割されていないことに注目してください。

ACS への負担を和らげるには、単に顧客に提供するトークンを減らします。Windows Azure サービス バスのパーティ定義による ACS の既定のトークンの期限は、1,200 秒、つまり 20 分です。最大 24 時間、つまり 86,400 秒まで発信でき、エアコンのキャッシュがその時間分のトークンを取得するようにできます。この場合、エアコンが新しいトークンを取得する必要があるのは 1 日 1 回だけになります。唯一の欠点は、長期間存続するトークンがインターセプトされるとトークンのベアラへのアクセスを呼び出せなくなることですが、特定のエンティティで送信またはリッスンするように制約されるトークンでは、このような欠点があっても耐えられるでしょう。

クラウドの場合

今後数年間、Windows Azure サービス バス チームは、"モノ" をクラウドに接続すること、またはクラウドを通じて接続することに大きな関心を払うでしょう。今回概略を示したアーキテクチャはすぐれた出発点と考えられ、たとえばスケールユニットの概念において、Windows Azure サービス バスを構築すること自体から苦労して獲得したベスト プラクティスが含まれています。メッセージ フロー、アグリゲーション、および分布のシナリオについては、容量に関してのみではなく、より簡単なプログラミングと構成モデルに関して、多くの最適化の余地が残っています。

今後数か月以内に Windows Azure サービス バスで、自動転送などのいくつかの最適化が見られるようになり、チームはこれらの新機能を活用してより良い抽象化を作成し、ここで紹介したようなスケールアウト シナリオの管理を簡略化するでしょう。数百万ものデバイスに迅速にイベントを分散するには、常に膨大な数の個別のシステム リソースが必要になりますが、移動するパーツが目に止まる数を減らすために追加できる抽象化の手法がたくさんあります。

シナリオをより具体的で楽しくするため、このシリーズの次回の記事では Microsoft .NET Micro Framework で動かすシンプルなエアコン (ハードウェアです) を構築します。このちょっとした自作用のエアコンは、ここで説明した一般的なアーキテクチャに従う Windows Azure サービス バスを介してバックエンド サービスと通信します。また次回お会いしましょう。

Clemens Vasters は、Windows Azure サービス バス チームの主な技術リーダーです。Vasters は、最も初期のインキュベーションの段階からサービス バス チームに参加しており、プッシュ通知および Web やデバイスへの大規模なシグナル化を含む Windows Azure サービス バスの技術機能のロードマップに取り組んでいます。カンファレンスにも頻繁に登壇しており、アーキテクチャのコースウェアも数多く執筆しています。Twitter (twitter.com/clemensv、英語) で彼をフォローしてください。

この記事のレビューに協力してくれた技術スタッフの Elio Damaggio、Abhishek Lal、Colin Miller、および Todd Holmquist-Sutherland に心より感謝いたします。