분산 애플리케이션을 위한 글로벌 서비스 메시

Ankur Singla

이 글은 당사의 SaaS 서비스를 구축하고 운영하는 데 필요했던 다양한 측면을 다루는 블로그 시리즈의 두 번째 글입니다:

1. 분산형 Kubernetes PaaS를 위한 컨트롤 플레인
2. 분산 애플리케이션을 위한 글로벌 서비스 메시
3. 분산 인프라, 앱 및 데이터를 위한 플랫폼 보안
4. 분산 클러스터의 애플리케이션 및 네트워크 보안
5. 전 세계에 분산된 플랫폼 전반의 관측 가능성
6. 전 세계에 분산된 플랫폼의 운영 및 SRE
7. 분산 마이크로서비스를 위한 Golang 서비스 프레임워크

이전에 게시한 블로그 글에서 새로운 플랫폼을 구축하게 된 배경과 요구 사항을 설명했습니다. 이 플랫폼을 통해 고객은 스마트 제조, 공공 안전을 위한 영상 포렌식, 알고리즘 트레이딩, 통신사의 5G 네트워크 등 복잡하고 다양한 애플리케이션을 구축할 수 있습니다.

이 시리즈의 첫 번째 블로그에서는 퍼블릭 클라우드, 당사의 프라이빗 네트워크 PoP 및 엣지 사이트에 여러 멀티테넌트 Kubernetes 기반 애플리케이션 클러스터를 제공하기 위한 분산형 컨트롤 플레인을 다뤘습니다.

이번 블로그에서는 애플리케이션 간 연결, 사용자/머신과 애플리케이션 간 연결, 애플리케이션과 공용 인터넷 간 연결이라는 세 가지 관점에서 이러한 분산 애플리케이션 클러스터를 연결하고 보호할 때 발생하는 과제를 다룹니다. 완전히 새롭게 개발되어 완벽하게 통합된 L3-L7+ 데이터 경로, 전 세계에 분산된 컨트롤 플레인, 고성능 글로벌 네트워크를 소개합니다. 이 세 가지 요소를 결합하여 엣지, 모든 클라우드 VPC 내부 또는 글로벌 네트워크 PoP에서 포괄적인 네트워크 및 보안 서비스를 제공합니다. 35곳 이상의 고객 환경에서 1년 넘게 프로덕션으로 운영한 후 배포 규모를 확대하기 시작했으며, 지금이 그 여정을 공유하기에 좋은 시점이라고 판단했습니다.

요약

• 분산된 애플리케이션 클러스터에 고성능의 안정적이고 안전한 연결을 제공하려면 새로운 글로벌 네트워크를 구축해야 했습니다. 소비자와 애플리케이션 간의 연결 및 보안을 제공하는 서비스 사업자(Akamai, Cloudflare 등)와 직원과 애플리케이션 간의 연결 및 보안을 제공하는 서비스 사업자(예: Zscaler, Netskope 등)는 많지만, 애플리케이션 간 연결 및 보안 요구를 충족하는 서비스 사업자는 없습니다.
  
• 분산 애플리케이션을 연결하는 글로벌 네트워크뿐만 아니라, 이러한 애플리케이션 클러스터에는 일관된 구성 및 운영 모델을 갖춘 네트워킹, 안정성, 보안 서비스(API 라우팅, 부하 분산, 보안, 네트워크 라우팅)가 필요합니다. 이러한 서비스는 여러 클라우드 제공업체의 리전, 리소스가 제한된 엣지 로케이션 및/또는 당사의 글로벌 네트워크에서 실행되어야 합니다.
  
• 이러한 네트워킹 및 보안 서비스를 제공하기 위해, 당사 네트워크, 여러 퍼블릭 클라우드 또는 엣지 위치 등 실행 환경에 관계없이 일관된 구성, 정책 및 관측 가능성을 제공하는 완전히 통합된 새로운 L3-L7+ 네트워크 데이터 경로를 구축하기로 했습니다. 이러한 데이터 경로는 여러 사이트에 걸쳐 배포될 수 있으므로, 이를 오케스트레이션하기 위한 전 세계 분산형 제어 영역도 구축해야 했습니다.
  
