Hibernate의 connection release mode는 JDBC 커넥션을 언제 획득하고 언제 풀에 반환할지를 결정하는 전략이다. 이 설정은 단독으로 동작하는 것이 아니라, Spring의 @Transactional 전파 전략과 맞물려서 실제 커넥션 생명주기를 결정한다. 이 글에서는 Spring Boot + JPA 환경에서 커넥션이 풀에서 빠져나가고 돌아오는 과정을 코드 레벨까지 확인한다.1. Connection Release Mode란?1. Hibernate의 5가지 커넥션 획득/반환 모드Hibernate의 커넥션 관리 전략은 PhysicalConnectionHandlingMode라는 enum으로 정의된다. 이 enum은 두 가지 축의 조합으로 구성된다. 획득 시점 (Connection Acqui..

Redis Cluster를 사용하면서 Lettuce 클라이언트의 Topology Refresh 설정을 빠뜨리는 경우가 생각보다 많다. 이번 글에서는 Redis Cluster에서 클라이언트가 어떻게 올바른 노드를 찾아가는지, 토폴로지가 outdated되면 어떤 장애가 발생하는지, 그리고 Lettuce가 제공하는 두 가지 갱신 전략의 동작 원리를 알아본다.1. Redis Cluster 슬롯 구조 및 클라이언트 동작1. 해시 슬롯 기반 분산 구조Redis Cluster는 전체 키 공간을 16,384개의 해시 슬롯(0~16383)으로 나누고, 각 Primary 노드가 이 슬롯의 일부를 담당한다.클라이언트가 특정 키에 대한 명령을 보내면, CRC16(Key) % 16384 연산으로 슬롯 번호를 결정하고, 해당 슬..

분산 시스템을 공부하면 반드시 만나게 되는 이론이 있다. 바로 CAP 정리다. "Consistency, Availability, Partition Tolerance" 중 두 가지만 선택할 수 있다"는 문장은 개발자라면 한 번쯤 들어봤을 것이다. 그런데 이 문장 자체가 오해를 품고 있다.이번 글에서는 CAP 정리의 이론적 배경부터 세 가지 속성의 정확한 정의, 추측에서 형식적 증명까지의 맥락, 그리고 실제 분산 시스템(ZooKeeper, Cassandra, Redis Cluster, Aurora DB)에서의 구현 방식과 후속 모델인 PACELC까지 정리한다.1. C, A, P — 각 속성의 정확한 정의CAP에 대한 오해는 대부분 세 속성의 정의를 부정확하게 이해하는 데서 시작된다. 하나씩 명확하게 알아보자..

웹 개발자라면 HTTP를 매일 사용한다. 하지만 "HTTP/2가 HTTP/1.1보다 빠르다" 수준의 이해에 머물러 있다면, 각 버전이 왜 등장했고 어떤 문제를 해결했는지를 놓치고 있는 것이다. 이 글에서는 HTTP/1.1 → HTTP/2 → HTTP/3로 이어지는 진화의 맥락을 짚고, 각 버전의 커넥션 관리, 멀티플렉싱, 헤더 압축, 전송 계층, 한계점을 깊이 있게 비교한다.1. HTTP/1.0 — 초기 문제점HTTP/1.0은 요청 하나를 보내고 응답을 받으면 TCP 커넥션(Connection)을 즉시 닫는다.단순하지만, 현실의 웹에서는 치명적이다.브라우저가 웹페이지 하나를 로드할 때 필요한 것은 HTML 파일 하나가 아니다.HTML 안에 포함된 CSS, JavaScript, 이미지, 폰트, API 응답..

실무나 사이드프로젝트를 하면 항상 만나게 되는 에러가 있는데 바로 CORS이다.자주 보는 CORS 에러지만 우리가 제대로 이해하고 해결하고 있는지는 곰곰히 생각해보자. 프로젝트를 진행하면서 CORS 에러를 만나면 "Access-Control-Allow-Origin: *" 을 추가하고 넘어가곤 했다.모놀리식에서는 그걸로 충분할 수 있지만, MSA 환경에서는 이 접근이 보안 취약점이 되거나 운영상 큰 장애 요인이 될 수 있다.이번 글에서 CORS의 동작 원리를 정확히 이해하고, MSA에서 CORS를 어느 계층에서 어떻게 관리할 수 있는지 설계 관점까지 알아보고자 한다.1. Same-Origin Policy — 왜 브라우저는 Cross-Origin 요청을 막을까?1. 브라우저를 악용하는 공격하나의 시나리오를 ..

개요TCP/IP 프로토콜 스택에서 체크섬(Checksum) 은 데이터가 전송 과정에서 손상되지 않았는지 검증하는 오류 검출 메커니즘이다.오늘날 인터넷의 모든 패킷은 이 체크섬을 거쳐 전송된다. 체크섬은 TCP/IP 스택의 여러 계층에서 동작하며, 각 계층의 체크섬은 보호 범위와 목적이 다르다.이번 정리에서는 체크섬의 내부 동작 원리를 세 계층으로 나누어 정리한다.L2 데이터 링크 계층의 Ethernet CRC (32bit)L3 네트워크 계층의 IP Header Checksum (16bit)L4 전송 계층의 TCP/UDP Checksum (16bit)1. 기반 원리 - 1의 보수 연산과 설계 배경checksum에 대해 들어가기 전에 bit 세계에서 역수를 취하기 위한 보수 방법 2가지에 대해 알아보자.1의..

서로 다른 관심사동기/비동기와 블로킹/논블로킹은 흔히 혼용되지만, 실제로는 서로 다른 관심사를 다루는 별개의 축이다. 이 구분을 명확히 하는것이 모든 논의의 바탕이 되므로 명확히 짚어보자. 동기(Synchronous) vs 비동기(Asynchronous) 작업 완료를 누가 확인하는가?동기(Synchronous)호출자(Caller)가 직접 작업의 완료 여부를 확인하거나 기다린다. 결과를 호출자가 내놓으라고 끌어오는 Pull 방식이다.비동기(Asynchronous)피호출자(Callee)가 작업이 완료되면 호출자에게 알려준다. 콜백(callback), 이벤트(event) 등을 통해 결과를 내보내는 Push 방식이다.즉, 동기/비동기의 핵심은 완료 통지의 주체가 누구인가이다.블로킹 (Blocking) vs 논블..

들어가며트랜잭션 격리 수준(Transaction Isolation Level)은 동시에 실행되는 트랜잭션 사이에서 데이터의 일관성을 어디까지 보장할지를 결정하는 설정이다. 격리 수준이 높을수록 일관성은 강해지지만 동시성은 떨어지고, 낮을수록 동시성은 좋지만 이상현상(anomaly)에 노출될 수 있다. 대부분의 개발자가 REPEATABLE READ, READ COMMITTED 같은 격리 수준 이름을 알고 있다.그런데 ANSI SQL-92 표준이 정의한 REPEATABLE READ와 MySQL InnoDB가 실제로 제공하는 REPEATABLE READ는 같은 수준의 격리를 보장할까? 결론부터 말하면, 같은 이름이지만 보장하는 범위가 다르다. 이 글에서는 ANSI SQL-92 (이하 ANSI SQL) 표준의 ..

ACIDACID의 의미부터 확인하자.ACID 자체의 의미RDBMS 단일 트랜잭션을 기준으로Atomicity (원자성)Consistency (일관성)Isolation (격리성)Durability (지속성)위 4가지 속성이 하나의 DB 커넥션 안에서 트랜잭션을 통해 보장되는 것을 말한다.사실 데이터베이스 관점에서 트랜잭션을 정의하는 속성이므로 ACID 트랜잭션이라 말하는게 맞다.MSA에서 ACID가 깨지는 이유MSA의 본질은 서비스별로 독립된 데이터를 가지는 것이다. 이로인해 단일 DB 트랜잭션으로 여러 서비스의 데이터 정합성을 보장하는 것이 원칙적으로 불가능해진다.ACID의 4가지 속성 모두가 서비스의 경계를 넘는 순간 보장할 수 없게 된다.ACID 각 속성이 어떻게 깨지는가Atomicity모놀리식에서는 ..

개요객체지향의 핵심은 구현과 역할을 분리하는 것이다.객체에게 역할을 부여하고, 그 역할에 따라 책임을 할당하며, 객체 간 협력을 통해 시스템이 동작한다. 그렇다면 객체지향에서 좋은 설계와 아키텍처란 무엇일까?바로 SOLID 원칙이다.SOLID는 좋은 설계를 얻기 위해 지켜야 할 규범이며, 이 원칙들은 소프트웨어의 유지보수성과 확장성을 높이기 위한 것이다.유지보수성무엇이 유지보수성을 높이는 것일까? 가독성?가독성은 사람마다 다르며, 좋지 못한 코드가 오히려 가독성이 더 좋을 수도 있다. 가독성은 유지보수성의 명확한 기준이 되지 못한다. 유지보수성을 높이는 명확한 기준은 다음 세 가지이다.영향 범위 — 코드 변경으로 인한 영향 범위가 어떻게 되는가?의존성 — 소프트웨어의 의존성 관리가 잘 이뤄지고 있는가?확..