API Gateway 란?
일단, API Gateway는 API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 인증과 인가 기능에서 부터 메세지에 따라 여러 서버로 라우팅하는 고급 기능까지 많은 기능을 담당하는 또 하나의 서버이다.
특징
- JSON/REST 기반에 최소한의 기능을 처리하는 경량화 서비스이다.
- MSA 설계이 있어 많이 언급되는 컴포넌트 중 하나가 API Gateway이다.
- API Gateway는 마치 프록시 서버처럼 API 앞에서 모든 API에 대한 엔드포인트를 통합하는 등의 기능을 제공하는 미들웨어다.
- SOA의 ESB(Enterprise Service Bus)의 경량화 버전이다.
API Gateway 주요 기능
- MSA의 문제점 중 하나로 각 서비스가 다른 서버에 배포되기 때문에, API의 엔드포인트 즉, 서버의 URL이 각각 다른 문제점을 엔드포인트 통합으로 해결해준다.
- 여러 서비스를 묶어 하나의 새로운 서비스를 만들어준다.
- 실제로 넷플릭스의 경우 MSA를 사용하면서, 여러 서비스를 Gateway 계층을 통해서 orchestration 하는 모델을 사용하고 있다.
- API에 대한 인증이나, 로깅과 같은 공통 기능에 대해서, API Gateway로 공통 기능을 처리하게 되면, API 자체는 비지니스 로직에만 집중을 하여 개발에 있어서의 중복 등을 방지 할 수 있다.
[주요 기능 정리]
- 역방향 Proxy & Gateway Routing
- 요청 집계
- 교차 편집 문제 & Gateway 오프로딩
- 인증 및 권한 부여
- 서비스 검색 통합
- 응답 캐싱
- 정책, 회로 차단기 및 QoS 다시 시도
- 속도 제한
- 부하 분산
- 로깅, 추적, 상관 관계
- 헤더, 쿼리 문자열 및 청구 변환
- IP 허용 목록에 추가 등
API Gateway의 필요성
MSA를 적용하면, 각 서비스마다 기능을 나누게 되기 때문에, 수많은 서비스가 만들어질 것이다.
근데 만약, 서비스가 기하급수적으로 만들어진다면, 어떻게 될까?
당장 클라이언트는 내가 원하는 정보를 어떠한 서비스에게 요청해야 되는지 모를 것이다.
심지어... 어떠한 서버가 있는지도 알 수 없을 것이다.
이뿐만 아니라, 우리는 Gateway를 사용해야하는 여러 이유가 있다...!
- 왕복
- 대부분의 애플리케이션은 메인 페이지에 많은 정보를 포함하고 있다.
- 이러한 모든 정보를 만들기 위해서는 여러 마이크로서비스들이 각자 자신이 담당하고 있는 데이터를 가공하고 조립하여 생성된다.
- 이 상황에서 만약 API Gateway가 없다면 클라이언트는 필요한 모든 서비스에게 요청을 보내서 필요한 데이터를 수집하고 가공하여 화면에 표시해야한다.
- 보안
- API Gateway가 존재하면 Gateway에게만 진입점을 요청하더라도 클라이언트는 원하는 결과를 얻을 수 있다.
- 때문에, 마이크로서비스에게 다가가기 위한 방법은 Gateway 이며 보안상 신경써야하는 부분도 Gateway가 된다.
- 즉, 각 마이크로서비스는 외부에 노출되지 않아도 된다.
- 결합
- API Gateway가 없으면 클라이언트의 애플리케이션은 서버가 어떠한 구조로 분리되어 있는지 알아야 하고 서버의 구조에 따라 애플리케이션이 서로 다른 Endpoint에 요청을 보낼 것이다.
- 즉, 추후 서버의 구조가 변경될 때 클라이언트의 애플리케이션도 같이 업데이트가 진행되어야한다.
- 공통 관심사 처리
- 대부분의 마이크로서비스는 인증 및 인가, SSL 인증과 같은 공통적으로 처리해야하는 관심사들이 있는, API Gateway가 마이크로서비스들 앞단에 존재한다면 이러한 중복되는 처리들을 한 곳에서 처리할 수 있다.
API Gateway의 단점
- API Gateway도 결국 요청을 처리할 수 있는 서비스에게 요청하고 반환하는 역할을 하기 때문에 추가 네트워크 호출로 인한 응답 시간 증가로 이어질 것이다.
- API Gateway가 추가되면 문제가 발생할 수 있는 실패 지점이 추가된다.
- API Gateway를 구현할 때 해당 계층을 내부 마이크로서비스와 결합하기 때문에, Gateway가 거대해질 수 있다.
- API Gateway가 충분히 스케일 아웃되어 있지 않으면 마이크로서비스들의 상태와 무관하게 서비스 병목 현상이 발생할 수 있다.
- API Gateway는 각각의 마이크로서비스들과 강하게 결합하고 있기 때문에 새로운 엔드포인트를 노출하기 위해서는 API Gateway를 같이 업데이트해야 하기 때문에 만약 이러한 API Gateway를 단일 팀에서 관리하게 되면 개발 속도가 지연되는 개발 지연 현상이 발생할 수 있을 것이다.
Spring Cloud Netflix Eureka 란?
마이크로 서비스의 정보를 Registry에 등록할 수 있도록 하고 동적인 탐색과 로드 밸런싱을 제공한다.
AWS와 같은 Cloud 시스템에서 서비스의 로드 밸런싱과 실패 처리 등을 유연하게 가져가 위해 각 서비스들의 IP / Port / InstanceId를 가지고 있는 REST 기반의 미들웨어 서버이다.
그리고 유레카는 Middle-Tier Load Balancer로 정의된다.
전통적인 로드밸런싱의 경우 서비스의 위치가 고정되어 있었지만 AWS와 같은 클라우드 환경에서는 서버의 위치가 동적으로 변동되기 때문에 개발자가 직접 이를 컨트롤 하기는 쉽지 않다.
하지만, AWS에서는 middle-tier load balancer를 제공하지 않기 때문에 유레카는 더 많은 관심을 받는다고 한다.
MSA에서의 Eureka란?
마이크로서비스 아키텍처에서 유레카는 Client-Side Service Discovery라고 할 수 있다.
시스템은 트래픽에 따라 동적으로 늘어날 수도 줄어들 수도 있는데, 이러한 환경에서 서비스의 Host와 Port가 동적으로 변하더라도 서비스 인스턴스를 호출할 수 있도록 해주는 Service Registry를 제공 및 관리해준다는 것이다.
Eureka에서의 Discovery란 ?
- 각 서비스의 위치가 등록된 서버에서 특정 작업을 위한 서버의 위치를 파악하는 작업을 뜻한다.
- 즉, 각 서비스 인스턴스들이 동적으로 확장, 축소 되어도 인스턴스 상태를 하나의 서비스로 관리할 수 있는 서비스라 생각하면 된다.
MSA에선 Service의 IP와 Port가 일정하지 않고 지속적을 변화한다.
때문에, Client에 Service의 정보를 수동으로 입력하는 것은 한계가 분명하다. 즉, Service Discovery는 MSA의 상황에 적합하다.
이때, MSA의 핵심 원칙 중 하나인 Service Discovery의 역할을 수행하기 위해 Eureka Server를 사용한다.
Eureka에서의 Registry란?
- 각 서비스가 자신의 위치(IP) 정보를 특정 서버에 등록하는 작업을 말한다.
이때, MSA의 핵심 원칙 중 하나인 Service Discovery의 역할을 수행하기 위해 Eureka Client를 사용한다.
어쨌든 Eureka는 Eureka Server, Eureka Clinet로 구성이 되어 있는데, 이 두 역할이 무엇인 지 보자.
Eureka Clinet 란?
- 이는, 각각의 서비스에 해당하는 모듈이라 생각하면 된다.
- Eureka Client는 스스로 Eureka Server에 등록한다. (연결 정보 등)
- Eureka Client는 Eureka Server로부터 저장된 Registry 정보를 수신한다.
- 또한 자신의 로컬에 저장한다.
- Eureka Client는 Eureka Server에게 받은 Regisry를 통해 다른 Client의 정보를 알 수 있다.
- Eureka Client는 처음 모든 정보를 로컬에 저장하고 일정 시간마다 변경되니, 정보를 Eureka Server로 요청한다.
Eureka Server 란?
- Eureka Server는 Eureka Client를 관리하는 서버이다.
- Eureka Server는 Eureka Client의 정보를 Registy에 등록한다.
- Eureka Server는 Eureka Client의 Heartbeat Client를 수신하여 해당 Client가 수행 중임을 안다.
- Heartbeat가 정상적으로 수신되지 않은 경우엔 Server는 Client가 수행 중이지 않다고 판단해 해당 Client Registry 정보를 삭제한다.
Eureka의 흐름
- Eureka Client 서비스가 시작될 때, Service Registry 기능을 할 Eureka Server에 자신의 정보를 등록한다.
- Eureka Client는 Eureka Server로부터 다른 Clien의 연결 정보가 등록된 Registry를 받고 자신의 로컬에 저장한다.
- 일정 시간 마다 Eureka Server로부터 변경 사항을 갱신 받는다.
- 일정 시간 마다 Ping을 통해 자신이 동작하고 있다는 신호를 보낸다.
- 신호를 보내지 못하면 Eureka Server가 보내지 못한 Client를 Registry에서 제외한다.
즉, 유레카가 없으면, 연결 정보 수정 및 등록 등, 전부 직접 설정해야 할 것이다.....!
용어 정리
- Service Registration
- Client(마이크로서비스)가 자신의 정보를 유레카에 등록하는 행동을 의미.
- Service Registry
- Client의 정보들을 저장하는 위치를 의미.
- Service Discovery
- 클라이언트가 Service Registry에서 요청을 보내야하는 대상을 찾는 과정을 의미.
- Eureka Client
- 다른 서비스의 위치 정보를 알아내기 위해 유레카 서버에 질의하는 서비스.
- Eureka Server
- 유레카 서비스가 자기 자신을 등록(Service Registration)하고 Eureka Client가 Eureka Service를 찾기 위해 가용 서비스 목록(Service Registry)를 요청하는 서버.
- >Eureka Service
- 유레카 Client가 요청하였을 때 발견의 대상이 되는 서비스. (유레카에 등록되어 있는 Service)
- Eureka Instance
- 유레카에 등록되어 Service Registry에서 조회 가능한 Eureka Service를 의미.
- Fetch Registry
- Client는 Server로 부터 Service Registry 정보를 가져와 로컬 캐시로 저장하소 일정 주기마다 업데이트 한다.
- Cancel
- Client가 종료될 때, 유레카 서버로 Cancel 요청을 보내서 Service Registry에서 즉시 제거.
- Time Lag
- 유레카 서버의 Service Registry가 변경되어도 Client가 새로 Fetch 하기 전까지는 데이터의 차이를 말한다.
- Renew
- Client는 유레카에 등록된 이후 설정된 주기마다 heartbeat를 전송하여 자신의 존재를 알리는데, 유레카 서버는 설정된 시간동안 heartbeat를 받지 못하면 Eureka Instance를 Service Registry에서 제거한다.
- Renew Interval은 서버 내부적으로 유레카 클라이언트를 관리하는 로직이 있기 때문에 변경하는 것을 권장하지 않는다.
- Peering
- 여러대의 유레카 서버를 사용하면 서로 통신할 수 있도록 구성해야하는 데 이것을 Peering 구성이라고 한다.
- Self-Preservation Mode
- 유레카 인스턴스가 요청을 처리할 수는 있지만 단순 Heartbeat를 전송하지 못하는 상황을 대비하여 self-preservation을 사용한다.
- 이는 registry에서 문제된 인스턴스를 지정한 시간동안 제거하지 않을 수 있다.
시나리오
그렇다면, MSA, API Gateway, Eureka 흐름 시나리오를 짜보면 아래와 같을 것이다.
참고
'Activity > 한이음 - MSA 기반 시스템' 카테고리의 다른 글
| 우아한 멀티 모듈 세미나 정리 (1) | 2022.12.09 |
|---|---|
| 한이음 - MSA를 공부하면서 고민했던 것들. (0) | 2022.06.02 |
| 한이음 - MSA 기반 인사이력 블록체인 검증 시스템 (0) | 2022.06.02 |
