2020.12.16

'멀티 클라우드, 준비됐는가' 멀티 클라우드를 도입하기 전 준비 체크리스트

Isaac Sacolick | InfoWorld
처음 클라우드 네이티브 Node.js 애플리케이션을 아마존 웹 서비스(Amazon Web Services)에 배포하게 되면, 이후 여러 레거시 닷넷 애플리케이션을 퍼블릭 클라우드로 전환하라는 작업 지시를 받을 수 있다.

처음 단계로 아마존 라이트세일(Lightsail)을 사용해야 할까, 아니면 마이크로소프트 애저가 제공하는 닷넷 개발자를 위한 옵션이 더 나을까, 또는 현재 애저에서 실행 중인 애플리케이션을 데이터 과학 팀이 구글 클라우드 플랫폼에 배포한 머신러닝 모델에 안전하게 연결해야 하는 경우도 있다. 개발 팀과 데이터 과학 팀이 여러 애플리케이션과 데이터베이스, 마이크로서비스, 머신러닝 모델을 연구하고 프로토타이핑하고 배포해야 하는 시나리오는 어렵지 않게 상상할 수 있다.
 
ⓒ Getty Images Bank

대기업에서는 복수의 클라우드 지원은 거의 필연적이다. 모든 개발, 데이터 과학, 섀도우 IT 작업을 하나의 퍼블릭 클라우드로 보내기 위해 필요한 막대한 수준의 거버넌스 때문이다. 그렇다 해도 글로벌 기업과 대기업이 '멀티 클라우드화'를 전략적으로 중요하다고 판단하는 데는 여러 가지 이유가 있다.

필자는 IDG테크토크(IDGTechTalk), CIO챗(CIOChat)과 같은 소셜 채팅을 통해 트위터에서 활동하는 IT 리더에게 연락해 기업이 여러 클라우드를 지원해야 하는지 여부와 지원하는 방법에 관한 의견을 구했다. 이 체크리스트에는 멀티 클라우드 준비에 관한 이들의 경험과 의견이 포함돼 있다. 이제 준비가 됐는가?


멀티 클라우드 복잡성에 친숙해지기

IT 리더들은 안전하고 견고한 클라우드 인프라 설정의 복잡함에 익숙하다. 여러 클라우드를 결합할 때 이러한 복잡성은 당연히 배가된다. 한번에 모든 클라우드를 다루는 것은 바람직하지 않으므로 가급적 피해야 한다.

여러 클라우드에 걸친 운영은 많은 거버넌스와 기술 전문 지식, 통합이 필요한 복잡한 과업이다. 독립 기술 전문가인 사브지트 조할은 "어느날 갑자기 ‘오늘부터 멀티 클라우드를 해야겠다’고 결심하는 경우는 없다. 주로 기업의 사일로에 의해 의지와 관계없이 멀티 클라우드화된다. 멀티 클라우드를 쉽다고 말하는 사람도 결코 없다"라고 말했다.

커넥티드마인즈(Connektedminds) CEO인 조안 프리드먼은 IT 팀은 다른 제공업체에서 새롭거나 더 나은 기능을 물색하는 대신 가능한 모든 상황에서 주 클라우드 제공업체를 활용하는 것이 좋다면서 “하나의 퍼블릭 클라우드에서 모든 것을 해결할 수 없다는 것을 받아들여야 한다. 한 제공업체에서 필요한 일의 40%~60% 정도만 가능하다”라고 말했다.

다른 IT 리더는 멀티 클라우드가 어떻게 발전하고 초기의 복잡성에 어떻게 대처해 나갈지에 관한 견해를 공유했다. 빅데이터 컨설턴트인 트래비스 캠벨은 멀티 클라우드 여정의 시작에 관해 "멀티 클라우드를 하지만 사실상 각 부서별로 단일 클라우드처럼 다루는 기업은 특수한 경우다. 예를 들어 금융 부서는 클라우드 X에 애플리케이션을 두고 엔지니어링 부서는 클라우드 Y를 사용하며 두 부서 간에 작업과 데이터의 교류가 없는 경우를 생각해볼 수 있다. 이는 어려운 문제가 없는 멀티 클라우드다"라고 설명했다. 

따라서 이미 여러 클라우드를 다양한 용도로, 상호 독립적으로 운영 중인 경우 필연적인 다음 단계는 여러 클라우드에 걸친 애플리케이션 통합, 데이터 통합 또는 서비스 오케스트레이션이다. 여기서 어려운 문제가 시작된다. 최선의 방법은 천천히, 신중하게 진행하는 것이다.


