Snowball Finance, APISIX로 Active-Active 아키텍처 혁신

스노우볼 파이낸스 인프라 팀의 시원제(Shi Wenjie) 선임 개발 엔지니어가 Apache APISIX Summit ASIA 2022에서 스노우볼 파이낸스의 APISIX 활용 사례를 공유했습니다. 이 글은 그 발표를 바탕으로, 스노우볼 파이낸스가 Apache APISIX를 활용하여 내부의 액티브-액티브(active-active) 아키텍처를 진화시키고 더 유연한 서비스 관리를 달성한 방법을 소개합니다.

도전 과제

• 복잡한 SDK 인증 모듈로 인해 액티브-액티브 아키텍처가 시장 서비스 모듈에서만 사용 가능한 상황에서 사용자 센터가 지역 간에 접근할 때 시스템 복잡성과 보안 위험이 증가
• OpenResty는 관측 가능성을 위한 강력한 모니터링 시스템이 부족하며, 확장성을 달성하기 위해 맞춤형 스크립트가 필요해 개발 및 운영 비용이 높음
• NGINX 레지스트리 센터가 불완전하고 하트비트 메커니즘이 없어 가용성과 안정성이 낮아 시스템 장애를 신속하게 처리할 수 없음

목표

• 비즈니스 그룹에 투명성을 유지하면서 너무 많은 변수를 도입하지 않고 변경을 최소화
• 인프라 수준에서 문제를 통합적으로 처리하고, 로컬 데이터 센터 내에서 인증 서비스를 완료

결과

• 게이트웨이 계층에서 통합 인증, 서킷 브레이커, 속도 제한을 구현하여 시스템 결합도를 낮추고 이중 데이터 센터 시나리오에서 서비스 품질을 개선
• APISIX 모니터링 시스템을 활용하여 게이트웨이에서 서비스 계층까지 통합 모니터링 솔루션을 구축하고 글로벌 문제 해결을 위한 탁월한 지원 제공
• gRPC 프로토콜 변환 및 서비스 관리를 위한 우아한 구현 방식 제공

배경

2010년에 설립된 스노우볼 파이낸스는 투자 커뮤니티로 시작하여 현재 중국의 선도적인 온라인 금융 관리 플랫폼으로 성장했습니다. 투자자들에게 고품질 콘텐츠, 실시간 시장 서비스, 거래 도구, 자산 관리 등 다양한 서비스를 제공하고 있습니다.

이 중 실시간 시장 서비스는 여러 상위 데이터 소스에 연결되어 데이터 스트리밍, 저장 및 배포를 통해 투자자들에게 안정적인 데이터 서비스를 제공합니다. 따라서 실시간 시장 서비스는 스노우볼 파이낸스 시스템 내에서 주요 자원 소비자 중 하나입니다.

이에 따라 스노우볼 파이낸스 내에서 중요한 과제 중 하나는 시장 서비스의 성능 최적화를 포함한 지속적인 안정성 개선입니다. 그러나 트래픽 피크 기간에는 데이터 급증으로 인해 일부 시스템이 느린 응답 속도나 심지어 사용 불가 상태가 되어 사용자 경험에 영향을 미칠 수 있습니다.

이러한 배경에서 스노우볼 파이낸스는 투자자들에게 안정적이고 고품질의 서비스를 제공하기 위해 서비스 액티브-액티브 전환 계획을 시작했으며, Apache APISIX가 이를 크게 단순화했습니다. 또한, 클라우드 네이티브 API 게이트웨이인 APISIX는 활발한 커뮤니티와 풍부한 생태계를 갖추고 있으며, 여러 플러그인을 지원합니다. 이러한 장점들은 스노우볼 파이낸스의 클라우드 네이티브 아키텍처 진화를 위한 좋은 기반을 제공합니다.

액티브-액티브 전환의 고통 포인트

단일 아키텍처를 적용하던 시절, 사용자 트래픽은 서버 로드 밸런싱(SLB)을 통해 들어와 게이트웨이를 거쳐 간단한 공통 로직 처리를 받은 후 백엔드 서비스로 전달되었습니다. 백엔드 서비스는 통합 인증 모듈을 통해 SDK를 사용하여 스노우볼 사용자 센터와 사용자 인증을 시작하고, 인증이 성공하면 후속 처리를 진행했습니다.

