Web3를 위한 API Gateway: APISIX가 Hyperchain에 힘을 실어주는 방법

August 9, 2021

Case Study

개요

세계적인 기업용 컨소시엄 블록체인 인프라 공급자이자 솔루션 제공업체인 Hyperchain Technologies는 혁신적인 인프라를 구축하고 사회의 디지털 발전을 지원하기 위해 노력하고 있습니다. 빠르게 성장하는 과정에서 Hyperchain은 Hyperchain 블록체인 플랫폼을 구축하면서 다음과 같은 문제들을 직면했습니다:

  • 표준화된 트래픽 관리가 없어 시스템 붕괴 위험이 있음
  • 불완전한 보안 제어 및 인증 관리
  • 불편한 권한 제어
  • 공용 네트워크 IP 주소에 대한 높은 비용
  • 불안정한 블록체인 노드: 단일 노드가 공격에 취약함
  • 다양한 프로토콜에 대한 통합 관리 부재

Hyperchain은 Kong과 NGINX를 시도했지만, 불행히도 Hyperchain의 비즈니스 시나리오를 충족시키지 못했습니다. 그러나 Apache APISIX를 도입한 후, 위에서 언급한 모든 문제들이 해결되어 Hyperchain 블록체인 플랫폼에 무한한 활력을 불어넣었습니다.

Hyperchain 블록체인 플랫폼 소개

Hyperchain 블록체인 플랫폼은 블록체인 프레임워크를 클라우드 컴퓨팅 플랫폼에 내장하여 클라우드 서비스 인프라의 배포 및 관리 이점을 활용합니다. 이는 개발자들에게 편리하고 고성능의 블록체인 생태계와 관련 지원 서비스를 제공할 수 있는 오픈 블록체인 플랫폼이며, web3에서의 비즈니스 확장 및 운영도 지원합니다.

Hyperchain 블록체인 플랫폼은 블록체인 네트워크를 빠르고 유연하게 구축할 수 있습니다. 이 플랫폼을 통해 기업은 블록체인 비즈니스를 통합적으로 관리할 수 있습니다. 예를 들어, 통합 개발 환경에서 계약을 체결한 후 생성된 블록체인 네트워크에 배포할 수 있습니다. 상위 서비스 모듈은 블록체인 관련 계약을 호출하여 비즈니스 프로세스를 계속할 수 있습니다.

체인 내에 수십 개에서 수천 개에 이르는 많은 노드가 존재하기 때문에 플랫폼의 지원 없이는 체인의 운영을 모니터링하고 유지하는 것이 어렵습니다. Hyperchain 블록체인 플랫폼을 사용하면 사용자는 비용을 절약할 뿐만 아니라 블록체인을 더 편리하게 관리하고 전체 시스템의 보안을 강화할 수 있습니다.

Hyperchain을 예로 들어, 블록체인 기업들이 많은 API 게이트웨이 중에서 Apache APISIX를 선택해야 하는 이유와 방법을 알아보겠습니다. 아래에서는 APISIX의 Hyperchain 블록체인 플랫폼 및 블록체인 노드에서의 적용 사례를 분석하겠습니다.

Hyperchain 블록체인 플랫폼에서의 APISIX 적용

아래는 Hyperchain 블록체인 플랫폼에서 APISIX의 애플리케이션 상호작용 다이어그램입니다. 백엔드 서비스는 비즈니스 특성에 따라 etcd에 서비스 정보를 등록한 후, 라우트 등록 모듈을 통해 APISIX에 서비스를 등록합니다.

APISIX는 시스템 내부의 마이크로서비스에 대한 통합 진입점으로 작동합니다. 외부 요청은 먼저 APISIX로 전송되고, 인증을 통과한 후 API를 통해 액세스 계층에 접근하며, 이후 RPC(원격 프로시저 호출)를 통해 핵심 서비스에 접근합니다.

Hyperchain 애플리케이션 상호작용 다이어그램

라우트 전달

때로는 동일한 도메인 이름 아래에 API를 노출해야 할 경우가 있습니다. 이 경우 동일한 서비스의 API 경로에 /baas-core 또는 /baas-other와 같은 접두사를 추가할 수 있습니다. 클라이언트가 이러한 API를 요청할 때, API 게이트웨이는 추가된 접두사를 제거한 후 백엔드 서비스로 요청을 전달해야 합니다. APISIX의 proxy-rewrite 플러그인은 이러한 경우를 편리하게 처리할 수 있도록 도와줍니다.