• 글로벌 네트워크, 새로운 네트워크 데이터 경로, 분산형 제어 플레인의 결합을 통해 우리는 이 글로벌 네트워크 전반에 대한 네트워크 액세스를 허용하지 않고도 제로 트러스트 보안, 애플리케이션 연결성, 클러스터 안정성을 제공하는 ‘전 세계에 분산된 애플리케이션 게이트웨이’를 구축했습니다. 이는 보안 및 규정 준수 팀의 업무를 간소화하는 ‘글로벌 서비스 메시’입니다.

케이블은 어디에 있을까요? 우리는 왜 글로벌 네트워크를 구축했을까요?

고객들이 스마트 제조, 공공 안전을 위한 영상 포렌식, 알고리즘 트레이딩, 통신사의 5G 전환과 같이 상당히 복잡하고 미션 크리티컬한 애플리케이션을 구축하고 있으므로, 당사는 이러한 애플리케이션과 최종 사용자에게 상시 연결되고 안정적인 환경을 제공해야 합니다. 이러한 애플리케이션 중 일부는 클라우드 내 여러 클러스터에 걸쳐 데이터 파이프라인을 실행하거나, 여러 클라우드 제공업체에 데이터를 백업하거나, 전 세계 사용자 기반의 요청을 애플리케이션 백엔드에 안정적으로 전달해야 하거나, 자체 시스템과 중앙 집중식 클라우드에서 실행되는 백엔드 간에 고성능 연결을 필요로 합니다.

이러한 요구 사항을 충족하기 위해 물리적 네트워크에는 두 가지 요건이 있었습니다:

R1 — 클라우드 간 연결 — 전 세계 퍼블릭 또는 프라이빗 클라우드 환경에 있는 애플리케이션을 고성능으로 필요할 때 즉시 연결

R2 — 인터넷에서 클라우드로 — 엣지 위치의 디바이스와 머신이 애플리케이션 백엔드에 안정적으로 연결되도록 하려면 여러 개의 이중화 경로를 제공하고, 인터넷을 통해 트래픽을 백엔드까지 우회 전송하는 대신 이러한 사용자와 최대한 가까운 곳에서 연결을 종단해야 했습니다.

AT&T와 같은 네트워크 서비스 제공업체를 이용했다면 요구사항 R1과 R2를 해결할 수도 있었겠지만, 이들은 원활한 네트워크 환경과 애플리케이션 서비스와의 통합, 즉 API 기반 구성, 스트리밍 텔레메트리, 당사 또는 고객의 IP 프리픽스를 손쉽게 추가하는 기능, API 기반 네트워크 서비스 등을 제공할 수 없었을 것입니다. 또한 서비스 제공업체를 통해 전 세계를 포괄하는 것은 매우 어렵거나 비용이 지나치게 많이 듭니다. 이러한 문제를 모두 해결하기 위해 서로 다른 서비스 제공업체 두세 곳을 이용할 수도 있었겠지만, 그렇게 했다면 동작 방식, 장애 유형, SLA, 지원 시스템이 제각각이고 API도 서로 다르거나 아예 없는 여러 시스템이 뒤엉킨 복잡한 상황에 처했을 것입니다.

결국 자체 네트워크를 구축해야 했고, 이는 네트워크가 다음 세 가지 특성을 갖춰야 한다는 의미였습니다:

1. R1을 해결하려면 여러 클라우드 제공업체와 전 세계에 걸쳐 모든 리전을 연결하는 사설 네트워크를 구축해야 했습니다. 이를 위한 최선의 방법은 주요 클라우드 리전에서 클라우드 제공업체와 피어링하는 동시에 주요 코로케이션 시설의 전용 연결 링크를 함께 활용하는 것입니다. 피어링은 최상의 SLA를 보장하지 않지만, 전용 연결 링크는 클라우드 리전 내에서 SLA를 보장합니다.
   
2. 에지 위치의 머신에 대한 R2를 해결하려면 각 에지 위치에서 여러 개의 액티브-액티브 링크를 지원해야 했습니다. 이러한 링크는 저비용 인터넷 링크(셀룰러 또는 케이블/광섬유 기반) 및/또는 고비용 전용 링크(광섬유/이더넷 기반)일 수 있습니다. 성능과 안정성을 확보하려면 신뢰할 수 없는 인터넷을 통해 트래픽을 장거리 전송하는 대신, 에지 위치에서 최대한 가까운 곳에서 트래픽의 부하를 분산하고 종단 처리해야 합니다. 업계에서는 이 기능을 SD-WAN이라고도 합니다.
   
