*API Gateway KONG API Gateway kong의 사례와 Architecture 설계

*index 1. 사례 분석(GIS 플랫폼) 2. Gateway Architecture 3. API Gateway Architecture 설계

1. 사례 분석(GIS 플랫폼)

개발 목표 AS-IS: GIS 플랫폼의 API Gateway 요청에 대한 라우팅, 인증 기능 제공 Logical Architecture DMZ IS Proxy (Nginx) Gateway (Kong) Gateway Repository (Cassandra) Client와의 연결을 IS망으로 중계하는 컴포 넌트 Client의 요청에 대해 인증 처리 후 API 서버로의 연결 키에 대한 설정과 API에 대한 설정을 저장

Apache vs Nginx AS-IS: GIS 플랫폼의 API Gateway Nginx 는 비동기 이벤트 기반으로 요청을 처리 Apache 서버는 요청 당 쓰레드 또는 프로세스가 처리하는 구조 하지만 PHP 모듈 등을 직접 적재할 수 있는 Apache가 구조상 이점이 있기에 복잡한 웹 사이트의 경우 Apache가 적합하다. 세션 클러스터링 같은 특별한 목적을 추가적으로 수행하는 세팅을 할 경우에는 별도의 과정을 거쳐야 하기 때문에, 이러한 별도의 작업이 많이 필요한 서비스의 경우에도 유지 보수 측면에서 Apache가 유용합니다. 즉 안정성과 확장성, 호환성에서 Apache가 우세, 성능 면에서는 Nginx가 우세하다는 것이 결론입니다. Thread 방식 하나의 커넥션당 하나의 쓰레드를 잡아서 요청을 처리한다. Event-Driven 방식 여러 개의 커넥션을 Event Handler를 통해 비동기 방식으로 처리

Interface Architecture AS-IS: GIS 플랫폼의 API Gateway client proxy gateway AP Gateway Repository DMZ IS 443 8000 8000 9042 • HTTPS • client와 통신 • HTTP • 서버간 통신 • native • 해당 서비스가 제공하는 별도의 protocol 이용 • HTTP • 서버간 통신 DMZ에 있는 proxy의 역할? • 외부 네트워크와 내부 네트워크 분리하는 역할 • DMZ와 IS 사이에 방화벽이 있어, 보안을 한번 더 강화하기 위한 목적

HTTPs vs HTTP AS-IS: GIS 플랫폼의 API Gateway HTTP 의 문제점 • HTTP 는 평문 통신이기 때문에 도청이 가능하다. • 통신 상대를 확인하지 않기 때문에 위장이 가능하다. • 완전성을 증명할 수 없기 때문에 변조가 가능하다. SSL은 상대를 확인하는 수단으로 증명서를 제공 • 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. HTTPS는 SSL의 껍질을 덮어쓴 HTTP HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체 HTTP 는 원래 TCP 와 직접 통신했지만, HTTPS 에서 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신

Physical Architecture AS-IS: GIS 플랫폼의 API Gateway DMZ IS Proxy Gateway Gateway Repository Proxy Proxy Gateway Gateway Gateway Repository Gateway Repository L4 L4

Cassandra vs PostgreSQL AS-IS: GIS 플랫폼의 API Gateway NoSQL과 RDB Cassandra는 여러 서버에 데이터를 분산시키고, 분산된 데이터를 여러 서버에 복제하는 방식을 쓴다. • 선형으로 확장 가능 • 마스터 노드가 없고, 모든 노드에 데이터가 복제되므로 일부 노드가 죽어도 데이터가 손실되지 않는다. • 노드 복구 기능이 있어서 Cluster의 일관성을 유지 가능 • 뛰어난 노드 복제 및 일관성 기능을 가진다. PostgreSQL • ACID(Atomicity, Consistency, Isolation, Durability) 트랜젝션 지원 • 유연한 Full-text search 기능(문자열 검색, 벡터 연산) • 다양한 복제 지원 방식(Streaming Replication …) • 다양한 확장 기능 지원(PostGIS, key-value store방식 …) repository를 분리하게 된 것은 서버가 죽어도 repository는 살아야 다른 gateway가 동작하도록 하기 위해 분리함 (같은 서버에 구성해도 replica set을 3으로 하면 상관없긴 함) 이전 슬라이드에서 Gateway와 Repository를 3개씩 구성한 이유? GIS에서 Cassandra를 쓴 이유 • PostgreSQL은 보통 kt 내에서 관리하는 db로 분류 • 뭐 하려고 할 때마다 회사에서 간섭이 많다. • 반면 Cassandra는 kt 내부에서 관리대상 db로 분류하지 않음 • 유지보수 대상이 아님 • 알아서 관리하되, 문제시 개발부서 책임

