인사이트리포트

들어가며

API 호출 중 에러가 발생하는데, API 게이트웨이에서 확인 부탁 드려요.

API Gateway를 개발하고, 관리하는 개발자로서 빈번하게 받는 요청이다.

서비스 개발/운영 시 장애가 발생하면 원인을 추적하고, 담당자 식별은 항상 쉽지 않은 업무이다. 하지만 MSA 서비스로 전환된 이후 보다 빠르고 쉽게 담당자를 식별할 수 있게 되었다.

“일단 API Gateway 담당자에게 문의해”

API 게이트웨이란 무엇인가?

그림1. 은 Gartner에서 만든 Micro Service Architecture를 구성하는 요소 개념도이다.

Micro Service Architecture(MSA)를 구성하는 다양한 기능 요소 중 External Gateway로 분류된 기능에 속하는 기능이 API 게이트웨이이다. 모놀리식 아키텍처(Monolithic Architecture)에서는 하나의 거대 서비스와 세부 기능을 제공하는 모듈 단위로 구성되어 있었다. 거대한 서비스에 집합체인 모놀리식 아키텍처에 한계에 대한 대안으로 제시된 MSA에서는 서비스를 수십/수백 개의 작은 서비스로 분리할 것을 제안한다.

기능 단위로 개별 서비스로 분리되었지만, 서비스 필수 기능은 개별 서비스에서도 동일하게 지원 해야 한다. API 게이트웨이는 개별 서비스에 앞 단에서 모든 서비스들의 엔드포인트를 단일화 해주고, 필수 기능 요소들을 제공해주는 서비스 역할을 한다.

API 게이트웨이의 주요 기능

1. 인증 (Authentication) 과 인가 (Authorization)

• 인증 (Authentication) : 사용자의 신원을 검증하는 행위
• 인가 (Authorization) : 사용자에게 요청을 실행할 수 있는 권한 부여 절차
•  인증과 인가는 필수적으로 제공되어야 하는 기능
• 인증과 인가 서비스를 위해 자체 기능을 구현해서 사용하거나, 별도의 외부 서비스와 연계하여 제공

2. API 라우팅 (Routing)

• API 요청을 식별하여 적절한 마이크로 서비스로 전달하는 기능

3. QoS (Quality of Service)

• 안정적인 서비스 제공 및 네트워크 품질 관리를 위하여 사용자 / 클라이언트 / API 단위로 접속 제어 기능

4. 로깅 (Logging) 및 모니터링 (Monitoring)

•  API 요청에 대한 로깅 지원 및 모니터링 기능

5. 입력 유효성 검사

• API 요청이 적절한 형식과 필수 데이터를 포함하는지 식별 및 관리 기능 제공

API 게이트웨이 구축 방법

API 게이트웨이 서비스를 구축하기 위해서는 다음과 같은 방법을 사용한다.

1. SW 벤더가 제공하는 상용 API 게이트웨이 SW 사용

• 장점: 검증되고 다양한 기능을 보유한 솔루션 사용 가능
• 단점: 높은 라이선스 비용과 커스터마이즈가 어려움

–  AWS, Azure, Google Cloud Platform 등 클라우드 사업자가 제공 상품

– Kong, Tyk, WSO2, MuleSoft 등의 상용 API 게이트웨이

2. 오픈 소스 기반의 API 게이트웨이 SW 사용

• 장점: 저렴한 유지 비용과 다양한 기능을 보유한 솔루션 사용 가능
• 단점: 상용 SW 대비 빈약한 지원과 커스터마이즈가 어려움.

– Kong, Tyk, Ambassador, Traefik 등의 오픈 소스 API 게이트웨이

3. 오픈 소스 기반의 커스터마이즈 된 API 게이트웨이 개발 및 서비스

• 장점: 자사 환경에 맞는 최적화된 서비스 구축 가능
•  단점: 경험 부족에 따른 시행착오 발생
• Spring Cloud Gateway, Netflix Zuul API Gateway 등

안정적인 서비스를 위해서는 1번 상용 SW 제품을 사용하는 것이 쉽고 편리하지만, 서비스 비용에 대한 부담과 자사 서비스에 최적화된 기능 구성을 위해 오픈 소스 기반의 커스터마이즈를 선택하는 것도 좋은 대안이 될 수 있다.

