メディエーション・ポリシーを作成する際に、WSRR を「ポリシー・オーサリング・ポイント (Policy Authoring Point)」として、また WebSphere® DataPower® を「ポリシー実施ポイント (Policy Enforcement Point)」として使用するための実装の詳細を説明します。
WSRR を使用して、SLA (サービス・レベル・アグリーメント) ポリシー、メディエーション・ポリシー、モニタリング・ポリシー、カスタム・ポリシーなどのすべての SOA ポリシーと、今後サポートされる他のポリシー・ドメインを作成することができます。 Business Space ユーザー・インターフェースを使用すると、WSRR でポリシー文書を作成、更新、または削除することができます。 ポリシー文書には、特定のポリシー・ドメインに対していくつかのポリシーを指定するポリシー式を含めることができます。 あるいは、他の文書から既存のポリシーをアセンブルするポリシー文書を作成することもできます。 個々のポリシーは、ポリシーを文書に追加する際に指定したポリシー ID を使用して参照されます。 ポリシー式はポリシーの宣言を表し、WS-Policy 文書の <wsp:Policy> 要素に相当します。
Business Space でメディエーション・ポリシーを作成する手順については、新しいポリシーのオーサリングを参照してください。
サービス・レベル・アグリーメント (SLA) は、サービスの提供するサービス品質が指定された標準に合致することを必須とするビジネスの要件に基づいています。 サービスが設計される間に、サービスの動作のロジックをガイドするための機能要件が作成されます。 それと同時に、サービスの分析や設計の一環として非機能要求を指定して、サービスに期待されるサービスの品質を指定する必要があります。 例えば、ビジネスに、顧客のインターネット照会に応じて情報を提供するサービスがあるとします。 目標は、3 秒以内に応答を返すことです。 エンドツーエンド・トランザクションの設計の一環として、ビジネスの非機能要件を満たすためには、このサービスが 2 秒以内に情報を返す必要があると判断されます。
サービスがその SLA に合致することを保証するため、サービスのパフォーマンスに関するランタイム・チェックを実装し、SLA に合致しない場合にはアクションを実行するポリシーを作成することができます。 例えば、通常 (全体の時間の 95%) は 2 秒以内にサービス応答を提供できる、サービスの 1 次エンドポイントがあるとします。 SOA 設計者は、2 次エンドポイントを別のサーバー上に作成しました。通常、この 2 次エンドポイントは、1 次エンドポイントで障害が発生した際のホット・スタンバイとして使用されますが、1 次エンドポイントがトランザクションの負荷に対応しきれない場合に、オーバーフローしたトラフィックに対して使用されることも許可されています。 サービス応答時間を検査して、SLA に合致する必要がある場合にトラフィックを再経路指定するポリシーを作成できます。
ランタイム・ポリシーによって SLA が保守されるもう 1 つの例は、それぞれ優先順位レベルが異なる多様なコンシューマーを持つトランザクションにサービスが応答している場合です。 単純な例として、「Gold」および「Bronze」の顧客がいて、「Gold」の顧客に対してのみ特定のサービスの品質を保証する場合を考えます。 この例では、コンシューマーが「Gold」であるかどうかを検査し、そうであれば 2 次エンドポイントへ再経路指定します。「Bronze」の顧客は、それより低速の応答時間で対応することになります。 ビジネスでこの決定が下される理由は、「Bronze」の顧客に「Gold」の顧客の SLA に合致する応答時間を提供するための費用に対して、得られる増分収益が不十分であるためです。
3 つ目の例として、サービスが可能な限り十分機能しても、負荷がかかっていると判断される場合には、優先順位の低いコンシューマー・サービスからのメッセージをキューに入れたり、拒否したりする場合があります。 例えば、予期しない時間のコンシューマー要求で、バッチ・ルーチンによってシステムがフラッディングしてしまう場合が挙げられます。 サービスの品質を守るために、営業時間中にのみ有効になるランタイム・ポリシーを作成して、この時間内はすべてのバッチ要求を拒否することができます。
より一般的には、メディエーション・ポリシーを使用して、クライアント (コンシューマー) からの着信メッセージに対して妥当性検査と変換を行ってから、サーバー (プロバイダー) に表示することができます。
ポリシーはこのタイプのメッセージの妥当性検査や変換をサポートします。 ポリシーは、プロバイダー・サービスに対してのみ指定することも、特定のコンシューマーとプロバイダーのペアや、プロバイダー・サービスの匿名コンシューマーに対して指定することもできます。 匿名の顧客に対するポリシーによって、他のポリシーが適用されないコンシューマーに対してのみ適用されるデフォルト・ポリシーを定義することができます。 このフィーチャーを使用すると、自身を明らかにしない不正なコンシューマーに対してポリシーを指定することができます。 それによって、そのようなコンシューマー・サービスのトランザクションを拒否することができます。 これは、プロバイダー・サービスをダウンさせる目的でシステムをトランザクションでフラッディングさせようとするコンシューマー・ハッカーからのサービス妨害攻撃を防ぐのに役立ちます。
メディエーション・アサーションを作成して、ランタイム・ポリシーによって、サービスの SLAを制御したり、コンシューマーからプロバイダーへのメッセージを変換したり、コンシューマー・メッセージのメッセージ・スキーマを妥当性検査したりすることができます。
メディエーション・ポリシーの特殊なタイプである SLA ポリシー条件は、 条件を指定した従来の if-then-else 構造を効率的に使用して、その条件の評価に基づいて一連のアクションが実行されるようにします。 条件の指定はオプションです。 条件が指定されない場合は、True に評価される論理条件と同等と評価され、指定されたアクションがそれに応じて実施されます。
条件が指定される場合、その条件はブール式またはスケジュール仕様のいずれかで構成する必要があります。これら両方を含むこともできます。
スケジュール
スケジュールを指定する場合、そのスケジュールはポリシーが有効になる時点を特定します。 指定される日時はローカルの「ポリシー実施ポイント (Policy Enforcement Point)」によって評価され、使用されるタイム・ゾーンはその「ポリシー実施ポイント (Policy Enforcement Point)」のタイム・ゾーンになります。 スケジュールが指定されない場合、ポリシーは「ポリシー・オーサリング・ポイント (Policy Authoring Point)」から「ポリシー実施ポイント (Policy Enforcement Point)」にダウンロードされるとすぐに開始し、無期限に続行されます。
スケジュールでは、オプションの開始日とオプションの停止日、オプションの日次時間フレーム、およびオプションの曜日のリストを定義します。 例えば、2012 年 10 月 1 日から 2012 年 10 月 30 日までの毎週水曜日と日曜日に、午前 8 時から午後 5 時まで有効になるようにスケジュールを定義できます。
メディエーション・ポリシーの条件式
条件式が指定される場合、それはブール式を指定する非反復要素になります。
この式は、「Attribute」、「Operator」、および「Value」の 3 つの必須パラメーターと、オプションの「Interval」および「Limit」で構成されます。 「Attribute」および「Value」(該当する場合は、これらに加えて「Interval」および「Limit」) への「Operator」の適用が True に評価されると、式は True に評価されます。 「Limit」要素は、「HighLow」演算子および「TokenBucket」演算子と一緒にのみ使用されます。 「Limit」が指定されない場合、値は 0 になります。「Interval」が指定されない場合、デフォルトは 60 秒になります。
属性 | 説明とタイプ |
---|---|
ErrorCount | モニタリング間隔の間に確認された障害の数。 |
MessageCount | モニタリング間隔の間にインターセプトされたメッセージの実際の数。 |
InternalLatency | 秒単位の内部待ち時間 (処理時間)。 |
BackendLatency | 秒単位のアプライアンスからサーバーに対する待ち時間。 |
TotalLatency | 秒単位のバックエンドと内部待ち時間の合計。 |
演算子 | 意味 |
---|---|
GreaterThan | 定義された「Value」よりも「Attribute」が大きい場合に True に評価される、単純な数値アルゴリズム。 |
LessThan | 定義された「Value」よりも「Attribute」が小さい場合に True に評価される、単純な数値アルゴリズム。 |
TokenBucket | バーストを許容するレート・ベースのアルゴリズム。
このアルゴリズムは、トークンの最大容量「Limit」を持つバケットで構成されます。
「Attribute」単位ごとにトークンが 1 つ除去される一方で、バケットには「Interval」ごとに一定レートで「Value」個のトークンが入れられます。
このアルゴリズムは、バケットにトークンが入っていない場合に True に評価され、それ以外の場合は False に評価されます。
このアルゴリズムの説明に役立つ例を示します。Limit=100、Value=5、Interval=1 秒、および Attribute=MessageCount と想定します。
|
HighLow | 「Attribute」が「Value」として指定された上限しきい値に達すると True に評価され、「Attribute」が「Limit」として指定された下限しきい値に達するまで True に評価され続けるアルゴリズム。 |
「wsme:Operator」が「HighLow」である場合、この要素で下限しきい値を、「wsme:Value」で上限しきい値を定義します。 「wsme:Value」のしきい値よりも小さいしきい値を指定してください。 指定されない場合のデフォルトの「Limit」の値は「0」です。
「wsme:Operator」が「TokenBucket」である場合、このエレメントでバーストの最大サイズ、つまりバケット内のトークンの最大数を定義します。一方、「Value」でバケットが入れられるレートを「Interval」ごとのトークン数として指定します。 指定されない場合のデフォルトの「Limit」の値は「0」であり、その場合「TokenBucket」は「GreaterThan」演算子に相当します。
値 | 説明 |
---|---|
SOAPBody | SOAP Body 要素の内容。SOAP 障害に関する特別な処理はありません。(デフォルト) |
SOAPBodyOrDetails | SOAP 障害の詳細要素の内容。それ以外の場合は、Body の内容。 |
SOAPEnvelope | SOAP メッセージ全体 (エンベロープも含む)。 |
SOAPIgnoreFaults | メッセージが SOAP 障害の場合は妥当性検査なし。それ以外の場合は SOAP Body の内容。 |