スーパービジョン と モニタリング

スーパービジョンが意味するもの

アクターシステム にあるようにスーパービジョンはアクターの依存関係を記述します。スーパ＾バイザーはタスクを部下に移譲し、そしてその障害に対応する必要があります。部下が障害を検知したとき (つまり、例外を投げたとき) 、部下は自分自身と自分の部下すべてを停止し、スーパーバイザーにメッセージを送り、障害を伝えます。スーパバイザーの対象の作業の性質と障害の性質によって、スーパーバイザーは次の 4 つのオプションを選択できます。

1. 部下を再開し、蓄積されている内部状態を維持する。

2. 部下をリスタートし、蓄積された内部状態をクリアにする。

3. 部下を永久に停止する。

4. 障害を上位にエスカレートする。したがって自分自身が失敗になる。

アクターをスーパービジョンの階層の一部としてみることは重要であり、それにより 4 つめの選択肢 (あるスーパーバイザーもまた別の上位のスーパーバイザーの部下である) を説明できますし、また最初の3つについても密接な関係があります。アクターの再開はその部下すべてを再開しますし、アクターのリスタートはその部下のすべてをリスタートしますし (ただし、次に述べる詳細を見てください) 、同様にアクターの停止はすべての部下を停止しようとします。 Actor クラスにあるフックの preRestart のデフォルトの動作は、リスタートの前にすべての子供を停止することに注意するべきです。ただし、このフックはオーバーライドが可能であり、フックが実行された後に残ったすべての子供へに対して再帰的なリスタートが適用されます。

各スーパーバイザーは、発生する可能性のあるすべての障害 (つまり例外) を上記に挙げた4つの選択肢の1つに変換する関数で設定されます。特に、この関数は失敗したアクターのアイデンティティを入力にとりません。十分に柔軟に見えないような構造の例を挙げるのはとても簡単であり、例えば、異なる部下に対して異なる戦略を適用したい場合があります。この場合、スーパービジョンが障害を再帰的にハンドリングする形式であることを理解しておくことが不可欠です。1つの階層で沢山のことをしようとすと、理解するのが難しくなります。したがってこの場合、推奨されるのはスーパービジョンの階層を追加することです。

Akka は "親のスーパービジョン" と呼ばれる特定の形式を実装します。アクターは他のアクターによって生成されます。 ただし、トップレベルのあくたーはライブラリによって生成されます。 そして生成された各アクターはその親によって監督されます。この制約はアクターのスーパービジョンの階層を暗黙的にし、設計上の意思決定を行いやすくします。これによりアクターは孤立したり、外部のスーパーバイザーに補足されたりすることが無いことを保証していることに注意してください。そうでなければ、不意に補足したりするかもしれません。さらに、アクターアプリケーション (のサブツリー) の自然で整理されたシャットダウンの手順も獲得できます。

トップレベルのスーパーバイザー

アクターシステムは生成時に最低でも3つのアクターを開始します。そのイメージを上に示しています。アクターパスの結果に関する詳細な情報は アクターパスのトップレベルスコープ を見てください。

リスタートが意味するもの

特定のメッセージの処理にアクターが失敗したとき、 その失敗の原因は 3 つのカテゴリに分類されます。

• 特定の受信メッセージに対する、システム的な (すなわちプログラム上の) エラー

• メッセージ処理中に使用したある外部リソースの (一時的な) 障害

• アクターの内部状態の汚染

障害が明確に認識されない限り、3番目の原因を取り除くことはできず、そのため内部状態を空にする必要があるという結論が導かれます。もしスーパーバイザーがその他の子供や自分自身汚染による影響を受けていないと判断する場合、例えばエラーカーネルパターンを意識的に適用するために、子供をリスタートすることが最善です。これは、子供の ActorRef の内部で Actor 配下の新しいインスタンスを生成して、 障害の起きたインスタンスと新しいものを置き換えることで実現します。この能力がアクターを特別な参照で隠蔽する理由の1つです。新しいアクターはそれから自身のメールボックスの処理を再開します。つまり、リスタートは例外とアクター自身の外部から見えず、障害が起きている間に発生したメッセージは再び処理されることはありません。

リスタート中の正確なイベントの順序は次の通りです。

1. アクターを一時停止 ( 再開するまで通常のメッセージ処理は処理されません ) し、全ての子供も再帰的に一時停止します。

2. 古いインスタンスの preRestart フック ( デフォルトでは全ての子供に停止リクエストを送信し、 postStop を呼び出します ) を 呼び出します。

3. preRestart の中で、 (context.stop() を使って) 停止を要求した全ての子供が実際に停止するまで待機します。この操作は、 全てのアクターの操作がそうであるように、ノンブロッキングなので、 最後に死んだ子供からの停止の通知をもって、次のステップに進むようになるでしょう。

4. オリジナルの提供されたファクトリを再度実行して、新しいアクターのインスタンスを生成します。

5. 新しいインスタンスの postRestart メソッド ( デフォルトでは preStart も呼ばれます ) を実行します。

6. リスタート要求をステップ3 で死ななかった全てのアクターに送信します。リスタートした子供はステップ2 から再帰的に同じ処理を行います。

7. アクターを再開します。

ライフサイクルモニタリングが意味するもの

上記で述べたような親と子の間の特別な関係とは対照的に、各アクターはあらゆる他のアクターを監視するかもしれません。アクターは完全に生きている状態で生成され、リスタートは影響を受けるスーパーバイザーの外部から見えないため、モニタリングが可能な唯一の状態変更は、生存から死亡への変化のみです。このようにモニタリングはあるアクターを別のアクターと結びつけるために使用し、別のアクターの終了に対して反応します。障害に対して反応するスーパービジョンとは対照的です。

