Dispatcher는 ActorSystem 내에서 실행되는 모든 코드를 스케줄링 합니다. 각 Actor의 처리량과 시간 점유율을 조정하여 각자에게 공정한 리소스를 제공합니다. 구성 변경을 하지 않는한 일반적으로 시나리오에 맞게 최적화 된 .Net ThreadPOOL을 사용합니다. |
Dispatcher 설정기능을 제공함으로 , 액터그룹별로 다른 성능목표를 가지고 , 성능전략을 세울수가 있습니다.
AKKA를 사용하기 위해서는 스레드를 직접 생성하고 복잡한 스레드모델을 작성할 필요가 없다라고 앞에서
설명을 하였지만 동시성 메시지 처리를 잘하기 위해서 Dispatcher가 어떠한 옵션을 제공하는가?를
이해하기위해서는 멀티스레드를 구현의 관점이 아닌 이해의 관점에서 알아둘 필요가 있습니다.
C#이 지원하는 비동기 동시처리 프로그래밍에서 ASYNC ,AWAIT,TASK등의 지원으로 ( .net 45+)
닷넷프레임워크 내에서도 직접 스레드 생성하는것을 지양합니다.
동시성 처리 변천사 : 멀티스레드프로그래밍 → 비동기프로그램밍 → 동시성 프로그래밍
관련 개발 트렌드는, 언어에 상관없이 발전을하였며 추상화되어서 사용법의 차이이며
라이브러리 자체가 기존 메카니즘을 포함하고 있거나, 연동되어 같이 사용가능합니다.
Dispatchercustom-dispatcher {
type = Dispatcher
throughput = 100
} |
.NET ThreadPool 을 통해 작동이되며 대부분의 경우 이것만으로 충분합니다.
몇개의 스레드를 둘것인가? 보다 몇개의 메시지를 동시에 처리하게 할것인가? 에대한 설정입니다.
custom-task-dispatcher {
type = TaskDispatcher
throughput = 100
} |
TPL 인프라를 사용합니다. 어떠한 Task가 병렬적으로 처리가 되어 멀티코어에 최적화되어
작동되게 합니다. 일반적으로 사용될 일이 없으나
TPL인프라를 꼭 사용하여 극단적 튜닝이 필요할시 활용할수가 있습니다.
PinnedDispatchercustom-dedicated-dispatcher {
type = PinnedDispatcher
} |
AKKA가 준비한 ,단일 전용 스레드만 사용합니다. 어떠한 목적을 두고 준비된 Dispatcher는 아니며
서비스 메시지 처리와, 시스템 성능 메시지처리를 분리한다고 했을시
성능확인을 위해 그리많은 메시지처리가 되지 않고, 서비스 메시지처리와 분리하여 작동시키고자 할때 활용될수 있습니다.
my-dispatcher {
type = ForkJoinDispatcher
throughput = 100
throughput-deadline-time = 0ms
dedicated-thread-pool {
thread-count = 3
deadlock-timeout = 3s
threadtype = background
}
} |
대부분 Dispatcher는 목적에맞게 최적화된 각자의 스레드풀 메카니즘이 있고 신경쓸필요없으나
ForJoinDispatcher의 경우 전용 스레드풀을 생성하여, 스레드수를 직접 할수있는 유일한 Dispatcher입니다.
이 스케줄러를 이용할시, 세밀한 튜닝 전략으로 일부 액터를 분리할수가 있습니다.
또한 기존 플래폼이 가진, 비동기 프로그래밍과 휼륭하게 연동될수 있습니다.
지난 몇년간 멀티스레딩 프로그래밍을 통해 개발을 했고 문제를 풀려고 하였습니다. 하지만,5년간 운영하면서 어떠한 한계에 부딪쳤습니다. 스레드문제처리에대해 개발내에 숙련이 유지되지 않는다는점이며 단일기기에서 충분한 사용자처리 성능을 이끌수있으나, 그속에서도 대부분의 운영 로그가 스레드에관한것이고 이것을 해결하는데 골칫거리였습니다. 실제 서비스에관련된 로그가 20%라고 하면 TCP처리및 스레드에관련된 로그가 80%이상이였습니다. 로그의 복잡성은, 개발코드의 복잡성을 반영하며 문제파악및 확장이 어려워집니다. 더욱이 현재 느끼는 심각한문제는, 그렇게 쌓인 팀라이브러리가 AKKA에서 고민하는 추상화된 스레드모델에(디스페쳐) 한참 못미치고 거의 쓰일데가 없다란 것입니다. 오히려 어떠한 동시성을 위한 추상적 레벨의 라이브러리를통해, 제공하는 옵션을 어떻게 이해하고 사용해야하는가? 멀티스레드및 비동기프로그래밍을 어떻게 이해해야하고, 다시 학습하게 되는 계기가 되었습니다. 말이 길었지만 , AKKA에서는 아래와 같은 스레드 옵션을 지원합니다.
|
SynchronizedDispatchersynchronized-dispatcher {
type = "SynchronizedDispatcher"
throughput = 10
}
private void Form1_Load(object sender, System.EventArgs e)
{
system.ActorOf(Props.Create<UIWorker>().WithDispatcher("synchronized-dispatcher"), "ui-worker");
}
|
SynchronizedDispatcher는 SynchronizationContext 를 사용하며 Actor가 UI 업데이트를 한다고하면UI를 업데이트할수있는 전용 Dispatcher 입니다. Actor는 UI Thread내에서 작동되는 녀석이 아니며
Actor와 별개로 대부분 타 스레드가 UI 객체를 변경하고자 할때 문제가 생깁니다. ( WPF,WINFORM 모두 동일)
이러한 문제에 대한 단순한 처리는 UI 스레드내에서 어떠한 작업을 진행하는것인데, 그러면 UI가 멈춰서 좋은 UX를 제공하기 불가합니다.
관리툴 목적으로, 네이티브한 UI 를 만드는 경우 활용할수 있습니다.
public class ReActor : ReceiveActor
{
private ILoggingAdapter log = Context.GetLogger();
public ReActor()
{
Receive<string>(message => {
if(message == "slow") //slow메시지를 받으면, 지연시킵니다.(테스트 지연코드)
{
Task.Delay(500).Wait(); //처리결과를 기다리는 블락킹 코드사용은 권장되지 않음
}
string reply = string.Format("I'am {0} RE:{1}", Self.Path, message);
log.Info(reply);
Sender.Tell(reply);
});
}
} |
var actor1 = actorSystem.ActorOf(Props.Create<ReActor>().WithDispatcher("my-dispatcher"), "my-actor1");
var actor2 = actorSystem.ActorOf(Props.Create<ReActor>().WithDispatcher("my-dispatcher"), "my-actor2");
var actor3 = actorSystem.ActorOf(Props.Create<ReActor>().WithDispatcher("my-dispatcher"), "my-actor3");
for (int i=0; i < 100; i++)
{
actor1.Tell("slow");
actor2.Tell("slow");
actor3.Tell("slow");
}
Console.WriteLine("completed - send all"); |
Akka의 로그는 기본적으로 고유 스레드 아이디를 표시해줍니다.
아래내용을 펼쳐 옵션에따라 어떻게 결과가 다른지 확인이 가능합니다.
스레드수를 늘려 동시성을 처리하는것은 좋은 아이디어가 아닙니다. Dispatcher의 Thread수 조절에 따라
어떻게 작동되는지 확인하기위한 샘플이며, Actor내의 어떠한 Task도 비동기처리가 권장됩니다.
스레드 1개만 사용이 됩니다. |
스레드 3개가 번갈아가며 일을합니다. 우리는 스레드 코드를 생성한적이 없으나, 우리의 의도를 전달할수가 있습니다. |
대부분 사용할일이 없지만, 어떠한 액터가 메시지를 받으면 블락킹이되고 오래걸리는경우 (일반적으로 외부 RestAPI)
이와같은 전력을 통해 스레드수분리가 가능합니다. ( 기본 메시지처리기에 부하를 분리)
RestAPI를 대신하여 호출해주는 Actor가 필요하다고 가정해봅시다.
설계시 다음과 같은 요구사항을 가집니다.
C#의 비동기 프로그래밍의 힘을 빌려 Task에 완료된 비동기처리를 Pipe로 연결하여
이러한 문제를 풀어보겠습니다. 또한 성능 옵션설정은 위에서 설명한 디스패쳐를 통해 튜닝전략을 옵션을통해
이룩해냅니다.
이러한 모델은, 어떠한 작업이 언제끝날지 모르는 외부장치 의존이있을시(DB,RESTAPI)
연동시 활용될수 있습니다.
public class DelayReply
{
public string message;
}
public class ReActor : ReceiveActor
{
private ILoggingAdapter log = Context.GetLogger();
public ReActor()
{
string myPath = Self.Path.ToString();
Receive<string>(message => {
Handle(message);
});
Receive<DelayReply>(message => {
Handle(message);
});
}
public void Handle(string str) //In:샘플은 String이지만, 어떠한 Request를 의미하는게 좋습니다
{
Task.Run(async () =>
{
await Task.Delay(1000); //어떠한 값을 기다림
DelayReply reply = new DelayReply();
reply.message = str;
return reply;
}).PipeTo(Self); //처리완료 결과가 파이프를 통해 DelayReply 처리기로 넘깁니다.
}
public void Handle(DelayReply data) //Out:어떠한 Result/Response임을 명시하는게 좋습니다.
{
string logtrace = string.Format("I'am {0} RE:{1}", Self.Path, data.message);
log.Info(data.message);
Sender.Tell(data);
}
} |
var tasks = new List<Task>();
tasks.Add(actorA.Ask("request", TimeSpan.FromSeconds(1)));
tasks.Add(actorB.Ask("another request", TimeSpan.FromSeconds(5)));
Task.WhenAll(tasks).PipeTo(actorC, Self); |

