만들고, 고치고, 배우는 것들을 짧은 글로 남길려고 합니다.
10
Redis를 그냥 '빠른 캐시'로 보면 편하지만, Cache Aside·TTL·캐시 만료 동시성, Negative Caching, 메모리 정책, 복구 방식, 복잡해지는 분산 락 등 쓰면서 맞닥뜨리는 여러 문제를 함께 고려해야 하는 것이 핵심 주제입니다. 글은 DB로 해결할 수 있는 부분은 DB에 맡기고, Redis를 도입할 때는 얻는 이득과 새로 생길 비용을 현실적으로 따져야 한다고 조용히 짚어준다.
멀티스레드에서 변수 접근을 다루며 volatile, synchronized, AtomicInteger가 각각 무엇을 보장하고 어떤 한계가 있는지를 짚습니다. volatile은 가시성·순서만, synchronized는 상호 배제로 복합 연산을 보호하고, AtomicInteger는 CAS로 원자적 증감만 제공하니 문제의 성격(가시성인지 원자성인지)을 먼저 가려야 합니다.
서비스는 처음엔 한 대의 서버와 DB로 시작하지만, 트래픽과 요구가 커지며 세션 공유, 캐시 일관성, 읽기/쓰기 분산, 트랜잭션 일관성, 서비스 간 결합도 같은 현실적 문제를 해결하려다 보니 Redis, Replica, Sharding, Kafka 같은 구성으로 자연스럽게 복잡해진다. 이런 변화들은 기술 이름을 외우기보다 "무슨 문제가 생겼고 그걸 왜 이렇게 풀었나"를 이해하는 게 핵심이라는, 약간 골치 아프지만 당연한 결론으로 이어진다.
주문을 DB에 저장한 뒤 곧바로 Kafka에 이벤트를 발행할 때 서버가 죽으면 DB에는 남고 Kafka에는 전달되지 않는 문제가 생기는데, 이는 DB와 Kafka가 같은 트랜잭션으로 묶일 수 없기 때문입니다. Outbox 패턴은 같은 DB 트랜잭션 안에 이벤트를 기록해 별도 Publisher가 나중에 Kafka로 발행하게 함으로써 이벤트 유실을 줄이되, 중복 처리(멱등성)는 여전히 고려해야 한다는 현실적인 해결책을 제시합니다.
가비아에서 받은 인증서 파일을 윈도우 환경의 nginx에 맞게 cert.pem, chain.pem, privkey.pem으로 정리하고 fullchain.pem을 만들어 교체하는 과정을 정리한 글입니다. 백업을 먼저 하고 nginx 설정 검사를 한 뒤(권한 문제로 reload 대신) 재시작해 브라우저와 스크립트로 새 인증서가 반영되었는지 확인한 것이 핵심입니다.
객체지향책을 다시 읽으면서 깨달은 건, 좋은 설계란 단순히 클래스를 예쁘게 나누는 게 아니라 변경이 생겼을 때 덜 흔들리는 구조를 만드는 일이라는 점이다. 그래서 이제는 데이터보다 먼저 객체들이 어떤 행동을 하고 어떤 책임을 질지, 메시지는 어떻게 오갈지를 고민해 변경이 퍼지는 방향을 좁히는 쪽으로 설계하려 한다.
측정 데이터 목록 조회에서 최신 20건만 필요함에도 조인 순서 때문에 수집 로그 테이블에서 불필요한 읽기가 많이 발생하고 있었다는 문제를 STATISTICS IO/TIME으로 확인했습니다. 인덱스를 넣어 측정 테이블 읽기를 줄이고, 결국 먼저 20건을 뽑아서 그 결과만 로그와 대상자 테이블에 조인하는 구조로 바꿔 전체 logical reads를 약 98% 줄였습니다.
