APISIX가 Beeto 소셜 미디어 플랫폼의 중동 지역 로컬라이즈드 배포를 어떻게 지원하는지

개요

도전 과제

• 모놀리식 서비스 아키텍처로 인해 유지보수 및 운영 비용이 높음
• 복잡한 아키텍처 배포 및 서비스 호출, 다양한 기술 스택

결과

• 북-남 및 동-서 트래픽 통합으로 자원 및 인력 비용 절감, 동적 및 통합 관리 가능
• 배포 아키텍처 단순화로 게이트웨이와 사용자 간 상호작용 감소
• APISIX의 다양한 확장 플러그인으로 Beeto가 서비스의 권한 검증, 라우트 분배, 건강 상태 확인 기능을 효율적으로 관리
• APISIX를 통해 Beeto가 서비스를 동적으로 시작 및 마이그레이션할 수 있어 개발자 친화적

Beeto 소개

중동 시장을 위한 Beeto는 아랍어 소셜 미디어 플랫폼으로, 현지화된 제품 설계와 기술 아키텍처를 갖추고 있습니다. 이 플랫폼은 사우디 아라비아 iOS 앱 스토어의 Top List에서 4위를 차지하며, 소셜 플랫폼 거대 기업인 Facebook을 앞지른 적이 있습니다.

중동의 인터넷 개발은 성숙한 상태이며, 소셜 네트워크의 활성 사용자 비율이 매우 높습니다. 특히 사우디 아라비아에서는 2019년에 90%의 사람들이 인터넷을 사용했습니다. 2020년 사우디 아라비아의 활성 사용자 비율은 9위를 기록했습니다.

인터넷 시장의 성숙도로 인해 WhatsApp, YouTube, Instagram과 같은 인기 있는 국제 소셜 소프트웨어가 있습니다. 그러나 Twitter와 같은 현지화된 소셜 소프트웨어는 없습니다. 따라서 중동의 "성숙한 인터넷이지만 현지화가 부족한" 상황을 목표로 Beeto는 현지화된 제품 개발을 시작했습니다.

Beeto에게 중요한 현지화

Twitter와 Facebook과 같은 피드 스트림 애플리케이션을 벤치마크로 삼아, Beeto는 중동에서 비즈니스 아키텍처를 배포하기 위한 상대적으로 완전한 프레임워크를 계획했습니다. 예를 들어, 소셜 속성의 관계 상호작용, 콘텐츠 소비(텍스트, 비디오 라이브 방송, 현지 광고 등), 보상, 출금, 투표, 복권과 같은 다양한 비즈니스, 심지어 플랫폼 감독 및 콘텐츠 보안 검토 요구 사항을 충족시키기 위해 노력했습니다.

앞서 언급했듯이, 중동 시장의 인터넷 성숙도는 고품질 제품을 요구합니다. 따라서 Beeto의 첫 번째 버전의 비즈니스 아키텍처는 모든 주요 소셜 소프트웨어가 갖추어야 할 기능을 통합한 완전한 제품이었습니다. 한편, Beeto의 목표는 "현지화 기능"을 갖춘 중동 최대의 아랍어 소셜 플랫폼이자 최고의 아랍어 커뮤니티가 되는 것입니다. 이 목표를 실현하기 위해 Beeto는 아래와 같은 현지화 요구 사항을 분석했습니다.

Beeto 아키텍처 설계의 문제점

현지화는 비즈니스 수준에서 기존의 현지 소셜 요구 사항과 기술 수준에서의 현지화 운영(예: 서비스 배포 및 데이터 저장)을 포함합니다. Weibo나 Twitter에 익숙한 사람들은 이러한 거대한 정보 흐름 제품 뒤에 수십 또는 수백 개의 아키텍처 시스템이 협력해야 한다는 것을 알고 있을 것입니다. Beeto 아키텍처의 문제점은 다음과 같습니다.

모놀리식 서비스 아키텍처로 인한 높은 비용

Beeto의 서비스는 아래와 같이 8개 부분으로 나눌 수 있습니다.

이러한 비즈니스를 구현하려면 중동에서 현지화된 배포가 필요합니다. 각 비즈니스를 서비스별로 분할하면 각 서비스는 별도의 모놀리식 아키텍처입니다.

