Question on Akka router

[Grace]

Greetings!

 

I am new to Akka and am trying to understand routing.

In the below example, I have one front end and three backends running.  Suppose I run two front ends, my understand is that each front end would have an instance of a router, is that correct?  In such case, wouldn't the balancing logic be not quite correct because each router is not coordinated with another?  Is it common practice to create a centralized router (one single router) that all clients (frontEnds) go to? What are the pros and cons of the single router design and do you know of an example of article of such?

Or is this below design already sufficient for proper balanced routing?  

Thanks,

Grace

package com.packt.akka.loadBalancing
import com.packt.akka.commons.Add

object LoadBalancingApp extends App {


  //initiate three nodes from backend
  Backend.initiate(2551)


  Backend.initiate(2552)


  Backend.initiate(2561)


  //initiate frontend node
  Frontend.initiate()


  Thread.sleep(10000)


  Frontend.getFrontend ! Add(2, 4)


}

Loadbalancer.conf


akka {
  actor {
    provider = "akka.cluster.ClusterActorRefProvider"
  }
  remote {
    log-remote-lifecycle-events = off
    netty.tcp {
      hostname = "127.0.0.1"
      port = 0
    }
  }


  cluster {
    seed-nodes = [
      "akka.tcp://Cluste...@127.0.0.1:2551",
      "akka.tcp://Cluste...@127.0.0.1:2552"]


    auto-down-unreachable-after = 10s
  }
}


akka.cluster.min-nr-of-members = 3




akka.cluster.role {
  frontend.min-nr-of-members = 1
  backend.min-nr-of-members = 2
}


akka.actor.deployment {
  /frontend/backendRouter {
    # Router type provided by metrics extension.
    router = adaptive-group
    # Router parameter specific for metrics extension.
    # metrics-selector = heap
    # metrics-selector = load
    # metrics-selector = cpu
    metrics-selector = mix
    #
    nr-of-instances = 100
    routees.paths = ["/user/backend"]
    cluster {
      enabled = on
      use-role = backend
      allow-local-routees = off
    }
  }
}

Backend.scala


 


class Backend extends Actor {


  def receive = {
    case Add(num1, num2) =>
      println(s"I'm a backend with path: ${self} and I received add operation.")


  }


}


object Backend {
  def initiate(port: Int){
     val config = ConfigFactory.parseString(s"akka.remote.netty.tcp.port=$port").
      withFallback(ConfigFactory.parseString("akka.cluster.roles = [backend]")).
      withFallback(ConfigFactory.load("loadbalancer"))


    val system = ActorSystem("ClusterSystem", config)


    val Backend = system.actorOf(Props[Backend], name = "backend")
  }
}

Fronend.scala


class Frontend extends Actor {
  import context.dispatcher


  val backend = context.actorOf(FromConfig.props(), name = "backendRouter")


  context.system.scheduler.schedule(3.seconds, 3.seconds, self,
    Add(Random.nextInt(100), Random.nextInt(100)))


  def receive = {
    case addOp: Add =>
      println("Frontend: I'll forward add operation to backend node to handle it.")
      backend forward addOp


  }

}



object Frontend {


  private var _frontend: ActorRef = _


  val upToN = 200


  def initiate() = {
    val config = ConfigFactory.parseString("akka.cluster.roles = [frontend]").
      withFallback(ConfigFactory.load("loadbalancer"))


    val system = ActorSystem("ClusterSystem", config)
    system.log.info("Frontend will start when 2 backend members in the cluster.")
    //#registerOnUp
    Cluster(system) registerOnMemberUp {
      _frontend = system.actorOf(Props[Frontend],
        name = "frontend")
    }
    //#registerOnUp


  }


  def getFrontend = _frontend
}
 

 

[Patrik Nordwall]

The drawback of first sending everything to one single node would be “single point of bottleneck” and an extra network hop for many messages.

Even though all frontend nodes might not have exactly the same load information at the same time that should be fine anyway.

Load based routing is always difficult since it is acting on “historical” information and it’s easy to get oscillations. This also means that the distributed nature of the information is of less importance. It’s only an approximation that is changing anyway.

/Patrik

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Grace]

Thanks Patrik.

In my use case, I have a few hundreds of client nodes. I have about 300 worker nodes across 20 boxes. Due to a legacy limitation, one worker node can have only one actor and therefore, one worker node is only allowed to process one task at a time. Each task runs for a few seconds.

If we go with router inside each client, do you have a suggestion which routing machanism we use for fairer distribution? We are using pool instead of group and we are currently using round-robin-pool. Haven't tested under heavy load yet. Would round robin be a good choice?

Thanks,
Grace

[Akka Team]

We have a nice sample/guide showing distributed workers pulling work rather than pushing that may be interesting to you: https://developer.lightbend.com/guides/akka-distributed-workers-scala/

That does however potentially create a bottleneck so if you really want to avoid that you cannot copy the exact design of the sample, but maybe ideas in it may prove valuable.

--

Johan

Akka Team

--
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@googlegroups.com.