Why Do Microservices Need an API Gateway

마이크로서비스란 무엇인가

마이크로서비스 아키텍처는 일반적으로 마이크로서비스라고 불리며, 애플리케이션을 개발하는 데 사용되는 아키텍처 유형입니다. 마이크로서비스를 사용하면 대형 애플리케이션을 여러 독립적인 구성 요소로 분할할 수 있으며, 각 구성 요소는 고유한 책임을 가집니다. 마이크로서비스 기반 애플리케이션은 사용자 요청을 처리할 때 여러 내부 마이크로서비스를 호출하여 공동으로 응답을 생성할 수 있습니다. 마이크로서비스는 인터넷 발전의 결과물이며, 인터넷의 급속한 성장으로 인해 시스템 아키텍처가 지속적으로 변화하고 있습니다.

전체적으로 시스템 아키텍처는 대략적으로 모놀리식 아키텍처에서 SOA 아키텍처를 거쳐 마이크로서비스 아키텍처로 진화해 왔습니다. 각 아키텍처의 구체적인 진행 과정과 장단점은 아래 표에 요약되어 있습니다.

아키텍처 유형	설명	장점	단점
모놀리식 애플리케이션 아키텍처	모든 기능 코드를 단일 서비스로 패키징합니다.	1. 간단한 아키텍처로 프로젝트 개발 및 유지보수 비용이 낮습니다.	모든 모듈을 결합하는 것은 소규모 프로젝트 개발 및 유지보수에 유리하지만, 대형 프로젝트에서는 문제를 일으킬 수 있습니다. 1. 프로젝트 내 모듈이 너무 밀접하게 결합되어 있어 한 모듈의 성능 문제가 전체 프로젝트를 사용 불가능하게 만들 수 있습니다; 2. 프로젝트의 확장성이 부족합니다.
SOA 아키텍처	"서비스 지향 아키텍처"라는 용어로, 일반적으로 여러 서비스를 포함합니다. 서비스는 일반적으로 운영 체제 프로세스에서 독립적으로 존재하며, 서비스 간 통신은 종속성 또는 통신 메커니즘을 통해 이루어집니다. 궁극적으로 일련의 기능을 제공합니다.	1. 시스템 통합: 시스템적 관점에서 기업 시스템 간의 통신 문제를 해결하여 이전의 무질서하고 구조화되지 않은 네트워크 연결을 관리되고 구조화된 스타 구성으로 변환합니다. 2. 서비스 지향 시스템: 기능적 관점에서 비즈니스 로직을 재사용 가능하고 조합 가능한 서비스로 추상화하고 서비스 오케스트레이션을 사용하여 비즈니스 프로세스의 신속한 재구성을 달성합니다. 3. 비즈니스 서비스 지향: 기업 관점에서 기업 기능을 재사용 가능하고 조합 가능한 서비스로 추상화합니다.	1. 서비스를 중앙 집중화하면 서비스 간 종속성이 생기고, 한 서비스의 오류가 다른 서비스에 연쇄적인 장애를 일으킬 수 있습니다. 2. 서비스 간 종속성과 호출 관계가 복잡하여 테스트 및 배포가 어렵습니다.
마이크로서비스 아키텍처	마이크로서비스는 SOA의 승화입니다. 마이크로서비스 아키텍처의 주요 강조점 중 하나는 "비즈니스를 완전히 컴포넌트화하고 서비스화해야 한다"는 것입니다. 원래의 단일 비즈니스 시스템은 독립적으로 개발, 설계, 배포할 수 있는 여러 부분으로 분할됩니다. 이러한 부분은 작고 독립적인 애플리케이션으로 실행됩니다. 각 애플리케이션은 서로 협력하고 통신하여 통합과 상호작용을 달성하며, 이것이 마이크로서비스 아키텍처의 본질입니다.	1. 분산화; 2. 서비스를 통한 컴포넌트화; 3. 비즈니스 역량에 따라 서비스와 개발 팀을 분할; 4. 인프라 자동화 (DevOps, 자동화된 배포).	1. 개발 비용이 상대적으로 높음; 2. 서비스의 장애 허용 문제를 일으킬 수 있음; 3. 데이터 일관성 문제를 일으킬 수 있음; 4. 분산 트랜잭션을 포함함

따라서 마이크로서비스는 인터넷 발전의 필연적인 결과이며, 많은 전통적인 기업의 시스템 아키텍처도 점차 마이크로서비스 지향으로 변화하고 있습니다.

그러나 인터넷 비즈니스 발전과 함께 API의 수도 급격히 증가하고 있으며, 통합 API 관리를 위한 게이트웨이도 도전에 직면하고 있습니다. 더 강력한 API 게이트웨이를 선택하면 시스템의 모니터링, 재해 복구, 인증, 속도 제한 등의 능력을 효과적으로 향상시킬 수 있습니다.

API 게이트웨이란 무엇인가?

API 게이트웨이는 클라이언트와 서비스 시스템 간의 상호작용을 위한 통합 인터페이스를 제공하며, 요청과 응답을 관리하는 중앙 지점 역할을 합니다. 적합한 API 게이트웨이를 선택하면 개발을 단순화하고 시스템 운영 및 관리 효율성을 높일 수 있습니다.