3. 인터넷 사용자와 엣지 애플리케이션을 위한 R2를 해결하려면 TLS 트래픽을 엣지에서 종단해야 했으며, 이 역시 사용자와 최대한 가까운 곳에서 이루어져야 했습니다. 이를 위해 이동통신사 및 콘텐츠 제공업체와 긴밀하게 피어링하고, 최적의 라우팅을 보장하도록 여러 트랜짓 제공업체를 통해 트래픽을 유입하는 네트워크 엣지 로케이션을 구축해야 했습니다.

이 세 가지 특성을 충족하기 위해 많은 작업이 필요했습니다. 그중에서도 크게 다섯 가지 핵심 항목을 살펴보겠습니다:

1. 자체 네트워크 장비를 갖춘 글로벌 네트워크 PoP — 결국 주요 대도시권에 여러 네트워크 PoP를 구축해야 했습니다. 플랫폼 구축 초기에는 유럽의 파리, 런던, 암스테르담, 룩셈부르크와 미국의 뉴욕에 PoP를 마련한 뒤 시애틀, 산호세, 애슈번, 프랑크푸르트, 싱가포르, 도쿄로 확장했습니다. 이를 통해 전 세계를 아우르는 서비스 범위를 확보하고 모든 주요 클라우드 제공업체와 가까운 위치에 자리 잡을 수 있었습니다. 글로벌 파트너로 Equinix를 선택했으며, Equinix가 최적의 선택이 아닌 지역에서는 Interxion, Telehouse/KDDI, Westin을 추가로 활용했습니다. 자동화의 가치를 중시하기 때문에 스위칭 및 라우팅 장비로 Juniper Networks를, 400G 및 100G 링크를 통한 도시권 광섬유 상호 연결에는 Adva를 선택했습니다.
2. 프라이빗 백본 — 이러한 모든 PoP를 높은 성능과 안정성으로 연결하기 위해, 여러 트랜짓 제공업체 위에 오버레이 네트워크를 구축하는 대신 Zayo, Centurylink, EuNetworks 등의 제공업체가 공급하는 여러 100G 웨이브를 조합하여 글로벌 프라이빗 백본을 구축하기로 했습니다. 많은 CDN(예: Cloudflare, Fastly) 및 보안 제공업체(예: Zscaler)는 다운스트림 트래픽을 처리하기 때문에 트랜짓 및 피어링 연결에 전적으로 의존하지만, 당사는 애플리케이션 간의 이스트-웨스트 트래픽을 처리하므로 프라이빗 백본과 트랜짓을 함께 사용하는 데에는 충분한 이유가 있다고 생각합니다. 이는 당사만의 방식이 아닙니다. 모든 주요 클라우드 제공업체는 각자의 클라우드 리전을 연결하는 글로벌 프라이빗 백본을 보유하고 있습니다.
3. 인터넷 피어링 및 트랜짓 제공업체 — 다양성을 높이고 사용자와 콘텐츠 또는 SaaS 제공업체에 연결할 때 최상의 성능을 달성하려면 가능한 한 많은 통신 사업자 및 콘텐츠 제공업체와 직접 피어링하는 것이 이상적입니다. 당사는 PeeringDB에 명시된 대로 여러 인터넷 익스체인지에서 피어링하고 있습니다(PeeringDB의 ASN-35280). 모든 트래픽을 피어링 연결로 처리할 수 있는 것은 아니므로 이때 트랜짓 연결이 필요합니다. 품질을 유지하려면 트랜짓 링크와 피어링 포트를 매우 세심하게 모니터링해야 합니다. 이에 따라 당사는 전 세계 여러 지역에서 서비스를 제공하기 위해 NTT, CenturyLink, Telia와 같은 최고의 Tier-1 제공업체를 선정했습니다.
4. 클라우드 피어링 및 상호 연결 — 최근 클라우드 제공업체와 직접 피어링을 시작했지만, 이들은 해당 연결에 대해 SLA를 보장하지 않습니다. 예를 들어 시애틀의 피어링 연결 지점(Westin 시설)에서는 3대 주요 클라우드 제공업체 모두에 직접 연결할 수 있습니다. 이러한 연결은 단순히 트랜짓 제공업체를 경유하는 것보다 낫지만, SLA와 추가 기능이 제공되는 클라우드 제공업체와의 전용 연결(AWS Direct Connect, Azure Express Route, GCP Dedicated Interconnect)을 추가하여 네트워크를 보강하기 시작했습니다. 이러한 링크는 비용이 많이 들고 내부 VPC/VNET 서브넷에만 액세스할 수 있지만, 최상의 연결성을 제공합니다.
5. 소프트웨어 게이트웨이 — 당사의 PoP 위치에 직접 연결되지 않은 클라우드 또는 엣지 위치에는 소프트웨어 게이트웨이를 설치합니다. 이러한 게이트웨이가 제공하는 고급 기능은 이 블로그의 뒷부분에서 다루겠지만, 전송 계층과 관련된 기능 중 하나는 게이트웨이가 이중화를 위해 여러 네트워크 PoP에 보안 VPN(IPsec 또는 SSL) 터널을 자동으로 생성하고 PoP로 향하는 트래픽의 부하를 분산하는 것입니다. 또한 클라우드 환경에서는 이러한 게이트웨이가 클라우드 제공업체의 NAT 게이트웨이를 통해 가장 가까운 PoP로 아웃바운드 연결을 생성하고 당사의 글로벌 사설 네트워크로 진입할 수 있는 연결 지점을 제공합니다. 따라서 공용 네트워크를 경유하거나 공용 IP 주소를 사용해 여러 클라우드 위치의 애플리케이션 클러스터를 연결할 필요가 없습니다.