멀티 클라우드 아키텍처의 타당성 확보

다른 IT 리더의 의견도 비슷하다. 구체적으로 많은 IT 리더가 멀티 클라우드 지원이 쉽지 않으며, IT 리더는 멀티 클라우드 아키텍처를 추구하기에 앞서 강력한 사업적 근거를 파악해야 한다고 강조한다. 필자는 이들에게 멀티 클라우드 아키텍처를 추구하는 이유를 알아보기 위해 질문했다.

엣지바나(Edgevana)의 CEO이며 창업자인 마크 티엘은 멀티 클라우드 아키텍처에서 추구할 전략적 이점에 대해 “나라면 멀티 클라우드가 고객에게 유의미한 비용적 가치, 시장 진입 속도, 더 나은 가치와 혁신, 성능 개선을 위한 고유한 기술적 역량을 제공할 때 추구할 것”이라고 말했다.

팔로알토 스트래티지 그룹(Palo Alto Strategy Group)의 기술 전문가인 마이크 D. 카일 역시 “어느 클라우드 서비스 제공업체가 제공하는 서비스가 이전 배포에 사용한 서비스보다 훨씬 더 낫다면 이것이 멀티 클라우드를 고려하는 주된 이유가 된다”면서, “인공 지능과 머신러닝을 위한 텐서플로우를 예로 들 수 있다”라고 동의했다.

HPE 특별 기술 전문가인 에드 페더스톤도 이런 의견에 동조하며 다음과 같은 운영에 관한 지침을 제시했다.

"내가 담당하는 많은 조직은 주로 기반이 되는 플랫폼 하나를 선택하고, 구체적인 필요와 솔루션의 비즈니스 혜택을 근거로 다른 플랫폼을 선택하는 방식을 사용한다. IT 리더는 전략, 지원, 프로세스 관점에서 어떻게 멀티 클라우드에 접근할지를 정해야 한다. 다른 플랫폼이 추가되는 경우 접근 방법에 일관성을 제공하기 위한 프레임워크와 체계가 필요하다. 그대로 두면 안 된다. '클라우드 난립'은 항상 재앙으로 이어지기 때문이다."

HPE 금융 서비스 최고 기술 전문가인 크리스 이빗슨은 "기업들이 퍼블릭 클라우드와 프라이빗 클라우드에서 민첩성을 추구한다"면서, "퍼블릭 클라우드 제공업체를 사용하든 하이브리드 클라우드 모델을 사용하든 프라이빗 클라우드 기능과 여러 퍼블릭 클라우드 제공업체를 혼합해 활용할 때의 초점은 변화의 민첩성과 속도에 있다. 대부분의 조직은 이미 어떤 형태로든 하이브리드 클라우드를 도입했지만 현재 초점은 멀티 클라우드로 옮겨가는 중"이라고 말했다.

IT 부서가 특정 비즈니스 또는 기술적 요구를 지원하기 위해 두 번째 클라우드 서비스 제공업체를 끌어들일 수 있다. 이 경우 IT 리더는 각각의 클라우드를 활용할 비즈니스와 사용 사례, 각 클라우드가 제공할 서비스와 기술을 명확히 규정해야 한다.

조할과 다른 전문가들이 언급한 이 외의 이유는 다음과 같다.
 
  • 규모가 큰 기업은 특히 엔터프라이즈 서비스 수준 및 가격 협상을 기대하는 경우 하나의 클라우드 서비스 제공업체에 의존하는 상황을 피하고자 한다.
  • 데이터 자주권과 규정 준수에 따라 거주 국가 내 데이터 저장, 암호화 및 데이터 보안에 관한 구체적인 요구 사항, 또는 허용되는 클라우드 서비스 제공업체에 관한 특수함이 필요한 경우가 많다.
  • 인수합병을 진행하는 조직은 손쉬운 온보딩을 구축하고 지원 구조를 간소화하기 위해 여러 클라우드 서비스 제공업체와 지원 모델을 추구하는 경우가 많다.
  • 특정 클라우드 서비스 제공업체에 배포하는 것이 다른 업체에 배포하는 경우에 비해 전략적인 비즈니스 이점이 있는 상황에서 IT 부서가 (특히 대규모로) 특정 기술 역량을 요구한다.
  • IT 부서가 개발 표준으로 채택한 퍼블릭 클라우드가 아닌 다른 퍼블릭 클라우드에서 실행되는 상용 애플리케이션을 자체 관리하기로 결정한다. 산업별 애플리케이션 및 기타 틈새 애플리케이션 중에는 단일 클라우드 서비스 제공업체의 구조와 지원 모델만 제공하는 경우가 있다.

