Spring Cloud Gateway를 포기하라! 핀테크 앱 Huanbei가 Apache APISIX를 활용하는 방법

자바에 대한 애증

왜 금융 시스템은 자바를 선호하는가

자바는 출시 이후로 언어적 장점과 방대한 생태계로 인해 항상 인기 있고 많은 개발자들에게 선호되는 언어입니다.

최근 15~20년 동안, 많은 금융 시스템이 자바를 주요 기술 스택으로 선택했습니다. 조사를 통해 우리는 자바의 다음과 같은 장점을 결론지었습니다:

위의 이유들로 인해, 자바는 금융 소프트웨어 시스템의 선호를 받고 있습니다.

클라우드 네이티브 시대의 자바 현황

기술의 급속한 발전으로 인해, 업계는 곧 모놀리식 아키텍처를 버리고 마이크로서비스와 클라우드 네이티브가 주류가 될 것입니다. 그러나 최근 몇 년간의 기술 환경에서 자바는 일부 비즈니스 시나리오에서 주도적인 역할을 잃기 시작했습니다.

첫째, 자바는 성능이 약합니다. C 관련 기술 스택과 비교하면 왜 이렇게 말하는지 이해할 수 있을 것입니다.

둘째, 자바는 가상 머신에서 실행되며, 가상 머신이 자바의 메모리 관리를 담당합니다. 따라서 고성능이나 동적 변경이 필요한 경우 자바는 경쟁력이 떨어집니다.

그 외에도, 자바는 더 많은 리소스를 필요로 합니다. 프레임워크를 구축하는 것은 비용을 고려하지 않아도 쉽습니다. 그러나 클라우드 네이티브 시대에는 계산이 훨씬 더 세분화되고 세밀해졌기 때문에 리소스가 그 어느 때보다 귀중해졌습니다. 게다가 자바는 무겁고 때때로 재시작이 필요하기 때문에 실행하는 데 엄청난 리소스가 소모됩니다. 결과적으로, 자바는 QPS와 비즈니스 연속성에 대한 높은 요구 사항에서 문제가 발생할 수 있습니다.

마지막으로, 포인터 문제도 논의할 가치가 있습니다. 포인터는 C/C++에 익숙한 개발자들에게는 좋은 리소스입니다. 그러나 자바는 가상 머신에서 실행되기 때문에 메모리 관리는 개발자 대신 GC(Garbage Collection)에 의해 처리됩니다. 이 경우, 높은 동시성, 트래픽, 성능에 대한 엄격한 요구 사항이 있는 상황에서 자바의 성능이 충분하지 않을 수 있습니다.

환베이가 APISIX를 선택한 이유

수허 그룹은 비즈니스에서 기업과 개인을 위한 효율적이고 지능적인 서비스를 제공하는 금융 기술 플랫폼입니다. 환베이, EnjoyPay 등의 제품이 있습니다. 환베이는 여러 소비 시장을 위한 할부 서비스를 제공하는 플랫폼입니다. 환베이는 라이선스를 가진 금융 기관과 협력하여 개인 대출 서비스와 스타트업 대출 자금을 제공합니다. 환베이는 비즈니스에서 항상 자바 기술 스택을 사용하여 제품을 개발해 왔습니다.

Spring Cloud Gateway는 Spring Cloud 생태계에서 마이크로서비스를 더 잘 관리하기 위한 게이트웨이입니다. Spring Cloud Gateway는 자바를 주요 개발 언어로 사용하는 기업들에게 훌륭한 API 게이트웨이입니다. 그러나 최근 API 게이트웨이 업그레이드에서 환베이는 오랫동안 사용해 온 Spring Cloud Gateway를 버리고 Apache APISIX를 사용하기 시작했습니다.

Spring Cloud Gateway와 APISIX의 아키텍처 차이

환베이는 APISIX를 도입하기 전에 세 가지 다른 API 게이트웨이 시스템을 사용했습니다. 환베이는 운영 및 출구 시스템의 게이트웨이로 Spring Cloud Gateway를 사용했고, 비즈니스 시스템의 게이트웨이로 OpenResty를 사용했습니다.

