마이크로서비스 아키텍처(MSA)가 널리 사용되면서, 이를 뒷받침하는 핵심 구성 요소 중 하나가 바로 API Gateway이다.
클라이언트와 다수의 백엔드 서비스 사이에서 중심 역할을 하며, 시스템의 안전성과 확장성을 지탱하는 API Gateway의 개념과 등장 배경, 그리고 핵심 특징을 이 글에서 정리한다.
API Gateway란?
API Gateway는 클라이언트와 백엔드 서비스 사이의 통신을 중개하는 진입점이다.
모든 클라이어늩 요청은 API Gateway를 거쳐 해당 백엔드 서비스로 전달되며, 응답 또한 Gateway를 통해 다시 클라이언트에게 전달된다.
📌 API Gateway 정의
API Gateway는 모든 API 요청을 한 곳에서 수신하고, 해당 요청을 적절한 내부 서비스로 라우팅하는 프록시 서버이다.
🔁 기본 흐름 예시
[Client]
↓
[API Gateway]
↓
[User Service], [Product Service], [Order Service] ...- 이 구조 덕분에 클라이언트는 여러 백엔드 서비스를 직접 호출하지 않고도 하나의 통합된 API로 모든 기능을 사용할 수 있다.
API Gateway 패턴의 등장 배경
1️⃣ 모놀로식 아키텍처의 한계
기존 모놀리식(monolithic) 애플리케이션은 하나의 덩어리로 모든 기능이 묶여 있어 확장성과 유지보수에 큰 어려움이 있었다.
- 하나의 코드베이스
- 작은 변경도 전체 애플리케이션 재배포 필요
- 서비스 간 결합도 높음
👉 이를 해결하기 위해 등장한 것이 SOA(Service Oriented Architecture), 그리고 마이크로서비스 아키텍처(MSA)이다.
2️⃣ 마이크로서비스와 RESTful API의 부상
서비스를 작게 쪼개고, 각 서비스는 독립적으로 운영되며 HTTP 기반 REST API로 통신하게 되었다. 그러나..
마이크로서비스가 많아질수록 클라이언트는 수많은 API 엔드포인트를 직접 관리해야 했다.
✔️ 이때 서비스 간 통신을 중앙에서 중재해 줄 수 있는 구조가 필요했고, API Gateway가 그 해답이 되었다.
3️⃣ 클라우드 환경과 보안 요구의 증가
- 인증, 권한 관리, 로깅, 트래픽 제어 등 공통 기능을 각 서비스가 처리하면 중복 코드 증가
- 배포 환경이 다양해지고 클라우드 네이티브 구조가 확산되며 중앙 집중형 게이트웨이의 필요성이 커졌다.
👉 결과적으로 API Gateway는 보안, 성능, 유연한 통신을 지원하는 클라우드 시대의 핵심 인프라 구성 요소로 자리잡았다.
API Gateway가 필요한 이유
마이크로서비스가 증가할수록 통신 경로는 복잡해진다. 예를 들어 프론트엔드에서 사용자 정보를 조회하고, 주문 목록과 결제 정보를 가져와야 한다면?
[Client] → [User Service]
→ [Order Service]
→ [Payment Service]- 이러한 구조는 보안, 성능, 유지보수 모두 어렵게 만든다.
💡 API Gateway 도입 시
[Client] → [API Gateway] → [각 서비스]- 하나의 엔드포인트 (api.example.com)만 호출하면 되므로 프론트엔드가 단순해진다.
- 공통 관심사(인증, 로깅, 모니터링 등)를 한곳에서 처리 가능
API Gateway의 역할과 특징, 실전에서 어떻게 쓰일까?
API Gateway는 단순한 프록시 이상의 역할을 수행하며, 서비스의 안정과 효율성을 위한 다양한 기능을 내장하고 있다.
API Gateway의 주요 역할
1️⃣ 개발과 운영의 간편화
- 클라이언트는 다양한 서비스에 직접 접근하지 않고 API Gateway만 호출
- 각 마이크로서비스의 주소, 인증, 응답 포맷 등을 Gateway가 처리하므로 프론트엔드와 백엔드 간 결합도 최소화
📌 예시
- 프론트엔드에서 /api/user로 요청만 보내면, Gateway가 자동으로 내부 UserService로 라우팅
2️⃣ 서비스 통합 및 중복 방지
- 인증, 로깅, 응답 캐싱 등 공통 로직을 API Gateway에서 처리
- 각 서비스에 중복 코드를 작성할 필요 없음
📌 예시
- 모든 요청에 대해 JWT 인증을 API Gateway에서 한 번만 처리하고, 이후 서비스에 전달
3️⃣ 보안 및 통신 환경 강화
- 인증/권한 검사, SSL 처리, 요청 제한(Rate Limit) 등을 중앙에서 관리
- 외부와 내부 서비스 간 직접 통신 차단 -> 보안 강화
📌 예시
- 웹 애플리케이션이 인증 없이 ProductService에 직접 접근하는 것을 방지하고, Gatway를 통해 토큰 확인 후만 접근 허용
API Gateway의 다양한 특징
🌐 Backend for Frontend (BFF)
클라이언트별 최적화된 API 제공
- 웹/모바일/IoT 등 클라이언트의 특성을 고려한 API 제공
- 하나의 백엔드가 아닌, 사용자 인터페이스 별로 맞춤형 API 구성
📌 예시
- 모바일 전용 BFF -> 더 적은 필드와 최적화된 응답 제공
- 웹 BFF -> 더 많은 상세 정보 포함
🔍 Service Registry & Discovery
동적으로 서비스를 찾고 라우팅
- 마이크로서비스의 IP나 포트가 동적으로 바뀌는 환경에서 사용
- API Gateway는 레지스트리(예: Eureka)와 연결하여 서비스 주소를 동적으로 조회
📌 예시
- /api/order 요청시, Gateway가 Eureka에서 OrderService 인스턴스를 찾고 자동으로 요청 전달
🗂 External Configuration Store
설정 정보를 외부 시스템에서 관리
- 서비스 배포 없이 설정 변경 가능
- Spring Cloud Config, Consul, etcd 등을 통해 구성 관리
📌 예시
- 요일별 요청 제한 설정을 Config Server에서 읽어와 적용
🔐 Autentication & Authorization
보안은 기본, 인증과 권한을 중앙에서 관리
- JWT, OAuth 2.0, API Key 등 다양한 인증 방식 적용 가능
- 민감한 데이터에 대한 접근을 리졸버 단이 아닌 Gateway에서 미러 필터링
📌 예시
- 로그인 사용자의 역할(Role)에 따라 관리자 전용 API는 접근 차단
Circuit Breaker (서킷 브레이커)
장애 확산을 막는 핵심 패턴
- 특정 서비스가 일정 횟수 이상 실패하면 해당 서비스로의 호출을 일시적으로 차단
- 빠르게 fallback 응답 반환 -> 전체 시스템 장애 방지
📌 예시
- ProductService가 느려지면, Gateway가 fallback 응답으로 "서비스 지연 중" 메시지를 반환
📊 Monitoring & Tracing
시스템 상태를 실시간으로 추적
- 메트릭 수집, 지연 시간 분석, 오류 모니터링 등 지원
- Prometheus, Grafana, Zipken, Jaeger 등과 연동 가능
📌 예시
- 특정 시간대 / api / payment 요청 지연이 발생한 원인을 Zipkin을 통해 추적 가능
Centralized Log Aggregation
로그는 분산되어도 분석은 중앙에서
- 각 마이크로서비스에서 발생하는 로그를 중앙 시스템(ELK, Loki 등)에 수집
- 장애 발생 시 서비스 간 전체 로그 추적 가능
📌 예시
- Kibana에서 "결제 실패" 로그를 필터링하여 PaymentService의 오류 흐름 추적
실무에서 활용되는 API Gateway 사례 모음
마이크로서비스 아키텍처를 채택한 기업이라면 거의 예외 없이 API Gateway를 도입한다.
하지만 어떤 기업이 어떤 API Gateway를 선택했는지, 왜 선택했는지, 그리고 각각 어떤 특징을 가지는지는 잘 알려져 있지 않다.
🎬 Netflix - Zuul
Netflix는 마이크로서비스 아키텍처의 선도 주자이며, 그 중심에는 API Gateway 역할을 수행하는 Zuul이 있었다.
Zuul의 주요 특징
- 동적 라우팅
- 인증 및 보안 처리
- 모니터링
- 필터 기반 요청 처리 체계 (Pre, Post, Error 등)
📌 예시
- Netflix 사용자 로그인 ➡️ /auth/login ➡️ Zuul이 인증 처리 필터 실행 ➡️ Auth 서비스로 포워딩 ➡️ 응답 반환
🛑 Zuul의 대체: Zuul 2 또는 Spring Cloud Gateway
Zuul은 2018년 12월 이후 메인 개발 중단(Maintenance Mode) 상태로 진입했다.
성능 이슈(블로킹 I/O 기반)로 인해, Netflix는 내부적으로 Zuul 2(비동기, Netty 기반)로 전환했으며, 오픈 커뮤니티에서는 Spring Cloud Gateway로 전환하는 사례가 많아졌다.
🏠 Airbnb - Envoy Proxy
Airbnb는 API Gateway로 Envoy Proxy를 선택했다.
Envoy는 Lyft에서 개발했으며, 지금은 CNCF(Cloud Native Computing Foundation)의 핵심 프로젝트이다.
Envoy의 핵심 특징
- 동적 서비스 디스커버리
- 로드 밸런싱
- gRPC 및 HTTP/2 지원
- 트래픽 미러링, 시간 제한, 재시도 정책 설정
- Observability(가시성): 메트릭, 로깅, 트레이싱 지원
📌 예시
- Airbnb 앱이 /booking/info 호출 ➡️ Envoy Proxy가 서비스 레지스트리에서 BookingService 인스턴스를 조회 후 연결
👉 OpenTracing을 통해 Zipkin에 트레이스 기록까지 자동 수집
Envoy는 단순 API Gateway를 넘어서, Service Mesh의 핵심 프록시로도 많이 사용된다.
🛒 Amazon - Amazon API Gateway
AWS 환경에서 서버리스 아키텍처 또는 마이크로서비스를 도입했다면, Amazon API Gateway는 매우 강력한 선택이다.
Amazon API Gateway의 특징
- Lambda, EC2, ECS, ALB 등 다양한 백엔드와 통합
- Swagger(OpenAPI) 기반 API 설계 및 문서화
- 요청 제한, 인증(OAuth/JWT), CORS 정책 적용 지원
- 완전 관리형 서비스 (서버 운영 필요 없음)
📌 예시
- 고객이 S3에 업로드한 이미지를 처리하기 위해 /image/process 호출
👉 API Gateway가 요청 유효성 검사 ➡️ Lambda 호출 ➡️ 결과 반환
AWS IAM 또는 Cognito와 통합하여 권한 제어까지 깔금하게 해결 가능
🌱 Spring - Spring Cloud Gateway
Java/Spring 기반 마이크로서비스 환경에서는 Spring Cloud Gateway가 거의 표준처럼 사용된다.
Spring Cloud Gateway의 주요 특징
- Netty 기반 비동기 I/O (Reactive Stack)
- 다양한 라우팅 옵션 (Path, Host, Header, QueryParam 등)
- 필터 체인 구성 (Pre, Post, Error 등)
- 통합 모니터링 (Micrometer, Prometheus, Zipkin 등)
- 고성능 비동기 처리 기반 -> 경량화된 서비스에 최적화
📌 예시
- 프론트엔드에서 /api/v1/products 요청
👉 Spring Cloud Gateway가 JWT 인증 필터 적용 후 ProductSerivce로 전달
👉 응답 시 CORS 헤더 필터 적용 후 클라이언트에 반환
🤔 리액티브 프로그래밍 기반 구성 시 이점
Spring Cloud Gateway는 WebFlux 기반의 리액티브 처리 모델을 따른다.
장점
- 높은 동시성 처리: 블로킹 없이 다수 요청 처리 가능
- 리소스 효율성 향상: 적은 스레드 수로도 고부하 처리 가능
- 빠른 응답 시간: 네트워크 I/O 및 외부 호출 최적화
예시: 서버가 100개의 요청을 받더라도, 각 요청이 내부 서비스 호출을 기다리는 동안에도 다른 요청을 처리 가능 (동기 방식에서는 쓰레드가 블로킹됨)
'아키텍처 & 설계(Architecture & Design) > MSA' 카테고리의 다른 글
| [API Gateway] API Gateway에서의 트래픽 제어 (0) | 2025.04.08 |
|---|---|
| [API Gateway] API Gateway에서 인증과 인가 처리 방법 (0) | 2025.04.02 |
| [API Gateway] API Gateway 라우팅 (0) | 2025.04.01 |
| [API Gateway] API Gateway 프록시 서버 개념과 역할 (0) | 2025.03.31 |
| MSA 멀티 모듈 설정 (0) | 2024.04.24 |
마이크로서비스 아키텍처(MSA)가 널리 사용되면서, 이를 뒷받침하는 핵심 구성 요소 중 하나가 바로 API Gateway이다.
클라이언트와 다수의 백엔드 서비스 사이에서 중심 역할을 하며, 시스템의 안전성과 확장성을 지탱하는 API Gateway의 개념과 등장 배경, 그리고 핵심 특징을 이 글에서 정리한다.
API Gateway란?
API Gateway는 클라이언트와 백엔드 서비스 사이의 통신을 중개하는 진입점이다.
모든 클라이어늩 요청은 API Gateway를 거쳐 해당 백엔드 서비스로 전달되며, 응답 또한 Gateway를 통해 다시 클라이언트에게 전달된다.
📌 API Gateway 정의
API Gateway는 모든 API 요청을 한 곳에서 수신하고, 해당 요청을 적절한 내부 서비스로 라우팅하는 프록시 서버이다.
🔁 기본 흐름 예시
[Client]
↓
[API Gateway]
↓
[User Service], [Product Service], [Order Service] ...- 이 구조 덕분에 클라이언트는 여러 백엔드 서비스를 직접 호출하지 않고도 하나의 통합된 API로 모든 기능을 사용할 수 있다.
API Gateway 패턴의 등장 배경
1️⃣ 모놀로식 아키텍처의 한계
기존 모놀리식(monolithic) 애플리케이션은 하나의 덩어리로 모든 기능이 묶여 있어 확장성과 유지보수에 큰 어려움이 있었다.
- 하나의 코드베이스
- 작은 변경도 전체 애플리케이션 재배포 필요
- 서비스 간 결합도 높음
👉 이를 해결하기 위해 등장한 것이 SOA(Service Oriented Architecture), 그리고 마이크로서비스 아키텍처(MSA)이다.
2️⃣ 마이크로서비스와 RESTful API의 부상
서비스를 작게 쪼개고, 각 서비스는 독립적으로 운영되며 HTTP 기반 REST API로 통신하게 되었다. 그러나..
마이크로서비스가 많아질수록 클라이언트는 수많은 API 엔드포인트를 직접 관리해야 했다.
✔️ 이때 서비스 간 통신을 중앙에서 중재해 줄 수 있는 구조가 필요했고, API Gateway가 그 해답이 되었다.
3️⃣ 클라우드 환경과 보안 요구의 증가
- 인증, 권한 관리, 로깅, 트래픽 제어 등 공통 기능을 각 서비스가 처리하면 중복 코드 증가
- 배포 환경이 다양해지고 클라우드 네이티브 구조가 확산되며 중앙 집중형 게이트웨이의 필요성이 커졌다.
👉 결과적으로 API Gateway는 보안, 성능, 유연한 통신을 지원하는 클라우드 시대의 핵심 인프라 구성 요소로 자리잡았다.
API Gateway가 필요한 이유
마이크로서비스가 증가할수록 통신 경로는 복잡해진다. 예를 들어 프론트엔드에서 사용자 정보를 조회하고, 주문 목록과 결제 정보를 가져와야 한다면?
[Client] → [User Service]
→ [Order Service]
→ [Payment Service]- 이러한 구조는 보안, 성능, 유지보수 모두 어렵게 만든다.
💡 API Gateway 도입 시
[Client] → [API Gateway] → [각 서비스]- 하나의 엔드포인트 (api.example.com)만 호출하면 되므로 프론트엔드가 단순해진다.
- 공통 관심사(인증, 로깅, 모니터링 등)를 한곳에서 처리 가능
API Gateway의 역할과 특징, 실전에서 어떻게 쓰일까?
API Gateway는 단순한 프록시 이상의 역할을 수행하며, 서비스의 안정과 효율성을 위한 다양한 기능을 내장하고 있다.
API Gateway의 주요 역할
1️⃣ 개발과 운영의 간편화
- 클라이언트는 다양한 서비스에 직접 접근하지 않고 API Gateway만 호출
- 각 마이크로서비스의 주소, 인증, 응답 포맷 등을 Gateway가 처리하므로 프론트엔드와 백엔드 간 결합도 최소화
📌 예시
- 프론트엔드에서 /api/user로 요청만 보내면, Gateway가 자동으로 내부 UserService로 라우팅
2️⃣ 서비스 통합 및 중복 방지
- 인증, 로깅, 응답 캐싱 등 공통 로직을 API Gateway에서 처리
- 각 서비스에 중복 코드를 작성할 필요 없음
📌 예시
- 모든 요청에 대해 JWT 인증을 API Gateway에서 한 번만 처리하고, 이후 서비스에 전달
3️⃣ 보안 및 통신 환경 강화
- 인증/권한 검사, SSL 처리, 요청 제한(Rate Limit) 등을 중앙에서 관리
- 외부와 내부 서비스 간 직접 통신 차단 -> 보안 강화
📌 예시
- 웹 애플리케이션이 인증 없이 ProductService에 직접 접근하는 것을 방지하고, Gatway를 통해 토큰 확인 후만 접근 허용
API Gateway의 다양한 특징
🌐 Backend for Frontend (BFF)
클라이언트별 최적화된 API 제공
- 웹/모바일/IoT 등 클라이언트의 특성을 고려한 API 제공
- 하나의 백엔드가 아닌, 사용자 인터페이스 별로 맞춤형 API 구성
📌 예시
- 모바일 전용 BFF -> 더 적은 필드와 최적화된 응답 제공
- 웹 BFF -> 더 많은 상세 정보 포함
🔍 Service Registry & Discovery
동적으로 서비스를 찾고 라우팅
- 마이크로서비스의 IP나 포트가 동적으로 바뀌는 환경에서 사용
- API Gateway는 레지스트리(예: Eureka)와 연결하여 서비스 주소를 동적으로 조회
📌 예시
- /api/order 요청시, Gateway가 Eureka에서 OrderService 인스턴스를 찾고 자동으로 요청 전달
🗂 External Configuration Store
설정 정보를 외부 시스템에서 관리
- 서비스 배포 없이 설정 변경 가능
- Spring Cloud Config, Consul, etcd 등을 통해 구성 관리
📌 예시
- 요일별 요청 제한 설정을 Config Server에서 읽어와 적용
🔐 Autentication & Authorization
보안은 기본, 인증과 권한을 중앙에서 관리
- JWT, OAuth 2.0, API Key 등 다양한 인증 방식 적용 가능
- 민감한 데이터에 대한 접근을 리졸버 단이 아닌 Gateway에서 미러 필터링
📌 예시
- 로그인 사용자의 역할(Role)에 따라 관리자 전용 API는 접근 차단
Circuit Breaker (서킷 브레이커)
장애 확산을 막는 핵심 패턴
- 특정 서비스가 일정 횟수 이상 실패하면 해당 서비스로의 호출을 일시적으로 차단
- 빠르게 fallback 응답 반환 -> 전체 시스템 장애 방지
📌 예시
- ProductService가 느려지면, Gateway가 fallback 응답으로 "서비스 지연 중" 메시지를 반환
📊 Monitoring & Tracing
시스템 상태를 실시간으로 추적
- 메트릭 수집, 지연 시간 분석, 오류 모니터링 등 지원
- Prometheus, Grafana, Zipken, Jaeger 등과 연동 가능
📌 예시
- 특정 시간대 / api / payment 요청 지연이 발생한 원인을 Zipkin을 통해 추적 가능
Centralized Log Aggregation
로그는 분산되어도 분석은 중앙에서
- 각 마이크로서비스에서 발생하는 로그를 중앙 시스템(ELK, Loki 등)에 수집
- 장애 발생 시 서비스 간 전체 로그 추적 가능
📌 예시
- Kibana에서 "결제 실패" 로그를 필터링하여 PaymentService의 오류 흐름 추적
실무에서 활용되는 API Gateway 사례 모음
마이크로서비스 아키텍처를 채택한 기업이라면 거의 예외 없이 API Gateway를 도입한다.
하지만 어떤 기업이 어떤 API Gateway를 선택했는지, 왜 선택했는지, 그리고 각각 어떤 특징을 가지는지는 잘 알려져 있지 않다.
🎬 Netflix - Zuul
Netflix는 마이크로서비스 아키텍처의 선도 주자이며, 그 중심에는 API Gateway 역할을 수행하는 Zuul이 있었다.
Zuul의 주요 특징
- 동적 라우팅
- 인증 및 보안 처리
- 모니터링
- 필터 기반 요청 처리 체계 (Pre, Post, Error 등)
📌 예시
- Netflix 사용자 로그인 ➡️ /auth/login ➡️ Zuul이 인증 처리 필터 실행 ➡️ Auth 서비스로 포워딩 ➡️ 응답 반환
🛑 Zuul의 대체: Zuul 2 또는 Spring Cloud Gateway
Zuul은 2018년 12월 이후 메인 개발 중단(Maintenance Mode) 상태로 진입했다.
성능 이슈(블로킹 I/O 기반)로 인해, Netflix는 내부적으로 Zuul 2(비동기, Netty 기반)로 전환했으며, 오픈 커뮤니티에서는 Spring Cloud Gateway로 전환하는 사례가 많아졌다.
🏠 Airbnb - Envoy Proxy
Airbnb는 API Gateway로 Envoy Proxy를 선택했다.
Envoy는 Lyft에서 개발했으며, 지금은 CNCF(Cloud Native Computing Foundation)의 핵심 프로젝트이다.
Envoy의 핵심 특징
- 동적 서비스 디스커버리
- 로드 밸런싱
- gRPC 및 HTTP/2 지원
- 트래픽 미러링, 시간 제한, 재시도 정책 설정
- Observability(가시성): 메트릭, 로깅, 트레이싱 지원
📌 예시
- Airbnb 앱이 /booking/info 호출 ➡️ Envoy Proxy가 서비스 레지스트리에서 BookingService 인스턴스를 조회 후 연결
👉 OpenTracing을 통해 Zipkin에 트레이스 기록까지 자동 수집
Envoy는 단순 API Gateway를 넘어서, Service Mesh의 핵심 프록시로도 많이 사용된다.
🛒 Amazon - Amazon API Gateway
AWS 환경에서 서버리스 아키텍처 또는 마이크로서비스를 도입했다면, Amazon API Gateway는 매우 강력한 선택이다.
Amazon API Gateway의 특징
- Lambda, EC2, ECS, ALB 등 다양한 백엔드와 통합
- Swagger(OpenAPI) 기반 API 설계 및 문서화
- 요청 제한, 인증(OAuth/JWT), CORS 정책 적용 지원
- 완전 관리형 서비스 (서버 운영 필요 없음)
📌 예시
- 고객이 S3에 업로드한 이미지를 처리하기 위해 /image/process 호출
👉 API Gateway가 요청 유효성 검사 ➡️ Lambda 호출 ➡️ 결과 반환
AWS IAM 또는 Cognito와 통합하여 권한 제어까지 깔금하게 해결 가능
🌱 Spring - Spring Cloud Gateway
Java/Spring 기반 마이크로서비스 환경에서는 Spring Cloud Gateway가 거의 표준처럼 사용된다.
Spring Cloud Gateway의 주요 특징
- Netty 기반 비동기 I/O (Reactive Stack)
- 다양한 라우팅 옵션 (Path, Host, Header, QueryParam 등)
- 필터 체인 구성 (Pre, Post, Error 등)
- 통합 모니터링 (Micrometer, Prometheus, Zipkin 등)
- 고성능 비동기 처리 기반 -> 경량화된 서비스에 최적화
📌 예시
- 프론트엔드에서 /api/v1/products 요청
👉 Spring Cloud Gateway가 JWT 인증 필터 적용 후 ProductSerivce로 전달
👉 응답 시 CORS 헤더 필터 적용 후 클라이언트에 반환
🤔 리액티브 프로그래밍 기반 구성 시 이점
Spring Cloud Gateway는 WebFlux 기반의 리액티브 처리 모델을 따른다.
장점
- 높은 동시성 처리: 블로킹 없이 다수 요청 처리 가능
- 리소스 효율성 향상: 적은 스레드 수로도 고부하 처리 가능
- 빠른 응답 시간: 네트워크 I/O 및 외부 호출 최적화
예시: 서버가 100개의 요청을 받더라도, 각 요청이 내부 서비스 호출을 기다리는 동안에도 다른 요청을 처리 가능 (동기 방식에서는 쓰레드가 블로킹됨)
'아키텍처 & 설계(Architecture & Design) > MSA' 카테고리의 다른 글
| [API Gateway] API Gateway에서의 트래픽 제어 (0) | 2025.04.08 |
|---|---|
| [API Gateway] API Gateway에서 인증과 인가 처리 방법 (0) | 2025.04.02 |
| [API Gateway] API Gateway 라우팅 (0) | 2025.04.01 |
| [API Gateway] API Gateway 프록시 서버 개념과 역할 (0) | 2025.03.31 |
| MSA 멀티 모듈 설정 (0) | 2024.04.24 |
