규모에 따른 효율성: AWS 비용 최적화 이야기

게시 됨: 2022-07-22

저는 최근에 암호화폐 분석 플랫폼을 출시하여 적은 수의 일일 사용자를 기대하고 있습니다. 그러나 일부 유명 유튜버들이 이 사이트가 도움이 되었다고 평가하고 리뷰를 게시하자 트래픽이 너무 빠르게 증가하여 서버에 과부하가 걸리고 플랫폼(Scalper.AI)에 액세스할 수 없게 되었습니다. 원래 AWS EC2 환경에는 추가 지원이 필요했습니다. 여러 솔루션을 고려한 후 AWS Elastic Beanstalk를 사용하여 애플리케이션을 확장하기로 결정했습니다. 상황이 좋아보이고 원활하게 실행되고 있지만 청구 대시보드의 비용에 놀랐습니다.

이것은 드문 문제가 아닙니다. 2021년 설문 조사에 따르면 IT 및 클라우드 의사 결정자의 82%가 불필요한 클라우드 비용에 직면했으며 86%는 모든 클라우드 지출을 종합적으로 볼 수 없다고 생각합니다. Amazon은 문서에서 추가 비용에 대한 자세한 개요를 제공하지만 가격 모델은 성장하는 프로젝트에 대해 복잡합니다. 이해를 돕기 위해 몇 가지 관련 최적화를 분석하여 클라우드 비용을 절감하겠습니다.

AWS를 선택한 이유

Scalper.AI의 목표는 암호화폐 쌍(거래소에서 거래할 때 교환되는 자산)에 대한 정보를 수집하고, 통계 분석을 실행하고, 암호화폐 거래자에게 시장 상태에 대한 통찰력을 제공하는 것입니다. 플랫폼의 기술 구조는 세 부분으로 구성됩니다.

데이터 수집 스크립트
웹 서버
데이터베이스

수집 스크립트는 다양한 소스에서 데이터를 수집하여 데이터베이스에 로드합니다. AWS 서비스를 사용한 경험이 있으므로 EC2 인스턴스를 설정하여 이러한 스크립트를 배포하기로 결정했습니다. EC2는 다양한 인스턴스 유형을 제공하며 인스턴스의 프로세서, 스토리지, 네트워크 및 운영 체제를 선택할 수 있습니다.

나머지 기능은 원활한 애플리케이션 관리를 약속하는 Elastic Beanstalk를 선택했습니다. 로드 밸런서는 내 서버의 인스턴스 간에 부담을 적절하게 분산시켰고, 자동 확장 기능은 증가된 로드에 대한 새 인스턴스 추가를 처리했습니다. 몇 분 만에 업데이트 배포가 매우 쉬워졌습니다.

Scalper.AI는 안정적으로 작동했고 사용자는 더 이상 다운타임에 직면하지 않았습니다. 물론 부가 서비스를 추가해서 지출이 늘어날 거라 예상했지만, 예상보다 훨씬 많았다.

클라우드 비용을 절감할 수 있었던 방법

돌이켜보면 내 프로젝트에서 AWS 서비스를 사용하는 데 복잡한 영역이 많이 있었습니다. 버스트 가능한 성능 인스턴스, 아웃바운드 데이터 전송, 탄력적 IP 주소, 종료 및 중지 상태와 같은 일반적인 AWS EC2 기능으로 작업하는 동안 발견한 예산 최적화를 살펴보겠습니다.

버스트 가능한 성능 인스턴스

저의 첫 번째 과제는 성장하는 프로젝트의 CPU 전력 소비를 지원하는 것이었습니다. Scalper.AI의 데이터 수집 스크립트는 사용자에게 실시간 정보 분석을 제공합니다. 스크립트는 몇 초마다 실행되고 플랫폼에 암호화 교환의 최신 업데이트를 제공합니다. 이 프로세스를 반복할 때마다 수백 개의 비동기 작업이 생성되므로 사이트의 트래픽 증가로 인해 처리 시간을 줄이기 위해 더 많은 CPU 성능이 필요했습니다.

4개의 vCPU가 있는 AWS에서 제공하는 가장 저렴한 인스턴스인 a1.xlarge는 당시 월 75달러 정도였습니다. 대신 vCPU 2개와 각각 1GB RAM이 있는 2개의 t3.micro 인스턴스 간에 부하를 분산하기로 결정했습니다. t3.micro 인스턴스는 a1.xlarge 비용의 1/5로 필요한 작업에 충분한 속도와 메모리를 제공했습니다. 그럼에도 불구하고 내 청구서는 월말에 예상했던 것보다 여전히 많습니다.

