2022년 5월 18일 수요일

Public Cloud를 사용하는 많은 기업들은 Public Cloud vendor가 제공하는 as-a-Service (aaS)들을 이용한다. aaS 개념이 기존에 하드웨어와 소프트웨어를 구매해서 사용하는 방식과 다른 점들이 많아서 기존 방식에 익숙한 기업들이 Public Cloud의 aaS를 사용하게 되면서 aaS가 가진 장점을 이용하지 못하는 상황들이 많다. 이번 시리즈에서는 aaS의 개념과 이에 따른 특징들과 사용시에 고려사항들에 대해서 설명하고자 한다.

aaS를 풀어서 설명하면 서비스로 원하는 것을 얻는다이다. 이 개념을 예전부터 많이 글들과 영상들에서 비교하면서 설명했던 개념이 수도이다. 기존의 방식이 사람이 직접 우물을 파거나 계곡으로 가서 본인에게 만족하는 온도의 물을 길러오는 방식이었다면, 현대사회처럼 수돗물을 틀면 물이 나오고 사용한만큼 돈을 지불하는 방식이 aaS와 가깝다. 이 두가지 방식의 대표적인 차이점들은 제어할 수 있는 부분, 가격정책, 그리고 문제발생시 해결방법이다.

기존에는 통상적으로 aaS를 Infrastructure as-a-Service (IaaS), Platform as-a-Service (PaaS), 또는 Software as-a-Service (SaaS)로 구분하여 사용자가 무엇을 제어할수 있는지를 구분지었다. 하지만 요즘 trend로는 굳이 이렇게 구분하는 것보다 사용자가 원하는 것이 무엇인지에 따라서 자연스럽게 무엇을 할 수 있는지가 구분되게 된다. 다시 수도 예제로 돌아가면, 원할때마다 원하는 곳에 바로 물을 가지고 올 수 있는 우물을 만들어주는 서비스가 있다면, 사용자는 어떻게 우물이 만들어지는 중요한 사항이 아니다. 서비스라면 오히려 어느정도 물의 양이 유지되는지와 얼마나 깨끗한 물인지를 선택해야한다. IaaS에서 Storage Service를 사용할때에 어떤 기술인지는 중요한게 아니며 속도나 가용성을 주어진 옵션들에서 선택해서 사용하는 부분과 유사하다. 

기존 방식에서의 가격은 내가 하드웨어나 소프트웨어를 구매해서 사용하는 것이라 많은 돈을 지불하고 감가상각을 해가는 방식이다. 하지만 aaS는 사용한만큼 지불하는 방식이라 구매하는 것은 해당 시간만큼의 서비스이다. 이론적으로는 필요한만큼 무한정으로 서비스를 얻을 수 있으며, 아주 짧게 사용하는 것도 가능하다. 그리고 해당 시간과 서비스의 양만큼 돈을 지불하면 된다. 통상적으로 기존 방식에 익숙한 기업들이 비용에 대한 예측을 어려워하고 기존보다 더 많은 비용을 지불하게 되는 현상들이 있는데 이 부분에 대해서는 다음 글에 설명이 되어있다.

마지막으로 aaS는 사용자가 서비스 받는 기능에 문제가 있을 시에 소프트웨어나 하드웨어 vendor들에게 연락해서 문제를 해결하는 것이 아닌 서비스 제공자가 문제 발생을 감지하고 해결을 하는 방식이다. 물론 문제 해결이 오래 걸려서 사용자가 서비스를 정상적으로 사용하지 못하는 경우도 있으며, 이를 위해서 Service Level Agreement (SLA)가 있으며, 이를 어길 시에는 얼마의 금전적 보상을 하는 것이 통상적이다. 이 부분이 가능한 이유는, 서비스 제공자는 모든 사용자들에게 크게 보면 같은 구성으로 제공하니까 한 곳에서의 문제가 다른 고객에게 똑같이 발생할 확률이 높음으로 문제발생시 빠른 대처를 위해서 항상 모니터링 및 문제해결을 한다.

기존의 방식으로 운영하던 여러 회사들이 Cloud에서 IaaS를 사용하면서 기존에 구매한 소프트웨어의 운영을 아웃소싱하는 방식이 결국 aaS와 유사하다고 생각한다. 기존 기업 입장에서는 어차피 제어하는 부분은 똑같이 요구사항만 전달하고, 관리에 대한 비용을 지불하며, 장애처리를 해주니까 크게 보는 특징들에서는 다른점이 없어보인다. 하지만 크게 다른점은 해당 방식은 Cloud에서 aaS를 사용하는 장점을 이용하지 않는 방식이다. 만약 IaaS 위에 기존 구매한 소프트웨어을 설치해서 운영하는 방식을 아웃소싱 하는 상황이라면, 현재 trend에 따라 가격과 확장성을 위해 1 Serverless로 변경은 불가능하게 된다. 또한 Cloud에서 새로 만든 서비스들과 연동해서 사용하기에도 해당 소프트웨어가 지원을 하지 않는다면 불가능하게 된다. 마지막으로 해당 소프트웨어에 문제가 발생하여도 아웃소싱한 회사는 해당 제품의 소스를 가지고 있는 회사가 아니기에 책임을 지고 문제해결을 할 수 없다. 하지만 aaS는 SLA때문에 추가적으로 내부비용이 발생하더라도 사용자에게 추가 요금을 청구하지 않고 사용자가 서비스를 사용할 수 있는 상태로 만들어준다. 이런 차이점으로 인해서 운영을 아웃소싱하는 방식이 아닌, Cloud의 전문성을 가지는 Cloud Managed Service Partner (MSP)와 협업하여 요구사항에 맞는 Cloud aaS를 이용하고 운영하는 방식을 많이 사용한다. 2

다음 글에서는 Public Cloud aaS를 사용할 때에 위의 특징들로 인한 유의할 점에 대해서 살펴보고자 한다.

  1. It’s The End Of Infrastructure-As-A-Service As We Know It: Here’s What’s Next
  2. 6 Key Capabilities for Cloud Managed Service Providers

    Related Posts

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

    1 Response

    Leave a Reply