私たちが使用するさまざまな "画面" に共通して普及の度合いを増しているのが、軽量な通知機能という概念です。当初は Windows ガジェットがこういった役割を担うことを目指していました。重要な情報 (たとえばニュース、天気、スポーツのスコア、基幹業務関連のイベントなど) をすばやく表示するためのヘッドアップ ディスプレイを提供するという趣旨です。しかしながら、ガジェットの起動時間や動作モデルは、全体的な電力消費量の削減 (デスクトップ PC でもノート PC でも重要な要素です) や、開発者のための全画面表示のプラットフォーム提供といった取り組みとは相容れないものです。また、Windows 8 の [Start] (スタート) 画面では、こういった通知に利用できる面積が大幅に広がると共に、ユーザー主導のインターフェイスを通してデータの更新 (ネットワーク リソースの使用を含めて) を管理できるようになっています。プッシュ配信や構造化されたスニペットを通して提供される情報の比率が増え続けている近代的なエクスペリエンスにおいては、このことが開発者にとってもエンド ユーザーにとってもユニークな機会をもたらします。今回の記事では、Metro スタイルのライブ タイルの開発と、このアーキテクチャが多数のタイルに対応しながら全体的な電力消費量とシステム負荷の軽減を実現するしくみについて、Ryan Haveson がご紹介します。
–Steven Sinofsky

パフォーマンスとバッテリの寿命が Windows の成功に欠かせない重要な要素だというのは、見解の一致するところでしょう。このブログにいただいているコメントでも、一貫してこれらの点が強調されています。KISSmakesmeSMILE さんのコメントはこの点をよく示したものです。

「...軽負荷/低負荷使用時のバッテリ寿命で、(競合製品と) 同等か、できることならより優れたパフォーマンスを実現してみてほしい」

同時に、すべての近代的な環境 (PC からテレビ、電話まで) において、なんらかの形でガジェット、ウィジェット、プラグインなどのモデルが採用され、ひとめで情報を確認できるようになっているのも事実です。テレビでニュース、スポーツ、天気などを見ていても、複数のソースからの情報がリアルタイムでまとめられ、構造化された画面に表示されています。ユーザーが期待するのは、株価、天気、未読メール数、次の予定、基幹業務アプリケーションの状態、ソーシャル ネットワークの状態などをすばやく確認し、数秒のうちに元の作業に戻ることができるというような動作です。多くの点で、PC はこの領域において他のデバイスに後れを取っていると言えるでしょう。通知インフラストラクチャの設計を始めるにあたっての私たちの課題は、アクティビティを生きた情報として表示しながら、電力消費と帯域幅の使用量においてきわめて高い効率を維持することでした。AndyCadley さんのコメントはこの目標をよく表現しています。

「"Metro" アプリを、常に起動している (ただしバッテリやパフォーマンスにはまったく影響がない) ものとして扱う」

[Start] (スタート) 画面では、ユーザー モデルの観点からもこの点の効率性が強化されており、デスクトップ アプリや Metro スタイル アプリの使用を邪魔することなく、全画面表示のヘッドアップ ディスプレイを提供することができます。これに加え、効率性を追求するだけではなく、通知機能を持つアプリをどれだけたくさんインストールしても、パフォーマンスやバッテリ寿命への影響を心配する必要がないようにしたいとも考えました。

Windows 8 を社内で使用してきてわかったのは、基幹業務アプリケーションのための一元化された読みやすいヘッドアップ ディスプレイとして、[Start] (スタート) 画面は生産性の向上に寄与する有効なツールだということです。通知機能を中心に据えたアプリに、強い関心が集まっています。新しいプッシュ通知プラットフォームのスケーラビリティを活かすことで、Windows 8 ではこのような機能を最低限のシステム負荷で実現することができます。これは、多種多様なメカニズムが使用されている今日の Windows の状況と比べて、大幅な改善と言えます。キー操作 1 回で呼び出せる [Start] (スタート) 画面が提供する、よく整理され、管理された集約的な通知領域としての機能に、最もデスクトップ志向の強いユーザーでさえも高い価値を見いだすシナリオが (特に早い段階で) 登場することは、想像に難くありません。

