현재 클라우드 전문가들은 다양한 퍼블릭 클라우드의 집합 위에 자리 잡은 새로운 기술 레이어의 출현에 주목하고 있다. 멀티클라우드의 진정한 최종 형태라고 할 수 있다. 이 레이어는 애플리케이션 개발, 운영, 관측, 보안, 거버넌스 등을 포괄하는 것으로 개별 퍼블릭 클라우드 제공업체 수준을 뛰어넘어 적용되며 결과적으로 ‘실질적인’ 멀티클라우드를 구현한다.
이를 부르는 용어가 몇 가지 있다. 슈퍼클라우드(supercloud), 분산 클라우드(distributed cloud), 메타클라우드(metacloud), 추상적 클라우드(abstract cloud) 등이다. ‘클라우드 네이티브’라는 용어도 있다. 이런 신조어는 만드는 사람에 따라 정확한 개념이 약간씩 차이가 있지만, 공통으로 퍼블릭 클라우드의 모음을 의미하고 때로는 더 거대한 목표를 위해 함께 작동하는 엣지 기반 시스템을 가리킨다.
이러한 메타클라우드 개념은 퍼블릭 클라우드를 업무에 본격적으로 활용하게 되면서 앞으로 5~10년간 큰 주목을 받게 될 것이다. 추상화와 자동화를 통해 관리되는 여러 가지 클라우드 서비스의 모음을 확보하는 것이, 개별 퍼블릭 클라우드 업체의 서비스를 활용하는 것보다 더 중요해질 것이다.
보통 기업은 추상화된 인터페이스를 통해 스토리지나 컴퓨트, 인공지능, 데이터 등 원하는 서비스에 접근하는 방법으로 퍼블릭 클라우드 업체를 활용한다. 동시에 클라우드 확장 기술 레이어를 통해 이들 서비스를 더 효과적으로 사용하고 싶어 한다. 이 과정에서 복잡성이 필연적으로 발생하는데, 메타클라우드는 이런 복잡성을 제거한다. 또한, 크로스 클라우드 레이어를 통해 비용 효율적으로 멀티클라우드를 지원하는 확장 작업을 하는 것도 가능하다.
결과적으로 기업은 메타클라우드를 통해 보안과 거버넌스, 운영은 물론 애플리케이션 개발과 배포까지 통합된 단일 레이어를 확보할 수 있다. 그동안 기업이 원하던 궁극적인 멀티클라우드의 모습이다. 기존에는 단일 클라우드에서만 작동하는 전용 툴을 이용해 더 많은 사일로를 만들고 더 다양한 툴을 사용해야 했다. 복잡성은 점점 커지고 결국 멀티클라우드는 장점보다 오히려 단점이 더 많은 시스템이 될 수도 있었지만, 메타클라우드를 통해 그 해법을 찾을 수 있다.
이 새로운 멀티클라우드 트렌드를 무엇이라고 부르든 상관이 없다. 메타클라우드라는 용어가 또 다른 혼란으로 이어질지 수도 있음을 알고 있다. 그런데도 메타클라우드가 현재 가장 중요한 아키텍처 측면의 진화라는 사실은 변함이 없고, 우리는 이를 현실화해야 한다. 물론 이런 구현 작업에 실패한다면, 이 기술을 누가 어떤 명칭으로 부르든 아무 의미가 없게 된다.
‘메타클라우드’에 관한 4가지 오해
위에 기술한 ‘클라우드 컴퓨팅 최후의 미개척지, ‘메타클라우드(metacloud)’라는 글에는 제목 때문인지 유독 많은 사람이 관심을 보였으며, 소셜 미디어에 특히 여러 의견과 질문이 있었는데 그중에서 공통적으로 많이 나왔던 내용을 함께 공유하고자 한다.
1. 메타클라우드는 이미 판매 중이다
가장 많이 볼 수 있는 의견이었다. 먼저 메타클라우드는 특정 서비스나 기술이 아니라는 점을 강조하고 싶다.
메타클라우드는 아키텍처 패턴이다. 최근 페이스북이 기업명을 ‘메타 플랫폼(Meta Platforms, Inc.)’이라고 변경해서 혼동할 수 있는데, 페이스북의 메타는 메타클라우드와 상관없다.
메타클라우드는 제품, 기술 또는 아키텍처 표준에 의해 형성된다. 보안, 스토리지, 네트워크 등과관련한 퍼블릭 클라우드 서비스 2개 이상 포함한다.
특정 서비스가 메타클라우드 아키텍처의 일부가 될 수 있지만, 서비스 그 자체는 메타클라우드가 아니다.
2. 메타클라우드에는 기본 클라우드 서비스 업체가 필요하다
클라우드 서비스 업체 대부분이 이 표현을 강조한다. 절반은 맞는 말이다.
무엇으로 지칭하든 메타클라우드 사용자는 논리적으로 두 개 이상의 퍼블릭 클라우드 서비스를 이용한다. 핵심은 ‘논리적으로’이다. 메타클라우드 대시보드는 여러 클라우드의 보안, 운영, 거버넌스, 공통 저장 시스템 등을 논리적으로 확인하고 보여준다.
특정 클라우드 서비스 업체에서만 작동하는 독점 혹은 최적화 서비스가 있다하더라도 이를 볼 수 있는 추상화 기술이 제공된다. 메타클라우드 아키텍처 혹은 기술 스택은 ‘실제로는’ 한 개 혹은 여러 클라우드 서비스 업체의 플랫폼에 위치할 수 있다. 하지만 실제 위치와 상관없이 여러 시스템을 ‘논리적으로’ 한꺼번에 관리한다.
메타클라우드 사용자는 클라우드 지식과 상관없이 이용할 수 있는 쉬운 기술을 찾는 경향이 있다. 그래서 약간 혼란스러울 수 있지만 아무튼 메타클라우드는 어디선가에서 반드시 실행되며 그 실행 위치가 주요 퍼블릭 클라우드가 될 확률이 높다.
만약 여러 클라우드 시스템을 특정 클라우드 서비스 업체에서 관리하면서 메타클라우드를 구축했다면, 해당 클라우드 서비스를 메타클라우드의 기본 서비스 업체라고 봐도 무방하다. 그러나 그런 솔루션은 클라우드를 운영하는 모든 플랫폼 위에서 ‘물리적으로’ 설치해 실행할 수 있기 때문에 메타클라우드로 만드는 결과가 큰 의미가 있을지 모르겠다. 사용하고 있는 솔루션을 살펴보고 가장 적합한 플랫폼을 선택해보자.
3. 멀티클라우드 위에 계층을 추가해 발생하는 복잡성은 숨길 수 있어도 제거하지 못한다
핵심을 잘 파악한 의견이다. 그러나 멀티클라우드가 복잡한 이유는 여러 클라우드 업체를 선택하고, 또 그 안에서 다양한 서비스를 이용하기 때문이다. 보통 결정권을 가진 담당자가 복잡성에 미칠 영향보다 프로젝트 요구사항을 충족시키는 부분을 더 중요시해서 최상의 서비스만 선택할 때 이런 일이 발생한다. 복잡성과 이질성이 나타나는 것이다.
만약 인프라 조직에서 이용할 수 있는 클라우드 서비스 종류를 정해 놓는다면, 복잡성 문제를 미리 피할 수 있다. 대신 사업의 핵심 기술을 만들고 혁신을 추구하는 과정에서 최상의 기술을 이용하지 못할 수 있다. 따라서 기술 혁신이 가져올 이익과 그로 인해 초래할 복잡성 중 어느 것이 어떤 것을 우선해야 하는지 결정해야 한다. 이를 결정했다면, 둘 사이의 최적의 교차점을 찾아내야 한다.
시스템이 이미 복잡한 경우, 구조적 복잡성을 숨긴다고 문제가 해결되지 않는다. 이런 유형의 복잡성은 혁신을 추구하겠다고 좋은 서비스를 선택해서 생긴 복잡성과는 결이 다르다. 설계가 잘못돼 복잡성이 나타났다면, 숨기기보다 고쳐야 한다.
요점은 멀티클라우드를 사용하면 반드시 복잡성이 생긴다는 것이다. 확실히 얻을 이익이 있기 때문에 여러 클라우드를 선택한 것이고, 결국 어느 순간 복잡성이 나타날 수 있다. 하지만 추상화와 자동화 계층을 활용하면 복잡한 멀티클라우드 배포를 어떻게 최적의 방식으로 운영하고 보안성을 높일지 배울 수 있다.
추상화와 및 자동화 계층을 운영하려면 퍼블릭 클라우드 배포와 거의 동일 수준 혹은 그보다 적은 인력과 시스템 리소스를 투입해야 한다. 추상화와 자동화는 특정 유형의 복잡성을 숨길 수 있으며, 그 복잡성 수준은 확장 및 축소될 수 있다.
4. 추상화 계층을 이용하면 지연이 발생한다
마지막으로 흔히 볼 수 있는 의견은 기존 인터페이스와 최종적으로 해당 서비스를 소비하는 인터페이스 사이에 다른 계층을 추가하면 요구와 응답 시간 사이에 지연이 생긴다는 것이다.
예를 들어 기업이 퍼블릭 클라우드 스토리지를 위해 스토리지 인터페이스 추상화, 즉 클라우드 네이티브 스토리지 시스템을 사용하고 있다고 하자. 개발자는 각 퍼블릭 클라우드 서비스 업체의 전용 API와 같이 특정한 API를 사용할 필요가 없다. 인터페이스가 단일 추상 API/CLI를 이용해 그 과정을 자동화하기 때문이다. 물론 여기에는 추가적인 처리와 필수적인 I/O로 인해 지연이 발생한다. 하지만 개발자, 테스터, 사용자 대부분은 알아차리지 못할 수준일 것이다.
물론 메타클라우드에서 이 부분은 간단한 일이 아니다. 메타클라우드는 결국 스토리지와 컴퓨팅 인스턴스를 추상화해, 다양한 퍼블릭 클라우드 안의 여러 서비스가 서로 쉽고 간편하게 상호작용하는 방법을 찾아내는 일이다.
메타클라우드는 보안, 핵심 운영, 관리, 메타 데이터 관리 등 운영 프로세스에 관한 추상화로 이뤄진다. 각 클라우드의 네이티브 시스템을 사용해 이를 처리해야 한다면, 그 작업은 지나치게 복잡하고 번거로울 수 있다. 하나의 스토리지 운영 계층에서 작업하는 대신, 4~5개의 스토리지 운영 계층에서 작업해야 할 때도 있다.
각 퍼블릭 클라우드 서비스 및 세부 기능을 잘 아는 담당자를 확보하는 것은 쉬운 일이 아니다. 공통의 추상화 계층이 없기 때문에 크로스 클라우드 운영 기능이 없는 멀티클라우드를 운영하기 위해서는 평소보다 비용이 3~4배 더 들어갈 수 있다.