2021년 11월 30일 화요일

Public Cloud의 As-a-Service – Part I 사용시 고려사항

앞에 글에서 살펴보았듯이, 기존에 소프트웨어와 하드웨어를 구매해서 사용하는 방식과 Public Cloud의 As-a-Service에는 차이점들이 있다. 이 차이점을 이해한다고 하더라도 아직도 많은 기업들이 Public Cloud Vendor들이 제공하는 As-a-Service (aaS)를 사용하면서 어려움을 겪는 부분들이 존재한다. 특히 기술과 비용 측면에서 어려움이나 답답함을 표현하는 사례들을 접했었다.

기술적으로 As-a-Service는 Blackbox와 같다. 즉 내부적으로 어떤 기술을 이용하였는지에 대해서 상세한 설명을 하는 공식 문서들은 일부 Infrastructure as-a-Service (IaaS)를 제외하고 존재하지 않는다. 물론 새로운 서비스 내부 동작 방식을 알려주는 architecture들은 존재하나, 이 또한 새로운 서비스의 설명을 위한 그 당시의 architecture를 알려주는 것으로 공식적인 technical documentation은 존재하지 않는다. 이런식으로 As-a-Service를 운영하는 이유는 해당 architecture나 기술이 고객들의 요구사항들에 따라서 계속 변경되기 때문이다.

예를 들어서 어느 Database As-a-Service가 Active-Active방식의 가용성 보장을 하는 기능을 새로 만들었다면, 해당 서비스가 어떤 방식으로 Active-Active가 가능한지는 고객의 입장에서 중요한 사항이 아니다. 중요한 사항은 해당 기능을 사용할 때에 여러 node에서의 Transaction은 보장이 되는지, 그로 인한 기능저하가 있는지, Failover 시간은 어떻게 되는지 등등 해당 서비스를 사용하는 appplication의 요구사항에 대한 확인이고 만약 만족하지 못한다면 해당 Service의 Roadmap에서 부족한 요구사항들이 충족되는 기능들의 enhancement가 있을지를 확인하는 것이다. 하지만 기존 방식에 익숙한 몇몇 담당자들은 대부분 Active-Active가 어떤 방식으로 구현이 되었는지 궁금해하며, 이를 통해서 해당 기능으로 가능한 시나리오 및 한계점들을 유추하려고 한다. 하지만 위에도 언급 되었지만, 현재 구현한 방식과 기술은 빠르면 1달 뒤에 더 많은 usecase들을 만족하기 위해서 바뀔수 있기 때문에 요구사항들과 해당 서비스의 Roadmap이 오히려 중요한 부분이 된다. 기존과 같이 자세한 기술을 이해해야만 추후에 운영 시에 문제가 발생 안되도록 application을 만들어야하는 성향은 As-a-Service와 같이 해당 제품의 운영을 안해도 되는 상황과는 맞지 않는다.

As-a-Service를 사용하면 기존보다 더 적은 비용이 든다고 생각하는 많은 기업들이 요금 청구서를 보고 놀라는 경우가 있다. 물론 CAPEX (초기 비용)가 전혀 들지 않지만, OPEX (운영비용)가 기존 CAPEX의 감가상각을 고려해도 너무 많이 발생하는 경우를 종종 본다. 이는 보통 초반에 As-a-Service를 도입할 때에 정확한 value에 대한 계산이 안되어있는 경우가 대부분이었다.

예를 들어서 위에 언급한 Database as-a-Service를 도입한다면, 현재 Database Software와 연관된 비용을 전체적으로 계산해서 비교해야한다. 현재 Database 소프트웨어의 라이센스 비용, 운영비용, 그리고 Database 전용 하드웨어 비용 등이 있을 수 있다. 운영비용을 제외한 나머지 비용은 계산하기 쉬우나, 운영비용은 단순 인건비로 치부할 수 있는 부분이 아니라는 것이 중요하다. 인건비 내에 한 사람이 운영 가능한 Database의 갯수도 포함해야한다. 왜냐하면 As-a-Service를 사용하게 되었을 때는 많은 수의 Database를 사용해도 운영인력은 기존과 같이 늘어나지 않기 때문이다. 즉 As-a-Service는 확장시에 들어가는 인건비가 상대적으로 적다. 단순 숫자 비교는 이렇게 할 수 있으며, 추가적으로 As-a-Service가 주는 value에 대한 계산도 필요하다. 예를 들어서 Active-Active 기능이나, compute의 탄력성 (elasticity)이 필요해서 서비스를 사용하는 것이라면, 해당 기능을 개발 혹은 구매, 그리고 운영 하기 위한 비용도 계산해서 포함하여야한다. 또한 network이나 데이터센터 비용 등 Database로 인해 주변에 발생하는 비용도 추가를 하게 되면 대략적으로 비교가 가능하게 된다. 1

위의 고려할 점들은 대표적으로 고려해야할 사항이며, 추가적으로 각 서비스 별로 더 자세한 고려사항들이 존재한다. 예를 들어 특정 application의 architecture로 serverless가 맞는 선택인지 아닌지와 같은 사항이다. 그러므로 각 상황에 맞게 추가적으로 고려해야할 사항들을 잘 살펴보아야 성공적인 As-a-Service 도입을 할 수 있을 것이라 생각한다.

  1. 5 Financial Benefits of Moving to the Cloud

    Related Posts

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

    3 Responses

    1. Pingback : Serverless Architecture 개념 및 장단점 - CloudInsight

    2. Pingback : Hybrid-Cloud 전략의 장단점 및 유의점 - 클라우드 인사이트

    Leave a Reply