通知プラットフォームの目標

何百ものアプリのタイルでアクティビティを生きた情報として表示しつつ、同時にパフォーマンスの低下を防ぐというのは、両立が難しい目標のように思えるかもしれません。そもそも "アクティビティ" というものが本質的にリソースを消費するものです。たとえば、クラウドから通知を取得するにはネットワークが必要ですし、通知をタイルに表示する際は GPU/CPU リソースが使用されます。正しい設計を実現するには、最初に設定した以下の目標を常に意識する必要がありました。

  • パフォーマンスを犠牲にすることなく何百ものライブ タイルの表示に対応する
  • バルーン、アイコン、テキストなどのレベルを超える、美しい画像を使った表示
  • 開発者にとって扱いやすい "ファイア アンド フォーゲット" (お任せ) 型のモデル
  • インスタント メッセージが "インスタント" に届くリアルタイム性の実現

これらの目標を踏まえ、アーキテクチャ上の基本方針として最初に決定されたのは、データドリブンなプラットフォームにするということでした。つまり、[Start] (スタート) 画面を動かすために背景でアプリのコードが実行されていてはいけないということです。

通知を表示するシステムの構成は、いくつかのパーツに分けて捉えることができます。接続するタイミングを決めるロジック、認証、ローカル キャッシュ、レンダリング、エラー処理、バックオフ アルゴリズム、帯域幅の調整などがあるほか、サービス側の問題への対応、たとえばネットワーク接続の有無に応じて、未配信コンテンツのキャッシュや複雑な再試行シナリオの処理も行う必要があります。こういった動作のためのクライアント/サーバー コードを、一つ一つのアプリが独自に持っていたらどうなるか、想像してみてください。各実装でそれぞれ発生するバグに対応しなければならないばかりか、本質的には同じ内容のコードをアプリごとに重複してメモリにロードすることになり、ディスクへのコードのページングも頻繁に発生します。これは非常に非効率的です。[Start] (スタート) 画面をライブ状態に保つために、すべてのアプリが常時動作していることになるのです。大容量のメモリを搭載したマシンであっても、システムのパフォーマンスはいずれ非常に低いレベルまで低下してしまうでしょう。

Windows 8 におけるメモリ使用量の削減を扱った Bill Karagounis の記事をお読みになった方ならご存知のとおり、実行するプロセス、DLL、サービスなどの数が増えればパフォーマンスは低下します。各ライブ タイルがそれぞれ独自のコードを実行するモデルでは、パフォーマンスを犠牲にせずに何百ものライブ タイルに対応するという第一の目標は達成できません。

解決策は、データドリブンなモデルを構築することでした。このモデルでは、開発者は事前定義済みのプロパティやテンプレートを使ってタイルを表現します。その方法としてこの場合に使用するのは、XML スキーマです。XML によるタイルのデータは、単純な HTTP POST によって Windows プッシュ通知サービス (WNS) へと送信され、あとは自動的に処理されます。接続、再試行、認証、キャッシュ、レンダリング、エラー処理などを行うコードはすべて、電力効率に優れた統一的な方法で処理されます。

次に示すのは、開発者が Windows 8 アプリに使用することができる数多くのタイルのテンプレート (英語) の中の一例です。この例はテキスト フィールド 1 つと画像 1 つから成るものですが、他にもさまざまなテンプレートが用意されています。

サーファーの画像と RSS フィード アイコン、"First ever surfboard kickflip recorded in Santa Cruz" というテキストが表示されている
図 1: テンプレートの例 (TileWideImageAndText (英語))

上のタイルに対応する XML コードは次のようになります。

<?xml version="1.0" encoding="utf-8"?>
<tile>
<visual lang="en-US">
<binding template="TileWideImageAndText">
<image id="1" src="http://www.fabrikam.com/kickflip.png"/>
<text id="1">First ever surfboard kickflip recorded in Santa
Cruz</text>
</binding>
</visual>
</tile>

データドリブンなモデルの採用により、最初の 2 つの目標 (パフォーマンスと高品質なエクスペリエンス) は実現することができましたが、リアルタイムの表示と "ファイア アンド フォーゲット" 方式の効率性という点はまだ残っています。

