개발문화탐구: 데브옵스 (DevOps) - 마이크로서비스 vs 모놀리식서비스

들어가기 전

몇 년 전부터 마이크로 서비스에 대한 이야기를 흔히 접할 수 있었습니다.
많은 분이 서비스를 따로 분리하는 거 아니야? 정도로 간단하게 알고 있습니다.

하지만 마이크로 서비스가 무엇인지 혹은 왜 사용하는지에 대해서 어느 정도 알지 못한다면 이후 시리즈에서 소개할 개념들이 매끄럽게 이해가 안 되는 부분이 발생할 수 있겠다는 염려가 들었습니다.

그런 이유로 한번 짚고 넘어가 봅시다!

모놀리식 서비스


귀에 딱지가 생길 정도로 많이 보이던 용어인 마이크로 서비스에 관해서 이야기 하기 전에, 먼저 모놀리식 서비스에 대해 이야기해 봅시다.

모놀리식 서비스 혹은 모놀리스 구조라고 합니다.

이는 모든 비즈니스 로직이 한 애플리케이션 안에 포함되어 있는 구조를 말합니다.
일체형 구조라고 하면 이해가 더 쉬울 듯..!

위 이미지는 택시 앱의 비즈니스 로직입니다.
모놀리식 아키텍쳐이며 모든 기능들이 한 애플리케이션에서 동작하는 구조입니다.

이로인해 얻을 수 있는 장단점을 한번 훑고 가 봅시다.

장점

  • 처음에 구조 설계 및 개발이 간단하다. (통으로 만들어 버리니)
  • 내부 프로세스 간 지연시간이 짧음
  • 배포 시, 한번 배포하면 끝

단점

  • 낮은 모듈성
  • 낮은 확장성
  • 긴 빌드 시간

새로운 기능을 개발 시, 프로토타입을 만들기 좋습니다.
웹서비스를 예로 든다면
고로 배포 시 서비스를 빌드하면 시간이 오래 걸릴지언정 한 번에 똵-! 끝납니다.
개발과 배포가 단순하다니, 아아 유혹이 매우 달콤하군요.

하지만 치명적인 문제가 있습니다.

모놀리식 서비스를 팀 단위로 개발한다면 아래와 같은 문제를 일으킵니다.

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

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

마이크로 서비스란


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

그것이 바로 이 마이크로 서비스!

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

장점

  • 개발자 생산성 향상
    각 단위가 간단하니 개발자들이 방대한 코드를 보고 개복치가 되는 경우 방지
  • 테스트 용이성 증가
  • 빠르고 지속적인 배포 가능
  • 안전성 증가
  • 책임이 명확하게 분리됨

단점

  • 소스 저장소 및 서버 분리
  • 각 마이크로 서비스 간 네트워크 문제 발생 가능
  • 각 서비스에 대한 모니터링 필요

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

모놀리식은 구식이다?

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

하지만 마이크로 서비스가 무조건 짱이야!!는 아닙니다.

실제로 세그먼트에서는 마이크로 서비스에서 모놀로틱 구조로 돌아왔습니다.

Goodbye Microservices: From 100s of problem children to 1 superstar · Segment Blog
[번역] 잘가요 마이크로서비스: 100개의 문제점 투성이를 1개의 슈퍼스타로

결론은 서비스의 특성을 잘 이해하고 구조를 선택하자 입니다.
아 뭐지 이 고구마 먹은 느낌은...

하나의 정답 없이 서비스와 개발 문화에 따라 천차만별 변화하는 게 데브옵스의 묘미일까 싶기도 하구요!

참고

넷플릭스 마이크로 서비스 가이드 - 혼돈의 제왕
Introduction to Microservices | NGINX

마치며

그러면 모놀리식 서비스는 어떻게 마이크로 서비스로 만들 수 있을까요?
처음부터 새로 분리된 코드를 짜야 할까요?

교살자 애플리케이션 패턴에 관하여 이야기해 보겠습니다.