실제 비즈니스 시나리오에서 몇 가지 고통 포인트가 점차 드러났습니다.

1. 복잡한 SDK 인증 모듈

액티브-액티브 전환을 구현할 때, 마이크로서비스의 제공자와 소비자는 동시에 배포 및 출시될 수 없습니다. 스노우볼 파이낸스의 시장 서비스가 클라우드에 처음 출시되었을 때, 사용자 센터는 아직 클라우드를 지원하지 않아 데이터 센터 간 호출이 발생했습니다. 사용자 센터의 통계에 따르면, RPC 호출은 하루에 약 수십억 건에 달하며, 피크 시 50,000 QPS에 이를 수 있어 높은 지연 시간이 발생할 수 있습니다.

동시에, 스노우볼 파이낸스의 인증 로직은 복잡했습니다. OAuth2.0/JWT 프로토콜 외에도 클라이언트 버전과 스노우볼 파이낸스의 여러 앱 등 많은 요소를 고려해야 했습니다. 또한, 인증 모듈이 서비스에 내장되어 있어 업그레이드가 더 어려웠습니다.

2. OpenResty의 기능 한계

스노우볼 파이낸스는 이전에 OpenResty를 게이트웨이로 사용했지만, OpenResty는 일부 기능에서 약점이 있었습니다. 따라서 개발자들은 OpenResty를 기존 모니터링 시스템과 통합할 때 더 많은 맞춤화가 필요했습니다. 또한, DevOps 엔지니어들은 두 번째 개발 프로세스를 구현하기 위해 맞춤형 스크립트를 추가해야 했습니다.

3. 자체 개발 레지스트리 센터 의존

현재 스노우볼 파이낸스는 백엔드 서비스가 시작될 때 레지스트리 센터에 요청하여 게이트웨이에 등록하고, 서비스가 중지될 때 서비스 노드를 제거하는 방식으로 HTTP 서비스 등록을 수행합니다. 레지스트리 센터는 주기적으로 서비스 노드를 폴링하여 건강 상태를 확인합니다. 그러나 오픈소스 프로젝트와 비교했을 때, 자체 개발 서비스의 유지 보수 비용이 더 높습니다.

API 게이트웨이 기술 선택

비즈니스 실무 시나리오에서 점차 드러난 고통 포인트를 바탕으로, 스노우볼 인프라 팀은 게이트웨이 제품에 대한 연구를 시작했습니다.

팀 내부에서는 비즈니스 투명성을 보장하면서도 변경을 최소화하고 너무 많은 변수를 도입하지 않기를 원했습니다. 또한, 인프라 수준에서 문제를 통합적으로 해결하고, 로컬 데이터 센터 내에서 인증 서비스를 완료하고자 했습니다. 이를 고려하여 스노우볼 파이낸스는 인증 서비스를 API 게이트웨이로 이동하기로 결정했습니다.

스노우볼 파이낸스는 새로운 API 게이트웨이가 다음 요구 사항을 충족하기를 바랐습니다:

• 높은 성능
• 강력한 확장성
• 다중 프로토콜 지원
• 게이트웨이 인증 비용 절감

아래는 OpenResty, Spring Gateway, Kong, APISIX 간의 상세한 API 게이트웨이 기술 선택 목록입니다.

게이트웨이	장점	단점	운영 비용	가용성
OpenResty	높은 맞춤화 가능성과 안정성	관측 가능성 부족	높음	높음
Spring Gateway	Java 개발에 친화적	성능 수준이 요구 사항을 충족하지 못함	중간	중간
Kong	강력하고 기능이 풍부	PostgreSQL 단일 데이터베이스	낮음	중간
APISIX	클라우드 네이티브, 다중 프로그래밍 언어 지원, 강력한 확장성	/	낮음	높음

내부 요구 사항과 시장에서 인기 있는 게이트웨이 제품을 비교한 후, 스노우볼 파이낸스는 최종적으로 Apache APISIX를 선택하여 후속 아키텍처를 구축했습니다.

Apache APISIX 기반의 실습

조정된 아키텍처