이유를 이해하기 위해 Amazon 설명서를 검색하여 답을 찾았습니다. 인스턴스의 CPU 사용량이 정의된 기준 이하로 떨어지면 크레딧을 수집하지만 인스턴스가 기준 사용량을 초과하면 이전에 획득한 크레딧을 소모합니다. 사용 가능한 크레딧이 없는 경우 인스턴스는 Amazon에서 제공하는 "잉여 크레딧"을 사용합니다. 크레딧을 획득하고 사용할 수 있는 이 기능으로 인해 Amazon EC2는 24시간 동안 인스턴스의 CPU 사용량을 평균화합니다. 평균 사용량이 기준을 초과하면 vCPU 시간당 고정 요금으로 인스턴스에 추가로 청구됩니다.

며칠 동안 데이터 수집 인스턴스를 모니터링한 결과 비용을 절감하기 위한 CPU 설정이 반대임을 발견했습니다. 대부분의 경우 평균 CPU 사용량이 기준선보다 높았습니다.

차트에는 화면 상단에서 세 개의 드롭다운 선택 항목이 선택되어 있습니다. 왼쪽의 처음 두 개는 "2022년 2월 10일 - 2022년 2월 19일"과 "매일"이고 그 뒤에 작은 동그라미로 표시된 "i"가 표시됩니다. 세 번째는 화면 오른쪽에 있으며 선 그래프 기호와 함께 "선"이라고 표시됩니다. 드롭다운 선택 항목 아래에 필터가 있는 두 개의 선 그래프가 차트에 포함되어 있습니다. 맨 위에 있는 필터 행에는 "그룹화 기준: 사용 유형"(선택한 필터, 파란색 배경)이 표시된 다음 선택되지 않은 필터인 "서비스, 연결된 계정, 지역, 인스턴스 유형, 리소스, 비용 범주, 태그"가 표시됩니다. , 더보기', "리소스"가 회색으로 표시되고 마지막 세 개 옆에 드롭다운 화살표가 있습니다. 맨 위 선 그래프의 y축에는 0.0에서 2.5 사이의 "비용($)"이 있습니다. 맨 아래 선 그래프의 y축에는 0에서 40 사이의 "사용(vCPU-시간)"이 있습니다. 두 선 그래프는 2월 10일부터 2월 19일까지 x축에 레이블이 지정된 날짜와 키를 공유합니다. 보라색 라인 레이블: "USE2-CPUCredits:t3." 위쪽 선 그래프에는 선형으로 연결된 약 8개의 점이 있으며 시간이 지남에 따라 위쪽으로 추세를 나타냅니다. 4차(2월-14일, $2.1), 5차(2월-15일, $2.4), 6차(2월-16일, $2.3), 7차(2월-18일, $2.3), 8차(2월-18일, $2.3) 19, $2.6). 하단 라인 그래프에는 선형으로 연결된 약 8개의 점이 있으며 시간이 지남에 따라 위쪽으로 추세를 나타냅니다. -12, 10 vCPU-Hours), 4차(2월 14일, 40 vCPU-Hours), 5차(2월 15일, 50 vCPU-Hours), 6차(2월 16일, 45 vCPU-Hours) , 일곱 번째 경(2월 18일, 45 vCPU-시간) 및 여덟 번째 경(2월-19일, 55 vCPU-시간)입니다. — 위의 차트는 CPU 사용량이 기준선을 초과한 기간 동안 비용 급증(위쪽 그래프)과 CPU 크레딧 사용량 증가(아래쪽 그래프)를 표시합니다. 인스턴스는 vCPU 시간당 청구되므로 달러 비용은 소비된 잉여 크레딧에 비례합니다.

나는 처음에 몇 가지 암호화 쌍에 대한 CPU 사용량을 분석했습니다. 부하가 적었기 때문에 성장의 여지가 충분하다고 생각했습니다. (나는 더 적은 수의 암호화 쌍이 CPU 성능을 많이 요구하지 않았기 때문에 데이터 수집을 위해 단 하나의 마이크로 인스턴스를 사용했습니다.) 하지만, 통찰력을 더 포괄적으로 만들고 데이터 수집을 지원하기로 결정하자 원래 분석의 한계를 깨달았습니다. 수백 개의 암호화 쌍에 대해 클라우드 서비스 분석은 올바른 규모로 수행되지 않는 한 아무 의미가 없습니다.

아웃바운드 데이터 전송