이 외에 특히 엣지 컴퓨팅, 안전 애플리케이션, 실시간 분석에서 하이브리드 및 멀티 클라우드 아키텍처가 기술적인 이점을 제공하는 경우도 있다.


멀티 클라우드 도입에 앞서 클라우드 지원 모델 검토

기업에 멀티 클라우드 아키텍처를 지원할 만한 근거가 있더라도 IT 리더들은 여전히 재무 분석을 수행하고 클라우드 운영 모델을 검토할 것을 강하게 권장했다.

카일은 “혜택이 멀티 클라우드 아키텍처를 구축하고 운영하는 데 따르는 복잡함을 넘어설 만큼 큰지, 장단기적으로 재무 측면에 미치는 영향이 있는지를 따져봐야 한다”라고 충고했다.

뉴타닉스(Nutanix)의 고객 성공 파이낸스 부문 부사장 스티븐 카플란도 여기에 동의하며, “모든 중요한 IT 의사 결정이 그렇듯이 전략적으로 최적의 솔루션을 선택하기 위함일 뿐만 아니라 진행할 만한 타당성과 재무적 기준을 제공하기 위해서도 포괄적인 재무 분석이 필수적”이라고 말했다.

타당성이 있다면 IT 부서는 서비스 모델과 전문 기술을 단일 클라우드에서 멀티 클라우드로 확장하는 방안을 고려해야 한다. 페더스톤은 클라우드에는 기술보다 사람, 프로세스, 문화적 측면이 더 강하다면서 “기업은 대대적인 변화를 먼저 하나의 플랫폼에서 수행해 기반을 다지고 다른 플랫폼을 진전시키기 위한 틀을 마련해야 한다. 즉, 하나의 클라우드를 먼저 제대로 갖춘 다음, 추가해야 한다”라고 설명했다.

티엘은 멀티 클라우드를 확장하기 전에 몇 가지 구체적인 관행을 확립해야 한다면서 “보안, 배포, 가시성, 리소스 관리의 공통적인 프로세스를 조율하는 역량이 중요하다. 명확히 규정된 데브옵스 및 데브섹옵스 프로세스와 툴을 갖추면 효율성을 높이고 더 일관적인 보안 정책도 가능하다”라고 말했다.

프리드먼은 코드형 인프라 도구부터 시작하는 것이 좋다면서 “이와 같은 도구는 인프라 자동화와 구성을 지원한다. 클라우드 거버넌스의 전체 범위를 다루지는 않지만 프로그램 가능하고 버전 제어가 가능한 인프라를 두는 것이 중요하다”라고 권고했다. 


멀티 클라우드 아키텍처 지원을 위한 데브옵스 채택

특히 애플리케이션 배포를 위한 CI/CD와 관련해 견고한 데브섹옵스(devsecops), 인프라 프로비저닝과 구성을 위한 코드형 인프라(infrastructure as code), 그리고 AI옵스(AIops)를 포함한 모니터링 기능이 멀티 클라우드 아키텍처를 구현하고 지원하기 위해 중요하다.

그러나 필자가 이번에 인터뷰한 IT 리더에게서 배운 것은 아무 데브옵스 기술이나 데브옵스 방식을 선택하면 안 된다는 것이다. 멀티 클라우드 전략에 다른 방식보다 더 잘 맞는 것이 있다. 한 가지 방법은 AWS 클라우드포메이션(AWS CloudFormation), 애저 리소스 매니저(Azure Resource Manager) 또는 구글 클라우드 디플로이먼트 매니저(Google Cloud Deployment Manager)와 같은 클라우드 서비스 제공업체의 독점적 도구를 피하는 것이다. 이 가운데 일부 도구는 멀티 클라우드를 지원하지만 그래도 마찬가지다. 또한 기업 IT 부서는 배포 빈도에 초점을 두는 데브옵스 문화를 확장해 배포 민첩성도 반영해야 한다.

카일은 “구성 드리프트를 완화하기 위한 대책으로 코드형 인프라를 도입하고, 물론 처음부터 보안을 설계해야 한다. 테라폼(Terraform)과 같은 도구가 도움이 된다. 멀티 클라우드를 포괄할 수 있는 보안 솔루션 역시 중요하다”라고 조언했다.

