들어가는 글

Microservice Architure는 어느덧 Enterprise 규모에서는 당연한 구조로 받아들여지고 있습니다. 기존 Monolith Architure에서 새로운 아키텍처로 옮겨가면서 마이크로 서비스의 의미에 대해 다시 한번 정리해볼까 합니다.

마이크로서비스는 종횡무진 확장되어 나가는 사용자와 이를 서포트하기 위한 서버 스케일링의 한계 때문에 나왔습니다. 아이러니하게도 더 많은 사용자에게 서비스하기 위해서는 서비스 자체는 작아져야 한다는 페러다임입니다. 마이크로서비스를 이해하기 위해서 비교 대상이되는 Monolith Architecture를 알아보겠습니다.

Monolith Architecture의 단상

간단히 부트스트랩하는 프로젝트를 보면 하나의 소스코드에서 시작합니다. 처음에는 누구나 그렇게 시작하죠. 초기 기능들의 수가 적기 때문에 개발하고, 테스트하고, 빌드하고, 배포하는 것은 일사천리입니다. 그만큼 사용자 수도 적어서 스케일링에 대한 문제도 없습니다.

그러나 잘 만든 소프트웨어라면 금새 사용자 수가 늘고 지원하는 기능들도 늘어나게 됩니다. 소스 코드는 기하급수적으로 늘어납니다. 누가 만든 코드인지 알아내야지만 코드를 고칠 수 있을 정도로 원작자가 아니면 추가 개발이 어려워지는 상황도 발생합니다. 즉, 한 사람이 이해하기 힘든 규모가 된 것입니다.

이런 상황이 되면 개발은 물론 테스트, 빌드, 배포도 한나절이 걸립니다. 기능 하나 추가하거나 변경하는 것이 이렇게 고통스러울 때가 없지요. 그러나 비즈니스는 더욱 빠르게 변해갑니다. 오늘 추가해달라는 기능 목록이 산더미네요.

개발자들은 스스로 살길을 찾아 나섭니다.

이럴바에는 코드를 서비스 단위로 분리해버리자. 추가할 기능이 있으면 부트스트랩 코드로 처음부터 만들어 버리자. 어짜피 처음짜는 코드니까 Legacy 코드에 대한 지식도 필요없다.코드를 분리했으니 빌드, 배포, 서버도 분리해버리자.

드디어 자기도 모르게 마이크로서비스 구조로 가고 있습니다.

마이크로서비스 아키텍처의 장점은 “작다”는 것이다.

작게 개발하고 유지한다.

적당한 두께의 나무보다, 잔가지 여러개가 부러뜨리기 어렵다.

comments powered by Disqus