내 사이트 확장의 또 다른 결과는 작은 버그로 인해 내 앱에서 데이터 전송이 증가한 것입니다. 트래픽이 꾸준히 증가하고 다운타임이 없어짐에 따라 가능한 한 빨리 사용자의 관심을 사로잡을 수 있는 기능을 추가해야 했습니다. 내 최신 업데이트는 암호화 쌍의 시장 조건이 사용자의 사전 정의된 매개변수와 일치할 때 발생하는 오디오 경고였습니다. 불행히도 코드에서 실수를 했고 오디오 파일이 사용자의 브라우저에 몇 초마다 수백 번 로드되었습니다.

그 영향은 컸다. 내 버그로 인해 내 웹 서버에서 오디오 다운로드가 생성되어 추가 아웃바운드 데이터 전송이 발생했습니다. 내 코드의 작은 오류로 인해 청구서가 이전 청구서보다 거의 5배나 커졌습니다. (이것이 유일한 결과는 아닙니다. 버그로 인해 사용자 컴퓨터의 메모리 누수가 발생할 수 있어 많은 사용자가 다시 방문하지 않았습니다.)

이전 차트와 유사하지만 첫 번째 드롭다운이 "2022년 1월 6일 - 2022년 1월 15일"이고 상단 선 그래프의 "비용($)" 범위는 0에서 30이고 하단 선 그래프는 " 사용량(GB)"은 0에서 300까지 y축에 표시됩니다. 두 선 그래프는 x축에 1월 6일부터 1월 15일까지 레이블이 지정된 날짜와 보라색 라인에 "USE2- DataTransfer-Out-Bytes." 상단 선 그래프에는 선형으로 연결된 약 8개의 점이 있으며 시간이 지남에 따라 위쪽으로 추세를 나타냅니다. 4차(1월-10일, $6), 5차(1월-12일, $15), 6차(1월-13일, $25), 7차(1월-14일, $24), 8차(1월-14일, $24) 15, $29). 하단 라인 그래프에는 선형으로 연결된 약 8개의 포인트가 있으며 시간이 지남에 따라 위쪽으로 추세를 나타냅니다. GB), 4차 경(1월-10일, 70GB), 5차 경(1월-12일, 160GB), 6차 경(1월-13일, 270GB), 7차 경(1월-14일, 260GB) , 여덟 번째 경(1월 15일, 320GB). — 위의 차트는 비용 급증(상단 그래프)과 증가하는 아웃바운드 데이터 전송(하단 그래프)을 보여줍니다. 아웃바운드 데이터 전송은 GB당 청구되므로 달러 비용은 아웃바운드 데이터 사용량에 비례합니다.

데이터 전송 비용은 AWS 가격 급등의 30% 이상을 차지할 수 있습니다. EC2 인바운드 전송은 무료이지만 아웃바운드 전송 요금은 GB당 청구됩니다(Scalper.AI를 구축할 때 GB당 $0.09). 어려운 방법을 배웠기 때문에 아웃바운드 데이터에 영향을 미치는 코드에 주의하는 것이 중요합니다. 가능한 경우 다운로드 또는 파일 로드를 줄이면(또는 이러한 영역을 주의 깊게 모니터링하면) 더 높은 수수료로부터 보호할 수 있습니다. EC2에서 인터넷으로 데이터를 전송하는 비용은 워크로드 및 AWS 리전별 요금에 따라 달라지므로 이러한 비용은 빠르게 추가됩니다. 많은 신규 AWS 고객에게 알려지지 않은 마지막 주의 사항: 데이터 전송은 서로 다른 위치 간에 더 비쌉니다. 그러나 사설 IP 주소를 사용하면 동일한 지역의 서로 다른 가용 영역 간의 추가 데이터 전송 비용을 방지할 수 있습니다.

탄력적 IP 주소

탄력적 IP 주소(EIP)와 같은 공용 주소를 사용하는 경우에도 EC2 비용을 낮출 수 있습니다. EIP는 동적 클라우드 컴퓨팅에 사용되는 고정 IPv4 주소입니다. "탄력적" 부분은 EIP를 모든 EC2 인스턴스에 할당하고 중지할 때까지 사용할 수 있음을 의미합니다. 이러한 주소를 사용하면 주소를 계정의 다른 인스턴스에 다시 매핑하여 비정상 인스턴스를 정상 인스턴스와 원활하게 교환할 수 있습니다. EIP를 사용하여 EC2 인스턴스를 가리키도록 도메인에 대한 DNS 레코드를 지정할 수도 있습니다.

