멀티클라우드 네트워킹 전략으로 클라우드 진화에 대응하기

F5 에코시스템 | 2024년 3월 19일

멀티클라우드 네트워킹은 정말 마법일까요?

빠르게 진화하는 클라우드 컴퓨팅 분야에서 멀티클라우드 네트워킹에 대한 관심이 다시 급증하고 있습니다. 최근까지 포괄적인 멀티클라우드 솔루션을 갖추지 못했던 공급업체들의 잇따른 인수는 고객들이 멀티클라우드의 복잡성을 헤쳐 나갈 수 있도록 지원하는 간소화된 솔루션에 대한 수요가 증가하고 있음을 보여줍니다.

하지만 이러한 관심의 부활 속에서 시장의 많은 업체가 시도하는 접근 방식이 다소 근시안적이며, 고객이 직면한 복잡성을 줄일 진정한 기회를 놓치고 있다는 점이 점점 더 분명해지고 있습니다.

네트워크는 필수적이지만 한계가 있습니다

클라우드 컴퓨팅이 계속 발전함에 따라 멀티클라우드 네트워킹이 이제 기업의 기술적 고려 사항에서 핵심 화두로 떠오르고 있습니다. 기존 데이터 센터를 넘어선 컴퓨팅 역량이 원격 엣지 시설과 물리적 지사로 확장되면서 물리적 환경과 클라우드 환경 간에 새로운 패러다임이 요구되고 있습니다. 컨테이너화, 마이크로서비스, API의 등장으로 애플리케이션은 점점 더 분산되고 동적으로 변화하여 기존 네트워크 아키텍처에 새로운 과제를 제기하고 있습니다. 이제 이러한 애플리케이션은 대규모 서버 팜의 필요성에 얽매이지 않고 고도로 분산된 여러 위치에 배포될 수 있습니다.

현재 제공되는 멀티클라우드 네트워킹 솔루션의 대다수는 주로 네트워크 전송 계층에 초점을 맞추고 있습니다. 오늘날 우리가 알고 있는 네트워크는 애플리케이션을 인식하지 못합니다. 애초에 그런 용도로 설계된 것이 아니기 때문입니다. 또한 네트워크는 주로 사이트 간(남북 방향) 연결을 위해 설계되었으며, 단일 클라우드 또는 물리적 사이트의 클러스터를 넘어 확장되는 동서 방향 애플리케이션 서비스 연결의 증가를 지원할 준비가 되어 있지 않습니다. 이 때문에 기업이 대규모 합병이나 인수를 진행할 때 문제가 발생합니다. 네트워크 라우팅 테이블에 저장된 서로 다른 IP 주소가 동일한 인프라를 공유해야 하므로 필연적으로 IP 중복 문제가 발생하고 운영 복잡성이 증가합니다.

기존 네트워크는 흔히 "단순한 데이터 전달 통로"로 여겨지며, 상당한 운영 부담과 비효율을 초래해 민첩성이 매우 높은 조직의 개발 팀에 걸림돌이 됩니다. 많은 조직이 네트워크부터 이러한 문제를 해결하려 하지만, 결국 이 접근 방식의 한계를 깨닫게 됩니다.

Kubernetes의 딜레마

Kubernetes는 이러한 분산형 컨테이너 생태계를 오케스트레이션하는 데 필수적인 도구로 부상했으며, 대규모 민첩성과 확장성을 지원합니다. Google이 처음 개발한 오픈 소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 컨테이너화된 애플리케이션의 배포 및 관리를 위한 사실상의 표준으로 빠르게 자리 잡았습니다.

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 플랫폼을 제공합니다. Kubernetes는 기반 인프라를 추상화함으로써 개발자가 인프라 리소스 관리의 복잡성에 얽매이지 않고 애플리케이션 구축과 배포에 집중할 수 있도록 지원합니다. 하지만 Kubernetes 자체도(적어도 오픈 소스 형태에서는) 어느 정도의 복잡성을 수반합니다. 이러한 이유로 복잡성의 일부를 추상화하는 것을 목표로 하는 상용 배포판이 널리 사용되고 있습니다.

