You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

 최근에는 AKKA자체의 장점을 주위 사람에게 소개해주고 있지만, 성공사례가 있는지? 들어보긴했는데 그걸 왜 배워라던지?

이해시키는데 어려움에 있습니다. 오히려 비개발자가 AKKA란 단어를 더 잘알고 있으며 거부감이 없습니다.

새로운 개발트렌드는 분명 나의 개발경험을 부정할것이라는 추측때문이며,

저또한 지구를 침략하는 외계인으로 인식을 하였습니다.

3~4년전 분명 우리개발팀에게 SCALA와  더불어 AKKA는 외계 생명체였으며 듣보잡이였습니다.


결국 팀내 JAVA진영에서 외치던 그 플래폼을 결국 C++진영에서 JAVA를배워  AKKA 서비스를 성공했으며 서비스로 작동중입니다.

팀내 JAVA진영에서는 서비스런칭에 성공하지 못했습니다.  제가 가진 팀에서 일어난 아주 특수한 케이스이며 목표가 달랐기때문에

결과로 가지고 개발능력을 판단하는게 아니며, 고집스러운 C++개발자가 능동적으로 언어를 뛰어넘는 기술을

받아들이고 이해하려는 능동적인 움직임에 의미가 있습니다. 지금은 아마 C++에서도 Actor의 개념을 활용하는 라이브러리가 있을것으로

생각됩니다.

 - AKKA 성공사례 (국내최초라고 단언 말할수 있겠습니다.)


또한 소규모팀이아닌  MS거대 기업이  AKKA의 개발 컨셉을 도입하고 Microsoft 네임스페이스를 포함하는것은

아주 놀라운 사실일것입니다. 더욱이 해일로 멀티플레이어에서 성공을 했다고 성공사례로 광고까지 합니다.

자바/MS가 공식적으로 지구에 정착할수있도록 공식 지원하기때문에

이제는 더이상 외계 생명체가 아닙니다. 이부분은 아래 내용에서 다시 언급하도록 하겠습니다.


최근 몇년간  "분산환경에서 유연한  동시성 개발모델" 이라는 주제하에

언랭-OTP / GO언어등  직접 서비스에 녹인 성공사례가 많이 나오고 있으며,  성공사례의 이면을 살펴보면

기존 언어및 프레임워크 그리고 고전전인 해결방법의 문제점을 철저하게 분석하고 새로운 개발 모델을 제시했다란점입니다.


 자바및 MS 진영에서 우리는 우리의 방식으로 문제를 풀래라고 귀를 닫았으면  AKKA는 탄생하지 못하거나, 액터는 퍼지지못했을것입니다.

다른곳에 귀를 기울이니, 우리가 해결하려고 했던 방식에 문제를 느끼고  늦게나마 외부언어에서 좋은 개발모델을 도입하려는 시도를하였으며

그 이전에 자연스럽게 순수한 프레임워크 차원 에서 asyn,task 와 같은 키워드지원으로 멀티스레드의 복잡성에서 먼저 해방이됩니다.

이때부터 각 언어들이 블록킹이 없는 비동기 프로그래밍의 장점을 홍보하기 시작합니다.

한참전에 언랭의 OTP 에서 단순한 비동기처리가 분산환경에서 문제사항으로 지적하였고 콜백지옥이없는 개선작업을 진행하였습니다.

그리고 비동기처리에서 더 추상화된 동시성 처리모델인 액터모델을 제시하였으며

AKKA는 그러한 컨셉을 대부분 참조했다라고 보면 됩니다.

문제의 해결법은 단순합니다.  본질은 유지하고 개발 복잡성을 최대한 제거하는것만이 분산환경에서 

서비스를 올바르게 설계할수 있다입니다. 


또한 기존 솔리드형태의 웹서비스는 분산환경 즉 AKKA와 어울리기 어려운 웹환경으로 판단하고

이와동시에  https://www.playframework.com/ 라는  마이크로서비스에 적합한 웹서비스도 같이 준비했습니다.


