👉 [CS] Docker 기반 Microservice 구현

Monolithic Service vs Micro Service

두 가지 아키텍쳐로 백엔드 구성이 나뉠 수 있다. 전자는 하나의 큰 줄기에 모듈단위로 작업이 처리되는 것이고, 후자는 기능단위로 여러 줄기로 나누어 작업을 처리하는 것이다. 현재 우리 서비스는 전자로 설계되어 있다. 하지만 이번에 마이크로 서비스로 변경하자는 제안이 있었고 해당 작업을 진행중이다. 이러한 작업을 진행하는 이유는

1. 가독성의 문제(=코드간 독립성 증대)
= 사실 이건 모놀리식과 마이크로 간에 문제와는 결이 조금 다르지만, A 모델을 다루는 컨트롤러가 B 모델을 다루는 컨트롤러에 직접 접근하는 경우가 많아지면 보기에 매우 불편하다. 이를 서비스 단위로 나눈다면 조금 더 간편해진단 의견이 있었다.

2. 협업의 문제
= 협업하는 숫자가 많아지면서, 파일 단위로 쪼개지는 숫자가 많아야 브랜치가 컨플릭트되지 않을 것이라 예상했다. 작게 쪼갤수록(적당히) 더 나은 협업이 가능하다. 서비스 단위로 맡아 작업하기가 수월해질 것이라 예상했다.

3. 새 기술에 대한 경험
= 도커가 나온지 꽤 오래되었지만, 적용 해볼 기회가 마땅치 않았다. 무거운 서버를 다루는게 거의 처음이므로 적용해보면 경험적으로 더 좋으리라 생각했다.


개인적으로는 2번의 문제가 제일 컸다. 서비스 단위로 할일을 나누면 되니까......

아래는 찾아보며 비교한 구현 방식이다. 아키텍쳐간의 장단점에 대해는 많이 나와있지만, 실제 구현 방식은 찾기 어려워서 애먹었다.

모놀리식 서비스

현재 서비스 아키텍쳐이다. 모놀리식 서비스에 MVC 패턴을 적용해왔다. 유저와 게시판을 구성한다고 가정하면 User/Post/Comment 라는 Model(테이블)이 있을 것이고, 이에 해당하며 로직을 담당하는 Controller 가 존재한다.

마이크로 서비스로 전환하면 이러한 형태를 갖는다.

User와 Board(게시판) 서비스로 나뉘며, Board 서비스에는 Post/Comment 에 대한 MVC를 다루고 있다.

 

만약 Board에서 User에 대한 정보가 필요할 경우, API Call을 이용해서 해당 서비스를 이용해야 한다.

 

여기서 마이크로 서비스의 단점이라고 생각하는 부분이 나타난다.

 

API를 활용한다는 것 자체가 HTTP를 활용해야하고, 메모리단에서 직접 접근한 것보다 훨씬 오버헤드가 심하다.

 

이것이 계속 쌓여 선형적으로 레이턴시가 발생할 것이라 생각한다.

 

사실 이 부분 때문에 마이크로서비스에 대해 고민을 많이 했지만,

트래픽 때문에 발생하는 이슈보다 협업 상의 이슈가 더 클 것이라 판단했다.