API 인증 관리 AS-IS: GIS 플랫폼의 API Gateway Kong에서 제공하는 인증 플러그인(key-authentication) 사용 GIS에서는 Key를 생성하여 고객 정보와 사용 가능한 api 목록을 Repository(DB)에 저장하여 관리 이후, Request Header에 ID와 Key를 담아서 요청하면 Gateway에서 DB에 저장되어 있는 데이터 기반으로 인가 로직 수행

Kong 운영 AS-IS: GIS 플랫폼의 API Gateway kong에서 제공하는 Admin api (RESTful API) 이용 API 등록하기 API에 Plugin 등록하기 consumer 등록하기 key 등록하기 curl -i -X POST --url http://localhost:8001/apis/ --data 'name=rp-api' --data 'uris=/rp' --data 'upstream_url=http://192.168.151.233:10001' 등록: curl -i -X POST --url http://localhost:8001/apis/rp-api/plugins/ --data 'name=key-auth' --data 'config.key_names=key' 확인: curl -i -X GET --url http://localhost:8001/plugins/ 등록: curl -i -X POST --url http://localhost:8001/consumers/ --data "username=mobile" 확인: curl -i -X GET --url http://localhost:8001/consumers/mobile 등록: curl -i -X POST --url http://localhost:8001/consumers/mobile/key-auth --data "key={Value}“ 확인: curl -i -X GET --url "http://localhost:10002/rp/v0_7/navi_route?key={value}&start=953004,1951524&end=94686 0,1942084"

DB table AS-IS: GIS 플랫폼의 API Gateway apis • Id • Name • Hosts • Uris • Upstream_url • Methods • … consumers • Id • Custom_id • Service_id • Customer_id • Username • … Keyauth_credential • Id • key • Cunsumer_id • Uris • Hosts • Options • … Customer_info • Id • Username • … Service_info • Id • Name • … 허용 API 리스트 허용 호스트 리스트 key를 가지는 고객의 id key 값 API 정보 key-auth를 사용한 고객 정보 고객 정보 고객사 정보 서비스 정보

Logging AS-IS: GIS 플랫폼의 API Gateway API Gateway(kong) 서버에 Filebeat 설치하여 로그 수집 IS Gateway Gateway Gateway L4 Filebeat ElasticSearch

2. Gateway Architecture

Zuul의 구조는 어떻게 되어 있을까? 배민 API GATEWAY - spring cloud zuul 적용 사례 배민의 API 서버 구조 zuul의 core 부분 “요청 → Filter → 응답”의 구조 1. PRE Filter 라우팅 전에 실행되며 필터이다. 주로 logging, 인증 등이 pre Filter에서 이루어진다. 2. ROUTING Filter 요청에 대한 라우팅을 다루는 필터이다. Apache httpclient를 사용하여 정해진 Url로 보낼 수 있고, Neflix Ribbon을 사용하여 동적으로 라우팅 할 수도 있다. 3. POST Filter 라우팅 후에 실행되는 필터이다. response에 HTTP header를 추가하거나, response에 대한 응답속도, Status Code, 등 응답에 대한 statistics and metrics을 수집한다. 4. ERROR Filter 에러 발생시 실행되는 필터이다.

카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개 * sticky session : 쿠키 또는 세션을 사용하여 트래픽을 분산 카카오 광고 플랫폼 사례 JWT(JSON Web Token) 사용 디지털 서명을 통해 확인하고 신뢰할 수 있는 정보를 보내는 데 사용 수평으로 쉽게 확장 가능 세션 방식의 인증의 경우 중앙 세션 스토리지 시스템 필요 Sticky session 방식은 비용증대 유지 보수 및 디버그 용이 Base64 방식으로 데이터 인코딩 되어 웹 토큰 자체에 포함됨 보안성 암호화 알고리즘으로 암호화하여 클라이언트 변조를 막음 RESTful 서비스에 적합 쿠키방식의 경우 쿠키의 출처가 된 도메인에 대해서만 사용할 수 있는 단점 해소 토큰 자체 만료시간 기술 토큰 만료시간을 미리 알고 갱신 요청을 할 수 있음 JWT 우려되는 점 - 세션 방식에서는 로그아웃 할 때 인증정보 폐기 가능 - JWT는 만료시간 기준으로 무효화 됨 - 그래서 opaque token 고려