위 그림과 같이, 현재 스노우볼 시장 서비스의 액티브-액티브 아키텍처는 왼쪽에 표시되어 있으며, 이는 원본 데이터 센터의 아키텍처와 거의 동일합니다. 오른쪽은 클라우드로 마이그레이션 후 다중 지역 설계를 기반으로 한 액티브-액티브 아키텍처를 보여줍니다.

스노우볼 파이낸스는 APISIX를 기반으로 다음과 같은 조정을 주로 수행했습니다:

• 인증 모듈을 프록시 계층으로 통합하고 APISIX를 사용하여 통합 인증을 수행. JWT 유형의 경우 APISIX의 jwt-auth 플러그인을 사용하여 로컬 인증을 직접 수행.
• OAuth 2.0과 호환되도록 조정하고, APISIX를 사용하여 스노우볼 파이낸스 사용자 센터를 호출하여 처리.
• 스노우볼 파이낸스 백엔드 RPC 서비스 레지스트리 센터와 연결하여 JWT 인증이 실패할 때 백엔드 서비스를 사용하여 인증.

적용 시나리오

백엔드 서비스가 APISIX에 연결된 후, 주로 게이트웨이 인증 및 관측 가능성 측면에서 몇 가지 실습을 수행했습니다.

시나리오 1: 게이트웨이 인증

앞서 언급했듯이, 스노우볼 파이낸스의 이전 아키텍처에는 통합 인증 방법이 없었습니다. 한 방법은 내부 애플리케이션 측에서 SDK를 사용하여 사용자 센터를 호출하여 인증을 수행하는 것이었고, 다른 방법은 JWT 인증을 사용하는 것이었습니다. 이 두 인증 방법이 공존하면서 확장성과 유지 보수성에 문제가 발생했습니다.

1. APISIX를 게이트웨이로 통합한 후, 스노우볼 파이낸스는 APISIX 게이트웨이 계층을 사용하여 인증을 통합적으로 관리했습니다. 기존의 JWT 인증 방법은 공식 플러그인인 jwt-auth로 대체되었습니다. jwt-auth 플러그인을 구성하고 사용하는 것은 비교적 간단합니다: Dashboard에서 라우트 및 업스트림과 같은 관련 정보를 간단히 구성하면 플러그인이 활성화됩니다.
2. 스노우볼 파이낸스는 grpc-transcode 플러그인을 사용하여 이전의 OAuth 2.0 관련 인증 방법을 처리하기 위해 인증 서비스 호출을 프록시했습니다.

스노우볼 파이낸스는 내부적으로 gRPC를 호출하여 인증을 구현하기 위해 다음 세 가지 솔루션을 고려했습니다:

• 솔루션 1: Lua를 사용하여 gRPC를 직접 호출. 이 솔루션은 로드 밸런싱 및 동적 업스트림과 같은 관련 구현을 고려해야 하므로 과정이 더 복잡하여 폐기.
• 솔루션 2: Lua 코루틴을 사용하여 Golang 로직을 콜백. 스노우볼 파이낸스는 이 방법에 대한 실무 경험이 부족하여 폐기.
• 솔루션 3: Lua를 사용하여 HTTP 호출을 수행하고, gRPC 인터페이스는 APISIX의 grpc-transcode 플러그인을 사용하여 구현. APISIX 커뮤니티의 빠른 플러그인 최적화 반복 덕분에, 스노우볼 파이낸스는 최종적으로 이 옵션을 선택하여 gRPC 호출을 구현.

현재, 실행 중에 프로토콜 버퍼 파일의 수동 동기화가 필요합니다. 이는 사용자 센터가 프로토콜 버퍼 파일을 수정할 경우, APISIX에 저장된 버전과 일치하지 않으면 인증 문제가 발생할 수 있기 때문입니다.

시나리오 2: 관측 가능성 하의 다차원 모니터링

스노우볼 파이낸스에서 웹사이트 출시 후 많은 메트릭을 모니터링해야 하며, 주로 다음 세 부분에 초점을 맞춥니다:

• NGINX 연결 상태 및 입출력 트래픽
• HTTP 오류 상태 코드 비율 (서비스 또는 업스트림/다운스트림 문제 해결에 사용)
• APISIX 요청 지연 시간 (APISIX가 요청을 업스트림으로 전달할 때 로직 실행에 소요된 시간)

