thisisnew (매일 코딩, 매일 독서)

Redis를 업그레이드하는 동안 잠깐 master가 내려가고 replica가 새 master로 승격되는 일은 있을 수 있다. Sentinel이나 Cluster를 쓰고 있다면 애플리케이션 입장에서는 “클라이언트가 알아서 새 master를 따라가겠지”라고 기대하게 된다.그런데 운영에서는 가끔 이상한 일이 생긴다. 일반 Redis 명령은 어느 정도 복구되는 것 같은데, Lua script를 실행하는 경로에서만 READONLY You can't write against a read only replica 같은 에러가 몇 분 동안 튀어나오는 상황이다.처음 들으면 이상하다. Lua도 결국 Lettuce로 Redis에 보내는 것 아닌가. 맞다. 전송은 Lettuce를 탄다. 다만 여기서 중요한 건 “Lettuce를 ..

Development/Redis 2026. 9. 10. 20:52

카프카를 처음 쓸 때 가장 쉽게 놓치는 부분이 메시지 순서다. “카프카는 순서를 보장한다”는 말을 들으면 topic에 들어간 메시지가 전체적으로 하나의 줄처럼 처리된다고 생각하기 쉽다. 그런데 실제로는 그렇게 보면 안 된다.카프카의 순서 보장은 topic 전체가 아니라 partition 안에서의 이야기다. topic에 partition이 여러 개라면, 각 partition은 자기 안에서만 순서가 있다. partition 사이에는 전역 순서가 없다. 이 차이를 모르고 설계하면 주문 상태 변경, 포인트 적립, 알림 발송, 재고 차감 같은 흐름에서 이상한 결과가 나올 수 있다.partition은 각각 따로 움직이는 로그다Kafka topic은 여러 partition으로 나뉠 수 있다. 각 partition은 ..

Development/Kafka 2026. 9. 10. 20:45

카프카를 쓰다 보면 consumer lag보다 먼저 눈에 들어오는 단어가 있다. 리밸런싱이다. 로그에는 Rebalance in progress, Revoking previously assigned partitions, Successfully joined group 같은 메시지가 찍히고, 그 사이에 처리가 잠깐 멈춘 것처럼 보인다.처음에는 리밸런싱을 장애처럼 느끼기 쉽다. 그런데 리밸런싱 자체는 이상한 일이 아니다. consumer group 안에서 “어떤 consumer가 어떤 partition을 읽을지” 다시 정하는 정상적인 과정이다. 문제는 리밸런싱이 너무 자주 일어나거나, 한 번 일어날 때 너무 오래 걸리거나, 매번 너무 많은 partition을 옮기는 구조다.파티션은 한 그룹 안에서 한 consu..

Development/Kafka 2026. 9. 9. 19:50

MySQL 락을 볼 때 처음에는 “어떤 row가 잠겼는가”만 생각하기 쉽다. 그런데 InnoDB를 쓰다 보면 이 감각만으로는 설명이 안 되는 순간이 나온다. 서로 다른 데이터를 만지는 것 같은데 INSERT가 기다리고, 단순한 UPDATE 하나가 생각보다 넓은 범위를 붙잡고, 데드락 로그에는 내가 의식하지 못한 인덱스 이름이 나온다.이때부터는 MySQL 락을 row 하나의 문제로만 보면 안 된다. InnoDB의 row-level lock은 실제로 인덱스 레코드를 따라 걸린다. 그리고 조건에 따라 레코드 앞뒤의 빈 공간, 즉 gap까지 같이 잠길 수 있다.일반 SELECT는 보통 락을 기다리지 않는다먼저 읽기부터 분리해서 봐야 한다. InnoDB는 MVCC 기반으로 동작하고, 일반적인 SELECT는 기본적..

Development/Database 2026. 9. 3. 18:24

