RoutingTest

AKKA의 라우팅은 액터에서 발생하는 메시지를 다양한 장치를 이용하여 분배적략을 세울수 있습니다.

로컬에서는 동시성/병렬성 문제를 해결할수 있으며 클러스터내에서도 동일하게 작동하기 때문에

클라우드 분산컴퓨팅 환경에서도 동일한 컨셉으로 이벤트처리 분배 전략을 세울수 있는것이 장점입니다.

라우터와 관련된 용어 정리

라우팅 : 분배로직
라우터 : 분배지점 , 분배기
라우티 : 분배된 작업이 도달하는 작업자

테스트 시나리오

작업 노드는 5개를 지정 여러 라우팅을 테스
분배기에 50개의 작업 이벤트를 한꺼번에 발생시킴
작업노드중 특정 1노드는 항상 300ms 지연을 시킨다.
동일작성된 코드를 라우터만 변경하여 수행

AKKA에서는 다음과같은 라우팅을 제공하며 위와 같은 조건으로 전체 처리메시지 검사를 포함 전체 완료에 걸리는 시간을

유닛테스트화 해서 측정해보았습니다.

먼저 테스트에 이용된 AKKA제공 라우팅을 살펴보겠습니다.

RoundRobin

가장일반적인 순차 균등 분배로직입니다.

Random

순차를 고려하지 않는 랜덤 분배입니다.

SmallestMailbox

메시지가 덜 쌓인(가용성이 높은) 라우티에 우선적으로 메시지를 보냅니다.

BalancingRouting

MailBox와 유사하게 작동하지만, 바쁜 라우트에서 유휴 라우트로 작업을 재분배하려고 시도하는 라우터.

액터 코드

    @Override
    public Receive createReceive() {
        return receiveBuilder()
                .match(
                        WorkMessage.class,
                        message -> {
                            String pathName = self().path().name();
                            messageCount++;
                            log.info("[{}] ChildActor InMessage : {} - {}", pathName, message, messageCount);
                            // Routee가 a일때 임의 지연
                            if(pathName.equals("$a")){
                                log.info("SomeBlocking - 300ms");
                                Thread.sleep(300);
                            }
                            _probe.tell("completed", ActorRef.noSender());
                        })
                .build();
    }

라우티의 이름은 a/b/c/d/e 이며 a의 라우티에 임의 300ms 지연처리
round robbing 기준 각 라우티는 10개의 작업을 분배받습니다.

라우팅 정의

akka.actor.deployment {
  /router1 {
    router = round-robin-pool
    nr-of-instances = 5
  }

  /router2 {
    router = random-pool
    nr-of-instances = 5
  }

  /router3 {
    router = balancing-pool
    nr-of-instances = 5
    pool-dispatcher {
      attempt-teamwork = off
    }
  }

  /router4 {
    router = balancing-pool
    nr-of-instances = 5
    pool-dispatcher {
      executor = "thread-pool-executor"

      # allocate exactly 5 threads for this pool
      thread-pool-executor {
        core-pool-size-min = 5
        core-pool-size-max = 5
      }
    }
  }

  /router5 {
    router = smallest-mailbox-pool
    nr-of-instances = 5
  }}

라우팅을 코드로 정의할수 있지만 설정화로 완전하게 분리할수있습니다.

라우터 생성코드

                ActorRef router =
                        actorSystem.actorOf(FromConfig.getInstance().props(WorkerActor.Props(probe.getRef())), routerName);

라우팅 생성은 정의된

테스트 결과

해당 테스트 시나리오에서 아래와 같은 테스트 결과가 나왔으며~ BalancingRouting 이 전체 처리가 가장 빨랐습니다.

라우팅	총완료시간	Note
RoundRobin	3초 294ms	총완료시간은 제일늦은 라우티와 동일합니다. ( 10 * 300ms)
Random	2초 942ms	랜덤이기때문에 늦거나 빠를수도 있습니다. 늦은 라우티에 작업량이 운좋게 할당이 안된경우 라운드 로빈보다 빠르게 작동합니다.
SmallestMailBox	3초 272ms	RobundRobin과 유사하게 작동되었습니다. 이벤트가 한꺼번에 시도되었기때문에 지금과같은 테스트 시나리오에서 성능적 이점이 없습니다. 지속 운영중 쌓인 메시지큐에 차이가 발생했을때 이점을 볼수 있습니다.
BalancingRouting	490ms	느린 라우티를 자동검출하여 1개의 Task만 수행되었으며 결과적으로 가장 빠르게 작동되었습니다. 쌓인 개수가 아닌 라우티내 메시지처리 지연상황(메시지 밀림)을 고려 처리 지연발생된 라우티에게 메시지를 보내지 않으려고 균형을 맞추는것으로 보입니다.

작동가능 테스트 코드 : https://github.com/psmon/java-labs/tree/master/springweb/src/test/java/com/webnori/springweb/akka/router

Content

Space Tools