저렴한 비용, 높은 안정성 | 만방그룹의 Eureka 및 ZooKeeper 클라우드 마이그레이션 사례

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

저자: 환샹

만방그룹은 '인터넷+물류' 플랫폼 기업으로 화주의 배송 수요를 한쪽에서는 처리하고, 다른 쪽에서는 트럭 운전사와 연결해 화물 물류 효율성을 향상시킨다. 2021년 미국 주식시장에 상장해 상장되는 최초의 디지털 화물 플랫폼이 될 예정이다. 회사의 연례 보고서에 따르면 2021년에는 350만 명 이상의 트럭 운전사가 플랫폼에서 1억 2,830만 건 이상의 주문을 완료하여 총 거래 가치 2,623억 위안을 달성했으며 이는 중국 디지털 화물 플랫폼 점유율의 60% 이상을 차지합니다. 2022년 10월 윤만만의 드라이버 버전 MAU는 949만2100명, 왜건맨만의 드라이버 버전 MAU는 399만9100명, 윤만만 오너 버전 MAU는 218만6800명, 왜건방 카고 오너 버전 MAU는 399만9100명이다. 637,800이었습니다. (아래 내용은 Zikui와 Congyan이 편집하여 출력한 것입니다)

비즈니스 성장으로 인해 서비스 안정성이 저하됨

만방그룹은 North-South 트래픽 스케줄링, 보안 보호, 마이크로서비스 거버넌스를 담당하는 자체 마이크로서비스 게이트웨이를 비즈니스 생산 환경에 구축함과 동시에 다중 활성 재해 복구 기능을 고려하여 다음과 같은 서비스도 제공합니다. 동일한 컴퓨터실 내 우선 통화, 재해 복구 컴퓨터실 간 통화 등의 메커니즘으로 사용됩니다. 마이크로서비스 아키텍처의 프런트 엔드 구성 요소인 마이크로서비스 게이트웨이는 모든 마이크로서비스에 대한 트래픽 입구 역할을 합니다. 클라이언트 요청이 들어오면 먼저 ALB(로드 밸런싱)에 도달한 다음 내부 게이트웨이로 이동한 다음 게이트웨이를 통해 특정 비즈니스 서비스 모듈로 라우팅됩니다.

따라서 게이트웨이는 서비스 등록 센터를 사용하여 현재 프로덕션 환경에 배포된 모든 마이크로서비스 인스턴스를 동적으로 검색해야 합니다. 일부 서비스 인스턴스가 오류로 인해 서비스를 제공할 수 없는 경우 게이트웨이는 서비스 등록 센터와 협력하여 자동으로 전달할 수도 있습니다. 서비스 인스턴스에 대한 요청은 장애 조치 및 탄력성을 달성하고 자체 개발된 프레임워크를 사용하여 서비스 등록 센터와 협력하여 서비스 간 호출을 구현합니다. 만방그룹은 클러스터 구현을 위해 최초로 오픈소스 유레카와 주키퍼(ZooKeeper)를 도입했으며, 이 구조는 만방그룹의 빠른 비즈니스 성장도 초기 단계에서 잘 수행했다.

그러나 비즈니스 규모가 점차 증가함에 따라 비즈니스 모듈이 점점 더 많아지고 서비스 등록 인스턴스 수가 폭발적으로 증가합니다 . 이 아키텍처에서 자체 구축한 유레카 서비스 등록 센터 클러스터와 ZooKeeper 클러스터의 안정성 문제는 점점 더 명백해졌습니다 . .

운영 및 유지보수 과정에서 만방그룹 학생들은 자체 구축한 유레카 클러스터의 서비스 등록 인스턴스 수가 2000개 이상에 도달했을 때 유레카 클러스터 노드 간 인스턴스 등록 정보 동기화로 인해 일부 노드에서 이를 처리할 수 없는 현상을 발견했습니다. 노드가 서비스를 제공하지 못하고 결국 오류가 발생하는 경우 문제가 발생합니다. ZooKeeper 클러스터에서 잦은 GC로 인해 서비스 간 호출 및 구성 릴리스에 지터가 발생하고 ZooKeeper에는 인증 및 ID 인증이 없기 때문에 문제가 발생합니다. 기본적으로 활성화된 기능은 보안 위험에 직면해 있으며, 이러한 문제는 비즈니스의 안정적이고 지속적인 발전에 큰 어려움을 가져옵니다.

