"멀티클라우드에 범용성이란 없다" 그렇다면 해결책은?

Matt Asay  | InfoWorld 2021.04.12
멀티클라우드를 현실화할 때 필요한 ‘최소 공통 분모’ 범용 서비스는 아마도 클라우드 업체들이 혁신을 멈출 때에야 가능할 것이다. 필자가 오래 전부터 거듭 강조해 온 이야기다. 많은 업체가 여러 클라우드에서 워크로드를 실행하는 기능 판매에 열을 올리지만, 실제로는 업체마다 경쟁 클라우드에서는 쓸 수 없는 네이티브 서비스가 있다. 일종의 ‘불편한 진실’이다.

이 진실은 갈수록 더 확고해지고 있다.
 
ⓒ Getty Images Bank

마이크로소프트, 구글, 아마존 또는 알리바바가 하는 일을 대충만 훑어봐도 범용 서비스 같은 것은 없다는 것을 알 수 있다. 그렇다면 멀티클라우드가 완전히, 전적으로 죽었다는 뜻일까? 아니다. 몽고DB를 비롯한 여러 업체는 멀티클라우드가 죽지 않았다고 강하게 주장하는 중이다.
 

클라우드에는 범용이 없다

먼저, 워크로드가 업체를 가리지 않고 여러 클라우드에서 마법처럼 작동한다는 꿈에 대해 말해보자. 분석가 코리 퀸은 회의적이다. 코리는 이 개념에 다음과 같은 우려를 표했다.

“모든 클라우드 제공업체 또는 기업의 자체 데이터센터에서 쉽고 매끄럽게 실행 가능한 워크로드를 구축한다는 개념은 분명 매력적이다. 그러나 그 현실성 수준은 개발자에게 “버그가 없는 코드를 쓰라”고 말하는 것, 또는 물리 모델 관점에서 분명 존재해야 하는 ‘구형 소(spherical cow)’를 정말 찾으려고 애쓰는 것과 비슷하다. 보기보다 훨씬 더 어렵다.”

소프트웨어(클라우드도 마찬가지)는 그런 식으로 움직이지 않는다. 여러 클라우드 업체의 노력 덕분에 컴퓨팅 및 스토리지 같은 클라우드 서비스는 서로 똑같이 닮아가는 것이 아니라 혁신적인 차별화 기능을 덧붙이고 있으며, 그에 따라 최소 공통 분모라는 우주는 계속 축소되는 중이다.

예를 들어 스토리지만큼 범용적인 것이 있을까? 물론 거의 모든 클라우드가 객체 스토리지나 블록 스토리지 같은 용어를 얘기하고 있다. 그러나 더 깊이 들어가서 예를 들어 구글이 스토리지를 구축하는 방식을 보면 갑자기 똑같아 보이지 않는다. 구글은 아카이브 시스템을 하드웨어가 아닌 소프트웨어 정책에 구축했고, 이는 콜드라인 스토리지의 지연이 최상위 티어 스토리지와 동일하다는 것을 의미한다.
 
컴퓨팅은 어떨까? 완전한 범용이 아닐까? 글쎄, 새로운 종류의 프로세서인 그라비톤(Graviton)을 만들고 있는 AWS 세계에서는 아니다. 그라비톤은 64비트 ARM 네오버스(Neoverse) 코어와 AWS가 설계한 맞춤형 시스템온칩을 기반으로 한다. 그 결과는 과학 및 고성능 워크로드를 위한, 비약적으로 빨라진 코어당 부동소수점 성능, 더 낮은 비용 등이다. (필자는 AWS에서 일하지만 이 글은 100% 개인적인 의견임을 밝힌다.) 
 
AWS만의 이야기도 아니다. 현재 일어나고 있는 상황을 최근 비즈니스위크에서는 다음과 같이 전했다. 
 
“스머그머그(Smugmug)의 맥어스킬은 아마존, 구글, 마이크로소프트가 클라우드 컴퓨팅 고객을 두고 경쟁하면서 이들 각각의 칩이 가진 특정한 강점을 판매 포인트로 내세울 수 있다면서 “클라우드 업체들이 차별화를 더욱 강화하고 나서기 시작하면 더욱 흥미로운 상황이 일어날 것”이라고 말했다.”
 