AWS는 리전당 계정당 5개의 EIP만 제공하므로 리소스가 제한되고 비효율적인 사용으로 비용이 많이 듭니다. AWS는 각 추가 EIP에 대해 낮은 시간당 요금을 부과하고 한 달에 100회 이상 EIP를 다시 매핑하는 경우 추가 요금을 청구합니다. 이 한도 이하로 유지하면 비용이 절감됩니다.

종료 및 중지 상태

AWS는 실행 중인 EC2 인스턴스의 상태를 관리하기 위한 두 가지 옵션인 종료 또는 중지를 제공합니다. 종료하면 인스턴스가 종료되고 이에 대해 프로비저닝된 가상 머신을 더 이상 사용할 수 없습니다. 연결된 모든 EBS(Elastic Block Store) 볼륨이 분리 및 삭제되고 인스턴스에 로컬로 저장된 모든 데이터가 손실됩니다. 더 이상 인스턴스 비용이 청구되지 않습니다.

인스턴스를 중지하는 것도 비슷하지만 한 가지 작은 차이점이 있습니다. 연결된 EBS 볼륨은 삭제되지 않으므로 데이터가 보존되며 언제든지 인스턴스를 다시 시작할 수 있습니다. 두 경우 모두 Amazon은 더 이상 인스턴스 사용에 대해 요금을 부과하지 않지만 종료 대신 중지를 선택하면 EBS 볼륨이 존재하는 한 비용이 발생합니다. AWS는 곧 다시 활성화할 것으로 예상되는 경우에만 인스턴스를 중지할 것을 권장합니다.

그러나 인스턴스를 중지하지 않고 종료하더라도 월말에 AWS 청구서를 늘릴 수 있는 기능이 있습니다. 바로 EBS 스냅샷입니다. 이는 Amazon의 Simple Storage Service(S3)에 저장된 EBS 볼륨의 증분 백업입니다. 각 스냅샷에는 이전 데이터로 새 EBS 볼륨을 생성하는 데 필요한 정보가 들어 있습니다. 인스턴스를 종료하면 연결된 EBS 볼륨이 자동으로 삭제되지만 해당 스냅샷은 유지됩니다. S3는 저장된 데이터의 양에 따라 요금을 부과하므로 이러한 스냅샷을 곧 사용하지 않을 경우 삭제하는 것이 좋습니다. AWS는 CloudWatch 서비스를 사용하여 볼륨별 스토리지 활동을 모니터링하는 기능을 제공합니다.

AWS 콘솔에 로그인한 상태에서 왼쪽 상단의 서비스 메뉴에서 CloudWatch 서비스를 찾아 엽니다.
페이지 왼쪽의 메트릭 축소 가능 메뉴에서 모든 메트릭 을 클릭합니다.
이 페이지에는 EBS, EC2, S3 등을 포함하여 사용 가능한 지표가 있는 서비스 목록이 표시됩니다. EBS 를 클릭한 다음 볼륨별 지표 를 클릭합니다. (참고: EBS 옵션은 계정에 EBS 볼륨이 구성된 경우에만 표시됩니다.)
쿼리 탭을 클릭합니다. 편집기 보기에서 SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId 명령을 복사하여 붙여넣고 실행 을 클릭합니다. (참고: CloudWatch는 고유한 구문이 있는 SQL 언어를 사용합니다.)

