MSA 아키텍쳐와 API Gateway의 이해 (1)

글을 시작하기에 앞서

API 자동화 테스트를 구축하면서 어떻게 하면 Server-side에서 통합 테스트 시나리오를 구현할 수 있을까 고민했었다. 테스트 대상 프로덕트는 MSA를 지향하고 API gateway로 API 서버들을 엔드포인트를 통합하고 있었다. 따라서 로그인 기반의 API 서버를 테스트하려면 gw에서 정상적인 인증/인가 단계를 거쳐야했다.

당시에 api gateway 뒷단에서 인증 서버가 JSON Web token 방식으로의 전환을 위해 인증 개편을 진행하며 여러가지 노운이슈가 잔존했다. 자동화를 구축하는데 있어서 몇가지 문제를 발견했다. 내가 테스트 하고자 하는 대상은 API gateway 뒷단에 있는 API 서버였지만, 실제 User가 호출하는 엔드 포인트는 api gateway를 거친 통합 테스트 시나리오가 필요했다.

API 서버를 테스트하기 위해 api gw와 인증을 기술적으로 더 이해하기 위해 공부하고, 정상적인 사용자 인증 방식을 이해하기 위해 개발 스펙에 대해 서버 개발자들과 이야기를 많이 나누었다. 자동화 도중 token의 exp(유효기간)가 만료되는 문제도 있어서 JSON Web token 방식을 심층적으로 이해하고, payload를 parsing해서 exp의 validation을 판별하여 token을 재발급 받고 테스트를 위한 API를 호출 전 헤더에 배치하는 자동화 로직을 만들었다.
(POSTMAN의 pre-script에서 API를 호출하기 전 token의 exp를 먼저 판별하는 방식을 사용했습니다.)

이때 경험으로, 경량화된 서비스 개념과 미들웨어의 역할에 대해 더 알고싶어졌다. QA Engineering에 있어서도 자동화를 한다면, 자동화 대상이 되는 서비스의 아키텍처를 이해하는 것이 필수적이라고 생각한다. 아키텍처를 잘 몰라도 자동화는 할 수 있다. 하지만 반복적인 작업을 자동화하는 것과는 별개로 그것이 프로덕트 품질을 얼마나 효율적으로 컨트롤 할 수 있는지, 그래서 얼마나 리스크를 식별하고 나아가 줄일 수 있는지는 완전히 다른 이야기가 될 수 있다고 생각한다. 따라서 이번 글에서는 MSA 아키텍처와 API gateway에 대한 내용을 정리해보려고 한다.

MSA 그리고 API Gateway

• MSA(Micro Service architecture)
  - 전통적인 웹 시스템 개발 스타일의 Monolithic Architecture에서 대규모 분산 웹시스템에 적합하게 경량화된 개념이다. 근간은 SOA(Service Oriented Architecture: 서비스 지향 아키텍처)에 두고 있다. 각 컴포너트를 서비스라는 개념으로 정의하고, 서비스는 일반적으로 도메인(업무)의 경계를 따른다.

• API gateway
  - api 서버 앞단에서 모든 api 서버들의 엔드포인트를 단일화하여 통합하고 API에 대한 인증/인가 기능부터 메세지에 따라서 여러 서버로 라우팅하는 기능까지 다양한 기능을 추가로 제공한다. API gateway는 JSON/REST 기반의 최소한의 기능을 처리하는 경량화 서비스이다. MSA 아키텍쳐에서 API gateway가 어떤 역할들을 하는지 알아보자

MSA에서 API Gateway의 주요 기능

1. 마치 프록시 서버처럼 API 앞단에서 end point를 통합한다.

- 마이크로 서비스 아키텍처의 문제점 중의 하나는 서비스가 다른 서버들에 분리되기 때문에, API의 
end point가 각기 다르다는 것이다. 즉 서버의 URL이 모두 다르게 된다. API가 두 시스템, 
어플리케이션이 상호작용 할 수 있게 하는 프로토콜의 총 집합이라면 end point는 api가 서버에서
리소스에 접근할 수 있도록 가능하게 하는 URL이다. 

마이크로 서비스 아키텍쳐는 컴포넌트를 업무 단위로 잘게 쪼개는 방식을 지향하기 때문에, 컴포넌트의 url은
회원 관리, 상품 구매, 포인트 적립 등과 같이 대규모 개발 시스템일 수록 더 많이 늘어나게 될 것이다. API를 사용하는 클라이언트에서 서버간 통신이나 서버간 API 통신의 경우 p2p(Point to Point)형태로 Topology(링크, 노드 등이 물리적으로 연결되는 방식)가 복잡해짐에 따라 향후 유지보수에 문제를 야기할 수 있다. 이러한 문제를 해결하기 위해 중앙에 api gw라는 허브를 배치시켜 서비스간 호출을 단순화 할 수 있다.

2. 가장 기본적인 기능은 API 호출에 대한 인증과 인가

• API를 호출하기 전 인증이 필요하다.
  클라이언트를 인증하는 방법은 다양하다. id, password 입력또는 지문 등등. 인증이 완료되었다면 token을 발급하게 된다. 그 후는 발급 받은 token을 가지고 API를 호출할 수 있는 권한이 있는지 확인이 필요하다. token 자체가 이러한 정보를 갖는 형태를 클레임 기반의 token이라고 하는데, JWT(JSON Web Token) 방식이 이에 해당한다. 아래와 같은 흐름이다.

  (1) 클라이언트는 API Gateway에 id, password를 전달한다.
  (2) API gateway는 전달 받은 인증정보를 인증 서버에 전달한다.
  (3) 인증 서버는 인증을 수행한다.
  (4) 인증이 성공할 경우 token과 함께 API gateway에 반환한다.
  (5) API gateway는 클라이언트에 token을 응답한다.
  (6) 클라이언트는 가지고있는 token으로 호출하고자 하는 API에 access 한다.
  ( 이때, API에 호출할 수 있는 token인지 권한을 검증하는 단계를 api gw가 중간에서 결정한다.)

• 인증(Authentication)과 인가(Authorization)
  인증은 API를 호출 하는 것이 철수가 맞다는 것을 확인해준다면, 인가는 철수가 관리자 페이지에 접근할 수 있는 관리자 권한을 가지고 있는지 확인해주는 것과 같다. token에는 제한적으로 권한을 부여할 수 있다. 직접 권한을 토큰에 연결하지 않고, ROLE이라는 개념을 두고 역할별로 권한을 연결한 다음에, 이 ROLE을 token에 부여하는 개념이다. 일반 사용자용 기능들과 관리자용 기능들을 ROLE이라는 기준으로 분리하고, 이 ROLE을 token에 부여한다. 이를 RBAC(Role Based Access Control)이라고 한다.

https://bcho.tistory.com/1005?category=431297
이 블로그에서 관련 내용이 아주 잘 정리되어 있어서 도움이 많이 되었습니다. 참고하여 글을 작성하였습니다.
다음 글에서는 API 라우팅 기능에 대해서 정리해보겠습니다.