비즈니스 아키텍처의 원활한 마이그레이션

위의 비즈니스 배경에서 만방 학생들은 원래의 Eureka 및 Zookeeper 클러스터를 대체하기 위해 Alibaba Cloud MSE Nacos 및 MSE ZooKeeper 제품을 사용하여 클라우드로의 마이그레이션을 긴급하게 선택했습니다 . 그러나 어떻게 하면 저렴하고 빠른 아키텍처 업그레이드도 달성할 수 있습니까? 클라우드 마이그레이션 중에 비즈니스와 관련하여 무손실 및 원활한 트래픽 마이그레이션은 어떻습니까?

이 문제에서 MSE Nacos는 오픈 소스 Eureka 기본 프로토콜과의 완전한 호환성을 달성했습니다. 커널은 여전히 Nacos에 의해 구동됩니다. 비즈니스 적응 계층은 Eureka InstanceInfo 데이터 모델과 Nacos 데이터 모델(서비스 및 인스턴스)을 하나씩 매핑합니다. 이 모든 것은 만방그룹이 자체 구축한 유레카 클러스터를 인수한 사업 당사자에게 완전히 투명합니다.

이는 원래 비즈니스 측면을 코드 수준에서 변경할 필요가 없다는 의미이며, Eureka Client가 MSE Nacos의 엔드포인트에 연결된 서버 인스턴스의 엔드포인트 구성만 수정하면 된다는 의미입니다. 또한 사용이 매우 유연합니다. 기본 Eureka 프로토콜을 계속 사용하여 MSE Nacos 인스턴스를 Eureka 클러스터로 사용하거나 Nacos 및 Eureka 클라이언트 이중 프로토콜을 사용하여 서로 다른 프로토콜의 서비스 등록 정보를 지원할 수 있습니다. 변환하여 비즈니스 마이크로서비스 호출의 연결을 보장합니다.

또한 MSE는 클라우드 마이그레이션 과정에서 오픈소스 Nacos-Sync 기반의 데이터 동기화 도구를 지원하는 최적화된 마이그레이션인 MSE-Sync 솔루션을 공식 제공했습니다. 이는 양방향 동기화, 자동 풀 서비스 및 원클릭을 지원합니다. 동기화 기능. MSE-Sync를 통해 만방 수강생은 기존 자체 구축한 Eureka 클러스터에 있는 기존 온라인 서비스 등록 재고 데이터를 한 번의 클릭으로 새로운 MSE Nacos 클러스터로 쉽게 마이그레이션할 수 있습니다. 동시에 기존 클러스터에 새로 등록된 증분 데이터도 사용할 수 있습니다. 또한 한 번의 클릭으로 마이그레이션할 수 있습니다. 지속적으로 자동으로 새 클러스터에 동기화되므로 실제 비즈니스 흐름 마이그레이션 전에 양쪽의 클러스터 서비스 등록 인스턴스 정보가 항상 완전히 일치하도록 보장됩니다. 데이터 동기화 검사를 통과한 후 원래 Eureka 클라이언트 엔드포인트 구성을 교체하고 다시 게시 및 업그레이드한 후 새 MSE Nacos 클러스터로 성공적으로 마이그레이션합니다.

네이티브 Eureka 클러스터 아키텍처의 성능 병목 현상 극복