개발 초기부터 글로벌 네트워크를 구축하고 운영하려면 시간과 기술이 필요하며, 이러한 전문 역량을 확보해야 한다는 사실을 깨달았습니다. 프랑스 파리에 본사를 둔 보안 업체 Acorus Networks의 창립자들과 수개월간 논의한 끝에 Acorus를 Volterra와 합병했습니다. 이를 통해 글로벌 인프라 구축과 네트워크 확장 문제를 해결할 수 있었습니다. Acorus는 이미 훌륭한 네트워크와 운영팀을 자체적으로 구축한 상태였으며, 이 팀은 Ansible을 사용해 물리적 네트워크 구성을 완전히 자동화하고 소프트웨어팀이 사용할 수 있는 텔레메트리 및 구성용 외부 API를 개발했습니다.

그림 1: 글로벌 네트워크를 통한 앱 간 또는 사용자/머신과 앱 간 트래픽

이제 높은 안정성과 성능을 갖춘 글로벌 사설 네트워크 구축에 전념하는 팀이 생기면서, 그림 1과 같이 엣지 또는 클라우드 위치 전반에서 애플리케이션 간 트래픽과 사용자/머신에서 애플리케이션으로 향하는 트래픽의 문제를 모두 손쉽게 해결할 수 있게 되었습니다. 또한 네트워크 PoP의 컴퓨팅 및 스토리지 인프라를 활용해 API 종단 처리, 애플리케이션 보안, 워크로드 오프로딩(엣지 또는 클라우드에서 네트워크로 이전) 기능도 네트워크에 추가할 수 있었습니다. 이를 통해 앞으로도 오랫동안 역량을 지속적으로 발전시키고, 수요에 따라 네트워크 범위와 서비스 카탈로그를 손쉽게 확장할 수 있을 것입니다.

애플리케이션을 위한 네트워크 서비스 — 멀티 클라우드, 프라이빗 클라우드, 엣지?

글로벌 네트워크가 정상적으로 작동하게 된 후에는 애플리케이션 클러스터와 워크로드를 추가해야 했습니다. 이러한 워크로드에는 애플리케이션 수준의 연결 및 보안 서비스가 별도로 필요합니다.

앞서 블로그에서 설명했듯이, 이 플랫폼의 목표는 여러 환경(클라우드, 엣지 및 당사 네트워크 PoP)에서 실행되는 워크로드를 관리하는 팀의 생산성을 높이고 복잡성을 줄이는 것이었습니다.

