오늘부터 서버개발자로써 알아야 하는 기술용어들이나 스택들을 하나씩 정리해 보려 한다ㅎ
최근에 도커 스터디를 시작했다. 우테코의 프로젝트나 기업채용에서 종종 보이는 조건이 도커및 쿠버네티스 활용여부이기도 하고, 서버개발자라면 배포관련해서도 지식이 있어야 하기에,
책의 첫 단락에 마이크로 서비스 관련해 언급이 되어있었다. 오늘 주제는 마이크로 서비스 아키텍처다
일단 결론 - 마이크로 서비스 아키텍처란???
모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴
특정 서비스의 변경이 다른 서비스에 영향 미칠 가능성 적음 && 서비스 단위로 독립적인 배포 가능
최근에 RESTAPI 의 일반화, 도커 같은 컨테이너 기술, 클라우드 컴퓨팅 환경의 발전에 힘입어 마이크로 서비스가 좀 더 손쉽게 구현될수 있게 되었다고 합니다.
다음의 항목들에 현재상환이 해당되면 마이크로서비스 아키텍처 패턴에 대해 고민을 해보는게 좋다고 하네요!
- 애플리케이션의 배포에 한 시간 이상 소요된다.
- 단순한 기능 하나를 수정해도 전체 기능에 대한 QA가 필요하다.
- 단순한 버그 수정이 더 중대한 버그를 생산하는 일이 많아졌다.
- 현재의 애플리케이션을 기능별로 나눈다고 가정했을때 수십개의 마이크로서비스가 가능하다.
마이크로서비스 아키텍처를 잘 이해하기 위해서 반대개념인 모놀리틱 아키텍처에 대해서도 살펴보자.
모놀리틱 아키텍처
비즈니스 로직을 담당하고 있는 애플리케이션이 존재하고, 해당 애플리케이션은 데이터베이스 등 외부 시스템과 특정 프로토콜로 통신을 하게된다. 사용자에게 인터페이스를 제공하기 위해 HTML을 렌더링 하는 부분과 RESTful API를 제공하는 부분을 갖게 된다.
이렇게 구성된 애플리케이션의 소스코드는 하나의 프로젝트로 구성되어 있으며 단일한 패키지로 배포된다.
로컬 환경에서 개발도 편리하고 통합 시나리오 테스트를 수행하기에도 가장 손쉬운 구성이다. 또 모든 코드가 하나의 묶음으로 구성되어 있기 때문에 배포도 간편하다.
하지만
서비스가 지속적으로 성장하고 규모가 커질 때 한계에 부딪힐수 있음,,
개발자의 규모가 수십에서 백명 이상이 되고 서비스의 복잡도가 증가되면 아주 간단한 기능을 하나 추가하기 위해서도 매우 많은 줄의 코드를 수정해야함은 물론, 코드의 변화가 영향을 미치는 범위가 증가되었기 때문에 간단한 변화 하나에도 통합테스트가 필요하게 된다.
근본적 원인이 서비스의 구조 자체가 너무 복잡하다는 점이다.!
복잡한 구조는 서비스 초창기 부터 함께 개발을 하여 전체 히스토리를 알고 있는 소수의 개발자를 제외하고는 대부분의 개발자들이 전체적인 시스템 구조를 알지 못하기 때문에 재활용 가능한 모듈을 무시하고 중복된 코드생산++++ => 코드가 기술의 부채로 계속 쌓임 & 수정이 더 큰 버그 양산
서비스 복잡도 증가에 따라 모놀리틱 아키텍처가 가지는 문제점은
1. 배포 시간의 증가
2. 부분적 스케일 아웃의 어려움
3. 안정성 감소
4. 애플리케이션을 구성하는 프로그래밍언어, 프레임워크의 변경이 불가능에 가깝다
그래서 나온!!
마이크로 서비스 아키텍처
모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역활을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴
'사용자 관리', '주문관리', '결제관리', '알림관리'
각각이 하나의 모톨리틱 아키텍처와 유사한 구조를 갖는다.
하나의 서비스에서 처리해야 하는 기능과 규모가 작기 때문에 마이크로 아키텍처라고 부른다.
장점
1. 서비스가 개별적으로 독립적인 단위인 애플리케이션이기 때문에 변경이 용이하고, 그 변경이 다른 서비스에 미치는 영향이 작다.
2. 개별 서비스 단위의 배포가 가능하기 때문에 하루에도 여러 번 배포를 하는 것이 가능하다.
3. 서비스 특성에 맞게 자원을 할당하여 스케일 아웃할 수 있기 때문에 효율적인 자원사용이 가능하다.
4. 시스템의 아키텍처가 개발 조직과 나아가서 회사의 조직 문화에 큰 영향을 미친다.
