하지만 안쪽의 큰 흐름은 차분하다.

토큰을 벡터로 바꾼다.
각 토큰이 다른 토큰을 얼마나 참고할지 계산한다.
참고한 정보를 섞어 문맥이 반영된 벡터를 만든다.
그 벡터를 MLP로 다시 해석하고 다음 층으로 보낸다.

먼저 신경망은 무엇을 학습하나

딥러닝 모델을 아주 건조하게 말하면, 파라미터를 가진 함수다.

예측값 = f_theta(x)
theta = 학습으로 바뀌는 모든 숫자

완전연결층이라면 W, b가 파라미터다. CNN이라면 필터 안의 숫자도 파라미터고, Transformer라면 embedding table, W_Q, W_K, W_V, MLP의 가중치들이 모두 파라미터다. 학습은 손실 L(theta)를 줄이도록 이 숫자들을 조금씩 바꾸는 과정이다.

h = sigma(xW + b)
theta <- theta - eta * grad_theta L(theta)

여기서 중요한 점은 입력 데이터 자체가 파라미터는 아니라는 것이다. 모델은 데이터를 보고, 그 데이터를 더 잘 설명하는 내부 숫자들을 업데이트한다. 실무적으로는 “경사하강으로 업데이트되는 값들 전부”를 파라미터라고 보면 된다.

CNN과 RNN을 거쳐 Transformer로

Transformer가 갑자기 하늘에서 떨어진 구조는 아니다. 기존 신경망의 장점과 한계를 보면 왜 attention이 중심으로 올라왔는지 보인다.

DNN / MLP

MLP는 벡터를 받아 여러 층의 선형 변환과 비선형 함수를 통과시킨다.

h_1 = sigma(xW_1 + b_1)
h_2 = sigma(h_1W_2 + b_2)

이 구조는 강력하지만 입력의 구조를 별도로 가정하지 않는다. 이미지의 2차원 공간 구조나 문장의 순서를 처음부터 잘 살려 주지는 않는다. 모든 것을 벡터로 펼쳐서 처리하면 표현력은 있지만, 데이터가 가진 자연스러운 구조를 활용하기 어렵다.

CNN

CNN은 이미지처럼 공간 구조가 있는 데이터에 잘 맞는다. 핵심은 두 가지다.

local receptive field: 가까운 영역만 본다.
weight sharing: 같은 필터를 여러 위치에 반복 적용한다.

합성곱층의 계산은 보통 다음처럼 볼 수 있다. 실제 딥러닝 프레임워크의 convolution layer는 엄밀한 수학적 convolution이라기보다 cross-correlation 형태로 구현되는 경우가 많지만, 학습되는 필터 관점에서는 같은 패턴 감지기로 이해해도 충분하다.

y[i, j, k] = b[k] + sum_u sum_v sum_c W[u, v, c, k] * x[i+u, j+v, c]

CNN은 “어디에 있든 비슷한 지역 패턴은 같은 필터로 찾는다”는 강한 귀납 편향을 가진다. 그래서 이미지에서는 오래 강력했다. 다만 멀리 떨어진 요소 사이의 관계를 직접 계산하려면 층을 깊게 쌓거나 별도 구조가 필요하다.

RNN

RNN은 순서가 있는 데이터를 한 토큰씩 읽는다.

h_t = phi(W_x x_t + W_h h_{t-1} + b)

여기서 h_t는 지금까지 읽은 정보를 담은 상태다. 구조가 직관적이고 효율적이지만, 긴 문맥에서는 과거 전체를 하나의 상태에 계속 압축해야 한다. LSTM/GRU는 이 문제를 완화하려고 게이트를 도입했지만, 기본적으로 순차 계산이라는 성격은 남는다.

이 차이는 기억을 저장하는 방식으로도 볼 수 있다. RNN은 과거를 하나의 상태에 압축하는 쪽에 가깝고, Transformer attention은 과거 토큰의 정보를 직접 조회하는 쪽에 가깝다. 둘 중 어느 하나가 항상 정답이라기보다, 과거 정보를 어느 해상도로 저장하고 어떻게 검색할지가 핵심이다.

Transformer의 핵심 전환

Transformer의 핵심은 recurrent state를 중심에 두지 않는다는 점이다. 각 토큰은 한 번에 다른 토큰들을 바라보고, 필요한 정보를 가중합으로 가져온다.

Transformer 원 논문의 표현을 빌리면, attention 함수는 query와 key-value 쌍들을 받아 output을 만든다. output은 value들의 가중합이고, 각 value에 주는 weight는 query와 key의 compatibility로 계산된다.

한 토큰이 다른 토큰을 읽는 흐름은 다음과 같다.

여기서 주의할 점이 있다. 이 그림의 숫자는 이해를 위한 예시다. 실제 모델에서는 head와 layer마다 attention weight가 다르고, 그 weight가 사람이 붙인 문법 규칙처럼 깔끔하게 해석된다고 보장할 수는 없다. 그래도 “토큰이 다른 토큰의 정보를 동적으로 가져온다”는 큰 직관은 맞다.

Q, K, V는 무엇인가

입력 토큰 벡터들을 행렬 X라고 하자. 시퀀스 길이가 n, hidden dimension이 d_model이면 다음처럼 둘 수 있다.

X in R^(n x d_model)
Q = X W_Q
K = X W_K
V = X W_V

각 토큰은 같은 원본 벡터에서 세 가지 역할의 벡터를 만든다.

attention의 전체 식은 다음과 같다.

Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V

계산은 네 단계로 읽으면 된다.

1. QK^T: 각 토큰의 query와 모든 토큰의 key를 내적한다.
2. / sqrt(d_k): 내적 값이 너무 커져 softmax가 뾰족해지는 것을 완화한다.
3. softmax: 참고 비중을 확률분포처럼 만든다.
4. * V: value들을 그 비중대로 가중합한다.

Q/K는 “얼마나 볼지”를 정하고 V는 “무엇을 가져올지”를 담당한다. 그래서 attention은 정보를 섞는 라우팅 시스템에 가깝다.

Multi-head attention은 왜 필요한가

하나의 attention만 있으면 모든 관계를 한 가지 관점으로 봐야 한다. 문장 안에는 여러 관계가 동시에 있다. 주어-동사 관계, 수식어 관계, 지시어 관계, 문장 부호의 역할, 장거리 의존성 같은 것들이 서로 다른 방식으로 중요해진다.

Multi-head attention은 같은 입력을 여러 projection 공간으로 보내고, 각 head가 다른 attention을 계산하게 한다.

head_i = Attention(XW_Q_i, XW_K_i, XW_V_i)
MultiHead(X) = Concat(head_1, ..., head_h) W_O

각 head가 반드시 사람이 이름 붙일 수 있는 역할 하나를 맡는다고 단정하면 위험하다. 그러나 여러 head가 서로 다른 부분공간에서 관계를 계산하기 때문에, 하나의 attention보다 다양한 상호작용을 표현할 수 있다.

위치 정보가 없으면 순서를 모른다

self-attention만 보면 토큰 집합을 한꺼번에 비교한다. 그래서 별도 위치 정보가 없으면 순서가 바뀌어도 구조적으로 구분하기 어렵다. Transformer 원 논문은 sinusoidal positional encoding을 embedding에 더했다. 이후 모델들은 learned positional embedding, relative position, RoPE 같은 여러 방식을 쓴다.

핵심은 하나다.

토큰의 의미 벡터 + 위치 신호 = 순서를 가진 토큰 표현

“나는 어떤 단어인가”와 “나는 어디에 있는가”를 같이 넣어야 문장 구조를 계산할 수 있다.

MLP는 attention 뒤에서 무엇을 하나

Transformer block 안에는 attention만 있는 것이 아니다. attention 뒤에는 position-wise feed-forward network, 흔히 MLP 또는 FFN이라 부르는 부분이 있다.

FFN(x) = W_2 sigma(W_1 x + b_1) + b_2

Transformer 원 논문에서는 ReLU를 썼고, 이후 많은 모델은 GELU 같은 활성 함수를 사용한다. 일반적으로 d_model보다 큰 d_ff로 확장했다가 다시 줄인다.

d_model -> d_ff -> d_model
예: 768 -> 3072 -> 768

중요한 구분은 이것이다.

Attention: 토큰 사이의 정보를 섞는다.
MLP/FFN: 각 토큰 벡터를 독립적으로 비선형 변환한다.

MLP는 토큰 간 통신을 직접 하지는 않는다. 그 일은 attention이 맡는다. 대신 attention이 모아 온 문맥 벡터를 더 복잡한 feature 공간으로 보내고, 비선형 변환을 거쳐 다음 층이 쓰기 좋은 표현으로 바꾼다.

여기서 residual connection은 입력을 바로 더해 주는 길이다. 깊은 모델에서 매 층이 표현을 완전히 갈아엎는 것이 아니라, 기존 표현 위에 필요한 변화량을 더하게 만든다. Layer normalization은 값의 스케일을 정돈해 학습을 안정적으로 만든다.

Encoder, decoder, decoder-only

Transformer는 처음에는 machine translation을 위한 encoder-decoder 구조로 제안되었다.

LLM이 다음 토큰을 생성할 때는 보통 decoder-only 구조를 쓴다. 현재까지의 토큰만 보고 다음 토큰 분포를 만든다.

hidden state -> vocabulary logits -> softmax -> next token distribution

여기서도 중요한 구분이 있다. embedding table이나 W_Q, W_K, W_V 같은 파라미터는 학습 후 추론 중에는 고정되어 있다. 그러나 각 토큰의 최종 표현과 attention weight는 입력 문맥에 따라 매번 달라진다. 즉 초기 임베딩은 고정된 테이블에서 시작하지만, 레이어를 지난 문맥 표현은 동적으로 바뀐다.

CNN, RNN, Transformer를 같은 지도 위에 놓기

세 구조는 서로를 단순히 대체했다기보다, 데이터의 어떤 구조를 먼저 믿을 것인가가 다르다.

Transformer가 강력한 이유는 “모든 문제에서 CNN/RNN보다 항상 낫다”가 아니다. 핵심은 token들이 서로를 직접 조회하면서 문맥 표현을 동적으로 만든다는 점이다. 대신 긴 시퀀스에서는 attention matrix가 커진다. 그래서 efficient attention, sparse attention, linear attention, recurrent memory, memory caching 같은 연구들이 계속 이어진다.

한 층을 실제 계산처럼 따라가기

문장 고양이 생선을 먹었다를 아주 작게 벡터화했다고 생각해 보자.

X = [x_고양이, x_생선을, x_먹었다]
Q = XW_Q
K = XW_K
V = XW_V

먹었다 위치의 query를 q_먹었다라고 하면, 이 query는 모든 key와 내적된다.

s = [
  q_먹었다 · k_고양이,
  q_먹었다 · k_생선을,
  q_먹었다 · k_먹었다
]

그 다음 softmax를 거친다.

alpha = softmax(s / sqrt(d_k))

마지막으로 value를 섞는다.

z_먹었다 =
  alpha_1 * v_고양이 +
  alpha_2 * v_생선을 +
  alpha_3 * v_먹었다

이 z_먹었다는 더 이상 단순히 “먹었다”라는 토큰의 정적 벡터가 아니다. “고양이가 생선을 먹었다”라는 문맥이 반영된 벡터다. 다음 block으로 넘어가면 이 과정이 다시 반복되고, 더 추상적인 관계가 쌓인다.

오해하기 쉬운 부분

첫째, attention weight가 곧 완전한 설명은 아니다. 특정 head의 weight가 어떤 토큰을 많이 본다고 해서, 모델의 최종 판단 이유가 그 토큰 하나라고 단정할 수는 없다. 여러 head, 여러 layer, MLP, residual path가 함께 작동한다.

둘째, MLP의 뉴런 하나가 항상 사람이 읽을 수 있는 feature 하나를 담당한다고 보면 위험하다. 어떤 뉴런이나 방향이 특정 feature와 강하게 상관될 수는 있지만, 실제 표현은 대개 여러 차원에 분산되어 있다.

셋째, positional encoding이 “순서를 학습한다”는 말은 조금 조심해야 한다. 위치 신호를 넣어 주면 attention이 위치까지 포함한 관계를 계산할 수 있게 된다. 위치 정보를 어떤 방식으로 넣을지는 모델마다 다르다.

넷째, Transformer는 recurrence와 convolution을 기본 골격에서 제거했지만, 현대 모델 생태계에서는 CNN, RNN, attention, memory가 다시 섞이고 있다. 특히 vision transformer는 이미지를 patch sequence로 바꿔 attention을 적용하고, 반대로 일부 언어 모델 연구는 recurrent memory나 state-space 계열을 다시 탐색한다.

정리

Transformer를 한 문장으로 정리하면 이렇다.

각 토큰이 문맥 속의 다른 토큰들을 직접 조회해 새 표현을 만들고,
그 표현을 MLP로 다시 해석하는 block을 깊게 쌓은 모델.

DNN은 벡터를 비선형 함수로 바꿨고, CNN은 지역 패턴을 효율적으로 찾았고, RNN은 순서를 상태에 누적했다. Transformer는 여기서 한 걸음 옮겨 “지금 이 토큰이 어떤 토큰을 참고해야 하는가”를 매 입력마다 다시 계산한다.

그래서 같은 단어라도 문맥이 바뀌면 다른 벡터가 된다. 커피잔 옆에 놓인 “별”과 천문학 문서 속의 “별”은 같은 글자일 수 있지만, 모델 안에서는 서로 다른 밤하늘을 지나간다.

검증하며 보정한 점

• Transformer의 self-attention 수식과 encoder-decoder 구조는 Vaswani et al.의 원 논문을 기준으로 확인했다.
• attention 자체의 계보는 Bahdanau, Cho, Bengio의 neural machine translation 논문에서 제안된 alignment/attention 아이디어와 함께 보는 것이 정확하다.
• CNN 설명은 LeCun et al.의 LeNet/문서 인식 논문을 기준으로, 지역 수용영역과 가중치 공유 중심으로 정리했다.
• RNN의 장기 의존성 문제와 LSTM의 위치는 Hochreiter & Schmidhuber의 논문을 기준으로 확인했다.
• MLP 뉴런을 “특정 feature detector”로 단정하는 표현은 분산 표현 관점에서 완화했다.
• “embedding은 고정이지만 문맥 표현은 동적”이라는 설명은 추론 시 학습 파라미터는 고정되고, activation/attention weight는 입력에 따라 달라진다는 식으로 보정했다.

참고 자료

• Vaswani et al., Attention Is All You Need, 2017.
• Bahdanau, Cho, Bengio, Neural Machine Translation by Jointly Learning to Align and Translate, 2014.
• LeCun et al., Gradient-Based Learning Applied to Document Recognition, 1998.
• Hochreiter, Schmidhuber, Long Short-Term Memory, 1997.
• Rumelhart, Hinton, Williams, Learning representations by back-propagating errors, 1986.
• Hendrycks, Gimpel, Gaussian Error Linear Units (GELUs), 2016.
• Dosovitskiy et al., An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale, 2020.
• Behrouz et al., Memory Caching: RNNs with Growing Memory, 2026.

핵심은 단순하다.

다음 상태의 분포는 과거 전체가 아니라 현재 상태에 의해 결정된다.

이 말은 과거가 아무 의미 없다는 뜻이 아니다. 과거의 정보가 현재 상태 안에 충분히 요약되어 있다면, 다음을 예측할 때는 현재 상태만 보면 된다는 뜻이다.

마르코프 성질

확률 과정 X_0, X_1, X_2, ...가 있을 때, 이 과정이 마르코프 체인이라는 말은 다음 조건을 만족한다는 뜻이다.

P(X_{n+1} = j | X_n = i, X_{n-1}, ..., X_0)
=
P(X_{n+1} = j | X_n = i)

미래를 예측할 때 과거 전체를 다시 펼쳐 보지 않고, 현재 상태 X_n만 사용한다. 이 성질을 마르코프 성질이라고 한다.

주의할 점이 있다. 마르코프 성질은 “다음 상태가 현재 상태와 독립”이라는 뜻이 아니다. 오히려 다음 상태는 현재 상태에 강하게 의존한다. 다만 현재 상태를 알고 나면, 그 이전의 이력은 추가 정보를 주지 않는다는 뜻이다.

전이확률행렬

상태가 A, B, C 세 개라고 하자. 한 단계 뒤 어디로 갈지의 확률은 행렬로 표현할 수 있다.

       next A  next B  next C