모든 클라우드 제공업체에서는 애플리케이션 클러스터에 안전하게 연결하기 위해 다양한 클라우드 리소스를 구성하고 관리하며 모니터링해야 합니다. 예를 들어 Google Cloud에서 애플리케이션 클러스터를 위한 엔드투엔드 네트워크 서비스를 구성하려면 다음과 같은 여러 서비스 세트를 관리해야 합니다:

광역 네트워크(WAN) 서비스

• 가상 사설망(VPN) 및/또는 상호 연결
• DNS 서버
• DDoS 및 WAFS

애플리케이션 네트워킹 서비스

• 애플리케이션 로드 밸런서, 네트워크 로드 밸런서 (공개 API)
• 애플리케이션 로드 밸런서, 네트워크 로드 밸런서 (내부)
• 서비스 메시 (앱 간)

네트워크 라우팅 및 격리 서비스

• 가상 프라이빗 클라우드 네트워크(VPC 네트워크)
• 서브넷, IP 범위, 경로
• NAT 게이트웨이, 방화벽 규칙

물론 이는 큰 도전이었겠지만, 각 클라우드 제공업체의 환경을 통합하는 구성 및 운영 계층을 구축하는 방식으로 이 문제를 해결할 수도 있었습니다. 그러나 클라우드 제공업체의 서비스는 우리의 모든 요구 사항을 충족하지 못했고(예: CSP에는 애플리케이션 및 API 보안 기능이 없음), 동급 최고의 서비스도 아니며 계속해서 변화하고 있었기 때문에, 이러한 방식으로는 문제를 해결할 수 없다는 것을 알고 있었습니다.

또한 네트워크 PoP와 엣지 사이트는 어떻게 해야 할까요? 하드웨어 또는 소프트웨어 공급업체로부터 유사한 기능을 확보해 모두 통합해야 할 것입니다. 예를 들어 라우팅+NAT+VPN에는 Cisco/Juniper를, 로드 밸런싱과 방화벽에는 F5를 사용하는 식입니다. 엣지 위치에서는 클라우드 제공업체도 대형 네트워크 공급업체도 리소스가 제한된 환경의 네트워크 서비스 문제를 해결할 수 없기 때문에 문제가 더욱 복잡해집니다. 엣지를 위한 또 다른 잠재적 방안은 모든 애플리케이션 연결, 보안 및 네트워크 서비스를 글로벌 네트워크로 이전하는 것이었지만, 동일한 엣지 사이트 내의 앱 간 트래픽에도 이러한 서비스 중 일부가 필요했기 때문에 이 방안은 효과가 없을 것이 분명했습니다.

많은 논의를 거치고 시장 전반을 살펴본 결과, 여러 서비스 제공업체와 벤더의 구성, 텔레메트리, 모니터링, 알림 기능을 통합하고 이들의 로드맵과 API 변경 사항을 지속적으로 따라가는 것은 단순성과 속도라는 우리의 목표에 어긋난다는 사실을 깨달았습니다.

플랫폼 전반에서 해결해야 했던 또 다른 문제는 멀티테넌시였습니다. WAN 서비스와 네트워크 라우팅에서는 비교적 쉽게 구현할 수 있었지만, 시중에 나와 있는 대부분의 로드 밸런서가 멀티테넌시를 전혀 지원하지 않거나 지원 범위가 매우 제한적이어서 애플리케이션 네트워킹 서비스에서는 구현하기가 어려웠습니다.

새로운 L3-L7+ 네트워크 데이터 경로

그 결과, 우리는 이 과제에 도전하여 네트워크 라우팅 서비스뿐만 아니라 애플리케이션, 보안 및 광역 네트워크 서비스까지 제공하는 고성능 네트워크 데이터 경로를 구축하기로 했습니다. 이를 통해 하이브리드 및 분산 클라우드 환경 전반에서 서비스 포트폴리오를 통합하고 퍼블릭 클라우드의 네이티브 서비스에 대한 의존도를 최소화할 수 있습니다.

우리 팀은 네트워킹 분야에서 풍부한 경험을 보유하고 있었고, 이전에 Contrail/Juniper에서 근무할 때도 이와 같은 문제를 다뤄 본 적이 있었습니다. 따라서 이 문제를 해결하는 최선의 방법은 처음부터 새롭게 시작하여, 어떤 클라우드나 엣지 환경에서도 실행할 수 있고 플랫폼에서 중앙 집중식으로 관리되는 단일 데이터 경로에 L3부터 L7+까지의 서비스를 통합한 완전히 새로운 네트워킹 솔루션을 구축하는 것이라고 판단했습니다.

