API7 Gateway가 고가용성 전략으로 예외를 극복하는 방법
April 8, 2024
고가용성은 API 게이트웨이 배포의 중요한 설계 목표입니다. 게이트웨이는 애플리케이션과 서비스 사이의 요청 라우팅을 처리하지만, 엔드투엔드 가용성에는 게이트웨이 토폴로지, 네트워크, 업스트림 서비스 및 운영도 함께 고려해야 합니다.
이 글에서는 Apache APISIX를 기반으로 하는 엔터프라이즈 API 관리 플랫폼 API7 Enterprise와 컨트롤 플레인 또는 네트워크 예외의 영향을 줄이기 위한 데이터 플레인 메커니즘을 설명합니다. 실제 가용성은 고객이 관리하는 배포와 인프라에 따라 달라집니다.
엔터프라이즈급 고가용성 아키텍처
API7 엔터프라이즈 고가용성 솔루션에서 설명했듯이 무상태 컴포넌트는 장애 복구와 리소스 스케줄링을 지원할 수 있습니다. 이러한 설계 특성은 복원력을 높일 수 있지만, 운영 환경에서 달성되는 가용성은 고객의 토폴로지, 인프라 종속성 및 운영에 따라 달라집니다.
API7 Enterprise의 고가용성 전략
Apache APISIX를 기반으로 하는 API7 Gateway는 예외 상황에서 사용 가능한 구성을 유지하고 중단 위험을 줄이기 위한 구성 복구 메커니즘을 사용합니다. 이 메커니즘은 다음 세 단계로 동작합니다.
-
시작 시 구성 복구;
-
전체 구성 동기화 및 로컬 저장;
-
동적 구성 변경 및 지속성.
이러한 전략은 DNS, 네트워크, 컨트롤 플레인 등과 같은 중대한 불확실성으로 인해 데이터 플레인이 컨트롤 플레인에 연결할 수 없는 극단적인 상황을 해결하기 위해 설계되었습니다.
시작 시 구성 복구
API7 Gateway 인스턴스가 시작될 때 컨트롤 플레인 연결에 실패하면 게이트웨이는 로컬 저장소에서 최신 구성을 가져오려고 시도합니다. 유효한 로컬 스냅샷은 이전 구성으로 라우팅을 재개하는 데 도움이 될 수 있지만, 복구 성공 여부는 해당 스냅샷과 주변 인프라에 따라 달라집니다.
더 극단적인 경우에는 인스턴스의 로컬 구성 파일을 변경할 수 있으며, 이는 API7 Gateway의 시작 구성으로 사용될 수 있습니다.
전체 구성 동기화 및 로컬 저장
API7 Gateway는 구성 센터에 연결한 후 구성 정보를 동기화하고 로컬 파일 시스템에 JSON으로 저장합니다. 이후 연결이 중단되면 실행 중인 게이트웨이는 메모리 또는 로컬 구성을 사용할 수 있으며, 실제 동작은 구성의 유효성과 다른 배포 종속성에 따라 달라집니다.
동적 구성 변경 및 지속성
컨트롤 플레인이 구성 업데이트를 푸시하면 API7 Gateway는 변경 사항을 적용하고 로컬 구성 파일도 업데이트합니다. 이 지속성은 재시작 후 복구 시간을 줄일 수 있지만 모든 서비스 중단 가능성을 없애지는 않습니다.
극단적인 상황 처리 설계
API7 Gateway에는 네트워크 격리, 컨트롤 플레인 장애, 로컬 리소스 제약과 같은 상황을 위한 구성 지속성과 복구 로직이 포함됩니다. 이러한 메커니즘은 게이트웨이 복원력을 높일 수 있지만, 엔드투엔드 비즈니스 연속성은 중복 데이터 플레인 용량, 로드 밸런싱, 업스트림 서비스 및 고객 운영에도 따라 달라집니다.
결론
구성 복구와 동기화, 로컬 저장 및 지속성은 컨트롤 플레인을 사용할 수 없거나 인스턴스가 재시작될 때 API7 Gateway가 마지막으로 사용 가능한 구성을 활용하는 데 도움이 될 수 있습니다. 결과는 고객 관리형 아키텍처와 운영에 따라 달라지며 API7 Enterprise의 가동 시간을 약속하는 것이 아닙니다.
API7 Enterprise는 고객 관리형 배포를 위한 고가용성 메커니즘을 제공합니다. 이러한 메커니즘은 장애 영향을 줄일 수 있지만, 실제 서비스 가용성은 고객의 배포 아키텍처, 인프라 종속성 및 운영에 따라 달라집니다.