물론 그러한 상황은 이미 일어나는 중이고, 이는 고객을 위한 더 큰 혁신을 의미하지만 다른 한편으로는 멀티클라우드 신화의 설득력이 조금 더 떨어지게 된다는 것을 의미하기도 한다. 클라우드 제공업체가 고객을 각자의 틀 안에 가두고 덜 주려고 노력해서가 아니라, 반대로 고객에게 더 많은 것을 제공하기 위해 노력하기 때문이다.
 
그렇다고 멀티클라우드가 사기라는 말은 아니다.
 

멀티클라우드로 가려면 답은 마이크로서비스

예를 들어 몽고DB는 2020년 말에 멀티클라우드 클러스터를 출범했다. 이게 무슨 뜻일까? 몽고DB에 따르면 “고객이 여러 퍼블릭 클라우드에 걸친 하나의 클러스터에 동시에 데이터를 분산하거나, 이와 같은 클라우드 사이에서 단절 없이 워크로드를 옮길 수 있다는 것”을 의미한다. 이 기능에서 혜택을 얻기 위해 별도의 여러 마이크로서비스가 하나의 앱을 형성해서 다양한 클라우드에 배포되어 각 클라우드가 제공하는 최선의 서비스에 액세스한다.
 
이것은 여러 클라우드 간에 단절 없이 애플리케이션을 옮기는 문제가 아니다. 여러 클라우드에 걸쳐 범용화된 최소 공통 분모 서비스에 관한 것도 아니다. 사실 그것과는 정반대다. 별도의 마이크로서비스로 찾아서 도달한 각 클라우드의 최선의 요소를 가져오는 방식이다. 사실 몽고DB 아틀라스(Atlas) 멀티클라우드 클러스터의 꽤 많은 부분이 세 주요 클라우드 제공업체에서 모두 실행된다.
 
듣기에는 좋고, 어느 지점까지는 실제로도 좋다. 그 지점은 마이크로서비스로 시작하고 끝난다. 애플리케이션에 따라 마이크로서비스는 좋을 수도 있다. 어떻게? 서로 다른 팀이 꼭 같은 툴(프로그래밍 언어, 런타임 등)을 사용하지 않고도 같은 시스템에서 더 쉽게 협업을 할 수 있다. 또한 마이크로서비스로는 확장성 높은 애플리케이션을 더 쉽게 구축할 수 있다. 하나의 모놀리식 애플리케이션을 확장하는 대신 애플리케이션을 작은 서비스로 분할해서 각기 독립적으로 확장할 수 있기 때문이다. 좋지 않은가?
 
그렇기도 하고, 아니기도 하다. 마이크로서비스가 맞지 않는 경우도 있기 때문이다. (모놀리식이 정답일 때도 있다.)
 
템포럴(Temporal)의 라이랜드 골드스타인은 “마이크로서비스로 전환한 사람들이 가장 먼저 인지한 문제는 갑자기 많은 종류의 서버와 데이터베이스를 책임지게 됐다는 것”이라고 말했다. 마틴 파울러는 한 걸음 더 나아가서, 마이크로서비스가 아닌 모놀리식을 선택해야 할 다음과 같은 세 가지 타당한 이유를 제시했다.

1. 분산 마이크로서비스 지향 아키텍처는 원격 호출이 느리고 항상 실패의 위험을 안고 있으므로 프로그램하기가 더 어렵다.
2. 분산 시스템에서는 강력한 일관성을 유지하는 것이 어렵다.
3. 대부분의 기업은 정기적으로 재배포되는 다수의 서비스를 관리할 수 있는 성숙한 운영 팀을 보유하지 못했다.

파울러의 정리는 몽고DB가 내놓은 멀티클라우드 솔루션이 유망하기는 하지만, 많은 기업에서 수용하기 어려울 만큼 더 많은 일이 수반될 수 있음을 의미한다. IT에서 대부분의 일이 그렇듯이 멀티클라우드에 대한 대답 역시 “상황에 따라 다르다”. 조직의 성숙도가 어느 정도인지, 그리고 투자를 집중하는 대신 동종 최고의 항목을 선택하는 복잡성을 얼마만큼 감수할 수 있는지에 따라, 또 각자 처한 상황에 따라 멀티클라우드의 효과는 다를 수밖에 없다. 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.