API Gateway란 무엇이며, 왜 필수적인가?
August 30, 2022
API 소개
API(Application Programming Interface)란 무엇인가요? API는 다양한 애플리케이션과 시스템 간에 데이터를 교환하는 표준적인 방법입니다. 많은 개발 팀이 API를 중심으로 설계, 구현, 테스트, 보안, 배포, 문제 해결 및 분석을 반복하는 API-퍼스트 접근 방식을 채택하고 있으며, 이는 전체 라이프사이클 API 관리(APIM)를 의미합니다.
API가 등장하기 전에는 데이터를 교환하는 표준적인 방법이 없었습니다. 컴퓨터 프로그램은 FTP, FTPS, SFTP, HTTPS 등 다양한 프로토콜을 사용하여 서로 통신했습니다. 이러한 표준의 부재는 권한 제어, 데이터 관리, 속도 제한, 감사 등 여러 측면에서 높은 개발 비용과 숨겨진 보안 위험을 초래했습니다. 이는 컴퓨터 세계의 "바벨탑" 문제입니다. 충분히 복잡한 제품을 구축하려면 다양한 언어와 데이터 저장 방식으로 개발된 시스템들로 인한 문제를 해결해야 합니다.
API의 등장은 이러한 "바벨탑" 문제를 성공적으로 해결했습니다. 개발자들은 다른 시스템이 노출한 API에만 집중하면 되며, 내부 구현 세부 사항을 이해할 필요가 없습니다.
모바일 앱, 온라인 게임, 라이브 비디오 스트리밍, 원격 회의, IoT 기기 등 클라이언트 장치와 서버 간의 연결 및 데이터 전송은 모두 API와 밀접한 관련이 있습니다. API는 이러한 통신에서 중요한 역할을 합니다.
API 게이트웨이를 사용하는 이유
API 게이트웨이는 전체 라이프사이클 API 관리에서 필수적인 구성 요소입니다. 이는 프로덕션 환경에서 API 구성, 배포, 버전 롤백, 보안 및 로드 밸런싱을 담당합니다. 또한, API 게이트웨이는 모든 클라이언트 트래픽의 입구로서, 클라이언트의 API 요청을 올바른 업스트림 서비스로 라우팅하고, 반환된 데이터를 원래 요청자에게 반환하는 동안 전체 프로세스의 안전성, 신뢰성 및 낮은 지연 시간을 보장합니다.
초기에 API가 많지 않을 때, API 게이트웨이는 일반적으로 웹 서버와 업스트림 서비스가 결합된 가상 구성 요소입니다. 라우팅, 전달, 리버스 프록시, 로드 밸런싱과 같은 간단한 기능은 Apache, NGINX 및 기타 구성 요소에 의해 수행됩니다. 인증 및 속도 제한과 같은 다른 기능은 업스트림 서비스에 의존합니다.
API 게이트웨이가 필요한 이유
그러나 API의 수가 증가함에 따라, "게으른" 개발자들은 심각한 문제를 발견했습니다. 업스트림 서비스의 다른 부분에서 동일한 인증, 속도 제한, 로깅 및 기타 기능이 반복적으로 코딩되고 있었습니다. 이는 자원 낭비일 뿐만 아니라 코드 관리의 악몽이기도 합니다. 코드의 한 부분이 수정되거나 업그레이드되면 다른 부분의 코드도 업데이트해야 합니다. 이 문제를 어떻게 해결할까요? 똑똑한 개발자들은 빠르게 해결책을 찾았습니다: 공통 기능을 추출하여 단일 구성 요소에 넣는 것입니다. 업스트림 서비스에서 비즈니스 로직과 관련 없는 코드를 빼내고, Apache와 NGINX와 같은 구성 요소를 강화했습니다. 이것이 첫 번째 세대 API 게이트웨이의 진화입니다.
API 게이트웨이의 진화 방향은 가능한 한 많은 비즈니스와 관련 없는 기능을 내장하는 것입니다. 제품 반복 속도를 높이기 위해 프론트엔드 개발자와 백엔드 개발자들은 API 게이트웨이에 대해 점점 더 많은 요구를 하고 있으며, 이는 라우팅, 전달, 리버스 프록시, 로드 밸런싱과 같은 전통적인 기능뿐만 아니라 gRPC 및 GraphQL과 같은 관측 가능성 기능도 포함됩니다.
API 게이트웨이의 역할
API 게이트웨이를 더 유연하고 효율적으로 만들기 위해, API 게이트웨이 개발자들은 기본 구조에 많은 혁신을 가져왔습니다. 예를 들어:
- 기능 플러그인. API 게이트웨이에 점점 더 많은 기능이 내장됨에 따라, 각 기능을 어떻게 분리하여 개발을 쉽게 할 수 있을까요? 레고와 같은 플러그인 메커니즘이 완벽한 해결책이 될 것입니다. 주류 API 게이트웨이들은 모두 플러그인을 사용합니다. Apache APISIX에서는 "플러그인"이라고 부르며, Envoy에서는 "필터"라고 부릅니다. 플러그인은 게이트웨이 개발자들이 구현 세부 사항에서 벗어나게 해주며, 새로운 기능을 구현하는 데 필요한 개발 자원이 줄어듭니다.
- 데이터 플레인과 컨트롤 플레인의 분리. 첫 번째 세대 API 게이트웨이에서는 데이터 플레인과 컨트롤 플레인이 동일한 컴퓨터 프로세스에서 구현되었습니다. 이는 사용자가 배포하고 사용하기 쉽지만, 상당한 보안 위험을 초래합니다. 데이터 플레인은 외부에 직접 서비스를 제공합니다. 만약 해커가 외부에서 데이터 플레인을 해킹한다면, 컨트롤 권한과 컨트롤 플레인의 데이터(예: SSL 인증서)를 얻을 수 있으며, 이는 더 큰 피해를 초래할 수 있습니다. 따라서 대부분의 오픈소스 API 게이트웨이들은 이제 DP와 CP를 별도로 배포하고, 관계형 데이터베이스나 etcd를 사용하여 구성의 관리와 동기화를 수행합니다.
Apache APISIX를 예로 들면, 다음 아키텍처 다이어그램은 위의 혁신을 보여줍니다:
클라우드 네이티브의 도전
지난 10년간 IT 분야에서 가장 큰 기술적 변화는 클라우드 네이티브입니다. 2013년에 탄생한 Docker는 클라우드 네이티브의 막을 열었습니다. 그 이후로, 베어 메탈과 가상 머신은 컨테이너로 대체되었고, 모놀리식 아키텍처는 마이크로서비스로 대체되었습니다. 그러나 클라우드 네이티브는 단순한 기술 혁명이 아닙니다. 그 배경에는 인터넷 제품의 빠른 발전과 치열한 경쟁이 있습니다. 클라우드 네이티브 관련 기술들은 적절한 시기에 탄생하여 빠르게 인기를 얻고, 이전의 많은 기술 아키텍처와 솔루션을 대체했습니다. 구체적으로, API 게이트웨이의 클라우드 네이티브 도전은 주로 다음 두 가지 측면에서 비롯됩니다:
모놀리식에서 마이크로서비스로
마이크로서비스 아키텍처가 개발자들 사이에서 인기를 얻으면서, 엄청난 기술적 이점을 가져왔습니다. 마이크로서비스는 다른 서비스와의 결합을 걱정하지 않고 자체적으로 업그레이드 및 배포할 수 있습니다. 따라서 제품 반복이 민첩해져 하루에 수십 번 또는 수백 번의 배포가 가능합니다.
그러나 마이크로서비스의 발전은 몇 가지 부작용도 가져왔습니다:
- API와 마이크로서비스의 수가 수십 개에서 수천 개 또는 수만 개로 증가했습니다.
- 어떤 API가 오류를 일으켰는지 어떻게 빠르게 찾을 수 있을까요?
- API의 보안을 어떻게 보장할 수 있을까요?
- 서비스 회로 차단 및 서비스 다운그레이드를 어떻게 달성할 수 있을까요?
API 게이트웨이는 보안, 관측 가능성, 카나리 배포와 같은 문제를 스스로 해결할 수 없습니다. Prometheus, Zipkin, Skywalking, Datadog, Okta 등 많은 다른 오픈소스 프로젝트 및 SaaS 서비스와 협력하여 기업에 더 나은 솔루션을 제공해야 합니다.
동적 및 클러스터 관리
첫 번째 도전은 생태계에서 비롯되며, 두 번째 도전은 기술에서 비롯됩니다.
동적
컨테이너와 Kubernetes의 인기는 동적 기능을 모든 기본 클라우드 네이티브 구성 요소의 표준 기능으로 만들었습니다. Kubernetes 환경에서 컨테이너는 지속적으로 생성되고 파괴되며, 탄력적인 확장은 선택이 아니라 필수가 되었습니다.
다음 시나리오를 상상해 보세요: 전자상거래 회사가 프로모션을 진행하고, 수백만 명의 사용자가 한 시간 내에 몰려들었다가 프로모션이 끝나면 떠납니다. 이 시나리오에서 전통적인 아키텍처를 가진 회사는 피크 시간에 API 트래픽을 처리하기 위해 물리적 서버를 구매해야 합니다. 반면, 클라우드 네이티브 아키텍처를 가진 회사는 언제든지 공용 클라우드의 탄력적인 자원을 사용할 수 있습니다. 네트워크, 컴퓨팅 파워, 데이터베이스 및 기타 자원의 규모를 API 요청 수에 따라 자동으로 조정할 수 있습니다.
컨테이너의 탄력적인 확장과 관련된 기술적 도전도 있습니다:
- 업스트림 서비스의 IP 주소와 포트가 자주 변경됩니다.
- IP 허용 목록 및 차단 목록이 자주 업데이트됩니다.
- 서비스 건강 상태의 예외 감지 및 처리.
- API의 정기적인 배포.
- 서비스 등록 및 발견의 적시성.
- SSL 인증서의 핫 갱신 및 자동 회전.
이러한 기술적 도전을 해결하는 핵심은 동적 기능입니다.
NGINX로 대표되는 첫 번째 세대 API 게이트웨이는 동적 기능이 약합니다. NGINX는 로컬 정적 구성 파일에 의해 구동되기 때문에, 구성 변경이 있을 때마다 NGINX 서비스를 재시작해야 하며, 이는 클라우드 네이티브 시대의 기업들에게 받아들일 수 없는 일입니다. 이것이 첫 번째 세대 API 게이트웨이의 첫 번째 기술적 고통 포인트입니다.
클러스터 관리
두 번째 기술적 고통 포인트는 클러스터 관리입니다.
중국의 SaaS 오피스 소프트웨어 회사인 WPS는 Microsoft Office 365와 같은 소프트웨어를 제공합니다. 그들은 Apache APISIX를 실행하는 수백 대의 물리적 머신을 보유하고 있으며, 거의 10,000개의 코어 CPU가 클라이언트의 API 요청을 처리하고, 매일 수백억 개의 API를 처리합니다.
이러한 초대규모의 API 게이트웨이 환경에서, 개발자들은 각 API 게이트웨이의 구성을 하나씩 수정하고 재시작하는 것이 불가능합니다. 대신, 전체 클러스터를 운영할 수 있는 통합 콘솔을 원합니다. 불행히도, 첫 번째 세대 API 게이트웨이가 탄생했을 때는 이렇게 큰 인스턴스 규모가 없었기 때문에, 첫 번째 세대 게이트웨이 개발자들은 클러스터 관리의 필요성을 고려하지 않았습니다.
차세대 API 게이트웨이
위의 도전과 고통 포인트들은 점차 새로운 세대의 API 게이트웨이를 탄생시켰습니다.
차세대 API 게이트웨이의 특징
첫 번째 세대 API 게이트웨이와 달리, 오픈소스 커뮤니티는 클라우드 네이티브 시대의 차세대 API 게이트웨이 개발의 주역입니다. 커뮤니티와 수많은 오픈소스 기여자들의 힘을 통해, 이러한 API 게이트웨이들은 긍정적인 반복과 진화 주기를 형성할 기회를 얻었습니다:
- 개발자와 사용자의 요구와 고통 포인트를 훨씬 더 빠르게 수집할 수 있습니다.
- 이러한 문제를 오픈소스 프로젝트에서 해결하려고 시도합니다.
- 오픈소스 프로젝트가 사용하기 쉬워져 더 많은 개발자들을 끌어들입니다.
이 과정에서, 차세대 API 게이트웨이는 전통적인 게이트웨이의 로드 밸런싱 및 리버스 프록시의 역할을 넘어, 트래픽 연결, 스케줄링, 필터링, 분석, 프로토콜 변환, 거버넌스 및 통합과 같은 더 많은 책임을 맡게 되었습니다(아래 참조).
API 게이트웨이는 저비용의 2차 개발을 지원
동시에, 개발자들이 더 낮은 비용으로 커스텀 개발을 수행할 수 있도록 하는 것도 차세대 API 게이트웨이의 하이라이트가 되었습니다. 통합은 API 게이트웨이의 필수 기능 중 하나입니다. 다운스트림에서는 GraphQL, gRPC, Dubbo 등 프로토콜 해석 및 프로토콜 변환을 포함하며, 업스트림에서는 Okta, Keycloak, Datadog, Prometheus와 같은 인증 및 관측 가능성 서비스와 회사 내부의 인증, 로깅, 감사 등의 서비스를 통합합니다.
API 게이트웨이는 통합 프로세스의 모든 구성 요소를 커버할 수 없습니다. 따라서 개발자들은 플러그인을 통해 자신의 비즈니스 요구를 충족시키기 위해 커스텀 개발을 수행하는 것이 불가피합니다.
다른 API 게이트웨이들은 커스텀 개발을 위해 다양한 프로그래밍 언어와 개발 방법을 제공합니다. 예를 들어, Apache APISIX와 Kong은 모두 Lua를 사용하여 네이티브 플러그인을 작성할 수 있으며, Envoy는 C++을 사용하여 네이티브 플러그인을 작성합니다. 동시에, Apache APISIX는 Go, Python, Node.js, Java 및 Wasm을 사용하여 플러그인을 개발할 수도 있습니다. 거의 모든 개발자들은 이러한 주류 프로그래밍 언어 중 하나를 사용합니다.
오픈소스와 쉬운 커스텀 개발은 차세대 API 게이트웨이의 가장 중요한 특징입니다. 이는 개발자들에게 더 많은 선택을 제공하며, 동시에 개발자들은 멀티 클라우드 또는 하이브리드 클라우드 환경에서 API 게이트웨이를 자신 있게 사용할 수 있으며, 클라우드 서비스 제공업체에 의해 잠길 염려를 하지 않아도 됩니다.
예시: 블랙 프라이데이 트래픽을 위한 API 게이트웨이
다음으로, 구체적인 예시를 통해 API 게이트웨이가 무엇을 하는지 설명하겠습니다.
블랙 프라이데이에, 전자상거래 회사들은 많은 프로모션을 진행하며, 이 기간 동안의 API 요청량은 평소보다 수십 배 높습니다. 먼저, API 게이트웨이가 없을 때의 기술 아키텍처를 살펴보겠습니다:
위 이미지에서 볼 수 있듯이, 인증 및 로깅 기능이 Order 및 Payment 서비스에서 중복되어 있습니다. 전자상거래 서비스는 일반적으로 수천 개의 다른 서비스로 구성됩니다. 이때, 많은 코드와 절차가 반복됩니다.
다음은 API 게이트웨이를 추가한 후의 아키텍처 다이어그램입니다:
위에서 볼 수 있듯이, 우리는 API 게이트웨이 계층에서 공통 서비스를 통합했습니다. 결과적으로, 백엔드 서비스는 자신의 비즈니스에만 집중할 수 있으며, 탄력적인 확장에 대한 더 많은 가능성을 제공합니다.
프로모션이 시작되면, 클라이언트로부터 수백만 개의 API 요청이 API 게이트웨이로 쏟아지고, 백엔드 서비스는 빠른 탄력적인 확장을 수행해야 합니다. 갑작스러운 트래픽으로 인해 핵심 비즈니스가 영향을 받지 않도록 하기 위해, API 게이트웨이에서 악성 크롤러를 식별하고, 스로틀링, 서비스 다운그레이드 및 회로 차단을 구현해야 합니다.
또한, 제품 평가, 배송 조회 등 일부 서비스를 일시적으로 중단할 수 있습니다. 그러나 재고 정보, 구매 및 결제와 같은 핵심 비즈니스는 실패해서는 안 됩니다. 따라서, K8s를 통해 컨테이너 서비스를 관리하고, 더 많은 서비스 복사본을 생성하여 정상적인 운영을 유지해야 합니다. 이때, API 게이트웨이는 클라이언트의 API 요청을 새로 복사된 복제 서비스로 라우팅하고, 오류가 발생한 서비스를 자동으로 제거해야 합니다. 다음 그림과 같습니다:
요약
요약하자면, API 게이트웨이는 새로운 미들웨어가 아닙니다. 그러나 기술 아키텍처가 진화하고 제품 반복 속도가 점점 빨라짐에 따라 점점 더 중요해지고 있습니다. 차세대 클라우드 네이티브 API 게이트웨이의 등장은 클러스터 관리, 동적 기능, 생태계, 관측 가능성 및 보안 측면에서 기업 사용자들의 고통 포인트를 해결합니다.
API 게이트웨이는 API 트래픽뿐만 아니라 Kubernetes Ingress 및 서비스 메시의 트래픽도 처리할 수 있으며, 개발자의 학습 곡선을 더욱 단축하고 기업이 트래픽을 통합적으로 관리할 수 있도록 도와줍니다.
문의하기를 통해 Apache APISIX, API7 Enterprise Edition 및 API7 Cloud 제품에 대해 더 알아보세요.