Memory DB는 무엇으로 가득 차 있었을까 - 2부 : BCAST 전환과 Failover
유령 키로 누적되는 MemoryDB OPTIN tracking item 문제를 BCAST 전환으로 구조적으로 차단했습니다. 리허설 후 failover를 두 차례 수행해 7,684만 개 항목과 메모리 사용률을 정상화했습니다.
#MemoryDB#Redis#cache
300
모든 블로그
대표 인기 포스트버즈빌 프론트엔드 변천사143 조회143 조회 백엔드 백엔드
백엔드
백엔드
백엔드
백엔드
백엔드 백엔드
백엔드 백엔드
백엔드
백엔드 백엔드
백엔드
백엔드
백엔드
백엔드
백엔드
버즈빌
주요 카테고리 백엔드 · DevOps
활동 요약
- 최근 30일
- 2개
- 평균 조회
- 18
- 누적 조회
- 2,197
- 전체 글
- 125개
- 마지막 발행
- 2026. 11. 3.
버즈빌 기술 블로그 글 (42)
Go embed: 최소 변경으로 불필요한 메모리 사용 줄이기
GeoIP DB를 embed.FS.ReadFile로 읽으며 발생한 전체 DB heap 복사 원인을 분석했습니다.직접 []byte embed 방식으로 배포 구조를 유지하면서 보유 heap을 줄였습니다.
#Go#GeoIP#Pyroscope
300
Memory DB는 무엇으로 가득 차 있었을까 - 1부 : 클라이언트 캐싱과 tracking item
MemoryDB 메모리 급증의 원인을 Redis 클라이언트 캐싱 tracking item 누적으로 분석했습니다. 존재하지 않는 유령 키 조회가 TTL 없이 기록을 쌓는 구조를 확인했습니다.
#MemoryDB#Redis#클라이언트 캐싱
300
피크 타임 Pod 245개를 100여개로 — DynamoDB SDK v2 전환으로 Go 서버 CPU 절반 줄이기
Pyroscope로 DynamoDB 응답 역직렬화의 CPU 병목을 확인하고 AWS SDK v2 기반 래퍼로 전환했습니다. 요청당 CPU를 59% 줄여 피크 타임 HPA 파드를 245개에서 109개로 낮췄습니다.
#Go#DynamoDB#AWS SDK
100
Feature Flag API의 p99 레이턴시 개선기 (+오픈소스 기여)
S3 export 중 mutex를 잡아 Feature Flag API p99가 급등한 원인을 분석했습니다. 비동기 래퍼와 락 범위 축소로 최대 레이턴시를 200ms 내외로 안정화했습니다.
#Go#Feature Flag#S3
000
DynamoDB Limit 설정으로 RCU 97% 절감한 이야기
DynamoDB Query의 무제한 스캔과 Strong Consistent Read로 급증한 RCU 원인을 분석했습니다. SearchLimit과 Eventually Consistent Read 적용으로 RCU를 최대 97% 절감했습니다.
#DynamoDB#Go#AWS
300
DynamoDB Limit 설정으로 RCU 97% 절감한 이야기
DynamoDB 조회에서 Limit 미설정과 Strong Consistent Read가 RCU 급증의 원인이었습니다. SearchLimit 적용과 일관성 수준 조정으로 RCU를 최대 97% 절감했습니다.
#DynamoDB#RCU#Limit
8900
5대 금융사를 품은 버즈베네핏의 백엔드 팀은 무슨 일을 할까요?
게이미피케이션 확장에 맞춰 Kafka CDC와 Argo Workflow 기반의 데이터·랭킹 파이프라인을 구축했습니다. 모니터링과 Feature Flag로 대규모 트래픽 운영 및 제한적 기능 실험을 지원합니다.
#Go#Kafka#CDC
100
5대 금융사를 품은 버즈베네핏의 백엔드 팀은 무슨 일을 할까요?
버즈베네핏 백엔드 팀이 데이터 중심 설계와 확장 가능한 파이프라인, 모니터링 체계를 어떻게 구축했는지 소개했습니다. Feature Flag와 실험 지원으로 제품 검증 속도를 높인 사례도 함께 다뤘습니다.
#Golang#Python#Kafka
9600
데이터 엔지니어의 Airflow 데이터 파이프라인 CI 테스트 개선기
데이터 파이프라인 CI 테스트 시간을 7분대에서 3분대로 줄인 개선 사례를 다뤘습니다. YAML 작성부터 PR, 배포까지의 흐름 속 병목을 줄이는 방법을 소개했습니다.
#Airflow#CI/CD#YAML
2600
Ad Management 파트 서버 개발자의 지역 타게팅 개선기
ES5 패킷 제한을 넘던 지역 좌표 데이터를 convex hull로 압축했습니다. 저장 공간을 94.7% 줄이고 오차율을 검증해 지역 타게팅에 적용했습니다.
#Elasticsearch#Python#Shapely
100
Ad Management 파트 서버 개발자의 지역 타게팅 개선기
Ad Management 파트에서 서버 개발자가 지역 타게팅 개선 경험을 소개했습니다. 2주 스프린트 기반의 팀 운영 방식과 함께 과제 배경을 간단히 설명했습니다.
#server#agile#스프린트
1800
RDS MySQL IOPS 장애 대응기
RDS MySQL의 gp2 Burst Balance 소진으로 발생한 IOPS 장애를 분석했습니다. 메모리 스케일업으로 working set을 확보해 Read IOPS를 크게 낮췄습니다.
#AWS#RDS#MySQL
100
RDS MySQL IOPS 장애 대응기
AWS RDS MySQL 운영 중 메모리 문제로 장애가 발생한 사례를 소개했습니다. 높은 트래픽 환경에서의 원인과 해결 과정을 다루는 글입니다.
#AWS#RDS#MySQL
2100
Self Serving Data Platform 구축하기 (feat. Airflow)
셀프 서빙 데이터 플랫폼을 구축한 사례를 소개했습니다. Airflow를 활용해 데이터 파이프라인 운영 부담을 줄이는 방향을 다뤘습니다.
#Airflow#ETL#pipeline
3100
광고 예산 제어 시스템 개선기: Part 2 – 더 정교한 시스템, 그리고 성과
광고 예산 제어 시스템을 더 정교하게 개선한 사례와 그 성과를 소개했습니다. 예산을 더 자주, 더 세밀하게 통제하는 방향으로 문제를 풀었습니다.
#system#traffic
3200
광고 예산 제어 시스템 개선기: Part 1 – 시스템과 가시성 개선
광고 플랫폼의 예산 제어 시스템을 개선하는 연재의 첫 글입니다. 캠페인 예산을 안정적으로 분배하지 못하면 조기 소진과 지출 스파이크가 발생할 수 있음을 다뤘습니다.
#system#모니터링#traffic
3100
엘라스틱서치를 활용한 수평 확장 가능한 광고 서버 만들기
복잡한 광고 타게팅 조회를 MySQL 조인에서 Elasticsearch inverted index 검색으로 전환했습니다. 단일 샤드·자동 레플리카 확장 구성으로 낮은 지연과 수평 확장을 확보했습니다.
#Elasticsearch#MySQL#광고 서버
400