여러 IT 리더가 멀티 클라우드 아키텍처로 에이전트 없고(agentless), 마스터 없는(masterless), 선언적 프로비저닝 도구를 테라폼을 권장했다. 테라폼과 패커(Packer), 도커(Docker), 쿠버네티스(Kubernetes)를 결합해 프로비저닝, 서버 템플릿, 오케스트레이션(orchestration)을 지원하는 아키텍처도 권장된다.

그러나 멀티 클라우드 구현 툴을 선택한다고 해서 구현이 여러 클라우드를 지원하게 된다는 의미는 아니다. 페더스톤은 테라폼을 권장하면서도 “한 가지 주의할 점은 테라폼은 여러 플랫폼에서 사용하기 위한 공통 언어지만 AWS를 빌드하는 코드는 애저를 빌드하지 않는다는 것이다. 이것을 클라이언트에게 이해시켜야 한다. 혜택은 팀에 코딩을 위한 공통 언어가 생긴다는 것이지만 그 대신 모든 플랫폼 기능을 사용하지 못할 수도 있다”라고 경고했다.

프리드먼은 코드형 인프라 외에 멀티 클라우드 요구 사항을 충족하기 위한 다음과 같은 도구, 방식 및 거버넌스를 권장했다.

애플리케이션과 개별 가상 머신을 위한 자동화 및 오케스트레이션
ID 관리 및 데이터 보호/암호화를 포함한 보안
감사 및 SLA 메트릭을 포함한 정책 거버넌스와 규정 준수
인프라(컴퓨팅 인스턴스, 스토리지, 네트워크)와 애플리케이션을 위한 성능 모니터링
리소스 최적화 및 청구 금액 추정을 통한 비용 관리

IT 업체는 멀티 클라우드 구현 기술도 판매한다. 예를 들어 HPE 그린레이크 센트럴(HPE GreenLake Central)은 다양한 클라우드 제공업체에 걸친 비용 및 규정 준수에 관한 시야를 제공하며, 구글 클라우드 안토스(Google Cloud Anthos)는 하이브리드 및 멀티 클라우드 환경을 위한 일관적인 개발과 운영 경험을 구현할 수 있게 해준다.

멀티 클라우드의 미래에 대비
여러 퍼블릭 클라우드 도입에 따르는 지금의 온갖 복잡성에도 불구하고 IT 리더의 공통된 의견은 대부분의 기업이 멀티 클라우드 아키텍처를 지원할 것이며, 나아가 여러 클라우드에 걸쳐 애플리케이션을 통합할 것이라는 점이다. 이는 지난 경험에서도 배울 수 있다. 예를 들어 기업은 한 가지 플랫폼을 고수해야 할 수많은 근거에도 불구하고 리눅스와 윈도우, 닷넷과 자바, 오라클과 마이크로소프트 SQL 데이터베이스를 지원해야 했다.
 
IT 리더들의 결론은 다음과 같다.
크리스 이빗슨: 앞으로 3~5년 동안 멀티 클라우드가 발전하면서 더 많은 워크로드가 기본적으로 주 클라우드 제공업체에서 추상화되어 나오도록 설계될 것이다. 여러 클라우드 제공업체가 실현할 수 있는, 인공 지능이나 머신러닝, 분석과 같은 고급 기능에 초점이 맞춰질 것이다. 
마이크 D. 카일: 단일 클라우드에서 먼저 해결한 다음 멀티 클라우드가 적합한지 여부를 판단하라. 
사브지트 조할: 멀티 클라우드 아키텍처는 어렵고 유지 비용도 많이 든다. 단일 클라우드 제공업체에는 전략적으로, 멀티 클라우드 과업에는 전술적으로 대처해야 한다. 어떤 경우에도 동일한 워크로드에 대해 인프라 계층에서 멀티 클라우드를 추진하는 것은 피해야 한다.
조안 프리드먼: 최소 저항 경로를 택하고, 보안에 먼저 초점을 맞춘 다음 정책을 통해 자동화와 오케스트레이션을 견고하게 다져야 한다.

트래비스 캠벨은 "이 분야에서 성공적인 사람은 최소 공통 분모를 찾는다. 각 제공업체에서 최소한의 요소를 사용해 각자의 계층을 그 위에 올려 추상화를 처리한다. 한 번 빌드하고 모든 곳에서 실행하는 것은 우리 모두가 추구하는 이상이지만 거기까진 여전히 갈 길이 멀다"라고 요약했다. editor@itworld.co.kr


