Page History
AKKA 는 복잡한 분산개발환경에서,어렵게 개발했던것을 단순화해 드립니다라고 광고를 합니다.
그 복잡성을 줄이는 것에대해 설명하기위해서는 여러가지 구체적인 예시가 뒤따라야하고
더 추상적인 요소에대한 설명도 필요하며, 같은 의미로 동의를 구해내기도 어렵습니다.
개발자의 기존 개발 습관을 바꾸기도 어렵습니다. 하지만 AKKA를 배우면서 느낀것은 그것이였습니다.
저의 전통적이 개발방식을 꼬집고 설명하고 구체적인 예를 들면서 저의 개발 습관을 바꾸려고 드는것입니다.
그런데 한참 학습하다보니 중요한 사실을 뒤늦게 깨닫게 됩니다. 분산 개발환경속에서 그것을 이용하고 흉내내는 개발을 하였지만
진정 분산 개발환경을 직접 설계하고 구성하고 확장을 하는 개발을 해본적이 없다란 것입니다.
애시당초 AKKA와 대화할 준비가 안되어있는 상태였습니다. 하지만 AKKA는 친절하게 그러한 분산환경에서 필요한 백그라운드 지식에대해
한참을 설명을 합니다. 오히려 이것에 대해 이해를 시키기위해 코드보다 더 많은 설명을 합니다.
그리고 그것은 AKKA종속적이지않는 분산 개발환경에서 공통적으로 알아야하고 풀어야하는 모델을 제시해시해주며
Akka와 유사한 목적을 가진 다른 플랫폼, 공통적으로 Reactive라는 단어를 공통적으로 언급합니다.
다른 플랫폼에서도 분산처리를 위해 필요한것에대한 코어 컨셉설명을 똑같은 전개로 이야기를 하고 있습니다.
AKKA를 배우고 나면 분산개발환경에서 액터모델 도입이 우리랑 맞지도 않고 해야할필요도 없다란
결론을 낼수도 있습니다. 하지만 그 결정에 도달했을때 고전적인 개발방법의 한계와
분산처리 시스템에서 필요한 개발 컨셉을 배울것으로 기대해봅니다.
AKKA 도입 여부 결정은 뒤로 미루고 단지 제가 팀내에서 경험한 사소한 이야기와
메이져에서는 어떠한 일들이 벌어지고 있는지 간단하게 소개하려고 합니다.
필자의 개발팀에서의 적용사례
...
이전 개발팀에서 AKKA적용스토리를 잠깐 이야기 해보겠습니다.
4년전 분명 C++이 메이져인 우리개발팀에서 SCALA와 더불어 AKKA 플래폼 사용을 결정하였습니다.
고집스러운 C++ 개발자에게 이러한 민주주의방식으로 자바기술을 선택한다는것은 아주 어려운 과정이였습니다.
- 웹서비스로의 도약을 위해 자바혹은 닷넷이 필요하며, C++은 개발자 구하기가 어렵다
- 개발자의 대부분은 웹개발자이며 , 저수준 TCP패킷처리를 통해 서버개발을 할수 없으며 무엇인가가 필요하다.
- SCALA/AKKA 가 그러한 서버 기술에대해 평준화되는 무엇인가를 준비해 놓은것같으니 팀에서 배우고 준비하자
간단하게 요약하면 위 3가지 스텝으로 결정이 되었으며 서버개발에 있어서 자바 개발자를 유입시키기 시작했습니다.
어떠한 개발자에게는 이것은 지구를 침략하는 외계생명체와 같았으며, 관련 자료도 찾기힘들었습니다.
적어도 국내에서 언급조차 안되던 시기였으니까요 , 실제로 이과정에서 c++노선을 유지하여 팀을 떠나
더 잘되신 분도 계십니다.
JAVA진영에서 외치던 그 플래폼을 결국 C++진영에서 JAVA를배워 가며 AKKA를 통해 기존 서비스를 바꾸는 프로젝트가 진행이되었습니다.
이 과정중, 자바에서 대용량 웹소켓을 액터와 연결하고 트래픽 테스트를하고 검증하는 과정을 오히려 팀내 자바 진영에 가르키기 까지 했으며
안정적인 버젼조합에 대해 공유를 하였습니다.( 네티 + 앱모스피어 + 액터 + 스칼라버젼 + PLAY + AKKA : 초기버젼에서 안정적인 라이브러리
조합을 찾기란 거의 헬이였습니다. 마치 옛날옛적 컴퓨터 조립할때 안맞는 구성으로 작동이안되는 시절이 있었듯이 )
이 과정에서 실제 이름을 대면 유명한 자바개발자 라고 소개받고 문제해결에 그분야에서 도움움을 주는 포지션에 있었지만
큰 도움을 받지 못했습니다. 동접 천명 서버한대에서 1주일간 버티기에대한 해결과정은 플래폼을 뛰어넘는 과정이였기때문입니다.
GC작동에대한 JAVA 6/7 의 차이를 오히려 C++ 개발팀 진영에서 검증하기 시작했습니다. 적어도 이때는 생명주기가 다한
Data를 직접 메모리 해제를 해야안심을 하는 C++개발팀은 자바에서의 자동처리되는 객체를 대부분 의심했습니다.
팀내 자바개발자는 JVM을 믿고 잘 사용하기 때문에 이러한 문제에대해 고민하지 않는듯 보였습니다.
하지만 JMX등 자바 플래폼에서 운영 성능 문제해결을 위해 많은고민을 했고 몇가지 툴들을 사용하기 시작하면서
분명 C++에서 고민했던 어떤 문제들은 쉽게 풀어나갔으며, AKKA를통해 자바기술을 어느부분 이해하고 동의하기 시작하였습니다.
결국 극한의 성능 테스트를 통과하고 AKKA를 통한 웹서비스및 모바일 서비스 런칭을 성공하였습니다.
극한의 성능테스트 링크에서 이것이 실제로 일어난 일임을 확인할수 있습니다. ( 당시 로드 테스트 목표및 결과에대한 정보도 포함 )
이후 다른 목표를 가지고 대부분 순수 JAVA진영 개발자들만이 남게된 프로젝트는 서비스런칭에 성공하지 못했습니다.
목표하는 바가 달랐으며 결과를 가지고 개발팀 능력을 판단하는게 아니며, AKKA에 대한 순수이해는 자바진영의 개발자들이 분명 더 뛰어났습니다.
기존 서비스개발자의 도움없이도 성공할수 있다고 착각을 하고, 진단을 빨리하지 못한게 프로젝트의 실패요인중 하나입니다.
고집스러운 C++ 개발자가 언어를 뛰어넘는 기술을 받아들이고 그것을 이해하려는 능동적인 활동에 의미를 두겠습니다.
기존 서비스개발자가 스스로 새로운 도구를 사용하고 능동적으로 개선하려 하지 않았다면, 모두 실패하는 시나리오로 갔을것입니다.
- AKKA 성공사례 (개발범주에서 국내 최초라고 단언 말할수 있겠습니다만 의미 없습니다. 성공사례보다는 최초 적용사례가 맞을지도 모르겠습니다.)
MS도입 사례
...
소규모 사례는 특수하기때문에 이정도로 언급을 하고, 거대 공룡 MS의 도입사례를 보겠습니다.
국내 중견개발 기업의 사례가 있으면 더 좋겠지만, 커뮤니티 활동에서 찾기 힘들더군요
MS거대 기업이 AKKA의 개발 컨셉을 도입하고 Microsoft 네임스페이스에 포함하는것은
아주 놀라운 사실이며, 오랫동안 닷넷 개발을 해온 개발자들도 알고 있지 않더군요
더욱이 해일로 멀티플레이어에서 성공을 했다고 성공사례로 광고까지 합니다.
액터개념을 자바/MS가 공식적으로 지구에 정착할수있도록 공식 지원하며 안정적이기때문에
이제는 더이상 자구를 침략하는 외계 생명체가 아닙니다.
액터도입에 있어서 초기 도입과정 안정성에대한 문제및 플래폼 변경문제를 더이상 겪을 필요가 없습니다.
그냥 하던 개발에, 액터모델지원 라이브러리를 추가만 하면됩니다.
이부분은 아래 내용에서 다시 언급하도록 하겠습니다.
탄생 히스토리
최근에는 AKKA자체의 장점을 주위 사람에게 소개해주고 있지만, 성공사례가 있는지? 들어보긴했는데 그걸 왜 배워라던지?
설득하는데는 어려움에 있습니다. 오히려 비개발자가 AKKA란 단어를 더 잘알고 있습니다.
국내에서 성공사례가 잘없고 운영서비스 자체에 대부분 분산 처리 뿐아니라 실시간 처리 장치조차 없으며,
...
...
최근 몇년간 "분산환경에서 유연한 동시성 개발모델" 이라는 주제하에 이슈가 되고 있습니다.
언랭-OTP / GO언어등 직접 서비스에 녹인 성공사례가 많이 나오고 있으며, 성공사례의 이면을 살펴보면
고전적인 기존 언어및 프레임워크 그리고 고전전인 해결방법의 문제점을 철저하게 분석하고 새로운 개발 모델을 제시했다란점입니다.제시하고 성공사례로 이어졌다란것입니다.
- 요구사항대비 자원이 증가하는 경유
- 자원이 증가하여 복잡도가 증가하는 경우
고전 적인 기존 해결방법의 문제점은 대부분 위와같은 상황이 됩니다
자바
자바및 MS 자바및 닷넷프레임워크 진영에서 우리는 우리의 방식으로 문제를 풀래라고 귀를 닫았으면 AKKA는 탄생하지 못했습니다못하거나, 액터는 퍼지지못했을것입니다.
다른곳에 귀를 기울이니기울이고, 우리가 해결하려고 했던 방식에 문제를 고전적 방식의 한계를 느끼고 늦게나마 외부언어에서 다른언어에서 좋은 개발모델을 도입하려는 시도가 있었습니다.
자바 진영에서는 심지어 SCALA라는 새로운 언어를 만들고 JAVA와 AKKA를 동시에 사용할수있는 프레임워크도 만들었습니다.
시도를하였으며
그 이전에 자연스럽게 순수한 프레임워크 차원 에서 asyn,task 와 같은 키워드지원으로 멀티스레드의 복잡성에서 먼저 해방이됩니다.
이때부터 각 언어들이 블록킹이 없는 비동기 프로그래밍의 장점을 홍보하기 시작합니다. 하지만 그기간은 그리 길지 못했습니다.
Lock헬에서 벗어나니, 콜백헬이 우리를 기다리고 있었습니다.
이보다 더 한참전에 언랭-OTP 에서 단순한 비동기처리가 분산환경에서 문제사항으로 지적하였고 콜백지옥이없는
개선모델에대한 연구가 진행되고 있었습니다. 그리고 비동기처리에서 더 추상화된 동시성 처리모델인
액터모델을 제시하였으며 , 여러가지 진영에 영향을 끼치고 있고, 실제로 반영되고 있습니다.
AKKA는 그러한 컨셉을 대부분 참조했다라고 보면 되며 해결방법에 대해서는 새로운것이 아니라, 기존경험을
잘 참조하고 도구화를 시켜놓았습니다.
문제의 해결법은 단순합니다. 복잡성을 최대한 제거하는것만이 분산환경에서 서비스를 올바르게 설계할수 있다입니다.
왜냐? 분산처리는 그 자체만으로 복잡하기때문에 개발방법을 단순화할 필요가 있습니다.
또한 기존 솔리드형태의 웹서비스는 분산환경 즉 AKKA와 어울리기 어려운 웹환경으로 판단하고
이와 동시에 또한 기존 솔리드형태의 웹서비스의 한계를 느끼고 https://www.playframework.com/ 라는 새로운 마이크로서비스에 마이크로서비스에 적합한 웹서비스도 같이 준비했습니다..
MS진영
그러면 MS진영은 어떠한 활동을 했을까요? 닷넷프레임워크가 대부분 자바의 장점을 가지고 가려고 노력을하며
실제로 그렇게 합니다. 하지만 아무리 유명해도 선별을 하며 결코 함부로 microsoft 네임스페이스에 포함시키지 않습니다.
적어도 띄어난 개발팀이 어떠한 네임스페이스를 지속적으로 관리하고 있고 성과가 있을때 포함이되고 유지가됩니다.
더욱이 새롭게 생긴다는것은 그것이 자신들한테 없던것이며, 오픈진영에서 개발을 했던것을 인정하고 금전적인 지원을
통해 자신의 프레임 워크 속으로 포함시킵니다. 이러한 점에서는 자바진영과는 다르게 닷넷프레임워크는 조금더
조직적으로 유지되고 관리되고 있다란 점입니다. 장점이자 단점이지만, 탈 윈도우라는 오픈진영까지 인정하고
모노프로젝트 도입 이후부터 MS가 올바른 길로 가는듯 보입니다.
MS진영에서는 MS진영에서도 액터모델에 대응하기위해 orleans 이라는 프로젝트를 공식적으로 진행하고 있으며, akka의 지원 스택과 유사합니다.
저의 플래폼 예상이 항상맞지는 않으나~ 언젠가 닷넷 프레임워크에 기본으로 탑재를 시킬듯도 보입니다.
또한 MS역시 IIS형태의 솔리드 솔리드형태의 웹 서비스가 스케일아웃이되는 분산환경에 적합하지 않을것으로 이미 결론을 내리고
http://owin.org/ 라는 오픈형 웹서비스를 MS가 개발팀을사고 닷넷프레임워크에 지원하고 닷넷프레임워크에 공식적으로 녹였습니다.
오픈프로젝트는 별개로 진행되고 있으며 asp.net 개발자도 잘모르더군요 microsoft.iis.host 같은 IIS종속적인 네임스페이스를 버린지 오래되었으며
닷넷 개발자도, asp.net에서도 기본 사용되는 호스팅이 더이상 iis.host가 아니고 오픈소스에서 기원했다란 사실을 인지하는
사람은 잘 없더군요...., asp.net이 리눅스에 돌게끔 이전부터 준비를 해온듯 합니다.
owin실제 asp.net은 owin.host 기반으로 작동중인 사실을 owin.host의 탄생배경은 윈도우/IIS탈출을 통한 마이크로 웹서비스였습니다.
이것은 어떤 의미냐고하면, 아무런 생각없이 만든 asp.net 서비스가 리눅스에도 돌아갈수 있음을 의미합니다. 윈도우/IIS가 아니어도 된다란 의미입니다.
웹서비스 지향에 있으며 오픈프로젝트로 시작한 네임스페이스입니다.,
MS에서도 실제로는 이제 iis종속적인 웹호스팅의 한계를 느끼고 여기에 더 많은 지원이 이루어지고 있습니다.
vs2017 부터는, 그냥 공식적으로 리눅스에 작동하는 asp.net 이라는 프로젝트 템플릿이 있습니다.
이야기가 돌아 웹서비스 까지 갔지만 , 다시 본론으로 돌아가겠습니다.
우리가 가야할길
...
...
어쨋건 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/
- 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 사용하기 : 개인적으로 문서화 진행중입니다.
분산환경 동시성처리를 위해 Actor가 유일한 개발모델이 아니며, 언젠가 Actor모델의 단점을 지적하는 새로운
개발모델이 나올수도 있습니다. "코딩을 통해 서비스를 만드는것은 잘못되었다. 개발자의 수준을 못믿기때문에
우린 클라우드로 원클릭을 통해 서비스를 설계한다" 이러한 시대가 언젠가는 분명 올것입니다.
다만 액터모델은 자바/MS진영에 서 공식적으로 지원하는 개발 모델이며
분산환경에서의 서비스 설계를 개발자가 직접할수있게 고차원적인 라이브러리를 제공해준며
응용서비스 레벨에 이것을 직접설계하는것은 필요한 부분입니다.
하지만 이것에 유연하게 대응하지 않고 있다면, 우리가 만드는 서비스는 고작 DB호출만 하거나 API만 호출을
하는게 다이며 CPU의 대부분은 그것을 기다리는쓰고 , 트래픽의 대부분은 고정적인 리소스(이미지,텍스트)
...