그러면 MS진영은 어떠한 활동을 했을까요? 닷넷프레임워크가 대부분 자바의 장점을 가지고 가려고 노력을하며

실제로 그렇게 합니다. 하지만 아무리 유명해도 선별을 하며 결코 함부로 microsoft 네임스페이스에 포함시키지 않습니다.

적어도 띄어난 개발팀이 어떠한 네임스페이스를 담당하고 있고 성과가 있을때 포함이 됩니다.


MS진영에서는 액터모델에 대응하기위해  orleans 이라는 프로젝트를 공식적으로 진행하고 있으며, akka의 스택과 유사합니다.

저의 플래폼 예상이 항상맞지는 않으나~  언젠가 닷넷 프레임워크에 기본으로 탑재를 시킬듯도 보입니다.

또한  MS역시 IIS형태의 솔리드 서비스가 스케일아웃이되는 분산환경에 적합하지 않을것으로 이미 결론을 내리고

 http://owin.org/  라는 오픈형 웹서비스를  MS가 개발팀을사고 닷넷프레임워크에 공식적으로 녹였습니다.


오픈프로젝트는 별개로 진행되고 있으며,  asp.net 개발자도 잘모르더군요  

microsoft.iis.host 같은 IIS종속적인 네임스페이스를 개선하고 있지만

vs 2015에서 asp.net 프로젝트 생성하면 기본으로  owin.host 기반으로 작동중인 사실을  

owin.host의 탄생배경은 윈도우/IIS탈출을 통한 마이크로 웹서비스였으며, 

실제로는 이제 iis종속적인 웹서비스의 한계를 느끼고 여기에 더 많은 지원이 이루어지고 있습니다.

이것은 어떤 의미냐고하면, 아무런 생각없이 만든 asp.net 서비스가 리눅스에도 돌아갈수 있음을 의미합니다.

이야기가 돌아 웹서비스로 까지 갔지만 , 다시 본론으로 돌아와


어쨋건 Actor개념은 언랭에서 나왔으며, Actor모델 지원은 각 진영에서 가진 프레임워크에서 아주 중요하게 생각하고

있다란것이며, 과장을 하면 AKKA의 시작은 Actor이며 마지막까지 Actor입니다.

분산환경 비동기처리를 유연하게 하기 위해 AKKA일 필요는 없습니다. AKKA는 툴이며 ACTOR는 개발모델입니다.

다른 툴로 ACTOR모델을 사용하면 되며 ACTOR일 필요도 없습니다.


이에 준하는 개발모델을 미리 익혀두고 대비해두는것

능동적으로 개발모델을 개선하지 않는 다고하면 새로운 개발 모델을 배울필요가 없습니다.

액터는 능동적으로 적용하지 않으면, 성공할수 없습니다. 

비능동적으로 완성된 어떠한 메시지큐 서비스를 이용하는게 적합하다라고하면

그것을 통해 성공적인 서비스를 해도 무관합니다. 


하지만 각 주요 플래폼 개발 진영에서 서비스 해도 문제없을만큼 성공 사례와 문서및 샘플을 준비 해놓았으며

개발자에게 능동적으로 분산환경을 직접 설계할수 있는 기회를 줬다라고 생각하며,

이 기회를 놓치면 안된다라고 생각합니다.

객체 지향이후 비동기프로그래밍에 이은  액터모델은 새로운 개발 패러다임이 되지 않을까? 추측해보며

아래 링크를 통해 각 진영에서 어떻게 프로젝트가 진행이 되고 있는지 정도는 파악을 하면 도움이 될듯 합니다.


Actor지원 개발 툴킷:

확장에 용이한 마이크로 웹서비스: 웹서비스를 한곳에 몰아넣고, 내부에서 추가삭제가 용이한 솔리드 형태와 반대성격입니다.

기타: c++ python node.js 등 주요 메이져 언어에서도 actor를 지원하려는 움직임이 구글링을 통해 포착이됩니다.




  • No labels