Page History
AKKA 는 복잡한 분산개발환경에서,어렵게 개발했던것을 단순화해 드립니다라고 광고를 합니다.
그
최근에 AKKA자체의 장점을 주위 사람에게 소개해주고 떠들고 있습니다.
그런데 비개발자에게 AKKA란 단어를 설명해 주는게 더 편하더군요
새로운 개발 트렌드에대한 소개는 분명 기존 개발경험의 약점을 지적하고 시작해야 하기때문에
자칫 우월주의에 빠질수 있으며, 불편한 논쟁이 될수 있기때문입니다.
실제로 액터를 설명하다가 자유로운 멀티스레드 구현및 작성을 통해 실무에 사용하고 적용해야된다란
이슈까지 회기 해버리는 불편한 상황이 생겨버립니다.
액터는 그 반대의 입장에 있습니다. 복잡성은 모두 방해요소로 측정하고 앲앤상태로 시작해 나가는 것입니다.
하지만, 그 복잡성을 줄이는 것에대해 설명하기위해서는 여러가지 구체적인 예시가 뒤따라야하고
더 추상적인 요소에대한 설명도 필요하며, 같은 의미로 동의를 구해내기도 어렵습니다.
개발자의 기존 개발 습관을 바꾸기도 어렵습니다.
전통적인 개발방법과 그것을 개선할수 있는 방법 솔직히 저도 다 이해가 안되며 아직 내공이 부족한듯 보입니다.
그냥 혼자 연구하기엔 아깝고 외로웠을지도 모르겠습니다.
(이 주제와 유사한 것에 관심있는분 여기에 공간을 만들수있고 문서를 가져갈수있는 권한을 드립니다. 문의처: psmon@live.co.kr )
. 하지만 AKKA를 배우면서 느낀것은 그것이였습니다.
저의 전통적이 개발방식을 꼬집고 설명하고 구체적인 예를 들면서 저의 개발 습관을 바꾸려고 드는것입니다.
그런데 한참 학습하다보니 중요한 사실을 뒤늦게 깨닫게 됩니다. 분산 개발환경속에서 그것을 이용하고 흉내내는 개발을 하였지만
진정 분산 개발환경을 직접 설계하고 구성하고 확장을 하는 개발을 해본적이 없다란 것입니다.
애시당초 AKKA와 대화할 준비가 안되어있는 상태였습니다. 하지만 AKKA는 친절하게 그러한 분산환경에서 필요한 백그라운드 지식에대해
한참을 설명을 합니다. 오히려 이것에 대해 이해를 시키기위해 코드보다 더 많은 설명을 합니다.
그리고 그것은 AKKA종속적이지않는 분산 개발환경에서 공통적으로 알아야하고 풀어야하는 모델을 제시해시해주며
Akka와 유사한 목적을 가진 다른 플랫폼, 공통적으로 Reactive라는 단어를 공통적으로 언급합니다.
다른 플랫폼에서도 분산처리를 위해 필요한것에대한 코어 컨셉설명을 똑같은 전개로 이야기를 하고 있습니다.
AKKA를 배우고 나면 분산개발환경에서 액터모델 도입이 우리랑 맞지도 않고 해야할필요도 없다란
결론을 낼수도 있습니다. 하지만 그 결정에 도달했을때 고전적인 개발방법의 한계와
분산처리 시스템에서 필요한 개발 컨셉을 배울것으로 기대해봅니다.
AKKA 도입 여부 결정은 뒤로 미루고 AKKA 도입여부결정은 뒤로 한참 미루고 단지 제가 팀내에서 경험한 사소한 이야기와
메이져에서는 어떠한 일들이 벌어지고 있는지 간단하게 소개하려고 합니다.
경험없이 떠들고, 다른사람의 경험을 폄하하는 그러한 개발자가 안되기를 다짐해봅니다.
필자의 개발팀에서의 적용사례
...
이전 개발팀에서 AKKA적용스토리를 잠깐 이야기 해보겠습니다.
3~4년전 4년전 분명 C++이 메이져인 우리개발팀에서 SCALA와 더불어 AKKA 플래폼 사용을 결정하였습니다.
...
이 과정에서 실제 이름을 대면 유명한 자바개발자 라고 소개받았지만, 소개받고 문제해결에 그분야에서 도움움을 주는 포지션에 있었지만
큰 도움을 받지 못했습니다. 동접 천명 서버한대에서 1주일간 버티기에대한 해결과정은 플래폼을 뛰어넘는 과정이였기때문입니다.
GC작동에대한 JAVA 6/7 의 차이를 오히려 C++ 개발팀 진영에서 검증하기 시작했습니다. 적어도 이때는 생명주기가 다한
Data를 직접 메모리 해제를 해야안심이 되는 C해야안심을 하는 C++개발팀은 자바에서 자바에서의 자동처리되는 객체를 믿지 않았기때문입니다대부분 의심했습니다.
팀내 자바개발자는 JVM을 믿고 잘 사용하기 때문에 이러한 문제에대해 고민하지 않는듯 보였습니다.
하지만 JMX등 자바 플래폼에서 운영 성능 문제해결을 위해 많은고민을 했고 몇가지 툴들을 사용하기 시작하면서
분명 C++에서 고민했던 어떤 문제들은 쉽게 풀어나갔으며 어느부분 , AKKA를통해 자바기술을 어느부분 이해하고 동의하기 시작하였습니다.
결국 극한의 성능 테스트를 통과하고 AKKA를 통한 웹서비스및 모바일 서비스 런칭을 성공하였습니다.
...
이후 다른 목표를 가지고 대부분 순수 JAVA진영 개발자들만이 남게된 프로젝트는 서비스런칭에 성공하지 못했습니다.
목표하는 바가 달랐으며 결과로 결과를 가지고 개발능력을 개발팀 능력을 판단하는게 아니며, AKKA에 대한 순수이해는 자바진영의 개발자들이 분명 더 뛰어났습니다.
기존 서비스개발자가 필요없어도 서비스개발자의 도움없이도 성공할수 있다고 착각을 하고, 진단을 빨리하지 못한게 프로젝트의 실패요인중 하나입니다.
...
기존 서비스개발자가 스스로 새로운 도구를 사용하고 능동적으로 개선하려 하지 안았다면, 아주 어려운일이 될것입니다않았다면, 모두 실패하는 시나리오로 갔을것입니다.
지금은 아마 C++에서도 Actor의 개념을 활용하는 라이브러리가 있을것으로 추측됩니다.
- AKKA 성공사례 (국내최초라고 개발범주에서 국내 최초라고 단언 말할수 있겠습니다만 의미 없습니다. 성공사례보다는 최초 적용사례가 맞을지도 모르겠습니다.)
MS도입 사례
...
소규모 사례는 특수하기때문에 이정도로 언급을 하고, 거대 공룡 MS의 도입사례를 보겠습니다.
...
MS거대 기업이 AKKA의 개발 컨셉을 도입하고 Microsoft 네임스페이스를 네임스페이스에 포함하는것은
아주 놀라운 사실이며, 오랫동안 닷넷 개발을 해온 개발자들도 알고 있지 않더군요
사실일것입니다. 더욱이 해일로 멀티플레이어에서 성공을 했다고 성공사례로 광고까지 합니다.
...
액터개념을 자바/MS가 공식적으로 지구에 정착할수있도록 공식 지원하기때문에지원하며 안정적이기때문에
이제는 더이상 자구를 침략하는 외계 생명체가 아닙니다.
액터도입에 있어서 초기 도입과정 안정성에대한 문제및 플래폼 변경문제를 더이상 겪을 필요가 없습니다.
그냥 하던 개발에, 액터모델지원 라이브러리를 추가만 하면됩니다.
이부분은 아래 내용에서 다시 언급하도록 하겠습니다.
탄생 히스토리
...
최근 몇년간 "분산환경에서 유연한 동시성 개발모델" 이라는 주제하에 이슈가 되고 있습니다.
...
고전 적인 기존 해결방법의 문제점은 대부분 위와같은 상황이 됩니다
자바
자바및 MS 진영에서 우리는 우리의 방식으로 문제를 풀래라고 귀를 닫았으면 AKKA는 탄생하지 못하거나, 액터는 퍼지지못했을것입니다.
다른곳에 귀를 기울이고, 우리가 해결하려고 했던 고전적 방식에 방식의 한계를 느끼고 늦게나마 다른언어에서 좋은 개발모델을 도입하려는 시도를하였으며
...
이때부터 각 언어들이 블록킹이 없는 비동기 프로그래밍의 장점을 홍보하기 시작합니다. 하지만 그기간은 그리 길지 못했습니다.
Lock헬에서 벗어나니, 콜백헬이 우리를 기다리고 있었습니다.
하지만 이보다 더 한참전에 언랭의 언랭-OTP 에서 단순한 비동기처리가 분산환경에서 문제사항으로 지적하였고 콜백지옥이없는 개선작업을 진행하였습니다.
개선모델에대한 연구가 진행되고 있었습니다. 그리고 비동기처리에서 더 추상화된 동시성 처리모델인
액터모델을 제시하였으며 , 여러가지 영향을 끼쳤습니다진영에 영향을 끼치고 있고, 실제로 반영되고 있습니다.
AKKA는 그러한 컨셉을 대부분 참조했다라고 보면 됩니다되며 해결방법에 대해서는 새로운것이 아니라, 기존경험을
잘 참조하고 도구화를 시켜놓았습니다.
문제의 해결법은 단순합니다. 복잡성을 최대한 제거하는것만이 분산환경에서 서비스를 분산환경에서 서비스를 올바르게 설계할수 있다입니다.
왜냐? 분산처리는 그 자체만으로 복잡하기때문에 개발방법을 단순화할 필요가 있습니다.
또한 기존 솔리드형태의 웹서비스는 분산환경 즉 AKKA와 어울리기 어려운 웹환경으로 판단하고
이와동시에 이와 동시에 https://www.playframework.com/ 라는 마이크로서비스에 적합한 웹서비스도 같이 준비했습니다.
MS진영
그러면 그러면 MS진영은 어떠한 활동을 했을까요? 닷넷프레임워크가 대부분 자바의 장점을 가지고 가려고 노력을하며
실제로 그렇게 합니다. 하지만 아무리 유명해도 선별을 하며 결코 함부로 microsoft 네임스페이스에 포함시키지 않습니다.
적어도 띄어난 개발팀이 어떠한 네임스페이스를 담당하고 지속적으로 관리하고 있고 성과가 있을때 포함이 됩니다 포함이되고 유지가됩니다.
더욱이 새롭게 생긴다는것은 그것이 자신들한테 없던것이며, 오픈진영에서 개발을 했던것을 인정하고 금전적인 지원을
통해 자신의 프레임 워크 속으로 포함시킵니다. 이러한 점에서는 자바진영과는 다르게 닷넷프레임워크는 조금더
조직적으로 유지되고 관리되고 있다란 점입니다. 장점이자 단점이지만, 탈 윈도우라는 오픈진영까지 인정하고
모노프로젝트 도입 이후부터 MS가 올바른 길로 가는듯 보입니다.
MS진영에서는 액터모델에 대응하기위해 orleans 이라는 프로젝트를 공식적으로 진행하고 있으며, akka의 지원 스택과 유사합니다.
저의 플래폼 예상이 항상맞지는 않으나~ 언젠가 닷넷 프레임워크에 기본으로 탑재를 시킬듯도 보입니다.
또한 MS역시 IIS형태의 솔리드 솔리드형태의 웹 서비스가 스케일아웃이되는 분산환경에 적합하지 않을것으로 이미 결론을 내리고
http://owin.org/ 라는 오픈형 웹서비스를 MS가 개발팀을사고 닷넷프레임워크에 지원하고 닷넷프레임워크에 공식적으로 녹였습니다.
오픈프로젝트는 별개로 진행되고 있으며, asp.net 개발자도 잘모르더군요
microsoft.iis.host 같은 IIS종속적인 네임스페이스를 개선하고 있지만
닷넷 개발자도, asp.net에서도 기본 사용되는 호스팅이 더이상 iis.host가 아니고 오픈소스에서 기원했다란 사실을 인지하는
사람은 잘 없더군요...., asp.net이 리눅스에 돌게끔 이전부터 준비를 해온듯 합니다.vs 2015에서 asp.net 프로젝트 생성하면 기본으로 owin.host 기반으로 작동중인 사실을
owin.host의 탄생배경은 윈도우/IIS탈출을 통한 마이크로 웹서비스였으며웹서비스 지향에 있으며 오픈프로젝트로 시작한 네임스페이스입니다.,
MS에서도 실제로는 이제 iis종속적인 웹서비스의 웹호스팅의 한계를 느끼고 여기에 더 많은 지원이 이루어지고 있습니다.
이것은 어떤 의미냐고하면, 아무런 생각없이 만든 vs2017 부터는, 그냥 공식적으로 리눅스에 작동하는 asp.net 서비스가 리눅스에도 돌아갈수 있음을 의미합니다이라는 프로젝트 템플릿이 있습니다.
이야기가 돌아 웹서비스로 웹서비스 까지 갔지만 , 다시 본론으로 돌아와돌아가겠습니다.
우리가 가야할길
...
어쨋건 Actor개념은 언랭에서 나왔으며, Actor모델 지원은 각 진영에서 가진 프레임워크에서 아주 중요하게 생각하고
...
분산환경 비동기처리를 유연하게 하기 위해 AKKA일 필요는 없습니다. AKKA는 툴이며 AKKA는툴이며
ACTOR는 단순화된 개발모델입니다.
다른 툴로도 ACTOR모델을 사용하면 되며, 또한 궁극적으로 ACTOR일 필요도 없습니다.
전통적인 개방방법의 문제점을 인지하고, 그것을 개선하는 그 어떤것이면 충분합니다.
다만 AKKA가 제공하는 스펙이 무엇이고 내가가진 구현능력으로 커버가 가능한 부분인지 확인은 필요해보입니다.
이에 준하는 개발모델을 미리 익혀두고 대비해두는것
능동적으로 개발모델을 개선하지 않는다고 하면 새로운 개발 모델을 배울필요가 없습니다.
액터는 능동적으로 적용하지 않으면, 성공할수 없습니다.
비능동적으로 완성된 어떠한 메시지큐 서비스를 이용하는게 적합하다라고하면
그것을 통해 성공적인 서비스를 해도 무관합니다.
부분이
어디까지인가 비교과정은 한번쯤 해보는걸로 추천합니다.
각 하지만 각 주요 플래폼 개발 진영에서 서비스 해도 문제없을만큼 성공 사례와 문서및 샘플을 준비 해놓았으며
개발자에게 능동적으로 분산환경을 직접 설계할수 있는 기회를 줬다라고 생각하며, 이 기회를 놓치면 안된다라고 생각합니다.
클라우드의 어떠한 원클릭서비스가 직접 개발한것보다 분산환경에서 더 좋은 서비스를 줄려고 노력할것이며
우리의 개발 영역을 침공을 하려할것입니다. 그것을 잘 사용하는 방법도 실시간-스트리밍 방식이여야 할것입니다..
그것을 자각하지 않는다면 우리는 이제 데브옵스에게 분산환경 설계에있어서 메인키를 뺏기게 될지도 모릅니다.
데브옵스는 원클릭으로 그러한 서비스를 만들고 연결을 시킬 준비가 끝나있고, 우리 개발자는 아직도 고전적인 폴링방식에서
벗어나지 않으려고 할테니까요...(그것이 잘못되었다란 의미가 아니고, 그것만을 통해 해결을 하려는것을 의미합니다.)
이런의미에서 기회를 놓치면 안된다고 생각한것입니다.
객체 지향을 거쳐 비동기프로그래밍에 이은 액터프로그래밍은 새로운 개발 패러다임이 되지 않을까? 추측해보며
...
아래 링크를 통해 각 진영에서 어떻게 프로젝트가 진행이 되고 있고
내가 위치한곳은 어디며? 필요한것인지?정도는 필요한것이 무엇인지 파악을 하는데 도움이 되었으면 좋겠습니다.
...
링크들
...
Actor지원 개발 툴킷: 자바,닷넷진영
- http://akka.io/
- http://getakka.net/
- https://www.microsoft.com/en-us/research/project/orleans-virtual-actors/
- https://dotnet.github.io/orleans/
확장에 용이한 마이크로 웹서비스: 웹서비스를 한곳에 몰아넣고, 내부에서 추가삭제가 용이한 솔리드 형태와 반대성격입니다작은단위로 웹서비스를 배포하고 StandAlone으로 실행시키는 컨셉입니다.
- https://www.playframework.com
- http://owin.org/ ( http://nancyfx.org/ ) https://docs.microsoft.com/en-us/aspnet/core/fundamentals/owin
기타: c++ python node.js 등 주요 메이져 언어에서도 actor를 지원하려는 움직임이 구글링을 통해 포착이됩니다.
이것이 작동되는지 확인을 위해 파이썬에서도 액터를 사용해 보았습니다. 팀에서 파이썬 사용할 일이 생길거같아 파이썬을 처음 설치해보고 시도한것입니다..
.net환경에서 AKKA 사용하기 : 개인적으로 문서화 진행중입니다.