들어가며
회사의 이익을 늘리는 방법은 비싸게 팔기, 더 많이 팔기, 비용 줄이기의 세 가지가 있다고 한다. 데브옵스 엔지니어는 앞의 두 가지 방식으로는 회사에 기여하기는 어려우나, 비용을 줄이는 데는 누구보다 전문가라고 할 수 있다. 물론 구조조정과 정리해고라는 더 강력한 필살기가 있긴 하지만 이런 어두운 얘기는 하지 말도록 하자.
EC2는 아마도 AWS에서 가장 많이 사용되는 리소스일 것이다. 따라서 클라우드 비용을 절감하려면 EC2 사용 실태부터 점검하는 것이 좋다. 이번 포스팅에선 내가 직접 겪었던 시행착오를 위주로 인스턴스 비용을 줄일 수 있는 방법을 설명한다.
EC2 사용 전 한 번 더 생각하기
어플리케이션 배포를 위해 VM부터 할당하고 보는 엔지니어는 게으른 사람이다. EC2가 최적의 배포 방법이 아닌 경우가 많기 때문이다. 대표적인 예로 어플리케이션의 실질적 실행 시간이 짧은 경우를 들 수 있다. 예를 들어 매일 자정에 한 번씩 실행되는 배치잡이 있다고 생각해보자. 실행 시간은 5분 정도이다. 흔하게 생각할 수 있는 방식은 리눅스 EC2를 임대하고 크론탭을 설정하는 것이다. 그러나 하루에 5분 실행하는 어플리케이션을 위해 인스턴스를 24시간 임대해 둘 필요가 있을까? 이벤트 브릿지와 람다를 사용하는 방법이 훨씬 저렴하다.
서울 리전 기준으로 직접 계산해보자. x86 vCPU 2개와 메모리 4GiB를 갖춘 t3.medium을 임대하려면 시간당 0.052 USD를 지불해야 한다. 한 달 내내 임대하면 38.68 USD가 나오는데, 작성일 기준 한화 5만원이 넘는 돈이다. 반면 메모리 4GiB를 부여받은 Lambda는 밀리초당 0.0000000667 USD를 지불해야 한다. 하루에 5분씩 31일을 실행한다면 약 0.62 USD가 부과된다. 작성일 기준 한화 800원 정도의 돈이다.
사용하지 않는 리소스는 예외없이 삭제하기
테스트나 개발 환경에서 리소스를 자유롭게 생성할 수 있도록 허용하는 회사들이 간혹 있다. 생산성 증대에 효과가 있긴 하지만, 정책을 도입하기 전 반드시 사용하지 않는 리소스를 삭제하는 작업을 자동화 해야 한다. 자동화 해놓지 않으면 번번이 점검하는 시간이 낭비될 뿐더러 '혹시나 사용할 일이 있을지도 모른다.'라고 생각하는 동료의 저항 때문에 작업이 어려워진다. 이런 동료는 '아빠 안 잔다' 라고 주장하며 리모콘을 내놓지 않는 아버지와 같다. 이런 말을 믿었다가는 밤새 리모콘을 잡을 수 없게 된다. 적당한 규칙을 정해 예외없이 삭제해버리는 것이 좋다. aws는 파이썬, golang 등 다양한 언어로 sdk를 제공하고 있으므로 어렵지 않게 자동화 할 수 있다.
인스턴스 타입 선정 신중하게 선택하기
자기가 아는 몇 가지 타입에 한정해 인스턴스를 할당하는 사람들이 있다. 그러나 생각없이 한 결정이 인프라 비용을 크게 증가시킬 수 있다. 예를 들어 현재는 서울 리전에서 EC2를 생성할 때, 기본 타입이 t2.small 로 지정되어 있다. t2.small의 사양은 1vCPU에 2GiB의 메모리인데, 어플리케이션을 운영하기 위해선 최소 2vCPU와 8GiB가 필요하다고 가정해보자. t2 시리즈에 동일한 사양을 가진 t2.large 가 있다. 이 타입을 선택하면 되는 것일까? 그렇지 않다. 초당 부동소수점 연산량(FLOPS) 기준으로 성능이 두 배 좋고 가격은 10퍼센트 가량 저렴한 t3 타입이 있기 때문이다. 디폴트 값이라는 이유만으로 t2를 선택했다가는 엄청난 손해를 보게된다.
냅다 t3를 고르는 것도 정답이 아니다. t2와 t3는 모두 버스트 가능(burstable) 유형이라는 공통점이 있다. 이 유형의 인스턴스는 CPU의 부하량이 불규칙한 어플리케이션을 위해 설계 되었다. (예를 들어 쇼핑몰과 같은 어플리케이션은 평이한 수준의 트래픽을 유지하다가 할인과 같은 이벤트가 생길 때 연산량이 폭증하는 특성이 있다.) 버스트 가능 인스턴스는 CPU의 부하가 낮을 때에는 크레딧을 저축해놓았다가, 부하가 높을 때만 모아놓은 크레딧을 소모해 높은 성능을 발휘한다. 반면 CPU 부하가 계속 높은 어플리케이션이라면 금방 크레딧을 소모해버릴 것이다. 크레딧 소모의 결과는 설정에 따라 다른데, CPU 성능이 갑자기 낮아지거나 추가 요금이 지불된다. 어느 쪽이나 바람직하지 않은 결과이다. 버스트 가능 타입은 어플리케이션이 해당 기능을 통해 비용 이득을 볼 수 있는지 충분히 고려한 후 선택해야 한다.
그렇다고 모든 인스턴스 타입을 암기할 필요는 없다. 배포하려는 어플리케이션의 특성을 잘 이해하는 것이 선행 작업이다. 어플리케이션 CPU와 메모리, 디스크 IO, 네트워크 IO중 어떤 리소스를 가장 많이 필요로 하는지, 부하가 일정한지 불규칙한지 등의 요구사항을 파악하고 적절한 인스턴스 타입을 검색하자.
스케일 다운
인스턴스의 리소스는 일단 넉넉하게 주고 보는 것이 보편적인 심리이다. 리소스 부족은 서비스 장애를 유발하지만, 과잉은 비용을 더 지출하는 선에서 끝나기 때문이다. 그러나 장애가 겁난다고 해서 높은 인프라 비용을 계속 지출할 수는 없는 노릇이다. 현재 할당한 리소스가 과도하다는 확신이 든다면 과감하게 스케일 다운을 해야 한다. 기계는 사람과 달리 인권이 없으므로 최대한 쥐어짜도 된다.
예약 인스턴스 활용
'예약 인스턴스'란 1년이나 3년치의 비용을 선지불하고 할인을 받는 방식이다. 3년 예약을 하면 온디맨드 방식으로 사용할때보다 최대 72퍼센트 가량 저렴해진다고 한다. 장기 사용할 것이 명백한 운영용 인스턴스일때 활용하면 좋은 제도이지만, 원칙적으로 환불이 불가능하므로 신중하게 결정하도록 하자.
arm 아키텍처 사용
앞서 t2 대신 t3를 사용하자는 내용을 썼다. 그런데 x86 아키텍처를 고집할 생각이 없다면 더욱 좋은 선택지인 t4g가 있다. t4g는 t3에 비해 컴퓨팅 성능이 40% 뛰어나고 가격은 20% 저렴하다.t4g 뿐만 아니라 ARM 인스턴스는 대체로 동급의 x86 인스턴스 보다 가성비가 뛰어나다. 운영 환경에 ARM 아키텍처를 쓰기 꺼려하는 개발자나 엔지니어들이 많은데 대부분은 그럴 필요가 없다. 일반적인 어플리케이션에서 CPU 아키텍처에 의존성이 생길 일은 거의 없기 때문이다. 내가 재직중인 와탭도 운영 환경에 ARM 인스턴스를 적극적으로 사용하고 있다.
참고 자료
잘 읽었습니다