Azure DocumentDB: MSN ヘルスケアのご紹介
このポストは、10 月 9 日に投稿した Azure DocumentDB: Profile of MSN Health and Fitness の翻訳です。
MSN.com は世界 26 の市場において最大手 Web ポータルとして使用されている最も信頼性のあるサイトの 1 つであり、1 か月間に 5 億人ものユーザーが利用しています。MSN.com はマイクロソフトの Information and Content Experiences (ICE) グループの一部で、ヘルスケア、マネー、自動車、エンタメ、天気、フード&レシピ、動画、トラベル、ニュース、スポーツなどの一般ユーザー向けコンテンツで構成されています。各コンテンツのエクスペリエンスは高度にスケーラブルで疎結合されており、世界中の膨大な数のユーザーをサポートすることを目的として設計されています。また、これらのコンテンツは Windows Phone、iOS、Android といった各種プラットフォームに対応しており、そのブラウザー向けに個別のアプリケーションがリリースされています。
高度にスケーラブルでスキーマ フリーのクエリ可能な分散型データ ストア
MSN.com ではさまざまな目的に対応するデータ ストアおよびキャッシュ ソリューションが構築され、長年にわたって進化を続けてきました。今年の始めに MSN の各チームの間で話し合われたのは、MSN のあらゆるコンテンツで使用可能な統合された分散型ストレージ システムの必要性についてです。この統合は、新たなコンテンツや各デバイス向けのソーシャル コンピューティング機能を導入するためには欠かせないものでした。ICE チームは既存のストレージ ソリューションを改良し、User Data Store (UDS) と呼ばれる単一の Azure ベースの分散型ストレージ システムに置換することを決定しました。この UDS のサポート要件は以下のとおりです。
- スケール: 4 億 2,500 万人を超える MSN のユニーク ユーザーおよび 1 億人を超える直接認証済みのユーザーをサポート可能。初期容量: 20 TB のドキュメント ストレージ
- レイテンシ: 99% の要求で書き込みレイテンシは 15 ミリ秒未満、読み込みレイテンシは 10 ミリ秒未満
- 認証範囲: 同一の基礎データ全体にわたって認証可能
- ストレージ: リッチなクエリとトランザクションをサポートするスキーマ不要のストレージ
- データ モデル拡張: 各種コンテンツのあらゆるスキーマ群をサポート
- 分析: Hadoop ベースのデータ分析
- 可用性: 世界中の MSN サービス提供地域とユーザーに対応
Azure でさまざまなソリューションを評価した結果、MSN では UDS の中核コンポーネントとして Azure DocumentDB を使用することを決定しました。先日新しい MSN が公開 (英語) されましたが、ヘルスケアは Azure DocumentDB を使用して最初に公開された MSN コンテンツの 1 つです。MSN の他のコンテンツでも、順次 Azure DocumentDB 上に構築された新しい UDS アーキテクチャの使用が開始される予定です。
MSN ヘルスケアの概要
MSN ヘルスケアでは、次のようなさまざまなサービスを提供しています。
- ダイエットログ: 毎日の食事を記録できます。食品を検索すると関連した食事メニューが表示されます。食事メニューにはカロリーや脂質、炭水化物、タンパク質などが設定されています。
- エクササイズログ: 有酸素運動の距離、時間、消費カロリーを記録できます。
- GPS ログ: GPS 対応端末を携帯してランニングすることでアクティビティを GPS データとして記録できます。ランニングのメタデータは DocumentDB に保存されます。
- 歩数計: 歩数計を搭載した端末 (新しい Nokia 端末はすべて対応) では歩数を記録し、UDS に保存できます。
- 体重ログ: 日々の体重を記録できます。
- 分析機能: 食事、エクササイズ、GPS、歩数計の履歴データを分析できます。
- お気に入り機能とカスタマイズ機能: お気に入りの食品やエクササイズを保存したり、ユーザー独自の食品やエクササイズを作成してメタデータと関連付けることができます。お気に入り機能は今後拡充し、記事や健康状態、ヨガなどの種類のデータにも対応する予定です。
新しい MSN ポータルのリリース以降、ヘルスケアではユーザー データの保存とクエリの実行時に、バックエンドで Azure DocumentDB を使用するようになりました。またリリース時点から、3 つの地理リージョンで 150 能力単位 (CU) の SSD を使用するドキュメント ストレージとスループットがプロビジョニングされています。
ヘルスケア アプリケーションでは、各リージョンで DocumentDB データベース 1 つごとに 1 つの DocumentDB データベース アカウントが作成されます。また、このアプリケーションの DocumentDB データベース アカウントはセッションの整合性を保持するように構成されていて、単純な読み取りと書き込み、および自分で書き込んだデータの読み取りアクセス許可が保証されます。これにより非常に高い読み込みスケーラビリティが確保され、また書き込みについてもレイテンシの目標を達成することができます。各 DocumentDB データベースにはコレクションのセットが含まれていて、それらには MSN ユーザー群に所属するドキュメントが含まれています。ドキュメントのサイズは 1 ～ 10 KB で、コレクション内のドキュメントで何らかの共通のスキーマを使用する必要はありません。ほとんどのコレクションは、書き込みスループットを最適化し、特定のドキュメントのパスでインデックスを自動作成し、インデックスのオーバーヘッドを最小化するように構成されています。
下の図は、複数のプラットフォームでさまざまなコンテンツをサポートする User Data Store のアーキテクチャ全体を示したものです。このアーキテクチャでは、幅広いスキーマ セットを保存しつつすべてのコンテンツでリッチなクエリ機能を提供するなど、DocumentDB のあらゆる機能を活用しています。
Azure DocumentDB で新しい MSN の User Data Store を構築
UDS のフレームワークでは、使用可能な容量に基づいてユーザー情報を複数のコレクションに分散します。各ユーザーのデータは 1 つのドキュメントに保存されます。UDS では、ユーザー ID に基づいてコレクションのセットにドキュメントを分散する水平方向のスケーリング ソリューションを使用しています。このため、スケーラビリティの目標を達成しつつ、高いスループットと高効率のクエリが実現されています。
MSN の User Data Store のプリンシパル アーキテクトを務める Saud Alshibani と彼のチームは、Azure DocumentDB チームと緊密に連携して作業を進めています。Saud Alshibani は、DocumentDB に関する経験について次のように述べています。
「統合型データ ストレージ レイヤーの設計の一環として、私たちは数多くのストレージ ソリューションを評価してきました。評価は、Azure でホストされる OSS 製品とその他の Azure Storage サービスの両方について実施しましたが、最終的には DocumentDB を採用することに決定しました。これは、スキーマ フリーのドキュメントにおけるクエリ、複数のドキュメントでのトランザクション、スケーラビリティやパフォーマンスに関する目標など、重要な要件を DocumentDB が満たしていたためです。DocumentDB では予測可能なパフォーマンス保証があり、面倒な関連問題を気にする必要がありません。また、DocumentDB のスケーリングは非常に簡単で、CU を増減するだけで実施できます。アプリケーションでは、.NET や JavaScript の DocumentDB クライアント SDK を幅広く使用しています。DocumentDB で得られた経験は全般的に非常に生産的なものでした。これを受けて、私のチームは数か月間程度の短い検討期間で再び DocumentDB を採用することを決定したほどです」。
新しいポータルのリリースに尽力した MSN チームに敬意を表すると共に、DocumentDB チームもその成果の一部となれたことに大きな喜びを感じています。