마이크로 서비스 아키텍처의 정의
다음 특징을 갖는 서비스들의 조합으로 이뤄진 설계
- 유지보수에 유리하고, 테스트 가능해야 함
- 느슨하게 결합되어야 함
- 독립적으로 배포 가능함
- 비즈니스 역량을 중심으로 구성해야 함
- 작은 팀에 의해 소유됨
서비스로서의 컴포넌트화
- 컴포넌트 : 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위
- 컴포넌트화 : 시스템을 구성 요소(Component)를 나누고 이를 연결하여 구축하는 것
- 컴포넌트화는 어떻게? : 소프트웨어를 여러 서비스로 분리 하는 것
라이브러리 vs 서비스
비즈니스 수행에 따른 구성
before : 기술적 계층에 따른 팀 분류
-
예) UI 팀, 비즈니스 로직 팀, 데이터베이스 팀
-
단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가함.
after : 비즈니스 수행 능력(업무 도메인)에 따른 팀 분류
- 도메인이란?
- 예) 쇼핑몰의 경우 회원/상품/배송 이 각각의 도메인이 된다.
- 하나의 온전한 시스템의 단위
- 팀이 하는 일이 하나의 서비스로 나뉘어짐 -> 마이크로서비스
- 장점으로는, 소프트웨어 스태그 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
- 이를 달성하기 위해서,
- 각 팀은 서비스에 대한 책임을 가져야 한다
- 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 한다
현명한 엔드포인트와 바보 파이프라인
다른 말로 표현하면 서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 한다.
- 마이크로 서비스에서의 프로세스간 통신은, 현명한 엔트포인트와 바보 파이프라인 접근 방식을 따른다.
이는 리눅스 파이프라인의 철학과 흡사하다. - 서비스와 서비스 사이는 느슨(decoupled)하게, 응집성은 높게
대표적인 방법.
1. REST API(HTTP)
2. 메시지 버스를 이용한 메시지 전달 (메시지 큐)
분산화 거버넌스, 분산화된 데이터 관리
중앙 집중적인 시스템은 기술을 표준화하는 경향이 있다.
"회사에서는 Java 9 와 Oracle 만 사용한다."
"간단한 리포트 만드는 서비스가 필요한데, node.js로 금방하는걸 Java를 써야되는가?"
문제 해결에 방해가 될 수 있다.
해결책
- 분산화된 시스템
- 소프트웨어 스택, 데이터베이스의 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
- 데이터에 대한 분산 책임이 따른다.
- 서비스 데이터베이스 간의 일관성이 중요하다. -> 트랜잭션 협조가 중요하다.
- 분산화된 응용 프로그램 설계 -> 도메인 주도 설계(DDD, Domain-Driven Design)
- 소프트웨어 스택, 데이터베이스의 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
도메인 경계를 분평하게 해야한다 !
진화하는 설계
- 컴포넌트 핵심 : 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 한다.
- 장점
- 모놀리스 : 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 한다.
- 마이크로서비스 : 변경한 서비스만 다시 배포하면 된다.
- 간단하고 신속한 출시 프로세스
- 단점
- 기존 서비스에 대한 변경이 이 서비스를 이용하고 있는 다른 서비스에 영향을 주는지 여부를 신경써야 한다.
서버리스
- 서버가 없다는 뜻이 아니라, 서버에 대한 고민을 안한다는 것
- 컴퓨터 없이 어떻게 애플리케이션이 돌아갈까? 따라서 애플리케이션 구축 자체에만 집중하는 것이 가능
컴퓨팅의 진화 과정
오래전에는 애플리케이션을 배포하려면 직접 하드웨어 서버를 구매해서 구성했다. 이때는 하드웨어와 소프트웨어 둘다 관리를 했어야 하며, 하드웨어의 직접적 관리는 이점도 있었지만 서버 관리에 많은 비용을 지불해야 했고 메모리 관리와 같은 불편한 점도 있었다.
이런 서버의 하드웨어 관리의 어려움을 해결해준 것이 AWS 클라우드 컴퓨팅 서비스 EC2 였다. 이로서 하드웨어 관리의 불안감을 덜 수 있게 되었다. 하지만 빌려서 구성한 서버의 소프트웨어도 보안, 업데이트, 백업와 같은 많은 관리 과정이 필요하다. 이때 이런 서버의 소프트웨어 관리의 어려움을 해결하는 방안으로 Serverless가 등장한 것이다.
- 데이터센터에서의 물리 서버 → 데이터센터에서의 가상 서버
- 활용률 증가, 프로비저닝 속도 증가, 높아진 가동 시간, 재해 복구, 하드웨어 독립성
- → 데이터센터에서의 가상 서버 → 클라우드에서의 가상 서버
- 자본 비용 → 운용 비용, 높은 확장성, 탄력적인 리소스, 빠른 속도와 민첩성, 유지보수 비용 감소, 고가용성과 내결함성
- 단점: 가상 서버 관리, 용량 및 활용률 관리, 워크로드 사이징, 고가용성과 내결함성 관리, 간헐적 작업 시 비쌈
서버리스의 이점
- 서버관리 불필요
- 유연한 확장성
- 고가용성
- 유휴 용량 없음
마이크로서비스와 서버리스는 어떤 관계가 있나요?
마이크로 서비스와 서버리스가 공통적으로 추구하는 방향은 비즈니스 로직에 집중 할 수 있다. 개발자는 서로 독립된 서비스에서 개발을 하고 서버를 신경을 쓰지 않기 때문에 오로지 개발에만 집중을 할 수 있는 환경이 구성되고 그로 인해 개발의 생산성이 올라가게 된다.
서버리스의 특징 중 하나인 무상태성(Stateless)는 무엇을 의미하나요?
서버리스는 기본적으로 현재 상태에 대한 데이터를 저장하지 않는다. 이를 무상태성이라 한다.
무상태성은 현재 시점의 상황이나 상태가 저장되지 않아 다른 상태에서 전에 있었던 상태를 알 수 없다는 것.
무상태성은 서버리스와 아주 어울리는 특징이라고 생각한다.
그래서 보통 무상태성에서는 클라이언트가 서버로부터 무언가를 요청할 때 데이터를 다 그때그때 넘기게 되면 여러 서버에서 현재상태에 대한 데이터를 저장하지 않아도 된다. 이로 인해 엄청난 확장성을 가져올 수 있다.
마이크로서비스를 구성할 때, 데이터베이스를 꼭 분리해야 하나요?
마이크로 서비스 아키텍처는 각 마이크로 서비스가 자체 도메인 데이터가 있는 별도의 데이터베이스를 가지도록 설계해야 한다. 이렇게 해야 마이크로 서비스를 독립적으로 배포하거나 확장 할 수 있기 때문
데이터베이스를 한곳에서 관리하기엔 어떤 서비스의 경우 동기화된 데이터가 필요하고 어떤 서비스는 비동기화 데이터가 필요 할 수 있다. 또 서비스의 트래픽이 커짐에 따라 한곳에서 관리하다가 문제가 발생시 서비스 전체 장애가 발생 할 수 있기 때문에 따라서 규모가 있는 서비스라면 DB까지 서비스별로 분리해서 사용하는 것이 좋다.
데이터가 한 곳에 모여있지 않고 중복되어도 괜찮은가요?
제 생각에는 데이터의 중복이 많으면 하나의 서비스로 구성하여 운영하고, 만일 성향이 다른 서비스의 경우에는 불가피하게 데이터의 복제와 중복의 허용이 어느정도는 필요하다고 생각한다.
모범 사례
모범사례로 배달의 민족 초창기 16년까지는 서비스는 분리 했지만 고성능 루비DB에다 모든 데이터를 관리하는 방식을 사용하였고, 그러다 하나의 서비스가 에러가 났는데 통합된 DB인 상황이어서 서비스까지 마비되는 사건 이후 마이크로 서비스로 변경을 시작 서비스별로 DB를 조금씩 분리하여 19년 11월에 완전한 마이크로 서비스를 완성했다고 한다.