이 새로운 데이터 경로의 설계를 시작하기 위해 가장 적합한 프로젝트를 선택했습니다. L3-L4에는 이미 6년간 개발해 온 OpenContrail vRouter를, L7에는 대규모 커뮤니티의 지원을 받는 Envoy를 채택했습니다. 하지만 새로운 통합 L3-L7+ 데이터 경로를 구축하려면 Envoy 멀티테넌시, Envoy용 dpdk, 사용자 공간 dpdk TCP 스택, 네트워크 정책, SSL/IPSec VPN, http connect, 동적 리버스 프록시, 투명 포워드 프록시, API 게이트웨이, 프로그래밍 가능한 애플리케이션 정책, DDoS 방어를 위한 고속 ACL, PKI ID 통합, Chrome v8 엔진, 애플리케이션 및 네트워크 보안 등 여러 기능을 변경하고 추가해야 했습니다.

그림 2: 네트워크 데이터 경로

이 데이터 경로는(그림 2에 표시된 것처럼) 애플리케이션 클러스터의 인그레스/이그레스 게이트웨이, 엣지의 소프트웨어 게이트웨이로 배포되며, 단일 클러스터 내부 또는 여러 클러스터 간에 서비스 메시 기능을 제공하거나 글로벌 PoP에서 네트워크 서비스를 제공하는 데 사용됩니다.

플랫폼의 멀티테넌시 요구 사항(이전 블로그에서 다룸)에 부합하려면 이 네트워크 데이터 경로에도 완전한 멀티테넌시를 구현해야 했습니다. vRouter가 이미 VRF를 지원하고 있었기 때문에 라우팅 계층에서는 비교적 간단했지만, Envoy를 멀티테넌트 방식으로 작동하도록 변경해야 했습니다. 커널 TCP 스택을 사용하지 않았으므로 Envoy의 TCP 소켓 인터페이스를 변경하고 VRF 인식 기능을 추가했습니다.

이 데이터 경로는 API 보안, 애플리케이션 방화벽 및 네트워크 보안 기능도 수행해야 했습니다. 이를 위해 알고리즘 기법과 머신 추론을 함께 활용했으며, 이 주제는 향후 블로그 게시물에서 다룰 예정입니다.

이 네트워크 데이터 경로를 구축함으로써 다음과 같은 여러 이점을 얻었습니다:

일관된 구성, 제어 및 관측성을 갖춘 완전한 L3~L7+ 기능

단일 클러스터 내 스케일아웃을 지원하므로 설치 공간이 매우 작고 성능이 낮은 엣지 디바이스부터 네트워크 또는 퍼블릭 클라우드 환경에서 100Gbps 이상의 용량이 필요한 경우까지 폭넓게 지원할 수 있습니다.

특정 네트워크 벤더나 클라우드 제공업체에 의존하지 않고 네트워크 데이터 경로에 새로운 기능을 신속하게 추가

어떤 환경에서든 유사한 장애 및 성능 특성을 제공하는 공통 솔루션으로, 운영팀에 매우 중요합니다.

이제 이 새로운 네트워크 데이터 경로를 사용해 여러 앱 클러스터를 배포할 수 있게 되었으므로, 이를 구성하고 제어하며 모니터링할 수 있는 전 세계에 분산된 제어 플레인을 구축하는 것이 매우 중요했습니다.

분산 네트워크를 위해 특별히 설계된 제어 플레인

