Java EE勉強会

EIP / Control Bus

制御バス †

一言要約 †

メッセージングシステムが持つ複数のコンポーネントを透過的に管理および監視を行う。

要約 †

当然ながら、エンタープライズ統合システムは分散されている。実際、エンタープライズメッセージングシステムの性質を決定する要因の一つは異なるシステム間の通信を可能にすることである。メッセージングシステムは情報をルーティングし転送できるようにするので、データはこれらのシステム間を交換可能にする。ほとんどの場合、これらのアプリケーションは複数のネットワーク、建物、都市や大陸をまたがって広がっている。

複数のプラットフォームや広い地理的エリアにわたって分散されるメッセージングシステムを効率的に管理するにはどうすればよいか？

分散し疎結合のアーキテクチャは柔軟性や拡張性を可能にする。同時に、そのようなシステムを制御するための深刻な課題も提起してくれる。例えば、全コンポーネントが正常に動いているかをどうやって見分ければよいか？プロセスは多数のマシンに分散されているため、単純にプロセス状態を確認することは十分ではない。また、リモートマシンから状態を取得出来ない場合、それはそのマシンは動いてないかそのマシンとの通信が妨害されているのか？

システムまたはコンポーネントが稼動しているかを知るには、システムの動的な振る舞いを監視する必要がある。メッセージのスループットは？異常な遅延はないか？チャネルがいっぱいになってないか？この情報の一部はコンポーネント間またはコンポーネントを通じたメッセージの移動時間を追跡する必要がある。これは、複数のマシンから情報の収集および組み合わせが必要になる。

また、コンポーネントから情報を読むだけでは十分ではない場合がある。システム稼働中に設定を調整または変更する必要がしばしばある。例えば、システム稼働中にロギング機能をON/OFFする必要があるかもしれない。多くのアプリケーションは設定情報を読んでエラー状態をレポートするためにプロパティファイルやエラーログを使用する。このアプローチは単一のマシンまたは少数のマシンで構成しているアプリケーションにて上手くいきやすい。大規模で分散されたソリューションでは、プロパティファイルはファイル転送メカニズムを用いてリモートマシンにコピーしなければならなく、全マシンが離れてアクセスできるファイルシステムを必要とする。これはセキュリティ上のリスクをもたらし、もしマシンがインターネットまたはファイルマッピングプロトコルをサポートしていない広域ネットワークに繋がっている場合は難しい。また、ローカルのプロパティファイルのバージョンは注意して管理しなければならない(管理の悪夢が待っている)。

これらのタスクを実行するためにメッセージングシステムインフラストラクチャを活用しようとするのはごく自然なことである。例えば、設定を変更するためにコンポーネントにメッセージを送信できる。この制御メッセージは通常のメッセージと同様に転送、ルーティングされる。これは通信の問題をほとんど解決するが、新たな課題を引き起こす。設定メッセージは通常のアプリケーションメッセージより厳しいセキュリティポリシーの対象にすべきである。例えば、誤ったフォーマットの制御メッセージは簡単にコンポーネントをダウンさせる可能性がある。また、コンポーネントが故障しているのでもしメッセージチャネル上にキューがあればどうなるか？コンポーネントをリセットするために制御メッセージを送信したら、この制御メッセージは他の全メッセージとともにキューに入れられコンポーネントに到達しないだろう。一部のメッセージングシステムはメッセージの優先順位をサポートしており、キューの先頭に制御メッセージを移動させることができる。しかしながら、全てのシステムがこの機能を提供しているわけではなく、もしキューが満杯で他のメッセージを受け付けない場合は優先順位は役に立たない。同様に、制御メッセージのいくつかはアプリケーションメッセージより優先順位は低い。もし定期的なステータスメッセージを公開しているコンポーネントを持っている場合、「生きてるよ」制御メッセージが遅延したり失ったりすることで手間や「100万ドルの注文」メッセージの遅延や損失をずっと少なくさせる。

Control Busをつかってエンタープライズ統合システムを管理する。Control Busはアプリケーションデータによって使われるのと同じメッセージングシステムを利用するが、メッセージフロー内に含まれるコンポーネント管理に関連するデータを転送するために異なるチャネルを用いる。

ControlBus.gif