만방그룹이 MSE 팀 협력 기술 아키텍처 업그레이드를 찾았을 때 가장 중요한 요청은 유레카 클러스터 간 서비스 등록 정보를 동기화해야 한다는 원래의 문제를 해결하는 것이 었습니다 . 이는 유레카 서버가 전통적인 P2P 스타이기 때문입니다. 동기화 AP 모델에서는 각 서버 노드의 역할이 동일하고 완전히 동일합니다. 각 변경(등록/등록 취소/하트비트 갱신/서비스 상태 변경 등)에 대해 모든 인스턴스 데이터의 동기화를 위해 해당 동기화 작업이 생성됩니다. 이러한 방식으로 클러스터 크기 및 인스턴스 수와 직접적인 상관 관계에 따라 동기화 작업량이 증가합니다.

실습을 통해 만방 그룹 학생들은 클러스터 서비스 등록 규모가 2000+에 도달하면 일부 노드의 CPU 점유율과 로드가 매우 높으며 때로는 죽은 척하여 비즈니스 불안을 유발한다는 사실을 발견했습니다. 이는 공식 Eureka 문서에도 언급되어 있습니다. 오픈 소스 Eureka의 브로드캐스트 복제 모델은 자체 아키텍처 취약성을 유발할 뿐만 아니라 클러스터의 전반적인 수평 확장성에 영향을 미칩니다.

복제 알고리즘은 확장성을 제한합니다. Eureka는 브로드캐스트 복제 모델을 따릅니다. 즉, 모든 서버가 모든 피어에 데이터와 하트비트를 복제합니다. 이는 유레카에 포함된 데이터 세트에 대해 간단하고 효과적이지만 서버가 수신하는 모든 HTTP 호출을 있는 그대로 모든 피어에 중계하여 복제가 구현됩니다. 이는 모든 노드가 유레카의 전체 쓰기 부하를 견뎌야 하므로 확장성을 제한합니다.

MSE Nacos는 아키텍처 선택 시 이 문제를 고려하여 자체 개발한 AP 모델 Distro 프로토콜인 스타 동기화 모델을 기반으로 모든 서비스에 대한 인스턴스 데이터를 등록합니다. 샤딩이 수행되고 각 서비스 인스턴스 데이터에 클러스터 책임 노드가 할당됩니다. 각 서버 노드는 데이터의 자체 부분에 대한 동기화 및 갱신 논리만 담당합니다. 동시에 클러스터 간의 데이터 동기화 세분성은 다음과 같습니다. 상대적으로 유레카도 더 작습니다. 이것의 장점은 대규모 배포 및 대규모 서비스 인스턴스 데이터에서도 클러스터 간의 동기화 작업 양을 상대적으로 제어할 수 있으며 클러스터 크기가 클수록 이 모델을 통해 얻을 수 있는 성능 향상이 더 커진다는 것입니다.

지속적인 반복 최적화로 최고의 성능을 추구합니다.

MSE Nacos와 MSE ZooKeeper는 만방그룹의 전체 마이크로서비스 등록 센터 사업을 완료한 후 후속 업그레이드 버전에서 계속해서 최적화를 반복했으며, 수많은 성능 스트레스 테스트 비교 테스트를 통해 모든 세부 사항에서 서버 성능을 지속적으로 최적화했습니다. 비즈니스 경험을 바탕으로 업그레이드 버전의 최적화 포인트를 하나씩 분석하여 소개하겠습니다.

서비스 등록 고가용성 재해복구 보호

Native Nacos는 푸시 보호 라는 고급 기능을 제공합니다 . 서비스 소비자(Consumer)는 등록 센터가 변경되거나 긴급 상황이 발생한 경우 서비스 공급자(Provider)의 인스턴스 목록을 구독합니다. 등록 센터 네트워크, CPU 및 기타 요인으로 인해 센터 간의 링크가 불안정해지면 구독 예외가 발생하여 서비스 소비자가 빈 서비스 공급자 인스턴스 목록을 얻을 수 있습니다.

