요약
- 마이크로서비스 운영과 관리를 위한 플랫폼 패턴의 나머지 부분에 대해 이해함.
- 스프링 클라우드: 스프링 부트 + 넷플릭스 OSS
- 서비스 레지스트리, 서비스 디스커버리 패턴
- 서비스 단일 진입을 위한 API 게이트웨이 패턴
- BFF 패턴
- 외부 구성 저장소 패턴
- 인증/인가 패턴
메모
스프링 클라우드: 스프링 부트 + 넷플릭스 OSS
- 스프링 클라우드는 스프링 프레임워크를 개발하고 있는 피보탈에서 넷플릭스가 공개한 줄, 유레카, 히스트릭스, 리본 등의 넷플릭스 오픈소스를 스프링 부트 프레임워크 기반으로 사용하기 쉽게 통합한 것임.
- p 43~44 스프링 클라우드 서비스 연계 흐름 참고
- 마이크로서비스와 기반 서비스의 연계 흐름은 여러 개의 마이크로서비스로 시스템을 개발하면서 발생한 문제를 해결하기 위해 MSA 주요 아키텍처 패턴으로 자리 잡았음.
- 따라서 스프링 클라우드 외에 각 클라우드 제공 업체의 플랫폼에서도 유사한 형태의 서비스가 각기 존재함.
- 전반적인 패턴을 이해하는 것이 중요함.
다양한 서비스의 등록 및 탐색을 위한 서비스 레지스트리, 서비스 디스커버리 패턴
- 프론트엔드 클라이언트가 여러 개의 백엔드 마이크로서비스를 어떻게 호출할까?
- 스케일 아웃을 통해 인스턴스가 여러 개로 복제됐다면 어떻게 부하를 적절히 분산할 수 있을까?
- 이를 위한 패턴이
서비스 디스커버리 패턴임.
- 클라이언트가 여러 개의 마이크로서비스를 호출하기 위해서 최적 경로를 찾아주는 라우팅 기능과 적절한 부하 분산을 위한 로드 밸런싱 기능이 제공돼야 함.
- 넷플릭스의 OSS로 예를 들면 라우팅 기능은 줄이, 로드 밸런싱은 리본이 담당함.
- 라우터는 최적 경로를 탐색하기 위해 서비스 명칭에 해당하는 IP 주소를 알아야 함.
- 클라우드 환경에서 동적으로 변경되는 백엔드 유동 IP 정보는 제 3의 공간에서 관리하는 것이 좋음.
- 즉, 백엔드 마이크로서비스 서비스의 명칭과 유동적인 IP 정보를 매핑해서 보관할 저장소가 필요함.
- 넷플릭스 OSS의 유레카가 그 기능을 담당함.
- 이 패턴을
서비스 레지스트리 패턴이라고 함.
- 서비스 레지스트리에는 업무 처리를 위한 마이크로서비스뿐만 아니라 관리와 운영을 위한 기반 서비스의 주소도 함께 보관함.
- ex) Config 서비스, 모니터링 서비스, 추적 서비스도 모두 이름을 가지고 있기에 주소를 가지고 있어야 함.
- 쿠버네티스의 경우, 이 같은 서비스 레지스트리, 디스커버리 기능을 자체 기능인 쿠버네티스 DNS 및 서비스(Kubernetes Service)로 제공함.
서비스 단일 진입을 위한 API 게이트웨이 패턴
- 여러 클라이언트가 여러 개의 서버 서비스를 각각 호출하게 되면 매우 복잡한 호출 관계가 만들어 짐.
- 이 복잡성을 통제할 방법이 API 게이트웨이임.
- 다양한 클라이언트가 다양한 서비스에 접근하기 위해 단일 진입점을 만들어 놓으면 여러모로 효율적임.
- 다른 유형의 클라이언트에게 서로 다른 API 조합을 제공할 수 있음.
- 각 서비스에 접근할 때 필요한 인증/인가 기능을 한 번에 처리할 수도 있음.
- 정상적으로 동작하던 서비스에 문제가 생겨 서비스 요청에 대한 응답 지연이 발생하면
- 정상적인 다른 서비스로 요청 경로를 변경하는 기능이 작동되게 할 수도 있음.
- 이러한 서비스 흐름 제어를 위한 서비스 라우팅 기능은 L4 같은 하드웨어 장비로 구현할 수도 있고 소프트웨어로 구현할 수도 있음.
- 소프트웨어로 구현할 경우 API 게이트웨이가 애플리케이션 레벨의 라우팅 기능을 수행함.
- 여러 인스턴스로 부하를 분산하는 로드 밸런싱도 수행하고, 라우팅 시 필터를 둬서 라우팅 전과 후에 각각 수행되는 선행, 후행 처리, 에러 처리 등을 손쉽게 구현할 수 있음.
- API 게이트웨이 패턴은 스프링 클라우드의 스프링 API 게이트웨이 서비스(Spring API Gateway Service)라는 제품으로 구현할 수 있음.
- 간단한 스프링 애너테이션 설정만으로 손쉽게 적용할 수 있음.
- 쿠버네티스의 경우 자체 기능인 쿠버네시트 서비스(Kubernetes Service)와 인그레스 리소스(ingress resources)로 제공함.
- 외부 레거시 시스템과 단일 지점에서 서로 다른 형태의 API를 연계하는 용도로도 사용되기도 함.
BFF 패턴
- 최근에는 PC 뿐만 아니라 다양한 모바일 장비도 사용하므로 다양한 클라이언트를 고려해야 함.
- 다양한 클라이언트를 위해 특화된 처리를 위한 API 조합이나 처리가 필요함.
- 이를 위한 해결 방법으로 BFF(Backend for Frontend) 패턴이 있음.
- BFF 패턴은 API 게이트웨이와 같은 진입점을 하나로 두지 않고 프런트엔드 유형에 따라 각각 두는 패턴임.
- 웹을 위한 API 게이트웨이
- 모바일을 위한 API 게이트웨이 등
- 클라이언트 종류에 따라 최적화된 처리를 수행할 수 있게 구성할 수 있음.
- 통합적인 API 게이트웨이를 둠으로써 공통적인 인증/인가, 로깅 등의 처리를 통제하는 구조로 구성할 수도 있음.
외부 구성 저장소 패턴
- 애플리케이션 구성 정보 설정에 관련된 패턴임.
- 데이터베이스 연결 정보, 파일 스토리지 정보 같은 내용을 애플리케이션에 포함하면 변경 시 반드시 재배포 해야하는데, 이 경우 서비스를 중단해야 함.
- 마이크로서비스가 사용하는 자원의 설정 정보를 쉽고 일관되게 변경 가능하도록 관리할 필요가 있음.
- 이 방법이
외부 저장소 패턴임.
- 외부 저장소는 각 마이크로서비스의 외부 환경 설정 정보를 공동으로 저장하는 백업 저장소임.
- PaaS 솔루션 개발사인 Heroku 에서 발표한 Twelve-Factor 라는 클라우드 네이티브 애플리케이션을 만들기 위한 체크리스트가 있는데, 여기서 컨피그(Config) 라는 원칙을 언급함.
- 이는 애플리케이션이 배포되는 환경(스테이징, 프로덕션, 개발, 테스트 환경)이 매번 달라지기 때문에 코드에서 사용하는 환경 설정 정보는 코드와 완전히 분리되어 관리해야 한다는 원칙임.
- 이렇게 분리해야할 환경 정보들은 분리해서
환경 변수로 사용한다.
- 스프링 클라우드 컨피그(Spring Cloud Config)를 이용하면 이러한 환경 정보를 코드에서 분리하고 컨피그 서비스를 통해 런타임 시 주입되게 할 수 있음.
- Git 같은 별도의 형상관리 리포지토리에 보관하고 컨피그 서비스는 해당 서비스에 특정 환경에 배포될 때 적절한 환경 정보를 형상관리 리포지토리에서 가져와 해당 서비스에 주입함.
- 쿠버네티스에서는 이러한 외부 구성 저장소 패턴을 쿠버네티스 컨피그맵(COnfigMap)으로 제공함.
인증/인가 패턴
- 여러 마이크로서비스에 대한 인증/인가 접근 제어는 어떻게 구현하는 가?
- 각 서비스가 모든 인증/인가를 중복 구현하는건 비효율적임.
- 따라서 마이크로서비스 인증/인가를 처리하기 위해 일반적으로 다음과 같은 패턴을 활용함.
- 중앙 집중식 세션 관리
- 마이크로서비스 각자의 서비스에 세션을 저장하지 않고 공유 저장소에 세션을 저장하고, 모든 서비스가 동일한 사용자 데이터를 얻게함.
- 클라이언트 토큰
- 세션은 중앙 서버에 저장되고, 토큰은 사용자의 브라우저에 저장됨.
- 토큰은 사용자의 신원 정보를 가지고 있고, 서버로 요청을 보낼 때 전송되므로, 서버에서 인가 처리를 할 수 있음.
- API 게이트웨이를 사용한 클라이언트 토큰
- 인증/인가 처리하기 위한 별도의 전담 서비스를 만들어서 다른 서비스의 인증/인가 처리를 위임할 수 있음.
- 이를 인증 서비스(auth service)라고 함.
- API 게이트웨이와 연동해서 인증/인가를 처리함.
댓글