개발문화탐구: 데브옵스 (DevOps) - 마이크로서비스 vs 모놀리식서비스
들어가기 전
몇 년 전부터 마이크로 서비스에 대한 이야기를 흔히 접할 수 있었습니다.
마 그거? 서비스 다 따로 분리하는 거 아니야? 정도로 간단하게 알고 있습니다.
사실 그게 맞긴 하지만, 마이크로 서비스가 무엇인지 혹은 왜 사용하는지에 대해서 어느 정도 깊이있게 알지 못하면 이후 소개할 개념들이 매끄럽게 이해가 안 되는 부분이 발생할 수 있겠다는 염려가 들었습니다.
그런 이유로 한번 짚고 넘어가 봅시다!
그 전에 제목에도 언급된 모놀리식 서비스가 무엇인지 알아보도록 합시다.
모놀리식 서비스 (Monolithic)
귀에 딱지가 생길 정도로 많이 보이던 용어인 마이크로 서비스에 비해 모놀리식 서비스는 뭔가 생소합니다.
모놀리식 서비스 혹은 모놀리스 구조라고 합니다. (Monolithic)
이는 모든 비즈니스 로직이 한 애플리케이션 안에 포함되어 있는 구조를 말합니다.
이해를 돕기위해 간단한 위의 이미지를 봐봅시다!
위 이미지는 택시 앱의 비즈니스 로직입니다.
Billing, Notification, Payments, Management 기능들이 모두 들어가 있습니다!
모든 기능들이 한 애플리케이션에서 동작하는 구조이며 이를 모놀리식 서비스라고 합니다.
이해가 잘 안가신다구요? 하울의 움직이는 성을 떠올려보세요!
딱봐도 복잡해 보인다...
이로인해 얻을 수 있는 장단점을 한번 훑고 가 봅시다.
장점
- 처음에 구조 설계 및 개발이 간단하다. (통채로 각 기능들을 일체화된 구조에서 만들기 때문에)
- 내부 프로세스 간 지연시간이 짧음
- 배포 시, 한번 배포하면 끝
단점
- 낮은 모듈성
- 낮은 확장성
- 긴 빌드 시간
새로운 기능을 개발 시, 프로토타입을 만들기 좋습니다.
웹서비스를 예로 든다면, 배포가 한 번에 똵-! 끝! 대신 빌드 시간이 길겠지만 어쨋든 배포에 신경쓸 부분이 훨씬 줄어듭니다
개발과 배포가 단순하다니, 아아 매우 달콤하군요.
하지만 치명적인 문제가 있습니다!
모놀리식 서비스를 팀 단위로 개발한다면 아래와 같은 문제를 일으킵니다.
- 애플리케이션이 클수록 코드를 이해하기 어렵다. (그로 인한 숨 막히는 압박감은 덤)
- IDE가 과부하로 인한 생산성 감소.
- 모듈화가 힘들다.
- 코드 단 한 줄을 변경에도 전체 애플리케이션 빌드가 필요, 지속적인 배포는 사요나라.
- 새로운 기술의 사용이 어려워짐.
그럼 이런 문제들을 어떻게 해결할 수 있을까요?
마이크로 서비스 (Micro)
일체형 서비스 구조로 인해 시스템 엔트로피가 자꾸만 늘어만 갔습니다.
결국 많은 서비스들이 이런 문제를 해결하기 위해 더 적합한 아키텍처를 찾아서 진화했습니다.
그것이 바로 이 마이크로 서비스!
마이크로 서비스로 인해서 얻을 수 있는 장단점은 아래와 같습니다.
장점
- 개발자 생산성 향상
각 단위가 간단하니 개발자들이 방대한 코드를 보고 개복치가 되는 경우 방지 - 테스트 용이성 증가
- 빠르고 지속적인 배포 가능
- 안전성 증가
- 책임이 명확하게 분리됨
단점
- 소스 저장소 및 서버 분리
- 각 마이크로 서비스 간 네트워크 문제 발생 가능
- 각 서비스에 대한 모니터링 필요
물론 단점이 없는 건 아니지만, 팀 단위 개발의 문제점이 많이 개선되었습니다.
Payments가 업데이트 된다면 그 부분만 checkout해서 변경 & 빌드하면 될 것이고, 각 기능이 완벽히 분리되어 있다보니 코드의 복잡도가 훨씬 줄어듭니다.
새로온 개발자에게 작업을 인계할 때도 부담이 훨씬 줄어들게 됩니다.
모놀리식은 구식이다?
결과적으로 지금까지는 마이크로 서비스에 대한 장점을 어필하고 있었습니다.
왜냐하면 오늘날에 많이 쓰이는 서비스 중심의 아키텍쳐이기 때문이죠.
와 그럼 마이크로서비스 개꿀이네 완전? 이라는 생각이 들었다면 이 포스트위 목적이 절반은 성공했다는 생각이 드네요!
하지만 이게 마냥 꿀이 흐르는 강은 아닙니다. Netflix의 마이크로서비스 아치텍쳐를 보면 입이 떡벌이지게 됩니다.
아.... 분명 뭐 하나만 고치라했는데 뭐였더라..
실제로 세그먼트라는 회사에서는 마이크로 서비스에서 모놀로틱 구조로 다시 돌아왔습니다.
Goodbye Microservices: From 100s of problem children to 1 superstar · Segment Blog
[번역] 잘가요 마이크로서비스: 100개의 문제점 투성이를 1개의 슈퍼스타로
결론은 서비스의 특성을 잘 이해하고 구조를 선택하자 입니다.
아 뭐지 이 고구마 먹은 느낌은...
하나의 정답 없이 서비스와 개발 문화에 따라 천차만별 변화하는 게 데브옵스의 묘미일까 싶기도 하구요!
참고
넷플릭스 마이크로 서비스 가이드 - 혼돈의 제왕
Introduction to Microservices | NGINX
마치며
그러면 모놀리식 서비스는 어떻게 마이크로 서비스로 만들 수 있을까요?
처음부터 새로 분리된 코드를 짜야 할까요?
이런 궁금증을 해소하기 위해 다음에는 교살자 애플리케이션 패턴에 관하여 이야기해 보겠습니다.