クライアント/サーバー間でのコンテンツ配信において、高レベルでの設計パターンにはポーリング方式とプッシュ方式の 2 種類があります。ポーリングでは、クライアントが定期的に (たとえば 90 分おきに) サービスに対する問い合わせを行い、新しいコンテンツがないか確認します。プッシュでは、新しいコンテンツがある場合に、サービスがクライアントへと直接データを送ります。

ポーリング モデルでリアルタイムの通知をサポートするには、十分な頻度で (たとえば 5 秒おきに) ポーリングを行うしかありません。これによって、新着メッセージを概ねリアルタイムに表示することができます。しかしこれはパフォーマンス面の目標を大きく阻害するものです。5 秒間隔のポーリングでは、ネットワーク ラジオのスタックはいつまでもアイドルにならず、バッテリ寿命は大幅に低下し、デスクトップ PC は常時電源がオンになってしまいます。ちょうど携帯電話を通話中のままにするようなものです。バッテリが長持ちするはずはありません。そのうえ、5 秒ごとにサーバーへの問い合わせを行ったとすれば、ほとんどの場合新しいコンテンツがないことになるため、非常に無駄が多くなります。従来の通知領域アイコンや Vista で導入されたガジェットは、ポーリングを使ったものでした。しかしポーリング方式では、どのようなメカニズムであれ、即時的なリアルタイム性を求める今日のサービスに対応できるような短い間隔を設定することはできません。

このため、Windows 8 ではプッシュ ベースのサービスを構築することにしました。これは大きな決断でした。なぜなら、私たちが構築するプラットフォームは、グローバルな規模に対応し、将来的には何十万ものアプリや 10 億人以上のユーザーに対応するものでなければならないからです。一方で、この取り組みの価値は明らかでした。開発者は、クライアントへの固定接続を独自に開発したり管理したりすることなく、きわめて効率的なリアルタイムの通知機能を無料でユーザーに提供することができるのです。

プッシュ通知のプラットフォーム

それでは、プラットフォームのさまざまなコンポーネントを詳しく見ながら、このデザインの細かい部分を解説していきましょう。下の図には 3 つの主要なエンティティが示されています。

  1. Windows プッシュ通知サービス (WNS): ライブ タイルとトースト通知を動作させるサービスです。
  2. アプリのサービス: Metro スタイル アプリが (たとえばそのアプリの既存 Web サイトから) 実行する Web サービスで、トースト通知やタイルの更新データを WNS 経由で送信します。たとえば、Developer Preview (英語) にインストールされている Weather アプリのバックエンド サービスや、ソーシャル ネットワークのアプリ用に写真をホストするバックエンド サービスなどがこれにあたります。
  3. Windows 8 クライアント プラットフォーム: 実際の PC と、エンド ツー エンドのエクスペリエンスを構成する骨組みとなる OS 内のサブ コンポーネントに該当します。

アプリのバックエンド サービス、Windows プッシュ通知サービス (WNS) ("キャッシュ" というボックスが含まれる)、そして Windows 8 クライアント プラットフォーム ("タイル レンダラー"、"画像キャッシュ"、"WNS 接続" の各ボックスが含まれる) の 3 つの図が示されている。"1. プッシュ通知" と書かれた矢印がアプリのバックエンド サービスから WNS へと向いており、"2. 通知" と書かれた矢印が WNS からクライアント プラットフォームの WNS 接続に向いている。"3. 画像のフェッチ" と書かれた双方向の矢印が、アプリのバックエンド サービスとクライアント プラットフォームの画像キャッシュとをつないでいる。
図 2: プッシュ通知のプラットフォーム

