마이크로 서비스 설계 시 주의 사항

올바른 마이크로 서비스 세분화

• 광범위하게 시작하고 더 작은 서비스로 리팩터링
  → 모든 것을 마이크로 서비스로 만들어 버리는 것을 주의
• 서비스 간 교류하는 방식에 중점
• 문제 도메인에 이해가 깊어지면서 서비스 책임이 계속 변화

 

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

• 책임이 너무 많은 서비스
• 다수 테이블에 걸쳐 데이터를 관리하는 서비스
  • 마이크로 서비스는 자기가 관리하는 데이터에 대한 기록
  • 여러 테이블에 데이터를 유지하거나 서비스의 데이터베이스 외부에 있는 테이블에 접근하면 서비스가 너무 크다는 징조
  • 마이크로 서비스는 3~5개 이하의 테이블 소유 권장
    → 이보다 많으면 서비스가 너무 많은 책임을 담당할 가능성 ↑
• 테스트가 너무 많은 서비스
  • 서비스가 적은 수의 테스트 케이스로 시작해서 수백 개의 유닛 테스트와 통합 테스트로 끝나는 서비스가 있다면 리팩토링이 필요할 수 있음

 

너무 작은 서비스

• 문제 도메인의 한 부분에 속한 마이크로 서비스가 너무 많이 번식
  • 흔한 징후 ⇒ 애플리케이션에 수십 개의 마이크로 서비스가 존재하고 각 서비스가 하나의 데이터베이스 테이블과 통신할 때 나타남
• 마이크로 서비스가 지나치게 상호 의존적
  • 하나의 사용자 요청을 완료하기 위해 계속 서로 호출
• 마이크로 서비스가 단순한 CRUD 서비스 집합
  • CRUD 관련 로직만 수행할 경우 너무 세분화

 

서비스 인터페이스 설계

• REST 철학을 수용
  • HTTP Method를 사용하면서 서비스 호출 프로토콜로 HTTP를 수용
  • HTTP Method를 기반으로 기본 행동 양식을 모델링
• URI를 사용하여 의도 전달
  • 서비스의 엔드포인트로 사용되는 URI는 문제 영역에 존재하는 다양한 자원을 기술하고 자원 관계에 대한 기본 메커니즘을 제공
• 요청과 응답에 JSON 사용
  • JSON은 초 경량 데이터 직렬화 프로토콜로 XML보다 훨씬 사용하기 쉬움
• HTTP 상태 코드로 결과 전달
  • 상태 코드를 익히고 모든 서비스에 일관되게 사용하는 것이 중요