Freigeben über

クラウド サービスの基礎: テレメトリ – データ取得パイプライン

  • Artikel

このポストは、8 月 8 日に投稿された Cloud Service Fundamentals: Telemetry – Data Acquisition Pipeline の翻訳です。

Windows Azure のクラウド サービスの基礎の一部であるテレメトリ ソリューションの中心ともいえるのが、データ取得パイプラインです。Wiki シリーズ (英語) の 3 つ目の記事 (英語) で取り上げているのがこのパイプラインですが、テレメトリ ソリューションにおけるこのパイプラインの役割は、各種リポジトリからさまざまな情報を抽出し、単一のリレーショナル データベースに集積することです。このデータベースを使用して情報を関連付け、記録した指標の長期的なトレンドを分析し、特定の問題およびインシデントについて掘り下げ、定型のレポート/ダッシュボードおよびアドホックなレポート/ダッシュボードの両方をフィードすることができます (これについては次回の記事で取り上げます)。このエンドツーエンドのテレメトリ ソリューションにより、「利用者からパフォーマンス低下の報告があったが、そのときのアプリケーション コンポーネントの状態はどうだったのか」、「協定世界時 (UTC) の午前 0 時から午後 1 時の間にアプリケーションがタイムアウト エラーを生成した際、データ層にはどのような変化が生じていたか」といった問いに簡単に答えられるようになります。

図 1 - テレメトリ ソリューション アーキテクチャ全体におけるデータ取得パイプラインの概念図

アーキテクチャの観点から見ると、データ取得パイプラインは次の 3 つに分類することができます。

  1. インポート タスクや変換タスクを実行する、構成可能なスケジューラー エンジン
  2. 各種情報源を照会して特定の変換ロジックを適用し、その結果を中央リポジトリにプッシュする拡張可能なタスク群
  3. データを一般的なリレーショナル スキーマに保存する Windows Azure SQL データベース インスタンス (これを使用して分析クエリを実行し、有意な情報を抽出)

スケジューラー エンジンを実装すると共に、一定の時間間隔で各種データ ソースを照会する「プル」メカニズムを導入していますが、より複雑な「プッシュ」や「ストリーミング」といった方法よりもこのアプローチを採用していることにはいくつか理由があります。その最大の理由は、Windows Azure ストレージ (Windows Azure 診断により生成された情報の場合) や Windows Azure SQL データベースの内部データ構造体 (動的管理ビューの場合) のような中間リポジトリに、データが既に保存されている点です。また、リアルタイムの継続的な分析に対する厳格な要件もなく、実装をできるだけシンプルな状態に保つことを目指しました。最新リリースでは、スケジューラーは Windows Azure の Worker ロールとして実装されており、Windows Azure ストレージの BLOB コンテナーにホストされている XML ファイルから構成を読み取ります。このファイルには、実行予定のジョブの数、種類、実行頻度のほか、すべての構成オプション、各種データ ソースおよびデータ保存先の接続文字列が定義されています。構成ファイルはいつでも変更可能で、タスクを追加/削除したり、特定の構成を変更したりすることができ、Worker ロールは更新された構成ファイルに基づいて実行を開始します。自社のソリューションをモニタリングしているお客様およびパートナー様にご協力いただき、このスケジューラー コンポーネントを運用環境へ展開した結果、この Worker ロールは S サイズの仮想マシンで数百件のコンピューティング インスタンスおよびデータベースに十分対応できることがわかりました。

また他にも、次の 2 つの重要な診断ソースに接続するための重要なタスクを実装しました。

  • Windows Azure 診断によって生成されたデータ
  • 動的管理ビューからアクセス可能な Windows Azure SQL データベースの内部状態

Windows Azure 診断はほとんどの情報を Windows Azure ストレージ テーブルに保存するため、インポート タスクの多くは非常によく似ています。基本的には、Windows Azure ストレージ クライアント ライブラリ v 2.0 のコンテキストを使用して、特定の時間帯 (startdate から enddate まで) にソース テーブルを照会し、直接いくつかのフィルター (重要なイベント、エラー イベントなど) を適用して、データ行をその場で整形または変換し、その結果得られた新たな情報を目的のデータベースに一括コピーします。Windows Azure コンピューティング ノードのパフォーマンス カウンターや Windows イベント ログおよびトレース ログのなどの情報がこれに当たります。より複雑な実装では、特定の構造で構成されている BLOB コンテナーに保存されているすべての Web ロールの IIS ログを Windows Azure 診断で収集します。この場合、最初に (特定の時間帯に生成されたすべてのログ ファイルへの参照が格納されている) テーブルを照会した後、IIS ログ ファイルを Worker ロールのローカル ストレージにダウンロードして分析を行い、Web ページや API 応答時間などの有意な情報を抽出します。

SQL データベース インスタンスについては、(並列展開ライブラリを使用して) すべての対象データベースの公開されている動的管理ビューを照会する特定のインポート タスクを作成し、クエリや要求の統計情報、接続エラー、不足しているインデックス、データベースのサイズといったさまざまな有用な情報を抽出します。

今後改善すべき点として、Windows Azure ストレージ分析およびキャッシュの診断情報を追加することを検討しています。

この診断情報はすべて、時間ベースの共通のキー定義を使用し、一定間隔のクエリに最適化された (SQL データベースでもホストされている) 単一のリレーショナル スキーマに保存されます。その理由はシンプルで、特定のインシデントの調査や経時的なトレンドの把握に使用する可能性が高いためです。

先に述べたとおり、次回の記事では OpsStatsDB を照会し有意な情報を抽出する方法について取り上げ、テーブル値関数 (TVF) 層に焦点を当てます。この TVF は、Excel を使用したアドホックなレポートの実装を簡素化することを目的として開発したものです。また、クラウド サービスの基礎コード パッケージに付属の Windows Azure SQL レポート サービスのレポートおよびダッシュボードについても見ていきます。

クラウド サービスの基礎シリーズの全記事はこちら (英語) の TechNet Wiki ページをご覧ください。