환베이는 초기에 Spring Cloud Gateway를 운영 및 출구 시스템의 게이트웨이로 사용한 이유는 Spring Cloud Gateway가 방대한 생태계와 쉽게 배포 및 유지 관리할 수 있는 분산 개발 시스템을 가지고 있기 때문입니다. 비즈니스 기반이 구축되었을 때, 환베이는 비즈니스 모델을 빠르게 구축하기 위해 Spring Cloud가 제공하는 모든 서비스를 사용했습니다.

비즈니스가 발전함에 따라, 원래 아키텍처에서 게이트웨이가 메모리 오버플로우, 높은 CPU 사용률 등의 안정성 문제를 겪기 시작했습니다. 따라서 환베이는 게이트웨이 성능을 개선하고 여러 게이트웨이를 통합적으로 관리하기 위해 Apache APISIX를 아키텍처의 유일한 게이트웨이로 사용했습니다.

새로운 게이트웨이 프레임워크에서, 게이트웨이는 서비스 발견을 통해 요청 트래픽을 비즈니스 시스템으로 직접 전달합니다. 그러나 백엔드 애플리케이션이 서비스 발견을 지원하지 않거나 Consul에 건강한 Pod가 없는 경우, 시스템은 트래픽을 이전의 인트라넷 K8s Ingress로 리디렉션합니다.

APISIX의 실제 적용

환베이는 내부적으로 여러 게이트웨이 프레임워크를 가지고 있기 때문에 Apache APISIX를 직접 사용할 수 없어 실제 비즈니스 시나리오에서 APISIX 구성을 수정해야 했습니다.

APISIX 빌드 및 배포

내부 개발 중에, 환베이는 APISIX 게이트웨이의 소스 코드와 사용자 정의 코드를 다른 경로에 배치하고 독립적으로 협력하고 반복할 수 있도록 했습니다. 환베이는 게이트웨이를 배포하기 위해 Docker 이미지를 사용했습니다. 먼저, APISIX의 특정 버전을 기반으로 기본 이미지를 생성한 다음, 사용자 정의 코드를 사용하여 새로운 이미지로 래핑했습니다.

사용자 정의 코드의 래핑은 lua_package_path를 사용하여 코드 디렉토리를 지정하지 않고, 대신 소스 코드 디렉토리 아래의 기본 이미지 apisix를 직접 덮어썼습니다. 동일한 이름의 파일이 있는 경우입니다. Dockerfile은 아래와 같습니다:

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

APISIX 로그는 로컬에 저장됩니다(Syslog 또는 다른 플러그인을 통해 수집 가능). NGINX의 구성 템플릿을 수정하고 사용된 프로필을 확인하여 로그를 로컬에 저장할지 또는 Syslog를 통해 FLUENTD에 저장할지 결정할 수 있습니다. 또한 이미지를 빌드할 때 FLUENTD_HOST 변수를 교체해야 합니다:

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

NGINX 구성 템플릿에서, 환베이는 로그 저장뿐만 아니라 ENV 환경 변수와 lua_shared_dicts 구성을 루프에 추가하고 일부 NGINX 최적화 매개변수를 수정했습니다.

환베이는 다양한 비즈니스 요구에 따라 트래픽을 분리하고 유사한 기능을 가진 여러 게이트웨이를 생성합니다. 따라서 환베이는 내부적으로 "단일 소스 코드지만 여러 게이트웨이 애플리케이션" 계획을 사용합니다. 먼저, 환베이는 각 게이트웨이의 config-xxx.yaml 파일을 프로필 기능을 사용하여 구성한 다음, DevOps 플랫폼을 통해 이미지를 빌드할 때 애플리케이션 이름을 기반으로 다른 게이트웨이의 Docker 이미지를 구축할 수 있습니다.

기업 수준의 사용자 정의 플러그인

내부적으로 운영 시스템을 방문할 때, 시스템은 많은 백엔드 API를 호출하여 데이터를 가져오며, 이러한 API는 API 게이트웨이 구성의 화이트리스트에 포함되어야 합니다. 권한 시스템은 관련 API 목록을 유지해야 합니다. 운영 시스템의 각 로그인 사용자 역할에 따라 페이지가 다른 범위의 API를 제공하기 때문입니다. 페이지에서 새로운 API 호출이 있을 때마다, 개발자는 게이트웨이와 권한 시스템에서 두 번 구성해야 하며, 이는 중복되고 반복적입니다.