一般的な利用シナリオをたどって、しくみを確認してみましょう。たとえば、アプリのサービスがソーシャル ネットワークのサイトであるとしましょう。ユーザーの写真にだれかがコメントを追加すると、サイトからタイルの更新データが送信されるしくみを想定します (あるいは、基幹業務アプリで、バグが自分にアサインされた場合や経費明細書に問題があった場合に通知を行うシナリオを想定していただいてもかまいません)。情報の更新が発生すると、アプリのサービスは WNS に通知を送ります (上の図のステップ 1)。次に、WNS がクライアントへと通知をプッシュします (ステップ 2)。[Start] (スタート) 画面でタイルを更新するべきタイミングになると、OS は通知の XML に含まれる URL に基づき、該当するアプリのサービスから画像をフェッチします (ステップ 3)。通知と画像のダウンロードが完了すると、アプリは XML で指定されたテンプレートに基づいてライブ タイルをレンダリングし、[Start] (スタート) 画面に表示します。

前述のとおり、"ファイア アンド フォーゲット" の実現も目標の一つでした。このため、PC がネットワーク接続されていない場合 (たとえばノート PC がスリープ状態の場合) のキャッシュ処理や再試行メカニズムのための複雑なコードを開発者が記述しなくてよいよう、次に PC がオンラインになるまで、1 つのアプリにつき 1 つの通知が WNS クラウドにキャッシュされるようになっています。

クライアント プラットフォームの各コンポーネントを設計するにあたっては、高いパフォーマンスと低い電力消費の実現を常に念頭に置きました。通知のペイロードと画像のペイロードを分離したことは、この取り組みの重要な一部です。一般的な通知の XML は 1 KB 未満ですが、画像は最大 150 KB にもなります。これらを分類することによって、画像の重複が多発するシナリオにおいて、ネットワーク帯域幅を大幅に節約することができました。たとえば、タイルに使用する画像が友人のプロフィール写真であれば、PC に一度ダウンロードした後はローカルにキャッシュして再利用することができます。通知と画像とを分類することで、未使用の通知の破棄をスマートに行い、余分な画像のダウンロードを省略することが可能になりました。デバイスの画面をオフにして仕事中は寝室に放置しているというケースを考えてみると、次にデバイスを使用するまでは画像をダウンロードしても意味がないことがわかります。後続の更新データで置き換えられてしまうに違いないからです。

認証モデル

ライブ タイルと通知機能はアプリのエクスペリエンスにおいて重要な位置を占めるものですので、アプリのサービスから [Start] (スタート) 画面上のタイルに至るまで、認証されたセキュアな通信チャネルを確保することが重要です。アプリや悪質な Web サービスが、マシン上のタイルを勝手に更新できてしまうようでは問題です。このため、匿名認証のメカニズムによって、PC と WNS の接続が一意に識別されるようになっています。また、アプリとアプリのサービスが WNS と通信する際にも認証が行われます。WNS への両方の接続で認証を行うことにより、ライブ タイルの悪用 (スプーフィング攻撃など) を防ぐことができます。WNS が使用する認証メカニズムでは、アプリケーションとサービスが明示的に関連付けられ、他のアプリケーション (または悪意のあるユーザー) が所有権のないタイルにコンテンツを送信することはできないようになっています。また、当然ながら、通信はすべてセキュリティで保護されたチャネルを通して行われます。

これらはすべて、Windows Live ID を使って Windows にサインインしているかどうかにかかわらず機能します。もちろん、Katie Frigon が Windows Live ID によるサインインについての記事でお話ししたように、接続されたアカウントを使用すれば、アプリからのクラウド ストレージの活用、Windows およびアプリの設定のローミング、複数のアプリへのシングル サインオンなどが可能になり、Windows 8 を最大限に活用することができます。プッシュ通知のプラットフォームでは匿名の認証メカニズムを使用しているため、たとえ Windows Live ID を使ってサインインしていても、アプリの開発者が通知のパイプラインを使って Windows Live ID やシステム情報、位置情報などを特定することはできないようになっています。

大規模展開に対応したサービスの設計

記事の前半でも既に触れましたが、このプラットフォームは、膨大な数のユーザーやアプリに対応できるよう設計する必要がありました。どの程度の規模か実感していただくため、アプリが 1 日あたりに Windows 8 に送信している通知の数を示したグラフをご覧ください。数週間前の時点で、既に毎日 9,000 万件以上のタイルの更新データを配信しています。しかも、これはまだベータ リリースですらないのです!

