클라우드

블로그 | 메타클라우드에 대한 흔한 오해 4가지

David Linthicum | InfoWorld 2022.07.22
필자가 얼마 전 올린 ‘클라우드 컴퓨팅 최후의 미개척지, '메타클라우드(metacloud)’라는 글에는 제목 때문인지 유독 많은 사람이 관심을 보였다. 소셜 미디어에 특히 여러 의견과 질문이 있었는데, 그중에서 공통적으로 많이 나왔던 내용을 함께 공유하고자 한다. 
 
ⓒ Getty Images Bank
 

메타클라우드는 이미 판매 중이다

가장 많이 볼 수 있는 의견이었다. 먼저 메타클라우드는 특정 서비스나 기술이 아니라는 점을 강조하고 싶다. 메타클라우드는 아키텍처 패턴이다. 최근 페이스북이 기업명을 ‘메타 플랫폼(Meta Platforms, Inc.)’이라고 변경해서 혼동할 수 있는데, 페이스북의 메타는 메타클라우드와 상관이 없다. 

메타클라우드는 제품, 기술 또는 아키텍처 표준에 의해 형성된다. 보안, 스토리지, 네트워크 등과관련한 퍼블릭 클라우드 서비스 2개 이상 포함한다. 특정 서비스가 메타클라우드 아키텍처의 일부가 될 수 있지만, 서비스 그 자체는 메타클라우드가 아니며 적어도 필자가 제시한 개념과는 거리가 멀다.
 

메타클라우드에는 기본 클라우드 서비스 업체가 필요하다

클라우드 서비스 업체 대부분이 이 표현을 강조한다. 절반은 맞는 말이다. 무엇으로 지칭하든 메타클라우드 사용자는 논리적으로 두 개 이상의 퍼블릭 클라우드 서비스를 이용한다. 핵심은 ‘논리적으로’이다. 메타클라우드 대시보드는 여러 클라우드의 보안, 운영, 거버넌스, 공통 저장 시스템 등을 논리적으로 확인하고 보여준다. 특정 클라우드 서비스 업체에서만 작동하는 독점 혹은 최적화 서비스가 있다 하더라도 이를 볼 수 있는 추상화 기술이 제공된다. 메타클라우드 아키텍처 혹은 기술 스택은 ‘실제로는’ 한 개 혹은 여러 클라우드 서비스 업체의 플랫폼에 위치할 수 있다. 하지만 실제 위치와 상관없이 여러 시스템을 ‘논리적으로’ 한꺼번에 관리한다.

메타클라우드 사용자는 클라우드 지식과 상관없이 이용할 수 있는 쉬운 기술을 찾는 경향이 있다. 그래서 약간 혼란스러울 수 있지만 아무튼 메타클라우드는 어디선가에서 반드시 실행되며 그 실행 위치가 주요 퍼블릭 클라우드가 될 확률이 높다. 만약 여러 클라우드 시스템을 특정 클라우드 서비스 업체에서 관리하면서 메타클라우드를 구축했다면, 해당 클라우드 서비스를 메타클라우드의 기본 서비스 업체라고 봐도 무방하다. 그러나 그런 솔루션은 클라우드를 운영하는 모든 플랫폼 위에서 ‘물리적으로’ 설치해 실행할 수 있기 때문에 메타클라우드로 만드는 결과가 큰 의미가 있을지 모르겠다. 사용하고 있는 솔루션을 살펴보고 가장 적합한 플랫폼을 선택해보자.
 

멀티클라우드 위에 계층을 추가해 발생하는 복잡성은 숨길 수 있어도 제거하지 못한다

핵심을 잘 파악한 의견이다. 그러나 멀티클라우드가 복잡한 이유는 여러 클라우드 업체를 선택하고, 또 그 안에서 다양한 서비스를 이용하기 때문이다. 보통 결정권을 가진 담당자가 복잡성에 미칠 영향보다 프로젝트 요구사항을 충족시키는 부분을 더 중요시해서 최상의 서비스만 선택할 때 이런 일이 발생한다. 복잡성과 이질성이 나타나는 것이다. 