A      0.6     0.4     0.0
B      0.3     0.5     0.2
C      0.0     0.6     0.4

이 글에서는 행 벡터 관례를 사용한다. 즉, 현재 분포 pi^(0)를 왼쪽에 두고 오른쪽에 전이행렬 P를 곱한다.

pi^(1) = pi^(0) P
pi^(2) = pi^(0) P^2
pi^(n) = pi^(0) P^n

행렬의 각 행은 현재 상태 하나를 의미한다. 어떤 상태에 있든 다음 단계에는 반드시 어딘가의 상태가 되어야 하므로, 각 행의 합은 1이어야 한다. 이런 행렬을 row-stochastic matrix라고 부른다.

n-step 전이 계산

초기 상태가 반드시 A라고 하자.

pi^(0) = [1, 0, 0]

한 단계 뒤에는 전이행렬의 첫 번째 행 그대로가 된다.

pi^(1) = [1, 0, 0] P
       = [0.6, 0.4, 0.0]

두 단계 뒤에는 다시 한 번 P를 곱한다.

pi^(2) = [0.6, 0.4, 0.0] P
       = [0.48, 0.44, 0.08]

이 값이 중요하다. Notion 원문에는 같은 예시의 두 단계 뒤 분포가 [0.42, 0.44, 0.14]로 적혀 있었지만, 행 벡터 관례와 위 전이행렬을 그대로 사용하면 올바른 값은 [0.48, 0.44, 0.08]이다.

정지분포와 수렴분포

정지분포는 전이 이후에도 변하지 않는 분포다.

pi = pi P
sum(pi_i) = 1
pi_i >= 0

위 예시의 정지분포를 풀어보면 다음과 같다.

pi = [0.36, 0.48, 0.16]

확인해보면 pi P = pi가 된다.

정지분포와 수렴분포는 비슷해 보이지만 구분해야 한다.

정지분포는 “이미 이 분포로 시작하면 한 단계 뒤에도 그대로”라는 대수적 조건이다. 반면 수렴분포는 “어떤 초기 상태에서 시작해도 시간이 충분히 지나면 그 분포로 가까워지는가”라는 극한 조건이다.

유한 상태 마르코프 체인에서는 다음처럼 정리할 수 있다.

즉 “불가약 + 비주기적이면 항상 하나의 분포로 수렴한다”는 말은 유한 상태 체인에서는 안전하지만, 무한 상태 공간까지 일반화하려면 positive recurrence를 함께 확인해야 한다.

상태를 분류하는 말들

마르코프 체인을 읽다 보면 여러 성질이 나온다. 처음에는 아래 정도를 구분하면 충분하다.

흡수 마르코프 체인

흡수 상태가 있는 체인은 장기분포를 볼 때 조심해야 한다. 예를 들어 종료, 장애, 결제 완료 같은 상태는 한 번 들어가면 더 이상 빠져나오지 않는 상태로 모델링할 수 있다.

P(absorb -> absorb) = 1

이런 체인에서는 “전체가 하나의 평형으로 섞인다”보다 “어느 흡수 상태에 도달할 확률이 얼마인가”, “흡수되기까지 평균 몇 단계가 걸리는가”가 더 자연스러운 질문이다.

연속시간 마르코프 체인

Notion 원문에는 DTMC와 CTMC가 함께 언급되어 있다. 둘은 상태 전이의 철학은 같지만 시간 모델이 다르다.

CTMC에서는 “다음 단계로 갈 확률”보다 “얼마의 rate로 다른 상태로 점프하는가”가 중심이 된다. 예를 들어 서버 장애 모델에서 정상 상태가 평균적으로 100시간 유지되고, 복구 상태가 평균적으로 2시간 걸리는 식의 시간을 직접 다룰 수 있다.

어디에 쓰이는가

마르코프 체인은 단순한 수학 장난이 아니라, “현재 상태를 잘 정의하면 다음 흐름을 확률적으로 계산할 수 있다”는 틀이다.

PageRank는 특히 좋은 예다. 웹 페이지를 그래프의 노드로 두고, 사용자가 링크를 따라 무작위로 이동한다고 보면 하나의 마르코프 체인이 된다. 장기적으로 어떤 페이지에 오래 머무는지가 그 페이지의 중요도와 연결된다. 실제 PageRank에는 dangling node와 spider trap 문제를 피하기 위한 teleportation이 들어가는데, 이 역시 체인이 잘 섞이도록 만드는 장치로 이해할 수 있다.

글을 읽을 때의 기준

마르코프 체인 문서를 볼 때는 아래 질문을 순서대로 던지면 덜 헷갈린다.

1. 상태는 무엇인가?
2. 시간은 discrete인가, continuous인가?
3. 전이확률행렬 P 또는 generator Q는 어떻게 정의되는가?
4. 행 기준인가, 열 기준인가?
5. 정지분포를 묻는가, 수렴분포를 묻는가?
6. 불가약성, 비주기성, 흡수 상태는 어떻게 되는가?

특히 4번이 중요하다. 어떤 책은 행 벡터를 쓰고 pi P를 계산한다. 어떤 책은 열 벡터를 쓰고 P pi를 계산한다. 둘 중 어느 쪽이든 수학적으로는 가능하지만, 한 글 안에서는 관례를 섞으면 계산이 틀어진다.

정리

마르코프 체인은 복잡한 이력을 현재 상태 하나로 접어 넣는 모델이다. 상태 정의가 잘 되어 있으면, 다음 상태는 전이확률행렬로 계산할 수 있고, 여러 단계를 지나면 P^n이 시스템의 장기 행동을 보여준다.

다만 장기적으로 안정된 분포가 생기는지는 조건을 봐야 한다. 유한 상태에서 불가약이고 비주기적인 체인은 유일한 정지분포로 수렴한다. 흡수 상태가 있거나 주기성이 있거나 무한 상태 공간이라면 이야기가 달라질 수 있다.

그래서 마르코프 체인의 핵심은 “현재만 본다”가 아니라, “미래를 계산하기에 충분한 현재 상태를 어떻게 정의할 것인가”에 있다.

참고한 자료

• MIT OpenCourseWare, Lecture 16: Markov Chains I
• CMU Math, Markov Chains: The Stationary Distribution
• ProbabilityCourse.com, Stationary and Limiting Distributions for DTMC
• ProbabilityCourse.com, Stationary and Limiting Distributions for CTMC
• Stanford CME 323, PageRank lecture notes

데이터를 일부러 노이즈로 흩뜨린 뒤,
그 흩어진 길을 거꾸로 따라오는 방법을 학습하는 생성 모델.

이미지 생성 결과만 보면 마법처럼 느껴지지만, 안쪽의 학습 신호는 의외로 단정하다. 깨끗한 이미지에 우리가 직접 가우시안 노이즈를 섞고, 모델에게 “지금 섞인 노이즈가 무엇인지 맞혀보라”고 시킨다. 이 일을 충분히 잘하게 되면, 모델은 순수한 노이즈에서 시작해서 조금씩 자연스러운 이미지 쪽으로 이동하는 길을 만들 수 있다.

이 글은 Notion의 Diffusion, 이미지 분포, Stable Diffusion, AE/VAE/Latent 관련 문서들을 하나로 묶어 정리한 글이다. 직관은 포근하게 잡되, 수식과 용어는 가능한 정확하게 두었다.

데이터 분포는 의미 라벨이 아니다

Diffusion에서 말하는 p_data(x)는 “이 이미지는 고양이다” 같은 라벨 분포가 아니다. x는 픽셀 값 또는 latent 값으로 이루어진 좌표다. 그러니까 p_data(x)는 이미지 공간에서 자연스러운 이미지들이 어디에 많이 모여 있는지를 나타내는 확률 밀도다.

자연 이미지는 전체 픽셀 공간에 고르게 퍼져 있지 않다. 하늘은 하늘다운 색과 질감의 규칙이 있고, 얼굴은 얼굴다운 대칭과 구조가 있으며, 책상 위 사물들은 서로 그럴듯한 위치 관계를 가진다. 이런 통계적 구조 때문에 데이터는 거대한 좌표 공간 안의 일부 영역, 흔히 말하는 데이터 매니폴드 근처에 몰린다.

라벨은 필수가 아니다. 라벨이나 텍스트 조건이 없어도 모델은 데이터가 자주 나타나는 구조를 배울 수 있다. 다만 텍스트 조건을 주면 p(x)가 아니라 p(x | text)처럼 조건에 맞는 부분 분포를 따라가도록 안내할 수 있다.

정방향 과정: 이미지를 일부러 흐리게 만든다

DDPM 계열의 기본 정방향 과정은 마르코프 체인으로 표현한다.

q(x_t | x_{t-1}) = N(sqrt(1 - beta_t) x_{t-1}, beta_t I)

여기서 beta_t는 t번째 단계에서 노이즈를 얼마나 더할지 정하는 스케줄이다. 보통 한 번에 이미지를 망가뜨리지 않고, 작은 노이즈를 여러 단계에 걸쳐 누적한다.

실제 학습에서는 매번 x0 -> x1 -> ... -> x_t를 순서대로 계산하지 않아도 된다. 누적값을 쓰면 임의의 t에 대해 바로 x_t를 만들 수 있다.

alpha_t = 1 - beta_t
alpha_bar_t = alpha_1 * alpha_2 * ... * alpha_t

x_t = sqrt(alpha_bar_t) x0 + sqrt(1 - alpha_bar_t) epsilon
epsilon ~ N(0, I)

이 식이 중요하다. 깨끗한 이미지 x0, 임의의 시간 t, 우리가 뽑은 노이즈 epsilon만 있으면 노이즈 낀 입력 x_t를 만들 수 있다. 그리고 우리가 어떤 노이즈를 섞었는지도 정확히 알고 있다.

학습: 모델은 원본 이미지가 아니라 노이즈를 맞힌다

Diffusion 모델의 가장 흔한 학습 목표는 epsilon prediction이다.

loss = E[ || epsilon - epsilon_theta(x_t, t, condition) ||^2 ]

모델 입력은 노이즈가 섞인 x_t, 노이즈 수준 t, 선택적으로 텍스트나 클래스 같은 조건이다. 출력은 x_t에 섞였던 노이즈의 예측값이다.

겉으로는 정답이 있는 회귀 문제처럼 보인다. 하지만 정답 epsilon은 사람이 라벨링한 값이 아니라, 학습 과정에서 우리가 직접 만든 값이다. 그래서 Diffusion은 보통 비지도 생성 모델의 범주에 놓이지만, 구현되는 학습 신호는 자기지도 denoising objective라고 보는 편이 더 정확하다.

이 손실이 좋은 이유는 명확하다. 원본 이미지를 직접 회귀하는 것보다, 각 노이즈 수준에서 “무엇을 빼야 자연스러운 데이터 쪽으로 가까워지는지”를 배우게 된다.

Score 관점: 노이즈 예측은 방향을 배운다

Diffusion을 더 깊게 보면 score-based generative modeling과 연결된다. score는 확률밀도의 로그 기울기다.

score(x_t, t) = gradient_x log p_t(x_t)

직관적으로 score는 현재 위치에서 확률밀도가 커지는 방향을 가리킨다. DDPM의 노이즈 예측 모델은 일정한 스케일 변환을 거치면 이 score와 같은 정보를 담는다.

score(x_t, t) is approximately
- epsilon_theta(x_t, t) / sqrt(1 - alpha_bar_t)

따라서 샘플링은 “노이즈에서 시작해 score field를 따라 데이터 밀도가 높은 쪽으로 이동하는 수치적분”으로 볼 수 있다. 원본 한 장을 복구하는 것이 아니라, 학습 데이터 분포와 비슷한 새 샘플을 만들어내는 과정이다.

역방향 과정: 노이즈에서 새 이미지를 샘플링한다

학습이 끝나면 생성은 반대로 진행한다.

x_T ~ N(0, I)

for t = T, ..., 1:
  epsilon_pred = epsilon_theta(x_t, t, condition)
  x_{t-1} = denoise_step(x_t, epsilon_pred, t)

DDPM은 역방향 과정을 확률적으로 샘플링한다. 각 단계에서 평균 방향으로 denoise하면서도 약간의 가우시안 변동을 남긴다. 이 변동은 다양성을 만드는 데 도움을 준다.

DDIM은 같은 학습 목표를 유지하면서 비마르코프적 경로를 구성해 더 적은 단계로 샘플링할 수 있게 했다. 이후 DPM-Solver, UniPC, Euler, Heun 같은 sampler들은 역방향 과정을 수치적으로 더 효율적으로 적분하려는 시도들이다. 중요한 점은 sampler가 바뀌어도 모델이 배운 핵심은 여전히 “각 노이즈 수준에서 무엇을 제거해야 하는가”라는 것이다.

텍스트 조건과 classifier-free guidance

텍스트-이미지 모델에서는 U-Net이 이미지 또는 latent 특징만 보지 않는다. 텍스트 인코더가 만든 토큰 임베딩을 cross-attention으로 넣어준다.

Q = image or latent features
K, V = text token embeddings

이렇게 하면 모델은 p(x)가 아니라 p(x | text)에 가까운 방향으로 denoise한다.

Classifier-free guidance는 조건부 예측과 무조건부 예측을 함께 사용해 조건의 힘을 조절한다.

epsilon_hat =
  epsilon_uncond + guidance_scale * (epsilon_cond - epsilon_uncond)

guidance_scale을 키우면 프롬프트를 더 세게 따르는 경향이 생긴다. 대신 너무 크면 색이 과해지거나 구도가 경직되거나 세부가 깨질 수 있다. 실무에서 CFG는 “프롬프트 충실도와 다양성 사이의 손잡이”라고 이해하면 편하다.

AutoEncoder부터 잡고 가기

Latent Diffusion을 이해하려면 먼저 AutoEncoder를 짚는 편이 좋다. AutoEncoder는 입력을 한 번 압축했다가 다시 복원하는 신경망이다.

x -> Encoder -> z -> Decoder -> x_hat

여기서 x는 원본 이미지, z는 latent representation, x_hat은 복원 이미지다. 기본 AutoEncoder의 손실은 보통 입력과 최종 출력의 차이로 잡는다.

L_recon = || x - x_hat ||^2

중요한 점은 latent를 기준으로 encoder와 decoder의 중간 레이어를 대칭 비교하지 않는다는 것이다. 손실은 최종 복원 결과와 원본 사이에서 계산되고, 그 오차가 decoder를 거쳐 latent, 다시 encoder 쪽으로 역전파된다. Notion의 AutoEncoder 역전파 문서에서 정리한 것처럼, latent는 비교 대상이라기보다 gradient가 지나가는 병목 통로에 가깝다.

AutoEncoder가 하는 일은 단순한 압축 파일 만들기와 다르다. 좋은 encoder는 복원에 필요한 형태, 색감, 질감, 구도 같은 정보를 작은 표현에 담아야 한다. 좋은 decoder는 그 작은 표현에서 다시 눈에 자연스러운 이미지를 펼쳐야 한다.

다만 기본 AE에는 생성 모델로서의 약점이 있다. z = E(x)가 결정론적 점이기 때문에, latent 공간의 아무 지점이나 골라 decoder에 넣었을 때 자연스러운 이미지가 나온다는 보장이 약하다. 훈련 데이터가 지나간 지점 근처에서는 복원이 되지만, 그 사이 공간이나 바깥 공간이 매끄럽게 정돈되어 있지 않을 수 있다.

AE와 VAE는 무엇이 다른가

VAE는 AutoEncoder처럼 encoder와 decoder를 갖지만, latent를 하나의 점이 아니라 분포로 다룬다.

AE:
  z = E(x)

VAE:
  q_phi(z | x) = N(mu_phi(x), diag(sigma_phi(x)^2))
  z = mu + sigma * epsilon
  epsilon ~ N(0, I)

VAE encoder는 입력 이미지 하나에 대해 mu와 sigma를 예측한다. mu는 그 이미지가 latent 공간에서 있을 법한 중심이고, sigma는 그 주변에서 허용되는 변동 폭이다. 그 다음 reparameterization trick으로 z를 샘플링한다. 이렇게 해야 샘플링이 들어가도 gradient가 encoder 쪽으로 흘러갈 수 있다.

학습 목표는 복원 품질과 latent 정규화를 함께 본다.

ELBO = E_q[log p_theta(x | z)]
       - KL(q_phi(z | x) || p(z))