이를 달성하기 위해, 환베이는 게이트웨이 구성과 권한 시스템 구성 사이의 장벽을 제거하고 권한 시스템의 입구만 유지합니다. 게이트웨이 구성 관리 시스템은 주기적으로 권한 API를 가져온 다음 게이트웨이의 API 화이트리스트 구성으로 전환합니다. 이 행동은 불필요한 사용자 구성 작업을 생략하고 권한 시스템이 권한 제어를 할 수 있도록 도와줍니다. 또한, 운영 페이지에서 호출된 백엔드 API가 권한 시스템 구성에 존재하는지 보장합니다.

비즈니스 시나리오에서는 항상 네이티브 플러그인이 만족시킬 수 없는 요구 사항이 있으며, 이는 사용자 정의 개발이 필요합니다. APISIX는 네이티브 플러그인을 쉽게 사용자 정의할 수 있는 많은 도구를 제공합니다. 다음 표는 환베이 내부에서 APISIX를 기반으로 개발된 일부 사용자 정의 플러그인을 나열합니다:

게이트웨이 카나리 릴리스

이전에 환베이는 K8s 컨테이너로 OpenShift를 사용했으며(현재는 ACK 클러스터로 업그레이드됨), Ingress는 Haproxy로 구축되었습니다.

공용 네트워크 K8s Ingress의 Haproxy가 단일 도메인의 트래픽을 두 개의 다른 Namespace의 경로로 분할할 수 없기 때문에, 우리는 새로운 게이트웨이를 이전 게이트웨이와 동일한 Namespace에 배포하는 것을 고려해야 합니다. 즉, 각 도메인의 경로에는 여러 서비스가 있으며, 총 트래픽의 다른 부분을 할당하여 새 게이트웨이와 이전 게이트웨이의 트래픽을 제어할 수 있습니다.

실제 구현 흐름은 아래와 같습니다. 이전 게이트웨이의 Namespace 아래에 새 게이트웨이를 배포하기 위해 그룹 c와 d를 추가하고, 새 게이트웨이와 이전 게이트웨이의 트래픽 비율을 제어할 수 있습니다.

자바와 관련된 게이트웨이 요소

많은 자바 개발자들은 마이크로서비스 아키텍처에서 Spring Cloud를 선택합니다. Spring Cloud는 자바를 완벽하게 지원하며 소스 코드에 클래스 라이브러리를 포함시키기 때문입니다. 그러나 실제로 업그레이드가 어려운 상황이 발생합니다. 예를 들어, 팀이 여러 클래스 라이브러리를 유지해야 하고, 10개의 다른 언어와 10개의 다른 버전이 있다면, 이 팀은 100개의 다른 클래스 라이브러리를 유지해야 합니다.

현재, 우리는 프록시(API 게이트웨이)를 사용하여 다중 버전 및 다중 언어 문제를 쉽게 해결할 수 있습니다. 그렇다면 자바 기술 스택을 사용하는 기업들이 APISIX를 API 게이트웨이로 선택하는 것의 이점은 무엇일까요? 우리는 환베이의 실제 경험을 바탕으로 두 가지 측면에서 결론을 내렸습니다.

기업을 위한

1. 뛰어난 기능성 및 성능

APISIX의 QPS는 환베이가 4코어 가상 머신을 사용하고 플러그인 없이 APISIX를 스트레스 테스트할 경우 80k에 도달할 수 있습니다. 또한, APISIX는 소비자 트래픽을 수신할 때 Spring Cloud Gateway의 성능 문제를 완벽하게 해결하며, 이전 게이트웨이 대비 생산 환경에서 성능이 30% 향상되었습니다.

그 외에도, APISIX는 실제 테스트에서 인증 및 식별, 관찰 가능성, 서비스 발견, 속도 제한, 4계층 및 7계층 트래픽 전송과 같은 모든 회사 요구 사항을 충족할 수 있습니다. 기능 확장 측면에서, APISIX는 70개 이상의 플러그인을 지원하며, 대부분의 비즈니스는 네이티브 플러그인을 사용할 수 있어 개발 작업을 크게 줄일 수 있습니다.

