요청 한 건의 일생 4편 — 트랜잭션과 커넥션 풀, 부하에서 먼저 무너지는 지점

// ❌ 잘못된 코드: 세 쿼리가 서로 다른 연결에서 실행될 수 있다
await pool.query('BEGIN');
await pool.query('UPDATE accounts SET balance = balance - 100 WHERE id = 1');
await pool.query('COMMIT');

// ✅ 올바른 코드: 연결 하나를 명시적으로 잡는다
export async function withTransaction<T>(fn: (client: PoolClient) => Promise<T>): Promise<T> {
  const client = await pool.connect();
  try {
    await client.query('BEGIN');
    const result = await fn(client);
    await client.query('COMMIT');
    return result;
  } catch (err) {
    await client.query('ROLLBACK');
    throw err;
  } finally {
    client.release();          // 반드시 반납. 누락 = 커넥션 누수
  }
}
 
// Service에서 트랜잭션 경계를 정한다
await withTransaction(async (tx) => {
  await accountRepo.withdraw(tx, fromId, amount);
  await accountRepo.deposit(tx, toId, amount);
  await ledgerRepo.record(tx, { fromId, toId, amount });
});

await withTransaction(async (tx) => {
  await orderRepo.create(tx, order);
  await paymentGateway.charge(order);   // ❌ 외부 HTTP 호출 (수 초가 걸릴 수 있음)
  await orderRepo.markPaid(tx, order.id);
});

요청 A: SELECT stock FROM items WHERE id=1   → 10
요청 B: SELECT stock FROM items WHERE id=1   → 10
요청 A: UPDATE items SET stock = 9 WHERE id=1
요청 B: UPDATE items SET stock = 9 WHERE id=1   → 두 개 팔렸는데 재고는 9

-- ① 원자적 연산으로 바꾸기 (가장 좋다)
UPDATE items SET stock = stock - 1 WHERE id = $1 AND stock > 0 RETURNING stock;
 
-- ② 비관적 락: 조회 시점에 행을 잠근다
SELECT stock FROM items WHERE id = $1 FOR UPDATE;
 
-- ③ 낙관적 락: 버전 컬럼으로 충돌 감지
UPDATE items SET stock = $2, version = version + 1
WHERE id = $1 AND version = $3;   -- 영향받은 행이 0이면 충돌 → 재시도 또는 409

1. 특정 쿼리가 평소 20ms → 2초로 느려짐 (인덱스 누락, 락 대기 등)
2. 풀의 연결 10개가 전부 이 쿼리에 묶임
3. 새 요청들은 풀 대기열에서 줄을 섬
4. connectionTimeoutMillis가 0(기본값)이면 → 무한 대기
5. Node 메모리에 대기 중인 요청이 쌓임, 클라이언트는 타임아웃 후 재시도
6. 재시도가 대기열을 더 늘림 (재시도 폭풍)
7. 로드밸런서 헬스체크도 응답 못 함 → 인스턴스가 빠짐 → 남은 인스턴스에 부하 집중
8. 전체 장애

connections = (DB 코어 수 × 2) + 유효 디스크 수

총 연결 수 = 인스턴스 수 × 인스턴스당 max
예) Node 인스턴스 8개(클러스터 포함) × max 10 = 80개
    + 배치 작업 + 관리 도구 + 마이그레이션 ...
    → PostgreSQL max_connections(기본 100)를 쉽게 넘는다

setInterval(() => {
  metrics.gauge('db.pool.total', pool.totalCount);     // 생성된 연결 수
  metrics.gauge('db.pool.idle', pool.idleCount);       // 놀고 있는 연결
  metrics.gauge('db.pool.waiting', pool.waitingCount); // 대기 중인 요청 ← 가장 중요한 지표
}, 5_000);

SELECT pid, application_name, state, wait_event_type, wait_event,
       now() - xact_start AS xact_age, left(query, 80) AS query
FROM pg_stat_activity
WHERE datname = 'app'
ORDER BY xact_age DESC NULLS LAST;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, title FROM posts WHERE author_id = 42 ORDER BY created_at DESC LIMIT 20;

Limit  (cost=0.43..8.95 rows=20 width=40) (actual time=0.031..0.090 rows=20 loops=1)
  Buffers: shared hit=24
  ->  Index Scan using posts_author_created_idx on posts
        (actual time=0.030..0.085 rows=20 loops=1)
        Index Cond: (author_id = 42)
Planning Time: 0.120 ms
Execution Time: 0.110 ms

// ❌ N+1: 쿼리 1번 + 게시글 수만큼 추가 쿼리
const posts = await postRepo.findRecent(20);             // 1번
for (const post of posts) {
  post.author = await userRepo.findById(post.authorId);  // 20번
}

// ✅ 해결 1: JOIN
const { rows } = await db.query(`
  SELECT p.id, p.title, u.id AS author_id, u.name AS author_name
  FROM posts p JOIN users u ON u.id = p.author_id
  ORDER BY p.created_at DESC LIMIT 20
`);
 
// ✅ 해결 2: IN으로 한 번에 (1 + 1 쿼리)
const posts = await postRepo.findRecent(20);
const ids = [...new Set(posts.map((p) => p.authorId))];
const { rows: authors } = await db.query(
  'SELECT id, name FROM users WHERE id = ANY($1::bigint[])',
  [ids],
);
const byId = new Map(authors.map((a) => [a.id, a]));
posts.forEach((p) => (p.author = byId.get(String(p.authorId))));

-- OFFSET: 페이지가 뒤로 갈수록 느려진다 (앞의 100000행을 읽고 버림)
SELECT id, title FROM posts ORDER BY created_at DESC, id DESC LIMIT 20 OFFSET 100000;
 
-- Keyset(커서) 페이지네이션: 어느 페이지든 일정한 속도
SELECT id, title, created_at FROM posts
WHERE (created_at, id) < ($1, $2)          -- 이전 페이지 마지막 항목의 값
ORDER BY created_at DESC, id DESC
LIMIT 20;