Tencent에서 Apache APISIX를 활용한 API Gateway 실습

API 게이트웨이란 무엇인가?

전통적인 아키텍처

API 게이트웨이와 통합하기 전에는 몇 가지 일반적인 기능을 재사용하는 방법이 있었습니다. 예를 들어:

• 보안: 인증, 권한 부여, 재생 방지, 변조 방지, DDoS 방어 등
• 신뢰성: 서비스 저하, 서킷 브레이커, 트래픽 제한 등

전통적인 아키텍처에서는 이러한 경우를 처리하기 위해 가장 일반적인 방법은 이를 서비스 프레임워크에 포함시키고 AOP를 통해 구현하는 것이었습니다. 이는 다음과 같은 아키텍처 다이어그램과 유사합니다:

전통적인 아키텍처 다이어그램에는 다음과 같은 모듈이 있습니다.

• 백엔드: 백엔드 서비스
• AOP: 프레임워크가 제공하는 AOP 계층
• SD: 서비스 센터, 내부 서비스 탐색에 사용됩니다. 클라우드 네이티브 기술에서는 종종 Service로 이 컴포넌트를 대체합니다.
• LB: 로드 밸런서, 외부 트래픽의 진입점으로 네트워크 경계에서 사용됩니다.

이러한 아키텍처는 초기 설계에서 널리 사용되었으며, Dubbo, SpringCloud 등과 같은 포괄적인 서비스 프레임워크를 탄생시켰습니다. 그리고 대부분이 비슷한 기능을 많이 가지고 있다는 것을 알 수 있습니다.

이 아키텍처의 장점은 상하위 관계가 더 명확하고 네트워크 전송에서 한 번의 전달을 줄인다는 것입니다. 그러나 단점도 명확합니다:

• 표준 기능이 비즈니스 서비스 업데이트를 강제함: 코드 참조를 사용하기 때문에 기능을 적용하려면 비즈니스 서비스를 다시 컴파일해야 합니다. 롤링 릴리즈를 달성하지 못한 팀은 비즈니스가 한가한 시간에 릴리즈를 해야 합니다.
• 버전 관리가 어려움: 모든 서비스를 매번 최신 버전으로 업그레이드할 수 없기 때문에 시간이 지나면 다양한 서비스의 성능이 일관되지 않을 수 있습니다.

왜 이러한 동일한 기능을 독립적인 서비스에 넣어 별도로 업그레이드하거나 유지보수할 수 없을까요?

게이트웨이 모드

전통적인 아키텍처와 비교하여 백엔드 서비스와 LB 사이에 추가된 컴포넌트가 있습니다: 게이트웨이.

게이트웨이는 일반적으로 인증, 트래픽 관리 등과 같은 많은 표준 및 재사용 가능한 기능을 포함합니다. 다음과 같은 이점을 얻을 수 있습니다:

• 게이트웨이는 시스템의 종속 컴포넌트이며, 더 나은 유지보수 경험을 제공합니다.
• 게이트웨이는 언어에 독립적입니다.

그러나 게이트웨이 모드에도 단점이 있습니다:

• 트래픽을 먼저 게이트웨이로 프록시하기 때문에 한 번 더 전달이 발생하고 지연 시간이 높아집니다. 이는 문제 해결의 복잡성을 높입니다.
• 게이트웨이가 제대로 작동하지 않으면 전체 시스템의 병목 현상이 될 수 있습니다.

게이트웨이 모델의 이점과 단점을 어떻게 균형 있게 조정할지는 기술 팀에게 도전 과제입니다. Tencent OTeam이 Apache APISIX와 어떻게 협력하는지 살펴보겠습니다.

소개

OTeam

Tencent의 OTeam은 여러 팀으로 구성된 그룹이며, 각 팀은 하나 이상의 기술 제품을 유지 관리합니다. 그들의 목표는 내부 시스템을 위한 안정적이지만 강력한 중간 플랫폼을 구축하는 것입니다. 그 중 하나의 OTeam은 Tencent 내부의 Apache APISIX 커스터마이징 배포를 지원합니다.

회사 내부의 중복된 기능을 통합하고 기술 중간층을 하향시키기 위해 Tencent는 동일한 성격의 여러 기술 제품을 동일한 Oteam에 넣고, 유지보수 인력을 통합하여 함께 작업하게 함으로써 점차 하나의 큰 포괄적인 제품으로 통합하려고 합니다. 이것이 Oteam입니다.

