데이터 엔지니어의 Airflow 데이터 파이프라인 CI 테스트 개선기
들어가며 안녕하세요, 버즈빌 데이터 엔지니어 Abel 입니다. 이번 포스팅에서는 데이터 파이프라인 CI 테스트에 소요되는 시간을 어떻게 7분대에서 3분대로 개선하였는지에 대해 소개하려 합니다. 배경 이전에 버즈빌의 데이터 플랫폼 팀에서 ‘셀프 서빙 데이터 …
Read Article버즈빌은 2023년 한 해 동안 월간 약 1.2억, 연 기준으로 14억에 달하는 AWS 비용을 절약하였습니다. 그 경험과 팁을 여러 차례에 걸쳐 공유합니다.
버즈빌은 2022년 12월 약 3.6억에 달하는 AWS 비용이 발생하고 있었습니다. 지난 한 해 많은 노력을 기울인 끝에 2023년 12월 기준 전년 대비 2/3 수준인 월 2.4억으로 AWS 비용을 최적화했습니다. 이번 포스팅에서는 비용 최적화를 성공적으로 이끌어내기 위해 어떠한 방식의 접근을 취했는지를 공유합니다.
리워드 광고 플랫폼을 운영하는 버즈빌은 2013년 첫 서비스를 시작한 이래로 연간 매출이 600억원 가까이 될 정도로 빠르게 성장해왔습니다. 제품 개발 속도와 비용 최적화 사이에는 트레이드오프 관계가 존재합니다. 많은 상황에서 비용이 더 들더라도 제품 개발 속도를 빠르게 하는 방향으로 의사결정을 해오면서 AWS 비용이 지속해서 상승해왔습니다. 버즈빌은 탄탄하게 매출을 만들어오고 있는 회사이지만 경기 침체가 계속되고 스타트업 투자 시장이 얼어붙는 상황에서 오랜 기간 버틸 수 있는 기초 체력을 다지기 위해서 큰 비중을 차지하는 AWS 비용 최적화가 필요하다는 판단을 내렸습니다.
앞서 언급했듯이 비용과 제품 개발 속도는 트레이드오프 관계에 있습니다. 어느 한 쪽으로 지나치게 치우치기보다는 적절한 균형점을 찾는 것이 중요합니다. 그러면 어느 정도까지 비용을 최적화하는 것이 필요한지 객관적인 기준이 필요했습니다. 이는 재무팀에서 명확하게 제시해 주셨습니다. 바로 매출액 대비 인프라 비용이었습니다. 월마다 어느 정도 변동성이 있긴 했지만, 2021년 대비하여 2022년에는 매출액 대비 인프라 비용이 두 배 가까이 증가했습니다. 이를 원상태 이하로 효율화하는 것을 목표로 세웠습니다. 버즈빌을 담당해 주시는 AWS 계정 매니저님께서도 일반적인 SaaS 기업의 매출 대비 인프라 비용은 4% ~ 8% 수준이라는 의견을 주셨습니다. 버즈빌이 위험한 구간에 들어가지 않고 일반적인 SaaS 기업보다 더 효율적으로 운영되도록 하는 것을 목표로 하였습니다.
과제를 시작하기에 앞서 어떻게 하면 비용 최적화 목표의 동기부여를 더 잘 할 수 있을까 고민했습니다. 마침 회사에서 리더십 향상을 돕기 위해 “성과를 내고 싶으면 실행하라"라는 책을 선물받았습니다.
책에서는 4가지 실행 원칙을 제시하고 있습니다.
여기서 특히 원칙 3번이 가장 기억에 남았습니다. 지금 내가 이기고 있는지 지고 있는지를 점수판을 통해 쉽게 확인할 수 있어야 더욱 동기부여를 받고 목표를 달성할 수 있다고 합니다. 예를 들어 농구장에서 친구들이 점수를 세지 않고 게임을 하고 있을 때 누군가가 점수판을 갖다놓고 점수를 세기 시작하면 게임에서 이기기 위해서 더 열심히 하게 된다는 것입니다. 생각해 보니 저도 그런 경험이 있었던 것 같습니다. 그래서 점수판을 만들어야겠다고 생각했습니다.
그러고 나니 점수판의 점수를 무엇으로 할지 고민이 되었습니다. 처음에는 실제 청구된 AWS 비용을 점수판의 지표로 사용하려고 했습니다. 이는 우리가 달성하고자 하는 최종 아웃풋 지표라고 볼 수 있습니다. 하지만 이 지표는 한 가지 문제가 있습니다. 그것은 내가 아무리 비용 최적화를 잘 해도 트래픽이 상승하는 등 다른 이유로 비용이 증가하게 되면 노력한 결과가 잘 드러나지 않을 수 있다는 것입니다. 따라서 내가 한 노력이 그대로 드러나며 그 결과가 목표 달성에 중요한 영향을 미치는 지표인 인풋 지표가 필요했습니다. 그래서 각 과제를 수행할 때마다 수행하기 전/후 시점에 해당 서비스에서 청구된 비용 변화를 측정하고 이를 월 기준으로 환산한 절약 금액을 사용하기로 했습니다. 점수판에서는 누적된 절약 비용을 빨간색 선으로 표시하고 12월까지 10만 달러 절약 과제 수행을 목표로 표기했습니다.
이제 게임에서 지고 있는지(빨간선이 파란선 아래 위치하는지), 게임에서 이기고 있는지(빨간선이 파란선 위에 위치하는지) 쉽게 알 수 있는 상태가 되었습니다. 11월 이후 큰 폭으로 비용 최적화 과제가 수행된 것을 볼 수 있는데요. 이 점수판은 연말에 막판 스퍼트를 하는 데 동기 부여가 되었습니다. 결과적으로 1년간 약 100개의 과제를 수행하고 목표했던 10만 달러 절약 과제를 초과 달성하여 10.6만 달러의 과제를 수행했습니다. 실제로 줄어든 비용은 8.8만 달러로, 진행한 과제의 80% 수준으로 비용이 줄어들었습니다. 이를 통해 실제로 인풋 지표와 아웃풋 지표 사이에 차이가 있는 것을 알 수 있었고, 인풋 지표를 활용하는 것이 적절한 선택이었다는 것을 다시 한 번 확인했습니다.
참고로 위의 지표는 스프레드시트에서 과제가 수행될 때마다 일일이 수기로 입력하여 관리했습니다. 개발자로서 뭔가를 자동화하고 싶다는 욕구가 치솟았지만 수동으로 관리하는 것도 충분히 효율적인 방식이었습니다.
자, 이제 점수판도 만들었습니다. 그러면 이제 실제로 과제를 수행해야 합니다. 어떤 과제를 수행해야 하는지 판단하기 위해서는 어디서 비용이 발생하고 있는지 다양한 수준에서 데이터를 쪼개 봐야 합니다. 버즈빌은 MSP인 메가존을 통해서 AWS를 이용하고 있습니다. 이 경우 안타깝게도 AWS에서 제공하는 Cost Explorer를 사용할 수 없습니다. 하지만 메가존에서 제공하는 비용 분석 대시보드인 하이퍼빌링의 Cost Pivot 기능만 활용해도 아래와 같이 여러 가지 기준으로 드릴 다운을 통해 비용을 분석할 수 있어 부족함이 없었습니다.
가장 먼저 확인해야 할 숫자는 서비스별 비용입니다. 서비스별 비용을 보면 어디부터 최적화하는 것이 기대 효과가 큰지 일차적인 판단을 할 수 있습니다. 다음은 버즈빌의 주요 서비스에 대한 실제 비용 변화를 표로 작성하였습니다.
서비스 | 2022년 12월 | 2023년 12월 | 비용 변화 |
---|---|---|---|
AmazonEC2 | $75,104 | $58,959 | -21.50% |
AWSDataTransfer | $71,908 | $35,869 | -50.12% |
AmazonDynamoDB | $41,093 | $19,750 | -51.94% |
AmazonS3 | $25,253 | $20,595 | -18.45% |
AmazonRDS | $25,122 | $11,862 | -52.78% |
AmazonAthena | $7,501 | $9,408 | 25.42% |
AWSELB | $6,862 | $3,606 | -47.45% |
AmazonCloudWatch | $5,499 | $4,278 | -22.20% |
AmazonCloudFront | $3,485 | $5,997 | 72.08% |
비용에서 가장 큰 비중을 차지하는 쌍두마차는 EC2와 데이터 전송 비용인 것을 알 수 있습니다. 데이터 전송 비용이 EC2 비용과 비슷한 수준이면 너무 많이 나가는 것이 아닐까라는 생각을 하셨을 것입니다. 실제로도 데이터 전송 비용에 최적화할 부분이 많았고, 2023년 12월에는 50%가량 감소한 것을 알 수 있습니다. 버즈빌에서 주력 데이터베이스로 활용하고 있는 DynamoDB와 RDS MySQL에서도 많은 비용이 발생하고 있었고, 마찬가지로 50% 가량 최적화를 진행하였습니다.
각 서비스에서 발생하는 비용을 좀 더 자세히 분석하기 위해서는 Cost Pivot에서 제공하는 기능을 활용해 데이터를 드릴 다운해서 봐야 합니다. 어떤 기준으로 드릴 다운하는 것이 유용한지는 AWS 서비스에 따라서, 그리고 각 회사가 어떤 패턴으로 해당 서비스를 사용하고 있는지에 따라서 다르기 때문에 직접 여러 가지 방법으로 시도해 봐야 합니다.
그래도 가장 유용한 기준이 무엇인지 하나만 고른다면 바로 Lineitem Description입니다. 적당히 세부적인 레벨에서 비용을 구분해서 보여주며 말 그대로 어떤 비용인지 이해하기 쉽게 글로 기술되어 있습니다. 예를 들어 DynamoDB의 경우 다음과 같은 수준으로 데이터를 구분해서 볼 수 있습니다.
그 외에 각 서비스 별로 주로 활용했던 기준은 다음과 같습니다.
드릴 다운을 통해 숫자를 분석하다 보면 “어, 이거 좀 이상한데?“라는 생각이 드는 경우가 있습니다. 그리고 그 부분에 대해서 최적화를 했을 때 어느 정도의 기대 효과가 있는지도 추정할 수 있어야 합니다. 이를 위해서는 각 서비스별로 비용 발생 구조를 이해하고 그 숫자가 어떻게 되는지 기억하고 있는 것이 유리합니다. 특히 상대적인 비용 차이가 어떻게 되는지를 알면 도움이 되는 경우가 많았습니다. 이것이 무엇을 의미하는지는 다음과 같은 재미있는 사례를 통해 설명드립니다.
버즈빌은 S3에 적재된 데이터를 분석하기 위한 쿼리 엔진으로 Athena를 주로 활용하고 있습니다. Athena는 쿼리를 실행했을 때 스캔한 데이터량에 따라 비용이 발생합니다. 1TB 데이터를 스캔하면 5달러의 비용이 발생합니다. 버즈빌에서는 누구나 데이터 분석을 스스로 할 수 있도록 장려하고 있기에 많은 분들이 직접 Athena 쿼리를 통해 데이터를 분석하고 있습니다. 그러다 보니 내가 실행하는 쿼리가 얼마나 비용을 발생시키는지를 알고 있어야 하고, 1TB = 5달러라는 공식은 모두가 기억하고 있는 중요한 숫자가 되었습니다.
버즈빌은 대부분의 인프라가 도쿄 리전에 존재합니다. 그런데 데이터 분석 인프라는 오레곤 리전에 있습니다(여기에는 그 당시 어쩔 수 없던 사연이 있습니다). 그래서 도쿄 리전에서 생성된 데이터를 오레곤 리전으로 복사한 뒤 Athena를 활용해 데이터를 분석하고 있습니다.
자, 그렇다면 도쿄 리전에서 오레곤 리전으로 1TB의 데이터를 전송하는 데 드는 비용은 얼마일까요? 공식 홈페이지에 “$0.9 per GB” 라고 되어 있습니다. TB로 환산하면 다음과 같이 되겠네요.
1TB = $90
그렇습니다. Athena 스캔 비용의 18배에 달하는 비용이 데이터 전송에서 발생하고 있던 것입니다. 이를 통해 데이터를 다른 리전으로 옮겨서 처리하는 것이 얼마나 큰 비용을 발생시키는 결정이었는지 깨닫게 되었습니다. 사실 “$0.9 per GB"라는 숫자는 이전에도 많이 봤던 숫자였습니다. 다만 이전에는 그게 실제로 무슨 의미인지 몰랐다면, Athena 비용과 같은 기준에서 비교한 뒤로는 그 의미를 좀 더 구체적으로 알 수 있게 된 것입니다. 바로 이것이 숫자에 대한 감각이라고 생각합니다.
그래서 다른 AWS 비용도 TB 기준으로 환산해 보았습니다. 도쿄 리전 기준입니다.
이를 통해 NAT Gateways 데이터 처리 비용이 꽤 비싸다는 것, RDS MySQL에 있는 데이터를 S3으로 옮겨서 백업해두면 1/5도 안되는 가격으로 보관이 가능하다는 것 등을 알 수 있습니다.
공식 문서를 보면 소수점 아래로 숫자가 많아서 읽기 어렵지만, 쓰기 비용이 읽기 비용보다 정확히 5배 비쌉니다. 따라서 이를 고려하여 최적화를 해볼 수 있습니다. 예를 들어 인덱스를 추가할 때 읽기 비용은 감소하고 쓰기 비용은 증가하게 되는데요. 이 때 위의 사실을 고려해야 합니다.
서비스마다 숫자가 조금씩 다르지만, 약정 구매를 했을 때 할인받을 수 있는 범위가 크게 두 가지 타입으로 나뉩니다.
따라서 3년 약정 시 75%까지 할인이 되는 DynamoDB나 Redshift의 경우 약정 구매를 더 적극적으로 적용하는 전략을 취할 수 있습니다.
이번 포스팅에서는 AWS 비용 최적화를 시작하는 단계에서 점수판을 만들고, 수행해야 할 과제를 도출하기 위해 드릴 다운을 통해 비용 데이터를 분석하는 방법을 말씀드렸습니다. 이어지는 포스팅에서는 각 서비스별로 조금 더 구체적인 사례를 공유드릴 예정입니다. 많은 기대 부탁드립니다 :)
들어가며 안녕하세요, 버즈빌 데이터 엔지니어 Abel 입니다. 이번 포스팅에서는 데이터 파이프라인 CI 테스트에 소요되는 시간을 어떻게 7분대에서 3분대로 개선하였는지에 대해 소개하려 합니다. 배경 이전에 버즈빌의 데이터 플랫폼 팀에서 ‘셀프 서빙 데이터 …
Read Article안녕하세요. Demand Product 팀의 Ad Management 파트에서 서버 개발자로 일하고 있는 Kay입니다. 제가 팀에 합류한 지도 어느덧 2년이 되어가는데요, Ad Management 파트(이하 AdM)은 무슨 일을 하는지 간단하게 소개하고 재미있게 했던 …
Read Article