2020.12.16

'멀티 클라우드, 준비됐는가' 멀티 클라우드를 도입하기 전 준비 체크리스트

Isaac Sacolick | InfoWorld
처음 클라우드 네이티브 Node.js 애플리케이션을 아마존 웹 서비스(Amazon Web Services)에 배포하게 되면, 이후 여러 레거시 닷넷 애플리케이션을 퍼블릭 클라우드로 전환하라는 작업 지시를 받을 수 있다.

처음 단계로 아마존 라이트세일(Lightsail)을 사용해야 할까, 아니면 마이크로소프트 애저가 제공하는 닷넷 개발자를 위한 옵션이 더 나을까, 또는 현재 애저에서 실행 중인 애플리케이션을 데이터 과학 팀이 구글 클라우드 플랫폼에 배포한 머신러닝 모델에 안전하게 연결해야 하는 경우도 있다. 개발 팀과 데이터 과학 팀이 여러 애플리케이션과 데이터베이스, 마이크로서비스, 머신러닝 모델을 연구하고 프로토타이핑하고 배포해야 하는 시나리오는 어렵지 않게 상상할 수 있다.
 
ⓒ Getty Images Bank

대기업에서는 복수의 클라우드 지원은 거의 필연적이다. 모든 개발, 데이터 과학, 섀도우 IT 작업을 하나의 퍼블릭 클라우드로 보내기 위해 필요한 막대한 수준의 거버넌스 때문이다. 그렇다 해도 글로벌 기업과 대기업이 '멀티 클라우드화'를 전략적으로 중요하다고 판단하는 데는 여러 가지 이유가 있다.

필자는 IDG테크토크(IDGTechTalk), CIO챗(CIOChat)과 같은 소셜 채팅을 통해 트위터에서 활동하는 IT 리더에게 연락해 기업이 여러 클라우드를 지원해야 하는지 여부와 지원하는 방법에 관한 의견을 구했다. 이 체크리스트에는 멀티 클라우드 준비에 관한 이들의 경험과 의견이 포함돼 있다. 이제 준비가 됐는가?


멀티 클라우드 복잡성에 친숙해지기

IT 리더들은 안전하고 견고한 클라우드 인프라 설정의 복잡함에 익숙하다. 여러 클라우드를 결합할 때 이러한 복잡성은 당연히 배가된다. 한번에 모든 클라우드를 다루는 것은 바람직하지 않으므로 가급적 피해야 한다.

여러 클라우드에 걸친 운영은 많은 거버넌스와 기술 전문 지식, 통합이 필요한 복잡한 과업이다. 독립 기술 전문가인 사브지트 조할은 "어느날 갑자기 ‘오늘부터 멀티 클라우드를 해야겠다’고 결심하는 경우는 없다. 주로 기업의 사일로에 의해 의지와 관계없이 멀티 클라우드화된다. 멀티 클라우드를 쉽다고 말하는 사람도 결코 없다"라고 말했다.

커넥티드마인즈(Connektedminds) CEO인 조안 프리드먼은 IT 팀은 다른 제공업체에서 새롭거나 더 나은 기능을 물색하는 대신 가능한 모든 상황에서 주 클라우드 제공업체를 활용하는 것이 좋다면서 “하나의 퍼블릭 클라우드에서 모든 것을 해결할 수 없다는 것을 받아들여야 한다. 한 제공업체에서 필요한 일의 40%~60% 정도만 가능하다”라고 말했다.

다른 IT 리더는 멀티 클라우드가 어떻게 발전하고 초기의 복잡성에 어떻게 대처해 나갈지에 관한 견해를 공유했다. 빅데이터 컨설턴트인 트래비스 캠벨은 멀티 클라우드 여정의 시작에 관해 "멀티 클라우드를 하지만 사실상 각 부서별로 단일 클라우드처럼 다루는 기업은 특수한 경우다. 예를 들어 금융 부서는 클라우드 X에 애플리케이션을 두고 엔지니어링 부서는 클라우드 Y를 사용하며 두 부서 간에 작업과 데이터의 교류가 없는 경우를 생각해볼 수 있다. 이는 어려운 문제가 없는 멀티 클라우드다"라고 설명했다. 

따라서 이미 여러 클라우드를 다양한 용도로, 상호 독립적으로 운영 중인 경우 필연적인 다음 단계는 여러 클라우드에 걸친 애플리케이션 통합, 데이터 통합 또는 서비스 오케스트레이션이다. 여기서 어려운 문제가 시작된다. 최선의 방법은 천천히, 신중하게 진행하는 것이다.


