행성 규모의 크로스 클라우드 서비스 메쉬 연합을 구상해보세요. 이 연합은 AWS, Azure 및 GCP에서 실행되는 Kubernetes 클러스터 간의 트래픽 관리, 상호 TLS 인증 및 가시성을 통합하여 클라우드 경계를 초월하는 서비스 간 호출에 대해 50ms 이하의 동쪽-서쪽 대기 시간을 보장하고 비대칭 네트워크 분할 동안 제로 트러스트 보안 정책을 유지하며 공유 제어 평면 없이 일회성 엣지 컴퓨팅 노드에 대한 매쉬 확장을 원활하게 구현합니다.

질문의 역사

서비스 메쉬 아키텍처는 마이크로서비스 통신 복잡성을 해결하기 위해 Istio 및 Linkerd와 같은 사이드카 기반 솔루션으로 단일형 API 게이트웨이에서 발전했습니다. 기업들이 공급자 종속성을 피하고 탄력성을 강화하기 위해 다중 클라우드 전략을 채택함에 따라 이 메쉬를 이질적인 클라우드 공급자 간에 연합할 필요성이 중요해졌습니다. 초기 시도는 중앙 집중식 제어 평면이나 VPN 허브-스포크 모델에 의존하여 글로벌 애플리케이션을 위해 허용할 수 없는 대기 시간 및 단일 실패 지점을 도입했습니다. 이 질문은 금융 거래 플랫폼 및 엄격한 대기 시간 SLA 및 오프라인 기능을 요구하는 IoT 배포에서 발견되는 과제를 종합합니다.

문제

AWS, Azure 및 GCP 간에 서비스 메쉬를 연합하는 것은 호환되지 않는 네트워킹 추상화, 다양한 CNI 구현 및 독점적인 ID 시스템 때문에 고유한 장애물을 제공합니다. 크로스 클라우드 트래픽은 일반적으로 공용 인터넷 또는 비싼 전용 연결을 통과하여 변동 대기 시간 및 패킷 손실을 초래하고 50ms 이하 요구 사항을 위반합니다. 비대칭 네트워크 분할 동안 (AWS us-east-1이 GCP europe-west1에 도달할 수 있지만 Azure southeast-asia에는 도달할 수 없는 경우) 작업 부하가 중앙 집중식 OIDC 제공자에 의존하는 경우 제로 트러스트 mTLS 인증을 유지하는 것이 불가능합니다. 더욱이, 일회성 엣지 노드 (예: 5G MEC 장치 또는 자율 주행 차량 유닛)는 영구적인 신원이 부족하고 중앙 집중식 제어 평면에 오랜 기간 연결을 유지할 수 없지만 수동 개입 없이 보안 경계에 즉시 등록해야 합니다.

해결책

네트워크 토폴로우와 분리된 작업 부하 신원을 위해 SPIFFE/SPIRE를 활용한 분산형 Istio 주-주 연합 토폴로지를 구현합니다.

각 클라우드 제공자에 지역 인그레스 게이트웨이를 배포하고, 대기 시간 인식 라우팅 및 클러스터 간 로드 밸런싱을 위해 WASM 필터가 있는 Envoy 프록시로 구성합니다. 지역 게이트웨이 간에 WireGuard 또는 IPsec 터널을 설정하여 트랜스포트 계층에서 트래픽을 암호화하면서 서비스 수준 mTLS를 위한 직접적인 사이드카-사이드카 통신을 허용합니다. 각 지역에 SPIRE 서버를 구성하고, CloudFront 배포가 있는 S3 버킷에 게시된 연합 신뢰 번들을 사용하여 분할 동안 사용되는 SVID 검증을 가능하게 합니다. 엣지 노드의 경우, S3에 호스팅된 구성 및 STS 임시 자격 증명을 통해 부트스트랩하는 Istio 주변 메쉬 ztunnel 에이전트를 활용하여 지역 게이트웨이와의 상호 TLS를 설정하되, 지속적인 제어 평면 연결 없이 수행합니다.

생활 속 상황

글로벌 하이빈도 거래 플랫폼은 AWS us-east-1의 주문 실행 서비스를 GCP europe-west1의 리스크 분석 마이크로서비스 및 Azure southeast-asia의 고객 포트폴리오 데이터와 연결해야 했습니다. 사업의 명령은 arbitrage 손실을 방지하기 위해 크로스 클라우드 리스크 스코어링 호출에 대해 50ms 이하의 왕복 대기 시간을 요구했습니다. 북미와 유럽 간의 해저 케이블 차단이 시뮬레이션된 동안 회사의 온프레미스 데이터 센터에 있는 기존 IPSec VPN 허브는 병목현상이 되어 대기 시간을 180ms로 증가시키고 TCP 타임아웃을 유발하여 거래를 12분 동안 중단했습니다.

문제 설명