위의 모놀리식 아키텍처 다이어그램은 일반적인 배포 아키텍처를 보여줍니다. Beeto의 피드 스트리밍 서비스를 예로 들어보겠습니다. 사용자의 피드 스트림 탐색 요구를 실현하려면 공용 네트워크 접근, 즉 북-남 트래픽 접근을 지원해야 합니다. 동시에 피드 스트리밍 서비스는 토픽 비즈니스 형태로 내부 호출도 제공합니다. 즉, 동-서 트래픽 호출입니다.

따라서 전체 서비스는 외부 및 내부 호출 모드를 지원합니다. 7계층 로드 밸런싱 후 사용자 트래픽은 다른 서버로 분배되고, 다른 저장 리소스가 호출됩니다. 동-서 트래픽도 비슷합니다. 7계층 클러스터는 북-남 및 동-서 트래픽, 로드 밸런싱, 인증, 노드 모니터링을 처리합니다.

여러 비즈니스의 서비스가 결합되면 전체 아키텍처는 다음과 같습니다.

보시다시피, 서비스는 적응, 비즈니스, 기본 서비스 계층에 존재합니다. 이러한 각 서비스의 배포 아키텍처는 위에서 언급한 모놀리식 아키텍처 세부 사항을 가지고 있으므로, 그 사이에 여러 7계층 클러스터가 존재하며, 이는 매우 크고 복잡한 시스템 아키텍처입니다.

그러나 Beeto 제품은 스타트업 단계에 있으며 제품은 중동에서 출시되었지만, R&D 팀은 중국에 있기 때문에 서버 및 유지보수 비용이 많이 듭니다. 또한 비즈니스가 증가함에 따라 모놀리식 서비스의 수가 증가할 것이며, 이는 비용과 유지보수 작업을 모두 통제하기 어렵게 만듭니다.

여러 서비스 출시의 어려움

아키텍처 배포의 복잡성 외에도 클러스터 내 서비스 간 호출도 매우 복잡합니다.

북-남 트래픽은 다양한 서비스 풀로 분배되고, 동-서 트래픽도 다양한 서비스 간에 교차하며, 이러한 서비스 간의 호출 관계가 얽혀 있습니다.

또한 이러한 호출 관계는 서비스에 의해 유지되어야 하므로 호출 추적이 불명확하고 관리가 어렵습니다.

복잡한 호출 관계 외에도 각 서비스 간의 기술 스택 차이도 있습니다. 예를 들어, 호출 프로토콜에서 일부 서비스는 HTTP를 제공하고, 다른 서비스는 RPC를 제공합니다. 프로그래밍 언어 개발 측면에서는 Java, Go 및 기타 프로그래밍 언어가 혼합되어 있습니다.

이러한 다중 서비스 아키텍처 시스템은 현지에서 구현될 때 높은 배포 및 유지보수 비용 문제가 명확히 드러납니다. 또한 Beeto는 각 7계층 서비스 세트에 서버 비용을 투입해야 하며, 각 서비스의 트래픽 차이로 인해 트래픽이 불균형하게 분배되어 서버와 같은 리소스의 활용률이 낮고 리소스가 낭비됩니다.

Beeto가 비즈니스 업그레이드 및 반복에 더 집중했기 때문에 아키텍처는 유지보수 및 통합 관리를 용이하게 하기 위해 설계되었습니다. 그렇다면 이 목표를 어떻게 달성할 수 있을까요?

APISIX 게이트웨이가 Beeto의 아키텍처를 강화

서비스 관리의 불편함과 높은 비용 문제를 해결하기 위해 APISIX의 동적 성능과 etcd의 이점을 활용하여 Beeto의 제품 요구 사항에 더 부합하는 APISIX를 아키텍처 배포에 API 게이트웨이로 도입하고, 아래 그림과 같이 게이트웨이 클러스터를 구축했습니다.

APISIX 게이트웨이 클러스터는 모든 서비스에 대해 레지스트리 센터, 서비스 제어, 서비스 모니터링, 프로토콜 전달 및 플러그인과 같은 확장 도구를 제공합니다. 서비스 클러스터는 모두 게이트웨이에 등록할 수 있으며, 새로운 서비스를 게이트웨이를 통해 직접 추가 및 제거할 수 있습니다.

게이트웨이가 도입된 후, 전체 클러스터의 호출 추적이 더 명확해졌습니다. 북-남 트래픽은 게이트웨이에 의해 라우팅 및 전달되고, 동-서 트래픽은 인트라넷 서비스에 의해 게이트웨이에 의해 처리됩니다. 기능적 수준에서 APISIX는 이 트래픽에 의해 호출되는 인증을 유지 관리하여 게이트웨이 계층이 서비스 간의 성능 차이와 트래픽 차이를 명확히 이해할 수 있도록 합니다.

