実装ガイド › ケース スタディ例 › 効果的なビジネス ロジック例の作成 › ケース スタディ 15： クラスタ化メトリック

ケース スタディ 15： クラスタ化メトリック

通常、あるソフトウェアを説明するとき、説明は WHAT および HOW の 2 つの部分に分割できます。 WHAT は、この一片のコードが何を実行するかの説明を意味します。 HOW は、どのようにそれを実行するかです。 WHAT の部分に専念し、HOW の部分を無視する傾向があります。 その理由は単純で、多くの場合は正当化されます。 そうすることによって、コンポーネント間の結合を縮小し、多くの場合無関係の情報に煩わされなくなります。 しかし、多くの場合、HOW の部分を無視するのは割に合いません。

このケース スタディでは、エンジンがクラスタ化メトリックを計算する方法（HOW 部分への回答）を説明し、特定の実装について結果として伴うパフォーマンス コストを説明します。 また、実装法を変更することにより、このコストを削減する方法をいくつか説明しています。

クラスタ化メトリックとは

クラスタ化メトリックは、それらの定義内にリソースのあるグループを埋め込んだメトリックです。 このグループはメトリックのクラスタと呼ばれ、そのグループ内のリソースはそれぞれクラスタ アイテムと呼ばれます。 クラスタ化メトリックを計算するとき、それらのクラスタ アイテムに対して個別の計算が実行されます。 それらのクラスタ アイテムそれぞれの計算は次のものを除いて互いに似ています。

• Context.ClusterItem - 計算されているクラスタ アイテムに等しい Context.ClusterItem プロパティの値。
• クラスタ アイテムによる登録 - メトリックがクラスタ アイテムによりイベントに登録されるとき、各クラスタ アイテムは Raw データとこのクラスタ アイテムに送信される再利用性イベントを受信します。

クラスタ化メトリックの計算方法

クラスタ化メトリックの計算について理解する必要のある重要なことは、クラスタ アイテムはすべて並行して計算されるということです。 並行ということは、別々のスレッドで計算されるという意味ではなく、さまざまなクラスタ アイテムにより処理される必要のあるさまざまなイベントを処理する間、イベントはシーケンシャルに処理され、それぞれのイベントに対して関連するクラスタ アイテムが呼び出されてこのイベントを処理するということです。 たとえば、多くのクラスタ アイテムによって処理される必要のある多くのイベントがあります。 これを行う方法は 2 とおりあります。

例： オプション 1

各クラスタ アイテム C に対し
     C によって処理される必要のある各イベント E に対し
          C に E を処理させる

例： オプション 2

各イベント E に対し
     E を処理する必要のある各クラスタ アイテム C に対し
          C に E を処理させる

エンジンはオプション 2 を使用して、クラスタ化メトリックを処理します。

理解する必要のある別の重要なポイントは、PslWriter の内部の VBScript は Script Control と呼ばれるコンポーネントによって実行されるということです。 各メトリックについてこのコンポーネントのインスタンスはただ 1 つのみで、このインスタンスはさまざまなクラスタ アイテムの計算に再利用されます。 前に述べたようにクラスタ アイテムは並行に計算され、Script Control コンポーネントは各瞬間に単一のクラスタ アイテムのみを含むことができるので、Script Control コンポーネントの内部のデータを頻繁にスイッチする必要があります。

これについて説明するために、その計算を実行するさらに詳しい疑似コードを下に示します。

1- 各メトリック M に対し
2- X を M によってまだハンドルされていない最初のイベントとする
3- T を X の前の最新の状態のタイム スタンプとする
4- L をタイム スタンプ T から現在の時刻までの、M に登録されたすべてのイベントのリスト（すべてのクラスタ アイテム）とする
5- L 内の各イベント E に対し
6- E を処理する必要のある各クラスタ アイテム C に対し
7- C' を、現在スクリプト コントロールにロードされているクラスタ アイテムとする
8- スクリプト コントロールからグローバル変数の値をとって C'用に別に格納する
9- C 用の別に格納されたグローバル変数の値を取り、スクリプト コントロールにロードする
10- イベント E の処理

まだ考慮に入れられていなくて、次にこのポイントから先の計算を実行するイベントの時間を見つけるこの全工程は、再計算と呼ばれます。 グローバル変数（上記のコードの手順 8 および 9）の値を置換する過程は、コンテキスト スイッチングと呼ばれます。

上記のコード中で容易にわかる、2 つの主要な問題は次のとおりです。