이 문제를 해결하려면 Nacos 클라이언트 또는 MSE Nacos 서버에서 푸시 보호 기능을 활성화하여 전체 시스템의 가용성을 향상시킬 수 있습니다. 또한 MSE Nacos 서버 데이터가 비정상적인 경우 Eureka 클라이언트가 서버에서 데이터를 가져올 때 기본적으로 재해 복구 보호 지원을 받아 비즈니스 용도로 사용할 수 있도록 이 안정성 기능을 Eureka에 도입했습니다. 이렇게 하면 기대에 미치지 못하는 서비스 제공업체 인스턴스 목록을 얻을 수 없어 비즈니스 실패가 발생합니다.

또한 MSE Nacos 및 MSE ZooKeeper는 다양한 고가용성 보장 메커니즘 도 제공합니다 . 비즈니스 측면에서 높은 신뢰성과 데이터 보안 요구 사항이 있는 경우 인스턴스 생성 시 3개 이상의 노드를 사용하여 배포하도록 선택할 수 있습니다. 인스턴스 중 하나가 실패하면 노드 간 전환이 몇 초 안에 완료되고 실패한 노드는 자동으로 클러스터를 떠납니다. 동시에, 각 MSE 지역에는 여러 가용 영역이 포함되어 있으며, 동일한 지역 내 서로 다른 영역 간의 네트워크 지연은 매우 작습니다(3ms 이내). 가용 영역 A가 실패할 경우 서비스 노드를 배포할 수 있습니다. , , 트래픽은 짧은 시간 내에 다른 가용 영역 B로 전환됩니다. 비즈니스 측은 전체 프로세스를 인식하지 못하고 애플리케이션 코드 수준도 인식하지 못하며 변경이 필요하지 않습니다. 이 메커니즘은 다중 노드 배포 구성만 필요하며 MSE는 분산된 재해 복구를 위해 여러 가용성 영역에 배포하는 데 자동으로 도움을 줍니다.

점진적으로 데이터를 가져오도록 Eureka 클라이언트 지원

만방학생들이 MSE Nacos로 마이그레이션한 후 원래 서버 인스턴스가 정지되어 서비스를 제공할 수 없는 문제는 잘 해결되었습니다. 그러나 전산실의 네트워크 대역폭이 너무 높아 대역폭이 꽉 차는 경우가 있었습니다. 피크 서비스 기간 동안. 나중에 그 이유는 Eureka 클라이언트가 MSE Nacos에서 서비스 등록 정보를 가져올 때마다 전체 풀만 지원했으며 정기적으로 수천 레벨의 데이터를 가져오므로 FGC 수가 증가했기 때문인 것으로 밝혀졌습니다. 게이트웨이 수준.

이 문제를 해결하기 위해 MSE Nacos는 클라이언트 사용량 조정과 함께 Eureka 서비스 등록 정보에 대한 증분 풀 메커니즘을 시작했습니다. 클라이언트는 처음 시작 후 한 번만 전체 양의 데이터를 가져오면 됩니다. 증분 데이터를 기반으로 전체 양의 데이터를 가져와야 합니다. 데이터는 로컬 데이터와 서버 데이터의 일관성을 유지하는 데 사용되며, 정기적인 전체 규모 가져오기가 더 이상 필요하지 않습니다. 일반 프로덕션 환경에서 변경되는 증분 데이터의 양은 매우 많습니다. 이는 수출 대역폭에 대한 압력을 크게 줄일 수 있습니다. 만방 학생들은 이렇게 최적화된 버전으로 업그레이드한 후 200KB/s로 업그레이드하기 전 40MB/s에서 대역폭이 갑자기 떨어지는 것을 발견하고 전체 대역폭 문제가 해결되었습니다.

서버 성능을 최적화하기 위한 완전한 스트레스 테스트

이후 MSE 팀은 MSE Nacos 클러스터 For Eureka 시나리오에 대해 대규모 성능 스트레스 테스트를 수행하고 다양한 성능 분석 도구를 사용하여 비즈니스 링크의 성능 병목 현상을 식별하고 원래 기능에 대한 더 많은 성능 최적화 및 최적화를 수행했습니다. 레벨 성능 매개변수 튜닝.

