2021년 11월 30일 화요일

많은 기업들이 하나의 Public Cloud Vendor의 Cloud Platform를 사용하는 것보다 여러 다른 Public Cloud Vendor들의 Cloud Platform들을 동시에 사용하는 Multi-Cloud 전략을 사용하는 추세이다. 하지만 많은 한국기업들의 Multi-Cloud 의사결정들이 그 결정으로 인해서 추가되는 기술과 운영 복잡도와 인력투자에 대한 평가없이 이루어져서 추후에 기대했던 효과를 못 누리는 안타까운 현상을 많이 목격하였다.

대부분은 기업들은 특정 Vendor에 Lock-in이 되기 싫고, 필요시에 더 좋은 가격을 제공하는 Vendor로 손쉽게 옮기고 싶고, 마지막으로 특정 Vendor의 장애에 영향을 받기 싫어서 Multi-Cloud 전략을 선택하게 된다. 1위 세가지 이유는 어떤 제품을 사용하더라도 모든 기업들이 이루고 싶은 부분임을 동의하나, 이를 가능하게 하려면 크게 두가지 전제 조건이 존재한다.

첫째, 타 Vendor가 제공하는 서비스나 기술이 현재 사용하는 Vendor가 제공하는 서비스나 기술과 유사한 성능, 결과 등을 보장할 수 있어야 한다. 만약 그렇지 않다면, Migration 이후에 유사한 성능, 결과 등을 보장할 수 없게 된다. 예를 들어서 Serverless Service의 timeout 시간이 달라서 Migration 이후에 Time-out이 되는 현상도 발생할 수 있다. 또한 가격 비교를 위해서도, 유사한 환경을 구축할 수 있어야 비교가 가능하다.

둘째, Migration 시간이 짧아야한다. 만약 문제 발생을 인지한 후에 Migration을 하려는데에 많은 시간이 소요된다면, 차라리 해당 문제가 기존 Vendor에서 해결되기를 기다리는 것이 더 빠른 문제 해결이 될 수 있기 때문이다. 예를 들어서 SLA가 99.9%인 서비스를 기존에 사용하고, 평균적으로 1년이 2번정도 문제가 발생하고, 도합 1년에 최대 Downtime을 발생 시킨다면, Migration은 적어도 4시간 안에는 끝나야 거의 비슷한 Uptime이 된다. 물론 더 자주 문제가 발생한다면 시간은 계속 줄어들 것이다.

위 두가지 조건을 만족하기 위해서 많은 기업들은 Public Cloud Vendor들의 Infrastructure As-a-Service (IaaS)만, 특히 Migration이 매우 용이한 Container Service만 사용하려고 하는 현상을 많이 목격했다. 하지만 이는 Platform As-a-Service (PaaS)나 Software As-a-Service (SaaS)를 이용하는 것보다 훨씬 많은 운영 비용이 발생하게 된다. 왜냐하면, Infra를 제외한 모든 운영이 결국 기업의 책임이 되기 때문이다. 예를 들어서 Managed Database Service를 사용하면 신경 안써도 되는 Backup과 Failure 처리도 다 기업이 책임을 져야한다.

또한 한 화면에서 현재 기업이 사용하는 여러 Cloud Vendor들의 서비스 상태를 보려면 추가적으로 개발하거나 새로운 서비스를 사용해야한다. 현재 각 Vendor별로 Monitoring하는 서비스들은 잘 되어있는 편이긴하나, 모든 Cloud Vendor들을 통합해서 보여주는 서비스는 유료 서비스이고 통상적으로 log data의 크기로 돈을 지불해야함으로 꽤 비싼 가격을 지불해야할 수도 있다.

마지막으로 기업에게 Multi-Cloud 전략은 매우 중요한 전략이긴 하나, 이를 이루기 위해서 현재 놓치고 있는 것들을 살펴봄으로서 효과적인 의사결정을 할 수 있을 것이라 생각한다. 다음글에서 어떤 방식과 의사결정으로 Multi-Cloud 전략을 구축해야지 효과적인 Multi-Cloud 전략이 되는지에 대해서 살펴보고자 한다.

  1. Multi-Cloud Strategy

    Related Posts

    클라우드 서비스와 오픈소스 라이선싱
    ML 모델 도입을 위한 SageMaker의 효율성
    클라우드 환경에서의 데이터베이스 가용성

    3 Responses

    1. Pingback : Muti-Cloud 전략의 유의점 - 클라우드 인사이트

    2. Pingback : Service Mesh 에서의 Control Plane, Consul - 클라우드 인사이트

    Leave a Reply