MSA의 Outer Architecture 중 External Gateway에 대해 알아보자.
MSA 개념 설명 읽어보기
External Gateway
- 전체 서비스 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소
- 사용자 인증 (Consumer Identity Provider)과 권한 정책관리(Policy Management)를 수행
API Gateway
가 가장 핵심적인 역할
API Gateway
- 서버 최앞단에 위치하여 모든 API 호출을 받음 (API 서버들의 endpoint 단일화를 해주는 또다른 서버)
- API에 대한 인증과 인가 기능을 가지고 있음: 받은 API 호출을 인증한 후, 적절한 서비스들에 메세지를 전달(routing)
- SOA의 핵심 인프라인
ESB
(Enterprise Service Bus)에서 비롯됨- EBS는 SOAP/XML 기반의 무거운 기능
- API Gateway는 REST/JSON 기반의 가벼운 기능
API Gateway의 주요 기능
- 인증 및 인가 (Authentication and Authorization)
- MSA에서 각각의 서비스에 API호출에 대한 인증 및 인가를 한다는 것 = 같은 소스코드를 서비스 인스턴스들마다 심어줘야 함 = 소스의 중복이 심하여 유지 관리가 어렵고, 로깅 모니터링을 관리하는 것도 매우 어려워짐
- 따라서 인증서 관리나 인증, SSL, 프로토콜 변환화 같은 기능들을 API Gateway에서 오프로드 -> 각각의 서비스 부담 줄이기 및 서비스 관리, 업그레이드가 용이함
Authentication (인증) vs Authorization (인가)
- Authentication: 유저가 누구인지 확인하는 절차
- Authorizatoin: 어떠한 유저가 특정 자원에 접근하려 할 때, 그에 대한 접근 권한이 있는지 확인하는 절차
- 요청 절차의 단순화
- API Gateway가 없을 시 클라이언트에 여러 서비스들에 대한 요청을 진행해야 함
- API Gateway는 여러 클라이언트의 요청을 단일 클라이언트의 요청으로 대체 가능하도록 만들어줌
- 따라서 클라이언트와 백엔드 간 APU 통신량이 줄어 대기시간이 줄어줄이고 효율성을 높일 수 있음
- 라우팅 및 로드밸런싱
- 클라이언트로부터 접수된 메시지에 따라, API 호출을 적절한 서비스에 라우팅
- 서비스 인스턴스들에 대한 부하분산 가능
- 서비스 오케스트레이션
오케스트레이션
: 여러 개의 마이크로 서비스를 묶어 새로우 서비스를 만드는 개념- 과도한 오케스트레이션 로직: APU Gateway의 부담을 늘리는 것 = 성능 저하
- 서비스 디스커버리
- API Gateway는 각 서비스 호출을 위해 서비스마다 IP주소 및 포트번호를 알고 있어야 함
- lagacy 환경에서는 크게 문제될 점이 없지만, 클라우드 환경에서는
동적
으로 배포되기 때문에 서비스 위치를 찾는 것이 어려움- 이러한 서비스의 위치를 찾는 것을
Service Discory
- 이러한 서비스의 위치를 찾는 것을
- 서버 사이드나 클라이언트 사이드를 기준으로 서비스 디스커버리 구현 가능
API Gateway 적용 시 고려사항
API Gateway 계층이 추가적으로 만들어진다는 의미 = 그 만큼 네트워크 latency 증가
API Gateway의 Scale-out 적용이 유연하게 일어나지 않을 경우, API Gateway가 병목지점이 되어 어플리케이션의 성능저하가 일어날 수 있음
API Gateway의 가장 큰 단점은
API Gateway를 내부 마이크로서비스와 결합한다는 것
-> 기존 SOA에서의 EBS(Enterprise Service Bus)에서 발생했던 문제점이 다시 발생할 수 있음2000년대 후반, 많은 SOA 프로젝트가 실패한 이유로 SOA의 핵심적인 요소 중 하나인 ESB가 꼽히는 경우가 많음.
- 당시 EBS 내부 처리 로직을 XML 기반으로 했는데, XML의 파싱은 오버헤드가 큰 작업
- EBS는 가벼운 연산 외에도 과도한 Orchestration 등 무거운 로직을 가짐. 대부분 ESB를 Gateway로의 특성이 아닌 시스템을 통합하기 위한 역할로 많이 구현했음