최근에 AKKA자체의 장점을 주위 사람에게 소개해주고 떠들고 있습니다.
그런데 비개발자에게 AKKA란 단어를 설명해 주는게 더 편하더군요
새로운 개발 트렌드에대한 소개는 분명 기존 개발경험의 약점을 지적하고 시작해야 하기때문에
자칫 우월주의에 빠질수 있으며, 불편한 논쟁이 될수 있기때문입니다.
실제로 액터를 설명하다가 자유로운 멀티스레드 구현및 작성을 통해 실무에 사용하고 적용해야된다란
이슈까지 회기 해버리는 불편한 상황이 생겨버립니다.
액터는 그 반대의 입장에 있습니다. 복잡성은 모두 방해요소로 측정하고 앲앤상태로 시작해 나가는 것입니다.
하지만, 그 복잡성을 줄이는 것에대해 설명하기위해서는 여러가지 구체적인 예시가 뒤따라야하고
더 추상적인 요소에대한 설명도 필요하며, 같은 의미로 동의를 구해내기도 어렵습니다. 습관을 바꾸기도 어렵습니다.
전통적인 개발방법과 그것을 개선할수 있는 방법 솔직히 저도 다 이해가 안되며 아직 내공이 부족한듯 보입니다.
그냥 혼자 연구하기엔 아깝고 외로웠을지도 모르겠습니다.
(이 주제와 유사한 것에 관심있는분 여기에 공간을 만들수있고 문서를 가져갈수있는 권한을 드립니다. 문의처: psmon@live.co.kr )
AKKA 도입여부결정은 뒤로 한참 미루고 단지 제가 팀내에서 경험한 사소한 이야기와
메이져에서는 어떠한 일들이 벌어지고 있는지 간단하게 소개하려고 합니다.
경험없이 떠들고, 다른사람의 경험을 폄하하는 그러한 개발자가 안되기를 다짐해봅니다.
필자의 개발팀에서의 적용사례
이전 개발팀에서 AKKA적용스토리를 잠깐 이야기 해보겠습니다.
3~4년전 분명 C++이 메이져인 우리개발팀에서 SCALA와 더불어 AKKA 플래폼 사용을 결정하였습니다.
고집스러운 C++ 개발자에게 이러한 민주주의방식으로 자바기술을 선택한다는것은 아주 어려운 과정이였습니다.
- 웹서비스로의 도약을 위해 자바혹은 닷넷이 필요하며, C++은 개발자 구하기가 어렵다
- 개발자의 대부분은 웹개발자이며 , 저수준 TCP패킷처리를 통해 서버개발을 할수 없으며 무엇인가가 필요하다.
- SCALA/AKKA 가 그러한 서버 기술에대해 평준화되는 무엇인가를 준비해 놓은것같으니 팀에서 배우고 준비하자
간단하게 요약하면 위 3가지 스텝으로 결정이 되었으며 서버개발에 있어서 자바 개발자를 유입시키기 시작했습니다.
어떠한 개발자에게는 이것은 지구를 침략하는 외계생명체와 같았으며, 관련 자료도 찾기힘들었습니다.
적어도 국내에서 언급조차 안되던 시기였으니까요 , 실제로 이과정에서 c++노선을 유지하여 팀을 떠나
더 잘되신 분도 계십니다.
JAVA진영에서 외치던 그 플래폼을 결국 C++진영에서 JAVA를배워 가며 AKKA를 통해 기존 서비스를 바꾸는 프로젝트가 진행이되었습니다.
이 과정중, 자바에서 대용량 웹소켓을 액터와 연결하고 트래픽 테스트를하고 검증하는 과정을 오히려 팀내 자바 진영에 가르키기 까지 했으며
안정적인 버젼조합에 대해 공유를 하였습니다.( 네티 + 앱모스피어 + 액터 + 스칼라버젼 + PLAY + AKKA : 초기버젼에서 안정적인 라이브러리
조합을 찾기란 거의 헬이였습니다. 마치 옛날옛적 컴퓨터 조립할때 안맞는 구성으로 작동이안되는 시절이 있었듯이 )
이 과정에서 실제 이름을 대면 유명한 자바개발자 라고 소개받았지만, 큰 도움을 받지 못했습니다.
GC작동에대한 JAVA 6/7 의 차이를 오히려 C++ 개발팀 진영에서 검증하기 시작했습니다. 적어도 이때는 생명주기가 다한
Data를 직접 메모리 해제를 해야안심이 되는 C++개발팀은 자바에서 자동처리되는 객체를 믿지 않았기때문입니다.
팀내 자바개발자는 JVM을 믿고 잘 사용하기 때문에 이러한 문제에대해 고민하지 않는듯 보였습니다.
하지만 JMX등 자바 플래폼에서 운영 성능 문제해결을 위해 많은고민을 했고 몇가지 툴들을 사용하기 시작하면서
분명 C++에서 고민했던 어떤 문제들은 쉽게 풀어나갔으며 어느부분 이해하고 동의하기 시작하였습니다.
결국 극한의 성능 테스트를 통과하고 AKKA를 통한 웹서비스및 모바일 서비스 런칭을 성공하였습니다.
극한의 성능테스트 링크에서 이것이 실제로 일어난 일임을 확인할수 있습니다. ( 당시 로드 테스트 목표및 결과에대한 정보도 포함 )
이후 다른 목표를 가지고 대부분 순수 JAVA진영 개발자들만이 남게된 프로젝트는 서비스런칭에 성공하지 못했습니다.
목표하는 바가 달랐으며 결과로 가지고 개발능력을 판단하는게 아니며, AKKA에 대한 순수이해는 자바진영의 개발자들이 분명 더 뛰어났습니다.
기존 서비스개발자가 필요없어도 성공할수 있다고 착각을 하고 진단을 빨리하지 못한게 프로젝트의 실패요인중 하나입니다.
고집스러운 C++ 개발자가 언어를 뛰어넘는 기술을 받아들이고 그것을 이해하려는 능동적인 활동에 의미를 두겠습니다.
기존 서비스개발자가 스스로 새로운 도구를 사용하고 능동적으로 개선하려 하지 안았다면, 아주 어려운일이 될것입니다.
지금은 아마 C++에서도 Actor의 개념을 활용하는 라이브러리가 있을것으로 추측됩니다.
- AKKA 성공사례 (국내최초라고 단언 말할수 있겠습니다만 의미 없습니다. 성공사례보다는 최초 적용사례가 맞을지도 모르겠습니다.)
MS도입 사례
소규모 사례는 특수하기때문에 이정도로 언급을 하고, 거대 공룡 MS의 도입사례를 보겠습니다.
국내 중견개발 기업의 사례가 있으면 더 좋겠지만, 커뮤니티 활동에서 찾기 힘들더군요
MS거대 기업이 AKKA의 개발 컨셉을 도입하고 Microsoft 네임스페이스를 포함하는것은
아주 놀라운 사실일것입니다. 더욱이 해일로 멀티플레이어에서 성공을 했다고 성공사례로 광고까지 합니다.
액터개념을 자바/MS가 공식적으로 지구에 정착할수있도록 공식 지원하기때문에
이제는 더이상 외계 생명체가 아닙니다. 이부분은 아래 내용에서 다시 언급하도록 하겠습니다.
탄생 히스토리
최근 몇년간 "분산환경에서 유연한 동시성 개발모델" 이라는 주제하에 이슈가 되고 있습니다.
언랭-OTP / GO언어등 직접 서비스에 녹인 성공사례가 많이 나오고 있으며, 성공사례의 이면을 살펴보면
고전적인 기존 해결방법의 문제점을 철저하게 분석하고 새로운 개발 모델을 제시하고 성공사례로 이어졌다란것입니다.
- 요구사항대비 자원이 증가하는 경유
- 자원이 증가하여 복잡도가 증가하는 경우
고전 적인 기존 해결방법의 문제점은 대부분 위와같은 상황이 됩니다
자바
자바및 MS 진영에서 우리는 우리의 방식으로 문제를 풀래라고 귀를 닫았으면 AKKA는 탄생하지 못하거나, 액터는 퍼지지못했을것입니다.
다른곳에 귀를 기울이고, 우리가 해결하려고 했던 고전적 방식에 한계를 느끼고 늦게나마 다른언어에서 좋은 개발모델을 도입하려는 시도를하였으며
그 이전에 자연스럽게 순수한 프레임워크 차원 에서 asyn,task 와 같은 키워드지원으로 멀티스레드의 복잡성에서 먼저 해방이됩니다.
이때부터 각 언어들이 블록킹이 없는 비동기 프로그래밍의 장점을 홍보하기 시작합니다.
하지만 한참전에 언랭의 OTP 에서 단순한 비동기처리가 분산환경에서 문제사항으로 지적하였고 콜백지옥이없는 개선작업을 진행하였습니다.
그리고 비동기처리에서 더 추상화된 동시성 처리모델인 액터모델을 제시하였으며 , 여러가지 영향을 끼쳤습니다.
AKKA는 그러한 컨셉을 대부분 참조했다라고 보면 됩니다.
문제의 해결법은 단순합니다. 복잡성을 최대한 제거하는것만이 분산환경에서
서비스를 올바르게 설계할수 있다입니다.
또한 기존 솔리드형태의 웹서비스는 분산환경 즉 AKKA와 어울리기 어려운 웹환경으로 판단하고
이와동시에 https://www.playframework.com/ 라는 마이크로서비스에 적합한 웹서비스도 같이 준비했습니다.
MS진영
그러면 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일 필요도 없습니다.
다만 AKKA가 제공하는 스펙이 무엇이고 내가가진 구현능력으로 커버가 가능한 부분인지 확인은 필요해보입니다.
이에 준하는 개발모델을 미리 익혀두고 대비해두는것
능동적으로 개발모델을 개선하지 않는다고 하면 새로운 개발 모델을 배울필요가 없습니다.
액터는 능동적으로 적용하지 않으면, 성공할수 없습니다.
비능동적으로 완성된 어떠한 메시지큐 서비스를 이용하는게 적합하다라고하면
그것을 통해 성공적인 서비스를 해도 무관합니다.
하지만 각 주요 플래폼 개발 진영에서 서비스 해도 문제없을만큼 성공 사례와 문서및 샘플을 준비 해놓았으며
개발자에게 능동적으로 분산환경을 직접 설계할수 있는 기회를 줬다라고 생각하며,
이 기회를 놓치면 안된다라고 생각합니다.
객체 지향을 거쳐 비동기프로그래밍에 이은 액터프로그래밍은 새로운 개발 패러다임이 되지 않을까? 추측해보며
개발자로 밥먹고 사는데 없어도 되는 기술일수도 있으나
아래 링크를 통해 각 진영에서 어떻게 프로젝트가 진행이 되고 있고
내가 위치한곳은 어디며? 필요한것인지?
정도는 파악을 하는데 도움이 되었으면 좋겠습니다.
언급된 링크들
Actor지원 개발 툴킷:
- http://akka.io/
- http://getakka.net/
- https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/
확장에 용이한 마이크로 웹서비스: 웹서비스를 한곳에 몰아넣고, 내부에서 추가삭제가 용이한 솔리드 형태와 반대성격입니다.
기타: c++ python node.js 등 주요 메이져 언어에서도 actor를 지원하려는 움직임이 구글링을 통해 포착이됩니다.
이것이 작동되는지 확인을 위해 파이썬에서도 액터를 사용해 보았습니다. 파이썬을 처음 설치해보고 시도한것입니다.