• 再計算は、すべてのクラスタ アイテムに対してまとめて行われます。 時間 T の点（上記コードの手順 3）は一度発見され、次にクラスタ アイテムはすべてその点を基準に再計算を実行します。 これは、単一のクラスタ アイテムに新規イベントがある場合は常にクラスタ アイテムすべてが再計算されることを意味します。
• コンテキスト スイッチングは頻繁に行われます。 コンテキスト スイッチング（上記コードの手順 8 および 9）は内部ループの内側にあるので、簡単にわかります。

クラスタ化メトリックの再計算

• 問題の解説

  すでに説明されていたように、クラスタ化メトリック内のクラスタ アイテムはすべてまとめて再計算されます。 これは、1000 クラスタ アイテムを超えてクラスタ化されるメトリックがあり、届いたある新イベントのためにそのうちの 1 つを再計算する必要がある場合、その 1000 のクラスタ アイテムすべてが昨年度に対して再計算されます。

• 解決法

  以下のソリューション提案は、この問題の負担を軽減できます。しかし、それらは必ずしも常に適用可能ではなく、各々不利な点もあります。 重要なのは、問題とその見積もりコストを理解し、このコストを提案されたソリューションのコストと比較することです。

  • クラスタ アイテムの数が少ないとき、それらの各々を個別のメトリックとして定義するオプションを検討できます。 この方法の欠点はもちろん、複数のメトリックを維持するコストと、メトリック全体のレポートおよび次に特定のクラスタ アイテムの掘り下げができないことです。
  • クラスタ アイテムの数は多いが、頻繁に再計算されるのはそれらのうちのほんの 1 つ（または少数）のとき、このクラスタ アイテムを別のメトリックに入れ、残りのクラスタ アイテムすべてを他のメトリックに入れることを検討できます。
  • このメトリックが長時間の再計算を行わないように、関連する契約/メトリックに対する計算凍結を頻繁に使用します。
  • 長い再計算がないように（つまり、タイムスタンプが 1 か月より古いイベントを送信しないように）、アダプタおよびそのデータ ソースである変更を実行します。

コンテキスト スイッチング

• 問題の解説

  すでに説明したように、コンテキスト スイッチングは最も内側のループ中で実行されます。 言い換えれば、クラスタ アイテムごとに処理される必要のある各イベントに対して実行されます。 メトリックが多くのイベントを受信し、各イベントが多くのクラスタ アイテムによって処理されるとき、この量は非常に高くなる可能性があります。 コンテキスト スイッチング操作が（ビジネス ロジック内のイベント自体の取り扱いとの比較で）比較的高価で、問題であることを付け加えておきます。

  コンテキスト スイッチング操作のコストは、スイッチングしたデータのサイズに比例します。 私たちがコンテキスト スイッチ中に切り替えるデータは、ビジネス ロジック（"状態" とも呼ぶ）内のすべてのグローバル変数の値です。 したがって、グローバル変数が多くなり、それらのグローバル変数のサイズが大きくなるにつれて、コンテキスト スイッチング操作はそれだけ高くつくようになります。

  特に、ビジネス ロジック マップをクラスタ化メトリック中で使用することは、特にそれらのマップのサイズが大きくなる可能性がある場合、お勧めできません。

• 解決法
  • コンテキスト スイッチの各々の時間を縮小

    目的は状態（グローバル変数）のサイズを小さくすることです。 この方法は、マップを含まないようにビジネス ロジックを書き直すことにより実現できます。 もちろん、常に可能だとは限りませんが、可能な場合は推奨します。

  • コンテキスト スイッチの量を減らす

    クラスタが小さいとき、クラスタ アイテムごとに個別のメトリックを作成することが可能です。

    同一イベントに登録する多数のクラスタ化された項目を備えるクラスタ化メトリックは避けます。 この目的を以下に示します。

    イベントがそれぞれ単一のクラスタ アイテムによって処理される場合、コンテキスト スイッチングの量はイベントの数に比例します。

    イベントがそれぞれすべてのクラスタ アイテムによって処理される場合、コンテキスト スイッチングの量は、イベント数にクラスタ アイテム数をかけたものに比例します。

    元のクラスタ アイテム（それらは現在クラスタ アイテムではなく単純なリソースである）のすべてに対する結果を計算する非クラスタ化メトリックを作成します。 このメトリックにイベントとしてクラスタ アイテムの各々の結果を送らせます。 クラスタ化され、最初のメトリックからイベントを受信する別のメトリックを作成し、それらのイベントで受信した値を結果としてレポートします。 ここでのアイデアは、大きな量の Raw データ イベントが非クラスタ化メトリックによって処理されるということです。また、クラスタ化メトリックは、クラスタ アイテムについて期間当たりの単一のイベントを処理します。