멀티 클라우드 아키텍처의 타당성 확보

다른 IT 리더의 의견도 비슷하다. 구체적으로 많은 IT 리더가 멀티 클라우드 지원이 쉽지 않으며, IT 리더는 멀티 클라우드 아키텍처를 추구하기에 앞서 강력한 사업적 근거를 파악해야 한다고 강조한다. 필자는 이들에게 멀티 클라우드 아키텍처를 추구하는 이유를 알아보기 위해 질문했다.

엣지바나(Edgevana)의 CEO이며 창업자인 마크 티엘은 멀티 클라우드 아키텍처에서 추구할 전략적 이점에 대해 “나라면 멀티 클라우드가 고객에게 유의미한 비용적 가치, 시장 진입 속도, 더 나은 가치와 혁신, 성능 개선을 위한 고유한 기술적 역량을 제공할 때 추구할 것”이라고 말했다.

팔로알토 스트래티지 그룹(Palo Alto Strategy Group)의 기술 전문가인 마이크 D. 카일 역시 “어느 클라우드 서비스 제공업체가 제공하는 서비스가 이전 배포에 사용한 서비스보다 훨씬 더 낫다면 이것이 멀티 클라우드를 고려하는 주된 이유가 된다”면서, “인공 지능과 머신러닝을 위한 텐서플로우를 예로 들 수 있다”라고 동의했다.

HPE 특별 기술 전문가인 에드 페더스톤도 이런 의견에 동조하며 다음과 같은 운영에 관한 지침을 제시했다.

"내가 담당하는 많은 조직은 주로 기반이 되는 플랫폼 하나를 선택하고, 구체적인 필요와 솔루션의 비즈니스 혜택을 근거로 다른 플랫폼을 선택하는 방식을 사용한다. IT 리더는 전략, 지원, 프로세스 관점에서 어떻게 멀티 클라우드에 접근할지를 정해야 한다. 다른 플랫폼이 추가되는 경우 접근 방법에 일관성을 제공하기 위한 프레임워크와 체계가 필요하다. 그대로 두면 안 된다. '클라우드 난립'은 항상 재앙으로 이어지기 때문이다."

HPE 금융 서비스 최고 기술 전문가인 크리스 이빗슨은 "기업들이 퍼블릭 클라우드와 프라이빗 클라우드에서 민첩성을 추구한다"면서, "퍼블릭 클라우드 제공업체를 사용하든 하이브리드 클라우드 모델을 사용하든 프라이빗 클라우드 기능과 여러 퍼블릭 클라우드 제공업체를 혼합해 활용할 때의 초점은 변화의 민첩성과 속도에 있다. 대부분의 조직은 이미 어떤 형태로든 하이브리드 클라우드를 도입했지만 현재 초점은 멀티 클라우드로 옮겨가는 중"이라고 말했다.

IT 부서가 특정 비즈니스 또는 기술적 요구를 지원하기 위해 두 번째 클라우드 서비스 제공업체를 끌어들일 수 있다. 이 경우 IT 리더는 각각의 클라우드를 활용할 비즈니스와 사용 사례, 각 클라우드가 제공할 서비스와 기술을 명확히 규정해야 한다.

조할과 다른 전문가들이 언급한 이 외의 이유는 다음과 같다.
 
  • 규모가 큰 기업은 특히 엔터프라이즈 서비스 수준 및 가격 협상을 기대하는 경우 하나의 클라우드 서비스 제공업체에 의존하는 상황을 피하고자 한다.
  • 데이터 자주권과 규정 준수에 따라 거주 국가 내 데이터 저장, 암호화 및 데이터 보안에 관한 구체적인 요구 사항, 또는 허용되는 클라우드 서비스 제공업체에 관한 특수함이 필요한 경우가 많다.
  • 인수합병을 진행하는 조직은 손쉬운 온보딩을 구축하고 지원 구조를 간소화하기 위해 여러 클라우드 서비스 제공업체와 지원 모델을 추구하는 경우가 많다.
  • 특정 클라우드 서비스 제공업체에 배포하는 것이 다른 업체에 배포하는 경우에 비해 전략적인 비즈니스 이점이 있는 상황에서 IT 부서가 (특히 대규모로) 특정 기술 역량을 요구한다.
  • IT 부서가 개발 표준으로 채택한 퍼블릭 클라우드가 아닌 다른 퍼블릭 클라우드에서 실행되는 상용 애플리케이션을 자체 관리하기로 결정한다. 산업별 애플리케이션 및 기타 틈새 애플리케이션 중에는 단일 클라우드 서비스 제공업체의 구조와 지원 모델만 제공하는 경우가 있다.