기존 아키텍처는 인증을 위해 중앙 집중식 F5 로드 밸런서 클러스터와 Active Directory 도메인 서비스를 의존하여 단일 실패 지점을 만들었습니다. 네트워크 분할이 발생했을 때 Azure 작업 부하가 중앙 AD 서버에 대해 JWT 토큰을 검증할 수 없어 인증 실패가 연속적으로 발생했습니다. 또한 거래처의 새로운 5G 엣지 컴퓨트 노드(정상적으로 NVIDIA Jetson 장치를 실행함)는 시장 데이터를 로컬로 처리하기 위해 메쉬에 조인해야 했지만 표준 Istio 사이드카 모델은 장치의 2GB RAM 한계를 초과하고 VPN 인증서를 수동으로 45 분 동안 프로비전을 요구했습니다.

해결책 A: 중앙 집중식 정책 관리가 있는 네이티브 클라우드 전환 피어링

이 접근 방식은 AWS Transit Gateway 피어링을 Azure Virtual WAN 및 GCP Cloud Interconnect와 결합하여 완전 메쉬 네트워크 토폴로지를 생성합니다. 모든 크로스 클라우드 트래픽은 Palo Alto 또는 Fortinet 장비가 관리하는 중앙 집중식 엔터프라이즈 방화벽 클러스터를 통과하여 친숙한 보안 경계를 제공합니다. 구성은 클라우드 지역의 확장 시 연결 유지를 위해 BGP 경로 전파에 의존합니다.

• 장점: 네이티브 통합은 100Gbps까지의 높은 대역폭과 네이티브 클라우드 도구 또는 Aviatrix 컨트롤러를 통한 준수를 위한 중앙 집중식 가시성을 제공합니다. 이 접근 방식은 MPLS 백본에 익숙한 기존 네트워크 엔지니어링 작업 흐름에 최소한의 변경을 요구합니다.
• 단점: 데이터 이그레스 비용은 크로스 클라우드 트래픽에 대해 GB당 $0.09를 초과하여 거래 플랫폼 볼륨에서 월 예상 청구서가 $500K를 초과합니다. 아키텍처는 중앙 방화벽 클러스터에 병목 현상을 도입하여 80-120ms 대기 시간을 추가하고 50ms 이하의 요구사항을 위반합니다. 정적 IP 주소나 BGP 피어링 기능이 부족한 일회성 엣지 노드를 위한 합리적인 등록 경로가 없습니다.

해결책 B: Cilium 클러스터 메쉬 및 eBPF 데이터플레인

이 아키텍처는 모든 Kubernetes 클러스터에 Cilium을 배포하고 eBPF를 활용하여 커널 수준 로드 밸런싱과 WireGuard 암호화를 지원합니다. Cilium ClusterMesh는 각 클라우드의 etcd 클러스터 간에 Kubernetes Endpoints를 동기화하여 다중 지역 서비스 검색을 가능하게 합니다. 데이터플레인은 iptables를 완전히 우회하여 처리 오버헤드를 서브 밀리세컨드 수준으로 줄이고 사이드카 없이 Hubble을 통한 가시성을 제공합니다.

• 장점: eBPF는 최소한의 CPU 오버헤드로 뛰어난 성능을 제공하며 레이어 4 트래픽에 대한 Envoy 사이드카 필요성을 제거합니다. 이 솔루션은 투명한 암호화와 상세한 네트워크 정책을 통해 뛰어난 보안을 제공합니다.
• 단점: Cilium은 Azure CNI 오버레이 모드와 기존 Calico 정책 구현과 호환되지 않는 동질적인 CNI 구성이 필요합니다. 클라우드 경계를 통한 BGP 피어링은 클라우드 네트워크 팀과의 복잡한 조정을 요구하며 거래 프로토콜에 필수적인 세분화된 gRPC 메서드 수준 라우팅이 부족합니다. 엣지 노드 지원은 Cilium이 지속적인 Kubernetes 노드 신원을 가정하기 때문에 제한됩니다.

해결책 C: SPIFFE 및 주변 메쉬를 활용한 분산형 Istio 연합

각 클라우드가 자체 istiod 제어 평면을 유지하는 Istio 주-주 연합을 채택하고 GitOps 파이프라인을 통해 Flux 또는 ArgoCD를 사용하여 동기화합니다. 각 지역에 SPIRE를 구현하여 S3 버킷에 연합 신뢰 번들을 저장하고 CloudFront 엣지 캐싱을 통해 파티션 복원력을 확보합니다. 엣지 노드에서는 사이드카 대신 리소스를 절약하기 위해 Istio 주변 메쉬 ztunnel 에이전트를 사용합니다. 지역 게이트웨이는 WireGuard 터널을 설정하여 클라우드 간에 연결을 허용하고, Envoy 사이드카가 중앙 허브를 통과하지 않고 직접 통신할 수 있습니다.

