API Gateway를 활용한 10가지 일반적인 API 복원력 설계 패턴

API 복원력은 다양한 도전에 견딜 수 있는 견고한 API를 구축하여 효과적으로 기능을 유지하는 것을 의미합니다. API 게이트웨이는 외부 요청의 진입점 역할을 하며, 일반적인 API 복원력 패턴을 고려하여 서로 다른 서비스 간의 통신을 관리함으로써 이에 중요한 역할을 합니다. 인기 있는 오픈소스 API 게이트웨이 중 하나인 Apache APISIX는 API의 복원력과 견고성을 강화하기 위한 다양한 기능을 제공합니다. 이 글에서는 10가지 일반적인 API 복원력 설계 패턴과 APISIX를 사용하여 이를 구현하는 방법을 탐구해 보겠습니다.

다음은 10가지 API 복원력 패턴 목록입니다:

1. 속도 제한.
2. 재시도.
3. 타임아웃.
4. 폴백.
5. 캐시.
6. 중복.
7. 상태 확인.
8. 서킷 브레이커.
9. 벌크헤드.
10. 오류 주입.

API 복원력이란?

API 복원력은 API가 오류, 높은 트래픽, 예기치 못한 조건에도 불구하고 일관되게 의도한 기능을 수행할 수 있는 능력을 의미합니다. 이는 실패를 피하는 것이 아니라 실패가 발생할 수 있다는 사실을 받아들이고, 다운타임이나 데이터 손실을 방지하는 방식으로 대응하는 것입니다. 복원력의 목표는 실패 후 애플리케이션을 완전히 기능하는 상태로 되돌리는 것입니다. 복원력 있는 API는 API 자체 내부, 종속 서비스, 또는 네트워크 문제나 지연, API 버전 비호환성, 환경 변화 또는 예기치 못한 사용자 행동으로 인해 발생할 수 있는 문제 등 다양한 실패를 우아하게 처리할 수 있도록 설계되었습니다.

API 게이트웨이에서 API 복원력이 중요한 이유는?

기존의 많은 소프트웨어 개발 프레임워크는 API가 가용성, 응답성, 정확성을 유지할 수 있도록 설계된 일련의 관행과 패턴을 포함하고 있습니다. 그러나 API 복원력을 개별 서비스나 시스템의 다른 부분이 아닌 API 게이트웨이 수준에서 구현하면 여러 전략적 이점을 얻을 수 있습니다.

1. 중앙 집중식 제어: API 게이트웨이는 모든 API 요청의 중앙 진입점 역할을 하므로, 모든 서비스에 걸쳐 복원력 패턴을 통합적으로 관리하고 적용할 수 있는 독특한 기회를 제공합니다. 이러한 중앙 집중화는 복원력 기능의 구현과 유지 관리를 단순화합니다.

2. 일관성: API 게이트웨이에서 복원력을 처리하면 모든 서비스에 걸쳐 실패 처리, 속도 제한, 타임아웃 및 기타 복원력 전략에 대한 일관된 접근 방식을 보장할 수 있습니다. 이러한 일관성은 신뢰할 수 있고 예측 가능한 시스템 동작을 유지하는 데 중요합니다.

3. 복잡성 감소: 각 마이크로서비스에서 복원력 기능을 구현하면 중복된 노력과 복잡성이 증가할 수 있습니다. API 게이트웨이는 이러한 문제를 추상화하여 서비스 개발자가 복원력 처리보다 비즈니스 로직에 집중할 수 있도록 합니다.

4. 리소스 활용 개선: API 게이트웨이는 리소스를 효율적으로 관리하고 트래픽을 분산시켜 단일 서비스가 과부하되지 않도록 합니다. 이러한 로드 밸런싱은 시스템의 전반적인 복원력에 기여합니다.

5. 모니터링 및 로깅 용이성: 모든 API 트래픽이 단일 지점을 통해 흐르도록 하면 서비스의 상태를 모니터링하고 문제를 로깅하기가 더 쉬워집니다. 이러한 중앙 집중식 뷰는 문제를 신속하게 식별하고 대응하는 데 매우 유용합니다.

6. 보안 단순화: 인증, 권한 부여, 암호화와 같은 보안 조치를 API 게이트웨이에서 일관되게 적용할 수 있어 모든 서비스가 중복 구성 없이 보호됩니다.

7. 성능 향상: API 게이트웨이는 캐싱 및 응답 집계를 구현하여 백엔드 서비스에 대한 호출 횟수를 줄이고 시스템의 전반적인 성능을 개선할 수 있습니다.

