공유 게스트 Jian Haiqing은 CVTE의 운영 및 유지 관리 책임자입니다.
기술의 급속한 발전으로 인간 상호 작용 지능 분야에서 비즈니스 요구 사항은 아키텍처 반복에 대한 요구 사항도 높아졌습니다. 점점 더 성숙해지고 빠르게 성장하는 비즈니스 상황에 대처하기 위해 seewo는 게이트웨이 수준에서 어떻게 후속 조치를 취합니까?
게이트웨이 과거 반복 및 고충
seewo gateway의 개발은 4번의 반복을 거쳤습니다. 2013년부터 인터넷 사업에 도전하기 시작했는데, 당시 OpenResty + NGINX 정적 구성을 이용하여 초기 게이트웨이를 구축하고 개발자들이 SCP(Secure Copy)를 통해 공개했다. 동시에 더 심각한 문제는 모든 출시가 순조로운 출시를 보장하기 위해 운영 및 유지 관리 인력의 도움이 필요하다는 것입니다.
사업의 발전과 인력의 확대로 2016년에는 2세대 릴리스 시스템 및 관련 반복 게이트웨이를 개발했습니다. 이번에는 OpenResty 기반의 upsync 모듈을 통합하고 서비스 디스커버리를 위해 Consul과 협력한다. 2세대 시스템은 이전 세대 개발자가 독립적으로 릴리스하고 온라인에 접속할 수 없었던 문제를 해결하지만 여전히 용량을 확장하기 위해 운영 및 유지 관리의 도움이 필요합니다.
이후 회사의 비즈니스가 빠르게 발전하기 시작했고 게이트웨이 및 제품의 탄력적 확장성에 대한 요구 사항이 높아지기 시작했습니다. 2018년에는 K8s 기반의 3세대 시스템을 개발했습니다. 일부 애플리케이션이 여전히 어레이 시스템에 남아 있다는 점을 고려하면 전체 게이트웨이 아키텍처는 K8s의 Ingress NGINX를 2계층 게이트웨이로 사용하고 1계층 게이트웨이는 여전히 OpenResty가 포함된 2계층 게이트웨이 아키텍처입니다. 이 경우 이전 세대의 출시 및 확장과 같은 자조 문제는 해결되었지만 새로운 문제가 도입되었습니다.
비즈니스의 급속한 확장으로 인해 전반적인 안정성에 대한 요구 사항이 점점 더 높아지고 있습니다. 이 2계층 게이트웨이 아키텍처를 채택한 후 NGINX는 첫 번째 계층에서 다시 로드되고 두 번째 계층 게이트웨이의 라우팅 변경으로 인해 장기 연결이 끊어집니다. 이것은 일부 장기 연결 사용 시나리오에 더 큰 영향을 미치며, 예를 들어 소프트웨어가 교사의 교육 상태를 획득해야 할 때 연결이 갑자기 끊어지고 상태 획득이 중단되어 교육에 영향을 미칩니다.
2계층 구조 자체는 약간의 비용 증가를 가져옵니다. 동시에 위의 게이트웨이 트래픽 토폴로지 다이어그램에서 위의 레거시 문제 외에도 몇 가지 아키텍처 문제점이 있음을 알 수 있습니다.
2계층 게이트웨이 아키텍처에서 도메인 이름을 추가하든 구성을 수정하든 1계층 게이트웨이에 일부 특수 규칙을 추가하든 관계없이 NGINX를 다시 로드해야 합니다.
동시에 전체 아키텍처의 관점에서 구성 요소의 조정은 흐름 제어 수준에 비해 상대적으로 좋지 않습니다. 특히 현재 우리 회사의 기업 사용자 수는 수천만 명에 이르고 있으며 클라이언트 측에서 불가피한 이상이 발생하면 서버가 침식될 수 있습니다. 이때 게이트웨이 수준에서 특정 흐름 제어 기능이 없으면 백엔드 매우 심각한 눈사태를 일으킬 것입니다.
따라서 위에서 언급한 반복적인 레거시 문제와 아키텍처상의 문제점을 기반으로 2022년 APISIX를 도입하여 위의 문제를 해결했습니다. 동시에 APISIX의 도움으로 게이트웨이 수준에서 트래픽을 제어하는 기능도 강화됩니다.
그러나 APISIX 마이그레이션에는 몇 가지 알려진 문제가 있습니다. 예를 들어:
첫 번째 계층에는 NGINX 도메인 이름이 많고 사용자 지정 규칙이 복잡합니다. 현재 우리 사업에는 700개 이상의 도메인 이름이 있으며 리디렉션, 블랙 및 화이트 목록 등과 같은 많은 사용자 정의 구성이 여전히 있으며 모두 APISIX 플러그인에 적용해야 합니다.
과거의 문제로 인해 1계층 NGINX와 2계층 Ingress 게이트웨이 간의 관계는 여전히 일대다 관계이며, 후속 트래픽 전환이 매우 복잡할지 여부도 해결해야 할 문제입니다.
내부 2계층 DNS 아키텍처. 현재 DNS 확인은 주로 공용 네트워크와 서버의 내부 확인을 처리하는 데 사용되므로 후속 솔루션에서는 롤백을 용이하게 하고 인트라넷 호출의 성능을 최적화할 수 있기를 바랍니다.
APISIX 마이그레이션 후 아키텍처 조정
위에서 언급한 알려진 문제에 직면하여 마이그레이션 프로세스 중에 주로 다음 세 가지 각도에서 작업이 수행되었습니다. 전체 마이그레이션 프로세스에는 연구 개발 콘텐츠가 포함되지 않으므로 운영 및 유지 관리 담당자가 모두 구현합니다.
마이그레이션 과정에서 가장 먼저 해야 할 일은 APISIX 경로 생성입니다. 원래 아키텍처를 기반으로 재작성, 헤더 설정 등과 같은 특수 기능 계층을 제거했습니다. 1단계 게이트웨이의 포워딩을 약화시키고 2단계 Ingress에 모든 기능을 집중시킨 후 Ingress를 기반으로 APISIX 경로를 생성합니다. 동시에 APISIX 플러그인은 NGINX 구성을 기반으로 조정됩니다.
경로가 생성된 후에는 전체 포워딩 프로세스가 올바른지 확인해야 합니다. goreplay 녹화 및 재생을 기반으로 라우팅 및 포워딩의 정확성을 검증함과 동시에 자동 스크립트를 통해 플러그인 기능의 정상 여부를 검증합니다. 기능 검증을 통과한 경우 APISIX가 성능 측면에서 내부 요구 사항을 충족하는지 계속 검증할 것입니다. 따라서 성능 스트레스 테스트 중에 Elastic-apm 플러그인을 개발하고 QPS에 영향을 미치는 일부 플러그인의 성능을 최적화했습니다.
기능 및 성능과 관련된 문제를 처리한 후 가장 큰 과제는 트래픽 전환입니다. 트래픽 전환은 생산 품질에 직접적인 영향을 미치기 때문입니다.
트래픽 기록 및 재생에 goreplay를 사용했지만 여전히 보다 안정적인 롤백 솔루션이 필요합니다. 트래픽 전환으로 인해 포워딩 예외나 APISIX 크래시 등의 이상 현상이 발생한다고 가정하면 빠른 롤백 작업을 수행할 수 있습니다. 이를 바탕으로 공용망 트래픽을 WAF에서 다시 SLB로 다시 전환하는 역할을 하기 때문에 공용망 트래픽을 먼저 전환했는데, 이때 APISIX로 전환하면 back-to-source 주소를 쉽게 수정할 수 있습니다. 전체 트래픽을 전송하려면 위의 "Switch" 그림과 같이 롤백합니다. 이러한 비정상적인 상황에서의 트래픽 전환 과정은 기본적으로 2단계이며, 모든 트래픽은 10초 이내에 다시 전환될 수 있습니다.
공용망 트래픽 전환 완료 후 며칠 간의 원활한 운영 끝에 APISIX를 통해 내부망 트래픽 전환을 완료한 후 전체 프로덕션 전환이 완료되었습니다. 그러나이 온라인 프로세스 중에 실제로 몇 가지 문제가 발생했습니다.
마이그레이션 중 문제 및 해결 방법
Prometheus 플러그인 전달 지연
이것은 인트라넷 테스트 환경에서 발견된 문제입니다. 우리 인트라넷은 올인원 테스트 환경이기 때문에 모든 부서가 동일한 APISIX 항목을 사용하므로 라우팅 규칙이 4000개 이상에 이릅니다. 이로 인해 Prometheus 플러그인을 가져올 때마다 메트릭 크기가 80M+에 도달하여 단일 작업자 프로세스가 가득 차 실행되어 작업자 전달 지연이 발생합니다.
이 문제는 주로 비즈니스 트래픽과 내부 API 트래픽(예: Prometheus 메트릭 및 Admin API)이 작업자를 공유하기 때문에 현재 APISIX 오픈 소스 버전에 존재하는 현상입니다. 우리는 이전에 Prometheus 플러그인을 수정했고 지연 관련 메트릭이 90% 이상을 차지했기 때문에(위 그림 참조) 이 부분을 컬렉션에서 제거했습니다. 이 부분을 제거한 후에도 비즈니스 수준은 여전히 모니터링 사용 요구 사항을 충족하며 아무런 영향을 미치지 않습니다.
그러나 최근에는 이 문제에 대한 새로운 솔루션이 있으며 아직 데모 단계에 있습니다. 이 새로운 솔루션은 특정 포트(예: Prometheus, Admin API, Control API 등)에 대한 요청을 특별히 모니터링하기 위해 하나 이상의 작업자 프로세스(격리 프로세스)를 시작하여 NGINX의 소스 코드를 수정하는 것입니다. 일반 비즈니스 포트를 처리합니다. 다른 작업자 프로세스는 위 포트의 모니터링을 취소하고 정상적인 비즈니스 포트 요청만 처리하여 APISIX 내부 요청과 일반 비즈니스 요청이 서로 영향을 미치지 않도록 합니다.
기본 경로 일치 예외
APISIX를 런칭한 후 도메인 이름이 완전 일치 모드가 아니라 NGINX에서 도메인 이름의 가장 긴 일치와 일치하지 않는 와일드카드 일치를 사용하는 것을 발견했습니다. 따라서 라우팅 전략을 변경하고 URL 방식을 호스트+URL 방식으로 변경하여 문제를 해결했습니다.
단, APISIX의 URL 기반 라우팅 전략을 기본 경로로 고려하여 유지 여부를 결정하기 전에 자체 프로덕션 환경에서 압력 테스트를 수행할 수 있습니다.
프로덕션 시나리오에 URL이 많고 도메인 이름이 적은 경우 APISIX의 기본 라우팅 전략은 완전히 괜찮습니다. 그러나 비즈니스 시나리오에는 URL이 많지 않으므로 host+URL 방법이 성능 요구 사항에 더 적합합니다.
기본 자동 코어 바인딩 문제
클라우드 네이티브의 맥락에서 대부분의 사용자는 APISIX를 컨테이너에 배포하도록 선택합니다. 그러나 APISIX는 기본 구성에서 코어를 자동으로 바인딩하므로 컨테이너화된 시나리오에서 처음 몇 개의 코어만 사용되어 처음 몇 개의 코어는 완전히 실행되고 나머지 몇 개의 코어는 유휴 상태로 유지됩니다. CPU 사용량이 높지 않더라도 APISIX 포워딩이 지연됩니다.
그러나 최근 APISIX 커뮤니티에서 이 구성을 조정하기 시작하여 worker_cpu_affinity 구성의 기본값을 true에서 false로 변경했습니다. 따라서 이 문제는 현재 APISIX 버전에서 해결되었습니다.
버전 업그레이드 호환성 문제
APISIX를 시작하는 과정에서 이전 시스템 또는 OpenSSL 라이브러리에서 해당 ssl_ciphers가 서버의 기본값과 교차하지 않아 SSL 핸드셰이크 실패가 발생하는 것을 발견했습니다.
이 문제에 대응하기 위해 먼저 일부 SSL 도구를 사용하여 APISIX를 시작하기 전에 현재 기존 게이트웨이와 APISIX 게이트웨이 간의 SSL 핸드셰이크 교차가 올바른지 또는 사용 시나리오를 충족하는지 감지한 다음 대규모 마이그레이션 조정을 수행하는 것이 좋습니다. .
또한, APISIX 2.15 LTS 버전 출시 후 인트라넷을 업그레이드 하였는데, 업그레이드 이후 라우트 매칭과 관련된 몇 가지 문제점을 발견하였습니다.
이전 버전에서 새 버전으로 업그레이드할 때 일부 호환성 문제가 있기 때문에 리디렉션 플러그인의 http_to_https 매개 변수가 true인 경우 매개 변수 http_to_https 및 append_query_string의 확인이 실패하고 경로 로드가 실패하여 결과적으로 경로. 이 경우 경로가 일치하면 404 또는 다른 업스트림으로의 전달이 발생합니다.
현재 이 문제는 APISIX의 마스터 브랜치에서 해결되었으나 2.15 버전에서는 별도로 해결되지 않았으므로 이 버전을 사용할 때 이 부분에 주의가 필요합니다.
APISIX 적용의 이점 및 전망
앞서 APISIX 런칭 과정에서 겪었던 몇 가지 문제점을 언급했지만, APISIX 적용 후 회사의 비즈니스 수준에 많은 가치를 가져왔습니다. 예를 들어:
운영 및 유지 보수 효율성이 향상됩니다. APISIX를 사용하고 나면 더 이상 재로드와 관련된 문제가 없으며 라우팅 및 인증서를 언제든지 업데이트할 수 있어 개발자에게 편리함을 제공합니다.
향상된 흐름 제어 기능. APISIX 사용 후 서킷 브레이킹과 전류 제한을 모두 개선하여 트래픽 제어 수준의 기능을 강화하고 전체 핵심 비즈니스 프로세스를 더욱 안정화했습니다.
게이트웨이 기능을 향상시키는 자체 개발 플러그인. APISIX의 강력한 확장성과 자체 플러그인의 뛰어난 성능 덕분에 일부 플러그인 개발에도 더욱 적극적으로 임할 예정입니다. 예를 들어, APISIX에 통합 인증 기능을 통합하여 새로운 비즈니스가 인증 시스템에 별도로 연결할 필요가 없어 제품 반복 프로세스를 가속화합니다.
비용을 줄이고 효율성을 높이기 위해 NGINX의 중복 레이어가 제거되었습니다. 이전의 2계층 게이트웨이 아키텍처에서 NGINX의 첫 번째 계층은 개발자에게 투명하지 않았습니다. 이제 2계층 게이트웨이를 하나의 계층으로 병합한 후 개발자는 아키텍처의 라우팅 또는 플러그인에 대한 일부 구성을 명확하게 볼 수 있으므로 문제 해결이 더 편리하고 빠릅니다.
향후 APISIX 사용 계획에서는 게이트웨이 수준에서 지속적으로 개선해 나갈 예정입니다. 예를 들어 내부 비즈니스를 위한 자체 개발 플러그인을 개발하거나 멀티 테넌트 기능을 제공하거나 API 관리 기능을 게이트웨이 수준으로 가져오는 등의 작업을 수행할 수 있습니다.
물론 이 과정에서 우리는 적극적으로 지역 사회에 환원하고 있습니다. 현재 생태 플러그인과 관련된 일부 문제를 개선하고 수정하는 데 도움이 되는 8개의 PR이 커뮤니티에 기여되었습니다. 예를 들어 사용자 지정 uri를 지원하도록 batch_request를 개선하고 hmac-auth 플러그인에 대한 요청 본문 확인과 같은 기능을 제공합니다.
후속 실습 과정에서 APISIX의 특성을 보다 완벽하게 활용하고 발휘할 수 있기를 바라며, APISIX의 사용 시나리오를 보다 적극적으로 탐색할 수 있기를 바랍니다. 앞으로 더 많은 공동 건설 기능이 출시되기를 기대합니다.
CVTE 소개
설립 이후 CVTE는 교육용 디지털 도구 및 서비스 제공업체인 seewo, 스마트 협업 플랫폼 MAXHUB 및 기타 업계 유명 브랜드를 설립했습니다. 그중 seewo는 2012년부터 2021년까지 10년 연속 중국 대화형 스마트 태블릿 산업의 시장 점유율 왕관을 차지했으며 진정한 업계 벤치마크 기업이 되었습니다.
아파치 APISIX 정보
Apache APISIX는 로드 밸런싱, 동적 업스트림, 그레이스케일 릴리스, 서비스 퓨즈, ID 인증 및 관측 가능성과 같은 풍부한 트래픽 관리 기능을 제공하는 동적, 실시간, 고성능 오픈 소스 API 게이트웨이입니다.
API 게이트웨이로서 Apache APISIX는 기업이 API 및 마이크로서비스 트래픽을 빠르고 안전하게 처리할 수 있도록 지원하며 게이트웨이, Kubernetes 인그레스 및 서비스 그리드와 같은 시나리오에 적용할 수 있습니다. 현재 PwC Data Security Team, Tencent Blue Army, Ping An Galaxy Lab, iQiyi SRC 및 Origin Castle Technology Security Team과 같은 전문 네트워크 보안 조직에서 테스트를 거쳐 높은 평가를 받았습니다.
Apache APISIX 랜딩 사용자(일부만)
아파치 APISIX GitHub：https://github.com/apache/apisix
아파치 APISIX 공식 홈페이지: https://apisix.apache.org/
Apache APISIX 문서: https://apisix.apache.org/zh/docs/apisix/getting-started