모놀리식 vs 마이크로

모놀리식 서비스 (Monolithic)

장점

• 처음에 구조 설계 및 개발이 간단하다.
  (통채로 각 기능들을 일체화된 구조에서 만들기 때문에)
• 내부 프로세스 간 지연시간이 짧음
• 배포 시, 한번 배포하면 끝

단점

• 낮은 모듈성
• 낮은 확장성
• 긴 빌드 시간
• 새로운 기능을 개발 시, 프로토타입을 만들기 좋습니다.

앱 서비스를 예시로 든다면, 하나의 프로젝트에서 빌드 한번으로 끝.
대신 빌드 시간이 길겠지만 어쨋든 배포에 신경쓸 부분이 훨씬 줄어듭니다.

하지만 치명적인 문제가 있다.
모놀리식 서비스를 팀 단위로 개발한다면 아래와 같은 문제를 일으킵니다.

• 애플리케이션이 클수록 코드를 이해하기 어렵다.
• IDE가 과부하로 인한 생산성 감소.
• 모듈화가 힘들다.
• 코드 단 한 줄을 변경에도 전체 애플리케이션 빌드가 필요, 지속적인 배포는.... 불가능..
• 새로운 기술의 사용이 어려워짐.

그럼 이런 문제들을 어떻게 해결할 수 있을까?

마이크로 서비스 (Micro)

일체형 서비스 구조로 인해 시스템 엔트로피가 자꾸만 늘어만 갔습니다.
결국 많은 서비스들이 이런 문제를 해결하기 위해 더 적합한 아키텍처를 찾아서 진화했습니다.

마이크로 서비스로 인해서 얻을 수 있는 장단점은 아래와 같습니다.

장점

• 개발자 생산성 향상
• 각 단위가 간단하니 가독성 향상
• 테스트 용이성 증가
• 빠르고 지속적인 배포 가능
• 안전성 증가
• 책임이 명확하게 분리됨

단점

• 소스 저장소 및 서버 분리
• 각 마이크로 서비스 간 네트워크 문제 발생 가능
• 각 서비스에 대한 관리 포인트 증가

물론 단점이 없는 건 아니지만, 팀 단위 개발의 문제점이 많이 개선되었습니다.

업데이트 된다면 그 부분만 checkout해서 변경 & 빌드하면 될 것이고, 각 기능이 완벽히 분리되어 있다보니 코드의 복잡도가 훨씬 줄어듭니다.
새로온 개발자에게 작업을 인계할 때도 부담이 훨씬 줄어들게 됩니다.

모놀리식은 구식이다?

결과적으로 지금까지는 마이크로 서비스에 대한 장점을 어필하고 있었습니다.
왜냐하면 오늘날에 많이 쓰이는 서비스 중심의 아키텍쳐이기 때문이죠.

하지만 마이크로 서비스가 완벽한것은 아니다.
Netflix의 마이크로서비스 아치텍쳐를 보면 입이 떡벌이지게 됩니다.

실제로 세그먼트라는 회사에서는 마이크로 서비스에서 모놀로틱 구조로 다시 돌아왔습니다.
https://tech.ssut.me/goodbye-microservice/

결론은 서비스의 특성을 잘 이해하고 구조를 선택하자.

하나의 정답 없이 서비스와 개발 문화에 따라 천차만별 변화하는 게 개발의 재미가 아닐까 싶다.