이번 “Kubestronaut와 함께하는 커뮤니티 데이” 행사에 현장 질문으로 주신 내용을 공유합니다.
- 여러 리전에 걸쳐 메쉬를 구성하신거에 대해, 모든 클러스터가 같은 클라우드 환경에 있었나요? 만약 다른 클라우드 환경이면 고려해야 할 점 등이 따로 있을지 궁금합니다
전문가 Bro님들의 Insight 공유 부탁드립니다.
멀티 클라우드 환경에서 서비스 메시를 구성할 때는 멀티 클러스터와 겹치는 요소들이 분명 존재하지만, 실제 운영 난이도는 훨씬 더 높고 복합적이다. 이유는 단순히 "클러스터 수가 많아진다"는 차원이 아니라, 클라우드 간 네트워크·보안·아이덴티티·게이트웨이 모델·로깅/옵저버빌리티·정책 체계·부하 형태·비용 구조까지 모두 달라지기 때문이다. 그래서 멀티 클라우드 서비스 메시를 설계할 때는 클러스터 간 관계보다는 "클라우드 간 경계(boundary)와 차이"를 어떻게 흡수할지에 초점을 두게 된다.
우선 가장 중요한 요소는 네트워크 경계의 단절과 품질 편차다. 동일 클라우드 내 멀티 리전이라면 보통 전용 백본망과 일관된 네트워크 모델이 제공되지만, 서로 다른 클라우드 간에는 이를 기대할 수 없다. 트래픽은 VPN, VPC Peering Gateway, 전용선(Direct Connect / ExpressRoute) 같은 별도의 연결 계층을 통해 흐르고, 이 과정에서 레이턴시, 대역폭, MTU, NAT 정책이 통일되지 않는다. 결국 메시에 필요한 east-west 흐름이 “같은 네트워크처럼” 유지되지 못하는데, 이는 mTLS 핸드셰이크, XDS 동기화 속도, 워크로드 간 L7 라우팅 안정성에 영향을 미친다. 멀티 클라우드 메시가 기술적으로 가능하더라도, 성능 특성을 균일하게 유지하기 어려운 것은 이 때문이다.
보안과 인증 모델도 문제다. 클라우드마다 IAM 구조가 상이하고, CA 발급/키 관리 방식도 통일되어 있지 않다. 멀티 클러스터 환경에서 필요한 “공통 루트 오브 트러스트”를 멀티 클라우드로 확장하려면, 클라우드 간 PKI 통합, 외부 CA 사용, SPIFFE/SPIRE 기반의 ID 연동 등 추가 계층이 필요하다. 이 단계가 부실하면 메시 안에서 mTLS는 형식적으로는 동작하지만, 인증서 갱신/전달/동기화 과정이 불안정해져 서비스 간 호출이 주기적으로 실패하는 문제가 발생한다. 특히 클라우드 간 네트워크가 흔들릴 때 Control Plane ↔ Data Plane 간 sync가 지연되며 더 큰 문제로 이어진다.
서비스 디스커버리 역시 멀티 클라우드에서 훨씬 복잡하다. 각 클라우드는 자체 DNS, 로드밸런서, VPC 설계를 갖고 있기 때문에 메시가 요구하는 “단일 서비스 네임스페이스”를 쉽게 구성할 수 없다. 멀티 클라우드 환경에서는 결국 서비스 엔드포인트를 직접 브리징하거나, 메시에 외부 서비스 엔드포인트를 명시적으로 import/export하는 모델이 필요하다. 이는 단순한 클러스터 통합이 아니라, 클라우드 간 네트워크 이름과 주소, 정책을 압축하여 메시가 이해할 수 있는 형태로 재구성하는 과정이다. 자연스럽게 운영 복잡성이 증가한다.
옵저버빌리티 역시 클라우드마다 수집 경로, 로그 스토리지, 메트릭 파이프라인이 달라 중간에서 통합 레이어가 필요해진다. 동일 클라우드라면 Prometheus 페더레이션만으로 충분하지만, 멀티 클라우드에서는 로그/메트릭 전송 자체가 egress 비용을 발생시키고, 엔드포인트를 일관적으로 노출시키기 어렵다. 따라서 메쉬 자체의 telemetry pipeline을 표준화하거나, 별도 observability mesh를 구축해야 하는 경우도 많다. 또한 각 클라우드의 보안 규정과 네트워크 정책이 상충하는 지점이 있어 메시 내부 정책(AuthorizationPolicy, PeerAuthentication 등)과 클라우드 보안 정책이 충돌하지 않도록 조율하는 노력도 필요하다.
그리고 멀티 클라우드의 가장 현실적인 문제는 비용과 데이터 이동 정책이다. 클라우드 간 트래픽은 egress 비용이 크기 때문에, 메시가 자동으로 cross-cluster 로드밸런싱을 수행하는 구조를 그대로 쓰면 비용 폭등이 발생할 수 있다. 결국 트래픽 정책, locality 기반 라우팅, failover 전략 등을 비용 중심으로 재설계해야 하고, 멀티 클라우드 메시 운영이 “기술적 가능”을 넘어 “경제적 타당성”으로까지 확장된다.
종합하면, 멀티 클라우드 서비스 메시는 멀티 클러스터 메시의 요구사항(탐색·연결성·공통 트러스트)에 더해, 클라우드 간 네트워크 모델의 불일치, 보안/인증 체계의 차이, 서비스 디스커버리 방식의 단절, 옵저버빌리티 파이프라인의 비대칭성, 비용 관리, 운영 기준의 통합이라는 추가적인 층위가 붙는다. 기술적으로는 동일한 메시 아키텍처를 그대로 확장하는 형태지만, 설계 관점에서는 “단일 메시”를 구축하는 것보다 “여러 클라우드의 서로 다른 세계를 메시를 통해 추상화하는 작업”에 더 가깝다. 따라서 멀티 클라우드 환경에서는 기능적 통합보다 정책의 일관성, 보안의 신뢰 체계, 트래픽 경계 관리, 운영 복잡도를 얼마나 낮출 것인가가 핵심 고려사항이 된다.
2 Likes