8. 우아한 성능 저하: 서비스 실패 시 API 게이트웨이는 트래픽을 재라우팅하거나 폴백 응답을 제공하여 시스템이 우아하게 성능을 저하시키고 기능을 계속 제공할 수 있도록 합니다.

9. 빠른 복구: API 게이트웨이의 중앙 집중식 특성은 수정 및 업데이트를 신속하게 구현할 수 있도록 하여 실패 후 시스템을 빠르게 완전히 복구할 수 있습니다.

10. 클라이언트 상호작용 단순화: 클라이언트는 API 게이트웨이와만 상호작용하면 되며, 이는 일관되고 신뢰할 수 있는 인터페이스를 제공하여 기본 마이크로서비스의 복잡성을 추상화합니다.

개발 관점에서 API 게이트웨이 접근 방식은 일반적으로 사용되는 복원력 패턴을 구현하는 데 걸리는 시간을 줄여줍니다. 이제 일반적인 컨퍼런스 앱의 서비스 간 API 통신 예제를 통해 각 패턴을 살펴보고 이를 활성화하는 방법을 이해해 보겠습니다.

이 글은 주로 이론적인 부분에 초점을 맞추고 관련 문서를 참조합니다. 개발자는 각 링크를 확인하고 제공된 가이드를 통해 이러한 패턴을 구현할 수 있습니다. APISIX를 사용하면 Admin API, 정적 YAML 파일 또는 APISIX Dashboard를 통해 이러한 설계 패턴을 구성할 수 있습니다.

1. 속도 제한

이름에서 알 수 있듯이, 속도 제한은 클라이언트가 주어진 시간 동안 할 수 있는 요청 수를 제어합니다. APISIX는 limit-req 플러그인을 제공하여 속도 제한을 구성할 수 있습니다. 이 플러그인을 사용하면 개별 요청의 속성(특정 사용자, 클라이언트 애플리케이션 또는 위치에서 너무 많은 요청)을 기반으로 요청을 제한하는 규칙을 정의할 수 있어 API가 너무 많은 요청으로 인해 과부하되지 않도록 합니다.

속도 제한 정책은 권한이 없는 사용자의 접근을 제한하는 데에도 사용할 수 있습니다. 플러그인 사용 방법을 확인하여 속도 제한을 적용하는 방법을 알아보세요.

2. 재시도

재시도 패턴은 API 요청이 실패할 경우 자동으로 재시도하는 것을 포함합니다. APISIX를 사용하면 Upstream 객체에 재시도 메커니즘을 구성하여 재시도 횟수와 재시도를 시도해야 하는 조건을 지정할 수 있습니다.

재시도 속성으로 업스트림을 구성하면, APISIX는 이전 요청이 타임아웃되거나 네트워크 문제로 실패한 경우 백엔드 Attendee 서비스에 자동으로 재시도 요청을 보냅니다.

3. 타임아웃

타임아웃을 설정하면 백엔드 서비스가 응답하지 않을 경우 요청이 무한정 대기하지 않도록 합니다. APISIX는 동일한 Upstream 객체 구성에서 API에 대한 타임아웃을 구성할 수 있도록 하여 요청이 응답하는 데 너무 오래 걸리면 요청을 종료합니다.

Attendee 서비스가 느리게 응답하는 경우, APISIX는 빠른 실패 패턴을 적용하여 클라이언트 앱 요청에 빠르게 응답하여 전체 시스템의 응답성을 개선할 수 있습니다.

4. 폴백

폴백 패턴은 서비스를 사용할 수 없을 때 기본 응답을 제공합니다. APISIX를 사용하면 업스트림 우선순위를 정의할 수 있습니다. 기본 엔드포인트가 실패하면 API 게이트웨이는 트래픽을 보조 서비스로 리디렉션하거나 response-rewrite 플러그인을 사용하여 HTTP 500과 같은 서비스 실패 시 미리 정의된 응답을 반환할 수 있습니다.

또는 proxy-cache 플러그인을 사용하여 응답을 캐시하고 백엔드가 다운되었을 때 이를 제공할 수 있습니다. 예를 들어, 모바일 앱은 Attendee 서비스가 다운되었을 때 캐시된 컨퍼런스 참가자 목록을 표시할 수 있습니다.

5. 캐시

응답을 캐시하면 백엔드 서비스의 부하를 크게 줄일 수 있습니다. APISIX는 proxy-cache 플러그인을 제공하여 응답을 캐시하고 API 게이트웨이에서 직접 제공할 수 있도록 하여 지연 시간을 줄이고 성능을 개선합니다.

