web/마이크로서비스

마이크로서비스 조립성 및 정리

반응형

마이크로서비스의 조립성은 서비스 디자인 원칙의 하나이다. 서비스를 어떻게 디자인해서 효율적으로 할 수 있는 원칙을 이야기하며 크게  두 가지 요소로 나뉜다.


1. 오케스트레이션(Orchestration)

- 여러개의 서비스를 모아 하나의 완전한 기능을 만드는 서비스가 마이크로 서비스이다. 그럴 경우 중앙에서 두뇌 역할을 하는 오케이스트레이터가 여러 서비스를 묶어서 조율할 수 있어야 한다. 이 오케스트레이터는 외부에 노출되는 접점이다.

- 예를들어 주문이라는 서비스가 들어오면 고객 서비스, 상품 서비스, 배송 서비스에 역할을 분배하여 요청하는 중재자를 의미한다.


2. 연출 (Choreography)

- 특정한 서비스가 실행되면 메시키큐에 producer가 이벤트를 넣고 그 곳을 바라보면서 대기하던 consumer들이 자신에 맞는 이벤트 동작을 실행하는 것을 말한다. 

- ESB에 메시지가 푸시되면 그 이후에 처리되는 모든 결정은 메시지를 소비하는 서버에 의해 자동으로 결정된다.



마이크로 서비스의 현명한 종단점 개수는 몇 개일까?

- 마이크로 서비스를 만들 때 종단점의 수는 그렇게 중요하지 않다. 필요에 따라 여러개 일수도 있고 하나가 될 수도 있다.

- 하지만 서로 연결돼서 공통의 데이터를 사용하거나 비슷한 업무를 처리하는 부분을 모두 종단점으로 구분하게 된다면 결과적으로 동일한 부분을 잘게 쪼개놓은 꼴이된다. 결국 성능적으로 더 떨어진 시스템이 될 수도 있다.

- 결론적으로 종단점의 개수는 중요한 것이 아니고 마이크로서비스 크기에 적합하게 경계 지어진 컨텍스트를 적절하게 설계하는 것이 중요하다.


가상머신에 여러개의 마이크로서비스 

- 하나의 가성머신에 여러 마이크로서비스를 올려놓을 수 있다. 이는 용량을 포함하는 리소스가 충분하고 별도의 서비스로 동작하고 서비스 요구사항 (OS, JDK 등등)이 서로 충돌하지 않는다면 가능하다.

- 운영하는 서비스의 인프라의 가용성 특징, 배포 등을 잘 따져가며 설계해야한다.


마이크로서비스의 데이터 스토어 공유 

- 마이크로서비스에서 데이터 스토어를 공유하는 것은 처음에는 별로 어려움이 없어보이지만, 서비스가 많아지고 테이블이 많아지고 하다보면 서비스간에 결합이 생기게 된다. 그러면 두 개의 마이크로서비스도 결국 결합이 생기게 된다. 그러면 효율적인 마이크로서비스라고 할 수 없다.

- 데이터베이스 서버를 별도로 두기에 여유가 없다면 데이터베이스 서버의 스키마를 구분해서 사용해도 된다.

- 또 다른 방법으로 하나의 트랜잭션 관리가 필요한 데이터베이스는 별도로 분리해서 마이크로서비스로 관리하는 것이다.


분산 트랜잭션 시나리오

- 마이크로서비스에서 로컬 트랜잭션만을 이용하고 분산 트랜잭션을 피하는 것이 이상적이다.

- 하나의 서비스에서 식사 예약을 한다고 가정해봤을 때 식사 예약을 완료하기전에 픽업 예약 서비스를 해당 마이크로서비스에 요청한다고 했을 때 픽업 예약은 완료되었지만 식사 예약이 실패할 경우 픽업만 예약되는 사태가 발생할ㄹ 수 있다. 이런 문제를 해결하기 위해 픽업 예약을 식사 예약이 성공적으로 끝나고 나면 보내는 방법이 있으나 메시지를 보내고 나서 갑자기 실패하는 경우 등에 대한 문제를 해결하기에는 부족하다.


서비스 종단점 설계 고려사항

- 마이크로서비스에서 서비스 설계는 Contract Design (계약설계), Protocol Selection (프로토콜 선택) 이라는 두 가지 핵심요소로 나뉜다.

1. 계약 설계

- 서비스 설계에서 가장 주요한 원칙은 단순함이다. 서비스는 소비자가 소비할 수 있게 설계되어야한다. 복잡한 서비스 계약은 서비스의 사용성을 떨어트린다.


2. 프로토콜 선택

- 마이크로서비스는 SOA(서비스 지향 아키텍처)와 동일하게 HTTP/SOAP와 메시징 서비스 상호작용을 위한 기본 서비스 프로토콜을 따른다.

- 메시지 방식이나 REST 방식을 사용한다.

- API 문서는 Swagger 등을 사용한다.


공유 라이브러리 처리

- 마이크로서비스의 기본원칙은  자율성과 자기 완비성이다. 그래서 다른 서비스에서 같은 라이브러리가 필요한 경우가 있을 있다.

만약 동일 코드나 라이브러리를 서로 다른 마이크로서비스에서 가지게 된다면 중복 문제가 있지만 그렇지 않으면 한쪽 마이크로서비스에 다른 마이크로서비스가 의존하게 되는 문제가 발생할 있다. 

만약 동일한 코드를 둘다 가지고 있게 된다면 모든 지식은 하나의 시스템 안에서 오직 하나의 모호하지 않은 권위를 가진 표현으로 존재해야 한다는 DRY 원칙을 어긋나게 된다.

하지만 그렇다고 공통 서비스를 또다른 마이크로서비스로써 값을 참조하게 한다면 또다른 복잡도를 가질 있기 때문에 상황에 맞게 선택해서 진행하는것이 좋다.


API 게이트웨이

- 출국관리 애플리케이션에서 체크인, 라운지관리, 탑승수속등의 기능이 필요하다고 가정해보자. 각 서비스들은 별도의 API로 개발되어 있다. 하지만 이는 출국 관리 애플리케이션에서 봤을 때 하나의 웹 애플리케이션에 담아서 관리할 필요성이 있다고 느껴진다. 이럴 경우에 마이크로서비스(API들)를 연결해주는 컨테이너 웹 애플리케이션이나 Placeholder가 필요한데 이 경우 별도의 API 게이트 웨이를 만들어서 사용할 수 있다.

- 요청에 따라 모든 데이터를 한번에 전달하는 API는 쓸데없는 오버헤드를 발생시킬 수 있다. 그래서 필요한 데이터만 필드에 보내줄 수 있다. 하지만 그럴 경우 필요에 따라 전달되는 형식이 바뀌어야한다. 그래서 API 게이트웨이에서 데이터 명세에 따라 필요 데이터만 클라이언트 쪽으로 내보내주도록 만들어서 기존의 API들은 원래 하던대로 동작해도 무관하게 설계할 수 있다.







반응형