Overview

SW마에스트로에서 본 프로젝트를 MSA로 설계하며 인증/인가를 어떻게 처리해야할 지 고민하였다.

첫 번째로 우리가 생각한 가장 단순한 방법은 클라이언트-마이크로서비스 간 직접적으로 통신하게끔 하고 모든 마이크로서비스에 JWT 의존성을 구현한 후 각각의 마이크로서비스에서 토큰에 대한 인증/인가를 수행하는 방법이었다.
하지만 모든 마이크로서비스에 동일한 의존성 추가와 동일한 검증 로직을 구현해주어야 한다는 불편함과 JWT 검증을 위한 시크릿 키를 어떻게 모든 마이크로서비스가 공유할 것인가 대한 문제점이 있었다.

두 번째로 고민한 방법은 인증/인가를 수행하는 마이크로서비스 하나에만 JWT 의존성 추가작업과 검증 로직을 구현하고 각 마이크로서비스는 인가가 필요한 API call이 들어오면 동기적으로 인증/인가 마이크로서비스로 해당 토큰이 유효한 지 확인하는 방법이었다. 하지만 이 방법의 경우 인증/인가가 필요한 API를 클라이언트가 호출할 때마다 매번 동기적으로 인증/인가 마이크로서비스로 요청을 보내 확인해 결합도가 증가한다는 문제점이 있었다.

그래서 우리는 API Gateway 패턴을 도입하여 위와 같은 문제점을 해결하였다.

API Gateway 패턴이란?

API Gateway 패턴이란, 클라이언트로부터 각 마이크로서비스마다 진입점을 열어주는 것이 아닌 API Gateway를 통해 단일진입점을 구현하고 이를 통해 다양한 서비스에 접근하도록 한 패턴을 의미한다.

API Gateway를 통해 단일진입점을 구현하면 여러모로 효율적인 처리가 가능해진다.

인증 / 인가

인증 / 인가를 각 마이크로서비스에서 처리하는 것이 아닌 API Gateway에서 한번에 처리 가능하다.

API Composition

필요에 따라 다른 유형의 클라이언트에게 서로 다른 API 조합을 제공할 수 있다.

이와 관련하여 API Gateway를 여러 개 두어 클라이언트 유형(모바일, 웹, TV 등)에 따라 단일진입점을 열어두는 BFF Pattern이 있다.
https://fe-developers.kakaoent.com/2022/220310-kakaopage-bff/
https://www.youtube.com/watch?v=95L-_82N1vg

동적 라우팅, 로드밸런싱

서비스 요청에 대한 응답 지연이 발생하면 정상적인 다른 서비스로 요청 경로를 변경하여 기능이 작동하도록 할 수 있다.

로깅

요청/응답 데이터, API 소비자 정보나 에러율, 지연시간, 호출 빈도 등 다양한 매트릭 정보에 대해 로깅을 남길 수 있다.

장애 격리

서킷 브레이커 패턴을 적용하여 장애가 발생한 서비스를 격리할 수 있다.

단점

API Gateway를 사용하면 가능한 추가 단일 실패 지점이 만들어진다.

클라이언트는 단일진입점을 통해 요청을 보내므로 API Gateway가 죽으면 모든 마이크로서비스가 전체 다운될 것이다.

API Gateway가 개발 병목 현상이 될 위험이 있다.

개발자는 각 마이크로서비스의 Endpoint를 노출하기 위해 API Gateway를 업데이트해야 한다. API Gateway 업데이트 프로세스가 가볍지 않다면 개발자는 게이트웨이를 업데이트하기 위해 줄을 서서 기다려야 한다.

추가 네트워크 호출로 인해 응답 시간 증가로 이어질 수 있다.

하지만 이 추가 호출은 클라이언트 인터페이스가 일반적으로 내부 마이크로서비스를 너무 빈번하게 직접 호출하는 것보다는 적은 영향을 준다.

API Gateway 솔루션

API Gateway는 다양한 솔루션을 통해 구현할 수 있다.

• Spring Cloud Gateway
• Amazon API Gateway
• Kong Gateway
• 쿠버네티스 자체 기능 (service, ingress)
• 등등..

우리는 마이크로서비스로 설계, 개발하며 많은 학습비용을 치뤘다.
Spring Cloud Gateway를 사용하고 싶었으나 API Gateway를 개발하는 것 마저 학습하기에는 시간이 부족하여 우리는 Amazon API Gateway를 통해 API Gateway를 구현하였다.

Amazon API Gateway와 Service Mesh를 결합한 인증 / 인가 구조 예시

우리는 MSA로 설계, 개발하며 프론트-백엔드 간 만나는 최전선은 API Gateway로, 내부 마이크로서비스들 간 통신로직을 제어하기 위해서 service mesh 솔루션인 istio를 사용하였다.

클라이언트는 API를 이용하기 위해서 앞단의 API Gateway를 거치도록 설계하였고, API Gateway에서 Lambda Authorizer를 통해 JWT 토큰을 검증하는데 검증된 토큰의 페이로드에 저장되어있는 대칭키로 암호화한 사용자 식별값을 다시 복호화하여 뒷단의 마이크로서비스에 전달되도록 구현하여 인증 / 인가를 통합적으로 수행했다.
이를 통해 마이크로서비스 간 결합도가 낮은 구조가 되었다.

참고자료

https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

https://nginxstore.com/blog/api-gateway/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95%EC%9D%84-%EC%9C%84%ED%95%9C-api-gateway-%ED%8C%A8%ED%84%B4-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0/

도메인 주도 설계로 시작하는 마이크로서비스 개발