일관성 모델 - 선형화, 순차, 최종 일관성, 그리고 CAP를 설정값의 언어로 Notes “강한 일관성”과 “최종 일관성” 두 단어로 분산 시스템의 일관성을 이야기하면, 정작 설정 파일 앞에서 막힌다. Kafka의 acks, PostgreSQL의 synchronous_commit, MongoDB의 writeConcern·readConcern은 전부 일관성 모델을 값으로 고르는 자리인데, 두 단어짜리 어휘로는 그 값을 고를 수 없다. 이 글... 2026/01/12 Notes, Architecture
SLASH 21 리뷰 - SRE 사례 소개: Redis 리밸런싱 ASK 에러, Memcached 재분배 실패, Prometheus가 바꾼 GC 패턴 Conference 발표 SLASH 21 연사 조규희 (토스 서버 플랫폼팀, Site Reliability Engineer) 자료 발표 영상 · SLASH 21 토스 서버 플랫폼팀이 운영 중에 겪은 문제 세 ... 2026/01/09 Conference, Toss 토스 커뮤니티 백엔드 발표 리뷰 2편
격리 수준과 이상 현상 - 표준이 정의한 것과 MySQL·PostgreSQL이 실제로 하는 것 Notes 격리 수준을 “READ COMMITTED는 커밋된 것만 읽는다” 정도로 외우고 있으면, 실무에서 만나는 질문에 답할 수 없다. 같은 REPEATABLE READ인데 MySQL에서는 팬텀이 안 보이고 PostgreSQL에서는 갱신이 실패하며, 두 DB 모두 표준을 지키고 있다. 표준이 무엇을 정의했고 무엇을 정의하지 않았는지를 나누면 이 차이가 설명된다... 2026/01/06 Notes, Database
키 생성 병목을 추적해 구조를 바꾼 기록: Part 1 - INSERT가 느린 줄 알았다 Notes Part 1. INSERT가 느린 줄 알았다 – 2분짜리 배치의 착각 2분 걸리던 배치에서 대부분의 시간은 INSERT 구간에 찍혀 있었다. 그래서 INSERT를 튜닝했지만, 실행 시간은 약 1분 30초까지만 줄었다. 이 글은 그 차이를 보고 병목의 위치를 다시 찾기 시작한 과정이다. 1. 문제 상황: “실패하지 않지만, 너무 느린 배치... 2026/01/03 Notes, Common 키 생성 병목을 추적해 구조를 바꾼 기록 1편
대량 배치 안정성을 높이기 위한 구조 개선: Part 1 - 시스템을 압박하기 시작한 배치 Notes 1편. 대량 배치 작업이 시스템을 압박하기 시작했을 때 구조의 한계를 사람이 먼저 느꼈다 서비스가 성장하면서 데이터는 자연스럽게 누적된다. 문제는 기존 구조가 언제부터 한계에 도달했는지를 시스템이 아니라 사람이 먼저 체감한다는 점이다. 이번 글에서는 실행 시점마다 수십만 건 이상의 데이터를 처리해야 하는 배치 작업이 어떻게 시스템 전체의 안정성을... 2026/01/03 Notes, Common 대량 배치 안정성을 높이기 위한 구조 개선 1편
대량 배치 안정성을 높이기 위한 구조 개선: Part 2 - 전체 삭제 후 전체 등록 구조의 위험성 Notes 2편. 전체 삭제 → 전체 등록 구조의 위험성 들어가며 1편에서 살펴본 것처럼, 대량 데이터를 처리하는 배치 작업은 어느 순간부터 “느리다”는 문제를 넘어 “위험하다”는 영역으로 들어섰다. 이번 글에서는 그 원인이 되었던 “전체 삭제 → 전체 등록” 구조가 왜 대규모 환경에서 위험한 선택이 되는지, 그리고 어떤 관점으로 개선 목표를 설정했는지를 ... 2026/01/03 Notes, Common 대량 배치 안정성을 높이기 위한 구조 개선 2편
대량 배치 안정성을 높이기 위한 구조 개선: Part 3 - 청크 분할과 병렬 처리로 재설계하기 Notes 3편. 청크 분할과 병렬 처리로 배치 구조 재설계하기 들어가며 앞선 두 편(1편, 2편)에서 문제를 다뤘다면, 이번 글은 그래서 어떻게 바꿨는가에 대한 이야기다. 개선의 출발점은 2편에서 정한 원칙, 모든 데이터를 한 번에 처리하지 않는다는 것이었다. 이 원칙을 실제 시스템 구조로 옮기는 과정에서 가장 먼저 손을 댄 것이 청크 분할과 병렬 처리였... 2026/01/03 Notes, Common 대량 배치 안정성을 높이기 위한 구조 개선 3편
대량 배치 안정성을 높이기 위한 구조 개선: Part 4 - 분산 락이 있어도 레이스가 발생한 이유 Notes 4편. 분산 락이 있음에도 Race Condition이 발생한 이유 들어가며 3편의 청크 분할과 병렬 처리로 배치 성능은 크게 개선됐다. 처리 시간은 줄었고, 시스템 부하도 안정적으로 관리되기 시작했다. 그런데 예상하지 못한 문제가 남아 있었다. 락을 사용하고 있는데도 작업 순서가 깨지고 있었다. 이번 글에서는 분산 락이 있었는데도 Race C... 2026/01/03 Notes, Common 대량 배치 안정성을 높이기 위한 구조 개선 4편
대량 배치 안정성을 높이기 위한 구조 개선: Part 5 - 배타적 락과 조건부 해제로 순서를 보장하기 Notes 5편. 배타적 락과 조건부 해제로 순서를 보장하기 앞선 글에서 확인한 문제는 단순했다. 락을 쓰고 있었지만, 락의 생명주기와 실제 작업 생명주기가 일치하지 않았다. 결국 필요한 것은 “락이 존재하느냐”가 아니라 누가 락을 가졌는지, 그리고 그 락을 누가 해제할 수 있는지를 분명하게 만드는 구조였다. 왜 단순한 SET / DEL 패턴으로는 부족했나 ... 2026/01/03 Notes, Common 대량 배치 안정성을 높이기 위한 구조 개선 5편
카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다 Tech Blog Review 원문: MySQL ALTER DDL 수행 방식에 대한 이해 — kakao tech, 2025-05-14 한 줄 요약 MySQL의 ALTER는 세 알고리즘으로 돈다. Copy(새 테이블에 전부 복사, 쓰기 차단), In-Place(5.6+, 임시 구조와 DML 로그로 읽기·쓰기 허용, 필요 시 리빌드), Instant(8.0+, 메타데이터만 수정)다... 2025/12/30 TechBlog, Kakao 빅테크 기술 블로그 리뷰 17편