예를 들어, 어떤 경우에는 APISIX의 지연 시간이 높게 나타날 수 있습니다 (아래 그림 참조). 이는 지연 시간 계산 로직과 관련이 있습니다. 현재 로직은 NGINX에서 단일 HTTP 요청에 소요된 시간에서 이 요청이 업스트림으로 라우팅되는 데 소요된 시간을 뺀 값입니다. 두 시간 소요량의 차이가 APISIX 지연 시간 메트릭입니다.

APISIX를 사용한 후, 일부 플러그인을 추가하거나 수정하면 로직 변경이 발생할 수 있으며, 이는 지연 시간 관련 데이터에 편차를 일으킬 수 있습니다. 데이터 모니터링의 정확성을 보장하면서도, 문제를 사전에 파악하여 문제 해결을 용이하게 하기 위해 스노우볼 파이낸스는 지연 시간 모니터링 플러그인도 추가했습니다.

APISIX의 관측 가능성 기능을 활용하여 Access 로그를 수집하고, 이를 형식화 및 표준화하여 트래픽 대시보드에 전달하여 확인 및 요약할 수도 있습니다. 이를 통해 여러 관점에서 전반적인 추세를 사전에 파악하고, 잠재적인 문제를 식별하여 신속하게 해결할 수 있습니다.

시나리오 3: ZooKeeper 레지스트리 확장

스노우볼 파이낸스에서 gRPC 호출은 Zookeeper 레지스트리를 기반으로 등록 및 발견됩니다. 인증을 구현하는 과정에서, 로컬 JWT 검증이 실패할 경우 API 게이트웨이는 스노우볼 파이낸스 사용자 센터의 gRPC 서비스에 접근하여 인증을 수행해야 하며, 이를 위해 API 게이트웨이는 레지스트리 센터에서 백엔드 gRPC 서비스 주소 목록을 가져와야 합니다.

APISIX 공식 플러그인 apisix-seed는 ZooKeeper와 통합하여 서비스 발견을 수행할 수 있습니다. 스노우볼 파이낸스는 자체 비즈니스에 더 특화된 몇 가지 맞춤화를 수행했습니다.

구체적인 구현은 주로 APISIX의 콘텐츠 노드에서 이루어집니다. Worker 프로세스가 시작될 때, 아래 그림과 같은 ZK-Rest 클러스터를 폴링한 후, 정기적으로 전체 서비스의 소스 데이터와 정보를 가져와 Worker 프로세스의 로컬 캐시에 업데이트하여 서비스 목록을 갱신합니다.

위 그림에서도 볼 수 있듯이, ZK-Rest 클러스터는 Rest 형태로 ZooKeeper 데이터에 접근합니다. 이를 통해 고가용성 기능을 달성하기 위해 단순히 인스턴스를 추가하면 됩니다. 그러나 이 작업은 서비스 목록 업데이트에 지연을 초래할 수 있는 단점도 있습니다.

요약 및 전망

현재, Apache APISIX는 스노우볼 파이낸스 내에서 게이트웨이 계층으로 잘 작동하고 있습니다. 구체적으로:

• 게이트웨이 계층에서 통합 인증, 서킷 브레이커, 속도 제한 기능을 구현하여 전체 시스템의 결합도를 낮추고 이중 데이터 센터에서 서비스 품질을 개선.
• APISIX의 모니터링을 활용하여 게이트웨이에서 서비스까지 통합 모니터링 솔루션을 구축하고 글로벌 문제 해결을 위한 탁월한 지원 제공.
• gRPC 프로토콜 변환 및 서비스 관리를 위한 우아한 구현 방식 제공.

향후 사용 계획에서 스노우볼 파이낸스는 다음을 계획하고 있습니다:

• K8s 클러스터에 APISIX Ingress Controller 적용.
• grpc-transcode 플러그인을 사용하여 HTTP/gRPC 프로토콜 변환을 통해 통합 백엔드 인터페이스 달성.
• traffic-split 플러그인을 사용하여 트래픽 라벨링, Nacos 레지스트리 센터 연결, 카나리 릴리스 및 기타 서비스 거버넌스 구현.

향후 계획에서 Apache APISIX는 기존의 OpenResty를 대체하고, 최종적으로 전체 라이프사이클의 남북 트래픽 관리를 달성할 예정입니다.