플랫폼 팀은 수많은 분산 데이터 경로 처리 노드를 관리하기 위한 분산 제어 영역을 구축하면서 여러 문제를 해결해야 했습니다. 새로운 데이터 경로를 구축했기 때문에 바로 활용할 수 있는 제어 영역이 없었고, 단일 클러스터(클라우드, 엣지 또는 네트워크 PoP) 내에서 실행되는 여러 데이터 경로를 관리하기 위한 자체 로컬 제어 영역을 개발해야 했습니다. 이러한 데이터 경로 노드에는 구성 변경 및 경로 업데이트 관리, 상태 확인, 서비스 검색, BGP와 같은 프로토콜을 사용한 다른 네트워크 장치와의 피어링, 메트릭 및 액세스 로그 집계 등을 수행할 로컬 제어 영역이 필요했습니다. 여러 로컬 제어 영역을 관리하는 분산 제어 영역 — 글로벌 네트워크 PoP에는 분산 제어 영역이 실행되고 있으며(그림 3), 이 제어 영역은 로컬 제어 영역의 구성 관리, 각 로컬 제어 영역 간 운영 상태 배포, 각 노드의 데이터 수집을 담당합니다. 운영 상태를 배포하기 위해 최종 일관성을 제공하고 안정성이 뛰어난 BGP를 사용하기로 했습니다. OpenContrail의 일부로 확장성이 매우 뛰어난 멀티스레드 BGP 구현을 구축한 경험이 있었기 때문에 이를 활용하고, 부하 분산을 위한 상태 확인 배포, http/api 엔드포인트, 정책 전파 등의 확장 기능을 추가했습니다.

그림 3: 분산 및 로컬 제어 플레인

또한 그림 4와 같이 멀티테넌시를 제공하기 위해 분산형 컨트롤 플레인과 함께 사용되는 중앙 집중식 관리 플레인이 AWS와 Azure의 두 클라우드 리전에서 실행됩니다. SRE 팀은 여러 테넌트를 생성할 수 있으며, 각 테넌트는 글로벌 네트워크 전반에서 다른 테넌트와 완전히 격리됩니다. 테넌트 간 라우팅은 ‘퍼블릭 네트워크’를 통해서만 가능합니다. 한 테넌트 내에서는 서로 다른 네임스페이스의 서비스가 HTTP/API/네트워크 라우팅 및 보안 규칙에 따라 서로 통신할 수 있습니다.

그림 4: 네트워크의 멀티테넌시

컨트롤 플레인은 당사 SRE 팀만 관리할 수 있는 별도의 테넌트와 격리된 네임스페이스에서 Kubernetes 워크로드로 실행됩니다. 따라서 개발자나 고객이 이 서비스를 중단시킬 수 없습니다. 또한 컨트롤 플레인이 분산되어 있으므로 한 위치의 컨트롤 플레인에 장애가 발생하더라도 전체 서비스에는 영향을 미치지 않습니다.

전 세계에 분산된 애플리케이션 게이트웨이란?

글로벌 네트워크에 필요한 사항을 파악하고 앱 클러스터를 위한 L3~L7+ 네트워크 서비스의 요구 사항(새로운 데이터 경로 및 분산형 제어 영역)을 정의하고 나자, 제품 팀은 우리의 업무를 한층 더 흥미진진하게 만들 추가 요구 사항을 제시했습니다. 요약하자면, 다음 기능을 갖춘 글로벌 클러스터 간 서비스 메시를 구축해 달라는 것이었습니다:

1. 글로벌 네트워크 전반에서 애플리케이션 연결성(라우팅, 제어 및 관측 가능성)은 제공하되, 네트워크 연결성은 제공하지 않습니다(적어도 기본적으로는 제공하지 않음). 그 이유는 간단합니다. 네트워크를 연결하면 복잡한 방화벽 규칙을 만들어야만 해결할 수 있는 온갖 보안 취약점이 발생하며, 이로 인해 변경 관리가 더 어려워지기 때문입니다.
   
2. 엔드포인트 상태와 안정성 정보를 활용해 네트워크 PoP의 엣지 로드 밸런서를 개선합니다. 현재 엣지 로드 밸런서(예: AWS Global Accelerator 또는 Akamai 글로벌 로드 밸런서)는 엣지 위치에서 백엔드로의 라우팅을 오리진 서버의 상태에 따라 결정합니다. 대부분의 경우 오리진 서버는 실제 서비스 엔드포인트가 아니라 또 다른 로드 밸런서입니다. 저희 팀은 각 엣지 로드 밸런서가 오리진 로드 밸런서의 상태뿐만 아니라 모든 클러스터에 있는 전체 엔드포인트의 상태를 기반으로 트래픽을 관리할 수 있기를 원했습니다.
   
3. GSLB 의사 결정의 일환으로 에지 사이트(네트워크 PoP) 선택 개선 — 현재 애니캐스트 또는 GSLB는 사용자/클라이언트의 인그레스 트래픽을 가장 가까운 에지 사이트로 라우팅합니다. 그러나 여러 가지 이유(백본 및/또는 트랜짓 제공업체의 부하)로 인해 사용자를 다른 인그레스 에지 사이트로 보내는 것이 더 나을 수 있습니다.

