인기 주택 플랫폼 Beike가 Apache APISIX를 선택한 이유

안녕하세요, 저는 중국의 선도적인 주택 거래 및 서비스 통합 온라인 및 오프라인 플랫폼인 케 홀딩스(Beike)에서 API 게이트웨이 시스템 개발을 담당하고 있는 Hui Wang입니다. Beike는 프로덕션 시스템에서 API 게이트웨이로 Apache APISIX를 사용하고 있습니다. 데이터 중심 기업으로서, 매일 수백만 건의 프로덕션 트래픽이 API 게이트웨이를 통과하며, Apache APISIX는 안정적이고 뛰어난 성능을 제공할 수 있습니다. 최근 Apache APISIX가 Apache 인큐베이터에 합류했는데, 이 기회를 통해 초기에 Apache APISIX를 선택한 이유와 사용하면서 얻은 몇 가지 경험을 공유하고자 합니다.

Kong 또는 Apache APISIX

게이트웨이의 기술적 요구 사항으로, 먼저 게이트웨이는 뛰어난 성능과 대규모 트래픽 접근을 지원할 수 있는 능력을 갖추어야 합니다. 또한 안정적이어야 하며, 오류율이 0이어야 합니다.

벤더 선택 원칙은 다른 오픈소스 프로젝트를 기반으로 하거나 참고하여 더 안정적인 버전을 재구성하여 더 많은 트래픽을 처리할 수 있도록 하는 것입니다. 장단점을 평가한 후, 저는 이 아이디어를 상사와 논의했고, 이 프로젝트를 시작하기로 결정했습니다. 제 머릿속에 떠오른 첫 번째 선택지는 Kong이었습니다. Kong은 또 다른 유명한 오픈소스 게이트웨이입니다.

Kong의 공식 웹사이트를 둘러보고 관련 글을 읽어본 후, Kong은 대부분의 사용자 요구를 충족할 수 있고 성능도 매우 안정적이기 때문에 적합한 옵션이라고 생각했습니다. 저는 즉시 코드를 git clone하고 읽기 시작했습니다. 그러나 며칠 동안 조사한 후에도 여전히 혼란스러웠습니다. Kong이 왜 이렇게 큰 코드 베이스를 가지고 있는지 이유를 짐작할 수 있었는데, 그것은 Kong이 수많은 기능을 제공해야 하기 때문이었습니다.

갑자기 몇 가지 질문이 머릿속을 맴돌았습니다. Kong을 완전히 이해하는 데 얼마나 걸릴까? 모든 요구 사항을 충족하는 프로젝트를 구축하는 데 얼마나 걸릴까? Kong이 제공하는 모든 기능이 필요한가?

며칠 전, API 게이트웨이 Apache APISIX 버전 0.5가 출시되었습니다. 배우는 자세로 이 오픈소스 프로젝트를 빠르게 살펴보았고, 놀랍게도 API 분야의 전문가인 Yuansheng Wang과 Ming Wen이 함께 개발했다는 사실을 알게 되었습니다. 이러한 전문가들의 추천을 바탕으로 이 제품을 거부할 수 없었습니다.

오픈소스 프로젝트가 출시된 지 얼마 되지 않았기 때문에, Apache APISIX가 지원하는 기능은 상당히 제한적이었습니다. 그러나 동적 로드 밸런싱, 서킷 브레이커, 인증, 속도 제한과 같은 모든 필수 기능이 이미 구현되어 있었습니다. 동시에 상대적으로 작은 코드 베이스는 학습 비용을 줄여주었습니다. Kong과 비교했을 때, Apache APISIX의 승리를 선언할 수 있었습니다. Apache APISIX는 불필요한 기능에 대한 걱정 없이 초기 기능 계획을 충족할 수 있기 때문에 현재 상황에 더 적합했습니다.

그러나 가장 중요한 문제는 Apache APISIX의 성능이 오픈소스로 공개된 시간이 짧아 단점이 될 수 있다는 점이었습니다. 동일한 테스트 환경에서 Kong과의 스트레스 테스트 결과를 비교했을 때, Apache APISIX가 결국 Kong을 이겼습니다. 그러나 Kong은 훨씬 더 무겁고 복잡하기 때문에 Kong에게는 공평하지 않았습니다. 반면, 제 사용 사례에서는 Apache APISIX가 제공하는 모든 필요한 기능이 있기 때문에 차이가 없었습니다. Apache APISIX의 성능 테스트 보고서에 따르면, 단일 코어 CPU에서 24k QPS를 달성할 수 있으며, 지연 시간은 0.7밀리초에 불과합니다.

요약하면, 저는 다음과 같은 이유로 Apache APISIX를 선택했습니다:

• 프로젝트의 모든 요구를 충족할 수 있는 전제 하에, Apache APISIX의 학습 비용이 낮음
• Kong은 큰 코드 베이스를 가지고 있어 코드 유지 보수가 어려움
• Apache APISIX의 저자들은 OpenResty 커뮤니티에서 더 활발히 활동하며, 이는 더 나은 코드 품질을 제공할 수 있음
• 가장 중요한 것은 저자와 직접 소통하여 질문을 빠르게 해결할 수 있음

공식 웹사이트에서 제공하는 APISIX의 이유는 다음 그림과 같습니다:

Apache APISIX가 제공할 수 있는 기능

