마이크로 서비스 아키텍처와 개발문화
Micro Service Architecture
바야흐로 마이크로 서비스 아키텍처Micro Service Architecture, 이하 'MSA' 시대다. 우리나라의 개발 환경이 자바(Java)로 물들기 전, 직접 메모리 관리도 못하는 언어로 무슨 프로젝트를 하냐고 말하는 시대가 있었다. 하지만, 시대가 변해 자바 진영에서 스프링 프레임워크(Spring Framework)를 필두로 웹 서비스 프로젝트를 쏟아내게 되었다. 바로, 닷컴버블 직후 시절의 이야기다. 이후, 전자정부 프레임워크에서 스프링을 채택하게 되면서 SI업계System Integration, 주로 외주업체가 의뢰를 받고 웹 서비스 등을 개발하는 방식에서는 자바와 스프링이 주된 기술 스택Tech Stack, 개발언어나 프레임워크 등을 정한 규격으로 쓰였다.
MSA를 이야기하는데 어째서 스프링 이야기가 나온 걸까? 그건 바로 스프링 개발 환경에서 MSA를 지원하기 시작했기 때문이다. 컨테이너(Container) 기반의 쿠버네티스Kubernetes, 이하 'K8S' 상에 스프링부트Springboot, 스프링 프레임워크를 실행만으로도 사용할 수 있게 한 컴포넌트를 올리고 MSA를 구현할 수 있으며, 넷플릭스(Netflix)가 오픈소스로 공개한 스프링 클라우드(Spring Cloud)를 통해 MSA를 구현할 수도 있게 되었다. 우리나라의 대부분의 기업용 웹 서비스 환경이 스프링 기반이라는 걸 생각하면 그 파급력은 우리나라의 개발 환경 전체의 변화를 의미한다고도 할 수 있다.
마이크로 서비스 아키텍처 이해하기
<그림 1> 모놀리식 vs 마이크로 서비스 아키텍처(Tom Hardin, 2018)그렇다면 MSA는 무엇일까? 한 마디로 말하면, 각 중요 기능별 작은 서비스를 만들고 이를 유기적으로 엮어서 하나의 시스템을 통합하는 방식이다.
기존의 웹 서비스는 <그림 1>의 왼쪽 그림처럼, 비즈니스 로직, 데이터 베이스(DB), 사용자 인터페이스(UI) 처리가 모두 한 곳에서 이루어졌다. 이런 방식을 모놀리식(Monolithic) 구조를 가진다고 하며, 주로 소규모 시스템의 경우 빠른 구축과 관리를 할 수 있다는 장점을 가진다. 하지만, 서비스가 확장되고 이미 커질대로 커진 시스템의 경우 여러 측면에서 모놀리식 아키텍처의 한계가 드러나기 시작했다. 예를 들어, 모놀리식 방식에서는 더 많은 요청이나 부하에는 더 좋은 성능의 서버를 사용하는 방식인 스케일 업(Scale up) 방식으로 주로 대처하곤 했다. 고성능의 서버로 교체하는 방식에 한계가 오면, 서버 여러 대를 추가하는 방식인 수평 확장 방식을 사용해야 하는데 시스템 전체를 스케일 아웃(Scaling out) 할 수 밖에 없는 등 한계점이 있었다. 또한, 하나의 시스템 구성 요소에 문제가 생겨도 전체 시스템에 영향을 주는 경우가 많았고, 이 때문에 테스트와 배포에도 많은 시간과 자원이 소모됐다.
클라우드 컴퓨팅이 대중화 되고, 서버 인스턴스를 격리시킬 수 있는 도커(Docker)와 인스턴스(Instance)를 관리할 수 있는 오케스트레이션(Orchestration) 도구인 K8S가 등장했다. 스프링 진영에서는 스프링 부트와 스프링 클라우드를 지원하기 시작했다. MSA가 자라날 환경이 조성된 것이다. MSA 환경 아래에 각 서비스가 별도의 인스턴스에서 처리되면서, 서비스 별 배포와 테스트가 가능해졌으며, 부하나 장애에 있어서도 전체 시스템이 아닌 각 서비스 별 대응이 가능하게 되었다.
마이크로 서비스 아키텍처가 가져올 변화
주요 항목을 중심으로 어느새 성큼 우리에게로 다가온 마이크로 서비스 아키텍처가 앞으로의 개발환경에 어떠한 영향을 미칠지 정리해보았다.
1. 개발문화의 변화
Spring Camp 2018 세션에서 가장 인상 깊었던 말 중 하나는 기존의 보수적인 개발 문화를 짚는 한 마디였다.
나의 과감한 수정은 전사적 장애를 유발한다(윤용성, 2018).
이 말처럼, 기존의 개발 문화를 잘 설명하는 말이 없다. 팀원 모두가 개발 환경을 통일 시켜야 하고, 통일된 환경안에서도 조금만 잘못되면 전사 레벨의 장애로이어지는 시스템 속에서 어떤 개발자가 혁신을 이끌어낼 수 있을까? 사실 MSA를 기술적으로만 살펴본다면, 기존보다 성능적으로 나은 부분을 그래프로 보여주거나 이전에는 할 수 없었던 새로운 기능 몇 개가 추가된 것으로 끝날 것이다. 하지만 대규모 개발 조직을 가지고 있는 기업의 입장에서, 장표에 수치로 표기할 수 없는 정성적인 측면도 고려하지 않을 수 없다.
그것이 바로 개발 문화이다.
핵심적인 기능들은 당연히 현재처럼 민감하게 혹은 보수적으로 접근할 수 있을 것이다. 하지만 MSA 아래, 추가적으로 개발팀이 적극적으로 시도해 볼 수 있는 실험 가능성이 많아졌다. 과감한 수정이 전사적 장애를 유발하지 않는 환경, 다양한 시도를 해볼 수 있는 환경은 단순히 수치상으로 표기될 수 있는 변화의 수준이 아니다. 특히, 요즘처럼 ABC로 대변되는 신기술들AI인공지능, Blockchain블록체인, Cloud클라우드의 향연이 이루어지는 시기에는 더욱 더 그렇다.
2. 기술 부채(Technical Debt)의 빠른 청산
빠른 개발을 위해서 구조적인 손해를 감수하면서 프로젝트를 진행한 경험은 개발자라면 누구나 한 번쯤은 가지고 있을 것이다. MSA가 정착되고 업계의 표준으로 자리잡는다면, 해당 마이크로 서비스만 기술 부채를 지닌채 ‘남겨둘 수’ 있을 것이다. 하지만, 이전의 개발 환경에서는 쉽지 않았다. 기술 부채를 한 번에 청산한다는 것은 ‘차세대 시스템 개발’이라는 매우 큰 부채청산 작업을 수반했어야 했다. (물론, 기존의 모놀리식 구조에서 MSA로 바꾸는 것은 시스템의 규모에 따라 매우 큰 부채청산 작업이 될 수 있다.)
3. 폴리글랏 프로그래밍(Poly glot)
이제까지 개발이라고 하면 하나의 일관된 기술 스택 위에서 협업을 진행하여 개발을 진행하는 것이 정석처럼 여겨졌다. 심지어 사용하는 라이브러리의 버전까지 통일시켜 맞추고 해당 버전에서의 치명적인 문제가 다음 버전에서 수정되었다 하더라도 이를 직접 다시 만들어야 하는 흔히들 말하는 ‘바퀴를 다시 발명하는’ 수고를 거쳤어야 했다. 하지만, MSA가 자리를 잡고 각 마이크로 서비스간의 느슨한 결합(Loose coupling)을 원격 프로시져 호출이나 메시징, RESTful API 등을 통해 제대로 유지할 수만 있다면 다양한 환경에서 개발된 서비스들을 통합할 수 있을 것이다.
4. 코드레벨이 아닌 인프라와 네트워크 레벨의 대처능력 요구
이제 개발자는 코드만의 문제가 아니라 오케스트레이션의 장애에도 대처해야 한다. 이 경우에 단순히 해당 서비스의 코드 수정만으로 제대로 대처할 수 없다. 인프라 측면에서 인스턴스가 생성된 하드웨어 레벨에서 장애는 없는지, 각 인스턴스간의 네트워크 레벨에는 문제가 없는지 체크해야만 한다. MSA를 구성하고 Uptime과 Eureka에는 잡히지 않는데 문제는 지속되고 있으면 어디에서부터 디버깅을 시작해야 할까? 자동 오케스트레이션에 대한 의존도가 높으면 높을 수록 인프라와 네트워크 레벨의 지식이 없으면 더욱 더 장애에 대처하기 힘들어진 것이다.
MSA의 도입비용과 기회
주변에 보면 MSA가 마치 만능 열쇠인 것처럼 생각하는 사람이 많다. MSA가 아닌 것은 레거시Legacy, 낡은 기술 취급하는 힙스터 개발자들부터, 이제 막 사업을 시작해서 MVPMinimum Viable Product, 최소 기능 제품를 만들어야 하는 스타트업 대표들까지 다양하다. 하지만, 우리는 기억해야 한다. 여전히 소규모 시스템에는 모놀리식 (Monolithic) 개발도 유효하다는 사실을 말이다.
우리는 배보다 배꼽이 크다는 말의 뜻을 잘 이해하고 있다. 하지만 이상하게도 신기술을 적용하고자 할 때, 우리는 이런 사실을 쉽게 간과하는 경향이 있다. 개발팀의 기술 배경을 기반으로 MSA를 도입하는 비용보다 모놀리식 개발을 진행하는 것에 더 이득이 많다면 그렇게 해야 한다. 실제로, 도커(Docker) 인스턴스는 생각보다 쉽게 죽고, 서킷 브레이커 패턴(Circuit Breaker pattern)을 활용하여 마스터 노드가 SPOFSingle Point of Failure, 단일고장점가 되는 걸 방지하도록 구현하는 건 쉽지 않다. MSA의 핵심인 오케스트레이션(Orchestration)이 멈춘다면 어떨까? 기본 값에서 조금이라도 벗어난 경우에 개발팀은 오케스트레이션 엔진을 뜯어봐야 한다. 이러한 모든 것들이 MSA 도입의 기술 비용이다.
그럼에도 불구하고, 개발환경은 점차 모놀리식 구조에서 MSA로 바뀔 것이다. 자바와 스프링이 대세로 자리 잡고 있는 우리나라의 개발 환경에 스프링 부트와 스프링 클라우드가 지원하고 있다. 도입 사례를 저 멀리 글로벌 기업에서 찾을 필요없이 '쿠팡', '11번가', '배달의 민족'에서 찾을 수 있다. ‘미래는 이미 와 있다. 단지 널리 퍼져 있지 않을 뿐이다.’라고 윌리엄 깁슨이 경제주간지 <이코노미스트>에서 언급했던 것처럼, MSA는 앞으로 널리 퍼질 미래의 조각이다.
MSA가 만능 열쇠가 되진 못할 것이다. 하지만, 충분히 계산된 도입 및 전환 비용을 지불하고 개발팀의 지지가 있다면 그 동안 해보지 못했던 여러 도전을 할 수 있는 가능성의 단초가 되어줄 것이다.
참고문헌
Tom Hardin(2018), G2 Crowd, Digital trend: Microservice
윤용성(2018), Spring Camp: 11번가 Spring Cloud 기반 MSA 전환 1년간의 이야기, 발표세션
