Huge Traffic Handling
1.[Huge Traffic Handling] HTTP Session과 Session Clustering
지금까지 Spring MVC 흐름, JPA, 트랜잭션을 공부하면서 서버가 요청을 처리하는 방식을 살펴봤다. 그런데 한 가지 의문이 생긴다. 우리가 매일 쓰는 쇼핑몰에서는 로그인이 유지되고 장바구니도 사라지지 않는다. HTTP는 Stateless라고 했는데, 이게 어떻게
2.[Huge Traffic Handling] Redis의 데이터 타입: 왜 String 하나로는 부족한가
지난 글에서는 HTTP Session의 한계와 Redis를 세션 저장소로 활용하는 방법을 살펴봤다. Redis가 세션 관리에 적합한 이유는 In-Memory 저장소 특성상 매 요청마다 조회되는 세션 데이터를 빠르게 처리할 수 있기 때문이었다.이번 글에서는 Redis를
3.[Huge Traffic Handling] Redis 캐싱 전략 — Cache-Aside부터 Write-back까지
지난 글에서는 Redis의 핵심 데이터 타입을 살펴봤다. String, List, Set, Hash, Sorted Set이 각각 어떤 문제를 해결하는지, 왜 Redis 안에서 직접 처리하는 게 빠른지를 이해했다.이번 글에서는 한 발 더 나아가 Redis를 캐시로 활용하
4.[Huge Traffic Handling] Redis 영속성과 Spring Security 세션 인증
지난 글에서 Redis가 In-Memory 저장소로서 빠른 속도를 제공하고, 다양한 데이터 타입과 캐싱 전략을 통해 어떻게 시스템 성능을 끌어올리는지 살펴봤다. 그런데 여기서 자연스럽게 의문이 생긴다.Redis는 메모리에 저장하는데, 서버가 꺼지면 데이터는 어떻게 되는
5.[Huge Traffic Handling] 트랜잭션과 @Transactional — Spring은 왜 이걸 대신 해주는가
지난 글에서는 Spring AI의 Advisor 패턴과 Function Calling을 다뤘다. 이번 글에서는 잠시 AI 주제에서 벗어나, 백엔드 개발의 가장 기본적인 안전장치 중 하나인 트랜잭션을 짚고 넘어간다.이런 질문들을 생각해보자.트랜잭션이 왜 필요한가?Spri
6.[Huge Traffic Handling] 트랜잭션 격리 수준 — 동시성과 정합성 사이의 선택
지난 글에서 @Transactional의 동작 원리와 전파 방식을 살펴봤다.트랜잭션이 "하나의 논리적 작업 단위"라는 건 알겠는데, 여러 트랜잭션이 동시에 실행되면 어떤 일이 벌어질까?이번 글에서는 아래 질문들을 다룬다.동시에 100명이 같은 데이터에 접근하면 무슨 일
7.[Huge Traffic Handling] 낙관적 락과 비관적 락 — 동시성 제어의 두 번째 무기
지난 글에서 트랜잭션 격리 수준으로 동시성 문제를 1차적으로 방어하는 방법을 살펴봤다.그런데 Repeatable Read로 격리 수준을 올려도 여전히 해결되지 않는 문제가 있다.재고가 10개인데 동시에 100명이 주문하면?티켓팅에서 같은 좌석을 동시에 두 명이 선택하면
8.[Huge Traffic Handling] 트랜잭션 격리 수준, 코드로 직접 확인해보기
지난 글에서 트랜잭션 격리 수준의 개념을 정리했다. Dirty Read, Non-Repeatable Read, Phantom Read가 각각 어떤 상황에서 발생하는지, 어떤 격리 수준이 이를 막는지 표로 정리했었다.그런데 이론만으로는 뭔가 찜찜하다. 실제로 발생하는지
9.[Huge Traffic Handling] 트랜잭션 전파 옵션 — 어디까지를 하나의 작업으로 볼 것인가
지금까지 트랜잭션의 기초(14단계), 격리 수준(15단계), 낙관적/비관적 락(16단계)을 거치면서 트랜잭션이 어떻게 시작되고, 어떻게 서로를 보호하는지 익혔다.이번에는 조금 다른 질문을 다룬다.ServiceA가 ServiceB를 호출할 때, 트랜잭션은 몇 개가 생겨야