마이크로서비스설계 하는 법

고뱅쟁이·2020년 6월 17일
0

설계하기 전..

마이크로서비스로 설계하기 위한 적합하지 않은 시스템이 존재하기 때문에 설계 전 과연 마이크로서비스로 설계하는 것이 맞나부터 검토해야한다.

  • 마이크로서비스에 필요한 자동화나 운영에 투자하지 못하는 조직
    • 마이크로서비스로 갈 경우 시스템의 복잡성이 따라 오기 때문에 관리가 중요하다.
  • 부서 수준의 소형 애플리케이션이나 소수 사용자를 위한 애플리케이션
    • 배보다 배꼽이 더 큰 경우가 발생할 수 있다.
  • 여러 데이터 소스에서 복잡한 데이터를 취합하고 변환하는 애플리케이션
  • 모놀리식으로 관리하기에 특별히 복잡한 시스템이 아닌 시스템

목차

  1. 비즈니스 문제의 분해
  2. 서비스 세분화의 확정
  3. 서비스 인터페이스의 정의

1. 비즈니스 문제의 분해

제일 먼저 해야할 일은 문제를 기술하는 것! 기술하지 않고 나눌생각부터 하면 시작하지도 못한다.

  • 데이터 영역이 서로 어울리지 않는다면 서비스의 경계를 나누자
  • 비즈니스 문제를 기술하고 그 문제를 기술하는데 사용된 명사에 주목하라
  • 동사에 주목하라(조회해야되고...업데이트해야되고....)
  • 데이터 응집성을 찾아라(데이터의 성향을 확인)

2. 서비스 세분화의 확정

분해를 통해 데이터 모델을 단순화하고, 그 모델을 근거로 서비스를 정의한다.
적절한 서비스의 크기를 찾아서 설계한다. 처음부터 올바르게 설계하기 어렵기 때문에 점차 리팩토링하면서 발전해 나간다는 생각으로 해야한다.

  • 너무 크거나, 잘게 쪼개면 안된다.
  • 큰 마이크로서비스에서 시작해 작게 리팩토링하는게 더 낫다.
  • 서비스간 교류하는 방식(인터페이스)부터 접근한다.
  • 테이블은 3~5개이내만 소유하도록 설계한다.(너무 적어도, 너무 많아도 문제가 생긴다.)

나쁜 마이크로서비스의 징후

  • 너무 크게 나뉘어있을 때
    • 한 서비스에 다양한 종류의 비즈니스 규칙이 존재할 때
    • 한 서비스가 많은 테이블을 관리하고 있을 때
    • 복잡도가 늘어 테스트 케이스가 과다해보일 때
  • 너무 잘게 나뉘어있을 때
    • 한 기능이 수행 될 때 실행되는 서비스가 엄청나게 많다고 느낄 때
    • 마이크로서비스가 지나치게 상호 의존적일 때
    • 마이크로서비스가 단순한 CRUD의 집합이 될 때

3. 서비스 인터페이스의 정의

서비스-서비스나 클라이언트-서비스 간 인터페이스를 정의할 때 직관적이고 서비스간의 동작이 통일성이 있어야 한다.

  • REST 철학을 수용하라
  • URI를 사용해 의도를 전달하라
  • 요청과 응답에 JSON을 사용하라
  • HTTP 상태 코드로 결과를 전달하라.

참고(Reference)

profile
냥이들과 함께하는 만년 초보 개발자

0개의 댓글