마이크로서비스(Microservices) 에 대해

마이크로서비스 혹은 마이크로서비스 아키텍처는 크게 2가지의 목표를 가지고 일체형 서비스를 작은 컴포넌트화 시키는 것이다. 

 

1. 빠르게 개발하고 지속적으로 배포한다 -> Agile의 개념
2. 쉽게 Scaling 할 수 있어야 한다

 

사실 마이크로 서비스는 현대에 들어서 애자일(Agile)이 뜨고, 가상화 및 클라우드 시스템의 등장으로 잦은 배포와 거대한 서버를 소형 서버로 쪼갤 수 있으므로 개발의 효율을 극대화하기 위해서 등장했다. python의 경우 djang과 flusk로 api를 쉽게 띄우며, spring의 경우 마이크로 아키텍처와 함께 스프링부트가 뜨면서 대형 프로젝트를 제외하면 대세가 되어가고 있다.

 

모노리식 vs 마이크로서비스, https://www.teaminternational.com/modernization-legacy-software-microservices-pros-and-cons/

 

예를 들어, 어떤 거대한 웹사이트가 하나의 웹서비스(Monolithic Architecture, 모노리식 아키텍처)로 운영한다고 생각해보자. 뭐가 하나 런칭할때마다 수많은 사이드 이펙을 체크하고 그 엄청난 시스템을 이해하기 위해서 개발자들은 유지보수에 모든 시간을 쏟게 된다. 그리고 개발자들은 나 때문에 시스템이 문제가 있을까봐 오히려 개발을 주저해서 런칭의 횟수가 줄어드는 문제가 발생한다.

 

현재 마이크로서비스가 뜨기 직전, 일반적인 개발의 모습(아무래도 전자정부프레임워크로 대규모 프로젝트를 하는 것은 동일하겠지만) 아래와 같은 대화를 자주 나누곤 했다.

 

 

 "혹시 오늘 런칭할 사람 있나요? 오후 2시에 배포할 예정인데 없으면 진행합니다!!"

 

하지만 마이크로서비스를 쓰는 단계에서는 이와 같은 대화는 다음과 같은 대화로 변경되었다.

 

제가 오늘 곧 XX서비스 런칭할건데 개발 및 스테이징 확인좀 부탁드릴게요.

결국 대화의 주제가 배포에서 테스트로 넘어갔고, 리스크가 극단적으로 줄게 되었다. 다만 이렇게 Risk를 줄이기 위해서는 다음과 같은 Risk도 줄여야 한다.

 

1. 쪼렙(신입) 개발자가 문제 없이 개발 및 런칭할 수 있게 교육을 시켜야 한다.
2. Input 과 Output에 대한 확실한 API 정의서 등을 개발하고, 테스트를 많이 해야 된다.

 

마이크로서비스는 기존 View단계에서 코더 역할만 하던 개발자들에게 많은 Risk를 전담(그전에는 우산속에 있었다면)시키며 내가 만든 서비스에 대한 만족도를 증가시킬 수도 있다. 그리고 삽질을 하게 된다면 일체형 서비스보다 정말 큰 잔소리를 들을 수도 있다.

 

일체형과 마이크로아키텍처에 대해서 정답이 있을순 없다. 마치 Java와 C언어중에 정답이 무엇인가?라는 엉뚱한 질문일수가 있다. 둘의 장단점은 명확히 다르고 해당 서비스에 맞는 방식을 적용해야 하는데 "요즘 마이크로서비스가 유행이라고 하네요. 저희도 써요"라는 무책임한 말을 하는 개발자는 없어야 한다. 

 

그럼 마이크로아키텍처의 장단점을 알아보도록 한다. 각각의 장단점은 정확히 일체형 서비스의 장단점과 반대이다.

 

마이크로서비스의 장점

- 서비스의 유지보수가 매우 쉽다. 개별적인 서비스를 운영하기 때문에 소스가 적고 원하는 언어로 작성할 수 있다.

- 내가 삽질을 하든 남들은 신경 쓰지 않는다. 즉 내 서비스는 블랙박스이고, Output만 잘 만들어지면 된다.

- 문제가 발생했을 때 빠른 배포로 대처가 가능하다.

 

마이크로서비스의 문제

- 전체적인 퍼포먼스의 성능이 뛰어나지 못하다. 일체형으로 단순히 메소드끼리 이동한 녀석들이 http를 타고 전달하고 json등을 파싱하기 때문에 속도가 급격히 떨어진다.

 

- 개발자의 실수를 쉽게 인지할 수 없다. 타 마이크로서비스는 블랙박스이기 때문에 성능상 문제가 발생했을 때 쉽게 인지를 못한다. 이를 위해 끊임없는 테스트가 필요하지만, 초창기 테스트 이후 테스트베드가 제대로 유지되지 못하고 빨리 런칭하고 싶단 생각으로 테스트 과정을 매우 적게 한 후 런칭하는 것이 보편적이기 때문이다.

 

- 개별 개발자가 퇴사하였다면 인수인계 받아서 유지보수하기가 쉽지가 않다. 한 소스안에 있었다면 다른 개발자가 핸들링할 수 있겠지만 블랙박스 영역이었던 소스를 받거나 다른 언어로 개발되어 있는 경우 정말 지옥이다.

 

- 로깅이 매우 힘들다. 너무 여러군데에 퍼져 있어서 모든 서버의 자원을 파악하기 힘들고 각각의 서버에서 tomcat 등의 로그를 파악하는 것이 정말 지옥이다. 여러명이 각자 하면 괜찮지만 퇴사 등으로 한사람에게 수많은 서비스가 인계되었다면 정말 로그 띄우다가 하루가 다 간다.

 

이렇게 적다보니깐 단점이 훨씬 많은 것 같지만 현대에서는 뭐든지 시도를 하는 것이 좋은데 마이크로 아키텍처는 개발자 한명을 연구원으로 성장시킬 수 있고, 최근에 python를 flusk로 띄워 자바와 자주 접목시키는 상황에서는 마이크로아키텍처는 시대적인 흐름이라 할 수 있으며, 유지보수의 리스크가 없을 때에는 그 무엇보다 편하기에 흐름을 유지하되 유지보수를 앞으로 어떻게 할 것인지 그리고 블랙박스 영역등을 code review 등으로 모두 공유하는 등의 대처를 하는 것이 중요할 것이다.