라우터는 액터의 목적지 대상 경로를 정의하는 특수한 속성입니다.
동일메시지가 여러개의 경로에 복제 전달될수도 있으며, 최적화된 어떠한 경로를 동적으로 선택할수 있습니다.
메시지 전송 전략에따라 다양한 라우터 선택이 가능합니다.
라우터 설정전략
라우터 설정은, 코드가 아닌 설정파일을 통해 하는게 일반적입니다. 라우터에 해당하는 고정된 노드는
운영중 변경될수 있기때문입니다. 하지만 어떠한 패턴에의해 동적으로 변경할수 있는 가능성도
있기때문에, 런타임 코드로의 변경도 지원을 합니다.
코드를 통해
예제는 라운드로빈 방식으로 5개의 작업자 Pool을 만든 예입니다.
props 는 액터편에 설명이되었지만, 어떠한 액터를 만들것인가? 어떻게작동하는 녀석인가?
대략적인 정보를 미리 설정하고,관리해서 필요할시 실제 작동하는 액터를 만들때 사용됩니다.
var props = Props.Create<Worker>().WithRouter(new RoundRobinPool(5)); //액터에대한 옵션을 미리 만들고 관리 var actor = system.ActorOf(props, "worker"); //필요할때 만든다.
var props = new RoundRobinPool(5).Props(Props.Create<Worker>());
설정파일을 통해
예제는 동일한 방식으로, 설정파일을 통해 ( http://getakka.net/articles/concepts/configuration.html )
라운드로빈 라우터를 설정한 모습입니다.
akka.actor.deployment { /workers { router = round-robin-pool nr-of-instances = 5 } }
설정파일에서, 라운드로빈을 이용해서 처리할 Job 개수를 설정합니다.
var props = Props.Create<Worker>().WithRouter(FromConfig.Instance); var actor = system.ActorOf(props, "workers");
실제 라우팅기능을 하는 Actor를 , 설정파일에서 설정한 룰대로 생성이되고 작동이됩니다.
아래는 개수를 통해 자동생성이아닌, 명시적인 라우터 이름을 설정합니다.
akka.actor.deployment { /workers { router = round-robin-group routees.paths = ["/user/workers/w1", "/user/workers/w2", "/user/workers/w3"] } }
var props = Props.Create<Worker>().WithRouter(FromConfig.Instance); var actor = system.ActorOf(props, "workers");
Pools VS Groups
- 풀(Pool) : 라우티를 관리하는 라우터 풀은 라우티를 만드는것부터 종료시 목록에서 제거하는것 까지 책임을 진다.
- 그룹(Group) : 라우티를 자동으로 관리하지 않으며, 직접 경로를 지정하여 그룹화 라우티가 인스턴스화 되는곳을 직접 제어가능
풀라우터는 라이티가 라우터의 자식이여야 하지만, 그룹 라우터는 다른 액터(RouteeCreator)의
자식일수도 있다. 그룹의 경우 라우티의 부모가 같지 않아도되며, 각 라우터가 생성되어 실행중기기만
하면 된다.
라우터의 종류
이름 | 작동다이어그램 | 특징 |
---|---|---|
| 단순하게 들어온 메시지 순서대로, 순차적으로 대상 노드를 바꿔가며 전송시 사용 | |
| 어떠한 정보의 변경을 모든 노드가 알아야할시, 주로 전체 동기화및 전체 푸시용도 | |
| 랜덤 메시지 전송 | |
| 특정 처리에 대해 해시값기반 베이스로 노드의 변경의 가능성을 최소화할때 | |
| 기본적으로 랜덤이나, 느린놈을 제외하고 특정시간이 지나야 다시 합류시킴(일반적으로 빠른 응답속도 보장용) 옵션:
| |
| 성능을 위해 다중노드로 구성하였으며, 가장 빠르게 처리한 녀석의 결과를 사용할시 | |
| 덜바쁜 노드우선으로 메시지를 보내고자 할때, 대용량 메시지 전송 보증이 필요할때 | |
| 성능을 위해 다중노드로 구성하였으며, 가장 빠르게 처리한 녀석의 결과를 사용할시 옵션:
|
키설정이 필요한, consistent-hashing 제외하고 나머지 라우터전략을 옵션을 통해(라우터 이름만 알고 있으면됨)
이루어냅니다.
라우터 테스트
이제 위 표를 참고하여, 액터를 만들어봅시다.
{routeName}-{RouteType} round-robin-pool 라운드로빈을 풀로 써겠다 이런의미가 되겠습니다.
actor.deployment { /workers { router = round-robin-pool nr-of-instances = 5 } }
라우터 Type을 선택하고, 인스턴수를 지정합니다. 위 라우터정의표에서 작동 이름만 바꾸면
전략변경가능합니다.
public class ReActor : ReceiveActor { private ILoggingAdapter log = Context.GetLogger(); public ReActor() { Receive<string>(message => { string reply = string.Format("I'am {0} RE:{1}", Self.Path, message); log.Info(reply); Sender.Tell(reply); }); } }
라우터 테스트가 잘되는지 확인하기 위해, 나의 이름을 말하고 "RE"로 받은 메시지 응답을 합니다.
var props = Props.Create<ReActor>().WithRouter(FromConfig.Instance); var actor = actorSystem.ActorOf(props, "workers"); actor.Tell("t1"); actor.Tell("t2"); actor.Tell("t3");
해당 라우터에 여러번 메시지를 보냅니다.
여러개의 액터가 교대로 처리하는것을 확인할수 있습니다.
Actor Hash Message
특정 메시지에대해 노드변경횟수를 최대한 피하고자 할때 consistent-hashing
을 사용하며, 이를 사용하기위해서는, 메시지에 고유키값이 있어야합니다.
위 샘플에서 라우터 전략만 바꾸고, 처리할 메시지를 다음과 같이 정의를 하면됩니다.
public class SomeMessage : IConsistentHashable { public Guid GroupID { get; private set; } //사용자가 그룹별 고유 아이디를 지정만 해줌 public object ConsistentHashKey { get { return GroupID; } } //+ 추가처리 메시지 속성 추가 }
Todo List:
- Dynamically Resizable Pools
- Specially Handled Messqge
- PoisonPill Messages
- Kill Message
- 사용자 정의 라우터 설계방법