通知数は 2011 年 9 月 12 日の段階では 0 件、2011 年 9 月 16 日には約 6,400 万件まで急増した後、9 月 18 日には 3,600 万件まで減少し、その後徐々に増加を続けて 10 月上旬には 8,000 万~ 8,500 万件になっている。
図 3: Windows 8 Developer Preview に向けて送信された通知の 1 日あたりの数

Developer Preview ビルドに含まれるテスト アプリの中でも人気のあるものの一つとして、Stocks アプリがあります。次のグラフは、Developer Preview ビルドのリリースからの 1 か月のうちに、このアプリから登録されたライブ タイルの総数を示したものです。

Stocks アプリのライブ タイルの総数
図 4: Developer Preview の Stocks アプリで登録されたライブ タイルの数

Developer Preview のリリース直後から、私たちはデータ センターを通して入ってくるトラフィックを監視し、スケール アウトのようすを注意深くモニタリングしてきました。次のビデオは、//build/ カンファレンスでの Developer Preview リリースから最初の数日間に発生した通知の実際の地理的な分布をビジュアル化したものです。データは 1 平方マイルあたりの単位数で表示されており、幅広い濃度に対応するために対数目盛りが使用されている点にご注意ください。


ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4

WNS のデザインは Windows Live Messenger サービスのアーキテクチャに基づいており、実は、通知プラットフォームのサービスの部分は Windows Live Messenger と同じチームによって開発されています。このような規模にこれだけすばやく対応できるような、グローバルに展開可能なサービスを構築するだけの専門知識やノウハウを備えたチームは、世界中を探してもそう多くはありません。今日の Windows Live Messenger サービスの規模を実感していただくために、いくつか統計情報を挙げておきます。

  • 月間アクティブ ユーザー数 3 億人
  • 1 日あたりのログオン数 6 億 3,000 万回
  • 1 日あたりの通知数 100 億件
  • ピーク時の SOC (同時オンライン接続数) 4,000 万超
  • 世界中でメッセージのルーティングを行うマシン 3,000 台超

タスク マネージャーを使ったタイルのリソース使用量の確認

私たちが通知プラットフォームのパフォーマンス面に傾けた熱意は新しいタスク マネージャーにも反映されており、タイル プラットフォームが使用している帯域幅をアプリケーションごとにトラッキングするための測定項目が追加されています。一般的に、タイルのリソース使用量は比較的低いものにとどまるはずです。Developer Preview (英語) を使用されている方は、タスク マネージャーの [App History] (アプリ履歴) タブで [Tiles] (タイル) 列をご覧いただければ、過去 30 日間で各ライブ タイルが消費した帯域幅を確認していただけます。

2011 年 9 月 17 日から 2011 年 10 月 17 日の Metro スタイル アプリのリソース使用量の履歴を示したヒート マップ。"News" アプリのリソース使用量はネットワークで 71.9 MB、従量ネットワークで 57.2 MB を示しているが、タイルでの使用量は 0.1 MB のみ。合計 18 個のアプリが表示されており、[Tiles] (タイル) 列の数値はいずれも 0 MB または 0.1 MB。
図 5: タスク マネージャーのアプリ履歴に表示されたライブ タイルのリソース使用量

まとめ

Windows 8 では、必要な情報を一望できるビューを提供しながら、プラグインやガジェットをベースとした従来のモデルではつきものだったパフォーマンスやバッテリ寿命の懸念を回避する通知プラットフォームの設計を目指しました。設計上の一つ一つの決定が、すべてパフォーマンスとバッテリ寿命を意識しながら行われています。また、開発者の参加を容易にするため、複雑なネットワーク接続関連のコードを書くことなくライブ タイルを作成できるよう、Windows プッシュ通知サービス (WNS) が提供されます。WNS では HTTP POST などの標準的な Web テクノロジを使用するため、開発者が既存の Web サービスを基にした通知機能を組み込むのも容易になっています。

この結果として生まれたのは、情報をひとめで確認することができ、パフォーマンスやバッテリ寿命への影響を心配することなく、好きなだけアプリをインストールすることができる、新しい通知プラットフォームです。

--Ryan Haveson