카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개 카카오 광고 플랫폼 사례 Opaque token + JWT 1. 요청이 들어오면, 인증 서버에 token 발급 요청 2. JWT 생성하여 주는데, 게이트웨이에서는 JWT를 opaque token으로 변환하여 사용자에게 준다. 3. 실제 resource 서버에 요청을 할 때 opaque token을 JWT로 변환하여 넘겨줌 4. 나중에 사용자가 로그아웃 할 때 opaque token을 폐기하는 방식

다중 API 게이트웨이 아키텍쳐 API Gateway 디자인 패턴 • 외부 서비스용 게이트웨이와 내부 서비스용 게이트웨이를 분리하는 방안 • 외부 엔드포인트에 대해서는 인증/인가 로직 • 내부 API 엔드포인트는 내부 IP를 가지도록 하고, 방화벽 안에서만 오픈하되 별도의 인증/인가 로직을 거치지 않고 내부 서버들이 API를 호출하는데 사용

파일 업/다운로드 엔드 포인트 분리 API Gateway 디자인 패턴 • 특수 목적의 엔드포인트는 별도의 API 게이트웨이로 분리해 내는 것이 좋다. ex) 인증 등 없이 고속으로 많은 로그를 업로드 하는 엔드 포인트같은 경우, 부하량이 많기 때문에 다른 일반 API 엔드포인트에 부담을 주지 않기 위해서 분리 • 파일 업로드나 다운로드와 같은 트렌젝션은 CPU는 많이 사용하지 않지만, 요청 처리에 시간이 많이 걸리는 작업 • 싱글 쓰레드 기반의 비동기 IO 게이트웨이의 경우에는 비동기 IO이기 때문에 파일 업/다운로드에는 다소 유리할 수 있지만, 네트워 크 대역폭을 상당 부분 소모해버리기 때문에 마찬가지로 다른 API 서비스를 하는데 영향을 줄 수 있다. • 그래서 이러한 파일 업/다운로드는 가급적이면 게이트 웨이를 거치지 않고 별도의 독립된 엔드포인트나 프록시를 사용하는 것이 좋 은데, 다음은 별도의 프록시를 넣는 아키텍쳐 설계 방식의 예이다. 1. API 클라이언트가 파일 서버에 API를 이용하여 파일 다운로드를 요청한다. 2. 파일 서버는 API에 대한 응답으로 파일을 바로 내리 는 것이 아니라, 파일을 다운로드 받을 수 있는 URL 과 함께, 임시 인증 토큰을 발급(현재 API 클라이언 트에 IP 에만 유효하고, 특정시간 예를 들어 발급후 30분 이내만 사용이 가능한 토큰)하여, API 클라이언 트에게 리턴한다. 3. API 클라이언트는 2에서 받은 URL로 임시 인증 토큰 과 함께 파일 다운로드를 파일 다운로드 프로젝시를 통해서 요청한다. 4. 파일 다운로드 프록시는 임시 인증 토큰을 인증한 다음에, 파일 다운로드를 수행한다.

3. API Gateway Architecture 설계

DMZ API Gateway Architecture 설계 proxy (nginx) L4 proxy (nginx) proxy (nginx) Caching server DMZ 정적 컨텐츠 요청 시 (html, css, js, img …) * 컨텐츠 사이즈 커질 경우, 따로 서버 구성 고려 KTIS 그 외 요청

KTIS * Gateway와 Gateway DB 수는 임의로 구성 API Gateway Architecture 설계 Gateway L4 Gateway Gateway API Server API Server API Server File Server Proxy Gateway DB elasticsearch Mediator Server filebeat OAuth2.0 Web (kibana) 내부API Server

인증 관리(토큰 관리) API Gateway Architecture 설계 OAuth 2.0 Plugin 이용 client Reousrce owner Authorization Server Resource Server Authorization Request Authorization Grant Authorization Grant Access Token Access Token Protected Resource Gateway OAuth2.0 Id Consumer_id Access_token scope expires_in 인증이 완료되면, upstream server 에 요청을 보내기 전 request header에 다음과 같은 정보를 담아 서 보낸다 (X-Consumer-ID, X-Consumer- Custom-ID, X-Consumer- Username, X-Authenticated-Scope …)

로그 관리 API Gateway Architecture 설계 • 로그 수집은 GIS 플랫폼에서 사용하던 방식인 Filebeat을 통해 elasticsearch로 로그를 수집하는 식으로 한다. • KTIS 내부에 web server를 구성하여 수집된 로그를 모니터링 할 수 있는 kibana 구성 • 내부 API 서버를 통해 elasticseacrh의 데이터를 가져와 시각화한다. • 이 때 별도의 인증/인가 로직은 거치지 않는다. Gateway Gateway Gateway elasticsearch filebeat Web (kibana) 내부API Server

Thank you!! *