예를 들어: 방문 시: http://apisix:8080/baas-{service}/api/v1/… 요청은 http://{service}/api/v1/…로 전달될 수 있습니다. 정규 표현식 작성: ^/baas-core/(.*)$,/$1

proxy-rewrite 플러그인 편집

트래픽 제한 관리

사용자는 Hyperchain뿐만 아니라 IBM 데이터 Fabric, Baidu XuperChain 등과 같은 컨소시엄 블록체인을 필요에 따라 선택할 수 있습니다. 따라서 Hyperchain은 시스템 내 모든 컨소시엄 블록체인의 라이프사이클 관리를 수행해야 합니다.

컨소시엄 체인을 생성할 때, Hyperchain은 블록체인 플랫폼에 하드 코드를 작성하고 플러그형 드라이브 컴포넌트를 블록체인 플랫폼에 업로드하여 호출하여 컨소시엄 체인을 생성합니다. 일부 프라이빗 배포 사례에서는 플러그형 드라이브 컴포넌트가 빠르게 지원될 수 있습니다.

드라이브 컴포넌트에 대한 모든 호출은 제한이 필요한 프로세스이며, 특히 호출 횟수가 많을 때 더욱 그렇습니다. 따라서 APISIX의 limit-req 플러그인은 플랫폼의 트래픽 입출력을 제한하여 안정성을 보장하는 데 유용합니다.

limit-req 플러그인은 속도 및 버스트에 대한 사용자 정의 구성을 허용합니다.

limit-req 플러그인 모델

보안 제어 및 권한 관리

APISIX와 협력하기 위해 Hyperchain은 프라이빗 배포 환경을 위한 플러그인을 개발했습니다. 파티 A는 종종 자체 인증 서비스 또는 서비스 계정 시스템을 사용하려고 합니다. 프론트엔드 트래픽이 웹사이트를 방문할 때, 먼저 Access-auth 플러그인을 통과해야 하며, 인증을 통과한 후에만 백엔드 BFF(Backend for Frontend)에 접근할 수 있습니다.

인증 프로세스 다이어그램

Restful 표준 사양의 세 가지 주요 요소(인증 정보, Restful 경로, GET, POST, PUT, DELETE, PATCH 등의 HTTP 동사)에 따라 계정-역할-권한 인증이 수행됩니다. 인증이 통과되면 헤더에 사용자 정보가 반환되고, 그렇지 않으면 403이 반환됩니다.

API 인증 경로

핫 리로딩

APISIX는 내부적으로 개발된 플러그인의 핫 리로딩을 제공합니다. 이를 통해 개발 시간을 절약하고 사용자는 플러그인 러너를 재시작하지 않고도 코드의 일부를 변경할 수 있습니다. 이렇게 하면 개발자는 백엔드에서 인터페이스를 조정하여 즉시 적용할 수 있어 온라인 릴리스에 편리하고 친화적입니다.

Kong을 사용하지 않는 이유

Hyperchain은 이전에 Kong을 사용했지만 결국 Apache APISIX로 대체했습니다. 주된 이유는 다음과 같습니다:

  • 높은 배포 및 유지 관리 비용

    Kong 클러스터는 Postgresql 데이터베이스와 협력해야 하며, 고가용성을 위해 특정 데이터베이스 관리자가 필요합니다. Postgresql 데이터베이스의 클러스터 배포는 구현이 상대적으로 어렵고, 후속 운영 및 유지 관리 비용을 증가시킵니다.

  • 시스템 복잡성 및 장애율 증가

    Hyperchain 블록체인 플랫폼은 MySQL 데이터베이스를 사용하므로 Kong을 도입하면 시스템 내에 두 개의 관계형 데이터베이스가 존재하게 되어 시스템이 더 복잡해집니다. 또한 두 데이터베이스 간의 호환성을 개선하는 과정에서 장애율이 증가합니다.

블록체인 노드에서의 APISIX 적용

Hyperchain 블록체인 다이어그램

공용 네트워크 IP 주소 비용 절감

사용자는 Hyperchain 블록체인 플랫폼을 통해 블록체인을 구매합니다. 그런 다음 상위 비즈니스 및 개발자 클라이언트가 노드에 연결할 수 있습니다. 서비스는 하나 이상의 노드에 연결될 수 있으며, 사용자는 하나 이상의 노드에 접근할 수 있습니다. 이로 인해 거의 모든 노드가 방문되며, 단일 노드의 방문 압력이 증가합니다.