에스코어는 삼성 SDS의 클라우드 신규 서비스를 개발에 참여하면서, API 게이트웨이 구축을 하게 되었다. 서비스에 API 게이트웨이는 상용 SW는 초기 도입에는 쉽게 할 수 있겠지만, 서비스에 최적화가 쉽지 않고, GUI 기반의 환경 설정 같은 편의 기능은 필요치 않다고 판단 하였습니다. 그래서 API 게이트웨이에서 필요한 필수 기능을 지원하고, 불필요한 화면 설정 화면 대신 YAML 기반의 설정으로 경량의 서비스를 제공할 수 있는 Spring Cloud Gateway를 이용하기로 결정 하였습니다.

Spring Cloud Gateway (SCG)

• Spring에서 제공하는 오픈 소스 기반의 Gateway 서비스
• Netty 기반의 비동기(Asynchronous) 요청 처리 제공
• Spring에서 제공하는 다양한 Component를 조합하여 효율적인 개발이 가능

Spring Cloud Gateway 기본 동작 구조

• SCG의 내부 구조에서 기능 특성에 따라 Predicate와 Filter Chain으로 구분이 가능하다.
• Predicate는 요청 받은 API가 지정된 Route경로에 포함되는지 식별 후 Filter Chain으로 요청을 전달한다.
• Filter Chain은 각각 하나의 서비스를 제공하는 Filter를 등록하고 사슬과 같이 이어져서 연쇄적으로 Filter가 실행하는 방법이다.
• Filter Chain은 백엔드 서비스에 요청 처리 시점을 기준으로 요청 전은 Pre Filter와 요청 처리 후 실행하는 Post Filter로 구분한다.

Spring Cloud Gateway 장점

• Spring 오픈 소스 기반 사용으로 초기 라이선스 투자 비용 없음
• WebFlux 기반의 Non-Blocking 방식 채용으로 빠른 응답 속도 확보
• Spring에서 제공하는 다양한 서비스(Spring Boot, Spring Security, OAuth2 Client, Redis 등)와 조합하여 서비스 가능
• 오픈소스 커뮤니티에서 개발자 경험 공유 및 노하우 획득 가능

Spring Cloud Gateway 단점

• 다양한 필수 기본 서비스가 제공되지만 적절한 기능을 선택이 어렵다
• 서비스 구현에서 다양한 테스트 및 문제 해결을 통한 최적화가 필요
• 상용 SW에서 제공하는 GUI 기반에 관리 기능 미 제공(필요 시 자체 구축 필요)

Spring Cloud Gateway를 이용한 API 게이트웨이 서비스 구축

API 게이트웨이 요구 사항

• 웹 콘솔에서 OAuth2를 이용한 사용자 인증과 HMAC 해시 인증키를 사용한 사용자 인증을 지원한다.
• 개발 비용이 많이 필요한 GUI 기반의 관리 화면을 배제, Spring Yaml 파일 설정과 API Meta 정보 DB를 이용하여 유연한 설정 변경 지원
• 사용자 인증 Session 관리를 위해 Redis를 사용
• K8S 기반의 DevOps 운영 환경을 구성하여 원활한 Scale Out 지원
• 인증 방식 및 지원 API에 따라 독립적인 서비스 제공 필요

API 게이트웨이 서비스 구성 개념도

• API 게이트웨이의 인증 방식 단위로 별도의 API 게이트웨이를 구성

SCG 시스템 분류 구조에 따른 API 게이트웨이 서비스 내부 구성 설명

• SCG가 동작 구조에 맞게 Predicate 영역과 Filter Chain 영역으로 구분하여 구현 항목들에 대해 설명하기로 한다.

1. API Validate – Predicate

• 요청 API에 URL 패턴을 식별하여 해당 API가 서비스 가능 여부를 식별
• 미 지원 API 또는 Deprecated 된 API인 경우 404 응답 리턴

2. 라우팅 (Routing) – Predicate

• 요청 API URL 식별하여 적절한 서비스로의 연결하는 Routing 설정 구현
• 초기 Route Rule은 Context와 일치하는 API 요청에 대해 서비스로 전달하도록 구현