일부 Oteam은 그 아래에 수십 개의 제품을 가지고 있는 반면, 다른 Oteam은 단 하나의 제품만 가지고 있습니다. 예를 들어, Apache APISIX가 위치한 Oteam은 단 하나의 제품, Apache APISIX만을 가지고 있습니다. 이 Oteam의 원래 목적은 Tencent 내부에서 Apache APISIX의 커스터마이징 기능을 유지 관리하는 것입니다.

Apache APISIX

Apache APISIX는 Apache Software Foundation의 Top-Level Project이며, 다음은 몇 가지 주요 사항입니다:

• Apache APISIX는 OpenResty 기반의 클라우드 네이티브, 동적 API 게이트웨이로, Kong보다 더 높은 라우팅 성능을 제공합니다.
• Apache APISIX는 로드 밸런싱, 동적 업스트림, 카나리 릴리즈, 서킷 브레이커, 인증, 관찰 가능성 등과 같은 풍부한 트래픽 관리 기능을 제공합니다.
• Apache APISIX는 전통적인 남북 트래픽뿐만 아니라 서비스 간의 동서 트래픽도 잘 처리합니다. 또한 k8s ingress 컨트롤러로도 사용할 수 있습니다.
• Apache APISIX는 기본적으로 ETCD를 구성 센터로 사용하며, 몇 초 내에 구성을 업데이트할 수 있습니다.
• Apache APISIX는 Apache Software Foundation에서 졸업했으며, 단 몇 개월 만에 이를 달성했습니다.

Tencent OTeam의 운영 전략

위 다이어그램은 OTeam이 Apache APISIX 커뮤니티와 어떻게 협력하는지 보여줍니다:

• 사용자는 GitHub Issue를 통해 피드백이나 요구 사항을 제공합니다.
• OTeam 멤버들은 주간 회의에서 해결책을 논의하거나 Issue에 직접 답변합니다.
• 논의에 따라 기능을 구현하거나 버그를 수정합니다.
• 코드 리뷰와 CI 검사를 거친 후, 필요한 경우 릴리즈합니다.

이 과정은 다른 오픈 소스 프로젝트와 유사합니다. 다음은 몇 가지 주요 사항입니다:

• Issue를 해결한 후, Tencent 엔지니어들은 해당 문제가 커뮤니티에서도 공통적인 문제인지 판단합니다. 그렇다면 커뮤니티에 PR을 제출합니다.
• Tencent OTeam은 Apache APISIX의 새로운 기능을 정기적으로 검토하여 안정적인지, 그리고 Tencent의 고통 포인트인지 판단합니다. 그렇다면 관련 코드를 선택합니다.

처음에는 OTeam이 Apache APISIX와 12시간마다 코드를 동기화하여 Apache APISIX를 빠르게 따라갈 수 있었지만, 이 접근 방식은 몇 가지 문제를 야기했습니다:

• Apache APISIX와 코드를 동기화한 후, 규정이 올바른지 확인할 수 있었지만 코드가 안정적인지는 보장할 수 없었습니다. 동시성 사례에서 간헐적인 오류가 발생했습니다.
• 병합된 코드는 때때로 여러 PR 상위 충돌을 논리적으로 일으킬 수 있지만, Apache APISIX와 OTeam의 CI는 이를 감지할 수 없습니다. PR을 마스터 브랜치에 병합할 때만 문제가 발생했음을 알 수 있었습니다.

이러한 이유로, OTeam은 이제 내부 검토 후 필요한 기능에 대한 코드를 선택하는 방식으로 전환하고 있습니다.

OTeam 동향

2021년 5월 기준, OTeam은 Tencent 내부의 10개 이상의 팀에 Apache APISIX를 도입했으며, 하루 최대 비즈니스 요청 트래픽이 10억 건을 초과합니다. 동시에, OTeam은 Apache APISIX를 위해 서비스 탐색, RPC 프로토콜 변환, 모니터링 플랫폼 연결 등 10개 이상의 기능을 개발했습니다.

