Polynomeer

메트릭, 로그, 트레이스 - 무엇을 어디에 남기고 카디널리티는 어디서 터지는가

Notes

관측성의 세 기둥을 “메트릭, 로그, 트레이스”로 외우는 것은 쉽고, 어느 것에 무엇을 남길지 정하는 것은 어렵다. 세 가지는 취향의 문제가 아니라 비용 구조가 다른 저장소다. 그 차이를 알면 “이 값을 메트릭 라벨로 넣을까 로그 필드로 넣을까”에 답할 수 있다. 셋을 가르는 축은 카디널리티다   답하는 질...

Common APM과 관측 가능성 1편

컨텍스트 스위칭과 스케줄링 - CFS, cgroup CPU 제한, 그리고 스로틀링

Notes

컨테이너에 cpus: 2를 주면 “CPU 2개를 쓴다”고 읽게 된다. 실제로는 100ms마다 200ms의 CPU 시간을 쓸 수 있다는 뜻이고, 그 차이가 p99(가장 느린 1% 요청의 지연)를 만든다. 스레드를 많이 만들면 느려진다는 것도 알지만 어디서 느려지는지는 설명하기 어렵다. 둘 다 리눅스 스케줄러의 동작에서 나온다. 컨텍스트 스위칭의 비...

OS

트랜잭션 전파 7종 - 각 옵션이 커넥션과 롤백에 남기는 결과

Notes

@Transactional(propagation = ...)의 일곱 값을 표로 외우는 것과, 그중 하나를 골랐을 때 커넥션이 몇 개 잡히고 예외가 어디까지 번지는지 아는 것은 다르다. 후자를 모르면 REQUIRES_NEW 하나로 커넥션 풀을 고갈시키거나, 잡아서 무시한 예외 때문에 바깥 트랜잭션이 통째로 롤백되는 일을 만난다. 일곱 가지가 답하는...

Spring

키 생성 병목을 추적해 구조를 바꾼 기록: Part 3 - 채번을 INSERT 시점으로 옮기고 범위 단위로 받기

실무 사례 Notes

1편에서는 계약 생성에 2분이 걸리고 동시 요청과 배치에서 대기가 커졌다는 증상과, 그 원인이 계약 코드를 받아 오는 SELECT next_seq('CONTRACT_CODE') 안의 시퀀스 증가라는 것을 적었다. 2편에서는 그 안의 UPDATE가 시퀀스 행에 X 락을 걸고, 그 락이 비즈니스 트랜잭션이 커밋할 때까지 풀리지 않아 동시에 들어온 요청과 ...

Common 키 생성 병목을 추적해 구조를 바꾼 기록 3편

격리 수준의 이상 현상을 직접 만들기 - 같은 REPEATABLE READ에서 PostgreSQL은 중단시키고 MySQL은 조용히 덮어썼다

실무 사례 Notes

격리 수준과 이상 현상에서 표준이 정의한 세 현상과 표준에 없는 둘(lost update, write skew)을 정리했다. 그 글은 문서를 근거로 썼고, 마지막에 “다음 세 가지는 직접 만들어야 보인다”를 적어 뒀다. 이 글이 그것을 만든 기록이다. 저장소는 data-ops-lab이고 재실행은 한 줄이다. ./.venv/bin/python exp...

Database

자바 메모리 모델 - happens-before, volatile, 그리고 final의 안전 공개

Notes

멀티스레드 버그를 “가시성 문제”라고 부르고 volatile을 붙여 고친 경험은 있는데, 왜 그게 고쳐지는지는 설명하지 못했다. 자바 메모리 모델(JMM)은 그 “왜”를 정의한 문서다. JSR-133이 정의했고, 언어 명세 17장에 들어 있다. 그 정의의 중심에 happens-before라는 관계 하나가 있다. 무엇이 문제인가: 코드 순서는 실행...

Java

monticker 초기 설계: 이벤트를 중심에 둔 첫 구조와 기술 선택

monticker는 주가 차트 위에 뉴스, 공시, 거래량 이상, 감성 신호를 시간순으로 올려서 “왜 움직였는가”를 보여 주려는 주식 관찰 앱이다. 이 글은 저장소를 처음 열 때 세운 설계를 정리한다. 무엇을 만들려 했는지, 구성 요소와 데이터 흐름, 기술마다 무엇과 비교해 골랐는지, 그리고 첫 커밋들이 실제로 만든 것과 아직 비어 있던 것을 차례로 적...

Architecture