요구 사항 #2와 #3의 목표는 클라이언트와 서버 간 연결의 응답 시간과 성능을 개선하는 것이었으며, 이는 애플리케이션 간 통신이나 대규모 SaaS 애플리케이션에서 매우 중요합니다. 요구 사항 #2와 #3을 충족하기 위한 최선의 접근 방식은 분산 프록시(그림 5), 즉 인그레스 프록시와 이그레스 프록시를 구축하고 네트워크 주소가 아닌 애플리케이션 주소를 기반으로 라우팅하는 것임이 분명했습니다. 또한 분산 제어 플레인과 BGP 확장(앞서 설명한 바와 같음)을 활용하여 서비스 엔드포인트(또는 서버)의 상태 정보를 분산하기로 했습니다. 이러한 분산 프록시 구현은 아래 다이어그램에 나와 있습니다.

그림 5: 분산형 애플리케이션 게이트웨이

완전한 L3-L7+ 네트워크 스택을 갖춘 분산 프록시로 발전했기 때문에 이를 전 세계에 분산된 애플리케이션 게이트웨이라고 부릅니다. 이제 네트워크 데이터 경로에서 제공되는 모든 기능을 글로벌 네트워크 전반에서 사용할 수 있습니다. 예를 들어 HTTP 또는 API 기반의 부하 분산 및 라우팅, 엣지에서의 정책 적용, API 변환, 사용자와 더 가까운 위치에서의 TLS 종료 등이 있습니다.

분산 애플리케이션 게이트웨이가 제공하는 이점

팀은 전 세계에 분산된 애플리케이션 게이트웨이를 구현함으로써 다양한 이점을 얻을 수 있었습니다. 이러한 이점은 운영 개선, 보안, 성능 및 총소유비용(TCO) 측면에서 나타났습니다:

1. 보안 및 규정 준수 — 네트워크 액세스 없이 사이트 간 애플리케이션 액세스를 제공할 수 있게 되면서 엣지 또는 클라우드 위치의 애플리케이션 클러스터 전반에서 보안 및 규정 준수가 크게 향상되었습니다. 또한 사이트 간 네트워크 액세스가 없고 애플리케이션 클러스터를 연결하면서도 각 사이트의 NAT 뒤에 완전히 배치할 수 있으므로 복잡한 방화벽 구성 관리의 필요성도 줄었습니다.
   
2. 운영 오버헤드 — 네트워크 PoP와 엣지/클라우드 사이트 전반에 공통 네트워크 서비스 세트를 적용함으로써 SRE 또는 DevOps 팀이 서로 다른 서비스 세트 간의 구성 및 관측 가능성을 통합할 필요가 없어졌습니다.
   
3. 성능 및 안정성 향상 — 당사는 네트워크 PoP에서 최적의 로드 밸런서가 아닌 가장 적합하고 정상적으로 작동하는 엔드포인트로 트래픽을 라우팅하므로, 이 플랫폼은 애플리케이션 간 또는 사용자와 애플리케이션 간 트래픽에서 시중의 다른 어떤 솔루션보다 훨씬 뛰어난 성능을 제공합니다.
   
4. 총소유비용(TCO) 절감 — 대규모 SaaS 애플리케이션에서는 전 세계 여러 데이터 센터에서 수백 개의 서비스 복제본을 제공하는 것이 일반적입니다. 이를 효과적으로 구현하려면 SaaS 제공업체가 복잡한 기능을 구축해야 하지만, 이제 이 분산형 애플리케이션 게이트웨이를 통해 모든 고객이 이러한 기능을 이용할 수 있습니다.

계속됩니다…

이 블로그 시리즈에서는 퍼블릭 클라우드의 여러 애플리케이션 클러스터, 프라이빗 네트워크 PoP, 엣지 사이트를 기반으로 전 세계에 분산된 SaaS 서비스를 구축하고 운영하기 위해 필요했던 다양한 요소를 다룹니다. 다음 주제는 플랫폼 및 데이터 보안입니다…

작성자 소개

Ankur Singla

Ankur Singla의 다른 블로그 게시물