마이크로서비스 아키텍처에서 API 게이트웨이는 다양한 모듈의 마이크로서비스를 통합하고 서비스를 통합적으로 조정하는 시스템 설계 솔루션으로 작용합니다.

시스템 접근 측면에서 API 게이트웨이는 클라이언트에게 통합 진입점을 제공하고, 시스템 아키텍처의 구현 세부 사항을 숨기며, 마이크로서비스를 더 사용자 친화적으로 만듭니다. 또한 인증, 속도 제한, 서킷 브레이커와 같은 몇 가지 공통 기능을 통합하여 각 마이크로서비스의 개별 개발을 피하고 효율성을 높이며 시스템을 표준화합니다. 예를 들어, 신원 인증, 모니터링, 로드 밸런싱, 속도 제한, 서비스 저하, 애플리케이션 탐지 등이 있습니다.

마이크로서비스가 API 게이트웨이를 필요로 하는 이유는 무엇인가?

위 그림에서 볼 수 있듯이, API 게이트웨이는 클라이언트와 마이크로서비스 사이의 중간 계층 역할을 합니다. 외부에 마이크로서비스를 통합된 주소로 제공하고, 적절한 규칙에 따라 내부 클러스터의 올바른 서비스 노드로 트래픽을 라우팅할 수 있습니다.

API 게이트웨이가 없으면 트래픽의 입구와 출구가 통합되지 않으며, 클라이언트는 모든 서비스의 접근 정보를 알아야 합니다. 마이크로서비스의 의미가 사라지게 됩니다. 따라서 마이크로서비스 아키텍처에는 마이크로서비스 게이트웨이가 필수적입니다. 또한 API 게이트웨이는 시스템 관찰 가능성, 신원 인증, 안정성, 서비스 탐지에서 중요한 역할을 합니다.

마이크로서비스가 직면한 도전

마이크로서비스 게이트웨이는 먼저 API 라우팅 기능을 가져야 합니다. 마이크로서비스의 수가 증가함에 따라 API의 수도 증가합니다. 게이트웨이는 특정 시나리오에서 트래픽 필터로 사용될 수도 있으며, 특정 선택적 기능을 제공할 수 있습니다. 따라서 마이크로서비스 API 게이트웨이에 대한 요구 사항이 높아지고 있습니다. 예를 들어:

• 관찰 가능성: 과거 모놀리식 애플리케이션에서 문제 해결은 종종 로그를 확인하여 오류 메시지와 예외 스택을 찾는 방식으로 이루어졌습니다. 그러나 많은 서비스가 있는 마이크로서비스 아키텍처에서는 문제 진단이 매우 어려워집니다. 따라서 마이크로서비스의 운영을 모니터링하고 이상이 발생할 때 신속하게 경보를 제공하는 방법은 개발자에게 큰 도전입니다.
• 인증 및 권한 부여: 마이크로서비스 아키텍처에서 애플리케이션은 여러 마이크로 애플리케이션으로 분할되며, 이들은 접근을 인증하고 현재 사용자와 그들의 권한을 인식해야 합니다. 모놀리식 애플리케이션 아키텍처의 인증 방식은 특히 브라우저뿐만 아니라 다른 서비스 호출에서도 접근이 이루어지는 경우 적합하지 않습니다. 마이크로서비스 아키텍처에서는 외부 애플리케이션 접근, 사용자-서비스 인증, 서비스-서비스 인증 등 다양한 인증 시나리오를 고려해야 합니다.
• 시스템 안정성: 요청 수가 마이크로서비스의 처리 능력을 초과하면 서비스에 과부하가 걸릴 수 있으며, 이는 시스템 전체의 안정성에 영향을 미칠 수 있습니다.
• 서비스 탐지: 마이크로서비스의 분산 관리는 로드 밸런싱 구현에도 도전을 제기합니다.

해결책

API 게이트웨이는 클라이언트와 서버 사이의 중간 다리 역할을 하며, 마이크로서비스 시스템에 통합 관리 메커니즘을 제공합니다. 요청 분배, API 관리, 조건부 라우팅과 같은 기본 기능 외에도 신원 인증, 모니터링 및 경보, 추적 분석, 로드 밸런싱, 속도 제한, 격리, 서킷 브레이커 등을 포함합니다.

신원 인증: 다음 다이어그램은 마이크로서비스가 API 게이트웨이와 통합되어 신원 인증을 수행하는 방법을 보여줍니다. 모든 요청은 게이트웨이를 통과하며, 이는 마이크로서비스를 효과적으로 숨깁니다.

모니터링 및 경보/추적 분석:

클라이언트와 서버 사이의 중개자로서 API 게이트웨이는 마이크로서비스를 모니터링하기에 훌륭한 매체입니다.