• 핫 업데이트 및 핫 플러그인
• 동적 로드 밸런싱
• 능동 및 수동 상태 점검
• 서킷 브레이커
• 인증
• 속도 제한
• gRPC 프로토콜 변환
• 동적 TCP/UDP, gRPC, WebSocket, MQTT 브로커
• 대시보드
• 금지 및 허용 목록
• 서버리스

Apache APISIX는 거의 10개의 버전이 출시되었으며, 여기에 나열된 것보다 훨씬 더 많은 기능을 지원합니다. 비즈니스 상황에 따라 그린 아키텍처 다이어그램은 다음과 같습니다:

APISIX를 통합한 이야기

며칠 동안 코드를 읽은 후, 저는 Apache APISIX에 대한 기본적인 이해를 갖추게 되었지만, 한 가지 질문이 떠올랐습니다: 저는 오픈소스 프로젝트를 개발해본 적이 없는데, 어떻게 이를 완수할 수 있을까? 저는 로컬에 세 가지 다른 브랜치를 만들었습니다. 하나는 Apache APISIX 브랜치로, 업스트림 오픈소스 저장소를 가리키고, 다른 하나는 dev 브랜치로, 정기적인 비즈니스 반복에 사용되며, 마지막 main 브랜치는 온라인 업그레이드에 사용됩니다.

2주간의 노력 끝에, 제 프로젝트는 기본적인 구조를 갖추게 되었습니다. 이제 결과를 검토할 시간이 되었고, 그렇게 스트레스 테스트 단계를 시작했습니다. 서비스는 Tencent Cloud의 8코어 및 32GB 메모리 서버에 배포되었으며, 업스트림은 일반적인 클라우드 프로덕션 환경이기 때문에 너무 강하게 테스트할 수 없었습니다. 성능 보고서는 다음과 같습니다:

성능 보고서 요약: 인터페이스 소요 시간이 47% 감소했고, 오류가 발생하지 않았으며, 안정성이 향상되었습니다. TPS 피크 값이 82% 증가했고, 오류가 발생하지 않았으며, 안정성이 향상되었습니다.

개발 환경이 준비되었고, 클라우드 배포를 연구하기 시작했습니다. Apache APISIX는 Docker, RPM 패키지, Luarocks, 소스 코드 등 다양한 설치 방법을 지원합니다. 안타까운 소식은 클라우드 환경에 아무것도 설치할 수 없고, 소스 코드는 고정된 경로에만 배치할 수 있다는 점이었습니다. 따라서 OpenResty 1.15.8을 기반으로 개발된 Apache APISIX의 많은 기능이 지원되지 않을 것입니다. 어떻게 해야 할까요? 코드 저장소에서 컴파일된 파일이 생성되며, 특정 디렉토리에서 컴파일해야 하고, PCRE의 정적 바인딩을 사용할 수 없어 1-2일이 소요되었습니다. 마지막으로, 그레이 릴리스를 조정하여 트래픽을 몇 주 동안 2%에서 전체 볼륨으로 증가시켰습니다. 다행히 모든 것이 성공적으로 마무리되었습니다.

몇 주간의 모니터링 후, 온라인 서비스는 상대적으로 안정적이었습니다. Apache APISIX 0.5의 많은 기능은 API 인터페이스 호출을 통해 구현되어야 했습니다. 요청 매개변수는 구문 오류가 발생하기 쉬웠고, 직관적이고 편리한 페이지가 없었습니다. 그 외에도, 우리의 비즈니스 시나리오에서는 업스트림 서비스 탐색 기능이 필요했습니다. 마침 Apache APISIX 버전 0.7이 출시되었고, 버전 0.7은 콘솔과 업스트림 서비스 탐색을 지원했는데, 이는 바로 우리가 필요로 하는 것이었습니다. 정말 좋은 소식이었습니다! 업그레이드해야 했습니다!

Apache APISIX 브랜치는 0.7로 업그레이드하기 쉬웠지만, 코드를 어떻게 병합할 수 있을까요? 이 두 버전 간의 코드 변경 사항이 너무 많았습니다. 먼저 병합을 시도했지만, 충돌이 너무 많았고, 우리는 매우 위험한 속도로 진행 중이었습니다. 충돌을 해결하는 표준 방법은 비현실적이었고, 이는 수많은 숨겨진 버그를 초래할 수 있었습니다. 더 효율적인 해결책이 있을까요? 온라인에서 검색한 결과, git checkout –ours와 git checkout –theirs(사용해본 적이 없다면 검색해보세요)라는 단축 방법을 찾았고, 몇 분 만에 APISIX 0.5에서 0.7로 업그레이드를 완료했습니다. 물론, APISIX 코드의 견고함 덕분에 비즈니스 플러그인만 추가하면 되었고, 어떤 결합도 필요하지 않았습니다.

Apache APISIX 0.7 버전은 콘솔을 제공하기 때문에 더 이상 JSON을 작성할 필요가 없었습니다. 저는 빠르게 상태 점검을 검토했고, 초기에는 문제가 없었으며, 업스트림 서비스의 상태를 인지할 수 있었습니다. 그러나 업스트림 서비스의 로그를 확인했을 때, 여러 번 재시작한 후 상태 점검의 빈도가 계속 증가하는 것을 발견했습니다. 상태 점검에 버그가 있을 수 있다고 추측했습니다. 소스 코드를 읽은 후, 각 라우터의 체커가 전역적으로 고유하지 않고, 모든 작업에 체커가 있다는 것을 알게 되었습니다. 생성된 모든 작업에 동일한 이름을 사용하여 이 문제를 해결할 수 있었습니다. 사소한 수정이더라도, 핫