Velopers
필터 1
963초짜리 쿼리 하나가 HLL 205만까지 끌어올렸습니다
아임웹
백엔드

963초짜리 쿼리 하나가 HLL 205만까지 끌어올렸습니다

Aurora MySQL에서 963초짜리 쿼리 하나가 HLL을 205만까지 끌어올린 원인을 분석했습니다. 긴 스냅샷을 짧은 청크 조회로 나눠 HLL 급증을 완화했습니다.

#Aurora MySQL#MySQL
4400
벡터DB를 걷어내고 유사글 추천 되살리기 — 임베딩 배치 Agent 개발기
데보션
AI

벡터DB를 걷어내고 유사글 추천 되살리기 — 임베딩 배치 Agent 개발기

벡터DB를 걷어낸 뒤 MySQL과 배치로 유사글 추천을 다시 구현했습니다. Gemini 임베딩과 운영 사고 대응까지 포함해 비용과 안정성을 함께 개선했습니다.

#MySQL#벡터DB
7700
AWS
백엔드

Amazon RDS for MySQL에서 Amazon Aurora Serverless v2로 전환한 메가MGC커피 모바일 주문 서비스 DB 현대화 사례

메가MGC커피가 RDS for MySQL을 Aurora Serverless v2로 전환해 오전 피크 트래픽 대응력을 높였습니다. 또한 Read Replica 기반 Cut-over와 ACU 조정으로 안정성과 비용 효율을 함께 확보했습니다.

#AWS#Amazon RDS
1200
Flava DBaaS 딥다이브: 아키텍처부터 마이그레이션, 그리고 미래까지
라인
데브옵스

Flava DBaaS 딥다이브: 아키텍처부터 마이그레이션, 그리고 미래까지

Flava DBaaS의 쿠버네티스 기반 아키텍처와 운영 구조를 소개했습니다. 또한 마이그레이션 도구와 서버리스, AI 기반 확장 방향까지 설명했습니다.

#Kubernetes#DBaaS
1900
광고 성과 데이터 StarRocks 도입기
라포랩스
백엔드

광고 성과 데이터 StarRocks 도입기

MySQL 기반 광고 성과 집계의 확장성과 안정성 문제를 해결하기 위해 StarRocks를 도입했습니다.\n외부 원천, MV 설계, 아키텍처 전환으로 부하 분리와 복구 편의성을 확보했습니다.

#Starrocks#MySQL
29400
[의존성의 방향을 따라 1/5] 버전업이 고통인 이유
flex
아키텍처

[의존성의 방향을 따라 1/5] 버전업이 고통인 이유

50개 레포와 3,500개 모듈에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제인지 설명했습니다. 수동 전파의 한계를 보여주고, 자동화된 recipe 기반 구조를 제안했습니다.

#Spring Boot#MySQL
13000
[의존성의 방향을 따라 1/5] 버전업이 고통인 이유
flex
아키텍처

[의존성의 방향을 따라 1/5] 버전업이 고통인 이유

50개 레포와 3,500개 모듈 환경에서 Spring Boot 패치 버전업이 왜 조직 전체의 문제가 되는지 설명했습니다. 수동 전파의 병목을 줄이기 위해 자동화와 빌드 검증 중심의 Evergreen 구조를 제안했습니다.

#Spring Boot#Kotlin
4600
여기어때
백엔드

Aurora MySQL의 숨겨진 idle close 동작 — HikariCP "Failed to validate connection" 추적기

Aurora MySQL에서 HikariCP의 idle connection 검증 실패 원인을 추적해 비표준 timeout 동작을 확인했습니다. interactive_timeout 이 keepalive 보다 작으면 비활성 연결이 먼저 끊길 수 있음을 정리했습니다.

#Aurora MySQL#HikariCP
5400
[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행
flex
아키텍처

[AI가 읽을 수 있는 코드베이스 3/5] Standalone App: 도메인 슬라이스 독립 실행

Issue 도메인을 독립 실행 가능한 standalone-app으로 조립해 핵심 로직만 빠르게 검증하는 구조를 소개했습니다. 프로덕션 Adapter만 교체하고 시드 데이터, Swagger, React 프론트엔드를 묶어 AI 협업 검증 환경을 만들었습니다.

#Hexagonal Architecture#Spring Boot
300
[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합
flex
아키텍처

[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합

테스트 인프라를 프로덕션 구조에 맞춰 variant와 스냅샷 캐시로 분리·재사용하는 방법을 정리했습니다. 경계를 깎아 교체 가능성을 만들면 CI와 개발 이터레이션이 함께 빨라졌습니다.

#MySQL#Kafka
12500
[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합
flex
데브옵스

[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합

테스트 인프라에서 variant와 스냅샷 캐시로 프로덕션의 분리를 그대로 재현하는 구조를 설명했습니다. 경계를 명확히 하면 교체 가능성이 높아지고 실험 속도도 빨라진다고 정리했습니다.

#Kotlin#MySQL
4400
MySQL 3분 vs ClickHouse 0.3초 — 같은 쿼리입니다
NHN
기타

MySQL 3분 vs ClickHouse 0.3초 — 같은 쿼리입니다

X

#MySQL#ClickHouse
33400
[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다
flex
아키텍처

[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다

MSA 환경에서 전체 시스템을 띄우지 않고 수정 중인 서비스만 로컬로 교체하는 Rewrite Host를 소개했습니다. 디버그 헤더로 라우팅을 바꾸고, 응답 헤더로 적용 여부를 알려주는 방식입니다.

#MSA#Spring Cloud Gateway
3000
아임웹
백엔드

MySQL Online DDL의 메타데이터 잠금: pt-osc와 무엇이 다른가

MySQL Online DDL과 pt-osc의 메타데이터 잠금 차이를 비교했습니다. 바쁜 테이블은 pt-osc, 일반 변경은 INSTANT/INPLACE를 우선 검토하는 기준을 제시했습니다.

#MySQL#MDL
400