이 외에 특히 엣지 컴퓨팅, 안전 애플리케이션, 실시간 분석에서 하이브리드 및 멀티 클라우드 아키텍처가 기술적인 이점을 제공하는 경우도 있다.


멀티 클라우드 도입에 앞서 클라우드 지원 모델 검토

기업에 멀티 클라우드 아키텍처를 지원할 만한 근거가 있더라도 IT 리더들은 여전히 재무 분석을 수행하고 클라우드 운영 모델을 검토할 것을 강하게 권장했다.

카일은 “혜택이 멀티 클라우드 아키텍처를 구축하고 운영하는 데 따르는 복잡함을 넘어설 만큼 큰지, 장단기적으로 재무 측면에 미치는 영향이 있는지를 따져봐야 한다”라고 충고했다.

뉴타닉스(Nutanix)의 고객 성공 파이낸스 부문 부사장 스티븐 카플란도 여기에 동의하며, “모든 중요한 IT 의사 결정이 그렇듯이 전략적으로 최적의 솔루션을 선택하기 위함일 뿐만 아니라 진행할 만한 타당성과 재무적 기준을 제공하기 위해서도 포괄적인 재무 분석이 필수적”이라고 말했다.

타당성이 있다면 IT 부서는 서비스 모델과 전문 기술을 단일 클라우드에서 멀티 클라우드로 확장하는 방안을 고려해야 한다. 페더스톤은 클라우드에는 기술보다 사람, 프로세스, 문화적 측면이 더 강하다면서 “기업은 대대적인 변화를 먼저 하나의 플랫폼에서 수행해 기반을 다지고 다른 플랫폼을 진전시키기 위한 틀을 마련해야 한다. 즉, 하나의 클라우드를 먼저 제대로 갖춘 다음, 추가해야 한다”라고 설명했다.

티엘은 멀티 클라우드를 확장하기 전에 몇 가지 구체적인 관행을 확립해야 한다면서 “보안, 배포, 가시성, 리소스 관리의 공통적인 프로세스를 조율하는 역량이 중요하다. 명확히 규정된 데브옵스 및 데브섹옵스 프로세스와 툴을 갖추면 효율성을 높이고 더 일관적인 보안 정책도 가능하다”라고 말했다.

프리드먼은 코드형 인프라 도구부터 시작하는 것이 좋다면서 “이와 같은 도구는 인프라 자동화와 구성을 지원한다. 클라우드 거버넌스의 전체 범위를 다루지는 않지만 프로그램 가능하고 버전 제어가 가능한 인프라를 두는 것이 중요하다”라고 권고했다. 


멀티 클라우드 아키텍처 지원을 위한 데브옵스 채택

특히 애플리케이션 배포를 위한 CI/CD와 관련해 견고한 데브섹옵스(devsecops), 인프라 프로비저닝과 구성을 위한 코드형 인프라(infrastructure as code), 그리고 AI옵스(AIops)를 포함한 모니터링 기능이 멀티 클라우드 아키텍처를 구현하고 지원하기 위해 중요하다.

그러나 필자가 이번에 인터뷰한 IT 리더에게서 배운 것은 아무 데브옵스 기술이나 데브옵스 방식을 선택하면 안 된다는 것이다. 멀티 클라우드 전략에 다른 방식보다 더 잘 맞는 것이 있다. 한 가지 방법은 AWS 클라우드포메이션(AWS CloudFormation), 애저 리소스 매니저(Azure Resource Manager) 또는 구글 클라우드 디플로이먼트 매니저(Google Cloud Deployment Manager)와 같은 클라우드 서비스 제공업체의 독점적 도구를 피하는 것이다. 이 가운데 일부 도구는 멀티 클라우드를 지원하지만 그래도 마찬가지다. 또한 기업 IT 부서는 배포 빈도에 초점을 두는 데브옵스 문화를 확장해 배포 민첩성도 반영해야 한다.

카일은 “구성 드리프트를 완화하기 위한 대책으로 코드형 인프라를 도입하고, 물론 처음부터 보안을 설계해야 한다. 테라폼(Terraform)과 같은 도구가 도움이 된다. 멀티 클라우드를 포괄할 수 있는 보안 솔루션 역시 중요하다”라고 조언했다.

