Page History

간단한 용어설명

• Active Object : 항상 작동중이고 명령가능한 명령 가능한 능동적 객체란 점에서 액터 패턴과 유사,액터 패턴은 메시지를 통해서만 명령가능하며 별도의 메시지큐를 가지고 있는점에서 차이
• 명령가능 : 액터는 메시지를 통해서만 명령이전달된다는 점에서 차이가있습니다.
• 비동기 : 다른 녀석에게 일을 넘기고 내일을 한다. ( 논블럭킹 )
• 동기 : 다른 녀석이 일을 마칠때까지 기다린다. ( 블럭킹 )
• 능동적 : 나만의 큐와 스케쥴러를 가지고 있음

...

• 패턴 : 이하 참고

...

Actor2의 내부에서는 Lock자체가 필요가 없게됩니다.

더 중요한 사실은, 스레드 모델은 자신의 컴퓨팅에서 벗어나질 못한다는것입니다.

 위 그림을 보면, 이러한 의문을 가질수 있습니다.  액터하나당? Thread를 하나사용하는것인가?

그러면  액터수 생성에 제한이 있지 않는가? 실제 아무일을 하지 않는 액터는 스레드를 점유하지 않으며

동시 처리가능수에대한 제한도 가능합니다. ( dispatcher가 액터들을 스레드풀에의해 효율적으로 관리함)

만약 어떠한 액터가 처리 시간이 많이걸리는 액터라고 가정하면..,

빠르게 작동되는 액터와 스레드사용 전략을 분리할 필요가 있습니다.

AKKA에서는  이러한 문제를 복잡한 스레드 모델이 아닌 튜닝가능한 옵션으로 해결하려고 시도합니다.

Image Removed

멀티스레드 측정을 위해 Tace하거나 중단을 통해 작동의 연관성을 찾는것은 어렵기때문에, 스레드 프로파일러 시각화 툴의 도움을 받습니다.

만약 스레드제어를 직접 제어하는 구현체를 개발했을시  서비스코드의 복잡도증가및 숙련도에따라 서비스의 불안정으로 이어질수 있습니다.

동시성 프로그래밍을 위해 꼭 Akka가 있는것은 아니며, 동시성을 처리해주는 여러가지 라이브러리및 툴킷들은 훨씬더 이러한 문제에대해 공통적인 집단 지식으로

스레드의 복잡성문제를 단순화하려는 노력을 해왔습니다.

AKKA에서는 단지 튜닝을 위한 목적으로 스레드사용에대한 전략을 설정화로 이루어냅니다.

목적과 성능에따라 액터를 관리할 dispatcher를 분리하게되면 Actor의 성능에 대한 문제 파악이 용이해집니다.

my-blocking-dispatcher {
  type = Dispatcher
  executor = "thread-pool-executor"
  thread-pool-executor {
    fixed-pool-size = 16
  }
  throughput = 1
}
// 이것은 런타임 코드가 아니라, 튜닝요소입니다. AKKA에서는 Thread를 직접 생성하는 코드를 작성하지 않습니다.
// 장비 1개 성능 최적화와 관련된 튜닝사항으로 스케일업과 관련이있습니다.
// 만약 스레드풀을 직접 설계를 하였다고 해도, 튜닝설정이 없다고 하면 성능조정에 어려움이 생깁니다.
// 다양한 튜닝 옵션이 설정화로 빠질수 있는것은 스레드를 잘 이해하고 유연함을 의미합니다.

관련 액터들만, 스레드를 특정개수로 제한할수가 있으며  처리시간이 짧은 액터일경우 훨씬더 작은 수의 스레드로도 충분히 빠르게 작동을 합니다.

실제로 내부 장비에서 액터간 초당 50만 메시지가 처리가능하다라고 함 :  http://letitcrash.com/post/20397701710/50-million-messages-per-second-on-a-single

직접구현 방식을 사용하여 패킷을설계하고, 저수준 TCP전송 프로토콜을 사용하여 멀티스레드 기법으로 고성능 전송을 구현한다고 했을시

1:1 안정적인 고성능 전송기능이될때까지 엄청난 노력을 기울여야할것입니다. (그것이 c++이던 java이던간에)

그리고 100 유져의 안정적인 멀티 커넥션을 까지 처리하기까지 고난의 연속입니다. 

AKKA에서는 이 고민의 시간을 줄이고 , 우리의 개발 서비스를  어떠한 라우팅전략을 써고 클러스터링으로 잘 구성할것인가에대해서  집중하도록합니다. 

...