EIP
Introduction †
一言要約 †
本番環境や、疎結合、パッケージといった多くの複雑さの中、メッセージを分析したりデバッグするためのシステム管理に関するパターンを紹介する。
要約 †
Introduction †
メッセージングソリューションの開発は容易でなく、本番環境で運用するのも同様に難しい。メッセージベースの統合ソリューションは数千または数百万のメッセージを一日でさばき、例外やパフォーマンスのボトルネックや変更に対処しなければならない。さらにはコンポーネントが複数の場所に在る多くのプラットフォームやマシン間で分散されてることでより困難になる。
固有の複雑さや統合分散パッケージのスケール、カスタムアプリケーションに加え、疎結合のアーキテクチャの利点はテストをテストやデバッグを難しくする。マーティンファウラー氏はこれを「アーキテクトの夢、開発者の悪夢」と表現している。疎結合や間接のアーキテクチャ原則はシステムが互いに作る前提を減らし、柔軟性を提供する。しかしながら、メッセージプロデューサがこのメッセージのコンシューマが誰なのかを認識しないシステムをテストすることは困難である。また非同期やメッセージの時間的な側面によりさらに複雑になる。例えば、メッセージングソリューションは受信から返答メッセージを受け取るメッセージプロデューサのために設計されているわけではない。同様に、メッセージングインフラストラクチャは一般的にメッセージの配達を保証するものであり、配達の時間でない。これはメッセージ配達の結果に依存するテストケースの開発を難しくする。
メッセージソリューションを監視する場合、大きく２つのレベルに分けてメッセージを追跡できる。一般的なSystem Managementソリューションはどれだけメッセージが送られ、どのくらいメッセージの処理に時間がかかったのかを監視する。これらの監視ソリューションは、メッセージ識別子やMessage Historyのようなメッセージヘッダ内のフィールド以外のメッセージデータは調査しない。対照的に、Business Activity Monitoring(BAM)ソリューションはメッセージに含まれる本体データに焦点を当てている。このセクションで挙げるパターンの多くはどちらの目的に使っても問題ない。ただし、BAMはそれ自体が全く新しい分野で(この本では全く触れていない)データウェアハウスと多くの複雑さを共有しているため、この本はシステム管理のコンテキストでパターンを説明することに決めた。
System Managementパターンはこれらの要件に対応し、複雑なメッセージベースのシステムが安定して動くためのツールを提供する。この章は3つのセクションに分ける。
監視と制御 †
Control Busは分散ソリューションの管理と監視のために単一の制御ポイントを提供する。複数のコンポーネントは中央の管理コンソールに接続し、各コンポーネントの状態を表示し、コンポーネントを通じてメッセージトラフィックを監視する。コンソールは制御コマンドをコンポーネントに送ってメッセージフローを変更することもできる。
バリデーションやロギングのような追加ステップを介してメッセージをルーティングすることもできる。これらのステップにてパフォーマンスのオーバーヘッドを導入できるので、control busを通じてON/OFFを切り替えることができる。Detourがこの機能を提供する。
メッセージトラフィックの観察と分析 †
主要なメッセージフローに影響を与えることなくメッセージの内容を検査したいことがある。Wire Tapを使うことでメッセージトラフィックに入り込むことができる。
メッセージベースのシステムをデバッグする際、特定のメッセージがある場所を知るには最適である。Message Historyはコンポーネント間の依存なしにこの機能を提供できる。
Message Historyは個々のメッセージにひもづけられており、中央のMessage Storeはシステム間を行き来する各メッセージの完全な詳細を提供できる。Message Historyと組み合わせたMessage Storeはメッセージがシステムを通じて得られる全てのパスを分析できる。
Wire Tap、Message History、およびMessage Storeはメッセージの非同期フローを解析するのに役立つ。request-replyサービスに送信されたメッセージを追跡するにはSmart Proxyをメッセージストリームに挿入する必要がある。
テストとデバッグ †
本番環境にデプロイする前にメッセージングシステムをテストするのは良いアイデアである。しかしテストによってシステムを停止すべきではない。稼動しているメッセージングシステムが正しく機能していることを検証しなければならない。システムにTest Message?を定期的に注入することで実現でき、結果を検証できる。
コンポーネントに障害や誤動作が起こった場合、チャネル上の不要なメッセージに終わってしまうことがよくある。テスト中にチャネルから残った全てのメッセージを削除すると便利なので、テスト配下のコンポーネントは「食べ残し」メッセージを受け取ることはない。Channel Purgerはそれを行ってくれる。
担当者のコメント †
みんなの突っ込み †