ライフサイクルモニタリングは、モニタリングをしているアクターが受け取る Terminated メッセージを使って実装します。このデフォルトの動作は、別途処理しなければ、特定の DeathPactException をスローします。 Terminated メッセージの監視を開始するために、 ActorContext.watch(targetActorRef) を実行します。監視を停止するには、 ActorContext.unwatch(targetActorRef) を実行します。1つの重要な性質に、モニタリング要求と、対象の停止の発生の順序に関係なくメッセージが配信されることがあります。つまり、登録時に対象がすでに死んでいたとしても、メッセージが取得できる場合があります。

モニタリングは、スーパーバイザーが単純に子供をリスタートしたり停止したりできない状況で特に有用です。例えば、アクター初期化中の障害などの場合などです。そのような場合、子供を監視しておき、再生成するか、あるいは、しばらく経ってからリトライするようにスケジュールするべきです。

他によくあるケースとして、アクターが外部リソースがないために失敗させたい場合があります。外部リソースは自身の子供のどれかということもありえます。第三者が 子の system.stop(child) メソッドを呼ぶか、 あるいは子に PoisonPill メッセージを送信すると、 スーパーバイザーに影響を与えるでしょう。

val childProps = Props(classOf[EchoActor])

val supervisor = BackoffSupervisor.props(
  Backoff.onStop(
    childProps,
    childName = "myEcho",
    minBackoff = 3.seconds,
    maxBackoff = 30.seconds,
    randomFactor = 0.2 // adds 20% "noise" to vary the intervals slightly
  ))

system.actorOf(supervisor, name = "echoSupervisor")

import scala.concurrent.duration.Duration;

final Props childProps = Props.create(EchoActor.class);

final Props  supervisorProps = BackoffSupervisor.props(
  Backoff.onStop(
    childProps,
    "myEcho",
    Duration.create(3, TimeUnit.SECONDS),
    Duration.create(30, TimeUnit.SECONDS),
    0.2)); // adds 20% "noise" to vary the intervals slightly

system.actorOf(supervisorProps, "echoSupervisor");

val childProps = Props(classOf[EchoActor])

val supervisor = BackoffSupervisor.props(
  Backoff.onFailure(
    childProps,
    childName = "myEcho",
    minBackoff = 3.seconds,
    maxBackoff = 30.seconds,
    randomFactor = 0.2 // adds 20% "noise" to vary the intervals slightly
  ))

system.actorOf(supervisor, name = "echoSupervisor")

import scala.concurrent.duration.Duration;

final Props childProps = Props.create(EchoActor.class);

final Props  supervisorProps = BackoffSupervisor.props(
  Backoff.onFailure(
    childProps,
    "myEcho",
    Duration.create(3, TimeUnit.SECONDS),
    Duration.create(30, TimeUnit.SECONDS),
    0.2)); // adds 20% "noise" to vary the intervals slightly

system.actorOf(supervisorProps, "echoSupervisor");

val supervisor = BackoffSupervisor.props(
  Backoff.onStop(
  childProps,
  childName = "myEcho",
  minBackoff = 3.seconds,
  maxBackoff = 30.seconds,
  randomFactor = 0.2 // adds 20% "noise" to vary the intervals slightly
).withManualReset // the child must send BackoffSupervisor.Reset to its parent
  .withDefaultStoppingStrategy // Stop at any Exception thrown
)

val supervisor = BackoffSupervisor.props(
  Backoff.onFailure(
    childProps,
    childName = "myEcho",
    minBackoff = 3.seconds,
    maxBackoff = 30.seconds,
    randomFactor = 0.2 // adds 20% "noise" to vary the intervals slightly
  ).withAutoReset(10.seconds) // the child must send BackoffSupervisor.Reset to its parent
    .withSupervisorStrategy(
      OneForOneStrategy() {
        case _: MyException => SupervisorStrategy.Restart
        case _              => SupervisorStrategy.Escalate
      }))

One-For-One Strategy 対 All-For-One Strategy

Akka には、 OneForOneStrategy と AllForOneStrategy の2つのスーパービジョン戦略があります。両者はスーパビジョン命令 ( 上記 を参照) に対する例外の型から対応付けて設定し、終了の前にどの子供が失敗してもよいかを制限します。両者の違いは、前者は取得した命令を失敗した子供だけに適用し、後者は全ての兄弟に対して適用することにあります。通常、デフォルトであり明示する必要のない、 OneForOneStrategy を使用するべきです。

AllForOneStrategy は子供の全体が互いに強く依存していて、1つの子の障害が他の機能に影響を与える場合、つまり不可分の場合、に適用できます。リスタートではメールボックスは破棄されないので、障害時に子供を終了し、スーパバイザから子供を明示的に (子供のライフサイクルの監視によって) 再作成することがベストとなることがよくあります。 それ以外の場合、他のアクターに対して、リスタートの前にキューに入れられたメッセージが、後で処理されなくなることが問題ないことを確認する必要があります。

all-for-one strategy では、正常に子供を停止 ( つまり、障害による停止ではない場合) しても、他の子供を自動的に停止することにはなりません。これはライフサイクルの監視によって簡単に対応できます。もし Terminated メッセージをスーパーバイザーがハンドリングしなかった場合、 DeathPactException がスローされ、(スーパーバイザーに応じて) リスタートされます。そして、 preRestart のデフォルトの動作で全ての子供が終了します。もちろんこれらを明示的にハンドリングすることもできます。

all-for-one supervisor から一度限りのアクターを生成することは、一時的なアクターによってエスカレートされた障害が永久的に全てに影響することに注意が必要です。もしこれが望ましくないのなら、中間のスーパーバイザーを導入します。これは、サイズが 1 のルーターをワーカーとして宣言することでとても簡単に実現できます。 Routing か Routing を参照してください。