Apache APISIX의 고급 안정성 및 내결함성 메커니즘

API 게이트웨이를 선택할 때, 기능성, 확장성, 보안과 함께 안정성과 내결함성은 중요한 요소입니다. 2019년 Apache APISIX를 설계할 때, 내부 및 외부 트래픽 요청을 처리할 때 발생할 수 있는 중대한 프로덕션 사고를 고려하여 안정성과 내결함성이 필수적인 요소로 간주되었습니다.

연구자들을 위해 Apache APISIX의 주요 안정성 및 내결함성 기능을 자세히 살펴보겠습니다.

컨트롤 플레인과 데이터 플레인의 분리

Apache APISIX는 컨트롤 플레인(즉, etcd, Admin API)과 상태 비저장 데이터 플레인(즉, API 게이트웨이는 필요에 따라 확장 가능)으로 분리된 아키텍처를 채택합니다. 이 둘 사이에는 의존성이 없습니다. 이는 컨트롤 플레인이 이상 현상(예: 네트워크 중단 또는 비정상 종료)을 겪더라도 데이터 플레인이 정상적으로 작동하여 새로운 트래픽 요청을 처리할 수 있음을 의미합니다. 이러한 분리는 APISIX의 고가용성을 보장합니다.

데이터 동기화 메커니즘

데이터 플레인과 컨트롤 플레인 사이에는 효율적인 데이터 동기화 메커니즘이 존재합니다. 데이터 플레인은 etcd Watcher 역할을 하며, etcd로부터 데이터 변경 사항을 적극적으로 알림 받습니다. 이를 통해 데이터 플레인은 구성 및 규칙을 업데이트합니다. 따라서 관리자가 Admin API를 통해 etcd에 구성을 작성하면 데이터 플레인은 빠르게 변경 알림을 받고 구성을 메모리에 저장합니다. 이 메커니즘은 들어오는 모든 요청에 대해 etcd에서 구성을 가져올 필요를 없애 시스템 부하를 줄입니다. 그러나 컨트롤 플레인에 이상이 발생할 때 데이터 플레인 인스턴스를 재시작하지 않도록 주의해야 하며, 이는 메모리 내 구성을 잃지 않기 위함입니다.

컨트롤 플레인 이상 현상

네트워크 통신 중단

API 게이트웨이와 etcd 사이에 네트워크 중단이 발생하면 Admin API를 통해 etcd에 작성된 구성이 게이트웨이에 전달되지 않습니다. 그러나 게이트웨이는 이전에 저장된 메모리 내 구성을 사용하여 새로운 트래픽 요청을 계속 처리하며, etcd와의 연결 손실로 인한 비정상 종료를 방지합니다. 게이트웨이와 etcd 사이의 연결이 복구되면 게이트웨이는 최신 구성을 받아 정상적으로 작동을 재개합니다.

etcd 비정상 종료

etcd가 비정상적으로 종료되면 관리자는 Admin API를 통해 구성을 작성할 수 없습니다. 그러나 이는 게이트웨이의 작동에 영향을 미치지 않으며, 게이트웨이는 계속 작동하여 트래픽 요청을 처리합니다. 이 시나리오에서 게이트웨이의 동작은 네트워크 중단 후의 상황과 유사합니다.

다중 노드 배포 및 로드 밸런싱

고가용성을 보장하기 위해 여러 게이트웨이 인스턴스를 배포하고 그 사이에 로드 밸런서(예: AWS Load Balancer 또는 F5)를 설정하는 것이 좋습니다. 이러한 로드 밸런서는 게이트웨이 인스턴스의 상태를 평가하는 헬스 체크 메커니즘을 가지고 있습니다. 게이트웨이 인스턴스가 실패하면 로드 밸런서는 이를 서비스에서 즉시 제거하고 새로운 게이트웨이 노드를 추가할 수 있습니다. 이 다중 노드 배포 및 로드 밸런싱 전략은 단일 노드의 실패로 인한 비즈니스 중단을 방지하는 데 도움이 됩니다.

결론

요약하면, Apache APISIX는 컨트롤 플레인과 데이터 플레인이 분리된 상태에서도 뛰어난 안정성과 내결함성을 보여줍니다. 분리된 아키텍처, 효율적인 데이터 동기화 메커니즘, 다중 노드 배포 전략은 예외적인 상황에서도 고가용성을 보장합니다. Apache APISIX의 설계는 다양한 네트워크 및 구성 요소 이상을 고려하여 기업 수준의 트래픽 요청을 처리하는 데 탁월한 성능을 발휘합니다.