EIPとAkkaについて - Speaker Deck

EIPとAkkaについて

by かとじゅん

Slide 1

Slide 1 text

EIPとAKKAについてかとじゅん( ) 2022/02/09 実践！インテグレーションパターン現場から学ぶモデル駆動設計 @j5ik2o 1

Slide 2

Slide 2 text

自己紹介 Chatwork社テックリード副業では技術顧問として活動中 FizzBuzzを書くためだけのプログラミング言語を作りました @j5ik2o https://github.com/j5ik2o/oni-comb-rs 2

Slide 3

Slide 3 text

EIPとAKKAについて話します 3

Slide 4

Slide 4 text

具体的には配送保証(GUARANTEED DELIVERY) のパターンを解説しますが、前提知識を少し話します。 4

Slide 5

Slide 5 text

AGENDA 通信は届かない(ことがある) メッセージ配送の保証配送保証(Guaranteed Delivery) Akkaの簡単な実装例とReliable Delivery 5

Slide 6

Slide 6 text

送信したデータが相手に必ず届くと思い込んでませんか？ 6

Slide 7

Slide 7 text

通信は届かない(ことがある) 少なくとも現時点では失敗のないネットワークを構築することは不可能と言われている。メッセージが欠落したり、遅延したりする可能性は必ずある。今の技術で避けられないよく考えられたシステムは、この問題をカバーするように設計されている(それでも限界がある)。そのような考慮がないシステムでは容易にメッセージの欠落や矛盾が起こる 7

Slide 8

Slide 8 text

「なぜ届かないのか」を理解する 8

Slide 9

Slide 9 text

アナロジー：二人の将軍問題信頼性の低い通信チャネルではコンセンサスに達することが不可能である Two Generals' Problem 二人の将軍問題 9

Slide 10

Slide 10 text

二人の将軍問題(1/4) 赤が敵軍、緑が同盟軍。同盟軍A or Bが単独攻撃しても数で負けるが、AとB 一緒に攻撃すれば勝てる可能性がある。しかし、軍隊は谷間に位置しているため、旗などの遠隔通信で攻撃の時間を指示することは不可能彼らはコミュニケーションのために敵地を経由して使者(メッセンジャー)を送る。が、敵地を経由するので使者は捕まったり殺されたりする可能性がある⼭⼭敵軍同盟軍A 同盟軍B 10

Slide 11

Slide 11 text

この問題は「信頼性の低い通信路」で何が起きるかを示している 11

Slide 12

Slide 12 text

二人の将軍問題(2/4) 将軍Aから将軍Bに「14時に攻撃する」ということをメッセンジャーを通じて送る。無事に将軍Bにメッセージが届いた場合メッセンジャーは無事に敵地を通り抜けて、将軍Bにメッセージを伝える。将軍A 将軍A 敵地敵地将軍B 将軍B 14時に攻撃する 12

Slide 13

Slide 13 text

二人の将軍問題(3/4) 将軍Bから将軍Aに返信がない場合、将軍Aはどう考えるか将軍Aはメッセンジャーが将軍Bに到着したかを知らない。敵地で殺されたかもしれない。将軍Bは「14時に攻撃する」を知らない可能性がある。将軍Bが攻撃の準備ができていないかもしれない将軍A 将軍A 敵地敵地将軍B 将軍B 14時に攻撃する了解なので、将軍Bは「了解」ということをメッセンジャーを通じて返信もらう必要がある(返信が来ない場合はリトライするかも) 13

Slide 14

Slide 14 text

二人の将軍問題(4/4) が、これもメッセージが将軍Aに届かない可能性がある厳密には「了解」が伝わったかは、将軍Aからの「了解の了解」の返信を待つ必要がある… 将軍A 将軍A 敵地敵地将軍B 将軍B 14時に攻撃する了解了解の了解？？これでは完全に合意するには無限のメッセージを送る必要がある… 14

Slide 15

Slide 15 text

低信頼網では 100％の合意に到達できないどんなに多くの要求を送っても、どんなに多くの返答を送っても、将軍Aも将軍Bも相手の将軍が攻撃の準備をしていることを100％確信することはできません。これが「二人の将軍問題」の核心です 15

Slide 16

Slide 16 text

ネットワークを使ったメッセージ配送も信頼性の低い通信路を使った通信の一つ 16

Slide 17

Slide 17 text

メッセージ配送にはこれらを考慮したモデルがある 17

Slide 18

Slide 18 text

メッセージ配送の信頼性(1/2) At-Most-Once Delivery メッセージは0回もしくは1回配送される (tellの場合は)送ったけど相手に届かないことがある askによって返信を確認することはできるとはいえ、タイムアウトしたときリトライするなら、at- most-once以上のことをやろうとしている高パフォーマンス・低コスト 18

Slide 19

Slide 19 text

メッセージ配送の信頼性(1/2) At-Least-Once Delivery メッセージは少なくとも1回配送が成功する相手にメッセージが重複して届く可能性がある送信側に必ずディスクが必要になる Exactly-Once Delivery メッセージは正確に1回だけ配送される受信側にもディスクが必要になるデフォルトのメッセージ配送は「At-Most-Once Delivery」です。運がよかったら届くかもね！そんなインテグレーションで大丈夫か？！ 19

