마이크로 서비스 아키텍처란?
Micro Service Architecture의 약자로, 여러가지 서비스 기능들을 가지고 있는 하나의 프로그램을 각 서비스별로 나누어 관리하는 애플리케이션 개발 아키텍처 스타일을 의미한다.
주로 많고 다양한 서비스를 가지고 있는 대규모 서비스에 적용시키며 도입한 기업들은 아마존, 넷플릭스, 국내엔 삼성전자, 페이코 등이 있다.
왜 도입하나?
웬만한 서비스들은 전부 마이크로 서비스 아키텍처의 반대 격인 모노리스(Monolith) 아키텍처로부터 시작되었다고 볼 수 있는데, 모노리스 아키텍처란 하나의 프로그램에 모든 서비스 기능들이 포함된 형태의 개발 아키텍처 스타일이다.
모노리스 아키텍처에서의 다음과 같은 단점을 극복하기 위해 마이크로 서비스 아키텍처가 도입되었다.
Monolith Architechture의 단점
- 하나의 기능만 고장나도 전체 프로그램이 영향을 받는다.
- 모든 기능을 가진 하나의 무거운 프로그램이기에 테스트/빌드 시간이 오래 걸린다.(새로운 기능 업데이트 하기도 쉽지 않다)
- 하나의 기능에만 연결된 라이브러리나 프레임 워크가 업데이트되더라도 모든 기능에 영향을 미칠 수 있다.
을 해결해주는 Micro Service Architecture의 장점
- 각 기능 별로 나뉘어져 있기 때문에 하나의 기능이 고장나도 다른 기능들은 정상적으로 작동한다.
- 새로운 기능이 업데이트 되면 그 기능만 테스트/빌드하면 되기 때문에 기능 생성/수정/삭제가 빠르다.
- 하나의 기능에만 연결된 라이브러리나 프레임 워크가 업데이트되면 그 기능에만 영향을 미친다.
이 외의 장점들
각 서비스들이 독립적이기 때문에,
- 개발자가 원하는 언어로 기능 개발이 가능하다.
- 하나의 서비스에 트래픽이 몰리게 되면 그 서비스만 스케일 업 시킬 수 있어, 효율적인 클라우드 자원 운용이 가능하다.
그럼 무조건 도입하는 게 좋은 거 아냐?
마이크로 서비스 아키텍처는 아주 많은 장점들이 있지만, 무조건적으로 좋은 건 아니다.
우선, 마이크로 서비스 아키텍처를 도입했다고 가정해보자.
위에서 언급한 장점들로 인해 개발 관련 복잡도는 눈에 띄게 줄어들 것이다.
하지만, 아키텍처를 도입함으로써 나뉘어진 수 많은 서비스들을 관리하기 위해서는 여러가지 툴들이 필요하다.
여러가지 서비스들을 독립적으로 배포하기 위해, 도커의 컨테이너를 사용해 배포하기도 한다.
규모가 커지면 컨테이너 역시 늘어날 것이고, 이렇게 넘쳐나는 컨테이너를 관리하기 위해 쿠버네티스를 사용하기도 한다.
각 독립적인 서비스들 간의 통신을 손 쉽게 하기 위해 카프카도 사용해야 할 수도 있다.
수 많은 서비스들을 모니터링 하기 위해 프로메테우스와 같은 툴도 사용하게 될 것이다.
🤔 근데 위에서 언급한 것들은 모노리스에서도 사용하기도 하지 않나요?
그렇다. 하지만, 모노리스에서는 모든 서비스들을 가진 하나의 프로그램만 관리했다면, 마이크로 서비스는 이 많은 서비스들을 위의 툴들을 사용해 관리해야 한다. 즉, 마이크로 서비스 아키텍처를 도입하면 수 많은 서비스들을 가진 규모가 큰 서비스일수록 운영 복잡도는 늘어나게 된다.
그럼 규모가 큰 모노리스에만 도입하면 되겠네!
이것도 정답은 아니다.
개발 복잡도 + 운영 복잡도 = 총 복잡도 일 때, 총 복잡도가 높아지지 않고 낮아지는 상황에서만 모노리스로 유지할 지, 마이크로 서비스를 도입할 지를 결정하는 것이 좋아 보인다.
개발자들의 선생님인 스택오버플로우는 월 1억명이 방문하는 트래픽을 마이크로 서비스 아키텍처없이 Scalable Monolith 방식으로 운영되고 있다.
운영 복잡도 또한 겪고 싶지 않다면, 마이크로 서비스 아키텍처 대신 서버리스를 채택하는 것도 하나의 방법이 될 수 있다.