동시에, OTeam은 Apache APISIX 커뮤니티에 몇 가지 표준 기능을 기여했습니다. 현재 OTeam 팀의 두 멤버는 Apache APISIX의 PMC이며, OTeam은 커뮤니티에 50개 이상의 PR을 기여했습니다. 우리는 OTeam이 앞으로도 Apache APISIX 커뮤니티와 계속 협력할 것이라고 믿습니다.

OTeam 내부 기능

내부 고통 포인트

OTeam의 주요 책임은 Tencent를 위한 Apache APISIX의 기능을 유지 관리하는 것입니다. OTeam이 어떤 고통 포인트를 만났는지 살펴보겠습니다.

• RPC 프레임워크가 프론트엔드에 불친절함: Tencent 내부에는 TARS 프레임워크를 사용하는 많은 레거시 프로젝트가 있습니다. 이는 TRPC처럼 HTTP 프로토콜을 직접 지원하지 않으며, RPC 프레임워크의 가장 전통적인 TCP 프로토콜만 지원하며, 전송 내용은 특정 바이너리 프로토콜을 사용합니다. 이러한 인터페이스를 프론트엔드 친화적인 HTTP + JSON 형태로 변환하기 위해 중간 서비스를 유지해야 합니다.
• 서비스 센터의 다양성: Tencent 내부 서비스에는 CL5, L5, Polaris 등과 같은 많은 서비스 센터가 있습니다. 비록 동일한 서비스 센터를 점차 사용할 예정이지만, 이 긴 기간 동안 여러 서비스 센터를 동시에 사용할 것입니다. 초기 Apache APISIX는 이를 지원하지 않았습니다.
• 알람: 게이트웨이로서 알람은 주목해야 할 방향이 아니지만, 기본 컴포넌트로서 알람은 팀에게 필수적인 컴포넌트여야 합니다. 알람 문제를 어떻게 해결할지도 고통 포인트입니다.
• 보안: Tencent는 많은 트래픽과 보안 요구 사항을 가지고 있습니다. 많은 toC 제품이 OTeam을 사용하고 있으며, 네트워크로부터의 사용자 오용과 공격에 직면해야 합니다. 가장 전형적인 사례는 DDos, 재생, 요청 변조 등입니다. 이러한 문제를 게이트웨이 계층에서 해결할 수 있을까요?

문제 해결

위 다이어그램은 Tencent 내부의 실제 사례를 단순화한 것입니다. 우리는 방금 제기된 몇 가지 문제가 OTeam에서 해결되었음을 볼 수 있습니다:

• 프로토콜 변환: Apache APISIX를 기반으로, OTeam은 TRPC와 TARS 프로토콜 변환을 달성했습니다. HTTP를 수행하지 않는 레거시 서비스는 중간 서비스를 작성하지 않고도 게이트웨이의 변환 플러그인을 사용하여 HTTP와 RPC 전송 요구 사항을 달성할 수 있습니다.
• 다중 서비스 센터: 우리는 이 기능을 커뮤니티에 기여했습니다. 모니터링 플랫폼에 보고: Tencent OTeam은 플러그인을 사용하여 모니터링 플랫폼과 연결합니다. 사용자는 몇 가지 구성을 수행하면 시스템이 자동으로 메트릭, 로그를 보고합니다. 또한 사용자는 모니터링 플랫폼에서 알람 정책을 구성할 수 있습니다.
• 재생 방지 및 변조 방지: OTeam은 재생 방지 및 변조 방지 플러그인을 구현하여 이러한 기능이 필요한 외부 비즈니스가 즉시 사용할 수 있도록 하여 API 보안을 보호합니다.

우리는 이러한 예제가 Apache APISIX 사용 시나리오를 더 탐구하고 더 나은 플랫폼으로 사용하는 데 도움이 되기를 바랍니다. 예를 들어, 누군가는 게이트웨이를 사용하여 Tencent Cloud 정책에 따라 필수적인 일부 API 사양을 구현했습니다.

요약

OTeam은 비즈니스 팀이 그들의 고통 포인트를 해결하도록 도왔으며, Tencent 내부에서 Apache APISIX의 기능을 지속적으로 개선하고 커뮤니티의 발전과 함께 나아갔습니다.

만약 당신의 팀에 게이트웨이가 없다면, Apache APISIX에 대해 더 알아보고 Apache APISIX 커뮤니티에 참여하는 것을 환영합니다.