신뢰할 수 있는 API 구축을 위한 최적의 방법
August 18, 2022
API가 확장됨에 따라, 이를 신뢰할 수 있고 견고하게 만드는 필요성도 증가합니다.
이 글은 API 게이트웨이라는 특별한 종류의 리버스 프록시를 소개하며 신뢰할 수 있는 API를 구축하기 위한 최상의 실천 방법을 논의합니다.
우리는 다음을 살펴볼 것입니다:
- 전통적인 API 설계의 문제점
- API 게이트웨이가 무엇인지
- API 게이트웨이가 API를 어떻게 개선하는지
- API 게이트웨이를 사용한 패턴과 예시
하지만 먼저, "신뢰할 수 있는" API란 무엇일까요?
API를 신뢰할 수 있게 만드는 요소는 무엇인가?
서비스 제공자로서, 고객과 서비스 수준 계약(SLA)을 맺을 수 있으며, 이는 일반적으로 서비스가 온라인 상태이고 운영 중임을 보장하는 시간인 가동 시간으로 표현됩니다.
가동 시간은 신뢰성에 대한 근시안적인 관점입니다. 신뢰성이 무엇을 의미하는지 이해하려면 가동 시간에 영향을 미치는 요소들을 살펴봐야 합니다. 이러한 요소들을 이해하면 신뢰할 수 있는 서비스를 구축하는 데 더 나은 위치에 있게 될 것입니다.
이러한 요소들과 그들이 제기하는 질문들을 살펴보겠습니다:
- 지연 시간: API가 요청에 얼마나 빠르게 응답하는가?
- 보안: 누가 API에 접근할 수 있는가? 안전한가?
- 다운타임 빈도: API가 얼마나 자주 다운되는가?
- 일관성: API 엔드포인트가 일정한가? 소비자가 코드를 자주 변경해야 하는가?
- 모니터링 및 보고: API의 문제와 실패를 관찰할 수 있는가? 이를 소비자에게 보고하고 있는가?
조직들이 클라우드 네이티브 아키텍처로 이동함에 따라, 개발 팀이 각 서비스에서 이러한 요소들을 고려하는 것이 어려워집니다. 그리고 이러한 시스템이 확장됨에 따라, 이러한 책임을 단일, 분리된 시스템에 위임하는 것이 훨씬 쉬워질 것입니다. API 게이트웨이를 만나보세요!
API 게이트웨이, 통합 진입점
API 게이트웨이는 클라이언트와 API 사이의 중개자 역할을 합니다. 이는 리버스 프록시처럼 모든 트래픽(API 호출)을 수락하고, 요청을 백엔드의 필요한 서비스로 전달하며, 필요한 결과를 반환합니다.
API 게이트웨이는 인증, 보안, 트래픽 제어, 모니터링 문제를 모두 처리하는 중앙 지점이 될 수 있으며, API 개발자가 비즈니스 요구에 집중하고 신뢰성을 개선하는 것을 더 쉽게 만듭니다.
많은 오픈 소스 및 관리형 API 게이트웨이 제공이 있습니다. 이 글에서는 Apache APISIX를 사용할 것입니다.
다음 섹션에서는 API 게이트웨이를 사용하여 API를 신뢰할 수 있게 만드는 몇 가지 최상의 실천 방법을 설명할 것입니다.
API 게이트웨이를 사용한 신뢰성 최상의 실천 방법
실제 구현보다는 그 아래에 있는 패턴에 더 초점을 맞출 것입니다. 이는 API 게이트웨이 선택에 따라 달라질 수 있기 때문입니다.
이 패턴들을 세 가지 범주로 나눌 것입니다:
- 인증 및 보안
- 모니터링 및 관찰 가능성
- 버전 관리 및 제로 다운타임
아래에서 각 범주를 자세히 살펴보겠습니다.
인증 및 보안
사용자 인증
API 게이트웨이를 통한 인증된 요청은 클라이언트-API 상호 작용을 보호합니다. 클라이언트가 인증한 후, API 게이트웨이는 얻은 클라이언트 세부 정보를 세밀한 제어에 사용할 수 있습니다.
APISIX는 key-auth 및 jwt-auth와 같은 플러그인을 통해 직접 인증을 처리합니다. APISIX는 또한 OAuth 인증 및 openid-connect 및 wolf-rbac와 같은 플러그인을 통해 역할 기반 접근 제어 시스템을 지원합니다.
속도 제한
의도적인(DoS 공격) 및 의도하지 않은(클라이언트가 너무 많은 요청을 보내는 경우) 트래픽 급증은 API를 카드 집처럼 무너뜨릴 수 있습니다. 속도 제한을 설정하면 이러한 시나리오를 처리하는 시스템의 신뢰성이 향상됩니다.
API 게이트웨이에 속도 제한을 설정할 수 있으며, 요청 수가 임계값을 초과하면 API 게이트웨이는 초과 요청을 지연시키거나 거부할 수 있습니다.
APISIX를 사용하면 요청 수, 클라이언트당 동시 요청 수, 카운트에 기반한 속도 제한을 구성하기 위해 세 가지 플러그인 중 하나를 사용할 수 있습니다(limit-req, limit-conn, limit-count).
모니터링 및 관찰 가능성
API의 신뢰성과 모니터링 설정은 밀접한 관련이 있습니다. 그리고 API 게이트웨이에 모니터링을 설정하여 신뢰성 지표를 모니터링할 수 있습니다.
API 로그 및 추적은 API 호출에 대한 상세 정보를 제공합니다. 이 정보는 API가 실패하거나 오류가 발생했을 때 가능한 한 빨리 알 수 있게 도와줍니다. 침묵하는 실패는 수정되지 않은 오류로 이어져 미래에 문제를 일으킬 수 있습니다.
일부 설정을 통해 미래의 트래픽을 예측하고 예상할 수 있게 되어 신뢰성 있게 확장할 수 있습니다.
APISIX는 로깅(Apache SkyWalking, RocketMQ), 메트릭(Prometheus, Datadog), 추적(OpenTelemetry, Zipkin) 플랫폼/사양과 통합되는 플러그인을 가지고 있습니다. APISIX 플러그인을 통한 API 관찰 가능성에 대해 더 읽어볼 수 있습니다.
버전 관리 및 제로 다운타임
카나리 릴리스
API의 새 버전으로 전환할 때, 트래픽을 잃지 않도록 해야 합니다. 클라이언트는 여전히 API에 요청을 보내고 올바른 응답을 받을 수 있어야 합니다.
API 게이트웨이를 사용하면 카나리 릴리스를 설정할 수 있습니다. 이는 전환 중에도 API가 기능적으로 유지되도록 하며, 문제가 발생하면 이전 버전으로 롤백할 수도 있습니다.
처음에 API 게이트웨이는 모든 트래픽을 API의 이전 버전으로 라우팅합니다.
새 버전이 있으면 API 게이트웨이를 구성하여 일부 트래픽을 이 새 버전으로 라우팅할 수 있습니다. 새 서비스로의 트래픽 비율을 계속 증가시키고 모든 것이 예상대로 작동하는지 확인할 수 있습니다.
마지막으로, 모든 트래픽을 새 API로 라우팅할 수 있습니다.
APISIX는 서비스로의 트래픽을 제어할 수 있는 traffic-split 플러그인을 사용합니다. 이를 사용하여 카나리 릴리스 또는 사용자 정의 릴리스 구성을 설정할 수 있습니다.
서킷 브레이킹
업스트림 서비스 중 하나가 사용 불가능하거나 높은 지연 시간을 경험할 때, 이를 시스템에서 차단해야 합니다. 그렇지 않으면 클라이언트가 요청을 계속 재시도하여 자원 고갈로 이어질 수 있습니다. 이 실패는 시스템의 다른 서비스로 번져서 이를 무너뜨릴 수 있습니다.
전기 회로 차단기가 고장난 구성 요소를 회로에서 분리하는 것처럼, API 게이트웨이는 고장난 서비스를 분리하여 시스템을 건강하게 유지하는 서킷 브레이커 기능을 가지고 있습니다. 이러한 서비스로의 트래픽은 서비스가 건강해질 때까지 재라우팅되거나 지연됩니다.
APISIX는 이 패턴을 구현하는 api-breaker 플러그인을 제공합니다.
리디렉션
API를 업데이트할 때, 엔드포인트가 변경될 수 있습니다. 전통적으로, 이는 클라이언트 애플리케이션이 /old-api-endpoint 대신 /new-api-endpoint로 요청을 보내야 함을 의미하며, 이는 소비자가 이 API 엔드포인트에 대한 각 호출을 수동으로 변경해야 함을 의미합니다.
예상치 못한 경우, 이는 클라이언트 애플리케이션을 중단시킬 수 있습니다.
API 게이트웨이를 사용하면 클라이언트가 요청을 변경하지 않고도 /new-api-endpoint로 요청을 리디렉션할 수 있는 추상화 계층을 제공할 수 있습니다. 적절한 리디렉션 상태 코드와 메시지를 통해 소비자가 다운타임을 경험하지 않고도 /old-api-endpoint를 점차적으로 폐기할 수 있습니다.
APISIX를 사용하면 redirect 플러그인을 사용하여 리디렉션을 구성할 수 있습니다.
결론
신뢰성이 주요 관심사가 되면, 더 많은 조직이 모놀리스를 마이크로서비스로 분할하고 클라우드 네이티브 아키텍처로 이동함에 따라 API 게이트웨이가 필요하다는 것이 명백해집니다.
그러나 이는 API 게이트웨이가 모든 사람에게 적합하다는 것을 의미하지는 않습니다. API의 크기와 사용량에 따라 API 게이트웨이가 과도할 수 있으며, 기본 라우팅 및 로드 밸런싱 기능을 가진 리버스 프록시를 사용해도 충분할 수 있습니다.
여기서 언급된 사용 사례는 API 게이트웨이의 기능의 표면만 긁은 것입니다. API 게이트웨이와 Apache APISIX에 대해 더 알아보려면 apisix.apache.org를 방문하세요.