💡 API Gateway
API Gateway가 무엇인지 자세하게 설명
Load Balancer와의 공통점과 차이점 설명
API Gateway
API Gateway는 Client → Server로 통신할 때 사용하는 많은 api들의 관문(대문) 역할을 하는 서비스
사용자가 요청한 데이터를 적절한 서버로 보내고, 서버가 응답한 결과를 사용자에게 전달하는 역할
API Gateway 사용 전
API Gateway 사용 후
필요성
많은 서비스들이 마이크로 서비스 아키텍처 형태로 구축되고 있음. 하지만 작은 단위의 서비스가 50개, 100개가 되었을 때, 이 많은 서비스들의 엔드포인트를 관리하는데 있어 어려움이 있음. 공통으로 들어가는 기능을 중복으로 개발해야한다는 문제가 발생.
이러한 문제점을 해결하기 위해 등장.
💡 마이크로 서비스
애플리케이션을 여러 작고 독립적인 서비스로 나누는 아키텍쳐. (예를들어, 배달 앱의 경우 주문, 결제, 사용자 관리, 추천 서비스 등으로 나눌 수 있다.)
장점
단일 진입점 제공
- 통합적으로 엔드포인트와 REST API를 관리할 수 있다.
- 각 서비스의 엔드포인트로 바로 가지 않고, API Gateway로 요청을 전달.
- 사용자가 설정한 라우팅 설정에 따라서 각 엔드포인트로 클라이언트를 대신하여 요청, 응답을 받으면 다시 클라이언트에게 전달하는 프록시 역할.
부가적 기능 제공, 중복 구현 방지
- 엔드포인트 서버에서 공통으로 필요한 인증/인가, 사용량 제어, 요청/응답 변조 등의 다양한 기능을 제공.
- 각 엔드포인트마다 위의 기능들을 구현하지 않아도 되므로 개발 비용을 줄일 수 있음.
서비스 변경에 따른 유연성 제공
- 서비스의 URL이 변경되거나 API 포맷이 달라져도 API Gateway에서 이를 매핑해 처리하므로, 클라이언트는 이를 신경 쓸 필요가 없습니다.
- 기존
/order서비스가/new-order로 변경되더라도, API Gateway가 요청을 적절히 라우팅.
클라이언트는 여전히/order로 요청을 보낼 수 있다.
API Gateway와 Load Balancer의 차이
Load Balancer
서버에 부하를 분산시키는 역할.
한 서버에 너무 많은 요청이 몰리면 과부하가 걸릴 수 있기 때문에, 여러 서버에 요청을 골고루 나눠주는 도우미입니다.
차이점
| 구분 | API Gateway | Load Balancer |
|---|---|---|
| 목적 | 요청을 적절한 서비스로 전달 | 서버에 요청을 골고루 분배하여 부하를 줄임 |
| 예시 | "주문 API는 어디로 보내지?"를 결정 | "요청을 처리할 서버는 누구?"를 결정 |
| 초점 | API관리, 라우팅에 중점을 둔다. | 트래픽 분산, 서버 부하 관리에 중점을 둔다. |
- 공통점 : 둘 다 클라이언트 요청을 받아서 적절한 대상으로 전달하는 역할, 클라이언트 요청의 흐름을 관리
- API Gateway: 종합 안내 데스크. 손님이 원하는 서비스(주문, 결제 등)를 올바른 부서로 안내하고 필요한 추가 절차(신분 확인 등)도 처리합니다.
- Load Balancer: 손님을 여러 창구로 나눠주는 접수원. 특정 창구에 사람이 몰리는 걸 방지하고, 모든 창구가 바쁘다면 추가 창구를 열 수 있습니다.
API Gateway와 Load Balancer를 함께 사용
- API Gateway: 요청을 "주문 서비스"로 보낼지, "결제 서비스"로 보낼지 등을 결정.
- Load Balancer: "주문 서비스"를 처리하는 서버 중 어느 서버로 보낼지 결정.
참고 링크
일단 할 수 있는걸 하자.