분산 애플리케이션을 위한 글로벌 서비스 메시
이 블로그는 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다루는 일련의 블로그 중 두 번째입니다.
- 분산 Kubernetes PaaS를 위한 제어 평면
- 분산 애플리케이션을 위한 글로벌 서비스 메시
- 분산 인프라, 앱 및 데이터를 위한 플랫폼 보안
- 분산 클러스터의 응용 프로그램 및 네트워크 보안
- 전 세계적으로 분산된 플랫폼에서의 관찰 가능성
- 전 세계적으로 분산된 플랫폼의 운영 및 SRE
- 분산 마이크로서비스를 위한 Golang 서비스 프레임워크
이전 블로그 에서 저희는 새로운 플랫폼을 구축하게 된 배경을 설명했습니다. 이 플랫폼을 사용하면 고객이 스마트 제조, 공공 안전을 위한 비디오 포렌식, 알고리즘 트레이딩, 통신사 5G 네트워크 등 복잡하고 다양한 애플리케이션 세트를 구축할 수 있습니다.
이 시리즈의 첫 번째 블로그 에서는 퍼블릭 클라우드, 프라이빗 네트워크 PoP, 엣지 사이트에서 여러 멀티 테넌트 Kubernetes 기반 애플리케이션 클러스터를 제공하기 위한 분산형 제어 평면을 다루었습니다.
이 특정 블로그에서는 분산 애플리케이션 클러스터를 연결하고 보호하는 과제를 애플리케이션 간, 사용자/머신 간, 애플리케이션과 공용 인터넷의 세 가지 관점에서 다룰 것입니다. 우리는 완전히 통합된 L3-L7+ 데이터 경로, 전 세계적으로 분산된 제어 평면, 그리고 고성능 글로벌 네트워크를 도입할 것입니다. 이 세 가지가 결합되어 엣지, 모든 클라우드 VPC 또는 글로벌 네트워크 PoP에서 포괄적인 네트워크 및 보안 서비스 세트를 제공합니다. 1년 넘게 35명 이상의 고객과 함께 프로덕션을 운영한 후, 우리는 배포 규모를 확장하기 시작했으며 이제 여정을 공유하기에 좋은 때라고 생각했습니다.
TL;DR (요약)
- 분산 애플리케이션 클러스터에 고성능, 안정적이고 안전한 연결을 제공하려면 새로운 글로벌 네트워크를 구축해야 했습니다. 소비자를 애플리케이션에 연결하고 보안을 제공하는 서비스 제공업체(Akamai, Cloudflare 등)와 직원을 애플리케이션에 연결하고 보안을 제공하는 서비스 제공업체(예: Zscaler, Netskope 등)는 많지만 애플리케이션 간 연결 및 보안에 대한 요구를 충족하는 서비스 제공업체는 없습니다.
- 분산 애플리케이션을 연결하는 글로벌 네트워크 외에도 이러한 애플리케이션 클러스터에는 일관된 구성과 운영 모델을 갖춘 네트워킹, 안정성 및 보안 서비스(API 라우팅, 로드 밸런싱, 보안 및 네트워크 라우팅)가 필요합니다. 이러한 서비스는 여러 클라우드 공급자 위치, 리소스가 제한된 엣지 위치 및/또는 글로벌 네트워크에서 실행되어야 합니다.
- 이러한 네트워킹 및 보안 서비스를 제공하기 위해 우리는 네트워크, 여러 퍼블릭 클라우드 또는 에지 위치 등 어디에서 실행되든 일관된 구성, 정책 및 관찰성을 갖춘 새롭고 완벽하게 통합된 L3-L7+ 네트워크 데이터 경로를 구축하기로 결정했습니다. 이러한 데이터 경로의 대부분은 여러 사이트에 배포될 수 있기 때문에 이러한 데이터 경로를 조정하기 위해 전 세계적으로 분산된 제어 평면을 구축해야 했습니다.
- 글로벌 네트워크, 새로운 네트워크 데이터 경로, 분산 제어 플레인을 결합하면 네트워크 액세스를 이 글로벌 네트워크 전체에 제공하지 않고도 제로 트러스트 보안, 애플리케이션 연결, 클러스터 안정성을 제공하는 "글로벌 분산 애플리케이션 게이트웨이"가 제공됩니다. 보안 및 규정 준수 팀을 간소화하는 "글로벌 서비스 메시"입니다.
케이블은 어디에 있나요? 우리는 왜 글로벌 네트워크를 구축했나요?
고객들이 스마트 제조, 공공 안전을 위한 비디오 포렌식, 알고리즘 트레이딩, 통신사 5G 전환 등 상당히 복잡하고 임무 수행에 필수적인 애플리케이션을 구축함에 따라 당사는 애플리케이션과 이러한 애플리케이션의 최종 사용자에게 항상 연결되고 안정적인 환경을 제공해야 합니다. 이러한 애플리케이션 중 일부는 클라우드 내의 클러스터에서 데이터 파이프라인을 실행하거나 클라우드 공급자 간에 데이터를 백업해야 하거나 글로벌 사용자 기반의 요청을 앱 백엔드로 안정적으로 전달해야 하거나 중앙 클라우드에서 실행되는 백엔드까지 머신에서 고성능 연결이 필요합니다.
이러한 요구 사항을 충족하기 위해 물리적 네트워크에는 두 가지 요구 사항이 있었습니다.
R1 - 클라우드 간 - 전 세계 퍼블릭 또는 프라이빗 클라우드 위치에서 애플리케이션의 고성능 및 주문형 연결
R2 — 인터넷에서 클라우드로 — 엣지 위치에 있는 장치와 머신을 애플리케이션 백엔드에 안정적으로 연결하기 위해, 인터넷을 사용하여 백엔드까지 트래픽을 백홀링하는 대신 여러 개의 중복 경로를 제공하고 이러한 사용자에게 가까운 곳에서 연결을 종료해야 했습니다.
AT&T와 같은 네트워크 서비스 제공업체에 가서 요구 사항 R1 및 R2를 해결할 수 있었지만, 그들은 API 기반 구성, 스트리밍 원격 측정, 자체 또는 고객의 IP 접두사를 쉽게 추가하는 기능, API 기반 네트워크 서비스 등 원활한 네트워크 경험과 애플리케이션 서비스와의 통합을 제공할 수 없었습니다. 게다가 서비스 제공업체로부터 글로벌 커버리지를 확보하는 것은 매우 어렵거나 엄청나게 비쌉니다. 우리는 이 모든 문제를 해결하기 위해 두세 개의 다른 서비스 공급업체를 선택할 수도 있었지만 그러면 서로 다르게 동작하고, 장애 모드가 다르고, SLA, 지원 시스템이 다르고, API가 다르거나 아예 없는 등 다양한 시스템이 난무하는 복잡한 상황에 처하게 되었을 것입니다.
그래서 우리는 결국 우리만의 네트워크를 구축해야 했고 이는 네트워크에 세 가지 속성이 필요하다는 것을 의미했습니다.
- R1 문제를 해결하려면 전 세계의 여러 클라우드 공급업체에 걸쳐 프라이빗 네트워크를 구축하여 모든 지역을 연결해야 했습니다. 이를 위한 가장 좋은 방법은 주요 클라우드 지역의 클라우드 공급업체와 피어링하는 동시에 주요 콜로케이션 시설에서 직접 연결 링크를 혼합하여 사용하는 것입니다. 피어링은 최상의 SLA를 보장하지 않지만 직접 연결 링크는 클라우드 지역 내에서 SLA를 보장합니다.
- 에지 위치에 있는 머신의 R2를 해결한다는 것은 각 에지 위치에서 저가 인터넷 링크(셀룰러 또는 케이블/광섬유를 통한) 및/또는 고가 전용 링크(광섬유/이더넷을 통한)가 될 수 있는 여러 개의 액티브-액티브 링크를 지원해야 한다는 것을 의미합니다. 성능과 안정성을 확보하려면 트래픽을 부하 분산하고 신뢰할 수 없는 인터넷을 통해 전송하는 대신 가능한 한 엣지 위치에 가까운 곳에서 종료해야 합니다. 업계에서는 이 기능을 SD-WAN이라고도 부릅니다.
- 인터넷 사용자와 에지 애플리케이션을 위한 R2를 해결한다는 것은 TLS 트래픽의 에지 종료를 수행해야 한다는 것을 의미하며, 이는 사용자와 가능한 한 가까운 곳에서 이루어져야 합니다. 즉, 모바일 운영자, 콘텐츠 제공자와 긴밀한 피어링을 통해 네트워크 엣지 위치를 구축해야 했으며, 최적의 라우팅을 보장하기 위해 여러 전송 제공자를 사용하여 트래픽을 가져와야 했습니다.
이 세 가지 특성을 충족하기 위해 우리는 많은 일을 해야 했습니다. 하지만 우리는 다섯 가지 큰 버킷 항목을 강조할 것입니다.
- 네트워크 기어를 통한 글로벌 네트워크 PoP - 결국 주요 대도시 시장에 여러 네트워크 PoP를 구축해야 했습니다. 플랫폼 구축 초기에는 유럽의 여러 도시(파리, 런던, 암스테르담, 룩셈부르크)와 미국의 한 PoP(NYC)로 시작했고, 이후 시애틀, 샌호세, 애시번, 프랑크푸르트, 싱가포르, 도쿄로 확장했습니다. 이를 통해 글로벌 커버리지를 확보했고 모든 주요 클라우드 공급업체와 가까워졌습니다. 우리는 글로벌 파트너로 Equinix를 선택했으며, Equinix가 최적의 선택이 아닐 수 있는 지역에서는 Interxion과 Telehouse/KDDI, Westin을 파트너로 추가했습니다. 우리는 자동화를 믿기 때문에 스위칭/라우팅 장비를 위해 Juniper Networks를, 400G와 100G 링크의 메트로 파이버 상호연결을 위해 Adva를 선택했습니다.
- 사설 백본 - 이 모든 PoP를 높은 성능과 안정성으로 연결하기 위해 여러 전송 공급업체 위에 오버레이 네트워크를 구축하지 않고 대신 Zayo, Centurylink, EuNetworks 등의 공급업체가 제공하는 여러 100G 파장을 조합하여 글로벌 사설 백본을 구축하기로 결정했습니다. 많은 CDN(예: Cloudflare, Fastly)과 보안 공급업체(예: Zscaler)는 다운스트림 트래픽을 제공할 때 전송 및 피어링 연결에 전적으로 의존하지만, 우리는 동서 애플리케이션 간 트래픽을 처리하고 있기 때문에 개인 백본과 전송 연결을 함께 사용하는 것이 좋은 이유가 있다고 생각합니다. 이는 우리에게만 고유한 현상이 아닙니다. 모든 주요 클라우드 공급업체는 자사의 클라우드 위치를 연결하는 글로벌 프라이빗 백본을 보유하고 있습니다.
- 인터넷 피어링 및 전송 공급자 - 다양성을 높이고 사용자와 콘텐츠 또는 SaaS 공급자에게 도달하기 위한 최상의 성과를 달성하기 위해 이상적인 솔루션은 가능한 한 많은 운영자 및 콘텐츠 공급자와 직접 피어링하는 것입니다. PeeringDB( PeeringDB의 ASN-35280 )에 명시된 대로 여러 거래소에서 피어링합니다. 모든 트래픽이 피어링 연결을 통해 처리될 수 있는 것은 아니며, 여기서 전송 연결이 중요한 역할을 합니다. 품질을 유지하려면 중계 링크와 피어링 포트를 매우 신중하게 모니터링해야 합니다. 결국 우리는 다양한 글로벌 위치에서 서비스를 제공하기 위해 NTT, CenturyLink, Telia와 같은 최고의 Tier-1 공급업체를 선택했습니다.
- 클라우드 피어링 및 상호 연결 - 최근 클라우드 공급자와 직접 피어링을 시작했지만 이러한 연결에 대해 SLA를 보장하지는 않습니다. 예를 들어 시애틀(Westin 시설)의 피어링 연결에서는 세 개의 주요 클라우드 공급자에 직접 연결할 수 있습니다. 이러한 연결이 단순히 중계 서비스 제공업체를 거치는 것보다 나을지라도, 우리는 이러한 클라우드 제공업체에 대한 직접 연결(AWS Direct Connect, Azure Express Route, GCP Dedicated Interconnect라고 함)로 네트워크를 보강하기 시작했습니다. 이는 SLA와 추가 기능이 제공되기 때문입니다. 이러한 링크는 비용이 많이 들고 내부 VPC/VNET 서브넷에만 액세스할 수 있지만 가장 뛰어난 연결성을 제공합니다.
- 소프트웨어 게이트웨이 - PoP 위치에 직접 연결되지 않은 클라우드 또는 엣지 위치에는 소프트웨어 게이트웨이를 설치합니다. 이러한 게이트웨이가 제공하는 고급 기능에 대해서는 이 블로그의 후반부에서 다루겠지만, 전송 계층과 관련된 기능 중 하나는 이러한 게이트웨이가 중복성을 제공하고 PoP로의 트래픽 부하를 분산하기 위해 여러 네트워크 PoP에 대한 보안 VPN(IPsec 또는 SSL) 터널을 자동으로 생성한다는 것입니다. 또한 클라우드 배포에서 이러한 게이트웨이는 클라우드 공급자 NAT 게이트웨이를 통해 가장 가까운 PoP로의 아웃바운드 연결과 글로벌 프라이빗 네트워크로의 온램프를 생성하므로 공용 네트워크를 통과하거나 공용 IP 주소를 사용하여 클라우드 위치에서 애플리케이션 클러스터를 연결할 필요가 없습니다.
우리는 개발 초기에 글로벌 네트워크를 구축하고 운영하려면 시간과 기술이 필요하고, 이러한 전문 지식을 적용해야 한다는 점을 깨달았습니다. 프랑스 파리에 있는 보안 제공업체인 Acorus Networks의 창립자들과 수개월간 논의한 끝에, 우리는 결국 Acorus를 Volterra와 합병하기로 결정했습니다. 이를 통해 글로벌 인프라와 네트워크 구축 문제를 해결할 수 있었습니다. Acorus는 Ansible을 사용하여 물리적 네트워크 구성을 완전 자동화한 훌륭한 네트워크와 운영팀을 자체적으로 구성하고 소프트웨어 팀에서 사용할 수 있는 원격 측정 및 구성을 위한 외부 API를 구축했습니다.
이제 높은 안정성과 성능을 갖춘 글로벌 프라이빗 네트워크를 구축하는 데 주력하는 팀이 구성되었으므로 그림 1에서 볼 수 있듯이 에지나 클라우드 위치에서 발생하는 애플리케이션 간 트래픽과 사용자/머신 간 트래픽 문제를 쉽게 해결할 수 있습니다. 또한, 네트워크 PoP의 컴퓨팅 및 스토리지 인프라를 통해 API 종료, 앱 보안, 워크로드 오프로드(에지 또는 클라우드에서)를 네트워크에 추가할 수 있었습니다. 이를 통해 당사는 앞으로도 역량을 계속 발전시키고 수요에 따라 네트워크 범위와 서비스 카탈로그를 쉽게 확장할 수 있습니다.
애플리케이션을 위한 네트워크 서비스 - 멀티 클라우드, 프라이빗, 엣지?
글로벌 네트워크가 제대로 작동하게 된 후에는 애플리케이션 클러스터와 워크로드를 추가해야 했습니다. 이러한 작업 부하에는 고유한 애플리케이션 수준 연결 및 보안 서비스 세트가 필요합니다.
이전 블로그 에서 설명했듯이, 이 플랫폼을 구축한 목적은 여러 환경(클라우드, 엣지, 네트워크 PoP)에서 실행되는 작업 부하를 관리하는 팀의 생산성을 높이고 복잡성을 줄이는 것이었습니다.
모든 클라우드 공급자는 애플리케이션 클러스터에 대한 안전한 연결을 위해 다양한 클라우드 리소스를 구성, 관리 및 모니터링해야 합니다. 예를 들어, Google Cloud에서 애플리케이션 클러스터에 대한 엔드투엔드 네트워크 서비스를 구성하려면 다양한 서비스 세트를 관리해야 합니다.
광역 네트워크(WAN) 서비스
애플리케이션 네트워킹 서비스
- 애플리케이션 로드 밸런서 , 네트워크 로드 밸런서 (공개 API)
- 애플리케이션 로드 밸런서 , 네트워크 로드 밸런서 (내부)
- 서비스 메시 (앱 간)
네트워크 라우팅 및 격리 서비스
좋습니다. 큰 도전이 될 수는 있겠지만, 각 클라우드 공급자 전반에서 조화를 이루는 구성 및 운영 계층을 구축함으로써 이 문제를 해결하기로 결정할 수 있었습니다. 하지만 우리는 클라우드 공급업체의 서비스가 우리의 모든 요구 사항을 충족시키지 못하기 때문에(예: CSP에서는 애플리케이션을 실행하고 API 보안을 유지하는 기능이 부족함) 그것만으로는 문제를 해결할 수 없다는 걸 알고 있었습니다. 또한, 그들은 최고가 아니며, 끊임없이 변화하고 있습니다.
또한, 네트워크 PoP와 에지 사이트는 어떻습니까? 우리는 하드웨어 또는 소프트웨어 공급업체로부터 유사한 기능을 얻어서 모두 통합해야 합니다. 예를 들어, 라우팅+nat+vpn의 경우 Cisco/Juniper, 로드 밸런싱 및 방화벽의 경우 F5 등입니다. 에지 위치에서는 클라우드 공급업체나 대규모 네트워크 공급업체 모두 리소스가 제한된 환경에서 네트워크 서비스 문제를 해결할 수 없기 때문에 문제가 더욱 복잡해집니다. 에지에 대한 또 다른 잠재적인 옵션은 모든 애플리케이션 연결, 보안 및 네트워크 서비스를 글로벌 네트워크로 옮기는 것이었습니다. 하지만 동일한 에지 사이트 내의 앱 간 트래픽에도 이러한 서비스 중 일부가 필요하기 때문에 이 방법은 효과가 없다는 것이 분명했습니다.
많은 논의와 환경 조사를 거친 후, 우리는 여러 서비스 제공업체와 벤더 간의 통합(구성, 원격 측정, 모니터링, 알림)을 수행하고 로드맵과 API 변경 사항을 따라가는 것이 단순성과 속도라는 우리의 목표에 어긋난다는 것을 깨달았습니다.
플랫폼 전반에 걸쳐 해결해야 했던 또 다른 문제는 멀티 테넌시였습니다. WAN 서비스와 네트워크 라우팅에서는 쉽게 해결할 수 있지만, 대부분의 로드 밸런서가 멀티 테넌시에 대한 지원이 전혀 없거나 매우 제한적이기 때문에 애플리케이션 네트워킹 서비스에서는 어려운 문제였습니다.
새로운 L3-L7+ 네트워크 데이터 경로
결국, 우리는 이러한 과제를 맡아 네트워크 라우팅 서비스뿐만 아니라 애플리케이션, 보안, 광역 서비스까지 제공하는 고성능 네트워크 데이터 경로를 구축하기로 결정했습니다. 이를 통해 하이브리드 및 분산 클라우드 환경에서 서비스 포트폴리오를 통합하고 퍼블릭 클라우드의 기본 서비스에만 의존하면 됩니다.
팀원들이 네트워킹 경험이 풍부하고 이전에 Contrail/Juniper와 관련해 이런 문제를 처리한 적이 있다는 점을 고려했을 때, 우리는 이 문제를 해결하는 가장 좋은 방법은 깨끗한 상태에서 시작하여 L3에서 L7+까지 서비스를 단일 데이터 경로로 통합하는 완전히 새로운 네트워킹 솔루션을 구축하는 것이라고 생각했습니다. 이 솔루션은 모든 클라우드나 엣지에서 실행 가능하면서도 우리 플랫폼에서 중앙에서 관리됩니다.
우리는 이 새로운 데이터 경로의 설계를 시작하기 위해 가장 적합한 프로젝트를 선택했습니다. 즉, 이미 6년 동안 개발에 투자한 OpenContrail vRouter(L3-L4용)와 거대한 커뮤니티 지원을 받고 있는 L7용 Envoy입니다. 그럼에도 불구하고, 새로운 통합 L3-L7+ 데이터 경로를 구축하기 위해 여러 가지 변경 및 추가 작업을 해야 했습니다. Envoy의 멀티 테넌시, Envoy의 dpdk, 사용자 공간 dpdk TCP 스택, 네트워크 정책, SSL/IPSec VPN, http 연결, 동적 역방향 프록시, 투명한 정방향 프록시, API 게이트웨이, 프로그래밍 가능한 애플리케이션 정책, DDoS 보호를 위한 빠른 ACL, PKI ID 통합, Chrome v8 엔진, 애플리케이션 및 네트워크 보안 등이 있습니다.
이 데이터 경로( 그림 2 참조)는 애플리케이션 클러스터의 유입/유출 게이트웨이, 엣지의 소프트웨어 게이트웨이로 배포되고, 클러스터 내부나 여러 클러스터에서 서비스 메시 기능을 제공하거나, 글로벌 PoP에서 네트워크 서비스를 제공합니다.
플랫폼의 다중 테넌시에 대한 요구 사항(이전 블로그에서 다룸)에 맞춰 이 네트워크 데이터 경로에 대한 전체 다중 테넌시를 제공해야 했습니다. vRouter가 이미 VRF를 지원했기 때문에 라우팅 계층의 경우 비교적 간단했지만 Envoy에서 멀티 테넌트를 지원하기 위해 변경 작업을 해야 했습니다. 커널 TCP 스택을 사용하지 않았기 때문에 Envoy의 TCP 소켓 인터페이스를 변경하고 VRF 인식 기능을 추가했습니다.
이 데이터 경로는 또한 API 보안, 애플리케이션 방화벽 및 네트워크 보안을 수행해야 했습니다. 우리는 이를 위해 알고리즘 기술과 기계 추론을 결합하여 사용했으며, 이 주제는 다가올 블로그 게시물에서 다룰 예정입니다.
이 네트워크 데이터 경로를 구축함으로써 우리는 많은 이점을 얻었습니다.
균일한 구성, 제어 및 관찰성을 갖춘 완벽한 L3-L7+ 기능
단일 클러스터 내에서 확장을 지원하면 네트워크나 퍼블릭 클라우드 위치에서 매우 작은 설치 공간과 성능이 낮은 에지 장치부터 최대 100Gbps 이상 용량까지 다양한 범위를 지원할 수 있습니다.
네트워크 공급업체 및/또는 클라우드 공급업체에 의존하지 않고 네트워크 데이터 경로에 새로운 기능을 빠르게 추가합니다.
어떤 환경에서도 유사한 실패 및 성능 특성을 보이는 공통 솔루션은 운영 팀에 매우 중요합니다.
이 새로운 네트워크 데이터 경로를 사용하여 여러 앱 클러스터를 배포할 수 있게 되었으므로 이를 구성, 제어, 모니터링하기 위한 글로벌 분산 제어 평면을 구축하는 것이 중요했습니다.
분산 네트워크를 위한 특수 목적 제어 평면
저희 플랫폼 팀은 다수의 분산 데이터 경로 처리 노드를 관리하는 분산 제어 평면을 구축하는 과정에서 여러 가지 문제를 해결해야 했습니다. 새로운 데이터 경로를 구축했기 때문에 활용할 수 있는 즉시 사용 가능한 제어 평면이 없었고 우리는 다음과 같이 직접 작성해야 했습니다. 단일 클러스터(클라우드, 엣지 또는 네트워크 PoP) 내에서 실행되는 여러 데이터 경로를 관리하기 위한 로컬 제어 평면입니다. 이러한 데이터 경로 노드에는 구성 변경 관리, 경로 업데이트, 상태 점검 수행, 서비스 검색 수행, BGP와 같은 프로토콜을 사용하여 다른 네트워크 장치와의 피어링, 메트릭 및 액세스 로그 집계 등을 위한 로컬 제어 평면이 필요했습니다. 여러 로컬 제어 평면을 관리하기 위한 분산 제어 평면 - 글로벌 네트워크 PoP에서 실행되는 분산 제어 평면이 있습니다( 그림 3 ). 이 제어 평면은 로컬 제어 평면의 구성 관리, 각 로컬 제어 평면에서의 운영 상태 분배, 각 노드의 데이터 수집을 담당합니다. 운영 상태를 분산하기 위해 일관성이 뛰어나고 견고한 BGP를 사용하기로 결정했습니다. 우리는 OpenContrail의 일부로 BGP의 매우 대규모이고 다중 스레드 구현을 구축했으므로 이를 활용하여 부하 분산을 위한 확장 기능(상태 확인 배포, http/api 엔드포인트, 정책 전파 등)을 추가했습니다.
또한 AWS와 Azure의 두 클라우드 지역에서 실행되는 중앙 관리 평면이 있으며, 이는 그림 4 에서 볼 수 있듯이 분산 제어 평면과 함께 사용되어 다중 테넌시를 제공합니다. 당사 SRE 팀은 여러 테넌트를 생성할 수 있으며, 각 테넌트는 전 세계 네트워크 전반에서 다른 테넌트와 완전히 분리됩니다. 그들은 "공용 네트워크"를 사용해서만 서로에게 라우팅할 수 있습니다. 테넌트 내에서 네임스페이스 간의 서비스는 http/api/network 라우팅 및 보안 규칙에 따라 서로 통신할 수 있습니다.
제어 평면은 별도의 테넌트 및 격리된 네임스페이스에서 Kubernetes 워크로드로 실행되며, 이는 SRE 팀에서만 제어됩니다. 결과적으로 어떠한 개발자나 고객도 이 서비스를 방해할 수 없습니다. 게다가 제어 평면이 분산되어 있으므로 한 위치에서 제어 평면이 중단되어도 전체 서비스에 영향을 미치지 않습니다.
글로벌 분산 애플리케이션 게이트웨이?
글로벌 네트워크에 대한 요구 사항을 파악하고 앱 클러스터를 위한 L3-L7+ 네트워크 서비스(새로운 데이터 경로 및 분산 제어 평면)에 대한 요구 사항을 정의한 후, 제품 팀은 우리의 삶을 더욱 흥미롭게 만드는 더 많은 요구 사항을 내놓았습니다. 기본적으로 그들은 다음과 같은 기능을 갖춘 글로벌 클러스터 간 서비스 메시를 제공하기를 원했습니다.
- 글로벌 네트워크에서 애플리케이션 연결(라우팅, 제어 및 관찰 가능성)을 제공하지만 네트워크 연결은 제공하지 않습니다(적어도 기본적으로는 제공하지 않음). 그 이유는 간단합니다. 네트워크를 연결하면 복잡한 방화벽 규칙을 만들어서만 해결할 수 있는 온갖 보안 취약성이 발생하고, 이로 인해 변경 관리를 수행하기가 더 어려워지기 때문입니다.
- 네트워크 PoP의 에지 로드 밸런서를 엔드포인트 상태 및 안정성과 함께 개선합니다. 현재 에지 로드 밸런서(예: AWS 글로벌 가속기 또는 Akamai 글로벌 로드 밸런서)에서 에지 위치에서 백엔드로의 라우팅 결정은 원본 서버의 상태에 따라 이루어집니다(대부분의 경우 원본 서버는 또 다른 로드 밸런서이며 실제 서비스 엔드포인트가 아닙니다). 저희 팀은 모든 클러스터의 모든 엔드포인트 상태를 기준으로 트래픽을 관리할 수 있는 각 에지 로드 밸런서의 기능을 원했습니다. 단순히 원본 로드 밸런서의 상태만 고려하는 것은 아니었습니다.
- GSLB 의사결정의 일부로 에지 사이트(네트워크 PoP) 선택 개선 - 현재는 애니캐스트나 GSLB가 사용자/클라이언트를 가장 가까운 에지 사이트로 라우팅하여 유입합니다. 그러나 다양한 이유(백본 및/또는 전송 공급자의 부하)로 인해 사용자를 다른 인그레스 에지 사이트로 보내는 것이 더 나을 수 있습니다.
요구사항 2번과 3번의 목표는 클라이언트와 서버 간 연결의 응답 시간과 성능을 개선하는 것이었으며, 이는 애플리케이션 간 통신이나 대규모 SaaS 애플리케이션에 매우 중요합니다. 요구 사항 #2와 #3을 충족하기 위해서는 분산 프록시(그림 5)를 구축하는 것이 가장 좋은 방법이라는 것이 분명했습니다. 즉, 네트워크 주소가 아닌 애플리케이션 주소에 기반한 수신 프록시와 송신 프록시 및 경로를 구축하는 것입니다. 또한, 분산 제어 평면과 BGP 확장(앞서 설명한 대로)을 활용하여 서비스 엔드포인트(또는 서버)의 상태를 분산하기로 결정했습니다. 분산 프록시의 구현은 아래 다이어그램에 나와 있습니다.
완전한 L3-L7+ 네트워크 스택을 갖춘 분산 프록시가 되었으므로 이를 글로벌 분산 애플리케이션 게이트웨이라고 부릅니다. 네트워크 데이터 경로에서 사용 가능한 모든 기능을 이제 글로벌 네트워크 전반에서 사용할 수 있습니다. 예를 들어, HTTP 또는 API 기반 로드 밸런싱 및 라우팅, 에지에서의 정책 시행, API 변환, 사용자에게 더 가까운 곳에서의 TLS 종료 등이 있습니다.
분산 애플리케이션 게이트웨이가 제공하는 이점
팀은 전 세계적으로 분산된 애플리케이션 게이트웨이를 구현함으로써 여러 가지 이점을 얻을 수 있었습니다. 이러한 성과는 운영 개선, 보안, 성능 및 TCO 분야에서 나타났습니다.
- 보안 및 규정 준수 - 네트워크 액세스 없이도 사이트 전체에 애플리케이션 액세스를 제공하는 기능은 에지 또는 클라우드 위치에 있는 애플리케이션 클러스터 전체의 보안 및 규정 준수를 크게 개선했습니다. 또한 사이트 간에 네트워크 접근이 없고 애플리케이션 클러스터를 연결할 수 있지만 각 사이트에서 완전히 NAT 뒤에 있기 때문에 복잡한 방화벽 구성 관리의 필요성이 줄었습니다.
- 운영 오버헤드 - 네트워크 PoP와 에지/클라우드 사이트 전반의 공통 네트워크 서비스 세트 덕분에 SRE 또는 DevOps가 다양한 서비스 세트 전반에서 구성 및 관찰을 통합할 필요성이 없어졌습니다.
- 성능 및 안정성 개선 - 네트워크 PoP에서 가장 최적이고 건강한 엔드포인트로 라우팅하고 가장 최적의 로드 밸런서로 라우팅하지 않기 때문에 이 플랫폼은 시중의 다른 모든 솔루션보다 애플리케이션 간 또는 사용자 간 트래픽에 훨씬 더 높은 성능을 제공할 수 있습니다.
- TCO 이득 - 대규모 SaaS 애플리케이션의 경우 전 세계 여러 데이터 센터에서 제공되는 서비스의 복제본을 수백 개 보유하는 것이 일반적입니다. 이를 효과적으로 수행하기 위해 SaaS 제공자는 이 분산 애플리케이션 게이트웨이를 통해 모든 고객이 사용할 수 있는 복잡한 기능을 구축해야 합니다.
계속됩니다…
이 블로그 시리즈에서는 퍼블릭 클라우드, 프라이빗 네트워크 PoP, 엣지 사이트의 많은 애플리케이션 클러스터를 활용하여 전 세계적으로 분산된 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다룰 것입니다. 다음은 플랫폼 및 데이터 보안 입니다.