[MSA] 클루터 MSA 도입 과정

1) 도메인 분리 및 클라우드 환경 배포

• 클루터가 제공하는 핵심 기능을 중심으로 유저 / 알림 / 트윗으로 도메인을 분리함
• 도메인별 서버를 구성해 사내 인프라를 사용해 쿠버네티스 클러스터에 배포함
• 참고
  • https://helloworld.kurly.com/blog/ddd-msa-service-development/

 

2) 이후 구조 수립 과정

A. 초기 구조

설명

• API 게이트웨이(스프링 클라우드 게이트웨이), 서비스 레지스트리(유레카), Config 서버(스프링 클라우드 컨피그)와 중앙 저장소(github repository)로 구성하였음
• 마이크로서비스간 통신은 Feign Client를 사용한 HTTP 통신을 수행하도록 구성하였음

API 게이트웨이 도입 이유

> 기존 구조의 단점

• 서비스의 개수가 증가함에 따른 API 엔드포인트 관리의 어려움
• 서비스별 인증 로직 구현의 번거로움과 코드 중복 발생

> API 게이트웨이 도입 시 장점

• 외부에서 바라보는 API 엔드포인트를 단일화시킴
• API 엔드포인트별 공통 인증 처리 가능함
• 여러 마이크로서비스 호출을 포함하는 하나의 API 요청에 대한 기록과 관리가 용이함

Config 서버 도입 이유

• 각 서비스의 설정을 중앙 서버인 Config 서버에서 관리하도록 하여 서비스의 설정이 변경 되었을 때 서버 재배포를 거치치 않아도 됨
• 코드와 설정 파일을 분리하도록 함

 

B. 두번째 구조

설명

• Config 서버를 삭제하였음

Config 서버를 삭제한 이유

• 인프라팀으로부터 Config 서버를 거치는 구조가 스토브 플랫폼 내에서의 구조와 상이하여 사내 인프라 구성에 적합하지 않다는 피드백을 받았음
• 스토브는 모든 빌드 커맨드, 실행 커맨드, 필요한 설정(포트, DB 정보 등)을 선언형으로 관리하는게 원칙임
• 따라서 Config 서버를 삭제하고 마이크로서비스 각각이 설정 파일을 개별적으로 가지고 있는 형태로 구성하였음

 

C. 최종 구조

설명

• 서비스 레지스트리(유레카)를 삭제하였음

서비스 레지스트리를 삭제한 이유

• 현재 인프라 구성인 쿠버네티스 환경에 더 적합하게 구조를 개선하도록 하기 위함
• 현재 쿠버네티스 환경은 다음과 같음

• 위와 같은 쿠버네티스 환경에서는 별도의 서비스 레지스트리 서버가 필요하지 않음
• 이유
  • 서비스 레지스트리가 필요했던 이유는 컨테이너 기반 배포 시 서비스의 IP가 동적으로 변경되는 경우가 많으므로 MSA 구조에서 서비스 클라이언트가 서비스를 호출할 때 서비스의 위치(IP주소와 포트번호)를 알아낼 수 있도록 하기 위함이었음
  • 쿠버네티스는 Service가 생성되면 [service-name].[service-namespace].svc.cluster.local 이라는 DNS명으로 쿠버네티스 내부 DNS에 등록되어 쿠버네티스 클러스터 내부에서는 해당 DNS명으로 서비스간 접근이 가능함
  • 따라서 해당 DNS명을 알고 있다면, 별도의 서비스 레지스트리가 필요하지 않게 됨
• 참고
  • https://nice-engineer.tistory.com/entry/Kubernetes-Service-Discovery

 

서비스 레지스트리를 삭제함에 따라 게이트웨이의 application.yml 설정 파일에서 변경할 사항은?

gateway: 
	routes: 
		- id: notification-service 
			uri: http://clutter-server-notification-service.sgs-dev:8080 # 클러스터 내부 도메인명으로 변경
			predicates: 
				- Path=/api/notification/**

• 요청을 라우팅시킬 마이크로서비스의 URI에 클러스터 내부 도메인명을 명시함

 

📌 성장한 부분 및 개선 포인트

배운 점 및 깨달은 점

• 인프라 구성에도 답이 정해져 있는 것은 아니고, 주어진 환경에 더 적합한 방식이 있는 것일 뿐이다.
• 사내 인프라 구조에 맞게 인프라를 설계해야 함을 알게 되었다.
• 주어진 인프라 환경에 대한 이해를 바탕으로 인프라를 설계해야 함을 알게 되었다.

개선 포인트

• MSA 환경에서 안정적인 서비스 운영을 위한 방안
  • 로깅 및 모니터링 시스템 도입
  • 스프링 클라우드 슬루스와 집킨을 이용한 분산 추적
  • 스프링 클라우드 스트림을 사용한 이벤트 기반 아키텍처