최근에는 AKKA자체의 장점을 주위 사람에게 소개해주고 있지만, 성공사례가 있는지? 들어보긴했는데 그걸 왜 배워라던지?
설득하는데는 어려움에 있습니다. 오히려 비개발자가 AKKA란 단어를 더 잘알고 있습니다.
국내에서 성공사례가 잘없고 운영서비스 자체에 대부분 분산 처리 뿐아니라 실시간 처리 장치조차 없으며,
부자연스럽게 어떤 외부장치 또는 솔류션과 연동하여 분산 서비스를 잘 유지시키고 있기때문입니다.
최근 몇년간 "분산환경에서 유연한 동시성 개발모델" 이라는 주제하에
언랭-OTP / GO언어등 직접 서비스에 녹인 성공사례가 많이 나오고 있으며, 성공사례의 이면을 살펴보면
기존 언어및 프레임워크 그리고 고전전인 해결방법의 문제점을 철저하게 분석하고 새로운 개발 모델을 제시했다란점입니다.
자바및 닷넷프레임워크 진영에서 우리는 우리의 방식으로 문제를 풀래라고 귀를 닫았으면 AKKA는 탄생하지 못했습니다.
다른곳에 귀를 기울이니, 우리가 해결하려고 했던 방식에 문제를 느끼고 늦게나마 외부언어에서 좋은 개발모델을 도입하려는 시도가 있었습니다.
자바 진영에서는 심지어 SCALA라는 새로운 언어를 만들고 JAVA와 AKKA를 동시에 사용할수있는 프레임워크도 만들었습니다.
또한 기존 솔리드형태의 웹서비스의 한계를 느끼고 https://www.playframework.com/ 라는 새로운 마이크로서비스에 적합한 웹서비스도 준비했습니다.
MS진영에서도 액터모델에 대응하기위해 orleans 이라는 프로젝트를 공식적으로 진행하고 있으며, 저의 플래폼 예상이 항상맞지는
않으나~ 언젠가 닷넷 프레임워크에 기본으로 탑재를 시킬듯도 보입니다.
또한 MS역시 IIS형태의 솔리드 서비스가 스케일아웃이되는 분산환경에 적합하지 않을것으로 이미 결론을 내리고
http://owin.org/ 라는 오픈형 웹서비스를 MS가 개발팀을사고 닷넷프레임워크에 공식적으로 녹였습니다.
오픈프로젝트는 별개로 진행되고 있으며 asp.net 개발자도 잘모르더군요 microsoft.iis.host 같은 IIS종속적인 네임스페이스를 버린지 오래되었으며
실제 asp.net은 owin.host 기반으로 작동중인 사실을 owin.host의 탄생배경은 윈도우/IIS탈출을 통한 마이크로 웹서비스였습니다.
이것은 어떤 의미냐고하면, 아무런 생각없이 만든 asp.net 서비스가 리눅스에도 돌아갈수 있음을 의미합니다. 윈도우/IIS가 아니어도 된다란 의미입니다.
이야기가 돌아 웹서비스까지 갔지만 , 다시 본론으로 돌아와
어쨋건 Actor개념은 언랭에서 나왔으며, Actor모델 지원은 각 진영에서 가진 프레임워크에서 아주 중요하게 생각하고
있다란것이며, 과장을 하면 AKKA의 시작은 Actor이며 마지막까지 Actor입니다.
분산환경 비동기처리를 유연하게 하기 위해 AKKA일 필요는 없습니다.
다만 이에 준하는 개발모델을 미리 익혀두고 대비해두는것
능동적으로 개발모델을 개선하지 않는 다고하면 새로운 개발 모델을 배울필요가 없습니다.
액터는 능동적으로 적용하지 않으면, 성공할수 없습니다.
비능동적으로 완성된 어떠한 메시지큐 서비스를 이용하는게 적합하다라고하면
그것을 통해 성공적인 서비스를 해도 무관합니다.
하지만 각 주요 플래폼 개발 진영에서 서비스 해도 문제없을만큼 성공 사례와 문서및 샘플을 준비 해놓았으며
개발자에게 능동적으로 분산환경을 직접 설계할수 있는 기회를 줬다라고 생각하며,
이 기회를 놓치면 안된다라고 생각합니다.
객체 지향이후 비동기프로그래밍에 이은 액터모델은 새로운 개발 패러다임이 되지 않을까? 추측해보며
아래 링크를 통해 각 진영에서 어떻게 프로젝트가 진행이 되고 있는지 정도는 파악을 하면 도움이 될듯 합니다.
Actor지원 개발 툴킷:
- http://akka.io/
- http://getakka.net/
- https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/
확장에 용이한 마이크로 웹서비스: 웹서비스를 한곳에 몰아넣고, 내부에서 추가삭제가 용이한 솔리드 형태와 반대성격입니다.
기타: c++ python node.js 등 주요 메이져 언어에서도 actor를 지원하려는 움직임이 구글링을 통해 포착이됩니다.
분산환경 동시성처리를 위해 Actor가 유일한 개발모델이 아니며, 언젠가 Actor모델의 단점을 지적하는 새로운
개발모델이 나올수도 있습니다. "코딩을 통해 서비스를 만드는것은 잘못되었다. 개발자의 수준을 못믿기때문에
우린 클라우드로 원클릭을 통해 서비스를 설계한다" 이러한 시대가 언젠가는 분명 올것입니다.
다만 액터모델은 자바/MS진영에 서 공식적으로 지원하는 개발 모델이며
분산환경에서의 서비스 설계를 개발자가 직접할수있게 고차원적인 라이브러리를 제공해주며
응용서비스 레벨에 이것을 직접설계하는것은 필요한 부분입니다.
하지만 이것에 유연하게 대응하지 않고 있다면, 우리가 만드는 서비스는 DB호출만 하거나 API만 호출을
하는게 다이며 CPU의 대부분은 그것을 기다리는쓰고 , 트래픽의 대부분은 고정적인 리소스(이미지,텍스트)
를 반환하는데 쓰는게 다일것입니다. 그리고 우리가 하지못하는 어떠한 기능을 외부 의존 메시지 큐서비스를 통해
폴링방식으로 부자연스럽게 연동을 하여 사용할것입니다.
이러한 서비스도 휼륭한 서비스가 될수 있습니다. 하지만 이러한 서비스는 DB의존적이여서
서비스 설계를 dB엔지니어에게 뺏길것입니다. 외부 패키지를통해 서비스 문제를 해결한다고 하면
심지어 데브옵스에게 서비스 설계 기회를 뺏길것입니다.
우리는 더나은 개발 서비스를 위해 의존성을 줄이고 개선할수있는 기회가 있습니다. 그것이 꼭 AKKA나 ACTOR가 아니더라도....