Windows 8: タイルで躍動感を実現する
Windows 8 では、データ駆動のアーキテクチャによって、パフォーマンスとバッテリ寿命を維持しながら、多数のアプリを一度に実行できます。
Ryan Haveson
現在、ほぼすべての PC、ノート PC、またはモバイル環境には、情報をひと目で確認できるガジェット、ウィジェット、またはプラグイン モデルが導入されています。構造化された画面では、多数のデータ ソースからリアルタイムで取得した情報が表示された状態で、テレビのニュース番組、スポーツ番組、または天気予報を視聴できます。また、作業の合間のほんの数秒の時間に、株価、天気、電子メール、予定だけでなく、ソーシャル ネットワーキングの情報を確認できることが当たり前になっています。
この現状は、パフォーマンスやバッテリ寿命に大きなマイナスの影響を及ぼします。現在の PC は、この領域の多くの点において、ノート PC や他のモバイル デバイスに追い付く必要があると言えます。Windows 8 の通知インフラストラクチャを設計するときに課題となったのは、電力と帯域幅の使用量に関する効率を維持しながら、PC でアクティビティの状況をリアルタイムに反映することでした。
Windows 8 のスタート画面では、デスクトップや他のアプリをさえぎることなく、画面全体に通知が表示されるので、ユーザーの観点では、アクティビティの状況を効率的に確認できるようになっています。また、効率を追求するだけではなく、パフォーマンスやバッテリ寿命にマイナスの影響を及ぼすことなく、通知アプリを好きなだけインストールできるようにすることも目標としました。Windows 8 のスタート画面は、基幹業務 (LOB) アプリケーションの通知が表示される読みやすい総合的なビューとして使用できます。このように、Windows 8 のスタート画面は、生産性を向上する一助となっています。
新しいプッシュ通知プラットフォームのスケーラビリティにより、Windows 8 では、システムへの影響を最小限に抑えて、この機能を実現しています。デスクトップしか使用しない筋金入りのデスクトップ ユーザーにとっても、スタート画面が、1 回のキー操作でアクセスできて適切に情報が表示される管理された一元的な通知領域になるでしょう。
通知の目標
パフォーマンスの低下回避しながら、何百ものアプリのタイルに情報をリアルタイムに表示できるようにすることは、相反する目標のように思われます。というのも、"アクティビティ" は本質的にリソースを消費するものだからです。クラウドから通知を取得するにはネットワークを使用し、通知をタイルに表示するには、プロセッサのリソースを使用します。そのため適切なデザインを実現するには、次の最初に掲げた目標に集中する必要がありました。
- パフォーマンスを低下させることなく数百ものライブ タイルを実現する
- バルーン、アイコン、テキストだけでなく、魅力的なイメージを使用する
- 開発者にとって簡単なもの (呼び出し以外の処理は不要) にする
- リアル タイムの配信を実現して、"インスタント メッセージ" が瞬時に配信されるようにする
これらの目的に基づいて、アーキテクチャに関して最初に下した基本的な決定事項は、データ駆動のプラットフォームを実現することでした。つまり、スタート画面を機能させるために、バックグラウンドでアプリのコードが実行されるべきではないというものでした。通知の配信システムは、いくつかのコンポーネントで構成されており、接続、認証、ローカル キャッシュ、レンダリング、エラー処理、バックオフ アルゴリズム、帯域幅の調整などのタイミングを制御するロジックが存在します。また、サービス側の問題 (ユーザーが接続したタイミングを把握するなど) にも対応する必要があります。配信されていないコンテンツをキャッシュして、コンテンツの配信を再試行する複雑なシナリオにも対応する必要があります。
ライブ タイルに対応している全アプリが、このようなクライアント/サーバー コードをそれぞれ個別に保持していたらどうでしょうか。実装ごとに異なる問題が発生するだけでなく、本質的に同じ各アプリのコードがメモリに読み込まれることになります。このようなコードは、絶えずディスクに対してページ イン/アウトされます。スタート画面の情報がリアルタイムで更新される状態を維持するために、すべてのアプリが常時実行されるため、これは非常に非効率的です。大容量のメモリを搭載しているコンピューターでも、いずれはパフォーマンスが非常に低い状態になります。
一度に実行するプロセス、DLL、およびサービスの数が増えるにつれてパフォーマンスは低下します。各ライブ タイルで独自のコードが実行されていたら、パフォーマンスを低下させることなく数百ものライブ タイルを実現するという目標を達成することは不可能でしょう。この問題を解決するために、データ駆動のモデルを構築しました。
このモデルでは、アプリの開発者は、一連の定義済みのプロパティやテンプレートを使用して独自のタイルを作成できます。このモデルでは XML スキーマを使用しています。タイルの XML データは、単純な HTTP POST 経由で Windows プッシュ通知サービス (WNS) に送信され、それ以降の処理は Windows 8 によって行われます。接続、再試行、認証、キャッシュ、レンダリング、およびエラー処理のすべてのコードは、同一の電力効率のよい方法で実行されます。
データ駆動のモデルを使用するという決定により、パフォーマンスと高品質なエクスペリエンスを実現するという最初の 2 つの目標を達成することができました。ただし、リアル タイムの配信と呼び出し以外の処理は不要という効率性を実現する問題が残っていました。
ポーリングとプッシュ
クライアント/サーバーのコンテンツ配信には、"ポーリング" と "プッシュ" という 2 種類の高度なデザイン パターンがあります。ポーリングでは、クライアントがサービスに対して定期的 (90 分ごとなど) に新しいコンテンツがあるかどうかを確認します。プッシュでは、新しいコンテンツがあるときに、サービスがクライアントに直接データを送信します。
ポーリング モデルでリアルタイムの通知をサポートするには、高い頻度で (たとえば、5 秒ごとに) ポーリングを行う必要があります。頻繁に確認を行えば、新しいメッセージが配信されたときに、すぐにメッセージの通知が表示されます。ただし、このような処理を行うとパフォーマンスが低下します。5 秒というポーリング間隔では、ネットワーク スタックがアイドル状態になることがないため、バッテリ寿命が非常に短くなり、デスクトップ コンピューターは常に電源が入っている状態になります。
これは、携帯電話で 1 日中話をしている状態と少し似ています。携帯電話の充電は、それほど長くは持たないでしょう。それに加えて、5 秒ごとにサーバーに対してコンテンツを確認しても、ほとんどの場合は新しいコンテンツを確認できないので、非常に無駄の多い処理になります。従来のシステム トレイの通知と Windows Vista で導入されたデスクトップ ガジェットでは、ポーリング メカニズムが採用されていました。ただし、どのポーリング メカニズムでも、今日のリアル タイムで提供されているサービスに対応するには、5 秒というポーリング間隔も十分ではありません。
そのため、Windows 8 ではプッシュ ベースのサービスを採用しています。これは大きな決断でした。というのも、このプラットフォームは、グローバルなスケールで開発されており、最終的には、何十万ものアプリと 10 億以上のユーザーのタイルをサポートすることになるからです。ですが、この決断には明らかな価値がありました。それは、開発者が、クライアントへの常時接続を維持する必要なく、有益なリアルタイムの通知を無料でユーザーに提供できるようになることでした。
プッシュ プラットフォーム
プラットフォームのさまざまなコンポーネントを詳しく確認しながら、このデザインの細部を確認しましょう。このプラットフォームの主な構成要素は次の 3 つです。
- WNS: ライブ タイルが機能するようにして、通知を表示します。
- アプリ サービス: アプリを実行して、WNS 経由で通知とタイルの更新情報を送信する Web サービスです。アプリ サービスには、Developer Preview に同梱されていた Weather アプリのバックエンド サービスやソーシャル ネットワーキング アプリの写真をホスティングするバックエンド サービスなどが該当します。
- Windows 8 クライアント プラットフォーム: 実際の PC とエンド ツー エンドのエクスペリエンスを構築する OS のサブコンポーネントです。
このしくみを説明するために一般的な使用シナリオを紹介しましょう。アプリ サービスが、写真に対するコメントが投稿されたときにタイルに更新情報を送信するソーシャル ネットワーキング サイトだとしましょう。アプリ サービスは、新しいタスクがアサインされたり、経費報告書を確認する必要がある場合に更新情報を送信する LOB アプリの場合もあるでしょう。更新があると、アプリ サービスでは WNS に通知を送信します。
これを受けて WNS ではクライアントに通知をプッシュします。スタート画面のタイルに更新情報を表示するときには、OS が、通知の XML データで指定されている URL に基づいてアプリ サービスからイメージを取得します。通知とイメージのダウンロードが完了すると、アプリでは、XML で指定されているテンプレートに基づいてライブ タイルをレンダリングして、スタート画面に表示します。
このプロセスで呼び出し以外の処理を不要にするために (開発者が、PC がインターネットに接続されていないときに複雑なキャッシュと再試行のメカニズムのコードを記述する必要をなくすために)、PC が次にインターネットに接続するまで WNS クラウドには、アプリケーションごとに通知を 1 つキャッシュします。
クライアント プラットフォーム コンポーネントを設計するときには、高いパフォーマンスと低い電力消費を実現するように、すべてのものを設計することを心がけました。このとき重要になったのは、通知とイメージのペイロードを分離することでした。一般的な通知の XML データのサイズは 1 KB 未満ですが、イメージのサイズは最大 150 KB です。これらのペイロードを分離することで、重複するイメージが多数ある場合にネットワークの帯域幅を大きく節約することができます。
たとえば、タイルのイメージに友達のプロフィール写真が使われることがあります。PC で写真をダウンロードしたら、写真はローカルにキャッシュできます。通知をイメージと分離すると、イメージをダウンロードする前に不要な通知を破棄できるというメリットがあります。デバイスの画面の電源がオフになっている場合、タイルのイメージをダウンロードしても、ダウンロードしたイメージは、次にデバイスが使用される前に、新しい更新情報によって置き換えられるだけなので意味がありません。
認証モデル
ライブ タイルと通知は、アプリ エクスペリエンスの中核を担っているので、通信チャネルでは、認証が行われ、セキュリティが確保されていることが重要になります。そのため、Windows 8 では、PC と WNS の接続を一意に認識する匿名の認証メカニズムを採用しています。アプリとアプリ サービスでは、WNS と通信するときに認証を行います。
WNS への両方の接続で認証を行うと、ライブ タイルの更新情報がスプーフィング攻撃などによって悪用されることから保護できます。WNS で採用している認証メカニズムでは、アプリケーションとサービスを明示的に関連付けています。WNS では、関連付けられていない他のアプリケーション (またはユーザー) が所有していないタイルに対してコンテンツを送信できないようにすることで、このメカニズムを実現しています。もちろん、すべての通信は、セキュリティが確保されたチャネル経由で行われます。
このメカニズムは Windows Live ID を使用して Windows にサインインしているかどうかに関係なく機能します。Windows 8 では、インターネットに接続しているアカウントを使用すると、すべての強化された機能 (アプリのクラウド ストレージ、Windows とアプリの設定のローミング、複数のアプリへのシングル サインオンなど) が使用できるので、最も快適に使用できます。プッシュ通知プラットフォームでは、匿名の認証メカニズムを採用しているので、Windows Live ID でサインインしていても、アプリの開発者は、通知のパイプラインを使用して、ユーザーの Windows Live ID、システム情報、または場所を特定することはできません。
拡張できるように構築する
通知プラットフォームでは、膨大な数のユーザーとアプリをサポートする必要があります。ベータ版以前の開発段階でも、1 日に 9,000 万件以上のタイルの更新情報を送信していました。Developer Preview のビルドでは、一般的なテスト アプリとして株価アプリを使用していました。Developer Preview のリリース後は、データセンターに入ってくるトラフィックを注意して確認し、スケールアウトの状況を監視しました。
WNS の設計は、Windows Live Messenger サービスのアーキテクチャをベースとしています。実際、通知プラットフォームのサービスの部分は、同じチームが開発を担当しました。現在の Windows Live Messenger サービスの規模を理解していただくために、いくつか統計情報を紹介します。
- 1 か月のアクティブ ユーザー数: 3 億
- 1 日のログイン回数: 6.3 億
- 1 日の通知件数: 100 億
- 最大同時オンライン接続数 (SOC): 400 億以上
- 世界に向けてメッセージをルーティングしているサーバーの台数: 3,000 台以上
通知プラットフォームのパフォーマンスを注意深く監視するため、アプリごとにタイル プラットフォームが消費している帯域幅を追跡できるようにするメトリックスを新しいタスク マネージャーに追加しました。タイルによるリソースの使用率は、比較的低くなるようになっています。
Windows 8 では、従来のプラグインやガジェット ベースのモデルで見られたパフォーマンスやバッテリ寿命の問題が発生することなく、情報をひと目で確認できる通知プラットフォームの設計を目指しました。そのため、すべての設計に関する決定は、パフォーマンスとバッテリ寿命の効率という観点で行われました。
アプリの開発者が複雑なネットワーク接続のコードを記述する必要がないように WNS を構築して、開発者がライブ タイルに参加しやすくなるようにしました。WNS では、HTTP POST などの標準的な Web テクノロジを使用しているので、開発者は、既存の Web サービスに基づいて簡単に通知を統合できます。
その結果、情報をひと目で確認できる通知プラットフォームが実現しました。また、パフォーマンスやバッテリ寿命にマイナスの影響が及ぶことを気にすることなく、好きなだけアプリをインストールできます。
.jpg)
Ryan Haveson は、エンジニアリング チームを統率し、世界的に有名なブランドである Xbox や Windows などのソフトウェアとサービスの提供に 15 年以上携わってきました。Ryan は、Windows 8 の Windows エクスペリエンス チームのグループ マネージャーを務めていました。Windows エクスペリエンス チームでは、ライブ タイル通知プラットフォームや新しいタスク マネージャーなど、エンド ユーザーと開発者向けの機能をデザインして実現しました。現在は、米国カリフォルニア州のサンディエゴにある Qualcomm の Snapdragon 部門で Windows と Windows Phone のエンジニアリング システム グループを統率しています。連絡先は、ryanhaveson@hotmail.com (英語のみ) または linkedin.com/in/ryanha (英語) です。