Page History
| Info |
|---|
Dispatcher는 ActorSystem 내에서 실행되는 모든 코드를 스케줄링 합니다. 각 Actor의 처리량과 시간 점유율을 조정하여 각자에게 공정한 리소스를 제공합니다. 구성 변경을 하지 않는한 일반적으로 시나리오에 맞게 최적화 된 .Net ThreadPOOL을 사용합니다.각 프레임워크가 가지고 있는 ThreadPOOL을 각각 활용합니다.
|
Dispatcher 설정기능을 제공함으로 , 액터그룹별로 다른 성능목표를 가지고 , 성능전략을 세울수가 있습니다.
...
이해하기위해서는 멀티스레드를 구현의 관점이 아닌 이해의 사용 관점에서 알아둘 학습할 필요가 있습니다.
C#이 지원하는 비동기 동시처리 프로그래밍에서 ASYNC ,AWAIT,TASK등의 지원으로 ( .net 45+)
...
라이브러리 자체가 기존 메카니즘을 포함하고 있거나, 연동되어 같이 사용가능합니다.
포함의 의미는, 동시성 프로그래밍을 다루면 멀티스레드가 포함된다란 의미 입니다.
반대로 멀티스레드 프로그래밍만 제공되는 어떠한 프레임워크에서는
문법적으로 비동기 프로그래밍지원이 안될수도 있습니다.
Dispatcher
...
| No Format |
|---|
custom-dispatcher {
type = Dispatcher
throughput = 100
} |
...
| No Format |
|---|
custom-task-dispatcher {
type = TaskDispatcher
throughput = 100
} |
TPL 인프라를 사용합니다. ThreadPool과 유사하지만 병렬처리 Thread를 사용해야하는
특수한 케이스일때 사용합니다. 대부분 신경쓸필요없이 프레임워크가 다중코어처리를 잘 수행하나
어떠한 Task가 병렬적으로 처리가 되어 멀티코어에 최적화되어
작동되게 합니다. 일반적으로 사용될 일이 없으나
TPL인프라를 꼭 사용하여 극단적 튜닝이 필요할시 활용할수가 있습니다.
- TPL에서 메시지 전송순서가 보장되는지 확인할것
병렬처리가 꼭 유용한 경우, 액터설정을 할수가 있습니다.
PinnedDispatcher
...
| No Format |
|---|
custom-dedicated-dispatcher {
type = PinnedDispatcher
} |
...
| Info |
|---|
지난 몇년간 멀티스레딩 프로그래밍을 통해 개발을 했고 문제를 풀려고 하였습니다. 하지만,5년간 운영하면서 어떠한 한계에 부딪쳤습니다. 스레드문제처리에대해 개발내에 숙련이 유지되지 않는다는점이며 단일기기에서 충분한 사용자처리 성능을 이끌수있으나, 그속에서도 대부분의 운영 로그가 스레드에관한것이고 이것을 해결하는데 골칫거리였습니다. 실제 서비스에관련된 로그가 20%라고 하면 TCP처리및 스레드에관련된 로그가 80%이상이였습니다. 로그의 복잡성은, 개발코드의 복잡성을 반영하며 문제파악및 확장이 어려워집니다. 더욱이 현재 느끼는 심각한문제는, 그렇게 쌓인 팀라이브러리가 AKKA에서 고민하는 추상화된 스레드모델에(디스페쳐) 한참 못미치고 거의 쓰일데가 없다란 것입니다. 오히려 어떠한 동시성을 위한 추상적 레벨의 라이브러리를통해, 제공하는 옵션을 어떻게 이해하고 사용해야하는가? 멀티스레드및 비동기프로그래밍을 어떻게 이해해야하고, 다시 학습하게 되는 계기가 되었습니다. 말이 길었지만 , AKKA에서는 아래와 같은 스레드 옵션을 지원합니다.
|
...
대부분 사용할일이 없지만, 어떠한 액터가 메시지를 받으면 블락킹이되고 오래걸리는경우 (일반적으로 외부 RestAPI)
이와같은 전력을 전략을 통해 스레드수분리가 가능합니다. ( 기본 메시지처리기에 부하를 분리)
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
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는 성능과 관련한 액터로, 멀티스레드개념을 어느정도 단순화하고 옵션화를 했다고 보시면될듯합니다.
이와 관련하여 위 그래프는 아주 중요한 의미를 내포하고 있습니다.
고성능처리를 위해서 개발 복잡도가 증가하고 (심각하게는 고성능처리에 대해 아무것도 할수 없음)
요구사항 증가로인해, 필요한 자원이 계속 증가한다면 그것은 파멸적 시나리오로 연결될것입니다.
분산 개발 환경에서 해결 키 포인트가 멀티스레드 작성이라고 생각하고, 시도 했다면 다행입니다.
심각한 문제는 그것이 분산환경및 복잡한 연산처리에서도 이것이 해결을위한 키포인트로 정의 내리는 굳은 믿음에 있으며
실제 이것은 개발복잡도 증가요인으로 해당이 되는 사항입니다.
이미 동시성 처리를 위해 멀티스레드를 직접 작성하지않는 여러가지 모델들이 등장했으며
액터모델은 그중에 하나일뿐입니다.
(어떠한 특수목적으로, 단일기기 메모리내에서 병렬처리를 다루는것이라면, 이상황과 무관합니다. 스레드를 극닥적으로
- 사용 자원증가에 따른 최대 한계측정
스레드의 비용
| 항목 | 비용 | 상세 |
|---|---|---|
| 커널메모리 | 약 1KB | 스레드 데이터와 속성들을 저장합니다. 이 데이터들은 페이징 될 수 없습니다. |
| 스택영역 | 512KB(일반 스레드), 8MB(OS X 메인 스레드), 1MB(iOS 메인 스레드) | 일반 스레드의 스택 영역은 최소 16KB이고, 4KB의 배수여야 합니다. 해당 메모리는 스레드가 생성될 때 할당되지만, 실제 사용되기 전까지 페이지가 생성되지는 않습니다. |
| 생성 시간 | 약 90ms | 스레드 생성 요청부터 스레드 루틴이 시작될 때 까지의 시간 |
스레드는 스택영역에 생성되기때문에 생성만 되어도 기본적으로 큰 메모리를 차지하게됩니다.
채널처리라는 도메인처리를 단일장비에서 1000개가 필요하다고 가정해봅시다.
- 1000 * 1mb = 약 1gb
채널하나당 스레드로 할당하게되면 아무런 일을 하지 않고도 1gb의 메모리를 차지하게 됩니다.
물론 스레드풀을 이용하여 스레드를 더 적게 사용할수 있도록 설계할수도 있습니다. 하지만 이것은 도메인 프로그래밍이 아니라 시스템 프로그래밍이 되게 됩니다.
도메인 로직속에 시스템 프로그래밍이 결정적으로 함께 있어야함을 의미하며 멀티스레딩 프로그래밍이란 다루기 어려운 시스템 프로그래밍을 깊이 있게 학습해야합니다.
반면 액터의 경우 스택영역이 아닌 힙영역에 생성되며 200만개의 액터가 사용하는 메모리는 고작 1GB에 불가합니다.
물론 이것이 200만개의 액터가 모두 동시에 진행할수 있다란것을 보장하는것은 아닙니다.
액터를 실행하는 스케줄러는 Dispacher에서 튜닝을 할수 있으며 스레드수를 조절할수 있습니다.
스레드 사용전략을 도메인 모델을 가지고 있는 액터모델과 완벽하게 분리할수 있음을 의미하며 실행레벨에 정의할수도 있지만
설정화로 완벽하게 분리하여 빌드없이 튜닝옵션으로 실행단계에 결정할수도 있습니다. 이해하고 사용해야되는 케이스도 분명 있습니다.)