loss = reconstruction loss + KL regularization

p(z)는 보통 표준정규분포 N(0, I)로 둔다. KL 항은 encoder가 만든 q_phi(z | x)가 이 prior에서 너무 멀어지지 않게 붙잡는다. 그래서 VAE의 latent 공간은 AE보다 샘플링하기 쉬운 형태로 정돈된다.

그래서 “VAE가 AE보다 항상 복원을 더 잘한다”라고 말하면 부정확하다. VAE는 복원만 최적화하는 모델이 아니라, 복원과 생성 가능한 latent 공간 사이의 균형을 맞추는 모델이다. Latent Diffusion에서 VAE가 중요한 이유도 이 균형 때문이다. diffusion이 다룰 latent가 너무 임의적인 모양이면 가우시안 노이즈 스케줄과 잘 맞지 않고, decoder가 복원할 수 있는 의미 있는 공간 안에서 denoise가 진행되어야 한다.

Stable Diffusion은 왜 latent에서 diffusion을 하는가

픽셀 공간에서 diffusion을 돌리면 계산량이 크다. 512 x 512 RGB 이미지는 786,432개의 숫자를 가진다. 이를 매 denoise step마다 U-Net으로 처리하면 학습과 추론 모두 비싸진다.

Latent Diffusion의 핵심은 이미지를 먼저 더 작은 latent로 압축하고, diffusion은 그 latent 공간에서 수행하는 것이다.

Latent는 단순한 썸네일이 아니다. 공간 구조는 유지하지만, 각 값은 RGB처럼 사람이 바로 읽을 수 있는 색이 아니다. VAE가 학습한 압축 표현이고, 여러 시각적 특징이 얽혀 있다.

예를 들어 Stable Diffusion v1 계열처럼 512 x 512 x 3 이미지가 64 x 64 x 4 latent로 내려간다고 하자. 공간적으로는 대략 8배 다운샘플된 격자처럼 볼 수 있다. 하지만 latent의 한 칸이 원본의 정확한 8 x 8 패치를 독립적으로 뜻한다고 단정하면 곤란하다. convolution과 attention, decoder의 receptive field 때문에 주변 정보와 함께 해석된다.

여기서 -1.24, 0.43 같은 부동소수점 값은 “이 위치의 어떤 학습된 feature가 어느 방향과 강도로 활성화되었는가”에 가깝다. 값의 부호와 크기가 의미는 있지만, 사람이 “이 값은 눈”, “이 채널은 조명”처럼 직접 이름 붙일 수 있는 축은 아니다. 이런 표현은 대부분 entangled representation이다.

VAE는 latent를 하나의 점이 아니라 분포로 본다

VAE의 인코더는 보통 입력 이미지 x를 받아 latent z 하나를 바로 내놓지 않는다. 대신 approximate posterior의 파라미터를 낸다.

q_phi(z | x) = N(mu_phi(x), diag(sigma_phi(x)^2))
z = mu + sigma * epsilon
epsilon ~ N(0, I)

이때 mu는 입력 이미지가 latent 공간에서 있을 법한 중심이고, sigma는 그 주변의 불확실성 또는 허용되는 변동 폭이다. 학습은 reconstruction term과 KL term으로 구성된 ELBO를 최적화한다.

ELBO =
  reconstruction quality
  - KL(q_phi(z | x) || p(z))

p(z) is usually N(0, I)

정확히 말하면 VAE가 “알 수 없는 실제 posterior를 직접 구한다”기보다, 다루기 쉬운 분포 q_phi(z | x)로 근사하고 그 하한을 최적화한다. 이 점은 오래된 VAE 설명에서 자주 흐려지는 부분이다.

데이터셋 전체로 보면 latent 분포는 각 샘플의 가우시안 posterior가 모인 aggregated posterior다.

q_phi(z) ~= average_i q_phi(z | x_i)

평균과 분산은 이 분포의 중심과 스케일을 요약한다. 다만 평균과 분산만으로 복잡한 다봉 분포의 모든 구조를 알 수는 없다. 그래도 latent가 표준정규에 맞게 잘 정규화되어 있는지, 특정 차원이 거의 쓰이지 않는지, diffusion noise schedule과 스케일이 맞는지는 점검할 수 있다.

Diffusers의 AutoencoderKL도 scaling_factor를 가진다. Stable Diffusion 계열에서 자주 보이는 0.18215 같은 값은 latent를 diffusion 모델에 넣기 전 단위 분산에 가깝게 맞추기 위한 스케일이다. 이 값은 모든 VAE에 보편적인 상수가 아니라 모델과 학습 설정에 묶인 구현 세부사항이다.

Stable Diffusion에서 VAE가 실제로 맡는 일

Stable Diffusion의 VAE를 “그림을 작게 줄이는 모듈” 정도로만 보면 부족하다. VAE는 diffusion이 일할 좌표계를 미리 만든다. 이 좌표계가 좋아야 U-Net이 노이즈를 더하고 빼는 일이 쉬워진다.

훈련 과정을 분리해서 보면 더 선명하다.

1. Autoencoder/VAE를 먼저 학습한다.
   x -> E(x) -> z -> D(z) -> x_hat

2. 학습된 encoder/decoder를 고정하거나 재사용한다.
   z0 = E(x)

3. diffusion U-Net은 pixel이 아니라 z0에 노이즈를 섞고 제거하는 법을 배운다.
   z_t = sqrt(alpha_bar_t) z0 + sqrt(1 - alpha_bar_t) epsilon

추론할 때는 반대다. 처음부터 이미지를 압축하지 않는다. 표준정규에 가까운 latent noise에서 시작한다.

z_T ~ N(0, I)
z_T -> z_{T-1} -> ... -> z_0
image = Decoder(z_0)

여기서 decoder는 “아무 latent나 이미지로 바꾸는 마술 상자”가 아니다. 자신이 학습한 latent 공간 근처의 표현을 가장 잘 복원한다. 그래서 diffusion U-Net은 decoder가 이해할 수 있는 latent manifold 근처로 샘플을 이동시켜야 한다.

Latent Diffusion 논문은 이 지점을 “복잡도 감소와 디테일 보존 사이의 균형”으로 본다. 너무 강하게 압축하면 U-Net은 빨라지지만 디테일이 사라진다. 너무 약하게 압축하면 픽셀 diffusion과 비용 차이가 줄어든다. Stable Diffusion 계열에서 VAE가 이미지의 약 8배 downsampling latent를 쓰는 것도 이 균형점의 한 예다.

latent의 평균과 분산으로 무엇을 알 수 있나

VAE encoder가 각 이미지마다 mu_i, sigma_i를 낸다면, 데이터셋 전체 latent 분포는 개별 posterior들의 평균적인 혼합으로 볼 수 있다.

q_phi(z) ~= (1 / N) sum_i q_phi(z | x_i)

이때 전체 평균과 공분산은 다음처럼 요약할 수 있다.

m = mean_i(mu_i)
Sigma = mean_i(diag(sigma_i^2) + mu_i mu_i^T) - m m^T

이 식은 “샘플을 여러 번 뽑아 봐야만 분포를 알 수 있다”는 뜻이 아니다. q_phi(z | x)를 대각 가우시안으로 둔 VAE에서는 encoder가 낸 mu, sigma만으로 1차/2차 모멘트를 계산할 수 있다.

다만 평균과 분산이 분포의 모든 것을 말해 주는 것은 아니다. 데이터셋 전체의 aggregated posterior는 복잡한 혼합분포일 수 있다. 평균과 공분산은 중심, 스케일, 축별 사용량, collapse 여부를 보는 데 유용하지만, 여러 모드가 어떻게 갈라지는지까지 완전히 설명하지는 못한다.

실무적으로는 다음을 점검할 수 있다.

모델 변형은 어디가 다른가

Diffusion 계열 이름이 많지만, 처음에는 아래처럼 구분하면 충분하다.

다른 생성 모델과 비교하면

헷갈리기 쉬운 표현들

“Stable Diffusion은 비지도 학습인가?”

문제 범주로는 비지도 생성 모델이라고 말할 수 있다. 외부 라벨 없이 이미지 데이터의 분포를 모델링할 수 있기 때문이다. 하지만 학습 구현은 자기지도에 가깝다. 우리가 직접 만든 노이즈 epsilon을 정답으로 삼아 예측하게 하므로, “라벨이 전혀 없는 순수 무감독 최적화”처럼 이해하면 조금 어긋난다.

“모델은 원본 이미지를 복원하는가?”

학습 중에는 x0에서 만든 x_t를 보고 노이즈를 맞힌다. 하지만 생성 시 목표는 특정 학습 이미지를 되살리는 것이 아니다. 순수 노이즈에서 출발해 데이터 분포의 고밀도 영역으로 이동하고, 그 결과 학습 데이터와 통계적으로 비슷한 새 샘플을 만든다.

“latent 채널은 사람이 읽을 수 있는 의미 축인가?”

대체로 아니다. latent 값은 공간적 위치와 어느 정도 대응하지만, 각 채널이 RGB처럼 명시적인 의미를 갖지는 않는다. 어떤 방향이 조명, 스타일, 나이, 표정 같은 속성과 상관될 수는 있지만, 이는 분석이나 조작으로 찾아낸 방향이지 모델이 처음부터 사람이 읽기 좋게 이름 붙인 축은 아니다.

“VAE는 정확한 데이터 밀도를 구하는가?”

정확한 marginal likelihood는 보통 직접 계산하기 어렵다. VAE는 variational lower bound를 최적화해 근사 inference와 generation을 가능하게 만든다. 따라서 “intractable density를 직접 구한다”보다 “intractable posterior/lower bound 문제를 다룰 수 있게 만든다”가 더 정확하다.

“AE/VAE의 파라미터는 latent 값 자체인가?”

아니다. x, z, mu, sigma, x_hat은 forward pass에서 계산되는 데이터 또는 activation이다. 학습되는 파라미터는 encoder와 decoder 안의 weight, bias, convolution kernel 같은 값들이다. mu와 sigma는 encoder 파라미터가 직접 저장한 상수가 아니라, 입력 x와 현재 파라미터로 계산한 출력이다.

“latent의 한 칸은 원본 8 x 8 픽셀을 정확히 뜻하는가?”

공간 해상도가 8배 줄어든 모델에서는 대략적인 위치 대응이 있다. 하지만 한 latent cell이 원본의 독립적인 8 x 8 패치를 그대로 뜻한다고 보면 안 된다. convolution, attention, decoder의 receptive field 때문에 주변 latent와 함께 해석된다. 위치 대응은 있지만, 의미 대응은 분산되어 있다.

한 번에 정리하기

Diffusion 모델은 노이즈를 더하는 쉬운 과정을 먼저 정하고, 그 반대 방향을 학습한다. 모델은 원본 이미지를 외우는 대신, 각 노이즈 수준에서 데이터 밀도가 높아지는 방향을 배운다. 그래서 샘플링은 순수한 노이즈가 학습된 score field를 따라 자연 이미지의 매니폴드 쪽으로 이동하는 과정으로 볼 수 있다.

Stable Diffusion은 이 과정을 픽셀 공간이 아니라 VAE latent 공간에서 수행한다. VAE는 이미지를 더 작은 연속 latent로 압축하고, U-Net은 그 latent에서 노이즈를 예측하며, decoder는 마지막 latent를 다시 이미지로 펼친다. 덕분에 고해상도 이미지를 훨씬 적은 계산량으로 생성할 수 있다.

결국 Diffusion을 이해하는 핵심은 세 가지다.

1. forward process: 우리가 데이터를 노이즈로 망가뜨린다.
2. denoising objective: 모델은 섞인 노이즈 또는 score를 배운다.
3. reverse sampling: 배운 방향장을 따라 노이즈에서 새 샘플을 꺼낸다.

밤하늘이 처음에는 검은 면처럼 보이다가 눈이 적응하면 별자리의 구조가 드러나는 것처럼, diffusion도 처음에는 무작위 노이즈에서 시작한다. 다만 그 별자리를 상상으로 그리는 것이 아니라, 데이터가 남긴 확률적 방향을 따라 한 단계씩 찾아간다.

참고한 자료

• Notion: Diffusion
• Notion: Diffusion & Latent
• Notion: VAE(Variational Auto-Encoder)
• Notion: VAE 인코더와 디코더
• Notion: propagation에서 손실을 구하기 위한 비교는 어떻게 하는가?
• Autoencoders, Minimum Description Length and Helmholtz Free Energy
• Reducing the Dimensionality of Data with Neural Networks
• Denoising Diffusion Probabilistic Models
• Denoising Diffusion Implicit Models
• Score-Based Generative Modeling through Stochastic Differential Equations
• High-Resolution Image Synthesis with Latent Diffusion Models
• Auto-Encoding Variational Bayes
• Classifier-Free Diffusion Guidance
• Consistency Models
• Latent Consistency Models: Synthesizing High-Resolution Images with Few-Step Inference
• Hugging Face Diffusers AutoencoderKL documentation

Loki는 이 문제를 Elasticsearch류 검색 엔진과 다른 방식으로 푼다. 로그 본문 전체를 색인해서 모든 단어를 빠르게 찾는 모델이 아니라, 라벨과 시간으로 로그 stream을 좁히고, 압축된 chunk 안의 로그를 스캔하는 모델이다.

그래서 Loki를 이해할 때 가장 먼저 기억할 문장은 이것이다.

Loki는 로그 본문 전체가 아니라, 로그의 라벨을 중심으로 색인한다.

Loki는 무엇이 아닌가

Loki는 APM이 아니다. 요청 하나의 call stack을 보여주거나, 서비스 간 span 관계를 자동으로 그려주는 도구가 아니다. 그 역할은 Pinpoint, Tempo, Jaeger, 상용 APM, 또는 OpenTelemetry trace backend 쪽에 가깝다.

Loki는 로그 저장과 조회를 맡는다. Grafana를 UI로 붙이고, LogQL로 로그를 조회한다. 특히 Kubernetes처럼 많은 컨테이너가 stdout/stderr로 로그를 흘려보내는 환경에서 잘 맞는다.

Elasticsearch 계열과 비교하면 의도적인 포기가 있다. Loki는 모든 로그 본문을 색인하지 않는다. 대신 라벨 색인을 작게 유지하고, 로그 본문은 chunk로 저장한다. 이 덕분에 저장 비용과 색인 비용을 줄일 수 있지만, 쿼리할 때는 라벨과 시간 범위를 잘 좁혀야 한다.

쓰기 경로

Loki의 write path는 보통 다음 순서로 흐른다.

Distributor는 들어온 로그의 timestamp, label, tenant 등을 검증한다. 그 뒤 label set 기준으로 stream을 계산하고, consistent hashing ring을 통해 Ingester를 고른다. 일반적인 운영 구성에서는 replication factor와 quorum write가 함께 쓰인다.

Ingester는 받은 로그를 즉시 object storage에 한 줄씩 쓰지 않는다. stream별로 memory chunk를 만들고, 일정 크기나 시간이 되면 flush한다. flush 전에 죽었을 때 데이터를 잃지 않도록 WAL을 쓴다.

여기서 중요한 점은 WAL이 영구 저장소의 주인공이 아니라는 것이다. WAL은 미flush chunk를 보호하는 복구 장치에 가깝고, 장기 저장은 chunk와 index를 가진 object storage가 맡는다.

읽기 경로

읽기는 쓰기보다 더 많은 최적화가 필요하다. 사용자는 Grafana에서 LogQL을 실행하고, Loki는 해당 쿼리를 시간 범위별, label set별로 잘게 나누어 처리한다.

기본적인 LogQL은 label selector에서 시작한다.

{service_name="order-api", namespace="prod"} |= "ERROR"

JSON 로그라면 pipeline stage를 붙일 수 있다.

{service_name="order-api"} | json | status >= 500

여기서 오해하면 안 되는 점이 있다. Loki가 로그 본문을 색인하지 않는다고 해서 본문 검색이 불가능한 것은 아니다. 본문 검색은 가능하다. 다만 먼저 라벨과 시간으로 읽을 chunk를 줄이고, 그 chunk 안의 로그 라인을 스캔하는 방식이다. 그래서 좋은 LogQL은 항상 적절한 label selector와 좁은 시간 범위에서 시작한다.

라벨 설계가 거의 전부다

Loki 운영에서 가장 자주 문제가 되는 것은 라벨 카디널리티다.