API 게이트웨이의 모니터링 기능의 주요 책임은 게이트웨이와 백엔드 서버 간의 연결 이상을 신속하게 감지하는 것입니다. 사용자는 모니터링 플랫폼에서 API에 대한 로그 정보, 모니터링 정보, 추적 등을 확인할 수 있습니다. 또한 호스트에서 발생한 모든 이상은 자동으로 제어판에 보고됩니다. 특정 게이트웨이는 클라이언트와 서버 모두에 이중 경보를 발행할 수 있습니다.

속도 제한, 격리, 서킷 브레이커:

인터넷 비즈니스 규모가 계속 증가함에 따라 시스템의 동시성도 증가합니다. 여러 서비스가 서로 호출되는 경우가 많으며, 핵심 링크는 최대 10개의 서비스를 호출할 수 있습니다. 특정 서비스의 RT(응답 시간)가 급격히 상승하고 상위 서비스가 계속 요청을 보내면 악순환이 발생할 수 있습니다. 상위 서비스가 결과를 기다리는 동안 더 많은 상위 서비스가 차단되고, 결국 전체 프로세스가 사용 불가능하게 되어 서비스 눈사태가 발생할 수 있습니다.

따라서 들어오는 트래픽을 규제하고 관리하는 것이 필요합니다. 다음 다이어그램은 마이크로서비스 시스템이 API 게이트웨이와 결합하여 속도 제한, 격리, 서킷 브레이커를 수행하는 방법을 보여줍니다.

주요 게이트웨이 선택

마이크로서비스에는 NGINX, Kong, Apache APISIX, Envoy 등 많은 오픈소스 게이트웨이 구현체가 있습니다. Java 기술 스택의 경우 Netflix Zuul, Spring Cloud Gateway, Soul 등이 있습니다. 하지만 "왜 NGINX와 Kong 대신 Apache APISIX를 선택할까요?"라는 의문이 들 수 있습니다.

여기에 간단한 비교가 있습니다.

게이트웨이	문제점	장점
NGINX	1. 변경 사항이 적용되려면 재로드가 필요하며, 이는 클라우드 네이티브 기술의 발전 속도를 따라잡지 못합니다.	1. 전통적인 애플리케이션; 2. 안정적이고 신뢰할 수 있으며 시간의 검증을 받음; 3. 고성능
Apache APISIX	1. 문서가 충분히 풍부하거나 명확하지 않아 개선이 필요합니다.	1. Apache Foundation 최상위 프로젝트; 2. 기술 아키텍처가 클라우드 네이티브 원칙에 더 부합함; 3. 우수한 성능; 4. 풍부한 생태계; 5. Lua 개발 플러그인 외에도 Java, Go, Python, Node 등의 언어 플러그인을 지원합니다.
Kong	1. 기본적으로 PostgreSQL 또는 Cassandra 데이터베이스를 사용하므로 전체 아키텍처가 매우 부풀려져 고가용성 문제를 일으킬 수 있습니다; 2. 라우팅은 순차 탐색 알고리즘을 사용하므로 게이트웨이에 수천 개의 경로가 있을 때 성능이 크게 저하될 수 있습니다; 3. 일부 중요한 기능은 유료입니다;	1. 오픈소스 API 게이트웨이의 선구자로 큰 사용자 기반을 보유하고 있습니다; 2. 성능이 대부분의 사용자 요구를 충족합니다; 3. 풍부한 생태계; 4. Lua 및 Go 플러그인 개발을 지원합니다;
Envoy	1. C++로 개발되어 있어 2차 개발이 어렵습니다; 2. C++로 필터를 개발하는 것 외에도 WASM과 Lua를 지원합니다.	1. CNCF 졸업 프로젝트로 서비스 메시 시나리오에 더 적합하며 다국어 아키텍처 배포를 지원합니다;
Spring Cloud Gateway	1. Spring 커뮤니티는 성숙하지만 Gateway에 대한 리소스가 부족합니다.	1. 게이트웨이는 다양한 즉시 사용 가능한 기능을 제공하며, SpringBoot 구성 또는 수동 코딩 호출을 통해 사용할 수 있습니다; 2. Spring 프레임워크는 확장성이 뛰어나며 구성이 쉽고 유지보수가 용이합니다; 3. Spring 커뮤니티는 성숙합니다; 4. 사용하기 쉬움; 5. Java 기술 스택에 편리합니다.

요약

인터넷 세계가 계속 발전함에 따라 기업도 빠르게 진화하며, 시스템 아키텍처는 지속적으로 변화하고 있습니다. 마이크로서비스 아키텍처는 많은 기업에서 널리 채택되고 있습니다.

마이크로서비스의 데이터와 API 양이 증가함에 따라, 높은 트래픽 관리를 위해 우수한 API 게이트웨이를 선택하는 것이 중요합니다.

이 글은 일반적인 API 게이트웨이를 비교하며, 각각의 장단점을 강조합니다. 만약 API 게이트웨이 기술을 선택하는 과정에 있거나, 마이크로서비스 시스템에서 성능 문제를 겪고 있거나, 효율적이고 안정적인 마이크로서비스 시스템을 구축하려는 경우, 이 글이 유용한 통찰력을 제공할 것입니다.