Slide 20

Slide 20 text

そこでEIPですよ 20

Slide 21

Slide 21 text

配送保証(GUARANTEED DELIVERY) At-Least-Once Deliveryのために 21

Slide 22

Slide 22 text

メッセージングシステムが故障しても、送信者がメッセージを確実に届けられるようにするには？メッセージを配送するシステム＝メッセージングシステム messaging system sender receiver 22

Slide 23

Slide 23 text

メッセージの保存と転送のプロセス非同期に動作するメッセージングは送信者・受信者、そしてそれらを繋ぐネットワークが同時に動作している必要がない(同期型のRPCは障害に弱い) メッセージングシステムがネットワークを利用できない場合、ネットワークが利用可能になるまでメッセージを保存すればよい。受信者が利用できない場合も、メッセージを保存しておき、受信者が利用できるようになるまでリトライする。 23

Slide 24

Slide 24 text

受信者が故障で不通なら送信者はリトライする。リトライ中送信者が故障しても大丈夫？ 24

Slide 25

Slide 25 text

いいえ当然リトライ中であることも忘れます 25

Slide 26

Slide 26 text

メッセージが揮発しないようにメッセージを永続化するメッセージングシステムがノード障害などを起こせば、保持しているメッセージはすべて消失する。対策としてファイルやデータベースなどを使ってディスクに永続化する必要がある Apache Kafkaがまさに同じようなことをやっています(ブローカーが仲介するので厳密には同じではないが) 26

Slide 27

Slide 27 text

配送保証(GUARANTEED DELIVERY) のPROS/CONS 配送保証パターンでは、メッセージングシステムはデータストアを使ってメッセージを保存します 27

Slide 28

Slide 28 text

送信者が故障しても復旧後にメッセージは送信される送信側のPCのローカルに保存されます。メッセージ送信際、データストアにメッセージが保存されるまで送信操作は正常に完了しない。メッセージが正常に送信されたら、データストアからメッセージが削除される 28

Slide 29

Slide 29 text

信頼性を得る代わりにパフォーマンスが犠牲になるメッセージの永続性は信頼性を高めるが、パフォーマンスが犠牲になる。メッセージ配送のクラッシュやシャットダウン時にメッセージが失われても構わない場合は、配送保証パターンを採用しないほうがパフォーマンスがよくなる(トレードオフ) 29

Slide 30

Slide 30 text

FYI: EXACTLY-ONCE DELIVERY = 配送保証(GUARANTEED DELIVERY) + べき等レシーバー(IDEMPOTENT RECEIVER) 30

Slide 31

Slide 31 text

AKKAでどう実装するか 31

Slide 32

Slide 32 text

簡単なモデルを示した例 network Sender«Actor» Forwarder«PersistentActor» Receiver«Actor» 32

Slide 33

Slide 33 text

登場人物 Receiver Forwarder Sender https://github.com/j5ik2o/akka-at-least-once- delivery/blob/main/src/main/scala/example/simple/Receive https://github.com/j5ik2o/akka-at-least-once- delivery/blob/main/src/main/scala/example/simple/Forwar https://github.com/j5ik2o/akka-at-least-once- delivery/blob/main/src/test/scala/example/simple/AtLeastO 33

Slide 34

Slide 34 text

この設計の問題点リトライ間隔やリトライ上限回数がないので、リトライによってネットワークに負荷をかける可能性がある Akkaでは指数関数バックオフに対応したBackoffSupervisorによって解決できるメッセージの追い越しできない場合は、メッセージを蓄積しつつフロー制御が必要になる AkkaのStashBufferでバッファリングしつつ、 akka-persistenceの機能によって受け付けたメッセージを蓄積するこのサンプルでは、故障しやすいタスクをReceiverが担う場合、故障中のメッセージ配送をどうするかという問題がある EIPのように受信側にも故障しにくい仲介者が必要。仲介者としてSupervisorを間にいれる Akka Reliable Deliverも選択肢の一つ 34

Slide 35

Slide 35 text

AKKA RELIABLE DELIVERY https://doc.akka.io/docs/akka/current/typed/reliable- delivery.html https://github.com/j5ik2o/akka-at-least-once- delivery/tree/main/src/main/scala/example/delivery 35

Slide 36

Slide 36 text

まとめ一般的にメッセージ配送には保証がない(TCPもHTTPもat-most- once) その代わりに高パフォーマンス・低コストちゃんと届けるにはそれなりの仕組みが必要になるそれが配送保証(Guaranteed Delivery) 配送保証(Guaranteed Delivery)によってat-leaset-onceを実現する Akkaには、配送保証(Guaranteed Delivery)の考え方が設計思想に組み込まれている PersistentActorでも実現可能 Akka組込のReliable Deliveryを使うことも可能 36

Slide 37

Slide 37 text

終わり 37