2. 비즈니스 비용 절감

APISIX를 사용하기 전에는, 기업은 성능 문제를 해결하기 위해 서버 수를 늘려야 했으며, 이는 하드웨어 비용을 크게 증가시켰습니다.

환베이는 비용을 계산한 결과, APISIX를 사용한 후 서버 비용이 약 60% 감소했다는 것을 발견했습니다. 또한, 기술 스택을 통합한 후, 비즈니스는 APISIX 네이티브 아키텍처를 기반으로 다양한 기능을 빠르게 확장할 수 있으며, 개발 비용을 줄이고 제품 출시 시간을 단축할 수 있습니다.

개발자를 위한

1. 비즈니스 요구 사항 충족

비즈니스에서 사용되는 모든 소프트웨어 또는 기술은 요구 사항을 충족해야 합니다. 그러나 실제 테스트 및 연구 결과, APISIX는 더 나은 안정성, 관찰 가능성, 확장성을 가지고 있습니다.

소프트웨어는 비즈니스를 서비스하기 위한 것입니다. 따라서, 비즈니스 요구 사항이 회사가 리소스를 절약할 수 있도록 도와준다면, 이 회사가 어떤 기술 스택을 사용하든, 회사와 일치하는 구성 요소를 사용해야 합니다.

2. 유지 보수 비용 절감

이전에 사용한 OpenResty와 비교하여, APISIX는 학습 비용이 낮고 유지 보수가 더 쉽습니다. 동시에, APISIX의 풍부한 플러그인은 표준 기능의 배포 및 개발을 단순화하여 제품 출시 시간을 단축합니다.

또한, APISIX의 강력한 로그 및 동적 디버깅 기능은 비즈니스에서 실패 지점을 감지하여 오류를 빠르게 찾고 시간을 절약할 수 있도록 도와줍니다.

결론: 금융 산업 발전의 추세

거친 성장 단계에서, 유일하게 중요한 것은 효율성입니다. 따라서 디렉터는 익숙한 언어를 사용하여 시스템을 구축하고 비즈니스 모델을 더 빠르게 출시하기 위해 저수준 프레임워크 선택 시 다른 기술 스택을 선택할 것입니다. 다른 디렉터는 다른 기술 스택을 선택할 것이며, 이는 미래에 많은 문제를 일으킬 것입니다. 그러나 대부분의 활발한 금융 기업과 금융 서비스 회사는 동일한 기술적 문제에 직면할 것입니다: 다중 기술 스택 문제. 이 문제가 발생하면, 그들은 기술 스택을 하나로 통합해야 합니다.

회사 비즈니스가 정상 궤도에 오르면, 회사는 시스템을 수직적으로 분할할 때입니다. 회사는 정보 사일로 아키텍처를 프론트엔드, 미들엔드, 백엔드로 구성된 3계층 아키텍처로 전환해야 합니다. 그런 다음, 시스템이 안정적으로 운영되면, 회사는 저수준 구성 요소를 직접 구현할 때입니다.

시스템 구축의 최종 목표는 공유입니다. 시스템이 더 우수한 반복성을 가지고 있다면 유지 보수 비용이 더 낮습니다. 따라서, 비즈니스 운영이 안정화되면, 많은 회사들이 수직 분할 또는 저수준 기본 구성 요소를 구현하여 유지 보수 비용을 통제하기 시작합니다.

기업에게는 비용이 항상 가장 중요한 원칙입니다. 거친 성장 단계에서, 기업은 비즈니스를 가능한 한 빨리 출시하고 운영해야 합니다. 그러나 이 대규모 환경에서 예산 내에서 비용이 최우선 순위여야 합니다. 이 경우, 우리는 효율성과 비용 사이에서 선택해야 합니다. 따라서, 예산이 제한된 경우 기업은 최첨단 기술을 사용하지 않을 것입니다. 마찬가지로, 기술 직원은 기술 스택을 선택할 때 다음 질문을 고려하지 않을 것입니다: 이 새로운 기술이 팀에 어떤 영향을 미칠까요? 이 새로운 기술이 현재 인프라에 얼마나 많은 이점을 가져다 줄까요?

기술 직원은 이 새로운 기술의 비용만을 고려할 것입니다.