Zen of Akka

23 514 vues

Publié le

A collection of most important hints and patterns to use in your Akka apps straight from the team.

Publié dans : Internet
0 commentaire
88 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
23 514
Sur SlideShare
0
Issues des intégrations
0
Intégrations
10 795
Actions
Partages
0
Téléchargements
276
Commentaires
0
J’aime
88
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • The company soon to be previously known as Typesafe
  • You need a fishing rod, sure. But to cook the fish you’ll want to use a knife and something to cook it in as well. So you’ll need different tools.
  • Zen of Akka

    1. 1. Konrad `@ktosopl` Malawski @ Tokyo, Scala Matsuri 2016 の zen
    2. 2. Konrad `ktoso` Malawski (we’re renaming soon!) Akka Team, Reactive Streams TCK, Maintaining Akka Http
    3. 3. Konrad `@ktosopl` Malawski akka.io typesafe.com geecon.org Java.pl / KrakowScala.pl sckrk.com / meetup.com/Paper-Cup @ London GDGKrakow.pl lambdakrk.pl (we’re renaming soon!)
    4. 4. はじめまして! Who are you guys?
    5. 5. Why such talk? 1番: One actor is no Actor 2番: Structure your Actors 3番: Name your Actors 4番: ”Matrix of mutability (Pain)” 5番: Blocking needs careful management 6番: Never Await, for/flatMap instead! 7番: Avoid Java Serialization 7.5番: Trust no-one, benchmark everything! Agenda 8番: Let it Crash! 9番: Backoff Supervision 10番: Design using State Machines 11番: Cluster Convergence and Joining 12番: Cluster Partitions and “Down” 13番: Akka is a Toolkit. 14番: Happy Hakking, Community! Questions?
    6. 6. “The Tao / Zen of Programming” Talk title loosely based on the “Tao of Programming” book by Goeffrey James (1987). 「プログラミングの Tao (道)」
    7. 7. “The Tao / Zen of Programming” And the follow-up book “Zen of Programming”. 「プログラミングの Zen (禅)」の 2冊に影響を受けたトーク
    8. 8. “The Tao / Zen of Programming” Available here: http://www.mit.edu/~xela/tao.html Series of nine “books”, stories about an apprentice programmer and his sensei. Thus spake the Master Programmer: “Without the wind, the grass does not move. Without software hardware is useless.” 師が弟子に語る形式の 9冊シリーズの一部 「風無くば草は揺れず。ソフト無くばハードは無用の長物。」
    9. 9. The Akka landscape
    10. 10. The Akka landscape Akka Actor IO Cluster Cluster Tools (PubSub, Sharding, …) Persistence & Persistence Query Streams HTTP Typed
    11. 11. 1番: One actor is no Actor 1つのアクターは、0個のアクター
    12. 12. 1番: One actor is no Actor アクターは他のアクターと協調するためにある アクターは一つの責務に特化するべき
    13. 13. 1番: One actor is no Actor If you have only one actor then it can only… 1. Reply 2. Drop the message (“ignore” 3. Schedule another message to self So we’re not really making any use of its parallelism or concurrency capabilities. アクターは他のアクターと協調するためにある アクターは一つの責務に特化するべき
    14. 14. 1番: One actor is no Actor アクターは他のアクターと協調するためにある アクターは一つの責務に特化するべき
    15. 15. 1番: One actor is no Actor アクターは他のアクターと協調するためにある アクターは一つの責務に特化するべき
    16. 16. 1番: One actor is no Actor アクターは他のアクターと協調するためにある アクターは一つの責務に特化するべき
    17. 17. 1番: One actor is no Actor アクターは他のアクターと協調するためにある アクターは一つの責務に特化するべき
    18. 18. 1番: One actor is no Actor アクターは他のアクターと協調するためにある アクターは一つの責務に特化するべき
    19. 19. 1番: One actor is no Actor - Actors are meant to work together. - An Actor should do one thing and do it very well - then talk to other Actors to do other things for it.
 - Child Actors usually used for workers or “tasks” etc.
 - Avoid using `actorSelection`,
 introduce Actors to each other. アクターはエンティティーを表す それぞれが「一貫性の島」であるべき
    20. 20. 2番: Structure your Actors
    21. 21. 2番: Structure your Actors Different types… but no structure!
    22. 22. 2番: Structure your Actors Parent / child relationships also allow for Actor supervision.
    23. 23. 2番: Structure your Actors
    24. 24. 3番: Name your Actors
    25. 25. 3番: Name your Actors // default context.actorOf(childProps) // "$a", "$b", "$c" Default names are: BASE64(sequence_nr++) Here’s why: - cheap to generate - guarantees uniqueness - less chars than plain numbers
    26. 26. 3番: Name your Actors // default: naming is BASE64(sequential numbers) context.actorOf(childProps) // "$a", "$b", "$c" // better: but not very informative... context.actorOf(childProps, nextFetchWorkerName) // "fetch-worker-1", "fetch-worker-2" private var _fetchWorkers: Int = 0 private def nextFetchWorkerName: String = { _fetchWorkers += 1 s”fetch-worker-${_fetchWorkers}” } Sequential names are a bit better sometimes.
    27. 27. 3番: Name your Actors // default: naming is BASE64(sequential numbers) context.actorOf(childProps) // "$a", "$b", "$c" // better: but not much informative... context.actorOf(childProps, nextFetchWorkerName) // "fetch-worker-1", "fetch-worker-2" private var _fetchWorkers: Int = 0 private def nextFetchWorkerName: String = { _fetchWorkers += 1 s”fetch-worker-${_fetchWorkers}” } abstract class SeqActorName { def next(): String def copy(name: String): SeqActorName } object SeqActorName { def apply(prefix: String) = new SeqActorNameImpl(prefix, new AtomicLong(0)) } final class SeqActorNameImpl(val prefix: String, counter: AtomicLong) extends SeqActorName { def next(): String = prefix + '-' + counter.getAndIncrement() def copy(newPrefix: String): SeqActorName = new SeqActorNameImpl(newPrefix, counter) } If you use this pattern a lot, here’s a simple encapsulation of it:
    28. 28. 3番: Name your Actors // default: naming is BASE64(sequential numbers) context.actorOf(childProps) // "$a", "$b", "$c" // better: but not much informative... context.actorOf(childProps, nextFetchWorkerName) // "fetch-worker-1", "fetch-worker-2" private var fetchWorkers: Int = 0 private def nextFetchWorkerName: String = { fetchWorkers += 1 s"fetch-worker-$fetchWorkers" } // BEST: proper names, based on useful information context.actorOf(childProps, fetcherName(videoUrl)) // "fetch-yt-MRCWy2E_Ts", ... def fetcherName(link: Link) = link match { case YoutubeLink(id, metadata) => s"fetch-yt-$id" case DailyMotionLink(id, metadata) => s"fetch-dm-$id" case VimeoLink(id, metadata) => s"fetch-vim-$id" } Meaningful names are the best! アクターが適切に命名すべき アクターの名前は一意で、内容と構造を表す
    29. 29. 3番: Name your Actors Meaningful names are the best! import akka.actor.OneForOneStrategy import akka.actor.SupervisorStrategy._ import scala.concurrent.duration._ // ... extends Actor with ActorLogging { override def supervisorStrategy: SupervisorStrategy = OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1.minute) { case ex: Exception ⇒ log.warning("Child {} failed with {}, attempting restart...", sender().path.name, ex.getMessage) Restart } The name of the failed child Actor!
    30. 30. 3番: Name your Actors Meaningful names are the best! import akka.actor.OneForOneStrategy import akka.actor.SupervisorStrategy._ import scala.concurrent.duration._ // ... extends Actor with ActorLogging { override def supervisorStrategy: SupervisorStrategy = OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1.minute) { case ex: Exception ⇒ log.warning("Child {} failed with {}, attempting restart...", sender().path.name, ex.getMessage) Restart } The name of the failed child Actor! // BAD –– String ALWAYS built log.debug(s"Something heavy $generateId from $physicalAddress") // GOOD! –– String built only when DEBUG level is ON log.debug("Something heavy {} from {}", generateId, physicalAddress) Side note: always use {} log formatting (or macros), not s””
    31. 31. 4番: ”Matrix of mutability (Pain)”
    32. 32. 4番: ”Matrix of mutability (Pain)” See Jamie Allen’s talk on the subject. さまざまな可変性 ミュータブル+値よりも、イミュータブル+変数
    33. 33. 4番: ”Matrix of mutability (Pain)” See Jamie Allen’s talk on the subject. さまざまな可変性 ミュータブル+値よりも、イミュータブル+変数
    34. 34. 4番: ”Matrix of mutability (Pain)” See Jamie Allen’s talk on the subject. さまざまな可変性 ミュータブル+値よりも、イミュータブル+変数
    35. 35. 4番: ”Matrix of mutability (Pain)” See Jamie Allen’s talk on the subject. さまざまな可変性 ミュータブル+値よりも、イミュータブル+変数
    36. 36. 4番: ”Matrix of mutability (Pain)” See Jamie Allen’s talk on the subject. さまざまな可変性 ミュータブル+値よりも、イミュータブル+変数
    37. 37. 4番: ”Matrix of mutability (Pain)” さまざまな可変性 ミュータブル+値よりも、イミュータブル+変数
    38. 38. 5番: Blocking needs careful management 正しくは「ブロッキングは注意深く管理すべき」 バルクヘッド(防水隔壁)パターンが有効
    39. 39. 5番: Blocking needs careful management Blocking operations are really bad. Actors are all about resource sharing, and if someone is “behaving badly” it hurts everyone. Here is an example how blocking can grind an app to a halt. Next we’ll see how to avoid that… even if we have to live with the blocking code. ブロック操作を使ってはいけない アクター同士が共有するリソースを独り占めすると皆が困る
    40. 40. 5番: Blocking needs careful management In simple terms: Blocking is bad because instead of doing something else, we just wait and do nothing (wasting CPU time)… ブロック操作を使ってはいけない アクター同士が共有するリソースを独り占めすると皆が困る
    41. 41. 5番: Blocking needs careful management Future でブロックしている悪い例 デフォルトのディスパッチャーが枯渇する
    42. 42. 5番: Blocking needs careful management Having that said, it’s not a bad question. Let’s investigate. Future でブロックしている悪い例 デフォルトのディスパッチャーが枯渇する
    43. 43. 5番: Blocking needs careful management // BAD! (due to the blocking in Future): implicit val defaultDispatcher = system.dispatcher val routes: Route = post { complete { Future { // uses defaultDispatcher Thread.sleep(5000) // will block on the default dispatcher, System.currentTimeMillis().toString // starving the routing infra } } } Future でブロックしている悪い例 デフォルトのディスパッチャーが枯渇する
    44. 44. 5番: Blocking needs careful management // BAD! (due to the blocking in Future): implicit val defaultDispatcher = system.dispatcher val routes: Route = post { complete { Future { // uses defaultDispatcher Thread.sleep(5000) // will block on the default dispatcher, System.currentTimeMillis().toString // starving the routing infra } } } Future でブロックしている悪い例 デフォルトのディスパッチャーが枯渇する
    45. 45. 5番: Blocking needs careful management // application.conf my-blocking-dispatcher { type = Dispatcher executor = “thread-pool-executor" thread-pool-executor { // in Akka previous to 2.4.2: core-pool-size-min = 16 core-pool-size-max = 16 max-pool-size-min = 16 max-pool-size-max = 16 // or in Akka 2.4.2+ fixed-pool-size = 16 } throughput = 100 }
    46. 46. 5番: Blocking needs careful management // GOOD (due to the blocking on a dedicated dispatcher): implicit val blockingDispatcher = system.dispatchers.lookup("my-blocking-dispatcher") val routes: Route = post { complete { Future { // uses the good "blocking dispatcher" that we configured, // instead of the default dispatcher – the blocking is isolated. Thread.sleep(5000) System.currentTimeMillis().toString } } } Future でブロックしている良い例 別のディスパッチャーに隔離
    47. 47. 5番: Blocking needs careful management The “Never block!” mantra sounds cool, but actually what we mean by it is “blocking needs careful management”. We use the “bulkhead” pattern separate out potentially blocking behaviours to their independent dispatchers (and should always do so). http://stackoverflow.com/questions/34641861/akka-http-blocking-in-a-future-blocks-the-server/34645097#34645097
    48. 48. 6番: Never Await, for/flatMap instead!
    49. 49. 6番: Never Await, for/flatMap instead! // ... extends Actor { import context.dispatcher import scala.concurrent.duration._ import scala.concurrent.Await // bad sign! // BAD!!! val fThings: Future[Things] = computeThings() val t: Things = Await.result(fThings, atMost = 3.seconds) val d: Details = Await.result(moreDetailsFor(t), atMost = 3.seconds) Await してはいけない 代わりに map 関数を使う
    50. 50. 6番: Never Await, for/flatMap instead! // ... extends Actor { import context.dispatcher import scala.concurrent.duration._ import scala.concurrent.Await // bad sign! // BAD!!! val fThings: Future[Things] = computeThings() val t: Things = Await.result(fThings, atMost = 3.seconds) val d: Details = Await.result(moreDetailsFor(t), atMost = 3.seconds) // Good: val fThingsWithDetails = for { t <- computeThings() d <- moreDetailsFor(t) } yield t -> d fThingsWithDetails foreach { case (things, details) => // case (things: Things, details: Details) => println(s"$things with $details") } Await してはいけない 代わりに map 関数を使う
    51. 51. 6番: Never Await, for/flatMap instead! // ... extends Actor { import context.dispatcher import scala.concurrent.duration._ import scala.concurrent.Await // bad sign! // BAD!!! val fThings: Future[Things] = computeThings() val t: Things = Await.result(fThings, atMost = 3.seconds) val d: Details = Await.result(moreDetailsFor(t), atMost = 3.seconds) // Good: val fThingsWithDetails = for { t <- computeThings() d <- moreDetailsFor(t) } yield t -> d fThingsWithDetails foreach { case (things, details) => // case (things: Things, details: Details) => println(s"$things with $details") } // adding timeout: val timeoutFuture = akka.pattern.after(3.seconds, context.system.scheduler) { Future.failed(new TimeoutException("My timeout details...")) } Future.firstCompletedOf(fThingsWithDetails :: timeoutFuture :: Nil) foreach { case (things, details) => // case (things: Things, details: Details) => println(s"$things with $details") } Await してはいけない 代わりに map 関数を使う
    52. 52. 7番: Avoid Java Serialization
    53. 53. 7番: Avoid Java Serialization Java Serialization is the default one in Akka, since it’s easy to get started with it – no configuration needed. If you need performance and are running on multiple nodes, you must change the serialization. Popular formats are ProtoBuf or Kryo. Kryo is easier, but harder to evolve schema with. ProtoBuf is harder to maintain but great schema evolution. Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    54. 54. 7番: Avoid Java Serialization Benchmarking serialization impact on “ping pong” case. (Two actors sending a message between them.) in-process messaging, super fast.
 no serialization overhead. Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    55. 55. 7番: Avoid Java Serialization more work => increased latency => decreased throughput. over-the-network messaging, slower due to network and serialization. Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    56. 56. 7番: Avoid Java Serialization Java Serialization is known to be: very slow & footprint heavy Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    57. 57. 7番: Avoid Java Serialization It is on by default in Akka… Why? a) zero setup => simple to “play around” b) historical reasons - hard to remove the default Since 2.4 a warning is logged:
 WARNING: Using the default Java serializer for class [{}] which is not recommended because of performance implications. Use another serializer or disable this warning using the setting 'akka.actor.warn-about-java-serializer-usage' Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    58. 58. 7番: Avoid Java Serialization sbt> jmh:run 
 -f 1 -tu us 
 -wi 20 -i 10 -jvm /home/ktoso/opt/jdk1.8.0_65/bin/java -jvmArgsAppend -XX:+PreserveFramePointer -bm avgt .*pingPong.* [info] # JMH 1.10.3 (released 184 days ago, please consider updating!) [info] # VM version: JDK 1.8.0_65, VM 25.65-b01 [info] # VM invoker: /home/ktoso/opt/jdk1.8.0_65/bin/java [info] # VM options: -XX:+PreserveFramePointer [info] # Warmup: 20 iterations, 5 s each [info] # Measurement: 10 iterations, 1 s each [info] # Timeout: 10 min per iteration [info] # Threads: 1 thread, will synchronize iterations [info] # Benchmark mode: Average time, time/op [info] # Benchmark: akka.actor.ForkJoinActorBenchmark.pingPong [info] # Parameters: (serializer = java) github.com/ktoso/sbt-jmh openjdk.java.net/projects/code-tools/jmh/ Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    59. 59. 7番: Avoid Java Serialization [info] # Warmup Iteration 1: 35.717 us/op . . . [info] # Warmup Iteration 19: 25.164 us/op [info] # Warmup Iteration 20: 23.862 us/op [info] Iteration 1: 25.790 us/op . . . [info] Iteration 10: 26.168 us/op 
 [info] Result "pingPong": [info] 25.464 ±(99.9%) 1.175 us/op [Average] [info] (min, avg, max) = (24.383, 25.464, 26.888), stdev = 0.777 [info] CI (99.9%): [24.289, 26.639] (assumes normal distribution) [info] ForkJoinActorBenchmark.pingPong java avgt 10 25.464 ± 1.175 us/op [info] ForkJoinActorBenchmark.pingPong off avgt 10 0.967 ± 0.657 us/op github.com/ktoso/sbt-jmh openjdk.java.net/projects/code-tools/jmh/ Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    60. 60. 7番: Avoid Java Serialization Good serializers include (but are not limited to): Kryo, Google Protocol Buffers, SBE,Thrift, JSON even (sic!) // dependencies "com.github.romix.akka" %% "akka-kryo-serialization" % "0.4.0" // application.conf extensions = [“com.romix.akka.serialization.kryo.KryoSerializationExtension$"] 
 serializers { 
 java = "akka.serialization.JavaSerializer" kryo = "com.romix.akka.serialization.kryo.KryoSerializer" 
 } akka.actor.serialization-bindings { “com.mycompany.Example”: kryo . . . } [info] ForkJoinActorBenchmark.pingPong java avgt 10 25.464 ± 1.175 us/op [info] ForkJoinActorBenchmark.pingPong kryo avgt 10 4.348 ± 4.346 us/op [info] ForkJoinActorBenchmark.pingPong off avgt 10 0.967 ± 0.657 us/op Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    61. 61. 7番: Avoid Java Serialization ----sr--model.Order----h#-----J--idL--customert--Lmodel/Customer;L--descriptiont--Ljava/lang/String;L-- orderLinest--Ljava/util/List;L--totalCostt--Ljava/math/BigDecimal;xp--------ppsr--java.util.ArrayListx----- a----I--sizexp----w-----sr--model.OrderLine--&-1-S----I--lineNumberL--costq-~--L--descriptionq-~--L--ordert-- Lmodel/Order;xp----sr--java.math.BigDecimalT--W--(O---I--scaleL--intValt--Ljava/math/BigInteger;xr-- java.lang.Number-----------xp----sr--java.math.BigInteger-----;-----I--bitCountI--bitLengthI-- firstNonzeroByteNumI--lowestSetBitI--signum[--magnitudet--[Bxq-~----------------------ur--[B------T----xp---- xxpq-~--xq-~-- Java Serialization final case class Order(id: Long, description: String, totalCost: BigDecimal, orderLines: ArrayList[OrderLines], customer: Customer) <order id="0" totalCost="0"><orderLines lineNumber="1" cost="0"><order>0</order></orderLines></order>XML…! {"order":{"id":0,"totalCost":0,"orderLines":[{"lineNumber":1,"cost":0,"order":0}]}}JSON…! ------java-util-ArrayLis-----model-OrderLin----java-math-BigDecima---------model-Orde-----Kryo…! Excellent post by James Sutherland @ http://java-persistence-performance.blogspot.com/2013/08/optimizing-java-serialization-java-vs.html Java Serialization は遅い 性能を出したければ、ProtoBuf か Kryo
    62. 62. 7番: Avoid Java Serialization for Persistence!!! Java Serialization is a horrible idea if you’re going to store the messages for a long time. For example, with Akka Persistence we store events “forever”. Use a serialization format that can evolve over time in a compatible way. It can be JSON or ProtocolBuffers (or Thrift etc). Java Serialization を永続化に使わない スキーマの変更しやすいフォーマットを選ぶべき
    63. 63. 7.5番: Trust no-one, benchmark everything! Always measure and benchmark properly before judging performance of a tool / library. Benchmarking is often very hard, use the right tools: - JMH (for Scala via: ktoso/sbt-jmh) -YourKit / JProfiler / … - Linux perf_events 7.5番 推測するな、計測せよ ベンチマークを書いてプロファイラでスレッドの挙動を診断
    64. 64. 8番: Let it Crash! Supervision, Failures & Errors
    65. 65. http://www.reactivemanifesto.org/ 8番: Let it Crash! Supervision, Failures & Errors Error … which is an expected and coded-for condition—for example an error discovered during input validation, that will be communicated to the client … Failure … is an unexpected event within a service that prevents it from continuing to function normally. 
 A failure will generally prevent responses to the current, and possibly all following, client requests.
    66. 66. http://www.reactivemanifesto.org/ 8番: Let it Crash! Supervision, Failures & 「エラー」はビジネスロジックの問題 「障害」はインフラの問題 「エラー」はビジネスロジックの問題 「障害」はインフラの問題
    67. 67. http://www.reactivemanifesto.org/ 8番: Let it Crash! Supervision, Failures & Errors 「エラー」はビジネスロジックの問題 「障害」はインフラの問題
    68. 68. http://www.reactivemanifesto.org/ 8番: Let it Crash! Supervision, Failures & Errors Error: “Not enough cash.” 「エラー」はビジネスロジックの問題 「障害」はインフラの問題
    69. 69. http://www.reactivemanifesto.org/ 8番: Let it Crash! Supervision, Failures & Errors Error: “Unable to fulfil request” Failure: “Row 3 is broken” 「エラー」はビジネスロジックの問題 「障害」はインフラの問題
    70. 70. 9番: Backoff Supervision
    71. 71. 9番: Backoff Supervision
    72. 72. 9番: Backoff Supervision
    73. 73. 9番: Backoff Supervision
    74. 74. 9番: Backoff Supervision Our goal is to “let things crash” and “recover gracefully” Not to hammer the DB while it tries to recover! クラッシュさせた上で、しなやかな回復を目指す
    75. 75. 9番: Backoff Supervision クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    76. 76. 9番: Backoff Supervision クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    77. 77. 9番: Backoff Supervision IF we allowed immediate restarts… we could end up in “infinite replay+fail hell”. (we don’t. since Persistence went stable in 2.4.x) クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    78. 78. 9番: Backoff Supervision クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    79. 79. 9番: Backoff Supervision Many PersistentActors Fail and Stop. クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    80. 80. 9番: Backoff Supervision クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    81. 81. 9番: Backoff Supervision Backoff Supervisor counts failures and starts “the same” entity after exponential timeouts. クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    82. 82. 9番: Backoff Supervision クラスタでは BackoffSupervisor 全アクターが同時に再起動し DB に殺到するのを防ぐ
    83. 83. 10番: Design using State Machines
    84. 84. 10番: Design using State Machines def receive = { case Thingy() => // ... case AnotherThingy() => // ... case DoOtherThings() => // ... case PleaseGoAway() => // ... case CarryOn() => // ... case MakeSomething() => // ... // ... } 有限状態機械を作る FSM トレイトか become メソッドを使う
    85. 85. 10番: Design using State Machines def receive = { case Thingy() => // ... case AnotherThingy() => // ... case DoOtherThings() => // ... case PleaseGoAway() => // ... case CarryOn() => // ... case MakeSomething() => // ... // ... } Good: Actors avoid the “pyramid of doom”. Pyramid of doom in some async programming styles. 有限状態機械を作る FSM トレイトか become メソッドを使う
    86. 86. 10番: Design using State Machines def receive = { case Thingy() => // ... case AnotherThingy() => // ... case DoOtherThings() => // ... case PleaseGoAway() => // ... case CarryOn() => // ... case MakeSomething() => // ... // ... } That well works because “everything is a message”: 有限状態機械を作る FSM トレイトか become メソッドを使う
    87. 87. 10番: Design using State Machines def receive = awaitingInstructions def awaitingInstructions: Receive = terminationHandling orElse { case CarryOn() => // ... case MakeSomething(metadata) => // ... context become makeThings(meta) } def makeThings(metadata: Metadata): Receive = terminationHandling orElse { case Thingy() => // make a thingy ... case AnotherThingy() => // make another thingy ... case DoOtherThings(meta) => // ... context become awaitingInstructions } def terminationHandling: Receive = { case PleaseGoAway() => // ... context stop self } 有限状態機械を作る FSM トレイトか become メソッドを使う DoOtherThings MakeSomething
    88. 88. 10番: Design using State Machines We also provide an FSM (Finite State Machine) helper trait. You may enjoy it sometimes, give it a look. DoOtherThings MakeSomething http://doc.akka.io/docs/akka/2.4.1/scala/fsm.html class Buncher extends FSM[State, Data] { startWith(Idle, Uninitialized) when(Idle) { case Event(SetTarget(ref), Uninitialized) => stay using Todo(ref, Vector.empty) } // transition elided ... when(Active, stateTimeout = 1 second) { case Event(Flush | StateTimeout, t: Todo) => goto(Idle) using t.copy(queue = Vector.empty) } // unhandled elided ... initialize() } 有限状態機械を作る FSM トレイトか become メソッドを使う
    89. 89. 11番: Cluster Convergence and Joining
    90. 90. 11番: Cluster Convergence and Joining http://doc.akka.io/docs/akka/2.4.1/common/cluster.html Cluster Gossip Convergence When a node can prove that the cluster state it is observing has been observed by all other nodes in the cluster.
    91. 91. 11番: Cluster Convergence and Joining http://doc.akka.io/docs/akka/2.4.1/common/cluster.html Cluster Gossip Convergence When a node can prove that the cluster state it is observing has been observed by all other nodes in the cluster. Convergence is required for “Leader actions”, which include Join-ing and Remove-ing a node. Down-ing can happen without convergence.
    92. 92. 11番: Cluster Convergence and Joining http://doc.akka.io/docs/akka/2.4.1/common/cluster.html
    93. 93. 11番: Cluster Convergence and Joining http://doc.akka.io/docs/akka/2.4.1/common/cluster.html akka.cluster.allow-weakly-up-members=on
    94. 94. 11番: Cluster Convergence and Joining
    95. 95. 11番: Cluster Convergence and Joining
    96. 96. 11番: Cluster Convergence and Joining
    97. 97. 11番: Cluster Convergence and Joining
    98. 98. 11番: Cluster Convergence and Joining
    99. 99. 11番: Cluster Convergence and Joining Everyone has ‘seen’ Kurt joining, move him to Up.
    100. 100. 11番: Cluster Convergence and Joining Kurt is now with us in the Cluster.
    101. 101. 11番: Cluster Convergence and Joining I can’t hear Kurt… He’s unreachable…
    102. 102. 11番: Cluster Convergence and Joining Kurt does has not seen Rei… I can not mark him as Up! allow-weakly-up-members=off // default
    103. 103. 11番: Cluster Convergence and Joining I’ll mark Rei as “WeaklyUp” until Kurt is back. allow-weakly-up-members=on allow-weakly-up-members
    104. 104. 11番: Cluster Convergence and Joining Kurt is back! Once he has seen Rei I’ll mark Rei as Up. allow-weakly-up-members=on allow-weakly-up-members
    105. 105. 12番: Cluster Partitions and “Down”
    106. 106. 12番: Cluster Partitions and “Down”
    107. 107. 12番: Cluster Partitions and “Down” I’m going home…
    108. 108. 12番: Cluster Partitions and “Down” Make sure the others have heard you say goodbye before you leave. Vanishes immediately.
    109. 109. 12番: Cluster Partitions and “Down” Make sure the others have heard you say goodbye before you leave. “Where’s Bill? I did not hear him say Goodbye!” “Failure Detector” used to determine UNREACHABLE.
    110. 110. 12番: Cluster Partitions and “Down” Failure detection only triggers “UNREACHABLE”. Nodes can come back from that state.
    111. 111. 12番: Cluster Partitions and “Down” Declaring DOWN is done by either timeouts (which is rather unsafe) [auto-downing]. Or by “voting” or “majority” among the members of the cluster [split-brain-resolver].
    112. 112. 12番: Cluster Partitions and “Down”
    113. 113. 12番: Cluster Partitions and “Down” お 前 は も う 死 ん で い る . . . . Node declared “DOWN” comes back…
    114. 114. 12番: Cluster Partitions and “Down” お 前 は も う 死 ん で い る . . . .
    115. 115. 12番: Cluster Partitions and “Down” お 前 は も う 死 ん で い る . . . . Why do we do that? In order to guarantee consistency via “single writer principle”. Note: Akka Distributed Data has no need for “single writer”, it’s CRDT based. But it’s harder to model things as CRDT, so it’s a trade off.
    116. 116. 12番: Cluster Partitions and “Down” Notice that we do not mention “Quarantined”. That is a state in Akka Remoting, not Cluster. It’s a terminal state from which one can never recover. TL;DR; use Akka Cluster instead of Remoting. it’s pretty much always the thing you need (better than remoting).
    117. 117. 13番: A fishing rod is a Tool. Akka is a Toolkit.
    118. 118. 13番: A fishing rod is a Tool. Akka is a Toolkit. Akka strives is Toolkit, not a Framework. “Give a man a fish and you feed him for a day teach a man to fish and you feed him for a lifetime.”
    119. 119. 13番: Akka is a Toolkit, pick the right tools for the job. “Constraints Liberate, Liberties Constrain” Runar Bjarnason Runar’s excellent talk @ Scala.World 2015
    120. 120. 13番: Akka is a Toolkit, pick the right tools for the job. Runar’s excellent talk @ Scala.World 2015 The less powerful abstraction must be built on top of more powerful abstractions.
    121. 121. 13番: Akka is a Toolkit, pick the right tools for the job. Runar’s excellent talk @ Scala.World 2015 Asynchronous processing toolbox: Akka は道具箱。正しい道具を選ぶべし。 レゴを組み合わせるようにしてアプリを作れる
    122. 122. 13番: Akka is a Toolkit, pick the right tools for the job. Runar’s excellent talk @ Scala.World 2015 Asynchronous processing toolbox: Akka は道具箱。正しい道具を選ぶべし。 レゴを組み合わせるようにしてアプリを作れる
    123. 123. 13番: Akka is a Toolkit, pick the right tools for the job. Asynchronous processing toolbox: Akka は道具箱。正しい道具を選ぶべし。 レゴを組み合わせるようにしてアプリを作れる
    124. 124. 13番: Akka is a Toolkit, pick the right tools for the job. Single value, no streaming by definition. Local abstraction.
 Execution contexts. Akka は道具箱。正しい道具を選ぶべし。 レゴを組み合わせるようにしてアプリを作れる
    125. 125. 13番: Akka is a Toolkit, pick the right tools for the job. Mostly static processing layouts. Well typed and Back-pressured! Akka は道具箱。正しい道具を選ぶべし。 レゴを組み合わせるようにしてアプリを作れる
    126. 126. 13番: Akka is a Toolkit, pick the right tools for the job. Plain Actor’s younger brother, experimental. Location transparent, well typed. Technically unconstrained in actions performed Akka は道具箱。正しい道具を選ぶべし。 レゴを組み合わせるようにしてアプリを作れる
    127. 127. 13番: Akka is a Toolkit, pick the right tools for the job. Runar’s excellent talk @ Scala.World 2015 Location transparent. Various resilience mechanisms. (watching, persistent recovering, migration, pools) Untyped and unconstrained in actions performed. Akka は道具箱。正しい道具を選ぶべし。 レゴを組み合わせるようにしてアプリを作れる
    128. 128. 13番: Akka is a Toolkit, pick the right tools for the job. Akka it a Toolkit. Not a Framework. Another example is persisting data. Akka Persistence is specifically geared towards Event Sourcing. If you know you you want a raw Key-Value Store and do not need Event Sourcing’s capabilities, don’t use Akka Persistence – it would be the wrong tool for the job. If you use it for Event Sourcing though… it’ll work very well for you. There it is the right tool for the job. 用途に合わない道具は使うべきではない 例えば CQRS が適切でない時は生 DB アクセスを使えば済む
    129. 129. 14番: Happy hAkking, Community! 人にはやさしく コミュニティーに積極的に参加する
    130. 130. 14番: Happy hAkking, Community! akka.io – website github.com/akka/akka/issues – help out! “community-contrib” or “small” for starters groups.google.com/group/akka-user – mailing list gitter.im/akka/akka – chat about using Akka gitter.im/akka/dev – chat about developing Akka
    131. 131. Links • http://stackoverflow.com/questions/34641861/akka-http-blocking- in-a-future-blocks-the-server/34645097#34645097 • The wonderful Zen paintings to buy here:
 http://paintingwholesalechina.com/products/chinese-culture-zen- no-1-academic-chinese-painting • http://doc.akka.io/docs/akka/2.4.1/common/cluster.html • http://www.mit.edu/~xela/tao.html • http://doc.akka.io/docs/akka/2.4.1/common/cluster.html • http://doc.akka.io/docs/akka/2.4.1/scala/cluster-usage.html • akka.io et al.
    132. 132. https://www.typesafe.com/products/typesafe-reactive-platform Certified builds & Long Term Support Advanced commercial features: Monitoring, Split Brain Resolver, ConductR, Play User Quotas, Play SOAP Reactive Platform
    133. 133. ありがとう! ktoso @ typesafe.com twitter: ktosopl github: ktoso team blog: letitcrash.com home: akka.io Thus spake the Master Programmer: “After three days without programming, life becomes meaningless.”
    134. 134. Q/A (Now’s the time to ask things!) ktoso @ typesafe.com twitter: ktosopl github: ktoso team blog: letitcrash.com home: akka.io
    135. 135. ©Typesafe 2016 – All Rights Reserved

    ×