페이지 상단에 진한 파란색 헤더 메뉴가 있는 웹 페이지가 나타납니다. 이 메뉴에는 왼쪽에서 오른쪽으로 aws 로고, "서비스" 드롭다운, 검색 표시줄, 코드 아이콘, 종 모양 아이콘, 물음표 아이콘, "N. Virginia"라는 드롭다운 텍스트와 "Toptal Test Account"라는 드롭다운 텍스트가 있습니다. 그 아래에 웹 페이지의 주요 부분이 흰색으로 표시됩니다. 페이지 왼쪽에는 제목이 "CloudWatch"이고 "X"인 스크롤 메뉴가 있습니다. 메뉴 아래에는 위에서 아래로 "즐겨찾기 및 최근", "대시보드", "알람"(굵게 표시됨, "알람 중", "모든 알람" 및 "청구"의 세 가지 드롭다운 포함), "Logs"(굵게 표시, 두 개의 드롭다운: "Log groups" 및 "Log Insights" 포함), "Metrics"(굵게 표시, 세 개의 드롭다운 포함: "All metrics", 밝은 주황색으로 강조 표시됨), " Explorer" 및 "Streams"), "X-Ray 추적"(굵게), "이벤트"(굵게) 및 "애플리케이션 모니터링"(굵게). 메뉴의 모든 굵게 표시된 텍스트에는 텍스트 왼쪽에 드롭다운 메뉴 삼각형이 있습니다. 웹 페이지 중간에는 페이지 상단에 그래프가 표시되고 페이지 하단에 편집기가 표시됩니다. 그래프에는 두 줄의 헤더가 있습니다. 첫 번째 줄은 왼쪽에 "CloudWatch > Metrics"(파란색으로 "CloudWatch" 텍스트), 오른쪽에 파란색으로 "Switch to your original interface"를 읽습니다. 두 번째 줄에는 왼쪽에 편집 아이콘이 있는 "제목 없는 그래프"가 표시되고 오른쪽에 "1h, 3h, 12h, 1d, 3d, 1w, Custom" 옵션이 표시됩니다(파란색은 "3h", 파란색은 "Custom"). 캘린더 아이콘 있음), "라인"(드롭다운 아이콘 있음), "작업"(드롭다운 아이콘 있음) 및 드롭다운 아이콘이 있는 새로 고침 버튼. 그래프 자체의 중앙에는 "CloudWatch 그래프가 비어 있습니다. 여기에 표시할 지표를 선택하십시오."라는 텍스트가 있습니다. 편집기에는 두 줄의 헤더도 있습니다. 첫 번째 줄에는 왼쪽에 "찾아보기", "쿼리"(주황색으로 강조 표시됨), "그래프로 표시된 측정항목", "옵션" 및 "소스"가 표시되고 "수학 추가"(드롭다운 아이콘 포함) 및 "추가 쿼리"(드롭다운 아이콘 포함)를 오른쪽에 표시합니다. 두 번째 줄은 왼쪽에 "Metrics Insights - 쿼리 편집기" 및 "Info"(파란색), 오른쪽에 "Builder" 및 "Editor"("Editor"가 선택된 상태)로 표시됩니다. 편집기 아래 왼쪽에는 주황색 "실행" 버튼이 있고 오른쪽에는 "Ctrl + Enter를 사용하여 쿼리를 실행하고 Ctrl + Space를 사용하여 자동 완성"이라는 텍스트가 있습니다. 웹 페이지의 오른쪽에는 흰색 메뉴가 있으며 위에서 아래로 "쿼리" 및 "도움말"을 읽습니다. — 위에서 설명한 CloudWatch 모니터링 설정의 개요입니다(빈 데이터와 선택된 지표가 없는 상태로 표시됨). 계정에 기존 EBS, EC2 또는 S3 인스턴스가 있는 경우 지표 옵션으로 표시되고 CloudWatch 그래프를 채웁니다.

CloudWatch는 파이 차트, 선, 막대, 누적 영역 차트 및 숫자와 같은 스토리지 활동을 분석하기 위한 다양한 시각화 형식을 제공합니다. CloudWatch를 사용하여 비활성 EBS 볼륨 및 스냅샷을 식별하는 것은 클라우드 비용을 최적화하기 위한 쉬운 단계입니다.

주머니에 여분의 돈

CloudWatch와 같은 AWS 도구는 클라우드 비용 모니터링을 위한 적절한 솔루션을 제공하지만 보다 포괄적인 분석을 위해 다양한 외부 플랫폼이 AWS와 통합됩니다. 예를 들어 VMWare의 CloudHealth와 같은 클라우드 관리 플랫폼은 추세 분석, 이상 감지, 비용 및 성능 모니터링에 사용할 수 있는 상위 지출 영역에 대한 자세한 분석을 보여줍니다. 또한 요금이 과도해지기 전에 급증을 감지하도록 CloudWatch 결제 경보를 설정하는 것이 좋습니다.

Amazon은 서버, 데이터베이스 및 하드웨어의 유지 관리 작업을 AWS 팀에 위임하는 데 도움이 되는 많은 훌륭한 클라우드 서비스를 제공합니다. 버그나 사용자 오류로 인해 클라우드 플랫폼 비용이 쉽게 증가할 수 있지만 AWS 모니터링 도구는 개발자가 추가 비용으로부터 스스로를 방어할 수 있는 지식을 제공합니다.

이러한 비용 최적화를 염두에 두고 프로젝트를 시작하고 그 과정에서 수백 달러를 절약할 준비가 된 것입니다.

"PARTNER"라는 단어와 그 아래에 "Advanced Tier Services"라는 텍스트가 있는 AWS 로고. — Amazon 파트너 네트워크(APN)의 고급 컨설팅 파트너인 Toptal은 기업이 전 세계 어디에서나 요청 시 AWS 인증 전문가에 대한 액세스를 제공합니다.