API 응답 캐시 튜토리얼을 확인하여 proxy-cache 플러그인을 사용하는 방법을 알아보세요.

6. 중복

모든 API 게이트웨이는 로드 밸런싱과 같은 공통 기능을 제공하여 들어오는 API 요청을 여러 백엔드 서비스(노드 또는 인스턴스)에 분산시킵니다. 중복 인스턴스를 갖추면 이러한 불규칙한 이벤트에 대해 시스템이 더 견고해집니다. APISIX는 라운드 로빈, 최소 연결, 일관된 해싱과 같은 다양한 로드 밸런싱 알고리즘을 지원합니다.

Attendee 서비스의 경우 두 개의 인스턴스를 실행할 수 있으며, 서버 A가 다운되면 두 번째 서버에서 요청을 처리할 수 있습니다.

7. 상태 확인

상태 확인은 업스트림 서비스가 응답성을 기반으로 건강한지 아닌지를 결정하는 메커니즘입니다. APISIX는 업스트림 활성 상태 확인을 사용하여 서비스가 사용 가능한지 여부를 식별합니다. 상태 확인이 활성화되면 APISIX는 건강한 것으로 간주되는 업스트림 서비스로만 요청을 전달하고 건강하지 않은 것으로 간주되는 서비스로는 요청을 전달하지 않습니다.

API 상태를 주기적으로 확인하려면 APISIX는 업스트림 서비스의 상태 확인 엔드포인트의 HTTP 경로가 필요합니다. 따라서 먼저 Attendee 서비스에 /health 엔드포인트를 추가해야 합니다.

8. 서킷 브레이커

서킷 브레이커 패턴은 실패할 가능성이 있는 서비스에 대한 호출을 방지하여 시스템이 연쇄적인 실패로부터 보호되도록 합니다. APISIX는 Route 구성에서 api-breaker 플러그인을 사용하거나 업스트림 수동 상태 확인을 활성화하여 서킷 브레이커 기능을 구현하는 두 가지 옵션을 제공합니다. 두 방법 모두 실패를 처리하고 서비스가 실패하거나 느리게 수행되는 경우 업스트림 서비스에 대한 지속적인 재시도 시도를 방지합니다.

APISIX는 최근 발생한 실패 횟수를 모니터링하고 이 정보를 사용하여 작업을 계속 진행할지 또는 즉시 예외를 반환할지 결정합니다.

9. 벌크헤드

벌크헤드 패턴은 애플리케이션 내의 요소를 격리하여 시스템의 한 부분이 실패하거나 과부하가 걸려도 다른 부분이 계속 기능할 수 있도록 합니다. Attendee 서비스에서 읽기 작업에 대한 과도한 트래픽이나 문제가 Attendee 서비스에 대한 쓰기 작업의 가용성과 성능에 영향을 미치지 않도록 하기 위해 APISIX를 사용하여 벌크헤드 패턴을 구현할 수 있습니다.

API 게이트웨이에서 두 개의 업스트림 노드에 대한 별도의 경로 엔드포인트를 생성하여 모든 쓰기 요청은 서비스 A로, 모든 읽기 요청은 서비스 B로 전달되도록 할 수 있습니다.

10. 카오스 테스트

카오스 테스트는 프로덕션 환경에서 API가 복원력을 갖추도록 하는 데 도움을 줄 수 있습니다. 이를 사용하면 애플리케이션 또는 마이크로서비스 API의 복원력을 다양한 유형의 실패에 대해 평가하고 강화하여 신뢰성을 높일 수 있습니다. 이 방법은 지연을 의도적으로 도입하고 지정된 오류 코드로 요청을 강제 종료하여 서비스 중단, 과도한 서비스 요구, 상당한 네트워크 지연 및 네트워크 분할과 같은 다양한 부정적인 시나리오를 시뮬레이션할 수 있도록 합니다.

APISIX Fault Injection Plugin은 Attendee 서비스에서 오류 또는 지연을 시뮬레이션하여 클라이언트 앱이 이에 어떻게 반응하는지 테스트할 수 있는 동일한 메커니즘을 제공합니다.

결론

이 블로그 글에서는 10가지 일반적인 API 복원력 설계 패턴을 개괄하고 APISIX를 사용하여 이를 효과적으로 구현하는 방법을 살펴보았습니다. API 게이트웨이 수준에서 복원력 전략을 중앙 집중화함으로써 조직은 API 트래픽과 오류 처리를 일관되게, 단순화하고 효율적으로 관리할 수 있습니다.

관련 자료

• APISIX와 Prometheus를 사용하여 API 건강 유지
• 신뢰할 수 있는 API 구축을 위한 최적의 관행