분산 시스템에서 "메시지를 빠짐없이 전달했다"는 것만으로는 아무것도 보장되지 않고 유실이 0%여도 노드들의 상태는 갈라진다. 상태 발산이 왜 일어나는지부터 전체 순서 브로드캐스트(TOB)가 왜 등장했고 상태 기계 복제(SMR)와 어떤 관계인지, 그리고 이 구조가 실무에서 어떤 대가를 요구하는지 정리한다. 1. 문제점: 메시지를 전부 받아도 상태가 달라짐가격 시스템을 예로 들어보자. 상품 A의 가격을 두 주체가 거의 동시에 바꾼다.- MD가 정가를 10,000원으로 수정하고 프로모션 엔진이 9,000원으로 내린다. 복제본은 두 개고 메시지 유실은 단 한 건도 없다. (네트워크 지연이 경로마다 다름) MD ──► E1: SET price=10000 ──┬─────────────..

정규화/비정규화 비교데이터 중복정규화: 중복이 제거된다. 한곳에만 진실을 두는 SSOT를 지향한다.비정규화: 중복을 허용한다. 여러곳에 필요한 값들을 복사해 놓는다.쓰기 일관성정규화: 한 곳만 갱신한다. 테이블 ID로 참조하므로 다 연관으로서 전파된다. -> 일관성 관리가 쉬움.비정규화: 복사본 전부를 갱신해야한다. -> 일관성 비용이 높다. 읽기 성능정규화: 테이블들이 하나의 주제에 대한 사실만 두므로 쪼개져있다. 따라서 조인이 필요하므로 읽기 비용이 높다.비정규화: 관련있는 데이터들을 하나의 문서에 모아두므로 지역성이 높다. 따라서 조인이 필요없고 한번에 읽으므로 읽기가 빠르다.저장 공간정규화: 중복이 제거되므로 저장공간이 절약된다.비정규화: 데이터가 여러곳에 중복되어 저장되어있으므로 저장공간 사용이..

선언형 쿼리란?무엇(What)을 가져올지만 명시하는 질의 방식으로 가장 대표적인 예시가 바로 SQL이다. 선언형 쿼리(SQL)는 '관계해석'을 기반으로 하며, 이를 실행하기 위해 내부적으로 '관계대수'로 변환된다. [선언형 쿼리 예시]SELECT name FROM employees WHERE department = 'Planning'; 선언형 쿼리의 특징결과 중심: 데이터의 저장 위치나 탐색 경로를 사용자가 고민하지 않는다.최적화 위임: 구체적인 처리 절차는 데이터베이스 관리시스템(DBMS)의 옵티마이저가 결정한다.사용자 친화적: 절차형 언어에 비해 코드가 직관적이고 가독성이 높다. 문장으로 읽힘. 관계대수와의 핵심 관계성관계대수와 선언형 쿼리는 관계형 데이터베이스(RDB)의 근간을 이루는 두 축.이론적..

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 논블..