멀티클라우드 네트워킹 전략으로 클라우드 진화를 탐색하다
멀티클라우드 네트워킹이 정말 마법일까요?
급속하게 발전하는 클라우드 컴퓨팅 분야에서 멀티클라우드 네트워킹 에 대한 관심이 다시 높아지고 있습니다. 이전에는 포괄적인 멀티클라우드 솔루션이 없었던 공급업체가 최근 인수에 나선 것은 멀티클라우드의 복잡성을 탐색하는 데 도움이 되는 간소화된 솔루션에 대한 고객의 수요가 증가하고 있음을 보여줍니다.
그러나 이러한 부활 속에서, 시장의 많은 참여자들이 시도하는 것이 다소 근시안적이라는 점이 점점 더 분명해지고 있으며, 고객이 직면한 복잡성을 줄일 수 있는 진정한 기회를 놓치고 있습니다.
네트워크는 기본적이지만 제한적입니다.
클라우드 컴퓨팅이 계속 발전함에 따라 멀티클라우드 네트워킹이 이제 기업 기술 고려 사항의 최전선으로 부상하고 있습니다. 기존 데이터 센터를 넘어 원격 엣지 시설과 실제 지점 사무실까지 컴퓨팅 역량이 확산되면서 물리적 환경과 클라우드 환경 간에 새로운 패러다임이 요구되고 있습니다. 컨테이너화 , 마이크로서비스 , API가 등장하면서 애플리케이션은 점점 더 분산되고 역동적으로 변했으며, 기존 네트워크 아키텍처에 새로운 과제를 안겨주었습니다. 이제 이러한 애플리케이션은 대규모 서버 팜의 필요성에 구애받지 않고도 고도로 분산된 위치에 배포될 수 있습니다.
오늘날 사용 가능한 대부분의 멀티클라우드 네트워킹 솔루션은 주로 네트워크 전송 계층에 초점을 두고 있습니다. 오늘날 우리가 알고 있는 네트워크는 애플리케이션을 인식하지 못합니다. 원래 의도한 바가 아니니까요. 또한 네트워크는 주로 사이트 간(북쪽에서 남쪽으로) 연결을 위해 설계되었으며, 단일 클라우드나 물리적 사이트의 클러스터를 넘어 확장되는 동쪽에서 서쪽으로 앱 서비스 연결의 증가를 지원할 수 있도록 갖춰져 있지 않습니다. 이것이 회사가 대규모 합병이나 인수를 거치면 문제가 발생하는 이유입니다. 네트워크 라우팅 테이블에 저장된 여러 IP 주소가 이제 동일한 인프라를 공유해야 하며 필연적으로 IP 중복 문제가 발생하고 운영상의 복잡성이 증가합니다.
기존 네트워크는 종종 "단순 파이프"로 인식되며, 민첩성이 뛰어난 조직의 개발팀에 방해가 되는 상당한 운영 오버헤드와 비효율성을 발생시킵니다. 많은 사람들이 네트워크부터 문제를 해결하려고 시도하지만, 이 접근 방식의 단점을 깨닫게 됩니다.
쿠버네티스 딜레마
쿠버네티스는 이러한 분산형 컨테이너 생태계를 조율하는 데 필수적인 도구로 등장하여 대규모의 민첩성과 확장성을 실현했습니다. 원래 Google에서 개발한 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스는 컨테이너화된 애플리케이션 배포 및 관리를 위한 사실상의 표준으로 빠르게 채택되고 있습니다.
쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 플랫폼을 제공합니다. Kubernetes는 기본 인프라를 추상화함으로써 개발자가 인프라 리소스 관리의 복잡성에 얽매이지 않고 애플리케이션을 빌드하고 배포하는 데 집중할 수 있도록 지원합니다. 그러나 쿠버네티스 그 자체로는 (적어도 오픈소스 형태로는) 어느 정도 복잡성을 지닙니다. 따라서 복잡성 중 일부를 추상화하여 없애려는 상업적 배포가 널리 퍼졌습니다.
하지만 이것은 우리를 다시 시작점으로 되돌려 놓습니다. 예를 들어, 가장 널리 상업적으로 이용 가능한 배포판 중 하나인 Red Hat OpenShift를 살펴보겠습니다. OpenShift는 주로 온프레미스 데이터 센터를 비롯한 기업 환경에 널리 배포됩니다. 동일한 기업은 또한 AWS 와 같은 클라우드에 서비스 클러스터를 배포하고 Amazon Elastic Kubernetes Service(EKS)를 사용할 가능성이 높으며 Red Hat OpenShift on AWS(ROSA)에 서비스를 통합 하려고 합니다. 통합을 목적으로 설계되지 않은 개별 툴링 환경으로 인해 멀티클라우드 문제가 다시 한번 심각해지고 있습니다.
클라우드 네트워크 보안 격차
현재 시중에 판매되고 있는 모든 멀티클라우드 네트워킹 솔루션은 고급 세분화부터 기본 네트워크 방화벽 및 서비스 삽입 기능까지 어느 정도 고유한 보안 기능을 제공합니다. 하지만 다시 한번, 우리는 애플리케이션의 추진 요소를 놓치고 있습니다. 이러한 솔루션은 여러 클라우드 및 에지 사이트에 걸쳐 분산된 애플리케이션 서비스와 API 엔드포인트를 손상시키는 비즈니스 논리 공격을 사용하는 악의적인 위협을 고려하지 못합니다. 네트워크를 안전하게 유지하는 동시에 해당 네트워크에서 서비스하는 애플리케이션은 공격에 취약할 수 있습니다. 기업들은 여러 지점의 보안 솔루션을 배포하고 보안팀에서 엄청난 양의 거버넌스를 적용하여 분산된 하이브리드 및 멀티클라우드 애플리케이션 카탈로그 전체를 보호해야 합니다.
안전한 멀티클라우드 네트워킹을 위한 사례 만들기
영상 발췌: Kyndryl 및 F5를 사용하여 안전한 멀티클라우드 네트워킹 정의
미래지향적인 기업들은 도전에 맞서며 시장의 판도를 바꾸고 있습니다. 예를 들어 맥그로 힐을 살펴보자. McGraw Hill은 중요한 애플리케이션을 클라우드로 마이그레이션해야 하는 시급한 상황에 직면하여 애플리케이션 요구 사항과 보안 요구 사항을 우선 순위로 정하고, 엄격한 요구 사항을 충족하기 위해 F5 분산 클라우드 서비스를 선택했습니다. F5를 사용하면 온프레미스 네트워크를 모든 클라우드 환경으로 원활하게 확장하여 모든 클라우드에서 일관된 애플리케이션 수준의 보안을 보장할 수 있습니다.
마찬가지로 스코틀랜드 정부의 농업 및 농촌 경제(ARE) 이사회는 최신 애플리케이션 아키텍처를 처리하기 위한 새로운 패러다임이 필요하다는 사실을 인식했습니다. ARE는 분산 클라우드 서비스를 활용하여 OpenShift와 EKS 간에 작업 부하를 손쉽게 전송하고, 멀티클라우드 환경의 유연성과 민첩성을 수용합니다. 인프라 책임자인 닐 스미스가 말했듯이 "멀티클라우드 환경은 앞으로도 계속 유지될 것입니다. F5를 사용하면 컨테이너화된 Kubernetes 환경을 활용하여 이러한 전환을 지원하는 전체 서비스 및 솔루션을 활용할 수 있습니다."
이러한 성공 사례는 멀티클라우드 네트워킹에 대한 애플리케이션 중심 및 보안 중심 접근 방식으로의 전환을 보여줍니다. 기존의 기본 네트워크 인프라를 보완하면서 애플리케이션 요구 사항과 보안 요구 사항을 우선시함으로써 기업은 멀티클라우드 환경의 복잡성을 자신감과 효율성을 가지고 탐색할 수 있습니다. "마법"이 아닌 안전한 멀티클라우드 네트워킹은 현대적 애플리케이션 아키텍처를 기반으로 구축된 조직이 디지털 시대에 혁신과 성공을 추진하는 데 도움이 될 것입니다.