서버 측에서 전체 및 증분 데이터 등록 정보에 대해 캐싱을 도입하고, 서버 측 데이터 해시를 기반으로 변경 여부를 판단합니다. Eureka 서버가 더 많이 읽고 더 적게 쓰는 시나리오에서는 반환된 결과를 생성하기 위해 CPU 계산의 성능 오버헤드를 크게 줄일 수 있습니다.
SpringBoot의 기본 StringHttpMessageConverter는 대규모 데이터 반환 처리 시 성능 병목 현상이 발생하는 것으로 확인되었으며, 문자열 데이터 IO 전송 성능을 최적화하기 위해 EnhancedStringHttpMessageConverter를 제공했습니다.
서버 측 데이터 반환은 청크 분할을 지원합니다.
Tomcat 스레드 풀의 수는 컨테이너 구성에 따라 적응적으로 조정됩니다.

만방그룹이 위 버전의 반복적인 업그레이드를 완료한 후, 서버 측의 다양한 매개변수도 훌륭한 최적화 결과를 얻었습니다.

서버 CPU 사용률이 13%에서 2%로 감소했습니다.

RT를 읽는 등록 센터가 원래 55ms에서 3ms 미만으로 줄었습니다.

서버측 YGC 수가 원래 10개 이상에서 1개로 감소되었습니다.

YGC 시간이 기존 125ms에서 10ms 미만으로 단축되었습니다.

바이패스 최적화는 높은 압력 하에서 클러스터의 안정성을 보장합니다.

만방 학생들이 일정 기간 동안 MSE ZooKeeper로 마이그레이션한 후 클러스터에서 다시 Full GC가 발생하여 클러스터가 불안정해졌습니다. MSE 긴급 조사 결과 Metrics의 watch 관련 통계 지표 때문인 것으로 밝혀졌습니다. 계산 중에 ZooKeeper가 현재 노드에 저장되었습니다. 시계 데이터는 완전히 복사되었으며 전체 갱 시나리오에서는 시계 규모가 매우 큽니다. 이러한 시나리오에서 메트릭 계산 복사 시계는 많은 양의 메모리 조각을 생성합니다. 최종 클러스터가 정규화된 메모리 리소스를 할당할 수 없게 되어 궁극적으로 Full GC가 발생합니다.

이 문제를 해결하기 위해 MSE ZooKeeper는 중요하지 않은 메트릭에 대한 다운그레이드 조치를 취하여 이러한 메트릭이 클러스터 안정성에 영향을 미치지 않도록 합니다. 감시 복사 메트릭의 경우 데이터 복사 계산으로 인한 메모리 조각화 문제를 방지하기 위해 동적 획득 전략을 채택합니다. 이 최적화를 적용하면 클러스터 Young GC 시간과 횟수가 크게 줄어듭니다.

최적화 후 클러스터는 200W QPS를 원활하게 처리할 수 있으며 GC는 안정적입니다.

대기 시간과 처리량 간의 최적의 균형점을 찾기 위한 지속적인 매개변수 최적화

만방 학생들은 자체 구축한 ZooKeeper를 MSE ZooKeeper로 마이그레이션한 후 애플리케이션이 출시되었을 때 ZooKeeper에서 데이터를 읽는 데 있어 클라이언트의 지연이 너무 크고 애플리케이션 시작 읽기 구성 시간이 초과되어 애플리케이션 시작 시간이 초과되는 것을 발견했습니다. 이 문제를 해결하기 위해 MSE ZooKeeper 타겟 스트레스 테스트 분석에 따르면 풀 서비스 시나리오에서 ZooKeeper는 애플리케이션이 출시될 때 많은 수의 요청을 처리해야 하며 요청에 의해 생성된 개체로 인해 기존 시스템에서 빈번한 Young GC가 발생하는 것으로 나타났습니다. 구성.

