AWS에서 효율적인 비용으로 시스템을 운영하기

How to handle the cost of AWS when your system is dramatically growing up.

AWS에서 비용을 줄이는 포스팅은 많습니다. 이것저것 줄이고 바꿔서 비용을 효율적으로 사용하는 것이 대부분의 문맥입니다. 하지만 실제로 운영하면서 엔지니어들이 항상 염두에 둘 사항들에 대해서 이야기하는 포스팅을 보지 못했습니다. 그래서 서비스와 시스템이 빠르게 성장함에 따라 시스템 비용을 어떻게 운용해야 하는지 알아보고자 합니다.

 

클라우드 시스템을 운영하는 마음가짐 - You should change your mindset from IDC to Cloud on operating & planning Systems.

비용 절감 이야기에서 갑자기 마음가짐을 바꾸라는 말이냐 라고 생각하실 수 있습니다. 그런데 무엇을 하든지간에 사물을 바라보는 관점과 마음가짐이 바껴야 혁신을 할 수 있습니다. 제가 여러 엔지니어들과 AWS 리소스에 대해서 플래닝을 하다보면 이전에 IDC에서 서버를 운영하듯이 초반에 서버의 스펙을 고사양, 고용량으로 설정하고 유지하려는 모습을 자주 봤습니다. 이것은 클라우드가 가지고 있는 장치의 유연함의 1%도 활용하지 못하는 것입니다. 시스템 초기에 트래픽이 낮을때는 저사양의 인스턴스를 사용하다가 트래픽이 올라가기 시작하면 Scale-out으로 대응해야 합니다. 고사양이 필요한 것은 기능 추가로 인해 진짜 컴퓨팅 파워가 필요할때만 Scale-up을 해야 합니다. 처음부터 고사양의 인스턴스를 사용하는 것은 엄청난 비용 낭비를 초래하는 것입니다.

 

올바른 EBS 사용 법 - The EBS volume should be scaled up step by step.

원.래.부.터. EBS는 인스턴스를 정지하지 않고도 용량을 마음껏(?) 늘릴 수 있습니다. 하지만 용량 축소는 불가합니다. 이미 다들 아시리라 생각합니다. 그런데 대부분의 비용 낭비는 EBS에서 발생합니다. 왜일까요? 그것은 위에서 언급했던 것처럼 리소스를 플래닝할때 몇개월 후에 생길 예측량을 산정해서 EBS를 세팅하기 때문입니다. 가령 파일 서버를 세팅한다고 했을때 3개월뒤에 1TB정도를 예상하고 첫 세팅에서 EBS를 1TB로 설정하는 경우가 많습니다. EBS 1TB의 가격은 계산기에서 직접 계산해보시면 얼마나 비싼지 알 수 있습니다. 이런 경우는 초반에 작게 세팅하고 사용량에 따라 점진적으로 늘려야 합니다. 그래야 새는 돈을 막을 수 있습니다.

 

EC2 (Auto) Scale Out의 올바른 사용법 - The Scale-Out of EC2 makes by small Instances.

성장하는 시스템은 사용자가 몰리는 시간대의 트래픽을 감당하기 위해 Auto Scale-out을 설정합니다. 아주 행복한 상황입니다. 그런데 우리는 여기서 하나의 비용 낭비를 포착할 수 있습니다. 바로 스케일 아웃을 하는 인스턴스의 제품과 개수입니다. AWS의 모든 EC2 인스턴스의 스펙과 가격은 정확하게 2배씩 커지도록 책정되어 있습니다. 예를 들면 M5.large는 vCPU가 2개이고 메모리는 8기가이고, M5.xlarge는 vCPU가 4개이고 메모리는 16기가입니다. 가격도 정확하게 2배 차이입니다. 이렇다는 이야기는 오토 스케일링을 할때 늘어나는 트래픽의 기울기와 스케일링 장비의 수용치(Capacity)에 따라 불필요한 버퍼의 비용이 발생합니다. 그래서 어플리케이션이 구동하는 최소 단위로 인스턴스의 개수를 조정해서 허용할 버퍼의 오차 범위내로 Scale-out을 할 수 있습니다. 예를 들면, 오토 스케일링을 xlarge 5대로 점진적으로 추가하는 것보다 large 9대로 점진적으로 늘려서 동일한 트래픽을 처리하고 비용을 효율적으로 사용하는 것입니다. 그렇게 해서 얼마나 줄일 수 있겠느냐고 말씀하실 분들도 계시겠지만, 인스턴스를 몇천대 몇만대 단위로 운용하는 회사들이 이를 통해 절감할 수 있는 비용은 생각보다 아주 큽니다.

 

S3는 한시적인 보관 장소입니다. - S3 has the TTL on every object

Front-end에서 사용하는 리소스(이미지, JS등)는 CDN 서비스를 이용합니다. 그런데 CDN을 사용하지 못하는 보안(?) 등급이 높은 리소스들 또는 내부 파일들은 S3에 저장을 합니다. 그런데 S3의 비용도 무시하지 못할 정도로 비싸기 때문에 각 파일(Object)별로 TTL 설정을 해서 자동으로 Truncate 될 수 있도록 해야 합니다. TTL을 설정할 수 없는 영구보관 파일은 Glacier 서비스를 통해서 아카이빙 서비스를 받으면 효율적인 비용으로 운용할 수 있습니다.

 

Conclusion

위의 4가지는 어쩌면 너무 당연한 이야기일 수 있습니다. 한 조직의 전체 시스템 비용을 3년동안 담당해오면서 많은 엔지니어들이 이런 내용들을 놓치는 경우를 많이 목격할 수 있었습니다. 어떤 분들은 회사의 성장과 비즈니스 속도를 맞추기 위해 어느정도 비효율은 감수할 수 있다고 하실 수 있습니다. 하지만 그 비용이 회사의 성장과 함께 장시간 누적이 된다면, 어느 시점에서 비즈니스의 속도를 늦추고 AWS 비용을 줄이는 프로젝트를 수행할 수도 있습니다. 이제 클라우드 시대가 열리면서 개발자도 시스템 운영과 비용까지 관리해야하는 DevOps의 시대가 왔습니다. AWS 비용을 줄이는 몇가지 팁을 소개했습니다만, 정말 중요한 것은 인스턴스에서 구동하는 응용 프로그램이 얼마나 컴팩트하고 시스템 자원을 효율적으로 사용해서 큰 사이즈의 인스턴스를 사용하지 않도록 하는 것입니다. 

 

Thanks

Hans