빠른 개발 vs 미래대비 개발
빠르고 안정적인, 미래지향적인 서비스를 만드느냐, 스케줄을 맞추느냐.
요즘 개발을 하다 보면 많이 느끼는 부분이, 추후 서비스 운영을 생각했을 때 과연 최소한의 리소스로 최대한의 운영이 가능한지/대규모에 대한 대비가 가능한지에 대해서 이다. 그 부분이 내가 마이크로아키텍처를 선택한 이유이기도 하고, 도커 등을 사용해서 사용하는 리소스의 스케일을 global에 맞춰 자동적으로 밸런싱 한다면, 실상 서버 확장이나 co-location등에 대한 걱정은 없을 것이니깐. 그래서 사실 지금까지 보면 AWS, GCE등의 클라우드 서비스를 정말 잘 쓴다면, 기존의 bear-metal 서버를 이용했을 때보다는 훨씬 더 안정적이면서 동시에 비용대비 리소스 효율을 극적으로 끌어올리면서, 가장 좋은 것은 진정한 의미에서의 devops를 위한 development/operation flow가 설계가 된다는 것이다.
여기서 진정한 의미란 최소한의 개개인이라고 할까, 나는 그렇게 생각한다. 지금 나의 경우는 나름 글로벌한 서비스를 만든답시고 정말 이리저리 서비스 아키텍처에 대해 고민을 한두번 한 것이 아니다. 웹이라는 서비스가 그러하듯, 서비스의 구조가 어떻게 되냐에 따라 병목이냐 아니냐가 나뉘게 된다. 내가 생각하는 웹의 가장 중요한 요소는 '속도'이기 때문에, 병목을 최소화 하는 것은 게임개발을 할 때에 멀티코어나 GPU 연산을 최대로 끌어올리는 것과 비교될 정도로, 중요한 요소 중 하나다.
허나 여기서 더 나아가, 스타트업을 운영하기 때문에 비즈니스적 요소를 빼놓을 수는 없다. 즉, 비용과 스케줄, 보안, localization, 법적 이슈 등에 대해서 어쩔 수 없이 고려를 하게 된다. 특히, 비용적 측면에서 보면 클라우드, 정확히 말해 IaaS를 쓴다는 말은 auto-scaling의 성능에 기대 서버 설치의 유연성을 높인다는 의미일 것이다. 그렇다고 AWS의 ELS를 쓴다는 것은 글쎄, 솔직히 비용 대비 스타트업이 시작하기에는 약간은 무리가 있지 않은가 싶다. (물론 1년 credit이 있긴 하지만) 그래서 나는 대안책으로 Google Cloud를 약 3년전부터 사용해 왔고, 지금은 본격적으로 Kubernetes를 이용한 docker orchestration 을 하고 있다.
Google Cloud가 나온 김에, 잠깐 내가 사용/생각/설계 한 '빠른개발'에 대한 내용을 언급해본다. (개발자가 아닌 분들은 Skip) 특히 마이크로아키텍처쪽의 구글의 투자는 정말로 주목할 만 하다. Kubernetes의 그 쉬운 사용방법에 솔직히 반했었는데(아마존의 ECS는 글쎄.. 아직은 너무 조잡하다고 느낀다.) 일단 아직까지는 VM이 4대 정도라서 빠른지는 모르지만, 테스트해본 결과 yaml을 통한 replica등의 scale up/down은 매우 빠르게 돌아간다. docker의 private repositories부터 해서, yaml파일에서의 버전 조절을 통한 배포까지의 과정은 지금까지는 너무나도 순조롭게 돌아간다. 자세히 말하자면, Hotfix로 간단한 수정의 경우에도 pods(Kubernetes내의 docker image pool) 의 destroy / recreate 의 과정이 경험한 바로는 10초 이내로 이뤄지고, 무엇보다 connection이 최소인 서버부터 순차대로 배포가 진행되므로 continuous deployment가 가능하다.
개발에 있어서 가장 중요한 것은, '유저'를 생각하는 것이 아닐까. 나도 매번 개발하면서 사실 서비스의 UX와 기능적 측면을 가장 중요시 하면서도 동시에 아직까지는 '엔지니어'의 피가 흐르는지 속도에 참으로 민감하다. 아직까지는 와이프가 가장 큰 QA이지만, 그녀에게서 '빠르다' 라는 얘기를 들으면 그렇게 좋을 수가 없다. 하지만 향후 유저가 100명, 천명, 만명 그렇게 증가했을 때도 과연 빠른 서비스 운영이 가능할까.
그런 생각때문에 Rapid Prototyping이 정말로 힘든 것 같다. 솔직히 UX나 뭐 아키텍처 하나도 고려 안하고 원래 하던 방식대로 (아주 고전적으로) Spring/MyBatis/Velocity 등으로 개발하면 금방금방 할텐데.. SI시절 모아둔/사용하던 라이브러리도 아주아주 많으니깐. 아니면 MEAN이던 LAMP던 JSP던... HTML내에 이리저리 백엔드 코드를 붙혀 만든다면 금방금방 할텐데 말이다.
하지만 스스로 그런 코딩은 지향하고 있고, 무엇보다 최근의 경향과 맞지 않는다. 무조건 미래적으로 보면 병목이 생길 것이 분명하다. 그래서 Async가 베이스인 Play Framework/Scala를 역시나 3년전부터 열심히 써오려고 노력했고, Slick등의 DB라이브러리가 또 한번 열심히 내 전통적 RDB구조를 깨지 않는 선에서 비동기화를 지원 아닌 지원한다. (RDB 자체에서는 비동기스럽지 않지만..) Async가 기반이 되다 보니 백엔드도 그리 느리다는 생각이 들지 않고, 어쨋든간에 할당적 측면에서 백엔드의 async pool에 task가 몰리면 그 만큼 container의 할당량도 높아지니 쉽게 utilization의 측정이 가능하다. 그래서 로드 밸런서에서도 역시나 쉽게 scale up을 할 수 있는 장점이 있는 동시에, 약간 더 그런 checking주기를 높인다면, 보다 더 유연한 대비가 가능하게 되니 역시나 대규모에 대한 대비가 가능하다고 본다. 한편으론 DB자체도 replica를 통해 insert/select의 구분으로 나름 빠르게 느껴지고, 역시나 대규모에 대한 '대비'가 가능하다. 역시나 구글 클라우드에서는 rdb의 replica 를 UI로 쉽게 지원한다.
여기까지는 코딩이나 프레임워크적 측면이고, 다시 Kubernetes로 넘어가면 이런 play framework 나 AngularJS(요즘엔 앵귤러 개발에 푹 빠져있다.) 를 기반으로 NodeJS/Express를 기반으로 패킹해 두었는데 이 또한 container로 지원되면 쉽게 Kubernetes에서 ip expose를 통한 Google Cloud Load Balancer에 세팅이 된다.
하지만 문제는 이제 글로벌하게 고려해 봤을 때는 로드밸런서 설정이 더 복잡해진다. 더 이상 Kubernets나 구글 클라우드의 UI를 사용한 자동적 기능으로는 한계가 존재한다. 오늘 내가 직면한 문제는, 최근 Google Cloud가 Cloud CDN을 제공하게 되었는데 이게 일단 인스턴스가 여러개의 존재 똑같이 존재한다 하더라도 그들을 묶어둔 어떠한 group을, global영역의 ip가 감지해서 다시금 해당 region의 ip로 proxie해주는 방식이다.
https://cloud.google.com/compute/docs/load-balancing/http/content-based-example위처럼 content-based load balancing을 지원하기도 하고,
https://cloud.google.com/compute/docs/load-balancing/http/cross-region-example위처럼 cross-origin based load balancing을 지원하기도 한다.
어쨌든 좋다. 들리기에는 참으로 매력적으로 들린다. 하지만 단점도 있다. 아직까지는 Kubernetes를 통한 자동적으로 생성된 Load Balancer의 경우는, TCP기반이라(layer 4 기반) HTTP(S) 기반인 위의 로드밸런싱은 아직까지는 적용할 수 없다. 이를 위해서는 결국 layer 7(HTTP프로토콜) 을 Kubernetes의 서비스로 끌어당겨야 하는데, 그 부분에서 막혔다. (방법은 있을테다. 월 $150 주고 silver 서비스 지원 서비스를 받고픈데 아직 고민이다...) 사실 보안적 측면을 고려하면 SSL도 적용해야 하는데, 구글에서 쉽게 하려면 역시나 HTTP프로토콜 내에서 적용을 해야 하는데 이 또한 로드밸런서 내에 있어야 할지, 백엔드(Netty/Node.js)내에 있어야 할지도 아직도 막막하고..
뭐 사실 이야기가 어떻게 보면 개발쪽으로 많이 샜는데, 여기서 핵심은 계속 이렇게 '미래대비' 개발이라고 할까, 이러다 보니 마일스톤 대비 진도가 나가지 않고 계속해서 문제점이 발생한다. 스타트업의 가장 큰 핵심은 빠른 개발이라고 생각했는데, 사실 안정적인 서비스가 나오지 않는다면 그게 실제로 오픈을 했을 때 무슨 소용이 있을까 싶기도 하고.. 결론은, 빠른 개발과 미래대비 개발에 대한 밸런싱을 맞추는 수 밖에 없다. 이를 위해서 지속적으로 공부해 나갈 수 밖에 없고..
요즘 스타트업을 운영하면서 생각지도 못한 paperwork가 너무나도 많다. 미래대비 개발이란 그런 것 같다. 예상치는 못하겠지만, 결국엔 안정성을 위해서는 꼭 필요한 존재. paperwork라고 해서 다를 것이 무엇이 있겠는가. 어쨌든, 무엇이든지 간에 일정급 이상은 준비하고 만들어야 하는 것이 스타트업의 서비스인 것 같고, 그렇게 하지 않는 이상 사실 하지 않는것 만큼 못하다는 생각이다. 그래도 일정은 최대한 줄여야지.. 하는 이상한 한국적 마인드(?)도 있는 것도 사실이긴 하지만 :)
IT 세상은 발전하고, 좋아지지만 공부할 것이 너무나도 많은 것 같다. 이렇게 열심히 대비를 해놓는다 하더라도 유저가 없을 수도 있고, 문제점은 어디서든 발생할 수 있다. 하지만 소 잃고 외양간 고치지 말고, 최대한 개발자 혹은 devops로써의 프라이드(?)가 있는 한은 최대한 내 힘껏 공부해서 안정적이고 빠른 서비스를 만들어보리라 라는 포부를 품어본다.