라벨은 로그 source를 설명하는 낮은 카디널리티 값이어야 한다. 공식 문서도 라벨은 low-cardinality 값을 저장하기 위한 것이고, high-cardinality 데이터는 structured metadata를 쓰라고 안내한다.

traceId를 라벨로 올리고 싶어지는 순간이 많다. 장애 상황에서 특정 요청을 바로 찾고 싶기 때문이다. 하지만 요청마다 다른 값을 라벨로 만들면 stream 수가 폭발한다. Loki는 작은 index로 비용을 줄이는 도구인데, 이런 라벨 설계는 그 장점을 스스로 버리는 셈이다.

더 나은 방식은 trace id를 JSON 필드나 structured metadata로 남기는 것이다. 조회할 때는 먼저 {service_name="order-api"}처럼 source를 좁힌 다음, | json | trace_id="..." 같은 pipeline으로 본문 또는 metadata를 필터링한다.

Spring Boot 로그는 어떻게 보내는가

Spring Boot는 starters를 쓰면 기본적으로 Logback을 사용하고, 로그는 console output으로 나간다. 컨테이너와 Kubernetes 환경에서는 이 기본값이 오히려 좋은 출발점이다. 애플리케이션은 stdout/stderr로 로그를 내고, 노드나 Pod 옆의 수집기가 그 로그를 읽어 Loki로 보낸다.

운영 관점에서 권장 순서는 보통 이렇다.

1. stdout/stderr -> Grafana Alloy -> Loki
2. stdout/stderr 또는 OTLP logs -> OpenTelemetry Collector -> Loki
3. Logback appender -> Loki 직접 push

직접 push 방식은 빠른 PoC에는 편하다. 예를 들어 loki-logback-appender 같은 third-party appender를 쓰면 애플리케이션이 Loki push API로 바로 로그를 보낼 수 있다. 하지만 이 방식은 애플리케이션 요청 경로 근처에 네트워크 실패, queue 적체, retry, backpressure 문제가 붙는다. 운영에서는 timeout, buffer, drop 정책, 장애 격리를 반드시 정해야 한다.

OTel Collector를 거쳐 Loki로 보낼 때는 공식 Loki 문서의 OTLP HTTP 경로를 따르는 것이 좋다.

exporters:
  otlphttp:
    endpoint: http://loki:3100/otlp

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

여기서 Collector 설정의 endpoint는 http://loki:3100/otlp다. Loki의 실제 로그 ingest API 경로는 그 아래의 /otlp/v1/logs이지만, Collector exporter 설정에 전체 경로를 직접 쓰는 식으로 혼동하지 않는 편이 안전하다.

Promtail은 이제 과거 방식이다

과거 Loki 예제에는 Promtail이 자주 등장한다. 하지만 2026년 6월 8일 기준 공식 문서는 Promtail이 2026년 3월 2일 EOL이라고 명시한다. 상용 지원도 끝났고, 앞으로의 기능 개발은 Grafana Alloy에서 이루어진다.

따라서 새로 구성한다면 Promtail을 기본 선택지로 두지 않는 것이 맞다. 기존 Promtail 운영 환경은 Alloy 또는 다른 지원 클라이언트로 마이그레이션하는 계획을 세워야 한다.

운영 체크리스트

Loki를 운영할 때는 아래 항목을 먼저 정리한다.

• label은 적게 시작한다. 늘리는 것은 쉽지만, 줄이는 것은 운영 데이터와 대시보드에 영향을 준다.
• object storage를 기준으로 장기 저장을 설계한다. filesystem은 로컬 개발이나 작은 PoC에 가깝다.
• retention은 Compactor와 함께 설계한다. bucket lifecycle만 믿으면 Loki의 index와 chunk 관점에서 꼬일 수 있다.
• Java stack trace는 multiline 처리 없이는 여러 로그로 쪼개진다. Alloy loki.process의 multiline stage나 JSON logging 전략을 검토한다.
• 민감정보는 Loki로 보내기 전에 마스킹한다.
• 멀티테넌시를 쓰면 X-Scope-OrgID 처리와 tenant 격리를 명확히 한다.
• 대시보드 쿼리는 항상 label selector와 시간 범위를 좁힌다.
• 직접 appender 방식은 장애 격리, queue 크기, timeout, retry, drop 정책을 문서화한다.

Loki는 모든 로그를 기억하려는 도구가 아니다. 먼저 “어느 별자리에서 온 빛인가”를 라벨로 좁히고, 그 안에서 필요한 로그 라인을 천천히 읽는다. 이 방식은 단순해 보이지만, 대량 로그의 비용을 조용히 낮춘다. 대신 라벨 설계가 흐트러지면 그 단순함은 바로 깨진다.

참고한 자료

• Grafana Loki Architecture
• Grafana Loki Labels
• Grafana Loki OpenTelemetry ingestion
• Grafana Loki Promtail agent
• Spring Boot Logging

trace는 APM 제품의 agent가 만들고, metric은 다른 exporter가 만들고, log는 또 다른 수집기가 가져간다. 이름도 다르고, attribute도 다르고, 전송 프로토콜도 다르다. 나중에 backend를 바꾸려 하면 애플리케이션 곳곳에 묶인 설정과 계측 코드가 발목을 잡는다.

OpenTelemetry는 이 지점을 표준화하려는 프로젝트다. 관측성 backend 자체가 아니라, telemetry data를 만들고, 전파하고, 수집하고, 내보내는 공통 언어에 가깝다.

OpenTelemetry = instrumentation + data model + protocol + collector

OpenTelemetry는 backend가 아니다

공식 문서는 OpenTelemetry를 observability framework and toolkit이라고 설명한다. telemetry data의 generation, export, collection을 돕지만, observability backend 자체는 아니다. 저장과 시각화는 의도적으로 다른 도구에게 맡긴다.

이 구분이 중요하다.

• Pinpoint는 Agent, Collector, 저장소, UI를 함께 가진 APM이다.
• Loki는 로그 저장과 조회를 맡는 backend다.
• OpenTelemetry는 이들 앞단에서 telemetry를 표준 형식으로 만들고 흘려보내는 계층이다.

그래서 OpenTelemetry를 도입한다고 해서 대시보드가 자동으로 생기지는 않는다. 대신 trace, metric, log를 여러 backend로 보낼 수 있는 공통 파이프라인이 생긴다.

Signal: traces, metrics, logs, baggage

OpenTelemetry를 처음 볼 때는 세 가지 signal만 기억하기 쉽다.

traces
metrics
logs

하지만 개념적으로는 baggage도 중요하다. baggage는 서비스 경계를 넘어 함께 전파되는 key-value context다. 모든 데이터가 backend로 저장되는 관측성 signal이라고 보기는 조심스럽지만, trace/log/metric에 붙을 문맥을 이동시키는 역할을 한다.

Trace 안에서는 span이 기본 단위다. 하나의 HTTP 요청, DB query, message publish, 내부 작업 하나가 span이 될 수 있다. span들은 trace id를 공유하고, parent-child 관계로 이어진다.

Java와 Spring에서는 어떻게 붙는가

Java 애플리케이션에서는 크게 두 가지 접근이 있다.

하나는 zero-code instrumentation이다. OpenTelemetry Java Agent를 JVM 옵션으로 붙이면, 지원되는 라이브러리와 프레임워크에 대해 자동 계측이 들어간다.

java \
  -javaagent:/path/to/opentelemetry-javaagent.jar \
  -Dotel.service.name=order-api \
  -jar app.jar

환경 변수로도 설정할 수 있다.

export JAVA_TOOL_OPTIONS="-javaagent:/path/to/opentelemetry-javaagent.jar"
export OTEL_SERVICE_NAME="order-api"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://otel-collector:4318"
java -jar app.jar

다른 하나는 code-based instrumentation이다. 애플리케이션 코드에서 OpenTelemetry API를 직접 사용해 span, metric, attribute를 기록한다. 자동 계측이 놓치는 비즈니스 구간을 표시하거나, 더 의미 있는 attribute를 붙이고 싶을 때 쓴다.

Spring Boot에서는 Java Agent가 가장 직접적인 출발점인 경우가 많다. 다만 native image, agent 충돌, Spring 설정 파일 기반 관리가 중요하다면 Spring Boot starter 방식도 검토할 수 있다. 핵심은 둘 중 무엇을 쓰든 service.name과 resource attribute를 명시적으로 정하는 것이다.

Resource는 telemetry의 주소다

OpenTelemetry에서 resource는 telemetry를 만든 주체를 설명한다. 예를 들어 service.name, service.namespace, deployment.environment.name, k8s.namespace.name, k8s.cluster.name 같은 값이 여기에 들어간다.

공식 문서는 service.name을 명시적으로 설정할 것을 권장한다. 설정하지 않으면 SDK가 unknown_service 같은 기본값을 넣을 수 있다. backend에서 수많은 unknown_service를 보면, 이미 관측성의 첫 단추가 풀린 것이다.

좋은 resource 설계는 backend를 바꿔도 오래 남는다. 반대로 여기서 이름이 흔들리면 trace, metric, log를 서로 연결하는 일이 계속 어려워진다.

Collector는 작은 telemetry 라우터다

OpenTelemetry Collector는 telemetry를 받아서, 처리하고, 내보내는 독립 프로세스다.

Collector 설정은 보통 네 덩어리로 읽는다.

• receivers: 데이터를 받는다. 예: OTLP, Prometheus, Kafka, Fluent Forward.
• processors: 데이터를 가공한다. 예: batch, memory_limiter, attributes, tail_sampling.
• exporters: 데이터를 보낸다. 예: OTLP, Prometheus Remote Write, Loki OTLP HTTP, debug.
• service.pipelines: 어떤 receiver, processor, exporter를 실제로 연결할지 정한다.

중요한 점은 component를 정의하는 것만으로는 활성화되지 않는다는 것이다. 공식 문서도 receiver는 service 섹션의 pipeline에 추가되어야 활성화된다고 설명한다.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  otlp:
    endpoint: tempo:4317

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Agent pattern과 Gateway pattern

Collector 배포는 크게 두 가지로 시작할 수 있다.

Agent pattern은 애플리케이션과 가까워 장애 격리와 로컬 전처리에 유리하다. Gateway pattern은 정책과 exporter 설정을 중앙에서 관리하기 쉽다. 실제 운영에서는 Agent-to-Gateway처럼 둘을 섞는 경우도 많다.

tail sampling을 gateway에서 하고 싶다면 한 가지를 더 봐야 한다. tail sampling은 trace 전체 또는 대부분의 span을 본 뒤 sampling 여부를 정한다. 따라서 같은 trace의 span들이 같은 Collector로 모여야 한다. OpenTelemetry 공식 gateway 문서도 이런 경우 trace ID 또는 service-name aware load balancing을 언급한다.

Sampling은 비용과 정보의 균형이다

모든 trace를 저장하는 것은 가장 단순하지만 가장 비싸다. 그래서 sampling을 설계한다.

Head sampling은 trace 초반에 결정을 내린다. 단순하고 효율적이지만, 나중에 오류가 났는지, 전체 latency가 어땠는지 보고 결정할 수 없다.

Tail sampling은 trace가 끝난 뒤 전체 span을 보고 결정한다. 오류 trace를 항상 남기거나, latency가 긴 trace를 더 많이 남기는 식의 정책을 만들 수 있다. 대신 stateful하고 운영 비용이 크다.

Pinpoint, Loki와 함께 보면

세 도구를 같이 놓으면 역할이 선명해진다.

OpenTelemetry는 Pinpoint나 Loki를 단순히 대체하지 않는다. 오히려 시스템이 커질수록 이들 사이의 언어를 맞추는 층이 된다. trace id를 로그에 함께 남기고, Loki에서 해당 trace id를 찾고, trace backend에서 전체 요청을 따라가는 식의 연결이 가능해진다.

운영 체크리스트

OpenTelemetry를 도입할 때는 아래 항목부터 고정한다.

• service.name을 반드시 명시한다. unknown_service가 생기면 나중에 정리가 어렵다.
• resource attribute 이름을 조직 표준으로 정한다.
• 자동 계측과 수동 계측의 경계를 정한다. 자동 계측은 넓게, 수동 계측은 비즈니스 의미가 있는 구간에만 둔다.
• Collector pipeline에서 component 정의와 pipeline 활성화를 구분한다.
• OTLP gRPC 4317과 HTTP 4318을 혼동하지 않는다.
• sampling 정책을 비용 절감만으로 정하지 않는다. 장애 분석에 필요한 trace를 남겨야 한다.
• PII나 token 같은 민감정보가 attribute, baggage, log body로 흘러가지 않게 필터링한다.
• backend별 제한을 확인한다. 같은 OTel 데이터라도 Loki, Prometheus, trace backend가 받아들이는 label/attribute/cardinality 모델은 다르다.

OpenTelemetry는 별을 직접 보여주는 망원경이라기보다, 별빛을 같은 언어로 모으는 관측 장치에 가깝다. 어디에 저장하고 어떻게 볼지는 다른 도구가 맡는다. 대신 한 번 정돈된 telemetry pipeline은 backend가 바뀌어도 오래 남는다.

참고한 자료

• OpenTelemetry: What is OpenTelemetry?
• OpenTelemetry Collector Configuration
• OpenTelemetry OTLP Specification
• OpenTelemetry Java Agent Getting Started
• OpenTelemetry Sampling
• OpenTelemetry Resources
• OpenTelemetry Collector Agent Pattern
• OpenTelemetry Collector Gateway Pattern

요청은 분명 하나였는데, 그 요청은 API 서버를 지나고, 내부 HTTP 호출을 지나고, 메시지 큐와 데이터베이스를 지나며 여러 조각으로 흩어진다. 로그만으로 따라가려면 각 서비스의 시간, 요청 ID, 스레드, 예외를 하나씩 맞춰야 한다.

Pinpoint는 이 흩어진 요청을 하나의 흐름으로 다시 묶어 보여주는 APM이다. 로그 저장소도 아니고, OpenTelemetry 같은 표준 계측 규격도 아니다. 애플리케이션에 붙는 Agent, 데이터를 받는 Collector, 저장소, 그리고 UI를 함께 갖춘 완성형 Application Performance Management 도구에 가깝다.

Pinpoint의 위치

Pinpoint를 한 문장으로 줄이면 이렇게 말할 수 있다.

Pinpoint = Java Agent 중심의 분산 트랜잭션 추적 APM

공식 README도 Pinpoint를 대규모 분산 시스템을 위한 APM으로 설명한다. Java, PHP, Python 애플리케이션을 지원하고, Google Dapper에서 영감을 받은 분산 트랜잭션 추적 모델을 사용한다. 특히 Java 환경에서는 -javaagent로 애플리케이션에 붙어 코드 수정 없이 요청 흐름을 수집하는 것이 핵심이다.

Pinpoint가 제공하는 가치는 주로 네 가지다.

• ServerMap으로 서비스 간 호출 관계를 본다.
• Scatter나 Heatmap으로 느린 요청과 오류 요청을 찾는다.
• CallStack으로 한 요청의 내부 호출 순서를 본다.
• Inspector로 JVM, thread, CPU, memory, GC 같은 애플리케이션 상태를 본다.

그래서 Pinpoint는 “어떤 서비스가 느린가”에서 멈추지 않고, “그 요청 안에서 어떤 메서드와 외부 호출이 시간을 썼는가”까지 내려가려는 도구다.

전체 구조

Pinpoint는 단일 바이너리 하나로 끝나는 도구가 아니다. 공식 설치 문서 기준으로 핵심 구성요소는 HBase, Pinot, Collector, Web, Agent다.

각 구성요소의 역할은 다음처럼 나눠서 보는 편이 안전하다.

Java Agent는 어떻게 끼어드는가

Pinpoint Java Agent는 JVM 시작 옵션에 붙는다.

java \
  -javaagent:/path/to/pinpoint-agent/pinpoint-bootstrap-3.1.0.jar \
  -Dpinpoint.agentId=order-api-1 \
  -Dpinpoint.applicationName=order-api \
  -jar app.jar

여기서 agentId는 개별 인스턴스를 구분하고, applicationName은 같은 서비스를 이루는 여러 인스턴스를 묶는다. 컨테이너 환경에서는 배포 때마다 agentId가 계속 새로 생기면 UI에 과거 인스턴스가 지저분하게 남을 수 있다. 공식 설치 문서도 이런 환경에서는 컨테이너 옵션을 함께 검토하라고 안내한다.