• 장점: Envoy 사이드카는 금융 프로토콜에 필요한 gRPC 라우팅, 회선 차단 및 재시도 정책을 포함한 정교한 트래픽 관리를 가능하게 합니다. 네트워크 분할 동안 SVID가 중앙 집중식 OIDC 제공자에 의존하지 않고 S3에 게시된 번들을 검증하기 때문에 지역적으로 캐시된 SPIFFE 신원으로 살아남습니다. Ztunnel은 각 노드에서 50MB RAM만 소비하여 100MB의 POD당 메모리 소비를 줄이며 NVIDIA Jetson 장치가 완전히 참여할 수 있도록 합니다.
• 단점: 팀은 독립적인 세 개의 제어 평면을 관리하고 EKS, AKS 및 GKE 간의 CRD 버전 호환성을 보장해야 하므로 운영 복잡성이 크게 증가합니다. 초기 부트스트랩은 크로스 클라우드 S3 접근을 위한 IAM 역할 구성을 필요로 합니다.

선택된 솔루션 및 근거

솔루션 C가 50ms 이하의 대기 시간 요구 사항을 WireGuard 터널을 통한 Envoy 사이드카 간의 직접 통신으로 독특하게 충족시켰기 때문에 선택되었습니다. 이는 중앙 집중식 OIDC 제공자에 의존하지 않는 SPIFFE 기반 신원을 통해 파티션 동안 제로 트러스트 보안 보장을 유지했습니다. 아키텍처는 주변 메쉬 ztunnel을 통해 리소스 제한을 받는 엣지 노드를 지원했으며, 솔루션 A 및 B는 비용, 대기 시간 또는 엣지 제약 문제로 실패했습니다.

결과

구현 후 크로스 클라우드 대기 시간이 38ms P99로 안정적으로 유지되었으며, 50ms SLA를 잘 초과하는 성능을 보여주었습니다. 이후 AWS와 Azure 간의 예기치 않은 파티션 동안 시스템은 캐시된 SVID와 양호하나 안전한 라우팅 규칙을 활용하여 94%의 거래 처리량을 유지했습니다. 엣지 노드 프로비저닝 시간은 자동화된 S3 부트스트랩 스크립트를 통해 45분에서 90초로 감소했습니다. 월간 네트워킹 비용은 기본 Transit Gateway 피어링 추정치에 비해 60% 감소하여 월 약 $300K의 비용을 절감했습니다.

후보자들이 자주 놓치는 부분

질문: SPIRE가 네트워크 분할 중 지역 SPIRE 서버에 접근할 수 없을 때 작업 부하 가장에 대한 위조를 어떻게 방지합니까?

답변: 각 노드에서 실행되는 SPIRE 에이전트는 X.509 SVID 인증서 및 공개 키 신뢰 번들의 로컬 캐시를 유지합니다. 작업 부하가 mTLS를 설정하려고 할 때 피어는 실시간 서버를 쿼리하는 대신 로컬 캐시된 번들에 대해 SVID를 검증하여 파티션 동안 인증이 성공하도록 보장합니다. SVID는 짧은 TTL(일반적으로 5분)을 포함하며 작업 부하의 특정 개인 키에 바인딩되어, 공격자가 캐시된 인증서를 가로채더라도 재전송 공격을 방지합니다. 파티션 중에 조인하는 새로운 작업 부하는 AWS IAM 인스턴스 ID 문서나 TPM EK 인증서와 같은 노드 수준의 인증자를 사용하여 로컬 에이전트에 의해 인증됩니다.

질문: Istio 주변 메쉬가 전통적인 사이드카 주입과 비교하여 일회성 엣지 노드의 리소스 소비를 어떻게 줄입니까?

답변: 전통적인 Istio는 각 애플리케이션 Pod에 Envoy 사이드카 컨테이너를 배포하여 각 인스턴스당 약 100MB의 RAM과 0.5 vCPU를 소모하게 하여 리소스 제한을 받는 엣지 장치(NVIDIA Jetson와 같은)의 리소스를 고갈시킵니다. 주변 메쉬는 노드 자체에 DaemonSet으로 ztunnel을 배포하여 모든 포드에서 mTLS 종료 및 레이어 4 라우팅을 공유함으로써 작업 부하당 오버헤드를 거의 제로로 줄입니다. Ztunnel은 커널 수준에서 패킷 리디렉션을 효율적으로 위해 eBPF를 사용하여 iptables 통과 비용을 피합니다. 자주 메쉬에 조인하고 나가는 일회성 엣지 노드를 위해 ztunnel은 지역 게이트웨이에 대한 단일 영구 연결 풀을 유지하며, 수백 개의 개별 사이드카가 동시에 초기화될 때 발생하는 연결 설정 폭풍과 메모리 급증을 제거합니다.

질문: 다중 클라우드 연합에서 독립적인 Istio 제어 평면 간의 구성 변화(drift)를 어떻게 방지합니까?

답변: VirtualService 및 AuthorizationPolicy 매니페스트를 단일 진실 소스로 간주하는 GitOps 파이프라인을 구현하고, 이는 연합된 Git 리포지토리에 저장됩니다. 각 지역 제어 평면은 S3를 사용하는 크로스 클라우드 액세스를 위한 IAM 역할 구성을 필요로 합니다.