[MSA] MSA의 BFF 패턴, 외부 구성 저장소 패턴, 인증 인가 패턴이란?

안녕하세요. 저번 글에서는 Spring cloud 적용에 사용되는 컴포넌트 중 하나인 Eureka에 관해서 글을 작성해 보았습니다. 이번글은 BFF 패턴에 관해 글을 작성해보도록 하겠습니다.

BFF (Backend for Frontend) 패턴이란?

최근에는 PC뿐만 아니라 다양한 모바일 장비를 사용하기 때문에 다양한 클라이언트를 고려해야 합니다. 이처럼 다양한 클라이언트를 위해서는 특 화된 처리를 위한 API 조합이나 처리가 필요합니다. 이를 위한 해결 방법으로 BFF(Backend for Frontend) 패턴이 존재합니다.

 

BFF 패턴은 API 게이트웨이와 같은 진입점을 하나로 두지 않고 프론트엔드의 유형에 따라 각각 두는 패턴입니다. 프론트엔드를 위한 백엔드라는 의미로 BFF이라고 부릅니다.

 

각 프론트엔드에 대한 처리만 수행하는 BFF를 두고 이후에 통합적인 API 게이트웨이를 둠으로써 공통적인 인증/인가, 로깅 등의 처리를 통제하는 구조로 작성할 수 있습니다.

외부 구성 저장소 패턴

애플리케이션 구성 정보 설정에 관련된 패턴입니다.

 

이 패턴에서는 "컨피그(Config)"라는 원칙을 언급합니다. 이것은 애플리케이션이 배포되는 환경(스테이징, 프로덕션, 개발, 테스트 환경)이 매번 달라지기 때문에 코드에서 사용하는 환경 설정 정보는 코드와 완전히 분리되어 관리해야 한다는 원칙을 가리킵니다.

 

이를 좀 더 구체적으로 풀ㄹ어서 설명하면 클라우드에서 운영되는 애플리케이션은 특정한 배포환경에 종속된 정보를 코드에 두면 안된다는 원칙입니다.

 

왜냐하면 이러한 정보를 애플리케이션에 두면 배포 환경이 변경되었을 때 애프리케이션 또한 변경해야 하기 때문입니다. 이렇게 분리해야할 환경 정보로는 데이터베이스 연결 정보, 배포 시 변경해야할 호스트명, 백엔드 서비스의 연결을 위한 리소스 정보 등이 있습니다. 또한 서비스가 가동되는 개발 서버, 테스트, 운영 서버의 IP 주소와 포트 정보 등을 분리해서 환경 변수로 사용합니다.

스프링 컨피그 서비스 사용을 위한 구성도

위의 그림과 같이 스프링 클라우드 컨피그를 이용하면 이러한 환경 정보를 코드에서 분리하고 컨피그 서비스를 통해 런타임 시 주입되게 할 수 있습니다. 환경 정보는 Git 같은 별도의 형상관리 리포지토리에 보관하고 컨피그 서비슺는 해당 서비스에 틁정환경에 배포될 때 적절한 환경 정보를 형상관리 리포지토리에서 가져와 해당 서비스에 주입합니다.

인증/인가 패턴

여러 마이크로서비스에 대한 인증/인가 등 접근 제어는 어떻게 구현해야 할까요?

 

각 서비스가 모두 인증/인가를 중복으로 구현한다면 비효율적일 것 입니다. 따라서 마이크로서비스 인증/인가를 처리하기 위해서는 일반적으로 다음과 같은 패턴을 활용해야 합니다.                                                    

 

중앙 집중식 세션 관리

 

마이크로 서비스는 사용량에 따라 수시로 수평 확장할 수 있고 로드 밸런싱 처리가 되기 떄문에 세션 데이터가 손실될 수 있습니다. 따라서 마이크로 서비스는 각자의 서비스에 세션을 저장하지 않고 공유 저장소에 세션을 저정하고 모든 서비스가 동일한 사용자 데이터를 얻게 합니다. 따라서 이때 세션 저장소로 보통 레디스나 맴캐시드를 사용합니다.

 

클라이언트 토큰

 

 세션은 중앙 서버에서 저장되고 토큰은 사용자의 브라우저에 저장됩니다. 토큰은 사용자의 신원 정보를 가지고 있고 서버로 요청을 보낼 떄 전송되기 때문에 서버에서 인가 처리를 할 수 있습니다.

 

1. 브라우저가 서버에 사용자명과 패스워드로 인증 요청을 합니다.

2. 서버는 인증 후 토큰을 생성하고 브라우저에 토큰에 사용자 정보의 인증/인가 정보를 포함에 전송합니다.

3. 브라우저는 서버 리소스를 요청할 때 토큰을 함께 보냅니다. 서버의 서비스는 토큰 정보를 확인한 후 자원 접근을 허가합니다.

 

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

 

사용자 인증 프로세스는 토큰 인증 프로세스와 유사합니다. 차이점은 API 게이트웨이가 외부 요청의 입구로 추가된다는 것 입니다.

또한 인증/인가를 처리하기 위한 별도의 전담 서비스를 만들어서 다른 서비스의 인증/인가 처리를 위임할 수 있습니다. 이러한 서비스를 인증 서비스라 하는데, API 게이트웨이와 연동해서 인증/인가를 처리합니다. 인증 서비스를 이용하면 각 리소스 서비스가 자체적으로 인증/인가를 처리하지 않고 업무 처리에 집중할  수 있습니다.

 

1. 클라이언트가 리소스 서비스에 접근을 요청하면 API  게이트웨이는 인증 서비스에게 전달합니다.

2. 인증 서비스는 해당 요청이 인증된 사용자가 보낸 것인지(인증), 해당 리소스에 대한 접근 권한이 있는지(인가) 확인하고, 모두 확인하고 나면 리소스에 접근 가능한 증명서인 액세스 토큰을 발급합니다.

3. 클라이언트는 다시 액세스 토큰을 활용해  접근을 요청합니다.

4. 그럼  각 리소스 서비스는 이러한 요청이 액세스 토큰을 포함하고 있는지 판단해서 리소스에 대한 접근을 허용합니다.

 

이번 글은 MSA의 BFF 패턴, 외부 구성 저장소 패턴, 인증 인가 패턴에 관해 글을 작성해 보았습니다. 다음 글은  MSA의 장애 및 실패 처리를 위한 서킷 브레이커 패턴 및 모니터링과 추적 패턴에 관한 글을 작성해 보도록하겠습니다. 감사합니다.