Agent가 애플리케이션 코드를 추적하는 방식은 bytecode instrumentation이다. 클래스가 로딩되는 시점에 Pinpoint가 관심 있는 메서드 주변에 interceptor를 넣고, 호출 전후에 필요한 데이터를 기록한다.

이 방식의 장점은 분명하다.

• 애플리케이션 코드를 거의 수정하지 않아도 된다.
• Spring MVC, WebFlux, JDBC, Redis, Kafka, HTTP Client 같은 라이브러리 호출을 자동으로 추적할 수 있다.
• 요청 하나의 내부 호출 관계를 CallStack으로 자세히 볼 수 있다.

하지만 공짜는 아니다. bytecode instrumentation은 애플리케이션 코드 실행 경로에 개입한다. 공식 기술 문서도 profiling 부분에 문제가 생기면 애플리케이션에 영향을 줄 수 있다고 설명한다. 그래서 운영 도입 전에는 지원 라이브러리, Agent 버전, sampling 설정, 성능 영향을 반드시 검증해야 한다.

TraceId는 하나의 요청을 묶는 실이다

Pinpoint의 trace 모델에서 가장 중요한 단어는 TransactionId, SpanId, ParentSpanId다.

공식 문서 기준으로 Pinpoint의 TraceId는 이 세 값의 묶음이다. 여기서 TransactionId는 Dapper나 일반적인 tracing 문맥의 trace id에 가까운 값이고, SpanId와 ParentSpanId가 RPC 간 부모-자식 관계를 만든다.

예를 들어 order-api가 payment-api를 호출하면 order-api의 Agent는 outbound 호출에 trace 정보를 넣는다. payment-api의 Agent는 그 정보를 읽고 같은 TransactionId를 가진 child span을 만든다. 이렇게 하면 UI에서는 “주문 요청 하나가 결제 서비스와 DB 호출에서 어디까지 갔는지”를 한 장의 call tree로 볼 수 있다.

HBase와 Pinot를 구분해서 보자

Pinpoint 저장 구조에서 자주 헷갈리는 지점은 HBase, Kafka, Pinot의 관계다.

핵심 trace와 call stack은 HBase 축으로 이해하는 것이 맞다. Collector와 Web은 HBase를 trace 저장 백엔드로 사용하고, HBase schema에는 trace와 application trace index 성격의 테이블들이 있다.

반면 Pinot는 metric data storage에 가깝다. System Metric, URI Statistics, Error Analysis, New Inspector 같은 기능을 위해 Kafka stream ingestion과 Pinot table이 필요하다.

따라서 “Kafka가 Agent와 Collector 사이에서 모든 trace를 중계한다”고 이해하면 부정확하다. Agent는 Collector로 데이터를 보내고, Kafka는 주로 Pinot 기반 분석 기능을 위한 stream ingestion 축으로 설명하는 편이 공식 문서와 맞다.

OpenTelemetry와의 관계

OpenTelemetry는 observability backend가 아니다. 공식 문서의 설명처럼 telemetry data를 생성, export, collection하기 위한 vendor-agnostic framework이자 toolkit이다. 저장과 시각화는 Jaeger, Prometheus, Loki, Tempo, 상용 APM 같은 다른 도구가 담당한다.

Pinpoint는 이와 다르다. Pinpoint는 자체 Agent, Collector, 저장소, Web UI를 가진 APM이다.

다만 둘이 완전히 단절된 것도 아니다. Pinpoint v3.1.0 공식 릴리스에는 OpenTelemetry Metric Collection이 들어갔다. 그래서 현재 기준으로는 “Pinpoint는 OTel과 관계가 없다”고 쓰기보다, “Pinpoint는 OTel 표준 계측 계층과 성격이 다르며, v3.1.0 릴리스에서 명확히 강조된 연결점은 OTLP metric 수집이다”라고 쓰는 편이 정확하다. 반대로 Pinpoint를 일반적인 OTLP trace/log backend처럼 설명하는 것은 조심해야 한다.

언제 Pinpoint가 잘 맞는가

Pinpoint는 이런 상황에서 특히 잘 맞는다.

• Java/Spring 기반 서비스가 많다.
• 분산 요청의 call stack과 병목 지점을 UI에서 바로 보고 싶다.
• 코드 수정 없이 APM을 빠르게 붙이고 싶다.
• 서비스 간 topology, active thread, scatter chart, inspector를 한 화면에서 보고 싶다.

반대로 이런 경우에는 도입 전에 더 신중해야 한다.

• 이미 OpenTelemetry 중심으로 표준화된 telemetry pipeline이 있다.
• 여러 언어와 여러 backend로 이식 가능한 계측 표준이 더 중요하다.
• HBase, Pinot, Kafka까지 운영할 여력이 부족하다.
• Agent의 bytecode instrumentation 리스크를 받아들이기 어렵다.

운영 체크리스트

Pinpoint를 운영에 올릴 때는 기능보다 먼저 아래 항목을 봐야 한다.

• Agent와 Collector 버전을 맞춘다. 공식 README 기준 3.1.x Agent는 3.1.x Collector와 맞춰야 한다.
• Pinpoint v3.1.x README 기준 Collector, Web, Batch는 Java 17이 필요하고, Agent는 Java 8부터 25까지를 지원한다.
• HBase는 2.x, Pinot는 1.3.0 호환 기준을 먼저 확인한다.
• Agent sampling을 정한다. 전수 수집은 네트워크, Collector, HBase, Pinot 비용을 빠르게 키운다.
• HBase TTL과 compaction, region 분산, hotspot을 모니터링한다.
• Pinot/Kafka가 필요한 기능과 필요 없는 기능을 구분한다.
• 컨테이너 환경에서는 agentId 전략을 정한다.
• 장애 시 Agent를 제거하거나 비활성화하는 rollback 절차를 준비한다.

Pinpoint는 조용히 지나가는 요청에 작은 표식을 남긴다. 그 표식들이 Collector와 저장소를 지나 UI에 모이면, 시스템은 더 이상 검은 상자가 아니다. 다만 그만큼 운영해야 할 구성요소도 늘어난다. Pinpoint를 선택한다는 것은 편한 APM 화면뿐 아니라, 그 화면을 만드는 trace 저장소와 Agent 생태계까지 함께 책임진다는 뜻이다.

참고한 자료

• Pinpoint 공식 GitHub
• Pinpoint Installation Guide
• Pinpoint Tech Details
• Pinpoint v3.1.0 Release
• OpenTelemetry: What is OpenTelemetry?

autovacuum: VACUUM public.some_table (to prevent wraparound)

문구만 보면 평소 autovacuum과 비슷해 보인다. 하지만 이 작업은 단순히 dead tuple을 치우는 청소에 가깝지 않다. PostgreSQL이 MVCC의 시간 감각을 잃지 않도록, 아주 오래된 transaction ID를 안전한 상태로 정리하는 생존 작업에 가깝다.

이 글은 세 가지 질문을 기준으로 정리한다.

왜 transaction ID가 한 바퀴 도는 것이 위험한가
VACUUM FREEZE와 relfrozenxid는 무엇을 안전하게 만드는가
운영에서는 어떤 지표와 습관으로 이 일을 미리 제어해야 하는가

PostgreSQL의 row는 시간표를 들고 있다

PostgreSQL은 MVCC, 즉 multi-version concurrency control을 사용한다. 어떤 트랜잭션이 row를 읽을 때, 지금 저장된 값 하나만 보는 것이 아니라 “내 스냅샷에서 보이는 row version이 무엇인가”를 판단한다.

그 판단에 중요한 값이 row version의 xmin과 xmax다.

그래서 PostgreSQL에서 UPDATE는 보통 제자리 덮어쓰기가 아니다. 기존 row version의 xmax를 채워 과거 버전으로 만들고, 현재 transaction ID를 xmin으로 가진 새 row version을 만든다.

이 방식 덕분에 읽기와 쓰기는 덜 충돌한다. 읽는 쪽은 자기 스냅샷에 맞는 과거 버전을 볼 수 있고, 쓰는 쪽은 새 버전을 만들 수 있다. 대신 오래된 버전이 계속 남으므로, 언젠가는 vacuum이 필요하다.

XID wraparound가 왜 문제가 되는가

PostgreSQL의 일반 transaction ID, 즉 XID는 32비트 공간을 사용한다. 그래서 충분히 오래 운영되고 transaction이 계속 발생하면 숫자는 언젠가 한 바퀴 돈다.

여기서 헷갈리기 쉬운 부분이 있다.

XID 공간 자체는 32비트라 약 40억 개다.
하지만 MVCC 비교에서 안전하게 과거/미래를 구분하는 창은 양쪽 약 20억 개다.

PostgreSQL 공식 문서는 일반 XID 공간을 원형 공간으로 설명한다. 어떤 XID를 기준으로 약 20억 개는 더 오래된 XID이고, 다른 약 20억 개는 더 새로운 XID다. 그래서 row version이 만들어진 뒤 약 20억 transaction 이상 제대로 정리되지 않으면, 원래는 과거였던 row version이 갑자기 미래의 row처럼 해석될 수 있다.

그 결과는 단순 성능 저하가 아니다. 데이터는 물리적으로 남아 있어도 MVCC visibility 판단에서 보이지 않는 것처럼 해석될 수 있다. PostgreSQL 문서가 이 상황을 매우 강하게 경고하는 이유가 여기에 있다.

따라서 wraparound 대응의 핵심은 XID가 증가하지 못하게 막는 것이 아니다. XID는 계속 증가하고, 언젠가 돈다. 핵심은 너무 오래된 row version을 일반 XID 비교 대상에서 빼내는 것이다.

Freeze는 row를 없애지 않는다

VACUUM은 충분히 오래된 row version을 frozen 상태로 만든다. frozen row version은 모든 현재와 미래의 정상 트랜잭션에서 이미 과거의 row로 취급된다.

중요한 점은 이것이다.

freeze는 row를 조회 불가능하게 만드는 작업이 아니다.
오히려 그 row version을 항상 과거로 안전하게 확정하는 작업이다.

공식 문서 기준으로 frozen row version은 FrozenTransactionId로 삽입 XID를 가진 것처럼 취급된다. 다만 최신 PostgreSQL에서는 예전처럼 실제 xmin을 항상 FrozenTransactionId 값으로 물리 치환한다고 단정하면 안 된다. PostgreSQL 9.4 이후에는 원래 xmin을 보존하고 tuple flag bit로 frozen 상태를 표시할 수 있다. 그러니 글이나 코드에서 “반드시 xmin = 2로 바뀐다”고 설명하는 것은 부정확하다.

개념적으로만 이렇게 이해하면 안전하다.

일반 row version:
  xmin을 스냅샷과 비교해야 visibility를 판단할 수 있다.

frozen row version:
  이미 충분히 오래된 과거로 확정되어 XID 비교 부담에서 벗어난다.

frozen row를 UPDATE하면 freeze가 풀려서 같은 row가 제자리 수정되는 것이 아니다. PostgreSQL의 일반 MVCC 규칙대로 기존 frozen tuple은 과거 버전으로 남고, 현재 transaction ID를 가진 새 tuple이 만들어진다.

relfrozenxid는 테이블의 안전 기준선이다

PostgreSQL은 테이블마다 pg_class.relfrozenxid를 관리한다. 이 값은 대략 다음 의미를 가진다.

이 테이블에서 relfrozenxid보다 오래된 transaction ID는
이미 frozen 처리되어 안전하다고 볼 수 있다.

정확히는 최근 relfrozenxid를 앞으로 당긴 VACUUM이 끝났을 때, 테이블에 남아 있는 가장 오래된 unfrozen XID를 추적하는 값이다. 그래서 PostgreSQL은 age(relfrozenxid)를 보며 어떤 테이블이 얼마나 오래 freeze 관리를 받지 못했는지 판단한다.

이 때문에 “이 테이블은 이제 SELECT만 하는데 왜 autovacuum이 도는가?”라는 질문이 생긴다. 이유는 단순하다. 테이블이 바뀌지 않아도, 클러스터 전체의 XID는 다른 트랜잭션 때문에 계속 흐른다. 과거 파티션이나 히스토리 테이블도 freeze를 끝내지 않았다면 계속 늙는다.

일반 autovacuum과 anti-wraparound autovacuum은 목적이 다르다

둘 다 autovacuum worker가 수행할 수 있고, 둘 다 VACUUM의 세계 안에 있다. 하지만 운영자가 느끼는 의미는 다르다.

여기서 “테이블 전체를 반드시 한 번도 빠짐없이 읽는다”라고 단정하면 조금 과하다. 공식 문서 기준으로 aggressive vacuum은 dead tuple이 있을 법한 페이지만 보는 것이 아니라, unfrozen XID나 MXID가 있을 수 있는 페이지를 방문한다. 이미 all-frozen으로 표시된 페이지는 건너뛸 수 있다.

그래도 운영 체감은 “테이블 전체에 가까운 무거운 스캔”으로 다가올 때가 많다. 특히 대용량 히스토리 테이블이 오래 freeze되지 않았다면, 어느 날 갑자기 특정 테이블의 autovacuum이 CPU와 I/O를 크게 먹는 것처럼 보일 수 있다.

왜 파티셔닝만으로는 해결되지 않는가

파티셔닝은 중요하다. 하지만 파티셔닝 자체가 wraparound 관리를 자동으로 끝내지는 않는다.

각 파티션은 실질적으로 별도 relation이고, 각자 relfrozenxid를 가진다. 월별 파티션을 만들었고 2024년 1월 파티션이 더 이상 쓰이지 않더라도, 그 파티션이 충분히 freeze되지 않았다면 age(relfrozenxid)는 계속 커진다.

그래서 오래된 파티션 전략은 둘 중 하나로 명확해야 한다.

• 보관이 필요 없으면 정책에 따라 DROP 또는 archive 후 제거한다.
• 보관해야 하면 트래픽 낮은 시간에 계획적으로 VACUUM (FREEZE)를 수행해 all-frozen 상태에 가깝게 만든다.

이렇게 해두면 미래의 aggressive vacuum 부담이 줄어든다. 특히 all-frozen page가 잘 유지되는 과거 파티션은 다음 vacuum에서 건너뛸 수 있는 여지가 커진다. 반대로 과거 파티션에도 업데이트나 row lock이 계속 발생하면 all-frozen 상태가 깨질 수 있고, 다음 vacuum 비용이 다시 생긴다.

운영에서 먼저 볼 지표

가장 먼저 볼 것은 database와 relation의 freeze age다.

SELECT
    datname,
    age(datfrozenxid) AS xid_age
FROM pg_database
WHERE datallowconn
ORDER BY xid_age DESC;

테이블 단위로는 TOAST table까지 같이 보는 편이 낫다. PostgreSQL 공식 문서도 relation과 TOAST relation의 age를 함께 확인하는 예시를 제시한다.

SELECT
    c.oid::regclass AS table_name,
    greatest(age(c.relfrozenxid), age(t.relfrozenxid)) AS xid_age,
    c.relfrozenxid,
    t.relfrozenxid AS toast_relfrozenxid
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm')
ORDER BY xid_age DESC
LIMIT 20;

장기 트랜잭션도 같이 봐야 한다. 오래 열린 snapshot은 vacuum이 old row version을 안전하게 정리하거나 freeze하는 일을 어렵게 만든다.

SELECT
    pid,
    state,
    xact_start,
    now() - xact_start AS xact_age,
    query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

prepared transaction과 replication slot도 확인 대상이다. 특히 replication slot의 xmin이나 catalog_xmin이 오래 붙잡혀 있으면 vacuum 진행이 밀릴 수 있다.

SELECT
    gid,
    prepared,
    now() - prepared AS prepared_age,
    owner,
    database
FROM pg_prepared_xacts
ORDER BY prepared;

SELECT
    slot_name,
    active,
    xmin,
    catalog_xmin,
    restart_lsn
FROM pg_replication_slots;

튜닝은 autovacuum을 끄는 일이 아니다

가장 위험한 대응은 “autovacuum이 부하를 주니 꺼버리자”다. PostgreSQL은 wraparound 방지를 위해 autovacuum이 비활성화되어 있어도 필요한 autovacuum을 실행할 수 있다. 그만큼 이 작업은 선택 기능이 아니라 안전장치다.

운영에서 할 일은 autovacuum을 끄는 것이 아니라, 너무 늦게 응급 모드로 몰리지 않도록 평소에 작게 나누어 일하게 만드는 것이다.

