CPU들은 더 이상 빨라지지 않는다오. CPU에 고로 오늘날 코어 여러개를 집적하게 된다네. 이제 상용화된 이 하드웨어의 성능을 최대한 끌어내길 원한다면, 코드를 병행 수행시킬 방법이 필요하오. 수십년간의 추적이 어려운 버그들과 개발자가 격은 침울함을 고려하건대 스레드는 더 이상 그 방법이 아니오. 허나 두려워 말라, 이를 대체할 훌륭한 방식이 있으며 그중 하나인 Actor Model 을 오늘 소개하고자 한다오.
The model
행위자 모델은 병행 계산을 다루기 위한 개념적 모델이다. 이는 시스템 요소들끼리 어떻게 행동하고 상호작용하는지에 대한 일반적인 방법을 규정한다. 이 모델을 사용하는 가장 유명한 언어는 Erlang이다. 여기선 여러 다른 언어나 라이브러리에서 이 모델이 어떻게 구현되는데 집중하지 않고 모델 그 자체에 집중할 것이다.
Actors
행위자(Actor)는 연산의 기본 단위이다. 행위자는 메시지를 수신하고 그에 기반이 되는 어떤 연산을 수행하는 어떤 '것' 이다.
개념은 기존 객체지향언어에서 언급된 개념과 매우 유사하다. 한 객체는 메시지를 받고(메서드 콜) 어떤 메시지가 도착했느냐에 따라 특정 동작을 수행한다(우리가 호출한 메서드).
차이가 있다면 행위자는 다른 것들과 완전하게 독립되어 있다는 것이다. 이는 주된 차이점으로 상호간 메모리를 공유하지 않는다. 이는 행위자의 내부 상태는 다른 행위자에 의해 직접적으로 절대 변경될 수 없고 스스로 유지가 가능하단 점에서 가치가 있다.
One ant is no ant
한 개미는 더 이상 개미가 아니다. 그들은 협동하며 살고 혼자선 군림하지 못한다. 행위자도 마찬가지다. 즉 One actor is no actor다. 그들은 시스템을 이룬다. 행위자 모델에서 모든 것은 행위자이고 주소를 갖는다. 이는 한 행위자가 다른 행위자를 특정하여 메시지를 보낼 수 있도록 하기 위함이다.
Actors have mailboxes
여러 행위자가 동시에 계산을 수행할 수 있다 하더라도 하나의 행위자는 하나의 주어진 메시지만을 순차적으로 처리한다는 점을 이해하는 것은 매우 중요하다. 3 개의 메시지를 동일한 행위자에게 전달할 수는 있지만 이 경우, 한번에 하나씩 처리가 된다. 이 3개의 메시지가 병행 처리되도록 하려면 3개의 행위자를 만든 후 각각에 메시지를 하나씩 보내야 한다.
메시지는 한 행위자에게 비동기적으로 보내지며, 따라서 행위자는 현재 처리되고 있는 메시지가 있는 경우 이를 어딘가에 저장할 필요가 있다. 이때 그 저장소가 우편함(mailbox)이다. 각 메시지는 처리될 때까지 우편함에 저장된다.
what actors do
행위자가 메시지를 받으면, 3가지 중 한가지를 수행한다.
- 행위자를 더 생성한다
- 다른 행위자에게 메시지를 전달한다
- 다음 메시지로 무엇을 할지 결정한다
첫 2개는 매우 직관적으로 이해 가능하다. 하지만 마지막은 모호하되 살필 필요가 있다. 한 행위자는 그 내부 상태(private state)를 유지할 수 있다 전술하였다. "Designating what to do with the next message"란 기본적으로 이 상태가 다음 메시지를 받았을 때 어떻게 보일지를 결정하는 것을 의미한다. 즉, 명백히 말해서 이는 행위자가 상태를 변화시키는 방법이다.
계산기처럼 동작하는 행위자가 하나 있고 그 초기 상태가 단순히 숫자 0이라고 해보자. 이 행위자가 add(1) 과 같은 메시지를 수신한다면, 그 본래의 상태를 변경하는 대신에 다음에 수신한 메시지가 처리될 때 그 메시지에 대해 현재 상태를 1로 보여주는 방식이다(매우 중요).
Fault tolerance
Erlang에서는 "고장나도록 냅둔다|신경안쓴다('let it crash')"는 철학을 도입했다. 이 철학은 모든 나타날 수 있는 가능한 모든 문제상황들을 예상하고 그것들을 다 다룰 수 있는 방법을 마련하는 방어적인 프로그래밍을 할 필요가 없도록 만들어준다. 이는 단순히 모든 단일 실패 지점을 고려할 방법이 없기 때문이다. Erlang에선 단지문제가 생기(crash)도록 놔두지만, 중요 핵심 코드가 특정 주체에 의해 감시되도록 하며 그 주체는 단지 고장(crash)이 발생하면 무엇을 할지만을 알고 있다(가령 모든 안정된 상태로 리셋한다거나). 그런데 이를 행위자 모델이 가능케 한다.
모든 코드는 한 process 내에서 실행된다(이는 Erlang이 그의 행위자를 호출하는 기본적인 방법이다). 이 process는 완전히 고립되어 있으며 따라서 해당 process의 상태가 어떤 다른 process에게도 영향을 줄 수 없다. 관리자(supervisor)가 있고 이 또한 역시 기본적인 하나의 또다른 process 이다(모든 것은 행위자란 것을 기억하는가?). 관리자는 감시하고 있던 process가 문제를 일으키면 통지를 받게 되고 그에 대한 적절한 처리를 수행할 것이다.
이를 통해 자가 회복("self heal")하는 시스템을 만드는 것이 가능해진다. 어떤 이유라도 행위자가 깨지거나(crash) 예외적인 상태가 되면 관리자가 해당 행위자를 안정된 상태로 되돌리기 위한 작업을 할 수 있기 때문이다(이를 하기 위한 여러 전략이 있는데 가장 흔히 채택되는 전략은 행위자를 재시작하여 초기 상태로 만드는 것이다).
Distribution
행위자 모델의 주목할 만한 또하나의 측면은 행위자는 자신이 메시지를 보내는 대상이 로컬에 있는지 또는 다른 노드에 있는지 전혀 신경쓸 필요가 없다는 점이다.
잘 생각해보면 된다. 한 행위자가 단위 코드만을 갖고 있고 우편함도 가지며 초기 상태에 있다면, 게다가 메시지에 응답할 필요만 있는데 그 행위자가 어떤 머신에서 도는게 큰 문제가 되겠는가? 보낼 메시지만 제대로 도착하기만 한다면 만사 형통이다.
즉, 여러 대의 컴퓨터가 상호작용하고 한 대가 죽은(fail) 경우 다른 하나가 그의 회복을 돕는 시스템을 구성하는 것도 문제가 없다.
출처 : http://www.brianstorti.com/the-actor-model/
