[Cloud 인프라 아키텍트 방법론] 클라우드 환경으로 가기 전 우리가 인지 해야하는 점들

- CSP 환경으로 가기 위한 조건

 보통 Onpremise환경에서 클라우드 환경으로의 변화를 고려할 때, 막막함을 느끼기 마련이다. 처음 시작할 때는 도대체 왜 클라우드 환경으로 전환을 해야 하는지, 전환해서 얻는 이점이 도대체 무엇인지 처음에는 알지 못했다. (사실 그 당시 전환이 진행된 이유는 남들이 하니 우리도 해야 한다는 목적이 대부분이었다.)  클라우드 환경으로 갔을 때, 어떤 장단점이 있고, 어떤 환경에 어울리는지는 전환이 다 끝나고 운영을 하며 현실과 맞닿고 무지성적인 전환의 흔적들의 정리하며 비로소 알게 되었다.

나의 경험에 비추어 보았을 때 클라우드로 가기 전 반드시 고려해야 할 요소는 아래와 같다.

 

1. 고객과 사용자의 클라우드 환경에 대한 이해

  고객과 서비스 사용자 관점에서는 사실 Onpremise나 클라우드나 차이점은 찾기 어렵다. 쓰는 입장에서는 똑같으니까..

 근데 운영자적인 입장에서는 아주 큰 차이점이 있다. Onpremise장비의 오프라인은 내가 일정을 정해서 정시에 끄고, 내 입맛에 맞는 시간에 변경 작업을 수행할 수 있다. 근데 클라우드 환경에서는 장비를 내가 가지고 있지 않기 때문에, CSP사의 입맛대로 일정을 맞출 수밖에 없다. 예를 들어보자 Azure에는 Maintenance가 있다. 공식 Maintenance는 최소 1개월 전 공지를 해주고, 비공식 Maintenance는 15분 전에 공지를 해준다. 날짜와 시간은 내가 정할 수도 없고, 시간이 정해지면 나는 그날이 오기만을 기다려야 할 뿐이다.(물론 MI와 같은 몇몇 리소스들은 시간 바운더리를 정할 수 있기는 하다.)  AWS라고 다르지 않다. 예를 들면 RDS에 업데이트 공고가 뜨면 나는 그 일정이 오기 전에 작업을 수행해야만 한다.(물론 업데이트가 주요 업데이트인지 세부 업데이트인지 다르겠지만..)

 고객과 사용자는 자신의 서비스가 클라우드 환경으로 바뀌면서 이러한 예기치 않은 작업에 대한 끊김에 대한 이해를 인지하고 있어야 한다. 이 Maintenance는 Onpremise처럼 업무의 Prime Time을 벗어나지 못할 수도 있는 것이다.

 장애 끊김에 대한 보상? 한국 문화와는 다르게 외국 서비스는 SLA가 철저하다. (심지어 maintenance로 인한 끊김은 SLA로도 보상받지 못한다.) 끊기면 SLA대로 보상해주겠다가 방침이다. 예시로 Azure의 SLA는 아래 URL에도 아주 상세히 나와있다. https://azure.microsoft.com/ko-kr/support/legal/sla/

 

2. 비용적인 이슈

  언뜻 보면 Onpremise보다 클라우드 환경이 저렴해 보인다. 하지만 클라우드 환경에 적합하지 않은 상품을 적용했을 때, 비용은 더 많이 나올지도 모른다. Cloud에 상품이 다양한 만큼 적절한 상품을 사용하지 않았을 경우, 비용적 성능적 이슈에 봉착할 수밖에 없다. 예를 들어보자 Cloud에 상품이 다양한 만큼  Hot Storage, Cool Storage, Archive Storage 등 기능에 따라 비용 정책이 아주 상이하다.(AWS S3 Glacier 혹은 Azure Blob Storage) Hot Storage의 빈도를 갖춘 Storage를 무심코 Arichive용도로 설정한다면 대참사가 일어날 것이다. 또한 기본 네트워크 자원의 세팅이 필요하고, 몇몇 리소스에 대해서는 기본 비용이 있기 때문에 많지 않은 VM 수를 가진 서비스의 경우에는 ROI가 안 나오는 경우도 허다하다.

반드시 CSP에서 제공하는 비용 계산기를 통해 ROI를 계산해보길 바란다. 

 

3. 아키텍처 변경

 보통 Onpremise에서는 서버 기준으로 서비스를 구성한다. 네트워크 환경만 구성되면 서버를 일렬종대로 세워두고 구성하기만 하면 되는 것이다. 만약 클라우드 환경에서도 Onpremise의 서버를 VM, EC2 만으로 바꾸어서 Rehost방법으로 전환한다면 클라우드로 전환하는 의미가 크지 않다. 브랜드만 다른 같은 색의 옷을 입는 것뿐이다.클라우드의 동적인 그리고 무궁무진한 확대 요소를 고려하기 위해서는 Replatform, Refactor 등 Application단에서의 변화가 반드시 필요하다. 물론 전환 비용에 개발비용까지 비용적인 요소의 증가는 불가피하다. 하지만 진정한 클라우드로의 전환을 위해서는 Rehost로의 전환은 추천하지 않는다. CSP에서도 자체적으로 K8s, Container를 지원하고 그밖에 데이터 웨어하우스, AI, 메시징, 큐 확장해나갈 서비스들이 정말 많다. 전환할 때 반드시 고려해보기 바란다.

 

 

 세상에 무조건 좋은 건 없다. 심지어 싸고 질 좋은 건, 더 찾기 어렵다. 클라우드 환경이라고 다를까? 클라우드 환경에서 싸고 나에게 적합한 좋은 물건을 찾기 위해, 위와 같은 사항들을 반드시 고려해보자.

 다음 시간에는 그래서 AWS 써야 하는지 Azure를 써야하는지 아니면 제3의 클라우드를 써야 하는지 알아보도록 하자.