14강. 격리 수준, Lock, Deadlock 기초

?1. 이번 강의에서 해결할 문제

격리 수준을 무조건 높이거나 여러 플레이어를 서로 다른 순서로 잠그면 대기 증가와 deadlock이 발생합니다. 필요한 일관성에 맞는 격리 수준과 일관된 잠금 순서를 선택합니다.

✓2. 학습 목표

✓이 강의를 마치면

• Read Committed, Repeatable Read, Serializable의 관찰 차이를 설명합니다.
• SELECT ... FOR UPDATE의 행 잠금 범위를 이해합니다.
• 교착 상태 예방과 트랜잭션 재시도 원칙을 세웁니다.

◇3. 핵심 개념

PostgreSQL 기본 격리 수준은 Read Committed이며 각 문장은 시작 시점의 커밋된 스냅샷을 봅니다. Repeatable Read는 트랜잭션 동안 안정된 스냅샷을 제공하고 Serializable은 직렬 실행과 같은 결과를 목표로 하며 직렬화 실패 시 재시도가 필요합니다. 행 잠금은 충돌하는 변경을 기다리게 하고, 교착 상태는 서로 가진 잠금을 기다리는 순환입니다.

§4. 단계별 예시

파일 경로: C:\dev\game-ranking-service\database\sql\14-lock-order.sql

database/sql/14-lock-order.sql

BEGIN TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 여러 플레이어는 항상 ID 오름차순으로 잠근다.
SELECT player_id, rating
FROM ranking.players
WHERE player_id IN (42, 77)
ORDER BY player_id
FOR UPDATE;

UPDATE ranking.players
SET rating = rating + CASE player_id WHEN 42 THEN 25 ELSE -25 END,
    version = version + 1,
    updated_at = now()
WHERE player_id IN (42, 77);

COMMIT;

PowerShell · 잠금 관찰

psql -d game_ranking_dev -c "SELECT pid, wait_event_type, wait_event, state FROM pg_stat_activity WHERE datname = current_database();"

§5. 동작 원리

FOR UPDATE는 선택한 행을 다른 갱신과 충돌하는 방식으로 잠급니다. 모든 코드 경로가 작은 ID부터 잠그면 순환 대기 가능성이 줄어듭니다. PostgreSQL은 교착을 감지하면 한 트랜잭션을 중단하므로 애플리케이션은 전체 트랜잭션을 제한 횟수와 지연을 두고 재시도해야 합니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• Serializable이면 오류가 없다고 생각: 직렬화 실패는 정상적인 제어 신호입니다. 전체 트랜잭션 재시도를 설계합니다.
• 필요 이상 많은 행 잠금: 조건과 인덱스를 확인해 잠금 범위를 좁히고 트랜잭션을 짧게 유지합니다.
• deadlock을 무한 재시도: 제한 횟수, 지수 지연, 오류 로그와 멱등성 키를 둡니다.

✎7. 직접 실습

✎직접 실습

1. 두 세션에서 42→77, 77→42 순으로 잠가 교착 시나리오를 관찰합니다.
2. 두 세션 모두 오름차순 잠금으로 바꿔 차이를 기록합니다.
3. FastAPI 재시도 가능 오류와 사용자에게 즉시 반환할 오류를 구분합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. Read Committed에서 한 트랜잭션의 두 SELECT가 다른 결과를 볼 수 있는 이유는 무엇인가요?
2. 일관된 잠금 순서가 교착을 줄이는 이유는 무엇인가요?
3. Serializable 실패 시 한 SQL만 다시 실행하면 안 되는 이유는 무엇인가요?

■9. 핵심 요약

■핵심 요약

격리 수준은 정확성과 충돌 비용의 선택입니다. 필요한 행만 짧게 잠그고 모든 코드 경로의 잠금 순서를 통일하며, 교착과 직렬화 실패는 트랜잭션 단위 재시도로 처리합니다.