버즈빌

RSS

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

All Frontend Backend AI DevOps Architecture Etc

Backend
DynamoDB Limit 설정으로 RCU 97% 절감한 이야기
본 글은 버즈빌 Supply Platform 팀에서 대규모 트래픽 환경에서 DynamoDB RCU(Read Capacity Unit) 사용량이 급증한 이슈를 해결한 경험을 공유합니다. RCU 사용량은 약 1k에서 최고 130k RCU/s까지 130배 증가했으며, 원인 분석 결과 `Limit` 설정 누락과 불필요한 Strong Consistent Read 사용이 문제였습니다. 해결책으로 `Limit` 설정을 적용하고 Eventually Consistent Read로 전환하여 RCU 사용량을 87~97% 절감하는 성과를 거두었습니다. 이 경험은 대규모 트래픽 환경에서 데이터베이스 성능 최적화 및 비용 절감을 고민하는 개발자들에게 실질적인 도움을 줄 수 있을 것입니다.
DynamoDBRCUAWS
버즈빌·2026년 1월 23일
Backend
5대 금융사를 품은 버즈베네핏의 백엔드 팀은 무슨 일을 할까요?
버즈빌 Supply 그룹의 Product Backend 팀 리드 Wynn이 팀의 탄생 배경과 역할을 소개하는 글입니다. 버즈베네핏은 10년간 리워드 광고 송출에 집중했지만, 최근 게이미피케이션 기능 강화와 5대 금융사 파트너 확보 등 플랫폼으로 빠르게 진화했습니다. 이러한 제품의 급격한 성장과 함께 백엔드 시스템은 데이터 구조 파편화, 확장성 및 유지보수성 한계, 실험 데이터 수집/가공의 어려움 등 문제에 직면했습니다. 이에 따라 Product Backend 팀은 이러한 문제들을 근본적으로 해결하고 버즈베네핏의 현재와 미래 도약을 책임지기 위해 탄생했으며, 팀의 원칙과 목표를 수립했습니다.
버즈베네핏백엔드시스템 설계
버즈빌·2025년 10월 31일
Backend
Ad Management 파트 서버 개발자의 지역 타게팅 개선기
버즈빌 Ad Management 파트의 서버 개발자가 지역 타게팅 기능의 결함을 개선한 경험을 공유합니다. 글에서는 2주 스프린트 기반의 애자일 개발 방식과 자유로운 커뮤니케이션 문화를 소개하며, 입사 초기 맡았던 지역 타게팅 기능의 문제점을 발견하고 해결해나가는 과정을 상세히 설명합니다. 다양한 타겟팅 옵션 중 지역 타게팅 기능에 발생한 결함을 파악하고, 이를 개선하기 위한 서버 개발자의 노력을 중심으로 다룹니다. 이를 통해 팀의 개발 프로세스와 문제 해결 과정을 엿볼 수 있습니다.
서버 개발지역 타게팅Ad Management
버즈빌·2024년 3월 21일
Backend
RDS IOPS 장애 대응기
버즈빌에서 AWS RDS MySQL 데이터베이스 운영 중 발생한 메모리 및 IOPS 관련 장애와 해결 과정을 공유하는 글입니다. 월 2천만 사용자, 월 70억 건의 광고 요청을 처리하는 환경에서 user 서비스의 RPS가 5000/s에 달하는 상황에서, CPU 스로틀링, 메모리 사용량 급증, Goroutine 증가, MySQL replica 연결 폭증 등의 문제가 발생했습니다. RDS 모니터링 결과 IOPS 증가로 인한 burst balance 고갈이 원인으로 파악되었고, 스토리지 증설로 단기적인 문제를 해결했습니다. 이후 높은 디스크 I/O의 근본 원인을 조사하기 위해 3일간의 burst balance 변화를 분석한 결과, 낮 시간대에 지속적으로 burst balance를 사용하는 패턴을 확인했으며, 이에 대한 추가적인 조사와 해결 방안 모색이 필요함을 시사합니다.
RDSMySQLIOPS
버즈빌·2023년 11월 16일
Backend
광고 예산 제어 시스템 개선기: Part 2 – 더 정교한 시스템, 그리고 성과
이 글은 버즈빌의 광고 예산 제어 시스템 개선 경험을 공유하는 2편입니다. 1편에서 다룬 시스템 수준 개선을 바탕으로, 더 정교한 예산 제어를 위한 두 가지 주요 개선 사항을 소개합니다. 첫째, 예산 평가 주기를 15초로 단축하여 지출 스파이크로 인한 예산 초과 달성 실패를 줄이고 성과 최적화를 도모했습니다. 둘째, 지출 계획 단위를 1시간에서 1분으로 세밀하게 조정하여 광고 노출 기회 손실을 방지하고 성과 최적화에 기여했습니다. 이러한 개선을 통해 시스템의 안정성을 높이고 비즈니스 임팩트를 창출했습니다.
예산 제어 시스템광고 시스템마이크로서비스
버즈빌·2023년 2월 15일
Backend
예산 제어 시스템 개선기: Part 1 – 시스템과 가시성 개선
버즈빌 광고 플랫폼의 예산 제어 시스템 개선 과정을 소개하는 글입니다. 예산 제어는 캠페인 예산을 효율적으로 분배하여 광고 성과를 극대화하는 핵심 기능으로, 초기에는 광고 서버에 통합되었으나 현재는 별도의 마이크로서비스로 분리되어 고도화되고 있습니다. 예산 제어 시스템은 현재까지의 예산 소진액과 계획된 속도를 비교하여 다음 주기 동안의 예산 지출 속도를 조절하며, 이는 광고 서버의 입찰 빈도 결정에 영향을 미칩니다. 시스템은 예산 소진 속도가 계획보다 빠르면 줄이고, 느리면 빠르게 만드는 피드백 루프를 통해 작동합니다. 글에서는 예산 제어 시스템의 작동 방식과 함께, 예산 목표 설정, 지출 속도 조절 등 시스템 설계 시 고려해야 할 사항들을 다룹니다.
예산 제어 시스템광고 플랫폼마이크로서비스
버즈빌·2023년 2월 8일
Backend
엘라스틱서치를 활용한 수평 확장 가능한 광고 서버 만들기
이 글은 버즈빌이 리워드 광고 플랫폼 운영 중 겪었던 광고 서버의 확장성 문제를 해결하기 위해 MySQL 기반 시스템을 엘라스틱서치로 전환한 경험을 공유합니다. 초기 광고 서버는 다수의 테이블 조인과 100개 이상의 복잡한 WHERE 조건으로 인해 성능 저하를 겪었습니다. 광고 서버의 특성상 읽기 요청이 쓰기 요청보다 압도적으로 많고 최종 일관성이 허용된다는 점을 고려하여, 엘라스틱서치를 도입하여 수평 확장 가능한 고성능 광고 서버를 구축하는 과정을 설명합니다. 이를 통해 대규모 트래픽 처리와 다양한 타게팅 조건 충족이라는 두 가지 핵심 과제를 해결했습니다.
엘라스틱서치광고 서버수평 확장
버즈빌·2022년 12월 11일
Backend
Elasticsearch 검색에서 확률 사용하기
이 글은 Elasticsearch에서 각 문서에 확률을 적용하여 검색하는 두 가지 방법을 소개합니다. 버즈빌에서는 광고 서빙 속도 향상을 위해 Elasticsearch에 광고를 캐싱하고 있으며, 광고 요청 시 각 광고의 할당 확률을 동적으로 조절해야 하는 필요성이 발생했습니다. 기존의 `term`이나 `range` 쿼리로는 이러한 동적 확률 적용이 어렵기 때문에 Elasticsearch의 다른 기능을 활용해야 합니다. 글에서는 먼저 `range` 쿼리를 이용한 잘못된 접근 방식을 설명하고, 이어서 Elasticsearch의 `function_score` 기능을 활용하여 `alloc_rate` 필드에 기반한 확률적 검색을 구현하는 방법을 제시합니다. 각 방법의 성능 비교와 장단점을 분석하여 Elasticsearch에서 확률 기반 검색을 효과적으로 구현하는 데 도움을 줍니다.
Elasticsearch검색확률
버즈빌·2022년 6월 7일
Backend
asyncio 뽀개기 3 - SIGTERM (CTRL+C) 올바르게 처리하기
본 글은 asyncio를 사용하는 서버에서 SIGTERM 신호를 올바르게 처리하여 graceful shutdown을 구현하는 방법을 다룹니다. asyncio는 Eventloop에 task를 등록하는 구조이므로, graceful shutdown 없이 종료될 경우 사용자 요청이 유실될 수 있습니다. 이전 포스트에서 asyncio의 코루틴과 이벤트 루프, Future의 활용법을 다뤘다면, 이번 글에서는 signal의 개념과 종류를 설명하고, 특히 서버 개발자가 주목해야 할 SIGTERM, SIGKILL, SIGINT 신호를 소개합니다. Eventloop에 signal handler를 추가하여 SIGTERM 신호를 받았을 때 현재 진행 중인 작업들을 안전하게 마무리하고 프로세스를 종료하는 응용 방법을 살펴봅니다. 이를 통해 서비스 중단 없이 안정적인 서버 운영을 위한 기반을 마련할 수 있습니다.
asyncioSIGTERMgraceful shutdown
버즈빌·2022년 5월 30일
Backend
asyncio 뽀개기 2 - Future의 활용
이 글은 Python의 비동기 프로그래밍 라이브러리인 asyncio의 핵심 컴포넌트 중 하나인 Future에 대해 다룹니다. Future는 비동기 연산의 결과를 저장하는 객체로, 동기 함수와 달리 비동기 함수 호출 시 즉시 반환 값을 얻을 수 없을 때 사용됩니다. Python에는 concurrent.futures.Future와 asyncio.Future 두 가지 클래스가 있으며, 이 글에서는 asyncio.Future를 중심으로 설명합니다. Future 객체를 직접 다루는 것은 권장되지 않지만, 비동기 프로그래밍의 중요한 개념이며 저수준에서 asyncio를 다룰 때 효율적인 코드 작성을 위해 필수적으로 이해해야 합니다. 글에서는 Future를 만드는 방법과 Callback을 등록하여 활용하는 방법 등을 살펴볼 예정입니다.
asyncioFuturePython
버즈빌·2022년 4월 4일
Backend
asyncio 뽀개기 1 - Coroutine과 Eventloop
이 글은 Python의 asyncio 라이브러리 핵심 컴포넌트인 Coroutine과 Eventloop에 대해 설명합니다. 10초마다 새로운 Job을 생성하고, 각 Job은 랜덤한 시간을 소요하며, Job들이 동시에 실행되는 요구사항을 가상의 시나리오로 정의하고 asyncio 모듈만을 사용하여 이를 구현하는 방법을 보여줍니다. Coroutine은 asyncio의 기본 실행 단위이며, Eventloop은 코루틴을 실행하는 핵심 역할을 합니다. 이 시리즈는 asyncio의 컴포넌트와 활용법을 소개하며, 최종적으로는 실제 프로덕션 환경에서 사용되는 graceful shutdown 구현을 목표로 합니다. Python 공식 문서의 async, await 기본 예제를 이해하는 독자를 대상으로 합니다.
asyncioPythonCoroutine
버즈빌·2022년 3월 30일
Backend
DynamoDB를 사용하는 Go 서비스의 응답 시간 최적화 #2 TLS Handshake
이 글은 Go 서비스에서 DynamoDB 사용 시 발생하는 응답 시간 지연 문제를 해결하기 위한 두 번째 시도에 대해 다룹니다. 이전 포스팅에서 AWS Credential Token 문제를 다룬 데 이어, 이번에는 TLS Handshake와 관련된 지연 이슈에 초점을 맞춥니다. 트래픽 증가로 인해 DynamoDB의 쿼리 응답 시간이 100ms 이상으로 길어지는 현상이 관찰되었으며, 이는 AWS SDK의 기본 설정으로는 해결하기 어려운 문제였습니다. 특히 Go AWS SDK는 Java SDK와 달리 타임아웃 설정 및 재시도 로직을 직접 구현해야 했습니다. 필자는 30ms 타임아웃과 최대 3회의 재시도를 포함하는 커스텀 로직을 구현하여 배포했으며, 이를 통해 DynamoDB 요청 처리 시간을 개선하려는 시도를 공유합니다. 비록 이 시도가 완벽한 해결책은 아니었지만, DynamoDB와 Go HTTP Client 사용 경험을 통해 얻은 교훈을 전달합니다.
DynamoDBGo응답 시간
버즈빌·2022년 3월 29일
Backend
DynamoDB를 사용하는 Go 서비스의 응답 시간 최적화 #1 AWS Credential Token
이 글은 Go 서비스에서 DynamoDB 요청의 응답 시간에 큰 영향을 미치는 AWS Credential Token 발급 로직을 찾아내고 최적화한 경험을 공유합니다. 버즈빌은 Write intensive 한 테이블에 DynamoDB를 사용하며, 특히 리워드 테이블은 낮은 응답 시간과 높은 처리량을 요구합니다. 로드 테스트 중 간헐적으로 발생하는 높은 응답 시간 문제를 해결하기 위해 Trace를 심어 원인을 분석했습니다. 분석 결과, Credential Token 발급 과정에서 지연이 발생함을 확인하고 이를 최적화하여 응답 시간을 개선했습니다. 이 과정에서 DynamoDB의 특성과 로드 테스트 도구인 Locust 활용법도 함께 다룹니다.
DynamoDBGoAWS Credential Token
버즈빌·2022년 3월 15일
Backend
HTTP connection pool in Go explained
이 글은 Go 언어에서 HTTP 클라이언트의 커넥션 풀 관리 방식을 분석하고 최적화하는 방법을 다룹니다. 버즈빌의 데이터 엔지니어가 DynamoDB 응답 시간 최적화 과정에서 HTTP 커넥션 관리에 집중하게 된 경험을 공유합니다. Go의 `net/http` 패키지에서 `http.Client`와 `http.Transport`의 역할을 설명하고, 특히 `http.Transport`가 커넥션 풀을 어떻게 관리하는지, 효과적인 사용을 위해 설정할 수 있는 파라미터는 무엇인지, 그리고 `http.Client` 내부 로직에 trace를 심는 방법까지 소개합니다. 이를 통해 Go 애플리케이션의 HTTP 통신 성능을 향상시키는 데 도움을 줄 수 있습니다.
GoHTTPconnection pool
버즈빌·2022년 3월 7일
Backend
Buzzvil Billing Data Pipeline
버즈빌 개발팀의 정기 기술 공유 세션인 'Buzzvil Tech Weekly'에서 발표된 'Buzzvil Billing Data Pipeline'에 대한 글입니다. 이 글은 버즈빌의 정산 데이터가 생성되는 과정을 다루며, 서버 개발자가 공유한 내용을 바탕으로 합니다. 매주 수요일마다 진행되는 이 세션은 팀원들이 각자의 노하우나 새로운 기술에 대해 논의하고 배우는 자리로, 이를 통해 업무 효율성과 창의성을 높이는 것을 목표로 합니다. 구체적인 파이프라인 구축 과정이나 사용된 기술 스택에 대한 상세한 내용은 슬라이드를 통해 확인할 수 있습니다.
데이터 파이프라인정산 데이터버즈빌
버즈빌·2022년 2월 4일
Backend
Exactly-Once in Apache Flink
버즈빌 개발팀의 주간 기술 공유 세션에서 Data Engineer Raf가 발표한 'Exactly-Once in Apache Flink' 내용을 다룹니다. 이 글은 Apache Flink가 데이터 처리 과정에서 Exactly-Once 의미론을 어떻게 보장하는지에 대한 기술적인 내용을 설명합니다. Exactly-Once는 데이터가 정확히 한 번만 처리되도록 보장하는 것으로, 분산 시스템에서 데이터 무결성을 유지하는 데 매우 중요합니다. Flink의 내부 메커니즘과 이를 통해 달성하는 장애 복구 및 일관성 유지 방법에 대한 발표 내용을 슬라이드를 통해 상세히 확인할 수 있습니다. 이는 스트림 처리 시스템 설계 및 운영에 있어 핵심적인 주제입니다.
Apache FlinkExactly-OnceData Engineering
버즈빌·2022년 1월 5일
Backend
버즈빌 백엔드 기술 스택을 소개합니다
버즈빌은 월 2천만 오디언스에게 최적화된 광고를 노출하는 애드테크 플랫폼으로, 트래픽과 데이터 증가에 대응하기 위해 수년간 모놀리식 서비스에서 수십 개의 마이크로서비스로 분리해왔습니다. 이 글은 버즈빌의 백엔드 기술 스택을 소개하며, 주로 Python과 Go 언어를 사용하며 각각 21개, 16개의 마이크로서비스가 운영 중입니다. Python은 Django 프레임워크를 주로 사용하며, Flask, FastAPI도 활용합니다. Go 언어는 gRPC 기반 서비스 개발에 활발히 사용되고 있으며, 최근 gRPC 기반 서비스 생성이 증가하는 추세입니다. 이처럼 복잡하고 대용량 트래픽을 처리하는 광고 시스템 운영을 위한 다양한 백엔드 기술 스택을 활용하고 있습니다.
PythonGo마이크로서비스
버즈빌·2021년 10월 30일
Backend
setup.py 멈춰!
이 글은 파이썬 패키징의 역사와 문제점을 짚어보고, 현대적인 패키징 방식을 소개합니다. 기존의 setup.py 방식은 대체재가 없고 build-time dependency 관리에 어려움이 있다는 문제점을 지적합니다. 특히 setup.py가 없으면 패키징이 불가능하고, setup.py 스크립트 실행 시 의존성 문제가 발생할 수 있음을 설명합니다. 해결책으로 PEP-518에 정의된 pyproject.toml 파일을 소개하며, 이 파일이 build-time dependency를 선언적으로 관리하고 다양한 도구에서 활용될 수 있음을 강조합니다. 이를 통해 파이썬 프로젝트의 배포와 공유를 더욱 효율적으로 만들 수 있는 방안을 제시합니다.
Python패키징setup.py
버즈빌·2021년 9월 13일
Backend
다시 만난 버그
주말에 발생한 클라이언트에서 서버로 전달하는 checksum 오류 문제를 다룬 글입니다. 컨텐츠 클릭 시 서버로 전달되는 checksum 값이 잘못 생성되어 파트너사에서 컨텐츠 랜딩이 되지 않는 심각한 문제가 발생했습니다. 서버에서 계산된 checksum 값과 클라이언트에서 계산된 값이 상이했으며, 특히 아랍어 컨텐츠나 아랍어 설정 기기에서 문제가 발생하는 것으로 파악되었습니다. 초기 가설이었던 컨텐츠 제목 인코딩 문제나 whitespace escaping 차이 문제는 배제되었고, checksum 생성 로직 디버깅을 통해 문제의 원인을 찾아 해결하는 과정을 상세히 설명합니다.
버그checksum디버깅
버즈빌·2020년 9월 18일
Backend
안드로이드 11의 "패키지 공개 상태" 변경 사항 정리
안드로이드 11부터 도입된 '패키지 공개 상태' 변경 사항을 설명하는 글입니다. targetSdkVersion이 안드로이드 11 이상인 앱은 기본적으로 다른 앱 목록을 알 수 없으며, `AndroidManifest.xml`의 `<queries>` 요소를 통해 명시적으로 쿼리할 패키지 이름이나 인텐트 필터 서명을 지정해야 합니다. 런처, 접근성, 브라우저 등 특정 앱은 `QUERY_ALL_PACKAGES` 권한을 통해 모든 앱을 쿼리할 수 있지만, 구글은 이 권한 사용을 제한할 것으로 예상됩니다. 이 변경 사항은 기존 안드로이드 앱에 영향을 줄 수 있으므로 개발자는 이에 대한 이해와 대비가 필요합니다.
안드로이드 11패키지 공개 상태AndroidManifest.xml
버즈빌·2020년 8월 5일