대용량 테이블에서는 기본 scale factor가 너무 보수적일 수 있다. 예를 들어 10억 row 테이블에서 autovacuum_vacuum_scale_factor가 크면, vacuum이 시작되기 전에 너무 많은 dead tuple이나 unfrozen page가 쌓일 수 있다.

상황에 따라 테이블별 storage parameter를 조정한다.

ALTER TABLE big_event_history SET (
    autovacuum_vacuum_scale_factor = 0.01,
    autovacuum_vacuum_threshold = 50000
);

정적 대용량 테이블이나 닫힌 파티션은 계획적으로 freeze한다.

VACUUM (FREEZE, VERBOSE) event_history_2025_01;

이 작업도 무겁다. 그래서 운영 중 갑자기 마주치는 것이 아니라, 배치 창이나 트래픽이 낮은 시간에 분산해서 수행하는 편이 낫다.

VACUUM FULL은 답이 아닐 때가 많다

wraparound 문제를 보고 VACUUM FULL을 떠올리기 쉽지만, 둘은 목적이 다르다.

일반 VACUUM은 dead row version을 정리하고 내부 공간을 재사용 가능하게 만들지만, 대부분의 경우 디스크 파일 크기를 즉시 OS에 반환하지 않는다. VACUUM FULL은 테이블을 새로 써서 파일 크기를 줄일 수 있지만, 더 무겁고 ACCESS EXCLUSIVE lock이 필요하다.

wraparound 방지의 핵심은 디스크 파일을 줄이는 것이 아니라 오래된 row version을 frozen 상태로 만들어 XID 비교 위험에서 빼내는 것이다. 따라서 bloat 정리와 wraparound 예방을 섞어서 생각하면 잘못된 결정을 하기 쉽다.

실무 체크리스트

운영에서 반복해서 봐야 할 질문은 다음이다.

• age(datfrozenxid)가 높은 database가 있는가?
• age(relfrozenxid)가 높은 대형 table이나 TOAST table이 있는가?
• autovacuum_freeze_max_age에 가까워지는 relation이 있는가?
• idle in transaction 상태의 오래된 세션이 있는가?
• 장기 batch transaction이 snapshot을 오래 붙잡고 있지 않은가?
• prepared transaction이 방치되어 있지 않은가?
• replication slot이 오래된 xmin이나 catalog_xmin을 붙잡고 있지 않은가?
• 닫힌 파티션에 대해 VACUUM (FREEZE) 또는 drop/archive 정책이 있는가?
• 대용량 hot table의 autovacuum threshold와 scale factor가 기본값에만 묶여 있지 않은가?
• autovacuum 로그를 남겨 어떤 테이블에서 오래 걸리는지 볼 수 있는가?

한 문장으로 정리하면

PostgreSQL의 wraparound 관리는 XID가 도는 것을 막는 일이 아니다. XID는 원형 공간에서 계속 흐른다. 중요한 것은 오래된 row version을 frozen 상태로 확정해, 한 바퀴 돈 뒤에도 과거가 미래처럼 보이지 않게 만드는 것이다.

autovacuum: ... (to prevent wraparound)는 “청소가 조금 늦었다”는 신호가 아니라 “MVCC의 시간표를 안전하게 다시 고정해야 한다”는 신호에 가깝다. 이 로그를 줄이는 가장 좋은 방법은 autovacuum을 피하는 것이 아니라, 테이블의 나이를 평소에 보고, 대형 테이블과 닫힌 파티션이 너무 늙기 전에 작게 관리하는 것이다.

참고한 자료

• PostgreSQL Documentation: Routine Vacuuming
• PostgreSQL Documentation: Vacuuming Configuration
• PostgreSQL Documentation: MVCC Introduction
• PostgreSQL Documentation: pg_class

메모리에 올려두는 빠른 cache.

틀린 말은 아니다. 하지만 Redis를 cache로만 보면 중요한 부분을 많이 놓친다. Redis는 단순 key-value cache라기보다, 메모리 위에서 동작하는 data structure server에 가깝다. 문자열 하나를 저장하는 것뿐 아니라 Hash, List, Set, Sorted Set, Stream 같은 자료구조를 명령어 단위로 조작한다.

그래서 Redis를 잘 쓴다는 말은 두 가지를 같이 이해한다는 뜻이다.

데이터를 어떻게 빨리 읽을 것인가
데이터가 많아지고 장애가 날 때 어떻게 버틸 것인가

Redis는 자료구조 서버다

Redis의 기본 단위는 key다. 하지만 value는 단순 문자열만이 아니다.

Redis가 빠른 이유는 대부분의 명령을 메모리에서 처리하고, event loop 중심으로 단순하게 실행하기 때문이다. 하지만 이 말은 반대로, 오래 걸리는 명령 하나가 다른 요청들을 밀어낼 수 있다는 뜻이기도 하다.

그래서 운영 Redis에서 제일 먼저 피해야 할 습관은 “큰 key를 만들고, 큰 명령을 아무렇지 않게 호출하는 것”이다.

위험한 냄새가 나는 명령:
KEYS *
FLUSHALL
FLUSHDB
SAVE
큰 collection에 대한 전체 조회
큰 key에 대한 DEL

공식 문서도 KEYS는 production에서 극도로 조심해야 하고, 일반 애플리케이션 코드에서는 SCAN이나 별도 index set을 고려하라고 설명한다.

TTL은 collection 내부가 아니라 key에 붙는다

Redis의 expire는 key 단위다.

SET user:1:name "dngur"
EXPIRE user:1:name 60

이 key는 60초 뒤 만료될 수 있다. 하지만 Hash의 field 하나, List의 item 하나, Set의 member 하나에 개별 TTL이 붙는 것은 아니다.

HSET user:1 name "dngur" age 20
EXPIRE user:1 60

이 경우 TTL은 user:1이라는 Hash key 전체에 적용된다. field별 TTL이 필요하다면 key를 더 잘게 나누거나, Sorted Set에 만료 timestamp를 score로 넣고 별도 정리 작업을 두는 식으로 설계를 바꿔야 한다.

TTL은 cache freshness를 다루는 도구이고, eviction은 memory pressure를 다루는 도구다. 둘은 비슷해 보이지만 목적이 다르다.

TTL:
  시간이 지나면 사라져도 되는 데이터

eviction:
  maxmemory를 넘었을 때 무엇을 버릴지 정하는 정책

maxmemory와 eviction policy

Redis가 maxmemory에 도달하면, 설정된 maxmemory-policy에 따라 key를 제거하거나 쓰기를 거부한다.

순수 cache라면 allkeys-lru나 allkeys-lfu가 단순하다. TTL이 없는 cache key도 제거 후보가 되기 때문이다. 반대로 중요한 영구 key와 임시 key가 같은 Redis에 섞여 있다면 volatile-* 정책이 더 안전해 보일 수 있다. 다만 TTL 없는 key는 제거 후보가 아니므로, 메모리 압박이 왔을 때 정책이 기대대로 동작하는지 반드시 확인해야 한다.

noeviction은 key를 버리지 않는다. 대신 쓰기 명령이 에러를 반환할 수 있다. 캐시로 쓰는 Redis라면 장애 모드가 더 거칠어질 수 있고, source of truth처럼 쓰는 Redis라면 오히려 명시적 실패가 더 안전할 수 있다.

여기서 중요한 운영 감각이 하나 있다.

Redis eviction은 정확한 전역 LRU/LFU가 아니라 샘플링 기반 근사 알고리즘이다.

그래서 maxmemory-samples를 키우면 더 정확한 후보를 고를 수 있지만, 그만큼 CPU 비용도 늘어난다.

Persistence는 cache인지 data인지 먼저 정해야 한다

Redis는 in-memory로 동작하지만 디스크 persistence 옵션을 갖고 있다.

RDB = 특정 시점 snapshot
AOF = write command log
No persistence = 재시작하면 사라져도 되는 cache
RDB + AOF = 둘을 함께 사용

RDB는 point-in-time snapshot이다. 파일이 작고 재시작이 빠른 편이지만, snapshot 사이에 장애가 나면 최근 데이터가 사라질 수 있다. AOF는 write operation을 log로 남기고 재시작 시 replay한다. 더 촘촘한 복구가 가능하지만 파일 크기, fsync 정책, rewrite 비용을 같이 봐야 한다.

Redis를 cache로만 쓴다면 persistence를 끄는 선택도 자연스럽다. 재시작 후 cache miss가 늘 뿐, 원본 DB에서 다시 채울 수 있기 때문이다.

반대로 session, idempotency key, rate limit counter, queue처럼 Redis 안의 데이터가 서비스 의미를 갖는다면 persistence와 replication을 반드시 같이 봐야 한다. “Redis가 빠르다”와 “Redis에 저장한 데이터가 반드시 안전하다”는 다른 문장이다.

Sentinel과 Cluster는 해결하는 문제가 다르다

Sentinel과 Cluster는 둘 다 고가용성과 관련이 있지만, 같은 기능이 아니다.

Sentinel은 master를 감시하고, 충분한 Sentinel이 장애를 인정하면 replica 중 하나를 master로 승격한다. Redis 문서의 표현을 빌리면 SDOWN은 특정 Sentinel이 주관적으로 판단한 down 상태이고, ODOWN은 quorum 이상이 동의한 객관적 down 상태다.

Cluster는 keyspace를 16384개 hash slot으로 나눈다.

HASH_SLOT = CRC16(key) mod 16384

각 master node는 slot의 일부를 담당한다. client가 잘못된 node에 요청하면 Redis는 올바른 node를 알려주는 redirect를 반환하고, cluster-aware client는 이를 따라가야 한다.

Cluster에서는 key를 묶어 같은 slot으로 보내야 할 때 hash tag를 쓴다.

cart:{user-1}
cart-item:{user-1}:a
cart-item:{user-1}:b

중괄호 안의 user-1만 hash slot 계산에 쓰이므로, 관련 key를 같은 slot에 둘 수 있다. multi-key command나 transaction-like 흐름을 Redis Cluster에서 쓸 때 자주 필요한 감각이다.

Redis를 queue로 쓸 때는 보장 수준을 골라야 한다

Redis로 event queue를 만들 수 있다. 하지만 어떤 자료구조를 쓰는지에 따라 보장 수준이 완전히 달라진다.

Pub/Sub은 가장 가볍다. 하지만 Redis 공식 문서 기준으로 Pub/Sub은 at-most-once delivery semantics를 갖는다. subscriber가 연결되어 있지 않거나 처리 중 실패하면 메시지를 다시 받을 방법이 없다. 모니터링 알림, live notification처럼 유실이 치명적이지 않은 곳에 어울린다.

List는 간단한 작업 큐를 만들기 쉽다.

producer:
  LPUSH jobs payload

consumer:
  BRPOP jobs 5

여기서 BLPOP/BRPOP의 timeout 0은 즉시 반환이 아니라 무기한 대기다. 일정 시간마다 loop를 돌며 shutdown signal이나 health 상태를 확인하고 싶다면 0보다 작은 적절한 timeout을 두는 편이 운영하기 쉽다.

List는 “한 메시지를 한 consumer가 가져간다”는 queue에는 충분할 수 있다. 하지만 소비 후 ack, 실패 시 재처리, pending 상태 추적이 필요하면 직접 구현할 것이 많아진다.

Stream은 이 빈틈을 많이 채운다.

XADD order-events * orderId 123 status paid
XGROUP CREATE order-events order-workers $
XREADGROUP GROUP order-workers worker-1 COUNT 10 BLOCK 1000 STREAMS order-events >
XACK order-events order-workers 1680000000000-0

Stream은 append-only log에 가깝고, consumer group을 통해 여러 consumer가 같은 stream을 나누어 읽을 수 있다. XACK로 처리 완료를 표시하고, pending entries를 추적할 수 있다. 대신 stream이 무한히 커지지 않도록 XTRIM이나 maxlen 정책을 함께 설계해야 한다.

Spring Boot에서 Redis를 붙이는 기본 흐름

Spring Boot에서는 보통 spring-boot-starter-data-redis를 추가하면 Spring Data Redis가 Redis 접근 추상화를 제공한다. 기본 client는 Lettuce가 흔히 쓰인다.

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-data-redis")
    implementation("org.apache.commons:commons-pool2")
}

가장 단순한 설정은 property로 시작한다.

spring:
  data:
    redis:
      host: localhost
      port: 6379
      connect-timeout: 500ms
      timeout: 1s
      lettuce:
        pool:
          max-active: 16
          max-idle: 8
          min-idle: 0
          max-wait: 500ms

StringRedisTemplate은 문자열 중심으로 쓸 때 편하다.

@Service
public class LoginAttemptStore {

    private final StringRedisTemplate redis;

    public LoginAttemptStore(StringRedisTemplate redis) {
        this.redis = redis;
    }

    public long increase(String userId) {
        String key = "login:fail:" + userId;
        Long count = redis.opsForValue().increment(key);
        redis.expire(key, Duration.ofMinutes(10));
        return count == null ? 0 : count;
    }
}

객체를 저장한다면 serializer를 명시하는 편이 안전하다.

@Bean
RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory connectionFactory) {
    RedisTemplate<String, Object> template = new RedisTemplate<>();
    template.setConnectionFactory(connectionFactory);
    template.setKeySerializer(new StringRedisSerializer());
    template.setHashKeySerializer(new StringRedisSerializer());
    template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
    template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());
    template.afterPropertiesSet();
    return template;
}

serializer를 암묵적으로 두면 나중에 타입 변경, class package 변경, 다국어 client 접근, 운영 redis-cli 확인에서 비용이 커진다. key는 읽을 수 있는 문자열로 두고, value는 JSON인지 binary인지 명확히 정해두는 편이 좋다.

Spring Cache로 쓸 때

Spring Cache를 Redis 위에 올리면 @Cacheable로 cache-aside 패턴을 쉽게 만들 수 있다.

@Service
public class ProductService {

    @Cacheable(cacheNames = "product", key = "#id")
    public Product getProduct(Long id) {
        return productRepository.findById(id)
            .orElseThrow();
    }
}

CacheManager에는 TTL과 serializer를 같이 넣는다.

@Bean
RedisCacheManager redisCacheManager(RedisConnectionFactory connectionFactory) {
    RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
        .entryTtl(Duration.ofMinutes(10))
        .disableCachingNullValues()
        .serializeKeysWith(
            RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer())
        )
        .serializeValuesWith(
            RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer())
        );

    return RedisCacheManager.builder(connectionFactory)
        .cacheDefaults(config)
        .withCacheConfiguration(
            "product",
            config.entryTtl(Duration.ofMinutes(5))
        )
        .build();
}

운영 cache에서 TTL은 거의 필수다. 영구 cache는 언젠가 source of truth와 어긋난다. TTL을 너무 길게 잡으면 stale data가 오래 남고, 너무 짧게 잡으면 DB를 보호하지 못한다.

여기에 cache stampede도 고려해야 한다. 같은 key가 동시에 만료되면 많은 요청이 한꺼번에 DB로 몰릴 수 있다. 해결책은 상황에 따라 다르다.

• TTL에 작은 jitter를 섞는다.
• hot key는 refresh-ahead로 미리 갱신한다.
• miss 시 분산 lock이나 single-flight로 DB 조회를 합친다.
• null caching을 쓸지 명확히 정한다.

Lettuce를 이해해야 하는 이유

Lettuce는 Netty 기반 Redis client다. Spring Data Redis는 Lettuce를 통해 non-blocking I/O 기반 client를 제공하지만, Spring MVC에서 RedisTemplate을 동기 방식으로 쓰면 애플리케이션 코드 관점에서는 동기 호출처럼 느껴진다.

중요한 지점은 connection이다.

Spring Data Redis의 LettuceConnectionFactory는 기본적으로 여러 LettuceConnection이 하나의 thread-safe native connection을 공유할 수 있다. 하지만 LettuceConnection 자체와 clustered variant는 thread-safe가 아니므로, 인스턴스를 여러 스레드에서 직접 공유하면 안 된다. 보통은 RedisTemplate이 connection 획득과 반환을 관리하므로 직접 만질 일이 적다.

공식 API 문서 기준으로 shareNativeConnection이 true이면 일반 작업은 shared native connection을 사용하고, blocking이나 transaction 작업은 별도 connection provider를 통해 connection을 고른다. shareNativeConnection을 false로 끄면 모든 작업이 새 connection 또는 pool connection을 사용한다.

shareNativeConnection과 connection pool의 관계