여러 IT 리더가 멀티 클라우드 아키텍처로 에이전트 없고(agentless), 마스터 없는(masterless), 선언적 프로비저닝 도구를 테라폼을 권장했다. 테라폼과 패커(Packer), 도커(Docker), 쿠버네티스(Kubernetes)를 결합해 프로비저닝, 서버 템플릿, 오케스트레이션(orchestration)을 지원하는 아키텍처도 권장된다.

그러나 멀티 클라우드 구현 툴을 선택한다고 해서 구현이 여러 클라우드를 지원하게 된다는 의미는 아니다. 페더스톤은 테라폼을 권장하면서도 “한 가지 주의할 점은 테라폼은 여러 플랫폼에서 사용하기 위한 공통 언어지만 AWS를 빌드하는 코드는 애저를 빌드하지 않는다는 것이다. 이것을 클라이언트에게 이해시켜야 한다. 혜택은 팀에 코딩을 위한 공통 언어가 생긴다는 것이지만 그 대신 모든 플랫폼 기능을 사용하지 못할 수도 있다”라고 경고했다.

프리드먼은 코드형 인프라 외에 멀티 클라우드 요구 사항을 충족하기 위한 다음과 같은 도구, 방식 및 거버넌스를 권장했다.

애플리케이션과 개별 가상 머신을 위한 자동화 및 오케스트레이션
ID 관리 및 데이터 보호/암호화를 포함한 보안
감사 및 SLA 메트릭을 포함한 정책 거버넌스와 규정 준수
인프라(컴퓨팅 인스턴스, 스토리지, 네트워크)와 애플리케이션을 위한 성능 모니터링
리소스 최적화 및 청구 금액 추정을 통한 비용 관리

IT 업체는 멀티 클라우드 구현 기술도 판매한다. 예를 들어 HPE 그린레이크 센트럴(HPE GreenLake Central)은 다양한 클라우드 제공업체에 걸친 비용 및 규정 준수에 관한 시야를 제공하며, 구글 클라우드 안토스(Google Cloud Anthos)는 하이브리드 및 멀티 클라우드 환경을 위한 일관적인 개발과 운영 경험을 구현할 수 있게 해준다.

멀티 클라우드의 미래에 대비
여러 퍼블릭 클라우드 도입에 따르는 지금의 온갖 복잡성에도 불구하고 IT 리더의 공통된 의견은 대부분의 기업이 멀티 클라우드 아키텍처를 지원할 것이며, 나아가 여러 클라우드에 걸쳐 애플리케이션을 통합할 것이라는 점이다. 이는 지난 경험에서도 배울 수 있다. 예를 들어 기업은 한 가지 플랫폼을 고수해야 할 수많은 근거에도 불구하고 리눅스와 윈도우, 닷넷과 자바, 오라클과 마이크로소프트 SQL 데이터베이스를 지원해야 했다.
 
IT 리더들의 결론은 다음과 같다.
크리스 이빗슨: 앞으로 3~5년 동안 멀티 클라우드가 발전하면서 더 많은 워크로드가 기본적으로 주 클라우드 제공업체에서 추상화되어 나오도록 설계될 것이다. 여러 클라우드 제공업체가 실현할 수 있는, 인공 지능이나 머신러닝, 분석과 같은 고급 기능에 초점이 맞춰질 것이다. 
마이크 D. 카일: 단일 클라우드에서 먼저 해결한 다음 멀티 클라우드가 적합한지 여부를 판단하라. 
사브지트 조할: 멀티 클라우드 아키텍처는 어렵고 유지 비용도 많이 든다. 단일 클라우드 제공업체에는 전략적으로, 멀티 클라우드 과업에는 전술적으로 대처해야 한다. 어떤 경우에도 동일한 워크로드에 대해 인프라 계층에서 멀티 클라우드를 추진하는 것은 피해야 한다.
조안 프리드먼: 최소 저항 경로를 택하고, 보안에 먼저 초점을 맞춘 다음 정책을 통해 자동화와 오케스트레이션을 견고하게 다져야 한다.

트래비스 캠벨은 "이 분야에서 성공적인 사람은 최소 공통 분모를 찾는다. 각 제공업체에서 최소한의 요소를 사용해 각자의 계층을 그 위에 올려 추상화를 처리한다. 한 번 빌드하고 모든 곳에서 실행하는 것은 우리 모두가 추구하는 이상이지만 거기까진 여전히 갈 길이 멀다"라고 요약했다. editor@itworld.co.kr


X