API7 솔루션: B2B 서비스를 위한 고가용성

클라이언트와의 소통 과정에서 자주 제기되는 핵심 질문이 있습니다: "고가용성을 제공하나요? 그리고 어떻게 제공하나요?"

API7 Enterprise는 고객 관리형 고가용성 배포를 위한 구성 요소를 제공합니다. 가용성은 고객의 배포 아키텍처, 인프라 종속성 및 운영에 따라 달라지며, 셀프 호스팅 API7 Enterprise에는 제품 수준의 가동 시간 비율이 적용되지 않습니다.

비즈니스 환경에서 API 서비스의 고가용성은 특히 중요합니다. 이는 클라이언트의 연속성과 신뢰성에 직접적인 영향을 미치기 때문입니다. 왜 B2B 비즈니스에서 고가용성이 이렇게 중요한가요? 핵심 지표로서, 중요한 순간에 API 서비스가 중단되거나 실패하면 클라이언트의 비즈니스에 심각한 영향을 미칠 수 있으며, 이는 단순히 금전적 손실뿐만 아니라 클라이언트의 평판과 신뢰도에도 손상을 입힐 수 있습니다.

API7은 고가용성 배포를 어떻게 지원하나요?

고가용성은 기술 및 비즈니스 목표입니다. 다음 섹션에서는 복원력 있는 배포를 지원할 수 있는 API7 Enterprise 구성 요소를 설명하며, 이러한 메커니즘만으로 서비스 가용성이 보장되는 것은 아닙니다.

무상태 제어 평면

API7 Enterprise 컨트롤 플레인은 무상태 애플리케이션 컴포넌트를 사용하므로 인스턴스를 독립적으로 재시작하거나 확장할 수 있습니다. 이 설계는 장애 복구와 리소스 스케줄링을 지원할 수 있지만, 실제 가용성은 데이터베이스, 로드 밸런싱, 인프라 및 고객 운영에 따라 달라집니다.

PostgreSQL을 기본 구성 센터로 사용

API7 Enterprise는 APISIX가 사용하는 etcd 대신 PostgreSQL을 기본 구성 저장소로 사용합니다. PostgreSQL은 일반적인 복제 및 장애 조치 방식을 제공하지만, 적절한 토폴로지를 선택하고 구성, 모니터링 및 테스트하는 것은 고객의 책임입니다. 대기 데이터베이스는 기본 노드 장애 후 복구 시간을 줄일 수 있지만 그 자체로 구성 또는 서비스 가용성을 보장하지는 않습니다.

API7 Enterprise의 고가용성

무상태 데이터 평면

데이터 플레인은 비즈니스 트래픽을 처리하며 APISIX를 기반으로 합니다. 무상태 컴포넌트는 확장하거나 교체할 수 있습니다. 중복 인스턴스, 상태 점검, 충분한 용량 및 로드 밸런싱과 함께 사용하면 인스턴스 장애의 영향을 줄일 수 있지만, 서비스 연속성은 고객이 관리하는 전체 배포에 따라 달라집니다.

독립적인 데이터 평면과 제어 평면

데이터 플레인과 컨트롤 플레인을 분리하면 요청 경로가 컨트롤 플레인 가용성에 의존하는 정도를 줄일 수 있습니다. 실행 중인 데이터 플레인 인스턴스는 구성을 메모리에 보관하고 일부 컨트롤 플레인 장애 중 마지막으로 사용 가능한 구성을 계속 사용할 수 있습니다. 새 구성 변경, 새 인스턴스 및 다른 인프라 장애는 여전히 서비스에 영향을 줄 수 있습니다.

고가용성 아키텍처의 사용 시나리오와 이점

고객은 상태 점검이 있는 로드 밸런서 뒤에 중복 인스턴스를 배포하거나 Kubernetes의 상태 점검 및 교체 동작을 사용할 수 있습니다. 이러한 메커니즘은 일부 장애 컴포넌트를 감지하고 교체할 수 있지만, 효과는 올바른 구성, 예비 용량, 인프라 종속성 및 운영 테스트에 따라 달라집니다.

이러한 메커니즘을 적절하게 설계, 운영 및 테스트하면 일부 장애의 영향을 줄이고 복구를 앞당기며 일부 트래픽 처리를 계속하는 데 도움이 될 수 있습니다. 모든 비즈니스 중단을 방지하거나 유지보수 비용 절감을 보장하지는 않습니다. 결과는 복구 목표, 중복성, 외부 종속성, 모니터링 및 고객 운영 절차에 따라 달라집니다.