내가 Akka Actors 를 좋아하지 않는 이유 [번역]

은총알은 없으며 무엇을 사랑한다면 그것의 약한 점은 무엇인지도 알아야 하기에 번역해 보았습니다.

내가 Akka Actor 를 좋아하지 않는 이유  [번역] 

http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/

우리는 최근에 Myna의 백엔드 서비스를 다시 작성했습니다. 아키텍처가 크게 변경되어 이제는 더 빠르고 쉽게 확장 할 수 있습니다. 중요한 아키텍처 변경 중 하나는 모든 Akka 액터를 제거하는 것이 었습니다. 첫 번째 버전의 백엔드에서는  많이 사용 되었지만 이제 다른 동시성 관리 방법을 선호하게 되었습니다. Akka의 액터가 스칼라 커뮤니티 내에서 매우 두드러진 영향력을 가지고 있기 때문에 왜 우리가 이 변경을 했는지 설명하는 것이 매우  흥미로울 것 같습니다.

Actors 는  조악한 추상으로 이루어 졌다.

Actors 는 동시성을 위한 보편적인 프리미티브로 제공됩니다. 즉, 정통 액터 세계관에서 동시 프로그램에 필요한 모든 것입니다. 이 접근 방식은개념적으로 단순함이 매력적이며 다른 컨텍스트들 하에 쩌는 추상형을 찾는 아이디어는 꽤 성공적 이었습니다. 예를 들어, 스칼라가 자바의 원시 및 객체 유형을 통일 한 경우, 또는 파이썬이 모든 언어 커뮤니티에서 일반적으로 긍정적인 포인트로 간주되는 가변(mutable) 사전으로 모든 값을 나타내는 경우.

단순함을 추구 할 때 생기는 중요한 구별이 숨겨져 있을 때 문제는 발생합니다. 프로그래밍 언어에서 이것은 일반적으로 성능을 논의 할 때 나타납니다. 원시와 객체 유형의 차이는 속도면에서 중요합니다. 스칼라는 스칼라 컴파일러와 핫스팟에서 똑똑한 컴파일을 통해 대부분 이 부분을 없애 버렸지만 고성능 코드를 작성하는 것은 여전히 ​안개속에 있습니다.

동시 프로그래밍에는 동시성, 상호 배타성 및 동기화라는 세 가지 별개의 문제가 있습니다. 액터의 경우 처음 두 개가 항상 결합되어 있으며 사용자 정의 메시지 프로토콜을 통해 자신 만의 동기화를 수행 할 수 있습니다. 동시성과 상호 배타 제어를 분리하는 것과 같은 간단한 작업을 원한다면 불행 속에 빠지게 됩니다. 이것은 유별난것은 아니며 단순히 ConcurrentHashMap 를 사용하는 것입니다. 예를들어 정말로 성능을 원하면 lock-free 알고리즘을 사용하고 싶을 것입니다. 다시 말하지만, 이들은 액터 모델에 맞지 않습니다. 기본적으로 액터 모델은 우리에게 동시 프로그램에 대한 엄격한 개념에 부합 할 수 있도록 많은 도구를 포기하도록 강요합니다. 

(역주: 기본적인 자바 동시성 도구들을 사용해서 간단히 해결 할 수 있는 문제에 굳이 아카를 사용할 필요는 없겠지요.Coarse Abstractions 는 좀 과한 표현인듯?) 

Actors 는  잘 구성되어 있지 않다. 

컴포지션은 추상화의 바람직한 속성입니다. Function compose 는 함수형 개념에서 아주 일반적입니다. 어떤 함수 (예 : 더하기 및 빼기)를 만들면 다른 함수 (곱하기)를  그 함수를 사용하여 (구성되어) 만들 수 있습니다. 

Actors는 유연하게 구성되지 않습니다. 기본적으로 액터는 보내는 메시지의 수신자를 하드 코딩합니다. 액터 A를 만들어 액터 B에게 메시지를 보내는것을 액터 C로 변경하려면 매우 상황은 불편해 집니다. 운이 좋다면 사전에 이것을 예상하고 만들겠지만 소스를 변경해야 할 가능성이 큽니다. 구성능력이 부족하여 작은 시스템에서 큰 시스템으로 확장시켜 만드는 것이 어렵습니다.

(역주: 확실히 이 부분은 문제인듯한데.. Akka Streams 를 이용하여 좀 더 편하게 사용 할 수 있습니다.) 

Actors 는 유용한 타입시스템으로 되어 있지 않다. 

Akka의 액터는 한 액터 내에서 정적 타이핑을 제공하지만 액터 사이의 통신 (잘못 될 가능성이 큰 복잡한 비트)은 유용한 방식으로 입력 되지 않습니다. 나는 위의 두 가지 문제는 참을 수 있지만 이 문제는 정말로 ...

타입 시스템이 Scala를 사용하는 주요 이유입니다. 타입을 사용하면 프로그램의 특정 속성을 보증 할 수 있습니다. 당신이 현대적인 정적 타입의 프로그래밍 언어를 사용한 적이 없다면, 한번 써보세요. 얼마나 쩌는지 놀라게 될 것입니다. Akka는 become 와 transparent distribution 와 같은 많은 기능을 지원하는데 그것들은 정적으로 메세지를 타이핑 하는것을 어렵게 만듭니다. 동적 유형 언어를 사용하지 않은 불편을 희생하고 얻은 정적 타이핑의 이득 조차 잃어 버렸습니다. 이것은 말도 안되죠. 

Concurrent ML과 Haskell 같은 다른 언어들은 정적 타입 언어에서 동시적이고 분산 된 프로그래밍 추상화가 가능하다는 것을 보여주었습니다. 나는 단지 스칼라에서 같은 것을 기대했을 뿐입니다.  

이미지 참고 : http://www.slideshare.net/krivachy/the-dark-side-of-akka-and-the-remedy 

(역주: Any 로 입력받는 문제가 있다. 다음 링크를 통해 어느 정도 해소하고 있다. Akka Typed)

그래서 우리는 무엇을 사용했나?

그럼 Myna는 무엇을 사용합니까? 우리는 Akka의 Futures를 사용합니다. 환상적입니다. 우리는 상호 배제를 원하는 단순한 경우에 평범한 잠금을 사용하고 java.util.concurrent에있는 몇 가지 유틸리티를 사용합니다. 그것은 매우 간단하고 매우 빠릅니다 : 평균 응답 시간이 2.5ms이고 단일 코어 시스템에서 650 개 이상의 요청을 처리합니다. 

* 파이썬은 기본적으로 이 문제에 대해서는 아무 것도 하지 않습니다. 그래서 느립니다. 실제로 모든 것을 가변적인 사전으로 만드는 결정은 파이썬을 최적화 하기가 너무 어렵습니다. Python을위한 JIT 컴파일러 인 PyPy는 아직 널리 배포되지 않았습니다.

기타 Akka 단점에 대한 문서들 

* http://letitcrash.com/post/40755146949/tuning-dispatchers-in-akka-applications

* http://eng.localytics.com/akka-streams-akka-without-the-actors/