Spring Boot에서 Lettuce pool 설정을 넣으면 모든 Redis 명령이 pool에서 connection을 빌려 쓸 것처럼 느껴지지만, 기본 동작은 조금 다르다. 핵심은 LettuceConnectionFactory의 shareNativeConnection 값이다.

기본값은 true다. 이때 RedisTemplate이 GET, SET, HGET, INCR 같은 일반 명령을 실행하면 매번 새로운 TCP connection을 빌리는 것이 아니라, factory 내부의 shared native connection을 함께 사용한다. Lettuce의 native connection인 StatefulRedisConnection은 thread-safe하고 command multiplexing을 지원하므로, 여러 application thread가 같은 native connection을 통해 명령을 보낼 수 있다.

다만 Spring Data Redis의 LettuceConnection 객체 자체는 thread-safe하지 않다. 그래서 LettuceConnection 인스턴스를 직접 필드에 저장해 여러 스레드에서 공유하는 방식은 피해야 한다. 일반적인 RedisTemplate 사용에서는 template이 connection 획득과 반환을 감싸기 때문에 이 차이를 직접 의식할 일이 적다.

정리하면 다음처럼 보면 된다.

따라서 spring.data.redis.lettuce.pool.* 값을 설정했다고 해서 애플리케이션의 모든 Redis 요청이 max-active 개수만큼 분산되는 것은 아니다. shareNativeConnection=true라면 CLIENT LIST에서 일반 명령용 shared connection이 중심으로 보이고, blocking이나 transaction을 사용할 때 pool connection이 추가로 보이는 식으로 이해하는 편이 맞다.

setShareNativeConnection(false)는 이런 기본 공유 모델을 끄는 설정이다. 예를 들어 모든 동기 Redis 작업을 pool에서 빌린 connection으로 격리하고 싶다면 factory를 직접 만들고 값을 꺼야 한다.

@Bean
LettuceConnectionFactory pooledDedicatedRedisConnectionFactory() {
    RedisStandaloneConfiguration server = new RedisStandaloneConfiguration("localhost", 6379);

    GenericObjectPoolConfig<?> pool = new GenericObjectPoolConfig<>();
    pool.setMaxTotal(16);
    pool.setMaxIdle(8);
    pool.setMinIdle(0);
    pool.setMaxWait(Duration.ofMillis(500));

    LettuceClientConfiguration client = LettucePoolingClientConfiguration.builder()
        .poolConfig(pool)
        .commandTimeout(Duration.ofSeconds(1))
        .build();

    LettuceConnectionFactory factory = new LettuceConnectionFactory(server, client);
    factory.setShareNativeConnection(false);
    return factory;
}

하지만 이 설정을 성능 향상 버튼처럼 생각하면 안 된다. Redis server는 기본적으로 명령을 빠르게 순차 처리하고, Lettuce connection은 thread-safe하게 multiplexing할 수 있다. 일반적인 cache read/write에서는 connection을 늘리는 것보다 key 설계, command latency, payload 크기, slow command 제거, timeout 설정이 더 큰 영향을 준다.

shareNativeConnection=false가 의미 있는 경우는 보통 다음 쪽에 가깝다.

• connection 단위 상태가 섞이면 안 되는 작업을 명확히 격리하고 싶다.
• transaction, blocking command, batch성 작업이 섞여 일반 cache 요청과 분리하고 싶다.
• shared connection에서 특정 장애나 지연이 전체 요청에 영향을 주는지 검증하기 위해 실험적으로 비교하고 싶다.
• 운영 정책상 connection 수, pool wait, pool exhaustion을 명시적으로 관찰하고 제어하고 싶다.

반대로 단순히 “Redis가 느리니 pool을 늘리자”는 접근은 위험하다. Redis slowlog에 비싼 명령이 찍히거나, network latency가 튀거나, 큰 value 직렬화가 병목인 상황에서는 pool을 늘려도 병목 위치가 바뀌지 않는다. pool을 키우면 Redis server 입장에서는 더 많은 client connection과 더 많은 동시 대기열을 감당해야 하므로 장애가 더 늦게 드러날 수도 있다.

shared native connection은 LettuceConnection이 닫는 대상이 아니기 때문에, getConnection() 때마다 기본으로 검증되지 않는다. 연결 검증이 꼭 필요하면 setValidateConnection(true)를 켤 수 있지만, 검증 비용이 추가될 수 있으므로 장애 증상과 운영 환경을 보고 선택해야 한다.

Lettuce 설정 예시

기본 property로 충분하지 않다면 LettuceConnectionFactory를 명시적으로 구성한다.

@Configuration
public class RedisConfig {

    @Bean
    LettuceConnectionFactory redisConnectionFactory() {
        RedisStandaloneConfiguration server = new RedisStandaloneConfiguration("localhost", 6379);

        LettuceClientConfiguration client = LettuceClientConfiguration.builder()
            .commandTimeout(Duration.ofSeconds(1))
            .shutdownTimeout(Duration.ofMillis(100))
            .clientOptions(ClientOptions.builder()
                .autoReconnect(true)
                .build())
            .build();

        return new LettuceConnectionFactory(server, client);
    }
}

pool이 필요하면 commons-pool2와 함께 pooling configuration을 쓴다.

@Bean
LettuceConnectionFactory pooledRedisConnectionFactory() {
    RedisStandaloneConfiguration server = new RedisStandaloneConfiguration("localhost", 6379);

    GenericObjectPoolConfig<?> pool = new GenericObjectPoolConfig<>();
    pool.setMaxTotal(16);
    pool.setMaxIdle(8);
    pool.setMinIdle(0);
    pool.setMaxWait(Duration.ofMillis(500));

    LettuceClientConfiguration client = LettucePoolingClientConfiguration.builder()
        .poolConfig(pool)
        .commandTimeout(Duration.ofSeconds(1))
        .build();

    return new LettuceConnectionFactory(server, client);
}

pool을 늘린다고 Redis 처리량이 무조건 늘지는 않는다. Redis server는 명령을 매우 빠르게 처리하지만, single-thread event loop 특성상 비싼 명령이 섞이면 queueing이 생긴다. connection pool은 client 쪽 대기와 격리를 도와줄 수 있지만, Redis server의 CPU, command latency, network, slowlog가 병목이면 pool만 늘려서는 해결되지 않는다.

Lettuce 사용 시 유의사항

1. timeout은 짧고 명확하게 둔다

Redis는 빠른 저장소로 쓰는 경우가 많다. 그러면 timeout도 그 기대에 맞아야 한다. 요청 전체 SLA가 200ms인데 Redis command timeout이 60초라면, 장애 시 애플리케이션 thread가 너무 오래 붙잡힌다.

connect timeout:
  Redis에 새 연결을 맺는 시간

command timeout:
  GET, SET 같은 명령이 끝나길 기다리는 시간

pool max-wait:
  pool에서 connection을 빌릴 때 기다리는 시간

이 셋은 서로 다르다. timeout 로그를 볼 때도 “connect가 느린지, pool이 고갈됐는지, Redis command가 느린지”를 분리해서 봐야 한다.

2. blocking command는 connection을 분리한다

BLPOP, BRPOP, Pub/Sub subscribe 같은 작업은 connection을 오래 점유한다. 일반 cache GET/SET과 같은 connection을 공유하면 다른 명령이 밀릴 수 있다.

Spring Data Redis의 shareNativeConnection 기본 동작은 일반 작업과 blocking/transaction 작업을 구분하려고 한다. 하지만 직접 connection을 다루거나, custom factory/pool을 구성한다면 blocking 작업 전용 connection 또는 별도 RedisTemplate을 두는 편이 명확하다.

3. 큰 key 삭제는 UNLINK를 고려한다

큰 List, Set, Hash를 DEL로 지우면 메모리 해제가 main thread에서 부담이 될 수 있다. Redis에는 key를 keyspace에서 분리하고 실제 메모리 회수를 background에서 처리하는 UNLINK가 있다. 큰 key 정리 작업이라면 DEL과 UNLINK의 차이를 이해하고 선택해야 한다.

4. Cluster에서는 key naming이 routing이다

Redis Cluster에서는 key가 hash slot을 결정한다. 관련 key를 같은 slot에 두어야 한다면 hash tag를 써야 한다.

order:{123}:summary
order:{123}:items
order:{123}:payment

이렇게 하면 {123} 부분만 hash slot 계산에 쓰여 같은 slot으로 간다. 반대로 아무 생각 없이 key를 만들면 multi-key command가 cluster에서 실패하거나 redirect가 늘어날 수 있다.

5. cache miss도 장애 모드다

Redis cache 장애는 Redis가 죽었을 때만 생기지 않는다. eviction, TTL 만료, deploy 후 cold cache, hot key 만료가 모두 DB로 전이될 수 있다.

Redis hit:
  빠른 응답

Redis miss:
  DB query
  serialization
  Redis write-back
  동시 요청이면 stampede 가능

Redis를 붙였으면 hit ratio, command latency, used memory, evicted keys, expired keys, connected clients, slowlog, replication lag를 같이 봐야 한다.

운영 체크리스트

Redis를 붙이기 전에 다음 질문을 먼저 정리해두면 장애 때 덜 흔들린다.

• 이 Redis는 cache인가, session store인가, queue인가, source of truth에 가까운가?
• key마다 TTL이 있는가?
• maxmemory와 maxmemory-policy는 무엇인가?
• eviction이 발생해도 서비스 의미가 깨지지 않는가?
• RDB/AOF persistence를 켤 것인가?
• Sentinel/Cluster 중 어떤 topology가 필요한가?
• 큰 collection key가 생기지 않는가?
• KEYS, 큰 DEL, FLUSH*, SAVE 같은 명령이 운영 경로에 없는가?
• Spring Boot에서 command timeout, connect timeout, pool wait timeout이 분리되어 있는가?
• blocking Redis 작업이 일반 cache 작업과 connection을 공유하지 않는가?
• serializer와 key naming 규칙이 문서화되어 있는가?

한 문장으로 정리하면

Redis는 빠른 cache이기도 하지만, 실제로는 TTL, eviction, persistence, topology, client connection까지 함께 설계해야 하는 in-memory data structure server다.

Spring Boot에서 Lettuce를 쓸 때도 핵심은 같다. RedisTemplate은 Redis를 쉽게 쓰게 해주지만, timeout과 connection 공유, blocking command, serializer, key naming을 흐릿하게 만들면 장애는 훨씬 늦게 드러난다.

Redis를 잘 쓰는 기준은 “빨랐다”가 아니라 “느려지고, 메모리가 차고, master가 바뀌고, key가 사라져도 어떤 일이 일어나는지 알고 있다”에 가깝다.

참고한 자료

• Redis key eviction
• Redis persistence
• Redis Cluster specification
• Redis Sentinel
• Redis Pub/Sub
• Redis Streams
• Redis XREADGROUP
• Redis BLPOP
• Redis KEYS
• Spring Data Redis drivers
• Spring Boot RedisAutoConfiguration
• Spring Data Redis LettuceConnectionFactory API
• Lettuce production usage
• Lettuce connecting Redis
• Lettuce connection pooling

많은 fd 중 지금 읽거나 쓸 수 있는 fd를 알려준다.

그런데 io_uring은 조금 다르다. 단순히 “더 빠른 epoll”이라고 이해하면 중요한 부분을 놓치기 쉽다.

가장 큰 차이는 알림의 성격이다.

epoll    = 준비 상태 알림, readiness notification
io_uring = 완료 결과 알림, completion notification

epoll은 커널이 “이 fd는 지금 read/write 가능해 보인다”고 알려주는 모델이다. 그 뒤 실제 read()와 write()는 애플리케이션이 다시 호출해야 한다.

io_uring은 애플리케이션이 “이 작업을 해줘”라고 커널에 제출하고, 커널이 작업을 끝낸 뒤 “완료됐고 결과는 이렇다”고 알려주는 모델에 가깝다.

epoll은 I/O를 대신 해주지 않는다

epoll은 fd를 감시하는 메커니즘이다. 커널 안의 epoll 인스턴스에는 관심 목록, interest list가 있고, 그중 이벤트가 발생한 fd는 ready list로 올라온다.

흐름은 대략 이렇다.

socket fd 생성
-> epoll_ctl()로 interest list에 등록
-> epoll_wait()로 ready event 대기
-> readable 이벤트 수신
-> 애플리케이션이 read(fd, buf) 호출
-> 커널 버퍼에서 유저 버퍼로 데이터 복사

중요한 점은 epoll_wait()가 데이터를 읽어주는 것이 아니라는 점이다. epoll_wait()는 “이 fd에 읽을 수 있는 이벤트가 있다”는 정보를 반환한다. 실제 I/O는 그 다음 read()나 write() syscall에서 일어난다.

그래서 epoll 기반 이벤트 루프는 보통 이런 모습이 된다.

while (running) {
    events = epoll_wait(epfd, events, maxevents, timeout);

    for (event in events) {
        if (event.readable) {
            n = read(event.fd, buf, sizeof(buf));
            handle(buf, n);
        }
    }
}

이 모델은 네트워크 소켓과 잘 맞는다. Tomcat NIO, Netty epoll transport, Redis, Nginx 같은 구조가 이런 readiness 모델 위에서 오래 검증되어 왔다.

다만 readiness는 “가능해 보인다”에 가깝다. edge-triggered 모드에서는 특히 읽을 수 있는 만큼 drain해야 하고, 실제 read() 결과가 짧게 오거나 EAGAIN으로 끝날 수 있다.

io_uring은 작업을 제출하고 완료를 받는다

io_uring은 Linux 전용 비동기 I/O 인터페이스다. 이름처럼 userspace와 kernel space가 공유하는 ring buffer를 중심으로 동작한다.

두 개의 큐가 핵심이다.

Submission Queue, SQ: 애플리케이션 -> 커널
Completion Queue, CQ: 커널 -> 애플리케이션

애플리케이션은 SQE, submission queue entry에 작업을 쓴다.

opcode    = READ / WRITE / ACCEPT / RECV / SEND / TIMEOUT ...
fd        = 대상 파일 또는 소켓
addr      = 유저 버퍼 주소
len       = 길이
user_data = 완료를 다시 매칭하기 위한 식별자

커널은 작업을 처리하고 CQE, completion queue entry에 결과를 남긴다.

user_data = 원래 요청 식별자
res       = 결과값, 예: 읽은 바이트 수 또는 음수 에러 코드
flags     = 부가 정보

즉 질문이 바뀐다.

epoll:
  "이 fd 지금 읽을 수 있어?"

io_uring:
  "이 fd에서 이 버퍼로 읽어줘. 끝나면 알려줘."

syscall을 줄인다는 말의 의미

io_uring이 빠르다고 말할 때 자주 나오는 이유가 syscall 감소다. 이것도 조금 정확히 봐야 한다.

epoll 기반 루프는 대략 이렇게 syscall이 나뉜다.

epoll_wait()
read()
write()
epoll_wait()
read()
write()

반면 io_uring은 여러 작업을 SQ에 적어 두고, io_uring_enter() 한 번으로 여러 요청을 제출하거나 완료를 기다릴 수 있다.

SQ에 여러 recv/send/read/write SQE 적재
-> io_uring_enter()
-> CQ에서 여러 완료 확인

모든 syscall이 사라지는 것은 아니다. 커널에 새 제출이 있다는 사실을 알려야 하고, 완료를 기다려야 할 수도 있다. 다만 요청과 완료의 메타데이터가 공유 ring을 통해 오가기 때문에, 여러 I/O를 batch로 묶을 여지가 생긴다. SQPOLL, fixed buffer, registered file 같은 고급 옵션을 쓰면 특정 경로의 비용을 더 줄일 수도 있다.

네트워크 I/O에서는 무엇이 달라질까

epoll 기반 네트워크 서버의 read 흐름은 보통 이렇게 보인다.

NIC
-> kernel TCP receive buffer
-> epoll_wait(): socket readable
-> application read(fd, user_buffer)
-> kernel buffer에서 user buffer로 복사
-> HTTP 파싱 / handler 호출

io_uring 기반이라면 읽기 요청을 미리 제출해 둘 수 있다.

recv SQE 제출
-> 커널이 socket recv 수행
-> CQE 도착
-> res = 읽은 바이트 수
-> handler 호출
-> 다음 recv SQE 제출

여기서도 일반적인 socket receive는 여전히 kernel TCP buffer에서 user buffer로 복사가 일어난다. io_uring이라는 이름만으로 자동 zero-copy가 되는 것은 아니다.