물론, 이 아키텍처에서 게이트웨이가 모든 트래픽을 담당하므로 서비스가 확장됨에 따라 서비스 수가 증가하고 게이트웨이의 유지보수 비용이 증가하며 새로운 솔루션이 필요할 것입니다. 그러나 현재 상황에서는 이 솔루션이 여전히 최선의 선택입니다.

APISIX 적용 후의 실천

Apache APISIX는 API 게이트웨이로서 게이트웨이 수준에서 다양한 정책을 처리할 수 있습니다. 예를 들어, 인증, 서비스 전달, 건강 상태 확인 등이 있습니다. 따라서 Beeto는 APISIX를 도입한 후 비즈니스 실천 수준에서 많은 시도를 했습니다.

보안: 인증 플러그인

북-남 트래픽: 쿠키

앞서 언급했듯이, 공용 네트워크 사용자의 접근 트래픽은 게이트웨이를 통과합니다. 공용 네트워크 사용자의 인증은 쿠키 인증을 기반으로 한 사용자 요청입니다. 사용자가 쿠키를 게이트웨이에 요청하면 인증 플러그인에 의해 검증됩니다.

위의 플로우차트에서 볼 수 있듯이, 플러그인은 먼저 현지화 검증을 수행한 후 정책에 따라 원격 서비스의 인증 검증을 수행합니다. 요청이 쿠키 검증을 통과하면 지정된 서비스로 전달됩니다.

이렇게 하는 데는 두 가지 장점이 있습니다:

1. 사용자의 쿠키 보안이 보장됩니다. 실행 중에 쿠키는 민감한 데이터이므로 게이트웨이 계층만이 쿠키를 수신 및 처리할 수 있습니다. 이는 비즈니스 처리 규칙의 불일치로 인한 보안 문제를 방지하고, 인적 요인 및 불규칙성으로 인한 쿠키 유출을 효과적으로 방지합니다.

2. 서비스의 쿠키 인증 복잡성을 줄입니다. 쿠키는 현지 또는 원격으로 검증되어야 하며, 쿠키가 업그레이드될 때 동시에 서비스 업그레이드가 필요합니다. APISIX는 통합 관리 및 검증을 통해 비즈니스 서비스의 검증 비용을 절감하고 결과를 표시하여 각 비즈니스 처리가 비즈니스 자체에 더 집중할 수 있도록 합니다.

동-서 트래픽: 토큰

아래 다이어그램에서 서비스 A가 서비스 B를 호출합니다. 일반적으로 API만 있으면 서로 호출할 수 있습니다. 그러나 내부 프로세스에서는 "누가 API를 호출했는지, 어떻게 호출했는지, 권한을 확인할 필요가 있는지, 연구자를 통제할 필요가 있는지" 등을 이해해야 하며, 이는 내부적으로 처리되어야 합니다.

APISIX 게이트웨이를 사용하면 이 프로세스가 훨씬 간단해집니다. 모든 내부 서비스의 상호 호출은 Auth 인증 서비스에 등록하기만 하면 되며, 각 서비스에 App 키를 발급하여 서비스의 ID를 나타냅니다. 동시에 내부 서비스의 상호 호출도 게이트웨이를 통과합니다. 게이트웨이를 통해 토큰을 전달한 후, 게이트웨이는 토큰 플러그인을 통해 토큰을 인증합니다. 인증이 통과되면 호출된 서비스에 인증 식별자가 전달됩니다. 전체 프로세스 동안 서비스 시스템은 인증 등록을 수행하고 상호 호출을 완료합니다.

App 키의 토큰 규칙 덕분에 위의 작업은 호출 소스를 쉽게 추적할 수 있으며, 문제 해결 및 권한 제어에 사용할 수 있고, 불법 호출에 대한 효과적인 제어를 제공할 수 있습니다. 따라서 통합 인증의 장점은 북-남 또는 동-서 트래픽 모두에 대해 클러스터의 보안과 일관성을 보장하며, 문제 추적 및 호출 제어에 큰 도움이 됩니다.

확장성: 상태 비저장 서비스 확장 및 마이그레이션

Beeto 클러스터의 전체 배포 아키텍처는 위에서 아래로 APISIX 게이트웨이 클러스터 - 상태 비저장 서비스의 비즈니스 서비스 클러스터 - 상태 저장 서비스의 데이터 센터 클러스터로 구성됩니다. 중동에서 현지로 배포할 때 주요 클라우드 클러스터에 배포됩니다. 중동의 클라우드 커버리지 규모와 지역별 클라우드 제조업체에 따라 서비스 배포 시 클라우드 서비스의 확장 및 마이그레이션을 고려해야 합니다.

