timeline 1980년대 : Request/Response 프로토콜, RPC 1990년대 : CORBA, EAI 2000년대 : Reverse Proxy, SOA, ESB : Web 2.0 2010년대 ~ 현재 : Microservice, Kubernetes : API Gateway, Service Mesh 2020년대 : Kubernetes Gateway API?
Mermaid
복사
API Gateway, Service Mesh 이전과 현재 그리고 미래
Introduction
현 Microservice, Kubernetes 시대의 API Gateway, Service Mesh에 대해, Legacy 기술 관점과 주요 keyword 간의 연결 중심으로 간략히 논한다.
함께 다루는 주요 keywords
RPC, CORBA, EAI, ESB, SOA, Web Service, Web 2.0, Reverse Proxy, Microservice, Kubernetes, Kubernetes Gateway PI, gRPC, Kafka
API Gateway, Service Mesh가 나타나기까지
1980년대 : Request/Response 프로토콜 시작, RPC
•
시스템 간 연동을 위한 저수준(low level) socket 프로그래밍은 네트워크에 대한 깊은 지식이 필요함에 따라 고수준(high level)의 프로토콜 요구 대두. 한편, 현재 가장 많이 사용되는 remote call 프로토콜인 HTTP은 1960년대 후반에 만들어진 Request/Response 프로토콜에 기반함.
•
•
RPC는 위치 투명성 제공이 중요. 즉 호출자 관점에서 상대방의 위치(로컬 또는 원격)에 대한 정보가 불필요하거나 최소화되어야 함을 강조. 일종의 약결합 아키텍처 채택
1990년대 : CORBA, EAI
이기종간 RPC 기반 통신, CORBA : 1990년대 초
CORBA 통신/구현 모델. 이미지 출처 : https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture
•
CORBA(Common Object Request Broker Architecture)는 서로 다른 운영체제, 프로그래밍 언어, 컴퓨터 하드웨어 간의 통신을 위한 RPC 기반 표준으로 객체 지향(Object Oriented) 모델을 채용(분산 객체. 참조)
•
(특히 우리나라에서 유명했던, 그리고 원흉이었던) Active-X(이외에 COM, DCOM, EJB...)가 사실 상 본 모델을 사용
•
현재 Microservice 간의 통신에 자주 채택되는 gRPC 는 사실 상 본 모델 구현의 하나임. stub, IDL 등의 개념이 모두 포함됨. proxy 또는 broker 의 개념 본격 채용과 함께
기업 시스템 간의 통합, EAI : 1990년대 말
•
시스템 및 시스템 간 연동 요구가 많아지는 상황에, 앞선 RPC, CORBA 등으로 연동이 용이해지면서 시스템 연동에 특화된 기업용 미들웨어가 나타남 - EAI(Enterprise Application Integeration). 특히, 단일 전용 시스템을 중심으로 각 시스템을 연결하는 Hub and spoke 구성으로, 다수의 시스템 간 P2P 연동으로 인한 아키텍처 복잡도 증대 문제를 해결
EAI의 Hub and spoke 아키텍처. 이미지 출처 : https://blogs.mulesoft.com/dev-guides/how-to-tutorials/esb-or-not-to-esb-revisited-part-2/
한편, B2C 영역에서는 HTTP 프로토콜 기반의 Web Service가 부각되기 시작하는데…
2000년대 : 서비스(Service)의 부각, Reverse Proxy, SOA, ESB
•
Reverse Proxy 사용 일반화 : Web Service가 internet의 중심으로 부각되며 (static resource) caching, load balancing, security 등을 전담하도록 Reverse Proxy가 Web Server에서 분리됨. 그 유명한 3티어 아키텍처(Reverse Proxy / Web(application) Server / DB)의 주요 컴포넌트로 안착(참조). 또한 난립 중이던 프로토콜은 HTTP란 단일 프로토콜로 수렴됨. HAProxy, Apache httpd, NGINX는 대표적인 Reverse Proxy 구현체임.
Reverse Proxy의 위치. 이미지 출처 : https://en.wikipedia.org/wiki/Reverse_proxy
•
SOA(Service Oriented Architecture) 대두 : 자기완결성을 가지며 외부에 endpoint를 노출하는 workload를 가리켜 서비스(Service)란 명칭으로 (사실 상) 최초 표현하기 시작. Web Service으로 일반화된 HTTP 프로토콜 및 XML을 기반으로 RPC 의 (상대적) 강결합(tightly coupled) 구조를 개선한 SOAP(Simple Object Access Protocol)을 사용
•
ESB(Enterprise Service Bus) : SOA가 취한 약결합 기반의 서비스 간 연동 시스템으로 일종의 EAI 업그레이드 버전. EAI 의 hub and spoke 구조와는 달리 메시지 변환 및 라우팅 등을 engine 자체가 아닌 adapter에서 수행함으로 약결합과 확장성 장점 모두를 취함(참조). 순수하게 서비스 간 연동 관점으로 보았을 때, Apache Kafka는 ESB 가 취한 주요 약결합의 구현 개념인 event driven(e.g. EDA) message oriented(e.g. MOM)을 취한 ESB 의 사실 상 계승자일 수도
ESB bus 아키텍처. 이미지 출처 : https://blogs.mulesoft.com/dev-guides/how-to-tutorials/esb-or-not-to-esb-revisited-part-2/
한편 2000년대 말이 되자, B2C에서는 SOA, SOAP 의 복잡성, verbosity 등으로 인해, JSON 과 AJAX(Asynchronous JavaScript and XML - presentation과 data의 분리)를 중심으로한 Web 2.0 이 대두됨. 나아가 Web Service가 대성공을 거두며 컴퓨팅 패러다임을 이끄는 주류가 B2B에서 B2C로 옮겨감과 함께 JSON은 사실 상 XML을 완전 대체하며 자연스럽게 SOA 와 ESB 는 역사 속으로…
2010년대 : Microservice, Kubernetes
Web Service가 활성화 됨에 따라 B2C에서도 서비스 간 연동 요구 또한 증대됨. Web Service의 (HTTP) API(Application Programming Interface)를 통해 연동을 위한 endpoint 노출 역시 보편화되는 사이…
•
Microservice 대두: Web 2.0 으로 인해 SOA 는 묻혔지만 서비스 간 연동을 위한 SOA의 주요 개념은 여전히 유효. 이에 따라 SOA는 Microservice Architecture란 명칭으로 새롭게 태어남. 이 아키텍처는 사실 상 SOA의 현대적 해석(biz logic 캡슐화, 균일한 인터페이스, 검색 메커니즘 기반 공개적 사용 등. 참조)
•
Kubernetes : 한편 저수준에서는 Cloud Computing과 함께 Docker 를 위시한 container 기술이 발달. 특히 container는 다수의 서비스, 즉 Microservice를 cloud에서 운용하기 위한 최적의 기반 기술로 인정되고, 이들 container에 대한 orchestration을 위한 대표 기술로 Kubernetes 가 나타남
이제 API Gateway, Service Mesh
API Gateway와 Service Mesh는 앞서 논한 기존 기술을 개선과 동시에 대체한 솔루션으로서, 각기 다른 요구에 의해 2010년대에 상호 독립적으로 나타남. 이제 앞서 논한 기술 용어를 빌려 이들을 재구성하자면,
API Gateway
Microservice Architecture 에 클라이언트 대 다수 서비스 연동 솔루션이 필요한 상황에서 API Gateway는,
API Gateway Pattern. 이미지 출처 : https://medium.com/design-microservices-architecture-with-patterns/api-gateway-pattern-8ed0ddfce9df
•
client로의 여러 (마이크로) 서비스에 대한 단일 endpoint 접점 제공, routing, service discovery, 서비스의 각종 cross cutting concerns 처리 등으로 기존 Reverse Proxy 을 대체함과 동시에,
•
다수의 서비스에 대한 중앙 집중적 연동 및 약결합 기반 endpoint 제공으로 EAI , ESB 의 주요 역할 대체(다만, EAI, ESB 와는 달리 서비스 간 연동이 아닌 다수의 서비스에 대한 client로의 접점 제공으로 촛점이 옮겨감)
Service Mesh
앞선 Reverse Proxy 의 도입 요구가 Microservice Architecture 의 각 Microservice 에도 부각되기 시작. 이 요구는 보통 rich client 형태로 해당 Microservice 내 library로 구현됨. 한편 Kubernetes 부각되면서 pod 내 biz logic을 다루는 container와 별도로 container(sidecar)를 운용할 공간이 마련되던 중 Service Mesh는,
Istio 아키텍처. 이미지 출처 : https://istio.io/latest/docs/ops/deployment/architecture/
•
sidecar로서 Reverse Proxy 를 개별 서비스에 주입함으로 rich client - library로 인한 서비스 의존성 제거
•
이들 sidecar를 Service Mesh control plane에서 통합 관리함으로 EAI, ESB 의 역할인 클러스터 수준 관점으로 QoS, routing, security 등의 역할 대체
API Gateway, Service Mesh의 미래
API Gateway와 Service Mesh 모두 기술적 관점에서는 Reverse Proxy에 공통적으로 의존한다는 점이 유의미. 따라서 이들 둘 모두 운용의 기술적 세부 측면에서 상당 부분 동일함. (이로 인해?) Kubernetes는 결국 이들을 Kubernetes Gateway API 란 이름으로 통합 중임.
Kubernetes Gateway API에 대해서는 
API Gateway + Service Mesh = Kubernetes Gateway API 와 Ingress + API Gateway = Kubernetes Gateway API 를 참조.
API Gateway + Service Mesh = Kubernetes Gateway API 와 Ingress + API Gateway = Kubernetes Gateway API 를 참조.
