Search
Duplicate

API Gateway Part 1 - 개요

Tags
Engineering
서비스는 항상 진화한다. 요구사항이 추가되며 복잡도가 증가하고 여러개의 서비스로 분리되기도 한다. 의존관계가 생겨 유지보수가 어려워지만, 모든 것을 새로 작성하기에는 시간과 인력, 많은 리소스들이 부족하다. 이때 필요한 것이 최소의 비용으로 서비스를 분해하고 다시 조립하는 것이다. 새로운 서비스를 추가할 수 있도록 확장성을 가질 수 있으면 더욱 좋을 것이다. 이런 이유로 모놀리스 서비스가 마이크로서비스로 분해된다. 그리고 복잡해진다. 이것을 통합하고 단순화하기 위해 필요한 것이 API Gateway다.
GLAM 서비스에 API Gateway 를 도입하고 마이크로서비스를 통합한 과정을 소개한다.

API Gateway 란 무엇인가?

Wikipedia 의 API Management 페이지의 Gateway 항목은 아래와 같이 작성되어 있다.
Gateway: a server that acts as an API front-end, receives API requests, enforces throttling and security policies, passes requests to the back-end service and then passes the response back to the requester. A gateway often includes a transformation engine to orchestrate and modify the requests and responses on the fly. A gateway can also provide functionality such as collecting analytics data and providing caching. The gateway can provide functionality to support authentication, authorization, security, audit and regulatory compliance.API Management fro Wikipedia
게이트웨이: API 의 프론트엔드로서 동작하는 서비스로, API 요청을 받아 요청을 조정하고 보안정책을 적용한 후 요청을 백엔드 서비스로 전달하고 발생한 응답을 요청자에게 전달해주는 역할을 한다. 게이트웨이는 요청과 응답을 실시간으로 변형할 수 있는 기능을 제공하기도 한다. 또한 통계 자료에 대한 수집기능이나 응답에 대한 캐시 기능을 제공 한다. 게이트웨이는 기능적으로 인증, 인가, 보안, 감사 및 내부 규제 준수등의 기능을 제공한다.
… 고 간략히 번역할 수 있겠다.
API 게이트웨이의 주요 기능은 다음과 같다.
라우팅:
API 요청을 적합한 하위서비스가 처리할 수 있도록 전달하고, 응답을 요청자에게 전달해주는 기능
인증, 인가 및 보안 기능:
API 사용을 위한 KEY 를 발급하거나, 요청에 포함된 토큰을 검사하여 요청에 대한 접근을 제한하는 기능
공통 로직 처리:
요청에 대한 통계 자료를 수집 등, 요청에 대한 공통 비즈니스 로직을 처리할 수 있는 기능
요청 및 응답을 변환:
요청을 하위 서비스가 처리할 수 있도록 변형하거나, 하위서비스의 응답을 표준 포맷으로 변경하는 기능

왜 API Gateway 를 도입해야 했을까?

GLAM에서 처리해야하는 요구사항이 복잡해지면서, 글램의 백엔드 엔지니어링 팀은 기존의 모놀리틱 서비스를 서비스 도메인에 맞는 마이크로서비스로 분리하는 작업을 진행중이다.
현재 글램의 백엔드 서비스는 고객의 정보를 관리하며 고객의 평가, 결제, 설정 등 대부분의 입출력 작업을 처리하는 플랫폼 서비스, 고객이 마음에 쏙 들만한 상대를 찾아 추천해주며, 고객과 다른 고객 사이의 관계를 관리하는 매치 서비스, 글램 내 소셜 서비스를 제공하는 소셜 서비스 등으로 분리되어 있으며, 기존의 플랫폼 서비스를 코드 기반으로 업그레이드하는 신규 플랫폼 서비스의 개발도 현재 진행중이다.
서비스 분리의 초기에는 클라이언트의 API 요청을 플랫폼 서비스가 받아, 플랫폼 서비스를 통한 내부 통신을 통해 하위서비스에 요청을 하고 플랫폼 서비스가 응답까지 처리하는 방식으로 (플랫폼 서비스가 라우팅 기능을 수행)
서비스의 의존도가 플랫폼에 종속되는 비율이 커졌으며, 하위서비스 배포를 위해서도 플랫폼 서비스의 배포가 필요한 상황이 발생하였고, PHP 코드베이스 내에 API 라우팅에 대한 코드가 추가되는 문제 등등이 발생했다.
이에 따라 개별서비스에 대한 의존관계를 줄이며 공통된 비즈니스로직을 한 곳에서 처리하면서 안정된 서비스를 제공하자는 내부 요구사항이 생겨났다. 이 요구사항을 해결하기 위해 API 게이트웨이 도입을 진행하게 되었으며, 이것은 아래의 요구 사항과 기대 효과를 가지는 작업이었다.