마이그레이션 과정에서 Beeto는 상태 비저장 서비스의 마이그레이션에 중점을 두었습니다. 데이터 센터의 마이그레이션 비용이 제한적이기 때문에 동적 조정에는 적합하지 않습니다. 대부분의 요청은 상태 비저장 서비스에 의해 처리되므로 상태 비저장 서비스가 좋은 확장성을 갖는 것이 매우 중요합니다.

Beeto의 아키텍처에서 서비스 확장성은 주로 두 가지 측면에서 나타납니다: 단일 서비스 확장성과 전체 클러스터 확장성. 예를 들어, 단일 서비스가 리소스를 다 사용하여 확장이 필요한 경우 APISIX 게이트웨이를 통해 동적으로 노드를 추가하여 확장할 수 있습니다. 마찬가지로, 클러스터 간 또는 클라우드 간 상황에서 여러 APISIX 게이트웨이를 배포하고 다른 서비스를 다른 게이트웨이 노드로 마이그레이션하여 클러스터 확장성을 달성할 수 있습니다.

비즈니스 서비스의 경우 전체 아키텍처는 변경되지 않으므로 게이트웨이 계층에서 다양한 서비스의 동적 확장 및 축소와 서비스 마이그레이션을 실현할 수 있습니다. 전체 프로세스는 명확한 계획과 목표를 가지고 있으며, 변경이 발생하더라도 전체 아키텍처가 불안정해지지 않습니다.

기능 확장성: 서비스 동적 전달

위에서 언급한 게이트웨이의 일반적인 시나리오 외에도, Apache APISIX는 서비스 동적 전달 측면에서 Beeto에게 큰 도움을 제공합니다.

앱의 UI와 백엔드에 익숙한 사람들은 다른 제품 페이지가 다른 서비스에 의해 제공된다는 것을 알고 있을 것입니다. 페이지는 다른 모듈로 구성되며, 모듈의 내용은 모두 API에서 전송됩니다. API가 모듈에 전송하는 데이터는 클라이언트 측에서 렌더링됩니다. 이는 클라이언트 측 렌더링 프로세스를 더 일반적으로 만들고 비즈니스 처리를 더 유연하게 만드는 공통 클라이언트 측 렌더링 규격입니다.

위 그림의 PageA 구현에서 예를 들어보겠습니다. 클라이언트는 서비스 A의 API를 호출하고 해당 모듈의 데이터를 전송하여 PageA의 렌더링을 완료합니다. 이 작업은 클라이언트가 각 페이지와 각 서비스에 대한 API를 유지해야 하는 문제를 일으킵니다. 콘텐츠가 변경되면 출판을 통해 해결해야 하며, 이는 운영성과 효율성 측면에서 매우 불친절합니다.

위 문제의 해결책은 전체 아키텍처에서 서비스의 통합 분배를 구현하는 것입니다. 클라이언트는 먼저 API 주소를 요청하고, 이 유형의 모든 요청을 하나의 API로 전달합니다. 게이트웨이 수준에서 요청 매개변수와 URL 규칙을 처리한 후 분배 플러그인을 도입합니다. 마지막으로, 구성 규칙에 따라 게이트웨이 계층에서 지정된 서비스로 직접 요청을 전달합니다.

전체 프로세스에서 클라이언트는 데이터의 소스를 결정할 필요 없이 렌더링 규격만 결정하면 됩니다. 게이트웨이 계층은 서비스 분배의 책임을 지고 트래픽을 직접 전달합니다. APISIX의 플러그인 구성 파일은 실시간으로 동적으로 업데이트될 수 있으며, 전달 규칙은 동적으로 조정될 수 있어 매우 유연합니다. 실제로 BFF(Backend for Frontend) 아키텍처와 같은 애플리케이션의 경우 이러한 요구 사항은 게이트웨이 계층에서 해결할 수 있습니다.

결론

이 글은 Beeto가 Apache APISIX를 도입한 설계 사고와 비즈니스 관점에서의 적용 실천을 소개합니다.

APISIX는 Beeto가 리소스 비용과 여러 비즈니스 제품 라인을 통제하고, 중동에서 현지화된 배포, 통합 관리 및 운영, 유지보수 친화적인 시나리오를 실현하는 데 도움을 주었습니다.