Dispatcher는 성능과 관련한 액터로, 멀티스레드개념을 어느정도 단순화하고 옵션화를 했다고 보시면될듯합니다.
이와 관련하여 위 그래프는 아주 중요한 의미를 내포하고 있습니다.
고성능처리를 위해서 개발 복잡도가 증가하고 (심각하게는 고성능처리에 대해 아무것도 할수 없음)
요구사항 증가로인해, 필요한 자원이 계속 증가한다면 그것은 파멸적 시나리오로 연결될것입니다.
분산 개발 환경에서 해결 키 포인트가 멀티스레드 작성이라고 생각하고, 시도 했다면 다행입니다.
문제는 그것이 분산환경에서 복잡한 연산처리에서도 이것이 해결을위한 키포인트로 정의 내리는 굳은 믿음에 있으며
대부분 인메모리(네트워크가없는) 상황에서도 스레드를 직접 작성하여 처리능력을 올리는것은 큰 도움이 되지 않습니다.
이것은 개발복잡도 증가요인으로 해당이 되는 사항입니다.
이미 동시성 처리를 위해 멀티스레드를 직접 작성하지않는 여러가지 모델들이 등장했으며
액터모델은 그중에 하나일뿐입니다.
(어떠한 특수목적으로,병렬처리를 위해 스레드를 극단적으로 이해하고 사용해야되는 케이스도 분명 있습니다.)