요구 사항

보안 요건을 충족
공통 로직을 처리
하위 서비스로 라우팅 처리
요청과 응답을 표준화 처리

기대 효과

각 서비스에 대한 의존관계가 줄어든다.
서비스 배포가 간단해진다.

결정 과정

서비스 도입의 1차 목적은 보안요건을 충족시키며 요청에 대한 라우팅을 처리하는 것이었다. 이 목적에 맞고 현재 서비스에 쉽게 도입할 수 있었던 Kong 이 최종 선정되었으나 다음의 서비스들이 고려되었다.

도입을 위한 후보들

자체 개발

python 으로 request proxy 역할을 하는 코드를 직접 개발하는 것을 고려하였다. 커스터마이징 면에서 큰 장점이 있지만, 프로젝트를 안정적으로 운영하는데 추가적인 리소스가 지속적으로 필요하고, 개발한 결과물의 성능이 전문 제품과 견주어 낫기 어렵다는 이유로 반려되었다.

AWS API Gateway

아마존에서 제공하는 AWS API Gateway 는 Custom Authorizor Lambda 개발 등으로 보안에 관련한 처리를 적용할 수 있으며 AWS 인프라의 CloudWatch, X-Ray 등을 사용할 수 있는 기능, Lambda 기반의 서버리스 코드 실행등의 확장성을 기대할 수 있다는 장점이 있었으나, Requests 에 대한 Limit 가 존재하는 점, 파일업로드에 대한 Limit 가 존재하는 점, Lambda 스케일링 지연에 따른 오류가 발생할 경우 클라이언트 수정이 필요한 점, 과금 예상이 힘든 점, 그리고 현재 서버리스 아키텍처가 당장의 고려사항이 아닌 관계로 반려되었다.

Spring Cloud Gateway 및 Zuul

현재 사용중인 기술스택이 JVM 기반이거나 Spring Boot 를 사용하고 있는 상태가 아닌 관계로 대안이 존재하면 다른 서비스를 우선적으로 고려하기로 하였다. 하지만, Spring MSA 생태계에서 사용하고 있는 Zuul 및 Eureka 등은 지속적으로 관심을 갖고 지켜볼 계획이다.

Tyk

Tyk 는 go 기반의 API Gateway 로 구글 출신의 개발자들이 만든 것으로 유명한 서비스이다. 설치도 간단하고 GUI 관리도구도 제공되어 사용이 편리한 점이 있었으나, 상대적으로 속도가 느리고, 무료로 사용할 수 있는 버전은 한 대의 서비스만 제공되어 확장성에 문제가 있을 것으로 생각된다.

기타

AWS의 Application Load Balancer:ALB

ALB 는 cookie 기반으로 보안에 관련한 처리를 처리할 수는 있었으나, 요청 헤더나 querystring 기반으로 특정 보안 로직을 실행할 수 있는 기능은 없어 후보에서 제외되었다.

Ambassador

Kubenetes Native 를 표방하고 있는 오픈소스 API Gateway 로서 현재 글램의 다양한 백엔드 환경을 통합하기에는 적합하지 않아 반려하게 되었다. 하지만, 이후 Kubenetes 환경으로 통합하게 된다면 다시 한번 고려할 수 있을 것으로 기대한다.

여러 쟁쟁한 경쟁상대들 사이에서 최종적으로 Kong Community Edition 을 사용하는 것으로 결정되었다.

Kong을 선택한 이유

Kong 은 Kong Inc. 에서 제공하는 오픈소스 플랫폼과 클라우드 서비스로 제공하는 API Gateway 로 2015년 (Kong Inc.의 이름이 Mashape Inc 이던 시절에) 발표되었다. Nginx/OpenResty 과 Cassandra/PostgreSQL 데이터베이스 기반으로 구성되어 있으며 안정적인 성능과 플러그인 기반의 확장성을 제공한다.
잘 알려진 장점과 단점은 아래와 같았다.

장점

설치 및 관리가 쉽다.
성능이 좋다.
확장 가능하며 많은 공개 플러그인을 지원한다.

단점

관리용 대시보드가 Enterprise 버전에만 제공된다.
설정 변경등은 모두 RESTful API 요청으로 수행해야 한다.
플러그인 개발이 어렵다.
단점이었던 관리용 대시보드의 경우 CE 버전에서도 오픈소스 프로젝트인 Konga 와 Kong Dashboard 등을 사용할 수 있었고, 플러그인 개발의 경우 Lua 프로그래밍 언어로 개발을 해야하지만, Lua 언어가 난이도가 높은 편이 아니고, OpenResty 예제 등을 쉽게 찾을 수 있어 그다지 개발 난이도가 높지는 않았다.

다음편 링크