최신 커널에는 io_uring 기반 zero-copy receive 같은 기능도 있다. Linux kernel 문서 기준으로 ZC Rx는 네트워크 수신 경로에서 kernel-to-user copy를 제거하여 packet data를 userspace memory로 직접 받을 수 있게 하는 기능이다. 하지만 이건 일반적인 io_uring 사용 전체에 자동 적용되는 기본 동작이 아니다. NIC 조건, API 조건, 애플리케이션 구조가 맞아야 하는 별도 고급 기능으로 보는 편이 안전하다.

파일 I/O에서 의미가 더 커지는 이유

네트워크 소켓은 non-blocking readiness 모델과 잘 맞는다. 그래서 epoll만으로도 매우 빠른 서버를 만들 수 있다.

문제는 일반 파일 I/O다.

일반 파일은 네트워크 소켓처럼 “나중에 readable이 된다”는 readiness 모델과 잘 맞지 않는다. Linux epoll_ctl(2) 문서도 대상 fd가 epoll을 지원하지 않으면 EPERM을 반환할 수 있고, 그 예로 regular file이나 directory를 든다. 설령 poll/select 계열에서 일반 파일이 ready처럼 취급되는 상황을 생각하더라도, 실제 read는 page cache miss나 디스크 I/O 때문에 애플리케이션 스레드를 오래 붙잡을 수 있다.

그래서 전통적인 서버 구조에서는 이런 식의 분리가 흔했다.

network socket = epoll event loop
file I/O       = worker thread pool

예를 들어 파일을 읽어서 소켓으로 보내야 하는 서버라면, 이벤트 루프 스레드가 직접 파일 read를 하면 블로킹 위험이 있다. 그래서 파일 read를 worker pool에 넘기고, 완료 후 다시 socket write를 진행하는 구조가 나온다.

io_uring은 파일 read/write 자체를 비동기로 제출할 수 있어서 이 지점에서 의미가 커진다.

완료 순서는 제출 순서와 다를 수 있다

io_uring을 이해할 때 중요한 감각이 하나 더 있다. 여러 요청을 한 번에 제출하면, 완료 순서가 제출 순서와 같다고 가정하면 안 된다.

submit A: file read
submit B: socket recv
submit C: timeout

completion:
  B 완료
  C 완료
  A 완료

그래서 SQE의 user_data가 중요하다. 요청을 제출할 때 애플리케이션이 식별자를 넣어 두고, CQE가 돌아왔을 때 그 user_data로 어떤 요청의 완료인지 매칭해야 한다.

이 점은 epoll의 fd 이벤트 처리와 코드 구조를 다르게 만든다. io_uring 기반 코드는 보통 “완료 이벤트를 받아 다음 작업을 제출하는 상태머신”처럼 흐른다.

accept도 completion 스타일로 바뀐다

epoll 기반 accept는 이런 식이다.

listen socket을 epoll에 등록
-> EPOLLIN 발생
-> accept() 호출
-> client fd 획득
-> client fd를 다시 epoll에 등록

io_uring 기반 accept는 이렇게 볼 수 있다.

accept SQE 제출
-> 새 연결이 들어오면 accept 완료 CQE 발생
-> CQE 결과로 client fd 획득
-> client fd에 recv SQE 제출
-> 다음 accept SQE 다시 제출

이 차이는 “이벤트가 왔으니 내가 syscall을 호출한다”와 “작업을 걸어두고 완료를 받는다”의 차이다.

epoll과 io_uring 비교

Java 백엔드에서는 바로 체감하기 어렵다

Spring Boot, Tomcat, JDBC 기반 서버를 생각하면 io_uring이 곧바로 성능 향상으로 이어진다고 말하기 어렵다.

이런 서버의 병목은 자주 다른 곳에 있다.

JDBC blocking call
DB connection pool 대기
외부 API latency
serialization/deserialization
GC
worker thread 점유

Tomcat NIO나 Netty가 epoll 기반 readiness 모델을 잘 사용하더라도, 컨트롤러 안에서 JDBC를 호출하면 worker thread는 DB 응답을 기다리며 블로킹된다.

socket readable
-> request parsing
-> worker thread 배정
-> JDBC query
-> worker thread blocking

이 상황에서 네트워크 이벤트 감시 모델만 io_uring으로 바꾼다고 전체 병목이 사라지지는 않는다. io_uring을 제대로 활용하려면 서버 런타임이나 네트워크 라이브러리 레벨에서 completion 기반 transport를 제공하고, 애플리케이션 구조도 그 모델에 맞아야 한다.

반대로 다음 같은 시스템에서는 가치가 커질 수 있다.

• 고성능 프록시
• 파일 서버
• object storage gateway
• 로그 수집 서버
• 네트워크와 디스크를 함께 많이 쓰는 서버
• C/Rust 기반 커스텀 런타임
• syscall overhead가 병목인 초고성능 서버

io_uring이 항상 상위호환은 아니다

io_uring은 강력하지만 공짜는 아니다.

• 커널 버전에 따라 지원 opcode와 안정성이 달라질 수 있다.
• completion 기반 상태머신으로 코드를 설계해야 한다.
• 유저 버퍼의 생명주기를 완료 시점까지 안전하게 유지해야 한다.
• 특정 작업은 커널 내부 worker thread를 사용할 수 있다.
• 보안 정책이나 운영 환경에 따라 제한될 수 있다.
• 기존 epoll 기반 생태계는 훨씬 오래 검증되어 있다.

특히 버퍼 생명주기는 자주 놓치는 부분이다. SQE에 유저 버퍼 주소를 넘긴다는 것은, 커널이 그 작업을 끝낼 때까지 그 버퍼가 살아 있어야 한다는 뜻이다. completion 기반 I/O는 “요청을 제출한 함수가 끝났다”와 “버퍼를 재사용해도 된다”가 같은 시점이 아니다.

한 문장으로 정리하면

epoll은 준비된 fd 목록을 받아 애플리케이션이 직접 I/O를 호출하는 readiness 모델이고, io_uring은 I/O 작업을 커널에 제출한 뒤 완료 결과를 CQE로 받는 completion 모델이다.

그래서 io_uring은 epoll의 단순한 상위호환이라기보다, 파일 I/O와 네트워크 I/O를 같은 완료 기반 흐름으로 묶고 syscall 경계를 줄이기 위한 더 넓은 Linux I/O 인터페이스에 가깝다.

차분히 보면 핵심은 하나다.

epoll:
  "준비됐어?"

io_uring:
  "끝났어?"

그 작은 질문의 차이가 서버의 상태머신, syscall 경계, 버퍼 생명주기, 파일 I/O 처리 방식을 바꾼다.

참고한 자료

• io_uring(7) - Linux manual page
• io_uring_enter(2) - Linux manual page
• epoll(7) - Linux manual page
• epoll_wait(2) - Linux manual page
• io_uring zero copy Rx - Linux Kernel documentation

이 key는 어느 서버가 맡아야 할까?

처음에는 간단해 보인다.

server = hash(key) % N

서버가 4대라면 hash(key) % 4를 계산하면 된다. 구현은 쉽고, 해시 함수가 괜찮다면 분산도 나쁘지 않다.

문제는 서버 수가 바뀌는 순간 시작된다.

N = 4에서 N = 5가 되면 같은 key라도 나머지 연산의 결과가 거의 전부 바뀐다. 서버를 한 대 추가했을 뿐인데, 대다수 key의 소유자가 바뀌고, 캐시도 비고, 데이터도 대량으로 이동해야 한다.

Consistent Hashing은 이 문제를 다르게 푼다.

서버 수가 바뀌어도 전체 key를 다시 흔들지 말고, 영향을 받는 구간만 움직이게 하자.

왜 hash(key) % N으로는 부족할까

서버 수가 고정되어 있다면 modulo hashing도 쓸 수 있다. 문제는 클러스터가 고정되어 있지 않다는 점이다. 서버는 추가되고, 빠지고, 교체된다.

N = 4
server = hash(key) % 4

N = 5
server = hash(key) % 5

이렇게 바뀌면 key 대부분의 목적지가 바뀐다. 실제 시스템에서는 이것이 단순 계산 문제가 아니다.

• 캐시라면 cache miss가 한꺼번에 늘어난다.
• 저장소라면 데이터 이동량이 폭증한다.
• Kafka처럼 key와 partition ordering이 연결된 시스템에서는 mapping 변화가 ordering 기대를 흔들 수 있다.
• LSM 기반 저장소라면 이동된 데이터가 compaction과 tail latency를 건드릴 수 있다.

Consistent Hashing은 서버 수 변경을 “전체 재배치”가 아니라 “일부 구간의 ownership 변경”으로 줄인다.

링 위에 서버와 key를 같이 올린다

Consistent Hashing은 해시 함수의 출력 공간을 원처럼 생각한다.

0 ................................ 2^32 - 1
^                                  |
|__________________________________|

서버도 해시한다.

hash(nodeA)
hash(nodeB)
hash(nodeC)

key도 해시한다.

hash("user:123")

key는 자기 위치에서 시계 방향으로 이동하다가 처음 만나는 node에 배치된다. 이때 node는 key의 owner가 된다.

서버가 추가되면 일부 구간만 움직인다

새 서버 D가 A와 B 사이에 들어왔다고 하자. 그러면 D 바로 이전 구간에 있던 key들만 D로 이동한다. C 주변의 key, A 이전의 key, B 이후의 key는 그대로 남는다.

반대로 서버가 빠지면 그 서버가 담당하던 구간만 다음 node로 넘어간다. 그래서 Consistent Hashing은 “클러스터 membership 변화에 대한 이동 비용”을 줄이는 알고리즘이다.

그래도 균등 분산은 자동으로 보장되지 않는다

링을 만든다고 모든 문제가 끝나지는 않는다. 서버를 한 점씩만 링 위에 올리면 위치가 운 나쁘게 몰릴 수 있다.

A --------------------------- B -- C

이런 배치에서는 A나 B가 담당하는 구간이 지나치게 커질 수 있다. hash function이 균등하더라도 node가 적으면 구간 길이 편차가 커질 수 있고, 결국 특정 서버에 데이터와 요청이 몰린다.

여기서 virtual node가 등장한다.

Virtual Node는 물리 노드를 여러 점으로 쪼갠다

Virtual node, 줄여서 vnode는 물리 서버 하나를 링 위의 여러 위치로 표현하는 방법이다.

Node A -> A1, A2, A3, A4
Node B -> B1, B2, B3, B4
Node C -> C1, C2, C3, C4

vnode의 장점은 세 가지다.

1. 구간 편차가 줄어 load balancing이 좋아진다.
2. 새 서버가 들어올 때 여러 서버에서 조금씩 데이터를 받아 올 수 있다.
3. 성능이 다른 서버에 더 많은 vnode를 줄 수 있다.

하지만 vnode가 많다고 항상 좋은 것은 아니다. token 관리, streaming, repair, 모니터링의 단위가 늘어난다. Cassandra 문서도 vnode가 load distribution에는 도움을 주지만 token 관리 오버헤드를 늘릴 수 있다고 설명한다.

Consistent Hashing은 partitioning만이 아니다

분산 저장소에서는 partitioning과 replication이 함께 간다.

replication factor가 3이라면 key의 primary owner 하나만 고르는 것이 아니라, 링에서 이어지는 다음 node들까지 replica로 선택할 수 있다.

key K owner: Node B
replica candidates: Node B, Node C, Node D

Dynamo 계열 시스템에서는 이런 ownership과 replica list가 quorum, read repair, anti-entropy와 연결된다.

예를 들어 replica 수 N = 3, write quorum W = 2, read quorum R = 2라면:

R + W > N

조건을 만족하므로 읽기와 쓰기 quorum이 적어도 하나의 replica에서 겹친다. 물론 이것만으로 모든 일관성 문제가 사라지는 것은 아니다. 네트워크 partition, stale replica, conflict resolution, hinted handoff, read repair 같은 운영상의 문제가 뒤따른다.

균등한 hash와 균등한 workload는 다르다

Consistent Hashing은 key space를 나누는 데 도움을 준다. 하지만 실제 트래픽은 균등하지 않다.

데이터 크기 != 요청 수 != CPU 비용

작은 key 하나가 전체 트래픽의 큰 비율을 차지할 수 있다. celebrity user, 인기 게시글, 대형 채팅방, 실시간 경기 이벤트 같은 key는 해시가 아무리 균등해도 한 partition을 뜨겁게 만든다.

이것이 hot key 문제다.

해결 방법은 상황에 따라 달라진다.

• key salting: user123#0, user123#1처럼 나누어 write를 퍼뜨린다.
• read aggregation: salting된 key를 다시 모아서 읽는다.
• adaptive replication: hot partition의 replica를 늘린다.
• dynamic partitioning: load 기준으로 shard를 쪼갠다.
• cache isolation: hot key를 별도 캐시나 경로로 분리한다.

이 모든 방법에는 대가가 있다. 특히 key salting은 쓰기는 퍼뜨리지만 읽기에는 aggregation 비용을 남긴다.

Kafka와는 어떻게 연결될까

Kafka producer도 key가 있는 record를 partition에 배치한다. 가장 단순하게 보면 hash(key) % partition_count 계열의 문제다.

Kafka에서 같은 key를 같은 partition으로 보내는 이유는 보통 per-key ordering 때문이다. 한 partition 안에서는 record order가 보존되지만, 여러 partition 사이에는 전체 순서가 없다.

따라서 partition 수를 늘리면 주의해야 한다. key-to-partition mapping이 바뀔 수 있고, 같은 key가 과거와 다른 partition으로 갈 수 있다. Kafka 문서도 partition 수를 바꾸는 일이 key 기반 ordering과 partitioning에 영향을 줄 수 있음을 설명한다.

여기서 tradeoff가 나온다.

Rebalancing은 계산보다 운영 비용이 크다

Consistent Hashing은 이동해야 할 key 범위를 줄여준다. 하지만 이동이 “공짜”라는 뜻은 아니다.

노드 추가나 제거가 발생하면 실제로는 다음 비용이 생긴다.

• 네트워크 대역폭: 새 owner에게 데이터를 streaming해야 한다.
• 디스크 I/O: 읽고 쓰는 작업이 foreground traffic과 경쟁한다.
• cache miss: ownership이 바뀐 구간은 cache가 따뜻하지 않다.
• LSM compaction: Cassandra, ScyllaDB 같은 LSM 계열에서는 이동된 SSTable과 compaction이 tail latency를 흔들 수 있다.
• 운영 위험: 장애 복구와 scale-out이 동시에 일어나면 rebalance가 더 오래 걸린다.

그래서 좋은 partitioning은 단지 “어디에 둘까”가 아니라 “바뀔 때 얼마나 조용히 움직일 수 있을까”까지 포함한다.

언제 Consistent Hashing을 떠올려야 할까

다음 조건이 보이면 Consistent Hashing을 검토할 만하다.

• 서버 수가 자주 바뀐다.
• key ownership이 안정적이어야 한다.
• cache miss나 data movement 비용이 크다.
• 중앙 coordinator 없이도 ownership을 계산하고 싶다.
• partitioning과 replication을 함께 설계해야 한다.

반대로 단순하고 작은 시스템이라면 그냥 modulo hashing이나 명시적 shard map이 더 낫다. Consistent Hashing은 분산 시스템의 변화 비용을 줄이는 도구이지, 모든 배치 문제를 자동으로 해결하는 마법은 아니다.

한 문장으로 정리하면

Consistent Hashing은 key와 node를 같은 hash space에 배치해서, node 추가와 제거가 일어나도 전체 key를 다시 흔들지 않고 영향받는 구간만 이동시키는 distributed placement algorithm이다.

하지만 현실의 어려움은 그 다음에 온다. vnode로 구간 편차를 줄이고, replication으로 가용성을 만들고, quorum과 repair로 일관성을 다루고, hot key와 rebalancing 비용을 운영에서 견뎌야 한다. 균등한 hash는 시작일 뿐이고, 좋은 분산 시스템은 데이터 크기와 요청량과 이동 비용이 서로 다르다는 사실을 계속 다룬다.

참고한 자료

• Consistent Hashing and Random Trees, Karger et al.
• Dynamo: Amazon’s Highly Available Key-value Store
• Apache Cassandra - Dynamo
• Apache Cassandra - Adding, replacing, moving and removing nodes
• Apache Kafka - Basic Kafka Operations
• Apache Kafka - Protocol, Partitioning and bootstrapping