Golang 에서의 Actor 모델

액터 모델(Actor Model)은 컴퓨터 과학에서 동시성(concurrent)문제를 해결하기 위해서 사용하는 소프트웨어 개발 모델이다. 연극 무대는 여러 액션들이 동시에 일어난다. 감독은 하나 이상의 액터(배우)에게 명령(큐 사인이라고 하던가 연극을 잘 몰라서)을 전달하는 데, 명령을 받은 액터들은 자기의 액션과 대본을 소화한다. 감독은 큐 사인만 내릴 뿐으로, 나머지 행동은 액터들이 전적으로 알아서 진행한다.

소프트웨어에서의 액터 모델도 이와 비슷하게 작동한다. 액터역할을 하는 코드는 메시지의 수신을 대기하고 있다가 메시지가 전달이 되면, 명령을 수행하고 그 결과를 반환한다. 두 개 이상의 액터가 존재 할 수 있으며, 이들 액터는 다른 액터들에 대해서 독립적으로 작동하기 때문에 동시에 두 개 이상의 문제를 해결 할 수 있다. 아래 그림을 보자.

코디네이터(Coordinaotr)가 일을 분배하는 역할을 맡는다. 코디네이터는 처리해야 할 일이 생기면, 액터 중 하나를(보통 놀고 있는) 선택해서 작업 메시지를 전송한다. 작업 메시지를 받은 액터는 메시지를 읽어서 작업을 처리하고 그 결과를 코디네이터에게 전송한다. 액터 모델의 가장 단순한 형태라고 할 수 있다. 실제 애플리케이션을 만들 때는 메시지 큐(메시지 박스라고 보통 부르는)를 두거나 액터가 부족할 경우 새로운 액터를 만드는 등의 응용을 하게 된다.

이 방식의 장점은 아래와 같다.

1. 이해하기 쉽다. : 메시지를 기다리고 있다가 읽어서 처리하면 된다. 동작이 간단하고 다른 영향에 대해서 신경쓸 필요가 없기 때문에, 코드를 만들고 그 결과를 예측하는게 매우 쉽다.
2. 공유 자원 제어로 부터 자유롭다. : 공유 메모리와 잠금이 필요가 없다. Race condition과 데드락(deadlock)에서 자유롭다.
3. 손쉬운 확장 : 액터는 다른 액터와 독립적이다. 따라서 용량이 부족하다면 다른 머신에 액터를 실행하는 것만으로 Scale-Out 할 수 있다.

반면 공유 자원을 이용하는 방식보다 더 느리다는 단점이 있지만 CPU 클럭 상승의 한계와 Scale UP의 어려움 특히 클라우드 컴퓨팅이 일반화 되면서, Scale-Out이 쉬운 액터 모델을 사용하는 경우가 늘어나고 있다.

따라서 액터 모델을 위해서는 아래와 같은 특징을 구현해야 한다.

• 액터는 다른 액터와 완전히 분리된다.
• 액터와 액터들은 메시지만으로 작업을 수행한다.

각 액터는 아래의 일들을 할 수 있다.

• 자식 액터를 만들거나
• 자식 액터를 죽이거나
• 다른 액터에 메시지를 보낼 수 있다.

액터 모델은 코디네이터와 액터로 구성이 된다. 코디네이터는 메시지를 액터에게 전달 하는 것으로 작업을 수행한다. 이들 구성요소는 각각 고루틴(goroutin)과 채널(chan)에 대응 된다.

• Actor -> goroutine : 메시지를 읽어서 처리한다.
• MessageBox -> chan : 액터는 채널로 부터 메시지를 읽을 수 있다.

메시지박스는 채널로 구현 할 수 있다. int 타입의 메시지를 저장할 수 있는 메시지박스 - MessageBox - 를 만들었다. 이제 <-연산자를 이용해서 채널에 메시지를 보내고, 읽을 수 있다. MessageBox로 부터 메시지를 읽고 싶다면 아래와 같이 메시지를 보내고 싶다면 아래와 같이 하면 된다. 이제 코디네이터가 MessageBox에 보낸 데이터는 액터 고루틴이 읽을 수 있게 된다. 아래는 Ping, Pong 메시지를 주고 받는 간단한 go 예제다.

... 계속

1. Actor model - wikipedia
2. 맛만 보자 액 모델이란
3. An actor model in go