마이크로서비스 시작하기 (1편)

처음 마이크로서비스를 공부하기로 마음을 먹고 여러 정보들을 찾아보고 스터디를 구하던 중, 어느 분께서
"제 생각엔 MSA는 혼자 공부할 수 있는 학문이 아니예요, 회사에서나 공부할 수 있는거 같아요."
라는 말씀을 하셨을 때 막막함을 느꼈습니다.
왜냐면 실제로 MSA는 혼자서 공부하기 쉽지 않은 학문이기 때문이었죠.
2개 이상의 마이크로한 서비스를 띄워서 각 서비스는 OAuth, JWT 등 token 인증을 이용해 통신해야 하고 트랜잭션 관리도 기존의 모노리스 아키텍쳐와는 완전히 다르기 때문에 MQ도 반드시 구축이 되어야 했으며 API Gateway부터 서비스 디스커버리를 구축하는게 간단한 일이 아니었기 때문입니다.
더군다나 로드밸런싱, Auto Scale, Auto Recovery 등을 해결해주는 쿠버네티스까지 포함된다면 러닝커브는 더욱더 커질 수밖에 없습니다.
하지만 그렇다고 막연함에 손을 놓고 있을 수는 없기 때문에 '클라우드 네이티브 자바'라는 책과 함께 스터디를 시작하게 되었습니다.
이 글이 저와 같이 MSA를 공부하려 하지만 막연함을 느끼시는 분들께 도움이 되었으면 합니다.

왜 마이크로서비스를 써야하죠?

마이크로서비스를 사용하는 이유에 대해서 알기 위해서는 기존의 모노리스 아키텍쳐의 단점에 대해서 알아보아야 할것 같습니다.
기존의 모노리스는 서비스가 커지면 하나의 프로젝트 소스 역시 방대해지게 되었고 이는 하나의 WAS에서 돌아가는 어플리케이션 역시 방대해지도록 만들었습니다.
새로운 버전을 배포하기 위해서는 서비스를 개발하고 있는 모든 부서들이 소스를 병합하여 전체 테스트를 거친 후 배포해야 했기에 많은 시간과 비용이 발생되었습니다. 소스를 전부 병합하고 테스트하는데 완료하였더라도 이 거대한 어플리케이션을 서버에 띄우는데에는 오랜 시간이 발생되었고 이는 개발관점에서도 많은 시간을 소모하게 만들었습니다.
MSA는 이러한 단점들을 해결해줍니다. 거대하고 무거운 서비스를 마이크로하게 작은 서비스들로 나눠서 운영을 하기 때문이죠.
게다가 각 서비스는 언어나 환경에 구애받지 않을수도 있습니다. 모노리스는 하나의 프로젝트이기 때문에 모든 부서가 같은 환경과 같은 언어, 프레임워크를 이용하도록 강제되어야 했습니다. 그렇지만 메인서비스는 Spring으로 하되 머신러닝은 Python으로 개발하고 싶을 수 있고 IO와 같은 비동기가 많은 프로젝트의 경우 Node.js를 이용하고 싶을 수도 있습니다. 이러한 경우에 각각의 앱이 개별적으로 서비스되는 MSA가 해결책이 될 수 있습니다.

그렇다면 모노리스보다 MSA가 좋은건가요?

제 답변을 예상하셨겠지만 정답은 '그렇지 않습니다'입니다. 여러 아키텍쳐가 있는 이유는 장점이 있으면 단점도 있기 때문이죠. 만약 한가지 아키텍쳐가 다른 아키텍쳐에 비해 장점만 있다면 나머지는 사라지고 장점만 존재하는 아키텍쳐가 살아남았겠죠.
모노리스는 우선 MSA에 비해 개발이 간단합니다. 서론에서 언급한 것과 같이 MSA는 트랜잭션 관리는 물론이고 장애가 서비스 전체에 전파되는 것을 막기 위해 timeout을 설정하는 등 신경 써야 할 것들이 많기 때문이죠. 또한 MSA는 다른 서비스에 의존성이 있는 경우, 테스팅에 더 많은 시간이 소요되며 장애 추적이나 모니터링 역시 쉽지 않습니다.

Next

MSA를 시작하기 앞서 MSA가 무엇이고 어떠한 경우에 사용 되면 좋은지 장단점에 대해 알아보았습니다.
다음 챕터에서는 본격적으로 MSA에 대해 알아보기전에 12요소 방법론에 대해 짚고 넘어가겠습니다.

마이크로서비스 시작하기 (2편) - 12요소 방법론