하지만 이는 다시 원점으로 돌아가게 합니다. 상용으로 널리 제공되는 배포판 중 하나인 Red Hat OpenShift를 예로 들어 보겠습니다. OpenShift는 엔터프라이즈 환경, 특히 온프레미스 데이터 센터에 널리 배포되어 있습니다. 이러한 기업들은 AWS와 같은 클라우드에도 서비스 클러스터를 배포하며, Amazon Elastic Kubernetes Service(EKS)를 사용하면서 서비스를 AWS 기반 Red Hat OpenShift(ROSA)에 통합하고자 할 가능성이 높습니다. 서로 통합되도록 설계되지 않은 별개의 도구 환경으로 인해 멀티클라우드 문제가 다시금 고개를 듭니다.

클라우드 네트워크 보안의 격차

현재 시장에 출시된 모든 멀티클라우드 네트워킹 솔루션은 고급 세분화부터 네이티브 네트워크 방화벽 및 서비스 삽입 기능에 이르기까지 일정 수준의 기본 보안 기능을 제공합니다. 하지만 여기서도 애플리케이션이라는 핵심 동인을 놓치고 있습니다. 이러한 솔루션은 여러 클라우드 및 엣지 사이트에 걸쳐 분산된 애플리케이션 서비스와 API 엔드포인트를 침해하는 비즈니스 로직 공격 기반의 악성 위협을 고려하지 못합니다. 네트워크가 안전하더라도 해당 네트워크에서 서비스되는 애플리케이션은 여전히 공격에 취약할 수 있습니다. 기업은 분산형 하이브리드 및 멀티클라우드 애플리케이션 전체가 보호되도록 여러 개별 보안 솔루션을 배포하고, 보안팀을 통해 막대한 수준의 거버넌스를 적용해야 합니다.

안전한 멀티클라우드 네트워킹의 필요성

동영상 발췌: Kyndryl 및 F5와 함께 알아보는 안전한 멀티클라우드 네트워킹의 정의

미래 지향적인 기업들은 이러한 과제에 적극 대응하며 판도를 새롭게 바꾸고 있습니다. McGraw Hill을 예로 들어 보겠습니다. 핵심 애플리케이션을 클라우드로 시급히 마이그레이션해야 했던 McGraw Hill은 애플리케이션의 요구 사항과 보안 요건을 우선시하고, 엄격한 요구 조건을 충족하기 위해 F5 Distributed Cloud Services를 선택했습니다. F5를 통해 온프레미스 네트워크를 모든 클라우드 환경으로 원활하게 확장하고, 어떤 클라우드에서든 일관된 애플리케이션 수준의 보안을 보장할 수 있습니다.

마찬가지로 스코틀랜드 정부 농업·농촌경제(ARE)국은 최신 애플리케이션 아키텍처에 대응하기 위해 새로운 패러다임이 필요하다는 점을 인식했습니다. ARE는 Distributed Cloud Services를 활용해 OpenShift와 EKS 간에 워크로드를 원활하게 이전하며 멀티클라우드 환경의 유연성과 민첩성을 확보했습니다. 인프라 책임자인 Neil Smith는 이렇게 말했습니다. "멀티클라우드 환경은 앞으로도 계속될 것입니다. F5를 통해 우리는 상황에 맞게 전환하고, 이러한 전환을 지원하는 모든 서비스와 솔루션을 갖춘 컨테이너 기반 Kubernetes 환경을 활용할 수 있습니다."

이러한 성공 사례는 멀티클라우드 네트워킹이 애플리케이션 중심 및 보안 중심 접근 방식으로 전환되고 있음을 잘 보여줍니다. 기업은 기존의 기반 네트워크 인프라를 보완하는 동시에 애플리케이션의 요구 사항과 보안 요건을 우선시함으로써 멀티클라우드 환경의 복잡성을 자신감 있고 효율적으로 헤쳐 나갈 수 있습니다. 현대적인 애플리케이션 아키텍처를 기반으로 구축된 조직이 디지털 시대에 멀티클라우드의 역량을 활용해 혁신과 성공을 이끌 수 있도록 돕는 것은 ‘마법’이 아니라 안전한 멀티클라우드 네트워킹입니다.