JWT를 쓰다 보면 한 번쯤 이런 질문을 하게 된다. “토큰이 탈취되면 어떻게 하지?” 처음에는 서명을 잘 검증하면 괜찮은 줄 알았다. 그런데 서명 검증은 “이 토큰이 내가 발급한 게 맞는가”를 확인하는 장치이지, “이 토큰을 지금 들고 온 사람이 원래 사용자 맞는가”를 보장하는 장치는 아니다.JWT access token은 보통 bearer token이다. 말 그대로 들고 있는 사람이 쓸 수 있다. 그래서 토큰이 한 번 새면, 만료되기 전까지는 공격자도 정상 사용자처럼 API를 호출할 수 있다. 여기서 중요한 건 탈취 가능성을 0으로 만들겠다는 생각보다, 탈취됐을 때 피해 범위를 얼마나 줄일 수 있느냐다.JWT는 서버가 기억하지 않는다는 장점 때문에 회수가 어렵다JWT를 쓰는 이유 중 하나는 서버가 매..

Development/JWT 2026. 9. 2. 18:51

분산락을 보다 보면 자연스럽게 다시 DB 락으로 돌아오게 된다. 결국 많은 동시성 문제는 데이터베이스 안의 한 줄, 혹은 특정 조건을 만족하는 데이터 묶음에서 터진다. Redis나 etcd 같은 외부 락을 쓰기 전에 DB가 이미 어떤 락을 걸고 있는지부터 알아야 한다.처음에는 DB 락을 “성능을 느리게 만드는 것” 정도로만 생각하기 쉽다. 그런데 실제로는 조금 다르다. DB 락은 정합성을 지키기 위해 일부 요청을 기다리게 만드는 장치다. 문제는 락이 있다는 사실이 아니라, 내가 어떤 범위를 얼마나 오래 잠그고 있는지 모른다는 데서 자주 생긴다.읽기는 항상 막히는 게 아니다먼저 헷갈리는 부분부터 정리해야 한다. 트랜잭션이 있다고 해서 모든 읽기와 쓰기가 서로 막히는 건 아니다. PostgreSQL과 Inn..

Development/Database 2026. 9. 1. 18:56

분산락을 처음 공부하면 자연스럽게 Redis, Redlock, ZooKeeper, etcd 같은 도구부터 보게 된다. 나도 처음에는 그랬다. “어떤 락 라이브러리를 쓰면 안전할까?”가 먼저 떠올랐다.그런데 조금 더 생각해보면 질문을 바꿔야 할 때가 많다. “어떤 분산락을 쓸까?”보다 “이 작업이 정말 락을 필요로 하는 구조인가?”를 먼저 봐야 한다. 락은 문제를 해결해주기도 하지만, 동시에 새로운 실패 지점을 하나 더 추가한다.락은 동시성을 없애는 도구가 아니라 위험을 미루는 도구다분산락은 여러 서버 중 하나만 특정 작업을 하게 만드는 장치다. 여기까지만 보면 꽤 깔끔하다. 하지만 실제 시스템에서는 락을 잡은 서버가 멈출 수 있고, 네트워크가 늦어질 수 있고, 락 TTL이 먼저 끝날 수 있다. 그러면 예..

Development/Redis 2026. 8. 31. 18:25

요즘 분산락이라는 주제가 자꾸 눈에 밟혔다. 처음에는 “동시에 실행되면 안 되는 코드에 락 하나 걸면 되는 거 아닌가?” 정도로 생각했는데, 자료를 조금 더 찾아보니 생각보다 단순한 문제가 아니었다.특히 서버가 여러 대로 늘어나고, 배치 작업이나 쿠폰 발급, 재고 차감, 결제 후처리 같은 작업이 여러 인스턴스에서 동시에 돌기 시작하면 락은 꽤 현실적인 문제가 된다. 그런데 여기서 중요한 건 “락을 걸 수 있느냐”보다 “락이 실패했을 때 어떤 일이 생기느냐”였다.분산락이 필요한 순간분산락은 여러 프로세스나 여러 서버가 같은 자원에 동시에 접근하지 못하게 막는 장치다. 단일 서버 안에서는 언어의 mutex나 synchronized 같은 걸 쓰면 되지만, 서버가 여러 대면 메모리를 공유하지 않으니 외부 시스템..

Development/Redis 2026. 8. 30. 22:03