• 시스템 구축 및 운영하는 과정에서 서비스 및 API가 변경되는 일은 빈번하게 발생
• 기존 API 스펙에 Context와 다른 서비스로 연결되어야 하는 상황이 발생

• Routing은 설정 변경이 빈번하며, 외부 호출 URL은 유지하되, 내부에서 변경되어야 하는 경우가 자주 발생한다.
• Routing 기능을 설계/구현할 때는 변경 발생 시 유연하게 대처할 수 있는 구조를 채택하여 한다

3. 인증(Authentication) 서비스 연계 – Predicate

• 인증 시스템 개발은 두 가지 방식을 지원하도록 개발
• 레거시 시스템에서 사용하던 OAuth2 기반의 Identity Provider(IDP)를 이용한 OAuth2 사용자 인증 (사용자 Console 지원)
• OpenAPI 서비스 지원을 위한 HMAC 기반에 자체 인증 서비스 (OpenAPI 및 CLI 서비스 지원)
• Spring Security에서 제공하는 OAuth2 인증 처리를 사용하여 OAuth2 인증 구현
• 대량의 사용자 인증 요청에 대응하기 위해 session 관리를 Redis 기반의 인증 Session 사용 (Spring 라이브러리 지원)
• Spring profile을 사용하여 OAuth2 / HMAC 인증을 수행하는 별도의 게이트웨이로 실행 할 수 있도록 구현
• 새로운 인증 메소드 필요 시 Profile 추가 + 인증 프로세스 추가로 유연한 변경이 가능하도록 구현

4. Global Filter 설정 – Filter Chain

• AddUserInfoFilterFactory: API 요청 처리에 필요한 공통 정보 (Login ID, User ID, Time Zone 등)를 HTTP Header에 추가

• RequestIdFilterFactory: API 요청을 추적할 수 있는 Request ID를 HTTP Header에 추가

5. Custom Filter 설정 – Filter Chain

• RoleCheckFilterFactory : IAM 서비스에서 제공하는 역할(Role) 전환 기능 지원을 위한 역할 인증 및 인가 서비스 제공

6. 인가(Authorization) 서비스 연계 – Filter Chain

• MSA 백엔드 서비스의 권한 인가를 위해 별도의 IAM(Identity and Access Management) 서비스를 구현
• 사용자 인증을 통과한 API 요청에 대해 IAM 서비스에 해당 요청에 대한 권한 보유 여부를 식별

7. Logging Filter 설정 – Filter Chain

• 성API 요청과 처리 결과까지 기록하기 위해 로깅 필터를 추가하고 API 호출 기록을 생성한다.

8. 전역 예외 처리를 위한 RestControllerAdvice 사용

• API 실행 요청부터 종결까지 발생하는 에러 및 예외 처리를 위하여 게이트웨이에서 발생하는 예외를 통합 처리

9. API 실행 결과

• API 게이트웨이에 구현된 Predicate와 Filter Chain 실행이 완료가 되면 API가 요청이 서비스로 전달되고, 결과를 클라이언트에게 리턴 하며 API 게이트웨이 역할을 끝나게 된다.

마치며 – API 게이트웨이, MSA에 시작과 끝

API 게이트웨이는 오랜 역사를 가지고 있고, 비교적 확고한 기술 스택이 확립되어 있는 기술이다.

확고한 기술 스택이 있는 것과는 별개로 신규 서비스에서는 항상 다양한 난관을 거치게 된다.

Spring Cloud Gateway는 단순하지만, 고성능이 필요한 게이트웨이 서비스를 구축할 수 있는 기술적인 요건을 제공하고 있다. 너무 단순하게 구성 가능한 소스 코드를 보면 과연 이 솔루션이 고성능 API 게이트웨이를 만들 수 있을지 의문이 생길 수 있다.

전체 서비스 중 말단의 서비스가 아닌 시스템 앞 단에서 모든 API 요청을 관할하는 API 게이트웨이에서 장애가 발생하면 전체 서비스가 다운이 되는 것과 같은 치명적인 상황이 발생할 수도 있다. 그만큼 API 게이트웨이 서비스를 개발 운영을 하는 건 심적인 부담과 긴장을 가지게 한다. 그러한 긴장감을 즐기면서 API 게이트웨이를 개발해보면 한 단계 더 성장한 서비스와 자신을 마주할 수 있게 될 거라 생각한다.