만약 인프라 조직에서 이용할 수 있는 클라우드 서비스 종류를 정해 놓는다면, 복잡성 문제를 미리 피할 수 있다. 대신 사업의 핵심 기술을 만들고 혁신을 추구하는 과정에서 최상의 기술을 이용하지 못할 수 있다. 따라서 기술 혁신이 가져올 이익과 그로 인해 초래할 복잡성 중 어느 것이 어떤 것을 우선해야 하는지 결정해야 한다. 이를 결정했다면, 둘 사이의 최적의 교차점을 찾아내야 한다.

시스템이 이미 복잡한 경우, 구조적 복잡성을 숨긴다고 문제가 해결되지 않는다. 이런 유형의 복잡성은 혁신을 추구하겠다고 좋은 서비스를 선택해서 생긴 복잡성과는 결이 다르다. 설계가 잘못돼 복잡성이 나타났다면, 숨기기보다 고쳐야 한다. 

요점은 멀티클라우드를 사용하면 반드시 복잡성이 생긴다는 것이다. 확실히 얻을 이익이 있기 때문에 여러 클라우드를 선택한 것이고, 결국 어느 순간 복잡성이 나타날 수 있다. 하지만 추상화와 자동화 계층을 활용하면 복잡한 멀티클라우드 배포를 어떻게 최적의 방식으로 운영하고 보안성을 높일지 배울 수 있다. 

추상화와 및 자동화 계층을 운영하려면 퍼블릭 클라우드 배포와 거의 동일 수준 혹은 그보다 적은 인력과 시스템 리소스를 투입해야 한다. 추상화와 자동화는 특정 유형의 복잡성을 숨길 수 있으며, 그 복잡성 수준은 확장 및 축소될 수 있다. 


추상화 계층을 이용하면 지연이 발생한다

마지막으로 흔히 볼 수 있는 의견은 기존 인터페이스와 최종적으로 해당 서비스를 소비하는 인터페이스 사이에 다른 계층을 추가하면 요구와 응답 시간 사이에 지연이 생긴다는 것이다.

예를 들어 기업이 퍼블릭 클라우드 스토리지를 위해 스토리지 인터페이스 추상화, 즉 클라우드 네이티브 스토리지 시스템을 사용하고 있다고 하자. 개발자는 각 퍼블릭 클라우드 서비스 업체의 전용 API와 같이 특정한 API를 사용할 필요가 없다. 인터페이스가 단일 추상 API/CLI를 이용해 그 과정을 자동화하기 때문이다. 물론 여기에는 추가적인 처리와 필수적인 I/O로 인해 지연이 발생한다. 하지만 개발자, 테스터, 사용자 대부분은 알아차리지 못할 수준일 것이다. 

물론 메타클라우드에서 이 부분은 간단한 일이 아니다. 메타클라우드는 결국 스토리지와 컴퓨팅 인스턴스를 추상화해, 다양한 퍼블릭 클라우드 안의 여러 서비스가 서로 쉽고 간편하게 상호작용하는 방법을 찾아내는 일이다.

메타클라우드는 보안, 핵심 운영, 관리, 메타 데이터 관리 등 운영 프로세스에 관한 추상화로 이뤄진다. 각 클라우드의 네이티브 시스템을 사용해 이를 처리해야 한다면, 그 작업은 지나치게 복잡하고 번거로울 수 있다. 하나의 스토리지 운영 계층에서 작업하는 대신, 4~5개의 스토리지 운영 계층에서 작업해야 할 때도 있다. 

각 퍼블릭 클라우드 서비스 및 세부 기능을 잘 아는 담당자를 확보하는 것은 쉬운 일이 아니다. 공통의 추상화 계층이 없기 때문에 크로스 클라우드 운영 기능이 없는 멀티클라우드를 운영하기 위해서는 평소보다 비용이 3~4배 더 들어갈 수 있다.  
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.