Classic Actorから
 Typed Actor への移行について
 2021/03/05
 第6回Reactive System Meetup in 西新宿 LT枠
 株式会社スタンバイ
 池田健虎 @taket0ra1


自己紹介
 ● 株式会社スタンバイ
 ● 池田健虎
 ● 2020年12月に娘が生まれて2児の父
 ● Akkaは2020年の冬からさわりはじめました。
 ● 最近業務でやったこと
 ○ EMR on Apache Flink(Scala) ストリーム処理
 ■ 内部ではAkkaが使われています
 ○ スタンバイの広告周りのBatch処理(Actor)
 


Akkaへの関心が高まっている


Akka 2.6.13（ドキュメント）にコミッ トできました🎉



 Actor(Typed)を構築するDSLがClassic Actorと差異が多く、
 私自身理解をすることに時間がかかった。
 
 そこで違いを説明して
 移行する方の参考になればと思いのLTです。
 
 ● シンプルなAkka Actor Typedのカウンターサンプルコード(Scalatestサンプルあ り)
 ● Akka Typed 移行入門 (Scala)
 上記のブログ参考になりました。


● Learning Akka Typed from Classic 公式のドキュメントにも
 ClassicAkkaで開発している方向けに、
 Akka Typed を学ぶ資料があります。


ManuelさんのTour of Akka typed記事は公式ドキュメントからも推薦されてあり、
 今回の発表の参考にしています。


こちらの話はしません
 
 ● akka-cluster-typed
 ● akka-cluster-sharding-typed
 ● akka-persistence-typed
 ● akka-stream-typed
 ● akka-actor-testkit-typed


なぜClassic Actorではなく
 Typed Actorを採用するのか？


なぜClassic ActorではなくTyped Actorを採用するのか？
 
 ● 2019年11月にリリースされたAkka 2.6.0から
 typed Actorが安定版へ
 ● Typed APIがAkkaのメインのAPIになった。
 ○ Akka 2.6.0 Released
 ● メッセージの受け渡しが型安全になった
 ● 状態をもつようなActorをImmutableなコードで
 実装することできる


HelloWorld Greet Greeted 1 2

Actorはどんなメッセージも
 受信できる
 
 
 
 
 Actor間のメッセージの送信で
 どんなメッセージも送信できる。
 Classic Actor

sender()がなく、Greetメッセージを受け取ったアクターは、送信元のActorRef[Greeted]へ、Greetedと、自 身のActorRef返している。
 プロトコルメッセージでActorRef[T]を渡すことで、 
 何を期待しているのかがより明示的になる。 
 Typed Actor
 
 明示的に送信者を表すActorRefを
 メッセージに含める
 Actorを継承する代わりに、 Behaviorを定義して Actorを構築する

プロトコルメッセージ

プロトコルメッセージ
 TypedActorから公式ドキュメントでは単にメッセージではなくプロトコルと呼ばれている。 
 特定の順序と組み合わせで2つ以上のアクター間で交換されるメッセージのセットを 
 意図している。
 プロトコルメッセージ

プロトコルメッセージ
 プロトコル呼び出し方法もフルパスで明確にしている。 
 （公式ドキュメントでも2.6.Xからフルパスで定義されている） 
 左はAkka2.5.Xのドキュメントで、右がAkka2.6.Xのドキュメント 


Akka Typed の場合必ずプロトコルを宣言する必要があり、
 manuelさんの記事では、これをプロトコルファーストと呼んでいる


Classic Actor でも同様にプロトコルを定義できるが強制されていなかった。 
 
 そのためプロトコルを使っていない大規模なアクターシステムの拡張と維持が困難になる。 
 
 また仮にプロトコルを定義したとしても 
 
 ● コンパイル時にメッセージの型チェックができないため、処理できないアクターにメッセージ を渡していた場合に特定が難しい。 
 ● さらに時間の経過に伴うプロトコルの進化を支援するサポートメカニズムがない 
 
 
 


This is where the Akka Typed API comes in. This API is designed to be “protocol-first”: you no longer have a choice but to spend at least a little bit of time thinking about the messages each actor can deal with. Unlike the classic API where following this best practice is optional, you need to formalize the set of handled messages during implementation. そこで Akka Typed API の出番です。この API は "プロトコルファースト" で設計されています。この ベストプラクティスに従うことがオプションである古典的な API とは異なり、実装時に処理されるメッ セージのセットを形式化する必要があります。 Tour of Akka Typed: Protocols and Behaviors より引用

typed Actorのオブジェクト指向スタイル アクターの構築に Actor の代わりに AbstractBehavior[T] が継承して構築する sealed traitでプロトコルを定義 プロトコルが網羅的にチェックされる。

typed Actorの関数型スタイル AbstractBehaviorの代わりに、 より関数型のスタイルとして Behaviorsのファクトリーメソッドある。 （receiveなど） 状態をアクターに持たせたい場合に Immutableに定義することができる

Classic Actorの違い
 
 ● アクター間のメッセージの整合性がコンパイル時にチェックできる
 ○ TypedActorのメッセージの型を宣言する必要がある（強制される）
 ○ コンパイラーは、メッセージの受信者が送信中のメッセージを実際に処理でき るかどうかを静的にチェックできる。
 ● Actor内のmutableなコードがなくなり、ImmutableなコードでActorを実装できる。


項目
 Classic Actor API
 Typed Actor API
 アクター参照
 ActorRef
 ActorRef[T]
 アクターの構築
 extends Actor
 extends AbstractBehavior[T] 
 (オブジェクト指向スタイル) 
 子アクターの生成
 context.actorOf
 context.spawn
 ユーザーガーディアン 
 （/user）
 ActorSystemによって提供される 
 (ユーザーガーディアン) 
 ユーザーによって提供され、 ActorSystemにBehaviorを渡す。 
 デフォルトの
 スーパーバイザーの戦略 
 （監督戦略）
 例外が投げられた際に 
 子アクターを再起動する 
 例外が投げられた際に 
 子アクターを停止する 
 （let it crash）
 概念の比較表(厳密なマッピングの表ではない。)
 Tour of Akka Typed: Protocols and Behaviors 　より


子アクターの生成
 spawnで子アクターを生成している 
 setupはBehaviorの
 ファクトリーの一つ
 またtyped actorにはPreStartとPostRestartシグナルがないので、Behaviors.setupや AbstractBehaviorクラスのコンストラクタから実行する。 


ユーザーガーディアン
 typed Akkaでは、アプリケーションのための追加アクタをユーザーガーディアンから追加 する。初期化を行うと同時に、ユーザーガーディアンから作られる。
 Classic ではActorSystemからactorOfで作っている。
 / /user /system ルートガーディアン
 /user/system

デフォルトのスーパーバイザーの戦略が異なる
 例外が発生した際にClassicActorは子を再起動する。typed Actorは停止させる。 
 typed Actorでも再起動の戦略をカスタマイズもできる。

さらに詳細な違いについてはドキュメントで ● Learning Akka Typed from Classic
 ● Tour of Akka Typed: Protocols and Behaviors

ご静聴ありがとうございました