<책 정리> 도메인 주도 설계로 시작하는 마이크로서비스 개발 (3)

다양한 서비스의 등록 및 탐색을 위한 서비스 레지스트리,  서비스 디스커버리 패턴

클라이언트가 여러 개의 마이크로 서비스를 호출하기 위해서는 최적 경로를 찾아주는 라우팅 기능과 적절한 부하 분산을 위한 로드 밸런싱 기능이 제공되어야 한다.

 

라우팅의 정보를 클라이언트가 가지고 있으면 동적으로 변경되는 백엔드의 유동 IP를 매번 받아 전송해야 하는데 제3의 공간에서 이러한 정보를 관리하는 패턴을 서비스 레지스트리 패턴이라고 한다

 

서비스 인스턴스가 로딩 될 때 자신의 서비스 이름과 할당된 IP주소를 레지스트리에 등록하고 클라이언트가 해당 서비스를 호출할 때 라우터가 레지스트리를 검색해 매핑된 정보를 확인한 후 호출한다

 

서비스 레지스트리에는 관리와 운영을 위한 기반 서비스의 주소도 함께 보관된다. 예를 들어 Config 서비스, 모니터링 서비스, 추적 서비스 등이다

 

쿠버네티스의 경우 이 같은 기능을 쿠버네티스 DNS 및 서비스로 제공한다

 

서비스 단일 진입을 위한 API 게이트 웨이 패턴

다양한 클라이언트가 다양한 서비스에 접근하기 위해서는 단일 진입점을 만들어 놓으면 효율적이다. 이는 하드웨어와 소프트웨어 둘 다로 구현할 수 있는데 소프트웨어로 구현할 경우 API 게이트웨이가 애플리케이션 레벨의 라우팅 기능을 수행한다.

 

API 게이트 웨이는 이 외에도 다음과 같은 기능을 제공한다

- 레지스트리 서비스와 연계한 동적 라우팅, 로드 밸런싱

- 보안, 권한 서비스와 연계한 인증/인가

- 로그 집계 서비스와 연계한 로깅

- 메트릭 :  ex) 에러율, 호출 빈도 등

- 트레이싱 서비스와 연계한 서비스 추적

- 모니터링 서비스와 연계한 장애 격리

 

쿠버네티스의 경우 쿠버네티스 서비스와 인그레스 리소스로 제공한다

 

BFF 패턴

최근에는 PC 뿐만 아니라 다양한 모바일 사용을 통한 다양한 클라이언트들이 있다. BFF 패턴은 API 게이트웨이와 같은 진입점을 하나로 두지 않고 프런트엔드에 따라 각각 API를 다르게 제공하는 패턴이다. 각 프런트엔드에 대한 처리만 수행하는 BFF를 두고 이후에 통합적인 API 게이트웨이를 둘 수도 있다

 

외부 구성 저장소 패턴

다음은 애플리케이션 구성 정보 설정에 관련된 패턴이다. 외부 저장소는 각 마이크로서비스의 외부 환경 설정 정보를 공동으로 저장하는 백업 저장소이다. 클라우드에서 운영되는 애플리케이션은 특정한 배포 환경에 종속된 정보를 코드에 두면 안된다는 원칙이 있는데 배포 환경이 변경됐을 때 애플리케이션 또한 변경해야 하기 때문이다. 

 

분리해야 할 환경 정보로는 데이터베이스 연결 정보, 배포 시 변경해야 할 호스트명, 백엔드 서비스의 연결을 위한 리소스 정보 등이 있다.

 

쿠버네티스의 경우 쿠버네티스 컨피그 맵으로 제공한다

 

인증/인가 패턴

각 서비스 모두 인증/인가를 중복으로 구현한다면 비효율적이다.  따라서 마이크로서비스는 다음과 같은 패턴을 활용한다.

 

중앙 집중식 세션 관리

기존 모노리스 방식에서 가장 많이 사용했던 방식은 서버 세션에 사용자의 로그인 정보 및 권한 정보를 저장하고 애플리케이션의 인증/인가를 판단하는 것이다. 그러나 마이크로서비스는 사용량에 따라 수시로 수평 확장할 수 있고 로드 밸런싱 처리가 되기 때문에 세션 데이터가 손실될 수 있다. 따라서 공유 저장소에 세션을 저장하고 모든 서비스가 동일한 사용자 데이터를 얻게한다. 이때 세션 저장소로 레디스를 사용한다

 

클라이언트 토큰

세션과 달리 토큰은 사용자의 브라우저에 저장된다. 토큰은 사용자의 신원 정보를 가지고 있고 서버로 요청을 보낼 때 전송되기 때문에 서버에서 인가 처리를 할 수 있다. 가장 많이 사용하는 토큰은 JWT이다.

JWT 흐름도

 

API 게이트웨이를 사용한 클라이언트 토큰

사용자 인증 프로세스는 토큰 인증 프로세스와 유사하다. 차이점은 API 게이트 웨이가 외부 요청의 입구로 추가된다는 것이다. 또한 인증/인가를 처리하기 위한 별도의 전담 서비스를 만들어서 다른 서비스의 인증/인가 처리를 위임할 수 있다