이 시나리오에 대응하여 MSE 팀은 요청 지연과 TPS 간의 최적의 교차점을 찾기 위해 여러 차례의 스트레스 테스트를 통해 클러스터 구성을 조정했습니다. MSE 팀은 지연 요구 사항을 충족한다는 전제하에 클러스터의 최적 성능을 탐색했습니다. 클러스터의 일일 10w QPS 수준에서 20ms의 요청 지연을 보장하며 CPU는 20%에서 5%로 감소하고 클러스터 로드는 크게 줄어듭니다.

추신

디지털 화물 산업의 치열한 경쟁과 급속한 기술 발전을 배경으로 만방그룹은 자체 기술 아키텍처를 성공적으로 업그레이드하여 자체 구축한 유레카 등록 센터에서 보다 효율적이고 안정적인 MSE Nacos 플랫폼으로 원활하게 이전했습니다. 이는 기술 혁신과 사업 확장에 대한 만방그룹의 확고한 의지를 나타낼 뿐만 아니라 미래 발전을 위한 원대한 계획을 보여줍니다. 만방그룹은 마이크로서비스 아키텍처의 안정성과 고성능을 디지털 변혁의 핵심으로 간주합니다. 새로운 등록 센터 아키텍처를 통해 가져온 상당한 성능 개선과 안정성 향상은 만방에 대한 강력한 지원을 제공하여 플랫폼이 성장하는 비즈니스를 더 잘 처리할 수 있도록 준비합니다. 미래에 발생할 수 있는 모든 문제를 요구하고 처리할 수 있는 힘을 가지고 있습니다.

전체 마이그레이션 과정에서 만방그룹의 민첩한 대응과 기술팀의 전문적인 실행이 아키텍처 업그레이드 속도를 가속화했다는 점도 언급할 만하다. 비즈니스 플랫폼의 성공적인 전환은 만방의 서비스에 대한 사용자의 신뢰를 높일 뿐만 아니라 다른 기업에도 귀중한 경험을 제공합니다. 앞으로도 만방은 MSE와 긴밀히 협력해 기술 아키텍처의 안정성, 확장성, 성능을 더욱 향상시키고 업계 벤치마크를 지속적으로 설정하며 물류산업 전체의 디지털 전환을 촉진할 예정이다.

이번 마이그레이션 과정에서 비즈니스는 손실 없이 원활하게 마이그레이션될 수 있었고 성능도 크게 향상되어 서비스 등록 센터 분야에서 MSE의 탁월한 성능과 신뢰성이 입증되었습니다. 저는 MSE의 지속적인 발전과 함께 사용 편의성과 안정성에 대한 지속적인 추구가 의심할 여지 없이 더 많은 기업에 엄청난 상업적 가치를 제공하고 기업의 디지털화 프로세스에서 점점 더 중요한 역할을 할 것이라고 믿습니다.

또한 MSE는 트래픽 보호, 풀 링크 그레이스케일 릴리스 등을 포함한 마이크로서비스 거버넌스 기능도 완벽하게 지원합니다. 입구 게이트웨이부터 백엔드까지 완전히 구성된 전류 제한 규칙을 적용함으로써 갑작스러운 트래픽으로 인한 시스템 안정성 위험을 효과적으로 해결하여 시스템의 지속적이고 안정적인 운영을 보장하고 기업은 핵심 비즈니스 개발에 더욱 집중할 수 있습니다. 만방그룹의 성공 사례는 업계에 새로운 이정표를 세웠습니다. 더 많은 기업들이 디지털 여정에서 더욱 눈부신 성과를 거두기를 기대합니다.

Manbang CTO Wang Dong(Dongtian)의 메시지: 클라우드의 기능을 완전히 이해하고 활용하면 Manbang 기술팀은 하위 수준의 지속적인 투자에서 벗어나 더 높은 수준의 시스템 안정성과 엔지니어링 효율성에 집중할 수 있으며 클라우드의 기능을 통해 더 나은 결과를 얻을 수 있습니다. 아키텍처 수준.

추천 활동:

Feitian Technology Salon의 첫 번째 AI 네이티브 애플리케이션 아키텍처 세션에 등록하려면 여기를 클릭하세요 .