일부 프라이빗 배포 환경에서는 상대적으로 쉽게 처리할 수 있습니다. 그러나 인터넷 사용자를 대상으로 하는 시스템의 경우 너무 많은 노드와 공용 네트워크 IP가 필요합니다. 4MB 트래픽의 공용 네트워크 IP 가격은 월 200CNY에 달할 수 있습니다. Hyperchain 플랫폼에는 수천 개의 노드가 있어 높은 공용 IP 비용이 발생합니다.

APISIX는 모든 방문 요청을 관리하고 해당 블록체인 노드로 트래픽을 분배합니다. 이를 통해 Hyperchain은 높은 비용을 절감했습니다.

APISIX를 사용한 Hyperchain의 모드

편리한 권한 제어

Hyperchain 블록체인 플랫폼에는 다양한 블록체인이 있으며, 각 체인에는 복잡한 RBAC 권한 제어가 있습니다. 따라서 클라이언트 측에 TLS 인증서와 같은 다양한 종류의 인증서를 추가해야 하며, 이는 사용자에게도 혼란을 줍니다.

현재 APISIX의 key-auth 플러그인을 사용하여 이 문제를 효율적으로 해결할 수 있습니다. 인증된 사용자는 권한 구성을 걱정하지 않고 블록체인에 직접 접근할 수 있으며, APISIX는 기본 체인을 통합합니다.

클러스터링으로 노드 안정성 향상

위에서 언급한 바와 같이, 노드는 자주 방문됩니다. 대부분의 은행 사용자에게는 높은 동시성이 존재하며, TPS(초당 트랜잭션 수)는 40,000-50,000회에 달할 수 있습니다.

블록체인의 단일 노드는 취약한 것으로 밝혀졌는데, 각 트랜잭션이 방문된 노드에 영향을 미치기 때문입니다.

Hyperchain은 K8s에 Apache APISIX를 배포하고 Horizontal Pod Autoscaler를 사용했습니다. APISIX는 동적 확장성이 뛰어난 etcd를 사용하므로 단일 지점 트래픽 영향을 효과적으로 해결할 수 있습니다.

다양한 프로토콜 지원

Hyperchain 블록체인 플랫폼의 이종 체인 프로토콜은 HTTP 프로토콜, Websocket 프로토콜, gRPC 프로토콜, TCP 프로토콜, UDP 프로토콜 등 다양합니다.

APISIX는 다양한 프로토콜을 지원하여 서로 다른 블록체인의 기본 계층에 유연하게 적응하므로 개발 비용을 절감할 수 있습니다.

NGINX를 사용하지 않는 이유

Hyperchain은 NGINX를 사용하여 문제를 해결할 수 있을 것 같았지만, 시도 후 포기했습니다. 그 이유는 다음과 같습니다:

  • 동적 확장에 부적합

    Hyperchain은 블록체인 플랫폼에서 노드를 자주 추가 및 삭제해야 하는데, 이는 재시작 후에만 적용되므로 개발자에게 불편합니다. 또한 개발자는 NGINX의 conf 파일에 플러그인을 위한 복잡한 규칙 코드를 작성해야 합니다.

  • 클러스터링이 어려움

    NGINX는 클러스터를 지원하지 않아 사용자에게 상대적으로 복잡하고 불친절합니다.

  • TCP 및 UDP 직접 지원 부재

    NGINX는 7계층 프로토콜만 프록시할 수 있으며, 4계층 프로토콜을 직접 지원하지 않습니다. 또한 모듈이 기본적으로 컴파일되지 않아 추가 처리가 필요합니다.

  • 대시보드 부재

    NGINX에는 시각화된 인터페이스가 없어 개발자와 운영자가 많은 노드를 관리하기 어렵습니다.

요약

위에서 언급한 내용을 통해 Apache APISIX는 블록체인 영역에서 적용할 수 있는 동적 API 게이트웨이라는 것을 알 수 있습니다. 또한 Apache APISIX는 로드 밸런싱, 동적 업스트림, 카나리 릴리스, 서킷 브레이킹, 인증, 관찰 가능성 등과 같은 풍부한 트래픽 관리 기능을 제공합니다.

APISIX가 더 많은 블록체인 기업들이 새로운 발전 단계로 나아갈 수 있도록 지원하기를 바랍니다. Apache APISIX에 대해 더 알아보려면 https://api7.ai/contact로 문의하십시오.

Tags:
APISIX Basics
Web3
Best API Gateway