극강의 클라우드 비용 최소화
Serverless 와 Cloud Native Architecture
https://brunch.co.kr/magazine/cloud-finops
클라우드 환경에서 비용을 관리하는 여러가지 방법들 중 비용을 최대로 줄일 수 있는 방법은 바로 클라우드를 클라우드 답게 사용하는 방법입니다. Cloud Native 라고 부를 수도 있고, Serverless 환경이라고 부를 수도 있을 것 같습니다. 물론, Cloud Native 와 Serverless 가 같은 용어는 아닙니다. ^^;;
클라우드를 처음 사용할 때는 많은 경우 이전에 IDC 나 자체 운영하는 서버실에 위치한 서버들에 있던 어플리케이션을 그대로 클라우드 환경으로 이전하면서 시작하는 경우가 많이 있습니다. 물리적인 On-prem Server에서 Cloud Service Provider 가 제공하는 Virtual Machine 로 Infrastructure 영역이 변경되었을 뿐, WAS, WEB, DATABASE 등을 포함하여 기존의 Application 영역은 이전 환경 그대로 운영을 하게 됩니다. 이런 Cloud Migration 방식을 Lift & Shift 방식이라고 합니다.
우선 AWS 에서 제공한 아래의 그림을 이해할 필요가 있습니다.
클라우드 비용 최적화 방법여기 주목해야 할 부분은 주황색 막대입니다.
주황색 막대는 녹색 막대를 클라우드로 이전 했을 때, 클라우드에서 발생하는 비용을 의미합니다. 그림에는 주황색 막대가 3개가 있습니다. 모두 동일한 서비스를 제공하는 것임에도 불구하고 비용이 가장 많은 것, 가장 많은 것의 절반 정도 되는 것, 그리고 불과 1/5 정도 되는 것, 이렇게 3가지 옵션이 있는 것 입니다.
어느 옵션을 선택할지는 사용자의 선택입니다. 물론, 개발 비용, 인력, 경험, 시간 등등 여러 요소를 고려해야 합니다. 중요한 것은 클라우드를 사용한다고 비용이 줄어드는 것이 아니라 비용이 줄어들 수 있게하는 전략과 운영이 필요하다는 것 입니다.
리프트 & 쉬프트 라는 것은 클라우드를 사용하지 않은 기존의 인프라 구성을 그대로 들어 올려서(Lift) 동일한 사양의 클라우드 인프라로 옮겨 놓은(Shift) 것을 의미합니다. 사용되는 서버의 숫자나 각 서버의 사양이 동일하기 때문에 비용이 크게 줄어들 수가 없습니다. 그림에서는 인프라 최적화를 위하여 인스턴스 크기 조정, 인스턴스 스케쥴링, 스토리지 최적화 3가지 방법을 제시하고 있습니다. 서버가 필요 이상의 사양을 가지고 있다면 사양을 줄이고, 가동하지 않아도 될 시간에는 중지시키고, 백업과 같은 보관용 데이터는 저렴한 스토리지로 옮겨 놓음으로써 비용을 상당히 줄일 수 있습니다. 아키텍처의 변경 없이도 이러한 과정을 통하여 대략적으로 10~30% 정도의 비용 절감을 기대할 수 있습니다. 또한 동일한 사양의 서버를 계속 사용하더라도 1년 혹은 3년간 사용을 약정하는 Reserved Instance 계약을 통하여 비용을 낮출 수 있고, 연속성이 보장되지는 않지만 On-demand 대비 약 80~90% 저렴한 비용으로 제공되는 Spot Instance 를 사용하여 비용을 낮출 수 있습니다.
좀 더 자세한 내용은 "클라우드 비용을 잡기 위한 첫 걸음(https://brunch.co.kr/@cebi750/4)" 이라는 글을 참조해 주시기 바랍니다. 그리고, 시간이 되는대로 실제적인 인프라 최적화 사례들을 소개해 보도록 하겠습니다.
이 글에서는 서버리스 아키텍처로 변경을 통한 비용 절감을 설명드리고자 합니다.
일단 서버리스가 무엇인지 설명드리겠습니다.
기존의 컴퓨팅 서버는 사용자가 CPU, Memory, Storage 의 성능과 용량을 결정하고, 그 기준에 의해서 비용이 발생하게 됩니다. 사용자가 서버의 동작을 중단시키지 않는 한 계속해서 그 기준으로 비용이 발생하게 됩니다. 이것이 의미하는 것은 실제 프로그램이 돌아갈 때 항상 CPU나 Memory 등의 자원을 100% 사용하지는 않지만, 우리가 설정한 기준에 대하여 100% 비용을 지불해야 한다는 것 입니다.
서버리스 컴퓨팅은 필요한 성능이나 용량을 사용자가 결정하지 않습니다. 사용자는 프로그램만 구현하면 클라우드 서비스 공급자가 알아서 서버의 성능과 용량을 결정해 주는 개념이 바로 서버리스 컴퓨팅입니다. 그리고, 비용은 당연히 프로그램이 실행된 시간만큼만 지급을 합니다. 내가 만든 프로그램이 CPU 8 Core가 필요했고, 메모리 128GB 만큼이 필요했으며, 10초 동안 실행이 되었으면, 딱 그 기준으로 비용이 발생하는 것 입니다. 만약에 동일한 프로그램에 사용자가 증가해서 오래동안 실행되거나 여러차례 실행되거나 혹은 동시에 여러 개가 같이 실행되면, 그만큼 실행시간과 실행횟수가 반영되서 비용이 계산되는 것 입니다.
이건 완전히 획기적인 방식입니다.
개발하는 입장에서는 예상 사용자가 얼마나 될지, 서버에서 운영될 프로그램의 크기가 얼마나 될지에 따라서 서버의 사이즈를 어느 정도로 잡을지 결정해야 하는데, 모든 사람들이 알듯이 그걸 맞추는 건 불가능한 일이고, 또한 사용자가 몰리거나 프로그램의 성능 요구치가 peak 를 칠 때 기준으로 서버의 사이징을 하기 때문에 대부분의 경우 서버의 CPU 와 Memory 는 항상 여유있게 놀고 있습니다. 서버 모니터링에 관심이 전혀 없는 분들도 노트북에서 컨트롤+알트+딜리트를 눌러서 윈도우 프로세스 탭을 보신 적이 있을 겁니다. 만약 CPU가 100% 가까운 사용량을 보이고 있다면, 그 노트북은 팬 돌아가는 소리와 발열과 모든 어플리케이션이 버벅거리는 난장판이 되어 있을 것 입니다. 서버는 당연히 PC에 비하여 24시간 쉬지않고 가동되더라도 안정적으로 운영되는 고가용성을 보장하는 설계가 되어 있고 CPU 100% 피크를 치더라도 차례로 실행이 되도록 설계되어 있지만, 그래도 항상 CPU와 Memory는 여유분을 고려해 설정을 하게 되고, 그 여유분 만큼 항상 비용이 지출되고 있는 것 입니다.
서버리스 컴퓨팅은 사용자가 개발한 프로그램을 실행하는데 필요한 메모리만 결정하면 모든 것이 자동으로 결정됩니다. 메모리 설정 하나만으로 프로그램이 동작하는데 필요한 CPU 등의 자원이 자동을 결정이 되는 것 입니다. 그리고 프로그램이 시작되어 종료될 때까지 실행 시간 동안만 비용이 부과됩니다. 사용자가 서버의 사양과 가동 시간에 대하여 신경 쓸 필요가 없이 모든 것이 자동으로 필요한 만큼 할당된다는 의미에서 서버리스하고 부르는 것 입니다.
개발자가 코드만 작성을 해서 배포하면 해당 프로그램이 실행되는데 필요한 모든 것이 자동으로 결정되어 생성되고 프로그램이 완료되면 자동으로 종료되니 편리할 뿐 아니라 소요되는 비용도 최소화 될 수 밖에 없는 것 입니다. AWS 의 람다의 경우에는 호출되는 횟수와 메모리 크기에 따라서 단가가 결정되고, 여기에 실행시간을 곱하여 비용이 계산됩니다.
복잡한 기술적인 내용들은 제외하고, 어느 정도의 비용 절감 효과가 발생하는지 제가 근무하는 베스핀글로벌 개발팀에서의 사례를 소개해 드려 보겠습니다.
저는 OpsNow 라는 Cloud Management Platform 을 운영하고 있습니다. 1,000 이상의 Enterprise와 Startup 고객들이 클라우드 비용을 관리하고 최적화하는 목적으로 사용하고 있는데, 이런 서비스들을 제공하기 위하여 OpsNow 에서는 AWS와 같은 CSP 에서 제공하는 비용과 리소스 정보를 수집하여 재가공하는 백엔드 데이터플랫폼을 가지고 있습니다. 초기에는 On-demand 서버 Cluster 에서 데이터 수집과 처리를 진행했습니다. 고객사가 증가하고, 데이터량이 급증함에 따라 데이터 수집과 처리에 소요되는 시간이 급증하였고, 이에 따라 서버 스케일 업과 대수 증설이 필요하게 되었고, 당연히 비용이 증가하게 되었습니다.
첫번째 예시는 데이터 처리 단계에서의 개선입니다.데이터 처리 시간을 단축시키면서 투입되는 비용도 잡기 위하여 SPARK EMR 에서 사용하는 인프라를 On-demand 에서 Spot Instance 로 변경을 진행하였습니다. Spot Instance 는 On-demand 의 약 10~20% 정도의 비용으로 사용이 가능합니다. On-demand m4.large 를 8배 사양이 높은 m4.4xlarge Spot Instance 를 생성하여 처리하는 구조로 변경을 하고, 거의 동일한 비용으로 데이터 처리 시간을 1/6 로 줄였습니다. 물론 개발팀의 계속적인 프로그램 성능 개선도 반영해야 하지만, 단순하게 보면 비용을 1/5 줄이거나, 소요 시간을 1/6 로 줄일 수 있게 된 것 입니다.
Spot Instance 는 SLA가 보장되지 않기 때문에 불안하다는 말을 많이 하십니다. 저희 개발팀이 2019년 10월 부터 Spot Instance 를 여러 워크로드에서 사용을 하고 있는데, 지금까지 한번도 실행 중에 Spot Instance 가 회수되거나 동작 오류가 발생하는 경우가 없었습니다. 심지어 특정 워크로드에서는 20주째 Spot Instance가 교체없이 계속 사용되고 있습니다. 아마도 AWS Seoul 리전에 Spot Instance를 사용하는 기업이 많지 않아서 그런가 하며, 저희 팀에서는 감사한 마음으로 말그대로 1/10 의 비용으로 On-demand 처럼 사용하고 있는 셈 입니다.
Spot Instance 를 SLA 를 보장받으면 사용하고 싶으시면, OpsNow 에서 제공하는 Autospot 기능의 사용하시면 됩니다. Autospot 은 Spot Instance 를 사용자의 워크 로드에 쉽게 사용할 수 있게 도와주고, Spot Instance 사용을 주저하게 만드는 이유인 Instance 돌연한 반납에 의해서 서비스가 중단되지 않도록 가용성을 보장해 주고 있습니다. Autospot은 비용 절감액 중 일부를 사용요금으로 청구하는 성공보수 방식의 계약 구조이기 때문에 고객의 입장에서는 사실 상 손해 볼 부분이 없습니다.
두번째 예시는 Cloud Native 한 사례입니다. 데이터 수집 단계를 Serverless 아키텍처로 완전히 변경하였습니다. 이전 수집 아키텍처에서는 Zoo Keeper, Ni-Fi 등의 오픈소스를 사용하는 On-demand EC2 Cluster를 운영했습니다. 이 부분을 Lambda 와 Step Functions 으로 변경하였고, t타입과 c타입의 On-dmand Server 6대에서 한달에 약 $500 정도 발생하던 비용이 $7 로 감소하였습니다. 이전 수집 아키텍처에서 사용하던 Ni-Fi 라는 오픈소스를 구동하기 위해 기본적으로 많은 서버자원이 요구되었던 부분도 있고, Ni-Fi 에서 젝공하던 Data Flow Modeling 과 Monitoring 이 새로 구현된 Lambda 에서는 제외된 부분들을 감안해야 하겠지만, 일단 On-demand 서버 아키텍처를 Serverless 아키텍처로 변경하였을 때 가져올 수 있는 엄청난 비용의 감소 효과는 분명히 보여주고 있는 사례가 되는 것 같습니다..
클라우드 비용을 관리할 수 있는 방법은 무궁무진합니다. 오늘은 그러한 방법 중 극강의 방법인 Serverless 아키텍처의 비용 절감 이유와 그 실제 사례를 소개해 보았습니다. 실행하는 입장에서는 아직 경험하지 못한 영역을 가야 한다는 것은 선택하기 매우 힘들고, 실패의 위험이 지뢰밭처럼 깔려 있는 the long and winding road 입니다. 하지만, 클라우드 비용을 잡는 길은 가지 않을 수 있는 길이 아니니 하루라도 빨리 본격적인 클라우드 비용관리 FinOps 를 시작하는 것을 권하고 싶습니다.
"Cloud 관리를 위한 FinOps" - 전체 내용 보기 (https://brunch.co.kr/@cebi750/17)