システム内の各コンポーネントは2つのメッセージングサブシステムに繋がれている。

  • アプリケーションメッセージフロー
  • Control Bus アプリケーションメッセージフローは全てのアプリケーション関連メッセージを転送する。コンポーネントは管理されていない場合と同じようにこれらのチャネルに受信(subscribe)送信(publish)する。また、各コンポーネントはControl Busを構成するチャネルからもメッセージを送受信する。これらのチャネルは中央の管理コンポーネントに繋がっている。

Control Busは次のような種類のメッセージを運ぶのに適している。

  • 設定 - メッセージフロー内に含まれる各コンポーネントは設定可能なパラメータを持っている必要があり、必要に応じて変更できる。これらのパラメータはチャネルアドレス、メッセージデータ形式、タイムアウトなどが含まれている。コンポーネントはプロパティファイルを用いるというよりは中央リポジトリから情報を取得するためにControl Busを用い、設定や実行時の統合ソリューションの再構成を中心に置く。例えば、Content-Based Routerの内部にあるルーティングテーブルは、過負荷やコンポーネント障害などのシステム状況にもとづいて動的に更新する必要がある。
  • ハートビート - 各コンポーネントは指定間隔で定期的にControl Bus上で「ハートビート」メッセージを送り、中央コンソールアプリケーションはコンポーネントが正しく機能しているかを確認する。この「ハートビート」は処理されたメッセージ数やマシン上の利用可能なメモリ量などコンポーネントに関するメトリクスも含んでいる。
  • テストメッセージ - ハートビートメッセージはControl Busにコンポーネントがまだ生きているかを伝えるが、メッセージを正しく処理するコンポーネントの能力に関する情報は限られている。Control Busにハートビートメッセージを定期的に発行するコンポーネントを持っていることに加え、コンポーネントによって処理されるメッセージストリームにテストメッセージを注入することもできる。コンポーネントがメッセージを正しく処理したかを確認するために後でメッセージを抽出する。この制御バスとメッセージバスの定義の不明瞭さから、別々のパターンとして分けることに決めた。(Test Message参照)
  • 例外 - 各コンポーネントは例外条件を評価されるControl Busに向けることができる。深刻な例外はオペレータに警告を発する。例外処理を定義するルールは中央ハンドラー内で指定する必要がある。
  • 統計 - 各コンポーネントは処理されたメッセージ数、平均スループット、平均メッセージ処理時間などの統計情報を収集できる。このデータの中にはメッセージ種類によって分割されるので、どの特定のメッセージがシステムをあふれさせているのかが判別できる。このメッセージは他のメッセージより優先順位が低い傾向があるので、Control Busは非保証型またはこの種のデータは優先順位が低いチャネルを使う可能性がある。
  • ライブコンソール - ここであげた機能のほとんどは中央コンソールで表示するために集約できる。これにより、オペレータはメッセージングシステムの状態を評価し、必要に応じて適切に処理できる。

Control Busがサポートしている機能の多くは、任意のネットワークに繋がれているソリューションを監視および維持するために使われる従来のネットワーク管理機能に似ている。Control Busはメッセージングシステムレベル(低レベルのIPネットワークレベルからリッチなメッセージングレベルに本質的に引き上げて)にて同等の管理機能を実装している。この機能を提供することはメッセージングインフラストラクチャの正常動作に不可欠だが、メッセージングソリューションの管理基準が存在しないと、企業全体レベルのメッセージングシステムの再利用可能な管理ソリューションを構築することは困難になる。

メッセージ処理コンポーネントを設計する際、コアプロセッサと周りにある3つのインターフェースを設ける。インバウンドデータインターフェースはメッセージチャネルからメッセージを受信する。アウトバンドデータインターフェースはoutboundチャネルに処理されたメッセージを送信する。制御インターフェースはControl Busから(へ)制御メッセージを送受信する。

メッセージコンポーネントの主要インターフェース

例：ローンブローカーの測定

この章の終わりに、Control Busを使ってローンブローカーの非同期MSMQ実装を測定する方法について示す。この実装は、リアルタイムにコンポーネントの状態を表示するシンプルな管理コンソールを含んでいる(Loan Broker System Management参照)。

関連パターン：Asynchronous Implementation with MSMQ、Content-Based Router、Loan Broker System Management、Test Message

担当者のつぶやき †

みんなの突っ込み †


Menu