버즈빌

RSS

게시글: 102
등록: 2026년부터

All Frontend Backend AI DevOps Architecture Etc

DevOps
Python 2.7 서버의 CI Test 개선 - 13분에서 3분으로
버즈빌 허니스크린 서비스는 빈번한 배포가 필수적이지만, 약 13분 소요되는 CI 파이프라인의 긴 실행 시간이 병목이었습니다. 특히 Python 2.7 환경에서 CI-Test 작업이 평균 11분으로 가장 큰 비중을 차지했으며, Pull Request와 master merge 후에도 중복 실행되어 전체 배포 시간을 지연시켰습니다. 또한, CI-Test 단계에서 불필요한 패키지 설치 및 소스 빌드 과정이 포함되어 실제 테스트 실행 시간보다 오래 걸리는 문제가 있었습니다. 이에 첫 번째 최적화로 마스터 브랜치 merge 후 CI-Test 중복 실행을 방지하도록 트리거를 제한하여 전체 배포 시간을 50% 단축했습니다.
CI/CDPython 2.7CI Test
버즈빌·2025년 12월 18일
DevOps
AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까
버즈빌은 2023년 한 해 동안 약 14억 원에 달하는 AWS 비용을 절감한 경험을 공유합니다. 2022년 12월 월 3.6억 원이었던 AWS 비용을 2023년 12월 기준 월 2.4억 원으로 최적화했습니다. 이러한 비용 최적화는 매출 성장과 함께 상승한 인프라 비용 부담을 줄이고 회사의 장기적인 생존력을 강화하기 위해 시작되었습니다. 목표는 매출액 대비 인프라 비용을 과거 수준으로 되돌리고 일반적인 SaaS 기업의 효율성을 달성하는 것이었습니다. 이를 위해 구체적인 지표를 설정하고 팀의 동기 부여를 위한 방안을 모색했습니다. 본 글은 비용 최적화 과제 시작의 이유와 목표 설정 과정을 다루며, 향후 시리즈를 통해 구체적인 절감 팁을 공유할 예정입니다.
AWS비용 최적화클라우드
버즈빌·2024년 4월 29일
DevOps
AWS 비용 최적화 Part 1: 버즈빌은 어떻게 월 1억 이상의 AWS 비용을 절약할 수 있었을까
버즈빌은 2023년 한 해 동안 약 14억 원에 달하는 AWS 비용을 절감한 경험을 공유합니다. 2022년 12월 월 3.6억 원이었던 AWS 비용을 2023년 12월 기준 월 2.4억 원으로 최적화했습니다. 이러한 비용 최적화는 빠르게 성장하는 과정에서 제품 개발 속도를 우선시하며 증가한 인프라 비용을 관리하고, 경기 침체 및 투자 시장 위축 상황에 대비하여 회사의 재무적 기초 체력을 강화하기 위해 시작되었습니다. 목표는 매출액 대비 인프라 비용을 과거 수준 이하로 효율화하고, 일반적인 SaaS 기업의 평균 수준(4~8%)에 맞추는 것이었습니다. 비용 최적화 과제의 동기 부여를 위해 '성과를 내고 싶으면 실행하라' 책의 원칙을 참고하여 지표를 설정하고 점수판을 만드는 방식을 도입했습니다.
AWS비용 최적화Cloud
버즈빌·2024년 4월 29일
DevOps
데이터 엔지니어의 Airflow 데이터 파이프라인 CI 테스트 개선기
버즈빌 데이터 엔지니어 Abel이 데이터 파이프라인 CI 테스트에 소요되는 시간을 7분대에서 3분대로 단축한 경험을 공유합니다. 기존 CI 테스트는 데이터 파이프라인 추가 과정에서 사람의 실수를 감지하기 위해 Pull Request 생성 시 자동으로 실행되었으나, 넓은 영향 범위로 인해 개선 우선순위가 낮았습니다. 벨로시티 스프린트 기간을 활용하여 CI 테스트의 각 단계를 분석하고, 특히 ECR 로그인, 이미지 빌드, 코드 스타일 검사(flake8), 타입 검사(mypy) 등의 과정을 최적화하여 전체 테스트 시간을 획기적으로 줄였습니다. 이를 통해 데이터 파이프라인 관리자들의 개발 효율성을 크게 향상시켰습니다.
AirflowCI데이터 파이프라인
버즈빌·2024년 4월 18일
DevOps
쿠버네티스에게 Github Actions 설치에 대해 묻다
이 글은 버즈빌 DevOps 팀에서 Github Actions를 자체 호스팅으로 설치하고 운영하는 경험을 공유합니다. GitHub에서 제공하는 호스팅 방식의 제약(빌드 환경 제어 불가, 보안 문제, 비효율성) 때문에 자체 호스팅을 결정했으며, 특히 Kubernetes 기반의 ARC(Actions Runner Controller)를 사용한 이유를 설명합니다. ARC는 Kubernetes 오퍼레이터로, 러너를 파드로 실행하여 비용 효율성, 확장성, 속도 측면에서 이점을 제공합니다. 각 워크플로에 최적화된 리소스를 할당하고, Kubernetes의 자동 확장 기능을 활용하며, 대기 상태의 러너 파드를 유지하여 CI/CD 파이프라인의 효율성을 높이는 방법을 다룹니다.
GitHub ActionsKubernetesCI/CD
버즈빌·2024년 1월 1일
DevOps
Self Serving Data Platform 구축하기 (feat. Airflow)
버즈빌 데이터 엔지니어링 팀은 특정 팀에 의존하지 않고 누구나 데이터를 생산 및 소비할 수 있는 셀프 서빙 데이터 플랫폼을 구축했습니다. 과거에는 데이터 파이프라인 생성 요청 시 데이터 엔지니어에게 의존해야 했으나, 서비스 및 분석 도메인 다양화로 인지 부하가 증가하고 데이터 조회 지연 문제가 발생했습니다. 이를 해결하기 위해 도메인 전문성을 활용하는 셀프 서빙 플랫폼 개발을 시작했습니다. 버즈빌의 데이터 인프라는 S3를 SSOT로 활용하고, Athena와 Redshift를 통해 데이터를 분석 및 처리합니다. 특히 Airflow를 활용하여 데이터 파이프라인을 효율적으로 관리하고 자동화하는 방안을 제시합니다.
데이터 플랫폼Airflow데이터 파이프라인
버즈빌·2023년 5월 31일
DevOps
배포를 빠르게 - DIY(Deploy It Yourself)
이 글은 버즈빌에서 배포 속도를 높이기 위해 도입한 DIY(Deploy It Yourself) 전략을 소개합니다. 기존에는 배포 파이프라인 구축을 위해 헬름(Helm)이나 스피네이커(Spinnaker)와 같은 도구를 익혀야 했으나, 이는 배포 속도를 저하시키는 요인이었습니다. 버즈빌은 이를 해결하기 위해 단일 헬름 차트를 운영하고, 스피네이커의 파이프라인 템플릿 기능을 활용하여 사용자가 복잡한 설정 없이 `values.yaml` 파일 작성만으로 배포 파이프라인을 쉽게 구축할 수 있도록 했습니다. 이를 통해 엔지니어들은 새로운 도구를 학습하는 부담 없이 신속하게 서비스를 배포하고 고객에게 전달할 수 있게 되었습니다.
배포CI/CDDIY
버즈빌·2022년 7월 5일
DevOps
배포를 안전하게 - 카나리 배포, 롤백
이 글은 버즈빌에서 배포의 속도와 안전성을 동시에 확보하기 위해 도입한 카나리 배포 전략과 롤백 구현 방안을 다룹니다. AWS EKS 기반 쿠버네티스 환경에서의 배포 과정을 상세히 설명하며, 도커 이미지 빌드부터 쿠버네티스 메니페스트 생성까지의 파이프라인을 소개합니다. 특히, 각 커밋별로 도커 이미지를 빌드하고 커밋 SHA 값을 태그로 사용하여 이미지의 유니크함을 보장하는 방식을 설명합니다. 또한, CI/CD 파이프라인에서 이미지 빌드 후 쿠버네티스 메니페스트를 생성하고 배포하는 과정과, 배포 안정성을 높이기 위한 카나리 배포 전략 및 문제 발생 시 신속하게 이전 버전으로 되돌리는 롤백 기능의 중요성을 강조합니다.
배포카나리 배포롤백
버즈빌·2022년 6월 21일
DevOps
배포를 우아하게 - 원-클릭(one-click) 배포
이 글은 버즈빌에서 복잡한 런타임 환경 속에서도 배포 시스템의 복잡성을 줄이고 '원-클릭 배포'를 구현한 경험을 공유합니다. 일반적으로 런타임 환경이 늘어날수록 배포 시스템은 복잡해지지만, 버즈빌은 AWS EKS 기반 쿠버네티스, AWS 람다, AWS S3 등 다양한 환경에서도 통일된 배포 방식을 제공합니다. 이를 위해 각기 다른 배포 도구(Spinnaker, Drone CI) 대신 GitHub 배포 API를 활용하여 배포 파이프라인을 추상화했습니다. 사용자는 GitHub API만을 통해 배포를 트리거하고 상태를 확인할 수 있어, 배포 도구에 대한 이해 없이도 간편하게 배포 작업을 수행할 수 있습니다. 또한, 안전한 배포를 위한 카나리 배포 전략과 롤백, 빠른 배포를 위한 DIY 방식도 함께 소개합니다.
배포원클릭 배포카나리 배포
버즈빌·2022년 6월 14일
DevOps
Minerva: Airbnb's Metric Platform
이 글은 버즈빌 개발팀의 기술 공유 세션에서 발표된 Airbnb의 Metric Platform인 Minerva에 대한 내용을 다룹니다. Minerva는 Airbnb의 방대한 데이터를 효율적으로 관리하고 분석하기 위해 설계된 플랫폼입니다. 발표자는 Data Engineer Raf Kim으로, Minerva의 아키텍처, 주요 기능, 그리고 이를 통해 얻을 수 있는 이점들에 대해 공유했습니다. Metric Platform은 대규모 시스템에서 발생하는 다양한 지표들을 수집, 처리, 시각화하여 서비스의 성능을 모니터링하고 문제를 진단하는 데 필수적입니다. Minerva는 이러한 요구사항을 충족시키기 위해 설계되었으며, Airbnb의 안정적인 서비스 운영에 기여하는 핵심 요소 중 하나입니다. 이 발표는 대규모 서비스의 데이터 관리 및 모니터링 시스템 구축에 대한 인사이트를 제공합니다.
Metric PlatformMinervaAirbnb
버즈빌·2022년 6월 2일
DevOps
AWS GameDay Microservice Magic에서 3위! 버즈빌 A팀 인터뷰
버즈빌 개발팀이 AWS GameDay 'Microservice Magic' 대회에서 3위를 차지한 경험을 공유하는 글입니다. AWS GameDay는 실제 환경과 유사한 모의 환경에서 의도적으로 장애를 유발하여 대응 훈련을 하는 행사로, 이번 대회는 모노리스 환경을 마이크로서비스 환경으로 개선하는 주제로 진행되었습니다. 인터뷰를 통해 참가자들은 GameDay 참여 계기, 각자 맡은 역할(마이크로서비스 담당, API 게이트웨이, 정보 전파), 그리고 실제 버즈빌의 MSA 개선 과정과 GameDay 시나리오의 유사점 및 차이점에 대해 이야기합니다. 이 글은 개발자들에게 장애 대응 훈련의 중요성과 마이크로서비스 아키텍처 개선 경험을 간접적으로 전달합니다.
AWS GameDayMicroservice Magic장애 대응
버즈빌·2022년 3월 17일
DevOps
VS Code로 컨테이너 안에서 개발하기
이 글은 컨테이너 환경에서의 개발 필요성과 VS Code를 활용한 개발 환경 구성 방법을 다룹니다. 컨테이너는 배포 환경과 개발 환경을 일치시켜 예상치 못한 문제를 줄이고, docker-compose를 통해 실제 배포 환경과 유사한 환경을 로컬에서 구축할 수 있게 합니다. 하지만 개발 환경 통일과 테스트 환경 구성에 어려움이 있을 수 있습니다. 특히, IDE의 인텔리센스 기능 활용이나 디버깅을 위해 컨테이너 내부에 개발 도구를 설치해야 할 필요성이 제기됩니다. VS Code의 Remote-Containers 확장 기능을 사용하면 컨테이너 내부에서 직접 개발 및 디버깅이 가능해져 이러한 문제들을 해결하고 개발 생산성을 높일 수 있습니다.
DockerKubernetesVS Code
버즈빌·2019년 11월 12일
DevOps
How We Pipe Data
이 글은 버즈빌에서 1,700만 명 이상의 사용자 행동 데이터를 수집하고 분석하기 위해 구축한 데이터 파이프라인 구축 경험을 공유합니다. 다양한 소스와 데이터베이스(MySQL, DynamoDB, Redis, S3 등)에 흩어진 데이터를 Redshift라는 데이터 웨어하우스로 통합하는 과정을 설명합니다. Redshift는 열 기반 스토리지, 분산 저장 방식, 빠른 데이터 수집 속도, 수평적 확장성 등의 장점으로 인해 버즈빌의 데이터 통합 솔루션으로 선택되었습니다. 글은 데이터 수집 및 저장 방식과 통합 파이프라인 구축의 어려움 및 해결 과정을 다루며, 대규모 데이터 처리를 위한 기술적 고민과 솔루션을 제시합니다.
데이터 파이프라인Redshift데이터 수집
버즈빌·2018년 7월 31일
DevOps
버즈빌의 AWS Summit 2018 발표 참관기
이 글은 버즈빌의 AWS Summit Seoul 2018 발표 참관 후기입니다. 버즈빌은 EC2, S3, RDS 등 다양한 AWS 서비스를 활용하고 있으며, 이번 행사에서는 Senior Engineer Ben이 "AWS에서 Kubernetes 실전 활용하기"라는 주제로 발표했습니다. 발표 내용은 스타트업 환경에서 인프라 엔지니어 없이 여러 인스턴스의 컨테이너를 효율적으로 관리하기 위한 Kubernetes 도입 배경과 필요성에 초점을 맞췄습니다. 특히, Kubernetes가 Docker 컨테이너 생성 시 노드 개수를 최적화하는 Automatic binpack 기능 등을 통해 컨테이너 오케스트레이션의 이점을 강조했습니다. 이 글은 AWS와 Kubernetes를 활용하는 개발자 및 운영자에게 유용한 정보를 제공합니다.
AWS Summit Seoul 2018KubernetesContainer Orchestration
버즈빌·2018년 5월 4일
DevOps
버즈빌 AWS 활용기
버즈빌은 6명의 개발자로 허니스크린, 버즈애드 등 여러 서비스를 운영하기 위해 AWS에 적극적으로 의존하고 있습니다. 초기에는 EC2, RDS 등 기본 서비스를 사용했지만, 점차 Auto Scaling, CloudFront, Lambda, DynamoDB, Route 53 등 다양한 AWS 서비스를 도입했습니다. 이 글에서는 EC2 인스턴스 보안 강화를 위한 IAM role 활용, Security Group 설정 시 IP 제한 및 내부 통신 보안, 그리고 Availability Zone 선택 시 트래픽 비용 절감을 위한 팁을 공유합니다. 또한, t2 인스턴스의 CPU 성능에 대한 오해를 바로잡고, AWS를 통해 운영 리소스를 효율화하는 방안을 제시합니다.
AWSEC2IAM
버즈빌·2015년 11월 6일
DevOps
Scaling PhantomJS With Ghost Town
이 글은 Buzzvil에서 PhantomJS를 사용하여 대규모 이미지 렌더링 시스템을 구축한 경험을 공유합니다. PhantomJS는 불안정하고 메모리 사용량이 높으며 시작 시간이 느리고 수동 확장이 필요한 라이브러리입니다. 이러한 문제를 해결하기 위해 Ghost Town이라는 Node.js 모듈을 개발했습니다. Ghost Town은 PhantomJS 프로세스를 관리하고, 작업 큐를 통해 작업을 처리하며, 실패 시 재할당하여 안정성을 보장합니다. 또한 메모리 누수를 방지하기 위해 각 워커마다 별도의 PhantomJS 프로세스를 생성하고 주기적으로 재시작합니다. 이를 통해 낮은 지연 시간과 높은 동시성을 요구하는 이미지 렌더링 요구사항을 충족시켰습니다.
PhantomJSGhost TownNode.js
버즈빌·2014년 5월 29일