이것이 점프 투 공작소

피쳐 추출 시스템에 대해 알아보자

겅겅겅 — Fri, 29 Aug 2025 00:25:54 +0900

추적 시스템에서 데이터 마이닝은 필수적인 작업입니다.

마이닝 작업 중 가장 보편적이고 구현하기 쉬운 작업 중 하나인 '피쳐 추출' 시스템과 각 요소들에 대해 간단히 알아보려고 합니다.

피쳐란?

'피쳐((feature))'는 단일 스팬에서 계산할 수 없는 하나 이상의 값을 계산하는 프로세스를 의미합니다.

피쳐 데이터들은 어떤게 있을까?

피쳐는 거의 실시간으로 계산됩니다.

따라서 APM은 이를 시계열로 보거나 추세를 모니터링하거나 경보를 제공하게 됩니다.

피쳐로 추출되어 보여지는 대표적인 데이터들은 아래와 같습니다.

추적의 총 대기 시간
추적 시간 시간
스팬 수
네트워크 호출 횟수
루트 서비스 및 해당 엔드포인트 이름
클라이언트 타입
대기 시간 분석: CDN, 백엔드, 네트워크, 스토리지 등
다양한 메타데이터: 클라이언트 호출 발신 국가, 요청을 처리하는 데이터 센터

데이터 마이닝 파이프라인 구성 요소

아래 그림은 데이터 마이닝 파이프라인 아키텍쳐와 실제 프레임워크를 사용한 예시 그림입니다.

agent와 추적 백엔드를 통해 들어온 데이터는 트리거에 의해 피쳐 추출기로 전달되고 집계 후 최종 storage에 도착합니다.

추적 완료 트리거

추적 완료 트리거는 Collector에 존재하며,

요청이 데이터 마이닝 파이프라인에서 처리할 준비가 되었다는 판단을 하는 구간입니다.

OTel에서는 주로 SpanProcessor((Batch))에서 OTLP Exporter로 전달되고 최종적으로 Collector로 전달하는데

이 과정은 Span을 전달하는 과정일 뿐입니다.

하지만 피쳐추출에서는 span이 아닌 trace에 대한 정보가 필요합니다.

따라서 Collector에서 trace가 종료되었는지 판단 후 파이프라인으로 보내야 합니다.

Trace 완료를 판단하는 방법

APM과 collector는 서로 다른 프로그램이기에 정확하게 trace의 종료 시점을 알 수 없기에 몇가지 기준으로 판단해야합니다.

collector에서는 전달받은 span을 버퍼로 모아두고 몇가지 기준을 가지고 해당 span이 trace가 완료되었는지 판단합니다.

가장 간단한 방법은 첫 스팬을 수집 후 해당 span에 대한 trace가 끝날 때 까지 일정 시간동안 무작정 기다리는 방법입니다.

추가적으로 대기시간, 최대 대기시간, 강제 flush 이벤트와 같은 기능들을 사용합니다.

먼저 이 방법의 단점은 네트워크 측면에서 p99 보다 더 높은 대기 시간을 일상적으로 경험하는 사용자가 있을 수 있는데,

이 경우에 대해서 너무 짧은 타임 윈도우를 사용하게 되면 이런 요청에 대한 실제 추적이 끝나기 전 트리거에서 trace가 끝났다고 판단하게 됩니다.

하지만 몇가지 개선점이 존재하는데,

하나는 부모 스팬에서 자식 스팬의 수를 collector에 같이 전달해주면 해당 값을 이용해 trace의 완료를 판단 할 수 있고,

또 하나는 과거 데이터를 머신러닝하여 해당 span의 trace 종료 시점을 판단하는 방법입니다.

피쳐 추출기

피쳐 추출기에서는 추적 결과를 수신하고, trace와 span에서 적절한 데이터를 추출 후 피처를 계산하는 비즈니스 로직이 실행됩니다.

collector로는 RPS, 에러율, 지연 히스토그램, 서비스 맵과 같은 기본적인 분석을 만들고

피쳐 추출기를 사용해서 원인 분석, 최적화, 병목/변화 감시, ML을 사용한 예측, 이상탐지와 같은 기능들을 알 수 있습니다.

집계 연산기 ((Agggregator))

추출기에서 추출한 피쳐들을 비즈니스 로직에 맞게 집계하여 수치로 변환시켜줍니다.

Ad-hoc 분석 ((임시 분석))

피쳐 추출을 위한 데이터 마이닝은 기본적으로 실시간 데이터들에 대한 값들입니다.

AWS의 athena 처럼 저장해둔 피쳐 데이터들을 기반으로 쿼리를 통해 원하는 가치를 탐색하는 분석 방법입니다.

-- 지난 30일 /checkout p95 추세
SELECT window_start, p95
FROM endpoint_agg_1m
WHERE service='checkout' AND route='/orders/{id}' AND method='GET'
  AND window_start >= now() - INTERVAL 30 DAY
ORDER BY window_start;

피벗 추적에 대해 알아보자

겅겅겅 — Sun, 3 Aug 2025 22:57:55 +0900

피벗 추적이란?

분산 추적 시스템 내부의 계측 가능한 한 지점에서 측정값을 정의하고.

다른 지점에서 지정한 그 값을 기반으로 선택,필터링,그룹화 하여 클라이언트에서 전체 시스템을 관측 할 수 있게 하는 기능입니다.

예를 들어 아래 쿼리는 HBase,맵리듀스,HDFS 클라이언트를 실행하는 다른 클라이언트의 요청을 처리하는 HDFS 데이터 노드에 적용되는 쿼리입니다.

즉 분산 시스템 내부에서 "클라이언트가 얼마나 데이터를 읽었는지"를 추적하기 위한 코드입니다.

FROM bytesRead IN DataNodeMetrics.incrBytesRead
JOIN client IN FIRST(ClientProtocols) ON client => bytesRead
GROUP BY client.procName
SELECT cleint.procName, SUM(bytesRead.delta)

쿼리를 한줄씩 해석해 보면,

DataNodeMetrics.incrBytesRead 는 데이터 노드에서 바이트를 읽을 때 발생하는 추적 지점입니다.

이 지점에서 수집된 이벤트를 bytesRead 로 alias 지정합니다.

ClientProtocols는 클라이언트에서 시스템에 요청을 보낼 때 발생하는 지점입니다.

First 함수를 통해 ClientProtocols에 처음 도착한 이벤트를 client라는 alias로 가져오고, 그 요청이 bytesRead 이벤트를 유발했다고 정의합니다.

추적 시스템은 client.traceId == bytesRead.traceId를 기반으로 join합니다.

client안의 정보 안에 procName을 기준으로 데이터를 그룹화하고, 예를 들어 HDFS, Spark, Hive 등 프로세스 이름으로 그룹화 됩니다.

마지막으로 각 그룹별로 유발한 bytesRead.delta, 합계를 구합니다.

피벗 추적 흐름도

피벗 추적 흐름에서 주목할 만한 점은 컨텍스트 전파가 이루어 질 때,

최초 발생하는 추적 포인트에 피벗 추적에 필요한 데이터((traceId, procName 등))를 배기지에 저장해 전파합니다.

이후 이벤트가 발생하는 시점에 실제 집계에 필요한 데이터를 추출 후 배기지에 넣습니다.

최종적으로 배기지는 튜플로 전환 후 프론트에 전달되어 집계 후 원하는 쿼리 결과를 보여줍니다.

마무리

APM의 피벗 추적의 구현에 대해서는 책에서도 많이 다루지 않고 논문을 확인하라고 하는데,

아무래도 실제 APM을 만들 때 피벗 추적에 대해 더 공부 후 추가 포스팅을 해야겠습니다.

분산추적의 샘플링에 대해서 알아보자

겅겅겅 — Fri, 18 Jul 2025 23:24:46 +0900

APM에서는 어플리케이션의 모든 요청을 다 추적하고 분석하지 않습니다.

추적 데이터는 실제 어플리케이션의 비즈니스 트래픽을 쉽게 초과할 수 있으며, 이는 서비스에 영향을 주게됩니다.

요청을 100% 샘플링한다면 대퍼 추적기는 검색 작업에 대해 1.5%의 처리량과 16%의 시간지연 오버헤드가 발생한다고 합니다.

그렇기에 추적 시스템들은 추적의 특정 부분만을 캡쳐하기위해 샘플링을 사용합니다.

만약 추적의 0.01%만 캠쳐하도록 샘플링하면 처리량 오버헤드는 0.06%, 응답시간은 0.20% 감소한다고 합니다.

따라서 적절한 양의 요청들을 샘플링하는건 분산추적 어플리케이션에서 매우 중요한 요소입니다.

헤드 기반((head-based)) 샘플링

upfront sampling이라고도 하며, 들어오는 각각 추적들에 대해서 매번 샘플링 여부를 결정합니다.

일반적으로 추적은 인프라스트럭쳐, 웹서버를 지나 어플리케이션에 들어온 순간부터 시작됩니다.

헤드 기반 샘플링은 추적 시스템이 특정 추적((Trace))의 모든 스팬을 캡쳐하거나 또는 아무것도 캡쳐하지 않기에 추적(Trace)에 대해 일관적이라는 특징이 있습니다.

추적이 어플리케이션에 진입하면 해당 추적이 샘플링 되어야 좋을지, 되지 않아야 좋을지 판단해야하는데,

해당 추적에 대한 정보가 거의 없기에 판단이 어렵습니다.

그렇지만 헤드기반 샘플링은 아직까지도 많은 추적 시스템에서 사용하는 방식입니다.

헤드 기반의 반대로는 테일 기반 샘플링이 있습니다.

확률적 샘플링

확률적 샘플링 결정은 특정 확률값을 갖는 랜덤 기반으로 이뤄집니다.

이 샘플링 방식은 헤드 기반 샘플링을 이용한 추적 시스템에서 가장 많이 사용되는 샘플링 방식입니다.

스프링 클라우드 슬루스((Spring Cloud Sleuth))도 확률적 샘플러를 활용합니다.

예거((jaegor))는 요청 1000개당 1번의 추적이 만들어지도록 기본 샘플링 확률이 0.001로 설정되어 있습니다.

일정 시간동안 특정 서비스 엔드포인트 X에 대해 100개의 추적을 수집했다고 가정하고,

샘플링 확률 p를 알면, 이 시간 동안 엔드포인트 X에 대한 총 호출 수를 100/p로 확률적 샘플리의 샘플링 데이터 양을 추정 할 수 있습니다.

속도 제한 샘플링

샘플링 방법 중 하나로 속도 제한기((rate limiter))를 사용하는 방법도 있습니다.

보통 레저부아 샘플링 알고리즘을 사용합니다.

속도 제한기((rate limiter))는 초당 10개의 추적 또는 1분당 하나의 추적 등 지정된 시간 간격마다 고정된 수의 추적만 샘플링합니다.

속도 제한 샘플링은 불규칙한 트래픽 패턴을 보이는 MSA에 유용합니다.

레저부아 샘플링에 대해서는 다른 포스팅에서 다루었으니 혹시,, 궁금하신분은 아래 글에서 확인할 수 있습니다.

https://jaykos96.tistory.com/104

실시간 대용량 데이터에서 사용되는 알고리즘(Reservoir Sampling, HLL, CMS,Bloom Filter)들에 대해 알아보

스트리밍 시스템에서 모은 많은 데이터들은 시스템 안에서 효율적으로 분석되고 집계되어야합니다.아무래도 실시간이고 방대한 데이터를 대상으로 하는 만큼 '확률적인 알고리즘'이 많이 사용

jaykos96.tistory.com

처리량 보장 확률적 샘플링

처리량 보장 샘플러((guraranteed-throughput sampler))를 사용해 특정 상황에 트래픽이 급증하는 서비스가 있는 서비스에 적절한 샘플링 방식입니다.

확률적 샘플러와 속도 제한기((rate limiter))를 결합한 것입니다.

기본적으로는 확률적샘플링을 사용합니다, 하지만 서비스가 off-peak 기간이라면 요청이 추적되지 않을 수 있는데,

이를 방지하기 위해 지정된 시간 간격 이후에는 속도 제한기((rate limiter))를 사용해 요청이 하나도 샘플링되지 않는 상황을 방지합니다.

사실 현재 이 방식은 현재 거의 사용되지 않으나, 이 샘플링을 토대로 적응형 샘플링이 만들어졌습니다.

적응형 샘플링

서비스의 API들이 받는 트레픽은 다양합니다.

자주 사용하는 API는 트레픽이 많을 것이고, 어떤 API는 요청이 적을 것 입니다.

그렇기에 각 상황에 맞게 적응하는 샘플링 방식이 필요합니다.

적응형 샘플링은 기본적으로 수집한 처리량이 목표량을 넘어서면 샘플링 확률을 낮추는 방식입니다.

샘플링 확률은 동적으로 변경되며 각 서버에서 환경설정 파라미터를 읽어서 적용합니다.

적응형 샘플링은 각 서비스의 트래픽에 따라 자동으로 샘플링 비율을 조절하여,

아래 목표들을 안정적으로 달성하고자 합니다.

서비스의 특징에 따라 추구하는 목표의 우선순위가 다를 수 있습니다.

1. TPS ((Traces per Second))

서비스 인스턴스당 평균 초당 몇 개의 트레이스를 수집할지 목표를 설정합니다.

2. SPS ((Spans per Second))

스팬 수의 양을 고려하여 목표를 설정합니다.

3. BPS ((Bytes per Second))

스팬 크기를 고려하여 목표를 설정합니다.

적응형 샘플링 이론

예거((jaegor))의 샘플링을 가지고 샘플링에 대해 알아보겠습니다.

예거의 샘플링은 고전적인 PID ((proportional-integral-derivative)) 제어기와 유사합니다.

아키텍쳐적인 개념만 어느정도의 비슷하다고 생각하면 될 것 같습니다.

출처 : https://yunslog.tistory.com/78

PID는 현재 output y((t))) , 프로세스 값을 관찰하고, output은 Process 처리되기 전에 보정신호 u((t)) 로 인해 변경됩니다.

최초 입력인 원하는 프로세스 값과 output 사이의 오차((Error))를 최소화하기 위해 PID는 비례식(P), 적분 항(I), 미분 항(D)로 구성된 제어기의 가중치의 합계로 보정신호 u((t))가 계산됩니다.

이런 PID의 개념을 샘플링에 적용해 보면

y((t))는 실측값, 특정 시간 동안 모든 인스턴스를 대상으로 특정 서비스에 대해 샘플링된 추적의 수, 최종 Output TPS입니다.
r((t))는 허용추적률, 어플리케이션에서 오버헤드 수준과 추적 백엔드의 용량을 고려해 허용 가능하다고 생각하는 TPS, 원하는 Input TPS입니다.
u((t))는 알고리즘으로 계산하는 샘플링 확률입니다.
오류는 e((t)) = r((t))-y((t)), 목표값 - 현재값으로 계산합니다.

예거(Jaeger)의 적응형 샘플링

카운터((Counter))는 수집기가 수집한 모든 루트 스팬을 받아서 루트 스팬의 카운트 수를 집계합니다.

일정 시간 동안 카운트 수를 수집하고, 이후 데이터베이스의 Counts 테이블에 저장합니다.

즉 샘플링 여부와 상관없이 전체 요청수를 저장하는 위한 테이블입니다.

m분 동안 수집한 Counts 테이블 데이터들을 사용해 각 엔드포인트에 대한 y((t)), TPS를 계산합니다.

m은 loopback period 인데 보통 10분으로 설정합니다.

m, loopback period 값을 사용하는 이유는, 순간적인 트레픽의 증가와 같은 상황을 평균화해서 이후 적용될 샘플링 확률이 부드럽게 조정되도록 할 수 있기 때문입니다.

y((t))를 이후 Input TPS와 비교하여 개별 서비스나 엔드포인트에 대한 보정 신호((샘플링 확률)) u((t)) 계산 후 Targets 테이블에 저장합니다.

이후 제어기((Controller))는 Targets 테이블에서 계산된 샘플링확률을 읽어 메모리에 캐시한 다음 각 추적기로 전송합니다.

추적기는 주기적으로 수집기를 폴링하여 샘플링 전략을 가져옵니다.

예거((Jaeger))의 리더 선출

샘플링 확률을 계산하는 리더 노드는 하나여야합니다.

리더 선출을 위해 리더 임대((leader lease)) 정책을 사용하는데,

각 수집기에서 일정주기로 카산드라((Cassandra))의 compare-and-set 연산으로 리더 임대((leader lease)) 튜플 ((N,T)) 을 저장합니다.

여기서 N은 경쟁자의 이름 또는 ID이고 T는 임대 만료 시간입니다.

수집기는 리더 임대 튜플을 사용해 통해 T시간 까지 자신((N))이 리더를 하겠다는 의도를 전달합니다.

만약 튜플을 전달했을 때 그 기간에 리더가 없으면 튜플을 보낸 노드가 리더가 됩니다.

리더 임대 방식은 완전한 리더 선출 알고리즘((Paxos, Raft 등))에 비해서는 불완전합니다.
네트워크 지연이나 타이밍 이슈로 인해 잠시 동안 두 수집기가 동시에 리더가 될수도 있습니다.

그러나 적응형 샘플링의 목적은 트래픽 기반의 확률 조정이며, 수 초 단위의 오차는 큰 문제가 되지 않는다고 판단하기에, 현실적인 해결책입니다.

샘플링 확률 u((t)) 계산법

계산기(Calculator)가 m, loopback period 기간에 대한 누적 카운트 수를 읽었을 때

y((t))의 현재 값을 얻기 위해 이들을 모두 합하고 (m)으로 나눕니다.

u((t))의 예상값은 아래와 같이 계산합니다.

\[
u'(t) = u(t - 1) \times q,\quad q = \frac{r(t)}{y(t)}
\]

u'((t))은 새로 계산된 식, q는 보정계수, u((t-1)) 이전에 가지고 있던 보정값

(t)는loopback period의 시간 인덱스입니다.

\[
q = \frac{r(t)}{y(t)} = \frac{10}{20} = \frac{1}{2}
\Rightarrow
u'(t) = u(t-1) \times q = \frac{u(t-1)}{2}
\]

위와 같은 수식은 r((t))=10TPS이고 현재 속도는 y((t))=20TPS라고 가정합니다.

이러한 상황에서는 보정계수 q는 1/2가 되고,

이는 현재 서비스에서 사용중인 샘플링 확률이 너무 높아서 절반으로 줄인다는 의미입니다.

위와 같은 상황이 된다면 과다한 샘플링을 하고 있다고 판단한 것이고, 추적 벡엔드에 과부하가 걸렸던 상황이기에 가능한 한 빠르게 적용하며 어플리케이션의 특이사항 없이 적용됩니다.

\[
q = \frac{r(t)}{y(t)} = \frac{20}{10} = 2
\Rightarrow
u'(t) = u(t-1) \times q = 2 \times u(t-1)
\]

반면 위 처럼 r((t))=20TPS이고 현재 속도는 y((t))=10TPS이 된다면, 기존보다 샘플링해야하는 추적이 2배가 되고,

보정값 q가 증가하게되면, 몇가지 문제가 발생할 수 있습니다.

간단한 예로 어플리케이션에 많은 양의 데이터가 들어오는 30분 단위의 batch 작업이 있다고 해봅시다.

batch 시간이 아닐때는 추적이 거의 없으므로 샘플링 확률을 올려서 더 많은 추적을 샘플링하려 합니다.

이 때 갑자기 배치가 실행되면 올라간 샘플링 확률과 배치의 데이터가 맞물려 많은양의 추적이 발생하게되고 이는 서비스에 대한 지연으로 발전 할 수 있습니다.

그렇기에 적응형 샘플링에서는 p > 1이면 샘플링값을 바로 계산하지 않고 댐핑 함수(damping function) (B)를 사용합니다.

이를 통해 PID의 제어기의 도함수 항처럼, 샘플링 확률값의 급증을 늦츨 수 있습니다.

예거의 댐핑 함수는 확률값 증가율 (\theta)를 부과합니다. (\theta는 보통 0.5로 설정합니다.

\[
\beta(p_{\text{new}}, p_{\text{old}}, \theta) =
\begin{cases}
p_{\text{old}} \cdot (1 + \theta), & \text{if } \frac{p_{\text{new}} - p_{\text{old}}}{p_{\text{old}}} > \theta \\
p_{\text{new}}, & \text{otherwise}
\end{cases}
\]

(p_\text{old}) 와 (p_\text{new}) 는 이전 확률 u((t-1))과 새로운 확률 u'((t))를 의미합니다.

예를들어, (p_\text{old})기존값이 0.1이고 (p_\text{new})가 0.35로 증가하는 상황이라면,

\[
p_{\text{old}} = 0.2,\; p_{\text{new}} = 0.35,\; \theta = 0.5 \Rightarrow \frac{p_{\text{new}} - p_{\text{old}}}{p_{\text{old}}} = 0.75 > \theta \Rightarrow \beta(p_{\text{new}}, p_{\text{old}}, \theta) = 0.2 \cdot (1 + 0.5) = 0.3
\]

새로운 샘플링 확률 0.35는 급격히 증가한 것이므로, 최종적으로 (\beta)는 0.3이 적용됩니다.

따라서 최종 u((t))를 구하는 수식은 아래와 같습니다.

\[
u(t) =
\begin{cases}
\min\left[1,\; \beta\left(u'(t),\; u(t-1),\; \theta\right)\right] & \text{if } u'(t) < u(t-1) \\
u'(t) & \text{otherwise}
\end{cases}
\]

적응형 샘플링의 확장

앞서 살펴본 샘플링 방식은 기본적으로 시간을 기준으로 트래픽 양을 적절하게 유지하는데 목적이 있었습니다.

하지만 경우에 따라 적응형 샘플링은 트래픽 수 뿐만 아니라 초당 스팬 수, 초당 바이트 크기에 대해서도 최적화가 필요합니다.

y((t))를 아래와 같은 식을 사용해 계산하여 스팬 수, 바이트 크기에 대한 비율을 적용할 수 있습니다.

// S: 하나의 추적이 생성하는 스팬의 평균수
// B: 하나의 추적이 생성하는 평균 바이트 크기

(초당 스팬 수) = (초당 추적 수) × S  
(초당 바이트 수) = (초당 추적 수) × B

추가로 고려해야할 부분은 하한 속도 계산기((lower-bound rate limiter))입니다.

서비스가 새로운 서비스가 배포 될 때, 해당 서비스의 수집기에서는 대상 샘플링 확률 u((t))를 계산할 데이터가 없습니다.

그렇다면 u((t))는 기본값이 적용되는데, 이는 필요에 따라 보수적으로 매우 낮게 설정되어 있을수도 있습니다.

새로운 서비스가 많은 트래픽을 얻지 못하면 적절한 추적 데이터를 얻을 수 없기에,

하한 속도 계산기를 사용해 새로운 서비스의 적응형 샘플러에서 계산할 충분한 데이터를 확보하게 도와줘야합니다.

기존 계산식에 보정치 (r)을 사용하는 방식으로 적용합니다.

u(t)=max(u(t),r)

하한속도 보정에 대한 단점도 분명 존재합니다.

만약 하한추적으로 1분에 한 번씩 추적하도록 설정된 서비스가 있을 때, 갑자기 1000개의 인스턴스에 서비스가 배포된다고 가정해봅시다.

그러면 각각 매분 하나의 추적을 샘플링하거나 초당 1000 / 60 = 16.7개의 추적을 샘플링하게 됩니다.

이렇게 되면 하한 속도 계산기((lower-bound rate limiter))에 의해 너무 많은 추적을 얻게 됩니다.

이럴 때는 해결 방안으로 해당 수치를 파악할 수 있는 배포 시스템과 통합하는 방법을 고려할수도 있고, 아니면 하한 속도를 계산하는 적응형 알고리즘을 사용하는 방법도 있습니다.

또한 서비스의 특정 부분에 주의를 집중시키고 더 높은 빈도로 샘플링해야하는 상황이 있습니다.

예를 들어 서비스의 특정 버전에서 문제가 발생한다면 해당 버전에 대한 샘플링만을 더 높힌다면 더 빠르게 돌발상황에 대처 할 수 있습니다.

그렇기에 추적 시스템에서는 이런 상황에 대처 할 수 있도록, 유연한 기능 메커니즘이 필요합니다.

위와 같은 상황을 대처하기 위해서는 컨텍스트-맞춤형 샘플링을 구현해서 사용해야합니다.

오버샘플링 처리 방법

앞서 계속 살펴보았듯 서비스에서 적절한 샘플링을 적용하는건 어려운일입니다.

하지만 추적 시스템을 사용하는 클라이언트는 아마도 모든 샘플링들을 감지하고 처리하는 추적 시스템을 원할 것 입니다.

그렇게 샘플링확률을 올리다보면 오버샘플링이 될 수 있는데,

예거에서는 과부하로부터 서비스를 보호하기 위한 두가지 방법, 다운샘플링과 스로틀링이 존재합니다.

스로틀링과 포스트-컬렉션 다운샘플링

스로틀링 방식은 서비스에서 지나치게 많은 추적이 시작되었다고 판단되면 Drop Policy을 사용해서 추적을 조절하는 방식이며,

다운샘플링은 추적이 수집계층에 도착한 후, 2차 샘플링을 수행해서 오버샘플링을 처리하는 방법입니다.

먼저 traceId를 해시로 변환해서 0~1 사이의 실수로 변경합니다.

이후 지정한 확률보다 작으면 샘플링하고 크면 버립니다.

val downSamplingProbability: Double = 0.1

def downSample(span: Span): Boolean = {
  if (span.isDebug) {
    return false
  }

  val z: Double = hash(span.traceId)
  return z < downSamplingProbability
}

테일 기반의 일관성 있는 샘플링

사실 헤드 기반 샘플링은 비정상적인 요청이나 특정 상황에 의미가 있는 요청이 존재할때 해당 요청이 추적되지 않을 확률이 존재합니다.

하지만 테일 기반 샘플링은 일단 모든 추적을 수집한 후 샘플링을 진행합니다.

일종의 pull model과 비슷합니다.

반면 모든 트래픽에 대한 추적을 일단 수집해야하기에, 헤드기반에 비해 큰 오버헤드가 발생합니다.

또한 일단 수집된 데이터가 샘플링이 되기 전까지 어딘가에 데이터를 보관해야합니다.

보통 어플리케이션에서 헤드 기반과 테일 기반 샘플링은 모두 동일한 비율로 데이터를 샘플링하기에 추가 오버헤드를 피하기 위해 메모리에 추적 데이터를 보관하는게 합리적이라고 합니다.

하지만 서비스 상황에 따라 적절하게 저장소를 활용하는게 중요할 것 같습니다..

아래 그림은 2개의 마이크로서비스에서 2개의 요청 T1, T2를 테일기반으로 샘플링하는 상황입니다.

모든 요청은 수집기(Controller)로 전달됩니다.

수집기는 Stateless하기에 수집기에 잠시 저장될 때, TraceId 기반의 데이터 파티션이 필요합니다.

예를들어 'hash(traceId) % 수집기 수'와 같은 방법으로 TraceID를 구분하고,

파티션을 통해 각각의 Span들이 TraceId로 파티션되어 서로 다른 수집기로 가는 상황을 방지합니다.

최종적으로 샘플링 정책을 통해 T2요청만 샘플링되어 저장되며 T1은 버려집니다.

테일 기반에서의 샘플링 전략은 아래와 같습니다.

1. 대기 시간 기반 샘플링

추적의 대기 시간((latency))를 기준으로 샘플링합니다.

예를 들어 lantecy가 0ms ~ 2ms 구간에 들어오는 요청은 버리거나 낮은 확률로 샘플링합니다.

반면 100ms 이상 또는 1초 이상 대기가 있던 요청은 중요하게 판단하여 우선으로 샘플링합니다.

2. 에러 여부 기반 샘플링

추적 중 에러가 발생한 트레이스는 무조건 적으로 샘플링합니다.

3. 클러스터링 기반 샘플링

유사한 유형의 트레이스, 예를들어 경로, 사용자, 쿼리 등을 클러스터링해서 그룹화된 요청들의 대표값들만 샘플링합니다.

특정 요청에 가중치를 두어 샘플링 할수도 있습니다.

정리

포스팅하면서 찾아보니 Datadog, X-ray와 같은 유명 APM들을 비롯해 많은 APM들은 헤드기반 샘플링에 보조적으로 중요하거나 데이터가 큰 스팬들은 테일기반 샘플링하는 경우가 많은 것 같습니다.

즉 헤드 기반으로 1차로 샘플링하고, 큰 요청이나 오류가 있는 요청들은 테일기반으로 수집해서 구분하여 저장하는 방식인 것 같습니다!

분산추적에서 다른 프로세스, 외부 서비스간 전파는 어떻게 이루어질까

겅겅겅 — Sun, 29 Jun 2025 23:41:41 +0900

회사에서 분산추적APM을 사용하며 가장 궁금했던 부분은,

'다른 프로세스, 외부 서비스간 이동이 발생이 있었는데, 어떻게 하나의 추적이라고 계속 인식하는거지?' 였습니다.

오픈소스인 OTel 자바 프로젝트를 통해 분산추적 구현의 중요한 챕터 중 하나인 Context 전파에 대해서 알아보려고 합니다.

https://github.com/open-telemetry/opentelemetry-java-instrumentation

GitHub - open-telemetry/opentelemetry-java-instrumentation: OpenTelemetry auto-instrumentation and instrumentation libraries for

OpenTelemetry auto-instrumentation and instrumentation libraries for Java - open-telemetry/opentelemetry-java-instrumentation

github.com

여기서 말하는 Context는 APM의 추적, Trace에서 계속해서 생성되는 Span들이 하나의 Trace안에서 순차적으로 이어지기 위해 필요한 정보를 의미합니다.

Span과 Trace에 대해서는 다른 포스팅에서 다루겠습니다.

APM에서 어떻게 프로세스, 스레드 변경을 탐지할까?

OTel의 추적은 LocalThread 기반으로 만들어져 있어, 기본적으로 동일 스레드 안에서만 APM의 Context를 공유합니다.

그렇기에 새로운 프로세스, 스레드에 대한 추적을 적용하려면 LocalThread -> NewThread간 Context를 공유해야하기에

에이전트는 새로운 스레드의 생성을 지속적으로 감시하고있습니다.

새롭게 스레드를 생성하는 Runnable, Callable, ExecutorService 등을 감지하면, 에이전트에서 내부적으로 Context.wrap()를 호출하여 새로운 스레드에 Context가 추가된 Context 객체로 바꿔치기 합니다.

wrap은 Context 객체의 메소드로 자바의 스레드 관련 메소드가 실행될 때 현재 Context를 추가해주는 메소드입니다.

  default Runnable wrap(Runnable runnable) {
    return () -> {
      try (Scope ignored = makeCurrent()) {
        runnable.run();
      }
    };
  }

또 HTTP, RPC 클라이언트 호출과 같은 경우에는 에이전트가 Context 정보를 헤더에 실어 보냅니다.

수신하는 쪽에서는 Context를 추출하여 Cotext를 사용합니다.

추가로 OTel에서 Spring Batch의 추적과 계측은 아직 experimental상태로 OTel의 프로퍼티 옵션을 통해 활성은 가능하지만

기본적으로 비활성화 되어있기에 다루지 않으려고 합니다.

멀티스레드가 발생 했을 때

OTel은 기본적으로 LocalThread에 Context를 저장하기에 새롭게 스레드가 생긴다면, 해당 스레드에서 생성되는 Span은 이전 Context를 가지고 있지 않습니다.

즉 하나의 Trace로 연결될 수 없기에, 새로운 스레드에 Context를 넘겨주는 작업이 필요합니다.

자바에서 Executor, ExecutorService같은 스레드 관련 클래스가 실행되면,

에이전트가 bytecode 레벨에서 해당 코드를 변경하여, 새로운 스레드가 실행 될때 현재 wrap메소드를 사용해 현재 Context를 넣어줍니다.

Executor.submit(() -> { ... })
Executor.submit(Context.current().wrap(() -> { ... }))

앞서 잠깐 언급하였듯 wrap메소드는 각 Executor관련 메소드들을 wrap하여 makeCurrent로 현재 Context를 넣어주는 역할을 합니다.

자바의 Runnable 말고도 여러 메소드에 대한 wrap이 존재하며, Context.taskWrapping()를 사용해 Executor 자체를 감싸서 사용 할 수도 있습니다.

  default Runnable wrap(Runnable runnable) {
    return () -> {
      try (Scope ignored = makeCurrent()) {
        runnable.run();
      }
    };
  }

  default <T> Callable<T> wrap(Callable<T> callable) {
    return () -> {
      try (Scope ignored = makeCurrent()) {
        return callable.call();
      }
    };
  }

  default Executor wrap(Executor executor) {
    return command -> executor.execute(wrap(command));
  }

  default ExecutorService wrap(ExecutorService executor) {
    if (executor instanceof ContextExecutorService) {
      return executor;
    }
    return new ContextExecutorService(this, executor);
  }

  default ScheduledExecutorService wrap(ScheduledExecutorService executor) {
    if (executor instanceof ContextScheduledExecutorService) {
      return executor;
    }
    return new ContextScheduledExecutorService(this, executor);
  }

비동기 호출 시

CompletableFuture, @Async 등의 비동기 호출 또한 내부적으로 작업 스레드가 분리되어 새로운 스레드에서 실행되므로,

기본적으로 멀티 스레드에서의 Context전파와 동일한 방식이 사용됩니다.

HTTP, RPC, Kafka 호출이 발생 했을 때

멀티스레드가 아닌 http, rpc, 메시징 시스템 kafka 등을 활용한 호출이 발생했을때는

각 방법들에 맞게 Context를 옮겨주는 작업이 필요합니다.

이 때 OTel에서는 Context를 전파할 때 Instrumenter 객체를 공통적으로 사용합니다.

Instrumenter

에이전트에서 span을 생성하는데 필요한 객체입니다.

요청이 들어오면 에이전트는 Instrumenter를 사용해 span을 생성하고 종료시킵니다.

샘플링 여부 등을 파악해서 span의 시작여부를 결정하는 shouldStart() ,

span을 시작하는 start(), 종료하는 end() 메소드로 구성되어 있습니다.

public class Instrumenter<REQUEST, RESPONSE> {

  ...

  public boolean shouldStart(Context parentContext, REQUEST request) {
    SpanKind kind = spanKindExtractor.extract(request);
    return enabled && !spanSuppressor.shouldSuppress(parentContext, kind);
  }

  public Context start(Context parentContext, REQUEST request) {
    return doStart(parentContext, request, null);
  }

  public void end(Context context, REQUEST request, RESPONSE response, Throwable error) {
    doEnd(context, request, response, error, null);
  }

HTTP 호출이 발생 했을 때

http 모듈이 감지되면 에이전트에서는 헤더에 traceparent, tracestate라는 key에 Context를 담아서 전달합니다.

OTel에서는 Propagator객체를 사용하여 이 작업을 수행합니다.

Inject()를 호출하여 헤더에 Context를 담고 , Extract()를 통해 헤더에 담긴 Context들을 추출해서 사용합니다.

RestTemplate를 사용하는 경우 에이전트에서는 RestTemplateInterceptor를 bean-post-processor를 통해 모든 RestTemplate인스턴스에 추가하고, WebClient의 경우에는 WebClient.Builder Bean을 후처리하여 http요청을 감지합니다.

참고로 http호출이 발생하면 APM입장에서는 http호출이 시작되는 시점에 span을 생성하고, http응답을 받는 시점에 종료되는 'http호출'에 대한 하나의 span이 존재해야합니다. 해당 span을 통해 trace를 더 정확하게 관리 할 수 있습니다.

traceparent, tracestate

traceId와 Context를 담아 보내는 W3C의 규격 헤더입니다.

traceparent는 필수지만, tracestate는 부가정보입니다.

아래는 traceparent를 규정하는 W3C규격이며, trace-flags는 샘플링된 추적인지 여부를 확인합니다.

01은 샘플링되는 추적, 00은 샘플링되지 않는 추적을 의미합니다.

traceparent: {version}-{trace-id}-{span-id}-{trace-flags}

00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

W3CTraceContextPropagator

propagator 객체는 http뿐만 아니라 rpc, 메시징 시스템에서 Context를 전달하기 위해 사용하는 객체입니다.

inject(), extract()메소드를 사용해 Context를 주입, 추출합니다.

Inject

W3CTraceContextPropagator 객체의 Inject() 메소드입니다.

Context에 담긴 SpanContext를 traceparent, tracestate 헤더에 추가합니다.

파라미터의 C carrier는 헤더를 담을 객체, HttpHeaders 또는 Map입니다.

@Override
  public <C> void inject(Context context, @Nullable C carrier, TextMapSetter<C> setter) {
    if (context == null || setter == null) {
      return;
    }

    SpanContext spanContext = Span.fromContext(context).getSpanContext();
    if (!spanContext.isValid()) {
      return;
    }

    char[] chars = TemporaryBuffers.chars(TRACEPARENT_HEADER_SIZE);
    chars[0] = VERSION.charAt(0);
    chars[1] = VERSION.charAt(1);
    chars[2] = TRACEPARENT_DELIMITER;

    String traceId = spanContext.getTraceId();
    traceId.getChars(0, traceId.length(), chars, TRACE_ID_OFFSET);

    chars[SPAN_ID_OFFSET - 1] = TRACEPARENT_DELIMITER;

    String spanId = spanContext.getSpanId();
    spanId.getChars(0, spanId.length(), chars, SPAN_ID_OFFSET);

    chars[TRACE_OPTION_OFFSET - 1] = TRACEPARENT_DELIMITER;
    String traceFlagsHex = spanContext.getTraceFlags().asHex();
    chars[TRACE_OPTION_OFFSET] = traceFlagsHex.charAt(0);
    chars[TRACE_OPTION_OFFSET + 1] = traceFlagsHex.charAt(1);
    setter.set(carrier, TRACE_PARENT, new String(chars, 0, TRACEPARENT_HEADER_SIZE));
    TraceState traceState = spanContext.getTraceState();
    if (traceState.isEmpty()) {
      // No need to add an empty "tracestate" header.
      return;
    }
    setter.set(carrier, TRACE_STATE, encodeTraceState(traceState));
  }

Extract

요청이 도착하면 에이전트는 http헤더에서 traceparent, tracestate를 꺼내서 Context를 복원합니다.

  @Override
  public <C> Context extract(Context context, @Nullable C carrier, TextMapGetter<C> getter) {
    if (context == null) {
      return Context.root();
    }
    if (getter == null) {
      return context;
    }

    SpanContext spanContext = extractImpl(carrier, getter);
    if (!spanContext.isValid()) {
      return context;
    }

    return context.with(Span.wrap(spanContext));
  }

RPC 호출이 발생 했을 때

rpc에서는 메타데이터에 Context를 넣어서 전달합니다.

http와 동일하게 propagator클래스의 Extract(), Inject() 메소드를 사용하며, traceparent, tracestate는 RPC Metadata 키로서 사용됩니다.

에이전트에서 TracingClientInterceptor, TracingServerInterceptor에서 rpc을 감지하여 context를 주입합니다.

sendMessage, OnMessage

rpc 요청을 보내고 수신할 때,

Interceptor에서는 어떤 메시지가 몇 개 오갔는지, 또 언제 어떤 순서로 처리됐는지를 분석하기 위해

sendMessage(), on onMessage() 메소드를 사용해 자동으로 증가하는 메시지ID와 메시지 타입 SEND, RECEIVED를 저장합니다.

메시지 ID와 메시지 타입은 sendMessage()와 onMessage() 안에서 Span 이벤트로 기록됩니다.

    @Override
    public void sendMessage(REQUEST message) {
      try (Scope ignored = context.makeCurrent()) {
        super.sendMessage(message);
      } catch (Throwable e) {
        instrumenter.end(context, request, Status.UNKNOWN, e);
        throw e;
      }
      long messageId = SENT_MESSAGE_ID_UPDATER.incrementAndGet(this);
      if (emitMessageEvents) {
        Attributes attributes = Attributes.of(MESSAGE_TYPE, SENT, MESSAGE_ID, messageId);
        Span.fromContext(context).addEvent("message", attributes);
      }
    }

@Override
public void onMessage(REQUEST message) {
  long messageId = RECEIVED_MESSAGE_ID_UPDATER.incrementAndGet(TracingServerCall.this);
  if (emitMessageEvents) {
    Attributes attributes = Attributes.of(MESSAGE_TYPE, RECEIVED, MESSAGE_ID, messageId);
    Span.fromContext(context).addEvent("message", attributes);
  }
  delegate().onMessage(message);
}

TracingClientInterceptor-interceptCall

gRPC의 ClientInterceptor를 상속받아 interceptCall를 오버라이드하여, rpc가 나갈 때 Context를 추기해주는 역할을 합니다.

final class TracingClientInterceptor implements ClientInterceptor {

  ...

  @Override
  public <REQUEST, RESPONSE> ClientCall<REQUEST, RESPONSE> interceptCall(
      MethodDescriptor<REQUEST, RESPONSE> method, CallOptions callOptions, Channel next) {
    GrpcRequest request = new GrpcRequest(method, null, null, next.authority());
    Context parentContext = Context.current();
    if (!instrumenter.shouldStart(parentContext, request)) {
      return next.newCall(method, callOptions);
    }

    Context context = instrumenter.start(parentContext, request);
    ClientCall<REQUEST, RESPONSE> result;
    try (Scope ignored = context.makeCurrent()) {
      // call other interceptors
      result = next.newCall(method, callOptions);
    } catch (Throwable t) {
      instrumenter.end(context, request, Status.UNKNOWN, t);
      throw t;
    }

    return new TracingClientCall<>(result, parentContext, context, request);
  }

  
  final class TracingClientCall<REQUEST, RESPONSE>
      extends ForwardingClientCall.SimpleForwardingClientCall<REQUEST, RESPONSE> {

    private final Context parentContext;
    private final Context context;
    private final GrpcRequest request;

    // Used by SENT_MESSAGE_ID_UPDATER
    @SuppressWarnings("UnusedVariable")
    volatile long sentMessageId;

    // Used by RECEIVED_MESSAGE_ID_UPDATER
    @SuppressWarnings("UnusedVariable")
    volatile long receivedMessageId;

    TracingClientCall(
        ClientCall<REQUEST, RESPONSE> delegate,
        Context parentContext,
        Context context,
        GrpcRequest request) {
      super(delegate);
      this.parentContext = parentContext;
      this.context = context;
      this.request = request;
    }

    @Override
    public void start(Listener<RESPONSE> responseListener, Metadata headers) {
      propagators.getTextMapPropagator().inject(context, headers, MetadataSetter.INSTANCE);
      // store metadata so that it can be used by custom AttributesExtractors
      request.setMetadata(headers);
      try (Scope ignored = context.makeCurrent()) {
        super.start(
            new TracingClientCallListener(responseListener, parentContext, context, request),
            headers);
      } catch (Throwable e) {
        instrumenter.end(context, request, Status.UNKNOWN, e);
        throw e;
      }
    }
  
  ...
  
}

TracingClientCallListener

rpc의 interceptCall 메소드를 호출하기 위해서는 인자로 Listener를 전달해야하는데 이 때 OTel에서는 커스텀한 리스너 TracingClientCallListener를 전달합니다.

TracingClientCallListener는 클라이언트가 rpc 호출할 때 start() 내부에서 생성되며 gRPC의 ClientCall.Listener를 상속받아서 클라이언트가 서버 응답을 받을 때마다, Span에 이벤트를 찍고, Span을 종료하는 실질적인 역할을 합니다.

final class TracingClientInterceptor implements ClientInterceptor {

  ...

    final class TracingClientCallListener
        extends ForwardingClientCallListener.SimpleForwardingClientCallListener<RESPONSE> {

      private final Context parentContext;
      private final Context context;
      private final GrpcRequest request;

      TracingClientCallListener(
          Listener<RESPONSE> delegate,
          Context parentContext,
          Context context,
          GrpcRequest request) {
        super(delegate);
        this.parentContext = parentContext;
        this.context = context;
        this.request = request;
      }

      @Override
      public void onMessage(RESPONSE message) {
        long messageId = RECEIVED_MESSAGE_ID_UPDATER.incrementAndGet(TracingClientCall.this);
        if (emitMessageEvents) {
          Attributes attributes = Attributes.of(MESSAGE_TYPE, RECEIVED, MESSAGE_ID, messageId);
          Span.fromContext(context).addEvent("message", attributes);
        }
        try (Scope ignored = context.makeCurrent()) {
          delegate().onMessage(message);
        }
      }

      @Override
      public void onClose(Status status, Metadata trailers) {
        request.setPeerSocketAddress(getAttributes().get(Grpc.TRANSPORT_ATTR_REMOTE_ADDR));
        if (captureExperimentalSpanAttributes) {
          Span span = Span.fromContext(context);
          span.setAttribute(
              GRPC_RECEIVED_MESSAGE_COUNT, RECEIVED_MESSAGE_ID_UPDATER.get(TracingClientCall.this));
          span.setAttribute(
              GRPC_SENT_MESSAGE_COUNT, SENT_MESSAGE_ID_UPDATER.get(TracingClientCall.this));
        }
        instrumenter.end(context, request, status, status.getCause());
        try (Scope ignored = parentContext.makeCurrent()) {
          delegate().onClose(status, trailers);
        }
      }

      @Override
      public void onReady() {
        try (Scope ignored = context.makeCurrent()) {
          delegate().onReady();
        }
      }
    }
  }
}

TracingServerInterceptor-interceptCall

gRPC의 ServerInterceptor를 상속받아 interceptCall를 오버라이드하여, rpc가 들어오면 컨텍스트를 추출하고 Context에 저장합니다.

final class TracingServerInterceptor implements ServerInterceptor {

  ...

  @Override
  public <REQUEST, RESPONSE> ServerCall.Listener<REQUEST> interceptCall(
      ServerCall<REQUEST, RESPONSE> call,
      Metadata headers,
      ServerCallHandler<REQUEST, RESPONSE> next) {
    String authority = call.getAuthority();
    if (authority == null) {
      // Armeria grpc server call does not implement getAuthority(). In
      // ArmeriaServerCallInstrumentation we store the value for the authority header in a virtual
      // field.
      authority = GrpcAuthorityStorage.getAuthority(call);
    }
    GrpcRequest request =
        new GrpcRequest(
            call.getMethodDescriptor(),
            headers,
            call.getAttributes().get(Grpc.TRANSPORT_ATTR_REMOTE_ADDR),
            authority);
    Context parentContext = Context.current();
    if (!instrumenter.shouldStart(parentContext, request)) {
      return next.startCall(call, headers);
    }

    Context context = instrumenter.start(parentContext, request);

    try (Scope ignored = context.makeCurrent()) {
      return new TracingServerCall<>(call, context, request).start(headers, next);
    } catch (Throwable e) {
      instrumenter.end(context, request, Status.UNKNOWN, e);
      throw e;
    }
  }

  final class TracingServerCall<REQUEST, RESPONSE>
      extends ForwardingServerCall.SimpleForwardingServerCall<REQUEST, RESPONSE> {
    private final Context context;
    private final GrpcRequest request;
    private Status status;

    // Used by SENT_MESSAGE_ID_UPDATER
    @SuppressWarnings("UnusedVariable")
    volatile long sentMessageId;

    // Used by RECEIVED_MESSAGE_ID_UPDATER
    @SuppressWarnings("UnusedVariable")
    volatile long receivedMessageId;

    TracingServerCall(
        ServerCall<REQUEST, RESPONSE> delegate, Context context, GrpcRequest request) {
      super(delegate);
      this.context = context;
      this.request = request;
    }

  
}

TracingServerInterceptor

서버가 rpc 요청을 수신할 때 interceptCall() 내부에서 생성되며, 요청을 받는 동안 메시지의 수신,완료,취소 처리를 합니다.

final class TracingServerInterceptor implements ServerInterceptor {

    ...
    
    final class TracingServerCallListener
        extends ForwardingServerCallListener.SimpleForwardingServerCallListener<REQUEST> {
      private final Context context;
      private final GrpcRequest request;

      TracingServerCallListener(Listener<REQUEST> delegate, Context context, GrpcRequest request) {
        super(delegate);
        this.context = context;
        this.request = request;
      }

      private void end(Context context, GrpcRequest request, Status response, Throwable error) {
        if (captureExperimentalSpanAttributes) {
          Span span = Span.fromContext(context);
          span.setAttribute(
              GRPC_RECEIVED_MESSAGE_COUNT, RECEIVED_MESSAGE_ID_UPDATER.get(TracingServerCall.this));
          span.setAttribute(
              GRPC_SENT_MESSAGE_COUNT, SENT_MESSAGE_ID_UPDATER.get(TracingServerCall.this));
          if (Status.CANCELLED.equals(status)) {
            span.setAttribute(GRPC_CANCELED, true);
          }
        }
        instrumenter.end(context, request, response, error);
      }

      @Override
      public void onHalfClose() {
        try {
          delegate().onHalfClose();
        } catch (Throwable e) {
          instrumenter.end(context, request, Status.UNKNOWN, e);
          throw e;
        }
      }

      @Override
      public void onCancel() {
        try {
          delegate().onCancel();
        } catch (Throwable e) {
          end(context, request, Status.UNKNOWN, e);
          throw e;
        }
        end(context, request, Status.CANCELLED, null);
      }

      @Override
      public void onComplete() {
        try {
          delegate().onComplete();
        } catch (Throwable e) {
          end(context, request, Status.UNKNOWN, e);
          throw e;
        }
        if (status == null) {
          status = Status.UNKNOWN;
        }
        end(context, request, status, status.getCause());
      }

      @Override
      public void onReady() {
        try {
          delegate().onReady();
        } catch (Throwable e) {
          end(context, request, Status.UNKNOWN, e);
          throw e;
        }
      }
    }
  }
}

메시징 시스템에서는?

컨슈머와 프로듀서를 사용해서 데이터를 전달할때는 kafka의 send(), poll() 메소드를 wrap해서 propagator의 inject(), extract()를 사용하여 Context를 넣어줍니다.

Context 값의 key는 다른 방식들과 동일하게 traceparent입니다.

메시징 시스템에서 각 요청,응답 span은 process, received로 표현됩니다.

Producer-wrap

java의 동적 Proxy로 kafka의 Producer를 감싸서 kafka의 send메소드를 인터셉트해서 값들을 buildAndInjectSpan에 넣어줍니다.

kafka의 콜백이 있으면 콜백도 넣어줍니다.

public final class KafkaTelemetry {
  
  ...


  /** Returns a decorated {@link Producer} that emits spans for each sent message. */
  @SuppressWarnings("unchecked")
  public <K, V> Producer<K, V> wrap(Producer<K, V> producer) {
    return (Producer<K, V>)
        Proxy.newProxyInstance(
            KafkaTelemetry.class.getClassLoader(),
            new Class<?>[] {Producer.class},
            (proxy, method, args) -> {
              // Future<RecordMetadata> send(ProducerRecord<K, V> record)
              // Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback)
              if ("send".equals(method.getName())
                  && method.getParameterCount() >= 1
                  && method.getParameterTypes()[0] == ProducerRecord.class) {
                ProducerRecord<K, V> record = (ProducerRecord<K, V>) args[0];
                Callback callback =
                    method.getParameterCount() >= 2
                            && method.getParameterTypes()[1] == Callback.class
                        ? (Callback) args[1]
                        : null;
                return buildAndInjectSpan(record, producer, callback, producer::send);
              }
              try {
                return method.invoke(producer, args);
              } catch (InvocationTargetException exception) {
                throw exception.getCause();
              }
            });
  }

  ...
}

buildAndInjectSpan

buildAndInjectSpan에서는 Context를 꺼내고, OTel의 Kafka DTO, KafkaProducerRequest객체를 이용해 요청과 producer를 wrap 후, shouldStart 메소드로 해당 요청이 샘플링 되는 요청인지 확인합니다.

샘플링이 필요없으면 span생성 없이 카프카로 요청을 전달하고 필요하다면 span을 inject하여 요청을 전달합니다.

<K, V> Future<RecordMetadata> buildAndInjectSpan(
      ProducerRecord<K, V> record,
      Producer<K, V> producer,
      Callback callback,
      BiFunction<ProducerRecord<K, V>, Callback, Future<RecordMetadata>> sendFn) {
    Context parentContext = Context.current();

    KafkaProducerRequest request = KafkaProducerRequest.create(record, producer);
    if (!producerInstrumenter.shouldStart(parentContext, request)) {
      return sendFn.apply(record, callback);
    }

    Context context = producerInstrumenter.start(parentContext, request);
    propagator().inject(context, record.headers(), SETTER);

    try (Scope ignored = context.makeCurrent()) {
      return sendFn.apply(record, new ProducerCallback(callback, parentContext, context, request));
    }
}

Consumer-wrap

Producer와 동일하게 동적 Proxy를 사용해 kafka의 Consumer 를 wrap합니다.

proxy는 람다함수를 가로채서 poll() 메소드가 발생하면 먼저 시간 체크 작업을 시작합니다.

poll() 결과가 ConsumerRecords이면, ConsumerRecords는 여러 kafka메시지를 가지고 있는 객체입니다.

buildAndFinishSpan() 메소드를 실행시켜 poll()한 kafka메시지로 Context를 만들고 반환합니다.

이후 receiveContext, KafkaConsumer를 인자로 KafkaConsumerContext를 만들어 addTracing() 메소드를 호출해 반복문을 돌며 각 메시지마다 span을 만듭니다.

public final class KafkaTelemetry {
  
  ...

  /** Returns a decorated {@link Consumer} that consumes spans for each received message. */
  @SuppressWarnings("unchecked")
  public <K, V> Consumer<K, V> wrap(Consumer<K, V> consumer) {
    return (Consumer<K, V>)
        Proxy.newProxyInstance(
            KafkaTelemetry.class.getClassLoader(),
            new Class<?>[] {Consumer.class},
            (proxy, method, args) -> {
              Object result;
              Timer timer = "poll".equals(method.getName()) ? Timer.start() : null;
              try {
                result = method.invoke(consumer, args);
              } catch (InvocationTargetException exception) {
                throw exception.getCause();
              }
              // ConsumerRecords<K, V> poll(long timeout)
              // ConsumerRecords<K, V> poll(Duration duration)
              if ("poll".equals(method.getName()) && result instanceof ConsumerRecords) {
                ConsumerRecords<K, V> consumerRecords = (ConsumerRecords<K, V>) result;
                Context receiveContext = buildAndFinishSpan(consumerRecords, consumer, timer);
                if (receiveContext == null) {
                  receiveContext = Context.current();
                }
                KafkaConsumerContext consumerContext =
                    KafkaConsumerContextUtil.create(receiveContext, consumer);
                result = addTracing(consumerRecords, consumerContext);
              }
              return result;
            });
  }

}

addTracing

카프카 메시지들에 span을 붙이는 메소드입니다.

카프카 파티션의 메시지들을 consumerProcessInstrumenter를 사용하여 span의 시작과 종료를 감지하도록합니다.

  <K, V> ConsumerRecords<K, V> addTracing(
      ConsumerRecords<K, V> consumerRecords, KafkaConsumerContext consumerContext) {
    if (consumerRecords.isEmpty()) {
      return consumerRecords;
    }

    Map<TopicPartition, List<ConsumerRecord<K, V>>> records = new LinkedHashMap<>();
    for (TopicPartition partition : consumerRecords.partitions()) {
      List<ConsumerRecord<K, V>> list = consumerRecords.records(partition);
      if (list != null && !list.isEmpty()) {
        list = TracingList.wrap(list, consumerProcessInstrumenter, () -> true, consumerContext);
      }
      records.put(partition, list);
    }
    return new ConsumerRecords<>(records);
  }

Reactive 환경

reactive 체인에서는 스레드가 언제든지 변경 될 수 있기에, OTel의 LocalThread 기반의 Context 전파를 사용할 수 없습니다.

reactor 관련 메소드가 실행되면 wrap 후 hook을 만들어 체인간의 Context전파를 해주어야합니다.

참고로 webflux환경, 즉 netty의 멀티플렉싱 환경에서 추적은 bossGroup의 스레드가 아닌 Worker스레드에서부터 시작합니다.

ContextPropagationOperator

reactor 연산자들에 hook을 추가해주는 클래스입니다.

reactor의 연산자들은 내부적으로 모두 Subscriber를 만들고 다음 연산자에게 넘깁니다.

즉 모든 체인은 내부적으로 CoreSubscriber 클래스가 사용됩니다.

ContextPropagaionOperator 클래스에서 registerOnEachOperator의 tracingLift() 함수로 연산자마다 TracingSubscriber가 들어가도록 합니다.

public final class ContextPropagationOperator {

   ...
   
      public void registerOnEachOperator() {
        synchronized (lock) {
          if (enabled) {
            return;
          }
          Hooks.onEachOperator(
              TracingSubscriber.class.getName(), tracingLift(asyncOperationEndStrategy));
          AsyncOperationEndStrategies.instance().registerStrategy(asyncOperationEndStrategy);
          registerScheduleHook(RunnableWrapper.class.getName(), RunnableWrapper::new);
          enabled = true;
        }
      }
   
   ...
   
  }

tracingLift 함수에서 reactor가 연산자마다 Subscriber를 생성할 때 그걸 감싸주는 Lifter를 등록합니다.
Lifter를 통해 원래 subscriber를 TracingSubscriber로 감싸게 됩니다.

private static <T> Function<? super Publisher<T>, ? extends Publisher<T>> tracingLift(...) {
  return Operators.lift(
      ContextPropagationOperator::shouldInstrument, 
      new Lifter<>(...));
}

public CoreSubscriber<? super T> apply(Scannable publisher, CoreSubscriber<? super T> sub) {
  return new TracingSubscriber<>(sub, sub.currentContext());
}

마무리

분산추적에서 각 상황에 대해서 Context를 어떻게 전파하는지 OTel프로젝트를 보며 정리해 보았는데,

오픈소스를 처음으로 분석하다 보니 이런식으로 분석하는게 맞는건지 또 좋은건지 판단이 어렵네요.

어느정도 흐름은 이해했는데, 아무래도 직접 코드를 작성해봐야 어떤 디테일들이 있는지 알 수 있을 것 같습니다.

OpenTelemetry 프로젝트를 보며 공부하는 분산추적의 핵심요소들

겅겅겅 — Fri, 20 Jun 2025 00:19:41 +0900

APM을 직접 만들어 저의 사이드 프로젝트들에 쓰고싶다는 작은 소망이 있었습니다.

지금부터 APM을 만들기 위한 공부들과 만드는 과정들을 같이 포스팅하려고 합니다.

화이팅

첫번째로 CNCF 표준이자 분산 추적 프레임워크인 OpenTelemetry, OTel의 구조와 핵심 구성요소

Trace, Span, Baggage, Metric, Log 에 대해 알아보겠습니다.

OTel이란?

이전에 분산추적을 구현하는 방식은 매우 다양했고 대부분 직접 만들어 사용했기에 각 서비스들에 종속되어 있는 방식이었습니다.

시간이 지날수록 표준의 필요성이 느껴지게 되었고 두가지 오픈 소스가 만들어졌습니다.

하나는 구글의 내부 라이브러리 집합인 센서스((Census))에서 시작된 오픈센서스((OpenCensus))

하나는 CNCF 프로젝트인 OpenTracing입니다.

지금은 이 두 프로젝트가 합쳐저 OpenTelementry가 되었습니다.

OpenTelementry는 Jaeger, Zipkin과 같은 어플리케이션이 아니고 예시와 같은 추적서버에 데이터를 전송하는 역할을 합니다.

SDK와 API는 openTelementry-java프로젝트에 있고 Agent관련 파일은 openTelementry-java-instrumentation 프로젝트에 있습니다.

저는 먼저 자바 APM을 만들고자 해당 프로젝트를 좀 살펴보려합니다.

다른 생태계는 JavaAPM 먼저 만들고 한번 도전해 볼까 합니다,,

https://github.com/open-telemetry/opentelemetry-java

GitHub - open-telemetry/opentelemetry-java: OpenTelemetry Java SDK

OpenTelemetry Java SDK. Contribute to open-telemetry/opentelemetry-java development by creating an account on GitHub.

github.com

https://github.com/open-telemetry/opentelemetry-java-instrumentation

GitHub - open-telemetry/opentelemetry-java-instrumentation: OpenTelemetry auto-instrumentation and instrumentation libraries for

OpenTelemetry auto-instrumentation and instrumentation libraries for Java - open-telemetry/opentelemetry-java-instrumentation

github.com

트레이서 ((Tracer))

분산 추적 시스템에서 요청은 여러 서비스와 컴포넌트 등 다양한 홉((hop))을 거치게 되는데 Trace는 그 전체에 대한 경로를 의미하며 각 Trace들은Trace_Id로 구분됩니다.

Trace들은 여러 hop들을 통과하면서 스팬((Span))을 생성하는 역할을 합니다.

Tracer는 TracerProvider로 부터 생성되며, Provider는 TracerProvider는 어플리케이션의 수명주기와 동일합니다.

Expoter를 통해 Tracer를 Consumer, 다른 서버에 보낼수도 있다고 합니다.

근데 코드를 찾아보니 TracerExpoter는 따로 없고 SpanExtoter에서 해당 기능을 수행합니다.

이제 Tracer쪽 소스코드를 간략히 살펴보려고합니다.

Tracer

Tracer 인터페이스는 Span을 생성하는 SpanBuilder를 생성하는 메소드 하나만 있습니다.

@ThreadSafe
public interface Tracer {

  /**
   * Returns a {@link SpanBuilder} to create and start a new {@link Span}.
   *
   * <p>See {@link SpanBuilder} for usage examples.
   *
   * @param spanName The name of the returned Span.
   * @return a {@code Span.Builder} to create and start a new {@code Span}.
   */
  SpanBuilder spanBuilder(String spanName);
}

Tracer_ID

Tracer_ID가 어떻게 생성되는지 살펴보겠습니다.

개인적으로 이런 오픈소스를 통해서 공부하는게 처음이라, 어떤식으로 ID를 관리하는지 궁금했었는데 이제야 확인해보게 되네요

trace_id의 크기는 16byte입니다.

id를 사용할때는 이를 절반, 8byte로 나누어 high, low로 구분합니다.

이렇게 구분하여 사용하는 이유는 byte[16]과 같이 사용하면 jvm에서 heap객체로 사용되어서 G.C의 영향을 받게 됩니다.

반면 원시타입 long을 사용하면 G.C의 영향을 받지 않기에 이런식으로 구분하여 사용한다고 합니다.

또한 값이 모두 0이면 유효하지 않은 Trace로 취급합니다.

string으로 출력할때는 16진수 문자열로 변환하여 32자리의 string을 사용합니다.

public final class TraceId {
  private static final int BYTES_LENGTH = 16;
  private static final int HEX_LENGTH = 2 * BYTES_LENGTH;
  private static final String INVALID = "00000000000000000000000000000000";

  private TraceId() {}

  ...
 
   public static String fromLongs(long traceIdLongHighPart, long traceIdLongLowPart) {
    if (traceIdLongHighPart == 0 && traceIdLongLowPart == 0) {
      return getInvalid();
    }
    char[] chars = TemporaryBuffers.chars(HEX_LENGTH);
    OtelEncodingUtils.longToBase16String(traceIdLongHighPart, chars, 0);
    OtelEncodingUtils.longToBase16String(traceIdLongLowPart, chars, 16);
    return new String(chars, 0, HEX_LENGTH);
  }
 
 ...
}

Trace_ID의 생성은 RandomIdGenerator 객체를 이용해 high, low id값을 만들어 조합후 리턴해줍니다.

enum RandomIdGenerator implements IdGenerator {
  INSTANCE;

  private static final long INVALID_ID = 0;
  private static final Supplier<Random> randomSupplier = RandomSupplier.platformDefault();

  @Override
  public String generateSpanId() {
    long id;
    Random random = randomSupplier.get();
    do {
      id = random.nextLong();
    } while (id == INVALID_ID);
    return SpanId.fromLong(id);
  }

  @Override
  public String generateTraceId() {
    Random random = randomSupplier.get();
    long idHi = random.nextLong();
    long idLo;
    do {
      idLo = random.nextLong();
    } while (idLo == INVALID_ID);
    return TraceId.fromLongs(idHi, idLo);
  }

  @Override
  public String toString() {
    return "RandomIdGenerator{}";
  }
}

Tracer가 가지고 있는 정보들

Tracer는 span을 만드는 간단한 업무만 하지만, Tracer가 자체적으로 가지고 있는 정보도 중요합니다.

Tracer에 어떤 값들이 있어야하는지 SdkTracerBuilder와 Tracer의 구현체 SdkTracer 코드를 통해 알아보겠습니다.

TracerBuilder

SdkTracerBuilder 부터 먼저 알아보겠습니다.

Tracer를 만드는 빌더 클래스입니다.

TracerBuilder에는 가 어떤 기능에 사용될지 지정하는 instrumentationScopeName, 주로 라이브러리나 모듈을 지정합니다.

해당 Version, URL 정보를 넣기위한 schemaUrl이 존재합니다.

그리고 이렇게 만들어둔 Tracer 인스턴스를 재사용하기 위한 registry가 있습니다.

build() 메소드는 레지스트리에 해당 트레이서가 없으면 생성하는 역할까지 합니다.

Builder를 통해 생성된 각 Tracer는 고유한 이름을 사용해 해당 Tracer가 어떤 라이브러리나 모듈에 속하는지 식별합니다.

예를들어 "io.opentelemetry.contrib.mongodb"라는 이름((instrumentationScopeName))의 Tracer를 통해 생성된 Span들은 MongoDB 관련 작업을 의미하도록 추적에 명시 할 수 있습니다.

Tracer는 여러 개 만들어질 수 있지만, 일반적으로 구성요소별로 하나씩만 생성하여 재사용합니다.

class SdkTracerBuilder implements TracerBuilder {

  private final ComponentRegistry<SdkTracer> registry;
  private final String instrumentationScopeName;
  @Nullable private String instrumentationScopeVersion;
  @Nullable private String schemaUrl;

  SdkTracerBuilder(ComponentRegistry<SdkTracer> registry, String instrumentationScopeName) {
    this.registry = registry;
    this.instrumentationScopeName = instrumentationScopeName;
  }

  @Override
  public TracerBuilder setSchemaUrl(String schemaUrl) {
    this.schemaUrl = schemaUrl;
    return this;
  }

  @Override
  public TracerBuilder setInstrumentationVersion(String instrumentationScopeVersion) {
    this.instrumentationScopeVersion = instrumentationScopeVersion;
    return this;
  }

  @Override
  public Tracer build() {
    return registry.get(
        instrumentationScopeName, instrumentationScopeVersion, schemaUrl, Attributes.empty());
  }
}

SdkTracer

SDK에서 사용하는 Tracer의 구현체입니다.

생성자 부분을 보면 3가지 객체가 들어갑니다.

각 객체들을 살펴보겠습니다.

class SdkTracer implements Tracer {
  static final String FALLBACK_SPAN_NAME = "<unspecified span name>";
  private static final Tracer NOOP_TRACER = TracerProvider.noop().get("noop");
  private static final boolean INCUBATOR_AVAILABLE;

  static {
    boolean incubatorAvailable = false;
    try {
      Class.forName("io.opentelemetry.api.incubator.trace.ExtendedDefaultTracerProvider");
      incubatorAvailable = true;
    } catch (ClassNotFoundException e) {
      // Not available
    }
    INCUBATOR_AVAILABLE = incubatorAvailable;
  }

  private final TracerSharedState sharedState;
  private final InstrumentationScopeInfo instrumentationScopeInfo;
  protected boolean tracerEnabled;

  SdkTracer(
      TracerSharedState sharedState,
      InstrumentationScopeInfo instrumentationScopeInfo,
      TracerConfig tracerConfig) {
    this.sharedState = sharedState;
    this.instrumentationScopeInfo = instrumentationScopeInfo;
    this.tracerEnabled = tracerConfig.isEnabled();
  }

1. TracerSharedState

Tracer가 공통적으로 가지고 있는 설정값들입니다.

final class TracerSharedState {

 ...

  TracerSharedState(
      Clock clock,
      IdGenerator idGenerator,
      Resource resource,
      Supplier<SpanLimits> spanLimitsSupplier,
      Sampler sampler,
      List<SpanProcessor> spanProcessors,
      ExceptionAttributeResolver exceptionAttributeResolver) {
		...
  }

clock : Span의 시작/종료 시간을 측정
idGenerator : TraceId, SpanId를 만드는 객체
idGeneratorSafeToSkipIdValidation : ID 생성 검증 생략 여부
resource : 해당 Trace가 속한 서비스/환경 정보
activeSpanProcessor : Span종료 시 Export 등 종료 처리 객체
exceptionAttributeResolver : 예외처리
shutdownResult : 종료 상태 저장

2. InstrumentationScopeInfo

앞서 살펴보았던 Tracer의 기본 정보(ScopeName, Version, SchemaUrl)를 담는 객체입니다.

public final class InstrumentationScopeInfoBuilder {

  private final String name;
  @Nullable private String version;
  @Nullable private String schemaUrl;
  @Nullable private Attributes attributes;
  
   ... 
  
  }

3. TracerConfig

Tracer가 생성 될 때 Tracer의 생성을 막는 메소드입니다.

불필요한 계측을 할 것 같다거나, 라이브러리의 성능의 이슈가 있을 수 있을경우 명시적으로 해당 scope의 tracer를 막기 위한 설정값으로 사용합니다.

public abstract class TracerConfig {

  private static final TracerConfig DEFAULT_CONFIG =
      new AutoValue_TracerConfig(/* enabled= */ true);
  private static final TracerConfig DISABLED_CONFIG =
      new AutoValue_TracerConfig(/* enabled= */ false);

  /** Returns a disabled {@link TracerConfig}. */
  public static TracerConfig disabled() {
    return DISABLED_CONFIG;
  }

  /** Returns an enabled {@link TracerConfig}. */
  public static TracerConfig enabled() {
    return DEFAULT_CONFIG;
  }
  
  ...
  
  }

이제 생성자 아래 부분 코드도 살펴보겠습니다.

개념적으로 계속 Tracer는 Span을 생성한다고 했지만 코드상으로는 Span을 만드는 SpanBuilder를 리턴합니다.

class SdkTracer implements Tracer {
  ...
  
  /**
   * Note that {@link ExtendedSdkTracer#spanBuilder(String)} calls this and depends on it returning
   * {@link ExtendedSdkTracer} in all cases when the incubator is present.
   */
  @Override
  public SpanBuilder spanBuilder(String spanName) {
    if (!tracerEnabled) {
      return NOOP_TRACER.spanBuilder(spanName);
    }
    if (spanName == null || spanName.trim().isEmpty()) {
      spanName = FALLBACK_SPAN_NAME;
    }
    if (sharedState.hasBeenShutdown()) {
      return NOOP_TRACER.spanBuilder(spanName);
    }
    return INCUBATOR_AVAILABLE
        ? IncubatingUtil.createExtendedSpanBuilder(
            spanName, instrumentationScopeInfo, sharedState, sharedState.getSpanLimits())
        : new SdkSpanBuilder(
            spanName, instrumentationScopeInfo, sharedState, sharedState.getSpanLimits());
  }

  ...
}

TraceProvider

Tracer들의 팩토리입니다.

보통 어플리케이션 시작 시 TraceProvider를 초기화하여 전역으로 사용합니다.

TracerProvider는 Stateful한 객체로서 샘플링, SpanProcessor, Exporter 등 추적 구성((config)) 정보를 보유하여 해당 Provider에서 만들어진 모든 Tracer와 Span에 일관된 설정을 적용합니다.

메소드에 get밖에 없어서 어디서 Tracer를 만드는거지? 했지만 타고타고 살펴보면 구현체의 get()메소드가 실행되면 Tracer들의 저장소인 ComponentRegistry에서 원하는 Tracer가 없으면 생성하는 역할까지 하고있습니다.

package io.opentelemetry.api.trace;

import javax.annotation.concurrent.ThreadSafe;

@ThreadSafe
public interface TracerProvider {

  /**
   * Returns a no-op {@link TracerProvider} which only creates no-op {@link Span}s which do not
   * record nor are emitted.
   */
  static TracerProvider noop() {
    return DefaultTracerProvider.getInstance();
  }

  /**
   * Gets or creates a named tracer instance.
   *
   * @param instrumentationScopeName A name uniquely identifying the instrumentation scope, such as
   *     the instrumentation library, package, or fully qualified class name. Must not be null.
   * @return a tracer instance.
   */
  Tracer get(String instrumentationScopeName);

  /**
   * Gets or creates a named and versioned tracer instance.
   *
   * @param instrumentationScopeName A name uniquely identifying the instrumentation scope, such as
   *     the instrumentation library, package, or fully qualified class name. Must not be null.
   * @param instrumentationScopeVersion The version of the instrumentation scope (e.g., "1.0.0").
   * @return a tracer instance.
   */
  Tracer get(String instrumentationScopeName, String instrumentationScopeVersion);

  /**
   * Creates a TracerBuilder for a named {@link Tracer} instance.
   *
   * @param instrumentationScopeName A name uniquely identifying the instrumentation scope, such as
   *     the instrumentation library, package, or fully qualified class name. Must not be null.
   * @return a TracerBuilder instance.
   * @since 1.4.0
   */
  default TracerBuilder tracerBuilder(String instrumentationScopeName) {
    return DefaultTracerBuilder.getInstance();
  }
}

SdkTraceProvider

SDK에서 사용하는 TraceProvider의 구현체입니다.

Tracer의 설정값을 지정하는 생성자, 익스포터로 전송하는 flush메소드, 가장 핵심인 Tracer를 만드는 get()메소드도 구현되어있습니다.

또한 이미 만들어둔 Tracer 객체를 TracerBuilder를 통해 재사용하기 위한 ComponentRegistry 객체와,

상황에 따라 기존 설정값이 아닌 다른 설정값을 새로이 지정할 수 있도록 하는 setTracerConfigurator메소드도 보입니다.

참고로 ComponentRegistry는 Map을 통해 Tracer들을 관리합니다.

public final class SdkTracerProvider implements TracerProvider, Closeable {
  private static final Logger logger = Logger.getLogger(SdkTracerProvider.class.getName());
  static final String DEFAULT_TRACER_NAME = "";
  private final TracerSharedState sharedState;
  private final ComponentRegistry<SdkTracer> tracerSdkComponentRegistry;
  // deliberately not volatile because of performance concerns
  // - which means its eventually consistent
  private ScopeConfigurator<TracerConfig> tracerConfigurator;

  /**
   * Returns a new {@link SdkTracerProviderBuilder} for {@link SdkTracerProvider}.
   *
   * @return a new {@link SdkTracerProviderBuilder} for {@link SdkTracerProvider}.
   */
  public static SdkTracerProviderBuilder builder() {
    return new SdkTracerProviderBuilder();
  }

  @SuppressWarnings("NonApiType")
  SdkTracerProvider(
      Clock clock,
      IdGenerator idsGenerator,
      Resource resource,
      Supplier<SpanLimits> spanLimitsSupplier,
      Sampler sampler,
      List<SpanProcessor> spanProcessors,
      ScopeConfigurator<TracerConfig> tracerConfigurator,
      ExceptionAttributeResolver exceptionAttributeResolver) {
    this.sharedState =
        new TracerSharedState(
            clock,
            idsGenerator,
            resource,
            spanLimitsSupplier,
            sampler,
            spanProcessors,
            exceptionAttributeResolver);
    this.tracerSdkComponentRegistry =
        new ComponentRegistry<>(
            instrumentationScopeInfo ->
                SdkTracer.create(
                    sharedState,
                    instrumentationScopeInfo,
                    getTracerConfig(instrumentationScopeInfo)));
    this.tracerConfigurator = tracerConfigurator;
  }

  private TracerConfig getTracerConfig(InstrumentationScopeInfo instrumentationScopeInfo) {
    TracerConfig tracerConfig = tracerConfigurator.apply(instrumentationScopeInfo);
    return tracerConfig == null ? TracerConfig.defaultConfig() : tracerConfig;
  }

  @Override
  public Tracer get(String instrumentationScopeName) {
    return tracerBuilder(instrumentationScopeName).build();
  }

  @Override
  public Tracer get(String instrumentationScopeName, String instrumentationScopeVersion) {
    return tracerBuilder(instrumentationScopeName)
        .setInstrumentationVersion(instrumentationScopeVersion)
        .build();
  }

  @Override
  public TracerBuilder tracerBuilder(@Nullable String instrumentationScopeName) {
    // Per the spec, both null and empty are "invalid" and a default value should be used.
    if (instrumentationScopeName == null || instrumentationScopeName.isEmpty()) {
      logger.fine("Tracer requested without instrumentation scope name.");
      instrumentationScopeName = DEFAULT_TRACER_NAME;
    }
    return new SdkTracerBuilder(tracerSdkComponentRegistry, instrumentationScopeName);
  }

  /** Returns the {@link SpanLimits} that are currently applied to created spans. */
  public SpanLimits getSpanLimits() {
    return sharedState.getSpanLimits();
  }

  /** Returns the configured {@link Sampler}. */
  public Sampler getSampler() {
    return sharedState.getSampler();
  }

  /**
   * Updates the tracer configurator, which computes {@link TracerConfig} for each {@link
   * InstrumentationScopeInfo}.
   *
   * <p>This method is experimental so not public. You may reflectively call it using {@link
   * SdkTracerProviderUtil#setTracerConfigurator(SdkTracerProvider, ScopeConfigurator)}.
   *
   * @see TracerConfig#configuratorBuilder()
   */
  void setTracerConfigurator(ScopeConfigurator<TracerConfig> tracerConfigurator) {
    this.tracerConfigurator = tracerConfigurator;
    this.tracerSdkComponentRegistry
        .getComponents()
        .forEach(
            sdkTracer ->
                sdkTracer.updateTracerConfig(
                    getTracerConfig(sdkTracer.getInstrumentationScopeInfo())));
  }

  /**
   * Attempts to stop all the activity for {@link Tracer}s created by this provider. Calls {@link
   * SpanProcessor#shutdown()} for all registered {@link SpanProcessor}s.
   *
   * <p>The returned {@link CompletableResultCode} will be completed when all the Spans are
   * processed.
   *
   * <p>After this is called, newly created {@code Span}s will be no-ops.
   *
   * <p>After this is called, further attempts at re-using this instance will result in undefined
   * behavior. It should be considered a terminal operation for the SDK.
   *
   * @return a {@link CompletableResultCode} which is completed when all the span processors have
   *     been shut down.
   */
  public CompletableResultCode shutdown() {
    if (sharedState.hasBeenShutdown()) {
      logger.log(Level.INFO, "Calling shutdown() multiple times.");
      return CompletableResultCode.ofSuccess();
    }
    return sharedState.shutdown();
  }

  /**
   * Requests the active span processor to process all span events that have not yet been processed
   * and returns a {@link CompletableResultCode} which is completed when the flush is finished.
   *
   * @see SpanProcessor#forceFlush()
   */
  public CompletableResultCode forceFlush() {
    return sharedState.getActiveSpanProcessor().forceFlush();
  }

  /**
   * Attempts to stop all the activity for {@link Tracer}s created by this provider. Calls {@link
   * SpanProcessor#shutdown()} for all registered {@link SpanProcessor}s.
   *
   * <p>This operation may block until all the Spans are processed. Must be called before turning
   * off the main application to ensure all data are processed and exported.
   *
   * <p>After this is called, newly created {@code Span}s will be no-ops.
   *
   * <p>After this is called, further attempts at re-using this instance will result in undefined
   * behavior. It should be considered a terminal operation for the SDK.
   */
  @Override
  public void close() {
    shutdown().join(10, TimeUnit.SECONDS);
  }

  @Override
  public String toString() {
	// ...
  }
}

스팬 ((Span))

스팬은 어플리케이션이 수행하는 작업 단위를 의미합니다.

span들은 부모-자식 구조로 모여져 하나의 trace를 구성합니다.

OTel에서는 이벤트기반 설계같은 아키텍쳐도 커버하기 위해 부모-자식 관계를 Link관계라고도 표현합니다.

span은 hop마다 시작시간과 종료시간, 예외와 이벤트를 기록하는 역할이기에 추적에서 굉장히 중요한 요소입니다.

아래는 Elastic APM의 Tracing 관련 그림과 제가 작성한 코드인데 이를 보면 span이 어떤 느낌인지 쉽게 알 수 있습니다.

Span span = tracer.spanBuilder("span name")
    .setSpanKind(SpanKind.INTERNAL)               // Span 종류 설정 (Internal 기본값)
    .setAttribute("com.acme.string-key", "value") // 속성 설정 (여러 타입 지원)
    // ... 추가 속성들 설정 ...
    .addLink(linkContext, linkAttributes)         // 링크 추가 (옵션)
    .startSpan();                                 // Span 시작

if (span.isRecording()) {                        // 샘플링되어 기록중인 경우에만
    span.updateName("new span name");            // Span 이름 변경 (필요시)
    span.setAttribute("com.acme.new-attr", "v"); // 동적으로 속성 추가
    span.addLink(otherCtx);                      // 실행 중 링크 추가
    span.addEvent("my-event");                   // 이벤트 추가
    span.addEvent("my-event", someAttributes);   // 속성 포함 이벤트 추가
    span.recordException(new RuntimeException("error")); // 예외 기록 이벤트
    span.setStatus(StatusCode.OK, "done");       // 상태 설정 (OK 또는 ERROR)
}
span.end(); // Span 종료

아래는 실제 코드는 아니고, 이해를 돕기 위해 제가 적어본 Span이 생성되고 종료되는 과정에 대한 코드입니다.

우리는 Tracer의 spanBuilder메소드로 빌더를 만들고 빌더에 각 옵션값들을 넣은뒤 span을 실행시킵니다.

기록이 되어야하는 span이라면 스팬의 값들을 채우게됩니다.

OTel에서 Span의 이름은 낮은 카더널리티를 추구합니다.

만약 많은 정보가 들어가야한다면 Attribute속성 사용을 권장합니다.

그리고 span이 종료되지 않으면 메모리누수와 Trace가 종료되지 않는 문제가 생기기에 반드시 적절하게 종료되어야합니다.

Span-Context

trace에서 span을 식별하는 불변 객체입니다.

어떤 서비스가 다른 서비스에게 요청 할 때 Trace_ID와 Span_ID를 실어 보내면 수신 서비스에서는 이를 SpanContext로 받아들여 새로운 Span의 부모로 취급하게 됩니다.

Trace_ID, Span_ID, 샘플링 여부를 결정하는 TraceFlags, Trace의 상태값들을 저장하는 TraceState가 주된 구성요소이며,

TraceState는 key/value 리스트로 불변객체 특성상 새로운 key가 추가되면 새로운 TraceState를 반환하게 됩니다.

W3C 표준 형식에 맞게 작성해야합니다.

@Immutable
@AutoValue
public abstract class ImmutableSpanContext implements SpanContext {

  public static final SpanContext INVALID =
      createInternal(
          TraceId.getInvalid(),
          SpanId.getInvalid(),
          TraceFlags.getDefault(),
          TraceState.getDefault(),
          /* remote= */ false,
          /* valid= */ false);

  private static AutoValue_ImmutableSpanContext createInternal(
      String traceId,
      String spanId,
      TraceFlags traceFlags,
      TraceState traceState,
      boolean remote,
      boolean valid) {
    return new AutoValue_ImmutableSpanContext(
        traceId, spanId, traceFlags, traceState, remote, valid);
  }

  public static SpanContext create(
      String traceIdHex,
      String spanIdHex,
      TraceFlags traceFlags,
      TraceState traceState,
      boolean remote,
      boolean skipIdValidation) {
    if (skipIdValidation || (SpanId.isValid(spanIdHex) && TraceId.isValid(traceIdHex))) {
      return createInternal(
          traceIdHex, spanIdHex, traceFlags, traceState, remote, /* valid= */ true);
    }
    return createInternal(
        TraceId.getInvalid(),
        SpanId.getInvalid(),
        traceFlags,
        traceState,
        remote,
        /* valid= */ false);
  }

  @Override
  public abstract boolean isValid();
}

SpanBuilder

span은 tracer에서 호출하는 SpanBuilder에서 만들어집니다.

빌더가 생성되면 위에서 살펴본 Tracer관련 설정 파라미터 4개를 받습니다.

아래서 부터는 Span에서 새롭게 등장하는 값들에 대해 알아보겠습니다.

class SdkSpanBuilder implements SpanBuilder {

  private final String spanName;
  private final InstrumentationScopeInfo instrumentationScopeInfo;
  private final TracerSharedState tracerSharedState;
  private final SpanLimits spanLimits;

  @Nullable private Context parent;
  private SpanKind spanKind = SpanKind.INTERNAL;
  @Nullable private AttributesMap attributes;
  @Nullable private List<LinkData> links;
  private int totalNumberOfLinksAdded = 0;
  private long startEpochNanos = 0;

  SdkSpanBuilder(
      String spanName,
      InstrumentationScopeInfo instrumentationScopeInfo,
      TracerSharedState tracerSharedState,
      SpanLimits spanLimits) {
    this.spanName = spanName;
    this.instrumentationScopeInfo = instrumentationScopeInfo;
    this.tracerSharedState = tracerSharedState;
    this.spanLimits = spanLimits;
  }

  ...
 
}

Attributes

Span의 전반적인 정보를 key/value로 보관하는 클래스입니다.

예를들어 HTTP라면 method = GET, status_code = 200 DB쿼리 span이라면 system = mysql, statement = SELECT 1 FROM DUAL 등 우리가 span하면 떠오르는 값들을 저장합니다.

이후 여기에 넣어둔 Attribute 값들을 클라이언트나 샘플러에서 쿼리, 필터링하여 이용하게 됩니다.

class SdkSpanBuilder implements SpanBuilder {
  ...

  private AttributesMap attributes() {
    AttributesMap attributes = this.attributes;
    if (attributes == null) {
      this.attributes =
          AttributesMap.create(
              spanLimits.getMaxNumberOfAttributes(), spanLimits.getMaxAttributeValueLength());
      attributes = this.attributes;
    }
    return attributes;
  }

 ... 
  }
}

Parent , Span-Link와 LinkData

Parent는 Span간의 부모-자식 관계, Span-Link는 일종의 원인-결과관계를 의미합니다.

일반적으로 Parent는 Span이 생성될때 부모의 spanContext를 가져와 세팅하고

Span-Link는 Fan-Out패턴 처럼 부모는 따로 있어도 지금 Span과 관련된 다른 Span들을 참조하고 싶을 때 사용합니다.

OTel에서 Parent는 spanContext 객체를 사용해 표현하고 Link는 LinkData라는 객체를 사용해서 Span-Link를 구현합니다.

LinkData는 SpanContext, Attribute 객체를 가지고 있으며, Span에서 LinkData의 배열을 가짐으로서 1대1이 아닌 1대N관계도 표현할 수 있습니다.

@AutoValue
@Immutable
abstract class ImmutableLinkData implements LinkData {
  private static final Attributes DEFAULT_ATTRIBUTE_COLLECTION = Attributes.empty();
  private static final int DEFAULT_ATTRIBUTE_COUNT = 0;

  static LinkData create(SpanContext spanContext) {
    return new AutoValue_ImmutableLinkData(
        spanContext, DEFAULT_ATTRIBUTE_COLLECTION, DEFAULT_ATTRIBUTE_COUNT);
  }

  static LinkData create(SpanContext spanContext, Attributes attributes) {
    return new AutoValue_ImmutableLinkData(spanContext, attributes, attributes.size());
  }

  static LinkData create(SpanContext spanContext, Attributes attributes, int totalAttributeCount) {
    return new AutoValue_ImmutableLinkData(spanContext, attributes, totalAttributeCount);
  }

  ImmutableLinkData() {}
}

Link 세팅

spanBuilder에서 필요에 따라 SpanContext와 Attribute를 추가 할 수 있습니다.

class SdkSpanBuilder implements SpanBuilder {
  ...
  
  @Override
  public SpanBuilder addLink(SpanContext spanContext) {
    if (spanContext == null || !spanContext.isValid()) {
      return this;
    }
    addLink(LinkData.create(spanContext));
    return this;
  }

  @Override
  public SpanBuilder addLink(SpanContext spanContext, Attributes attributes) {
    if (spanContext == null || !spanContext.isValid()) {
      return this;
    }
    if (attributes == null) {
      attributes = Attributes.empty();
    }
    int totalAttributeCount = attributes.size();
    addLink(
        LinkData.create(
            spanContext,
            AttributeUtil.applyAttributesLimit(
                attributes,
                spanLimits.getMaxNumberOfAttributesPerLink(),
                spanLimits.getMaxAttributeValueLength()),
            totalAttributeCount));
    return this;
  }

  private void addLink(LinkData link) {
    totalNumberOfLinksAdded++;
    if (links == null) {
      links = new ArrayList<>(spanLimits.getMaxNumberOfLinks());
    }

    // don't bother doing anything with any links beyond the max.
    if (links.size() == spanLimits.getMaxNumberOfLinks()) {
      return;
    }

    links.add(link);
  }
 ... 
}

Patent 세팅

tracer에서 span을 만드는 OTel의 예시 코드를 보게되면 Context 객체를 Link에 넣어줍니다.

Span-Link는 부모의 SpanContext를 세팅하지만, Link와 달리 Parent가 필요로 하는 Context는 SpanContext가 아닌 다른 Context, Context.java의 객체입니다.

Context객체는 ContextKey<V> 와 같은 형태로 구현되어있어 다양한 값을 저장 할 수 있는 불변객체이자 저장소입니다.

Span span = tracer.spanBuilder("sb")
    .setParent(Context.current())  // 현재 컨텍스트를 부모로 설정
    .startSpan();

Context.current() 메소드를 살펴보면 ContextStorage라는 저장소에서 Context객체를 꺼내오는걸 확인 할 수 있습니다.

public interface Context {

 ...
 
  /** Return the context associated with the current {@link Scope}. */
  static Context current() {
    Context current = ContextStorage.get().current();
    return current != null ? current : root();
  }
  
  ...
 }

ContextStorage

enum 싱글톤 방식을 사용하여 Context를 자바의 ThreadLocal에 보관하는 Stoarge입니다.

ThreadLocal에 보관하여 Context가 스레드별 전역참조가 가능하도록 합니다.

Context.current()메소드를 사용하면 THREAD_LOCAL_STORAGE에 보관되어 있는 Context객체를 리턴합니다.

Context객체는 주로 span객체 자체를 저장하는데 사용됩니다.

사실 Context 객체, Context.java는 프로젝트에서 interface 파일인데 구현체가 프로젝트에 없는 것 같아서,,

구글링 + 공식문서 + GPT로 찾아봤더니 Context는 immutable이고, 대부분 내부 구현체를 사용한다.

이 정도로만 설명이 되어있어서 흠,, Context구현체에 대해서는 조금 더 찾아봐야 할 것 같습니다 ㅠㅠ

enum ThreadLocalContextStorage implements ContextStorage {
  INSTANCE;

  private static final Logger logger = Logger.getLogger(ThreadLocalContextStorage.class.getName());

  private static final ThreadLocal<Context> THREAD_LOCAL_STORAGE = new ThreadLocal<>();

  @Override
  public Scope attach(Context toAttach) {
    if (toAttach == null) {
      // Null context not allowed so ignore it.
      return NoopScope.INSTANCE;
    }

    Context beforeAttach = current();
    if (toAttach == beforeAttach) {
      return NoopScope.INSTANCE;
    }

    THREAD_LOCAL_STORAGE.set(toAttach);

    return new ScopeImpl(beforeAttach, toAttach);
  }

  private class ScopeImpl implements Scope {
    @Nullable private final Context beforeAttach;
    private final Context toAttach;
    private boolean closed;

    private ScopeImpl(@Nullable Context beforeAttach, Context toAttach) {
      this.beforeAttach = beforeAttach;
      this.toAttach = toAttach;
    }

    @Override
    public void close() {
      if (!closed && current() == toAttach) {
        closed = true;
        THREAD_LOCAL_STORAGE.set(beforeAttach);
      } else {
        logger.log(
            Level.FINE,
            " Trying to close scope which does not represent current context. Ignoring the call.");
      }
    }
  }

  @Override
  @Nullable
  public Context current() {
    return THREAD_LOCAL_STORAGE.get();
  }

  enum NoopScope implements Scope {
    INSTANCE;

    @Override
    public void close() {}
  }
}

Context와 Scope

Scope는 이전 Context를 기억하고 있는 객체입니다.

현재 Span을 Context에 값을 저장하기 위해서는,

Span이 상속받는 인터페이스 중 하나인 ImplicitContextKeyed의 makeCurrent()메소드를 통해 현재 span을 Context에 저장합니다.

여기서 this는 Span입니다.

public interface ImplicitContextKeyed {
  default Scope makeCurrent() {
    return Context.current().with(this).makeCurrent();
  }
}

makeCurrent메소드가 종료되면 Scope가 반환되는데 Scoep가 close되기 전 까지는 지금 Span이 현재 Thread에서 Current상태가 됩니다. close되면 다시 이전 상태의 Context가 Current가 됩니다.

전체적인 흐름으로 보면 이렇습니다.

// 현재 Context를 부모로 설정 하여 span생성
Span span = tracer.spanBuilder("sb")
    .setParent(Context.current()) 
    .startSpan();
    
// 해당 span을 Context에 등록
try (Scope scope = span.makeCurrent()) {
  
  ...
  
} finally {
    span.end(); // 이전 Context로 돌아감
}

하지만 일반적으로 Context들은 ThreadLocalStoarge에 저장되기에 만약 trace가 다른 스레드로 넘어가거나, http요청으로 인해 다른 서비스로 가야할때는 Context를 wrapp해서 전달하는 등 다른 방식이 필요합니다.

Span Status ((스팬 상태))

public enum StatusCode {
  UNSET,
  OK,
  ERROR
}

기본값은 UNSET이고 오류 없음을 의미합니다.

즉 별도로 status가 지정되지 않은 스팬은 오류없음, 즉 성공 스팬으로 취급합니다.

OTel에서도 오류가 있을때만 ERROR로 사용하도록 권고합니다.

span에서 status의 우선순위는 OK, ERROR, UNSET 이며 이미 OK상태가 된 span은 ERROR로 변경해도 무시됩니다.

Span Kind

SpanKind는 5가지 종류 Client, Server, Internal, Producer, Consumer가 있으며 Span이 어디서 실행되는지 구분하는 역할을 합니다.

public enum SpanKind {
  INTERNAL,
  SERVER,
  CLIENT,
  PRODUCER,
  CONSUMER
}

기본 SpanKind는 Internal입니다.

메시징 아키텍쳐에서 사용하기 위한 producer, consumer 타입도 존재합니다.

OTel에서 HTTP모듈, 데이터베이스를 향한 호출은 CLIENT로 처리한다고 합니다.

또 RPC의 양 끝점은 CLIENT, SERVER로 처리한다고 합니다.

대신 SpanKind를 세팅 할 때 한가지 주의 사항이 있는데 하나의 스팬은 하나의 역할만 해야한다는 것 입니다.

즉 아래와 같은 상황이 되면 서버 스팬이 일종의 클라이언트역할까지 하게됩니다.

이런 경우에는 클라이언트 스팬을 따로 만들어 httpCall을 해야합니다.

Span span = tracer.spanBuilder("processRequest")
  .setSpanKind(SpanKind.SERVER)  // 서버 스팬
  .startSpan();

// 이 안에서 외부로 HTTP 요청을 날림
makeHttpCall(); // CLIENT 역할도 동시에 수행하는 코드

span.end();

Span Events

span의 타임라인에서 발생한 시점의 이벤트를 의미합니다.

이벤트는 이름, 타임스탬프, Attribute를 가집니다.

span의 로그정도라고 생각하면 될 것 같습니다.

Span span = tracer.spanBuilder("processOrder")
  .startSpan();

try (Scope scope = span.makeCurrent()) {
  // 이런식으로 로그처럼 사용합니다.
  span.addEvent("order-fetched-from-db");
  processBusinessLogic();
  span.addEvent("order-validated");
  callExternalPaymentService();
  span.addEvent("payment-completed");
} finally {
  span.end();
}

Span Attribute(속성)와 Span Event(이벤트) 의 차이

Span에는 이미 Event와 비슷한 역할을 할 수 있는 Attribute가 있습니다.

두개의 쓰임새는 상황에 따라 조금 달라집니다.

간단하게 이야기하면 특정 타이밍이 중요한 정보라면 Event, 시간과 무관한 정보라면 Attribute에 넣는게 권장됩니다.

어떤 일이 발생한 순간 자체가 중요한 경우 이벤트를 사용하고, 어떤 상태나 결과를 나타내는 정보로서 시점이 중요하지 않다면 속성이 적절합니다.

OTel에서 Attribute와 Event를 구분하는 몇가지 기준이 있습니다.

시점이 의미 있는가? : Y 이벤트 , N : 속성
값이 변하는가? : Y : 이벤트, N : 속성
발생 기록: 이벤트, 단순 설명 : 속성
로그성 : 이벤트, 대표값: 속성
순간: 이벤트, 기간 : 속성

startSpan() ((SdkSpan에서 startSpan()코드도 살펴보기))

이제 span의 속성들을 알아봤으니, span을 시작하는 startSpan 메소드를 살펴보려합니다.

class SdkSpanBuilder implements SpanBuilder {
  ...
  

  @Override
  @SuppressWarnings({"unchecked", "rawtypes"})
  public Span startSpan() {
    Context parentContext = parent == null ? Context.current() : parent;
    Span parentSpan = Span.fromContext(parentContext);
    SpanContext parentSpanContext = parentSpan.getSpanContext();
    String traceId;
    IdGenerator idGenerator = tracerSharedState.getIdGenerator();
    String spanId = idGenerator.generateSpanId();
    if (!parentSpanContext.isValid()) {
      // New root span.
      traceId = idGenerator.generateTraceId();
    } else {
      // New child span.
      traceId = parentSpanContext.getTraceId();
    }
    List<LinkData> currentLinks = links;
    List<LinkData> immutableLinks =
        currentLinks == null ? Collections.emptyList() : Collections.unmodifiableList(currentLinks);
    // Avoid any possibility to modify the links list by adding links to the Builder after the
    // startSpan is called. If that happens all the links will be added in a new list.
    links = null;
    Attributes immutableAttributes = attributes == null ? Attributes.empty() : attributes;
    SamplingResult samplingResult =
        tracerSharedState
            .getSampler()
            .shouldSample(
                parentContext, traceId, spanName, spanKind, immutableAttributes, immutableLinks);
    SamplingDecision samplingDecision = samplingResult.getDecision();

    TraceState samplingResultTraceState =
        samplingResult.getUpdatedTraceState(parentSpanContext.getTraceState());
    SpanContext spanContext =
        ImmutableSpanContext.create(
            traceId,
            spanId,
            isSampled(samplingDecision) ? TraceFlags.getSampled() : TraceFlags.getDefault(),
            samplingResultTraceState,
            /* remote= */ false,
            tracerSharedState.isIdGeneratorSafeToSkipIdValidation());

    if (!isRecording(samplingDecision)) {
      return Span.wrap(spanContext);
    }
    Attributes samplingAttributes = samplingResult.getAttributes();
    if (!samplingAttributes.isEmpty()) {
      samplingAttributes.forEach((key, value) -> attributes().put((AttributeKey) key, value));
    }

    // Avoid any possibility to modify the attributes by adding attributes to the Builder after the
    // startSpan is called. If that happens all the attributes will be added in a new map.
    AttributesMap recordedAttributes = attributes;
    attributes = null;

    return SdkSpan.startSpan(
        spanContext,
        spanName,
        instrumentationScopeInfo,
        spanKind,
        parentSpan,
        parentContext,
        spanLimits,
        tracerSharedState.getActiveSpanProcessor(),
        tracerSharedState.getExceptionAttributesResolver(),
        tracerSharedState.getClock(),
        tracerSharedState.getResource(),
        recordedAttributes,
        currentLinks,
        totalNumberOfLinksAdded,
        startEpochNanos);
  }
  }
  ... 
}

코드가 매우 길지만, 전체적으로 하는일은 아래와 같습니다.

1.부모 Context 확인

부모의 context를 가져와서 세팅합니다. 없다면 Current.Context를 호출해서 Context를 사용합니다.

2. SpanId / TraceId 생성

부모가 있다면 TraceId를 그대로 사용하고 없다면 IdGenerator를 사용해 각 ID를 만듭니다.

3. 샘플링(Sampling)

샘플링 방식을 지정합니다. 샘플링에 대해서는 별도 포스팅으로 다루려고 합니다.

4. SpanContext 생성

SpanContext를 만듭니다.

5.기록 여부 판단 → SdkSpan 생성 or NoopSpan 리턴

recording 여부를 판단합니다. 이 부분도 샘플링에서 같이 다루려고 합니다.

배기지 ((Baggage))

배기지는 컨텍스트에 정의되는 key-value 정보입니다.

Context 인터페이스의 with 메소드로 Baggage를 Context에 저장 할 수 있습니다.

Baggage에 자체 메소드로도 Context에 추가 할 수 있습니다.

사용자ID나 테넌트ID같은 값을 Baggage에 넣어두면, 해당 추적의 Trace를 따라가는 모든 스팬에서도 Baggage를 참조 할 수 있습니다.

  <V> Context with(ContextKey<V> k1, V v1);

Baggage는 http모듈을 통해 외부 서비스로 전달될때는 W3CBaggagePropagator를 이용해 헤더에 값이 들어가서 전파됩니다.

그렇기에 무분별하게 많은 데이터나 민감한 데이터를 넣는 것은 권장되지 않습니다.

baggage: userId=alice,projectId=telemetry

메트릭 ((Metric))

Metric은 기본적으로 Trace와 관계 없이 동작합니다.

메트릭은 주기적으로 수집되는데 특정 조건((timeout 등))에 맞는 메트릭이 수집되면 해당 샘플에 메트릭 값을 추가하여 클라이언트에서 관측 가능하도록 합니다.

APM에서는 Metric은 Exporter를 통해 자체적인 클라이언트에 보낼 수도 있고, 아니면 프로메테우스같은 메트릭 수집기에 전달 할 수도 있습니다.

cpu와 메모리는 비동기 측정 방식을 사용하고 Count와 같은 메트릭은 동기적 측정 방식을 사용합니다.

Meter

사용할 메트릭 계측기들을 만드는 인터페이스입니다.

메트릭 계측기들은 동기, 비동기를 선택해 사용할 수 있습니다.

LongCounter : 카운터, 누적치 계산
LongUpDownCounter : 업다운 카운터, 증가 감소 둘다 있음
DoubleHistogram : 히스토그램, 분포를 보고 싶은 값 기록용
DoubleGauge : 게이지, 현재 값 확인

package io.opentelemetry.api.metrics;
import javax.annotation.concurrent.ThreadSafe;


@ThreadSafe
public interface Meter {

  LongCounterBuilder counterBuilder(String name);

  LongUpDownCounterBuilder upDownCounterBuilder(String name);

  DoubleHistogramBuilder histogramBuilder(String name);

  DoubleGaugeBuilder gaugeBuilder(String name);

  default BatchCallback batchCallback(
      Runnable callback,
      ObservableMeasurement observableMeasurement,
      ObservableMeasurement... additionalMeasurements) {
    return DefaultMeter.getInstance()
        .batchCallback(callback, observableMeasurement, additionalMeasurements);
  }
}

LongCounter

계측기가 여러개 있지만, 그 중 LongCounter의 구현체 하나만 알아보려고 합니다.

class SdkLongCounter extends AbstractInstrument implements LongCounter {

  private final ThrottlingLogger throttlingLogger = new ThrottlingLogger(logger);
  final SdkMeter sdkMeter;
  final WriteableMetricStorage storage;

  SdkLongCounter(
      InstrumentDescriptor descriptor, SdkMeter sdkMeter, WriteableMetricStorage storage) {
    super(descriptor);
    this.sdkMeter = sdkMeter;
    this.storage = storage;
  }
  
  ...
}

WriteableMetricStorage, sdkMeter, InstrumentDescriptor

WriteableMetricStorage는 들어온 메트릭을 Attributes와 Context를 기준으로 모아두는 storage입니다.

동기 비동기 각 상황에 맞게 다른 구현체가 존재하고 있습니다

Context를 파라미터로 받기에 이 값을 통해 추적에 메트릭을 추가 할 수 있습니다.

SdkMeter는 Meter의 구현체로 각 메트릭 수집기들이 등록되며 storage들과 비동기에 사용될 콜백함수도 등록됩니다.

InstrumentDescriptor 메타데이터를 담는 객체입니다.

public interface WriteableMetricStorage {

  /** Records a measurement. */
  void recordLong(long value, Attributes attributes, Context context);

  /** Records a measurement. */
  void recordDouble(double value, Attributes attributes, Context context);

  /**
   * Returns {@code true} if the storage is actively recording measurements, and {@code false}
   * otherwise (i.e. noop / empty metric storage is installed).
   */
  boolean isEnabled();
}

add()

Context와 Attributes를 key로 사용해서 값을 올리는 간단한 메소드입니다.

  ...
  
  @Override
  public void add(long increment, Attributes attributes, Context context) {
    if (increment < 0) {
      throttlingLogger.log(
          Level.WARNING,
          "Counters can only increase. Instrument "
              + getDescriptor().getName()
              + " has recorded a negative value.");
      return;
    }
    storage.recordLong(increment, attributes, context);
  }
  
  ...

SdkLongCounterBuilder

클래스 내부에 static class로 빌더가 존재합니다.

여기서 buildWithCallback 함수를 빌더에 추가하면 비동기 측정 방식으로 사용 할 수도 있습니다.

동기로 측정하면 런타임에 add() 가 호출되고 비동기로 사용하면 수집 주기마다 콜백을 호출하는 방식으로 측정합니다.

   ...

static class SdkLongCounterBuilder implements LongCounterBuilder { 

    @Override
    public LongCounterBuilder setDescription(String description) {
      builder.setDescription(description);
      return this;
    }

    @Override
    public LongCounterBuilder setUnit(String unit) {
      builder.setUnit(unit);
      return this;
    }

    @Override
    public SdkLongCounter build() {
      return builder.buildSynchronousInstrument(SdkLongCounter::new);
    }

    @Override
    public DoubleCounterBuilder ofDoubles() {
      return builder.swapBuilder(SdkDoubleCounter.SdkDoubleCounterBuilder::new);
    }

    @Override
    public ObservableLongCounter buildWithCallback(Consumer<ObservableLongMeasurement> callback) {
      return builder.buildLongAsynchronousInstrument(InstrumentType.OBSERVABLE_COUNTER, callback);
    }

    @Override
    public ObservableLongMeasurement buildObserver() {
      return builder.buildObservableMeasurement(InstrumentType.OBSERVABLE_COUNTER);
    }

    @Override
    public String toString() {
      return builder.toStringHelper(getClass().getSimpleName());
    }
  }

PeriodicMetricReader

지정한 주기마다 Metric을 읽어서 Exporter로 전달합니다.

생성자에서 Expoter와 Interval, Scheduler를 받습니다.

doRun() 메소드를 사용해 메트릭 수집과 추출을 진행합니다.

public final class PeriodicMetricReader implements MetricReader {
  private static final Logger logger = Logger.getLogger(PeriodicMetricReader.class.getName());

  private final MetricExporter exporter;
  private final long intervalNanos;
  private final ScheduledExecutorService scheduler;
  private final Scheduled scheduled;
  private final Object lock = new Object();
  private volatile CollectionRegistration collectionRegistration = CollectionRegistration.noop();

  @Nullable private volatile ScheduledFuture<?> scheduledFuture;

  public static PeriodicMetricReader create(MetricExporter exporter) {
    return builder(exporter).build();
  }

  public static PeriodicMetricReaderBuilder builder(MetricExporter exporter) {
    return new PeriodicMetricReaderBuilder(exporter);
  }

  PeriodicMetricReader(
      MetricExporter exporter, long intervalNanos, ScheduledExecutorService scheduler) {
    this.exporter = exporter;
    this.intervalNanos = intervalNanos;
    this.scheduler = scheduler;
    this.scheduled = new Scheduled();
  }


  ... 
}

Flush, Shutdown, Register

Register는 Provider가 storage에 저장되어 있던 메트릭을 가져와서 Exporter에 넘기는 작업, 즉 Reader의 작업을 실행합니다.

forceFlush 메소드는 지금 시점에 강제로 수집과 추출을 진행합니다.

내부적으로 스케줄러의 doRun을 실행시키고, Exporter.flush()를 실행시켜서 즉시 추출을 진행합니다.

shutdown()은 주기 스케줄을 취소하여 수집을 중지합니다.

스케줄러를 종료 대기 상태로 바꾸고 이후 doRun을 실행시킵니다.

마지막으로 exporter.shutdown()을 호출합니다.

public final class PeriodicMetricReader implements MetricReader {

  ...

  @Override
  public CompletableResultCode forceFlush() {
    CompletableResultCode result = new CompletableResultCode();
    CompletableResultCode doRunResult = scheduled.doRun();
    doRunResult.whenComplete(
        () -> {
          CompletableResultCode flushResult = exporter.flush();
          flushResult.whenComplete(
              () -> {
                if (doRunResult.isSuccess() && flushResult.isSuccess()) {
                  result.succeed();
                } else {
                  result.fail();
                }
              });
        });
    return result;
  }

  @Override
  public CompletableResultCode shutdown() {
    CompletableResultCode result = new CompletableResultCode();
    ScheduledFuture<?> scheduledFuture = this.scheduledFuture;
    if (scheduledFuture != null) {
      scheduledFuture.cancel(false);
    }
    scheduler.shutdown();
    try {
      scheduler.awaitTermination(5, TimeUnit.SECONDS);
      CompletableResultCode flushResult = scheduled.doRun();
      flushResult.join(5, TimeUnit.SECONDS);
    } catch (InterruptedException e) {
      // force a shutdown if the export hasn't finished.
      scheduler.shutdownNow();
      // reset the interrupted status
      Thread.currentThread().interrupt();
    } finally {
      CompletableResultCode shutdownResult = scheduled.shutdown();
      shutdownResult.whenComplete(
          () -> {
            if (!shutdownResult.isSuccess()) {
              result.fail();
            } else {
              result.succeed();
            }
          });
    }
    return result;
  }

  @Override
  public void register(CollectionRegistration collectionRegistration) {
    this.collectionRegistration = collectionRegistration;
    start();
  }
  
  void start() {
    synchronized (lock) {
      if (scheduledFuture != null) {
        return;
      }
      scheduledFuture =
          scheduler.scheduleAtFixedRate(
              scheduled, intervalNanos, intervalNanos, TimeUnit.NANOSECONDS);
    }
  }

  ... 
}

스케줄러

스케줄러는 틱 마다 run()을 호출되고 내부에서 doRun()을 호출합니다.

ScheduledExecutorService 라는 타이머가 있는 스레드 풀을 사용해서

scheduleAtFixedRate만큼의 간격마다 doRun을 실행합니다.

스레드 풀의 스레드 수는 보통 하나를 사용한다고 합니다.

doRun 메소드를 살펴보면

exportAvailable값을 읽어 false면, 즉 아직 export되지 않은 사이클이 있다면, 이번 사이클을 drop합니다.

Reader는 Exporter와 독립적인 관계이고 만약 Exporter가 느려지는 등 이슈가 발생은 Reader에서 알 수 없습니다.

그렇기에 추가적인 부하를 줄 수 있는 상황이라고 판단되면 drop을 진행합니다.

추출이 가능하다면, Storage에서 모든 메트릭을 가져와 Exporter에 전송합니다.

그 결과는 비동기 콜백으로 전달받습니다.

이후 exportAvailable값을 true로 변경합니다.

 private final class Scheduled implements Runnable {
    private final AtomicBoolean exportAvailable = new AtomicBoolean(true);

    private Scheduled() {}

    @Override
    public void run() {
      // Ignore the CompletableResultCode from doRun() in order to keep run() asynchronous
      doRun();
    }

    // Runs a collect + export cycle.
    CompletableResultCode doRun() {
      CompletableResultCode flushResult = new CompletableResultCode();
      if (exportAvailable.compareAndSet(true, false)) {
        try {
          Collection<MetricData> metricData = collectionRegistration.collectAllMetrics();
          if (metricData.isEmpty()) {
            logger.log(Level.FINE, "No metric data to export - skipping export.");
            flushResult.succeed();
            exportAvailable.set(true);
          } else {
            CompletableResultCode result = exporter.export(metricData);
            result.whenComplete(
                () -> {
                  if (!result.isSuccess()) {
                    logger.log(Level.FINE, "Exporter failed");
                  }
                  flushResult.succeed();
                  exportAvailable.set(true);
                });
          }
        } catch (Throwable t) {
          exportAvailable.set(true);
          logger.log(Level.WARNING, "Exporter threw an Exception", t);
          flushResult.fail();
        }
      } else {
        logger.log(Level.FINE, "Exporter busy. Dropping metrics.");
        flushResult.fail();
      }
      return flushResult;
    }

    CompletableResultCode shutdown() {
      return exporter.shutdown();
    }
  }

OtlpHTTPMetricExporter

Reader가 넘긴 데이터를 OTLP포맷으로 변환해 Collector에 전송합니다.

Collector에서 다시 Prometheous, Datadog으로 전송 가능합니다.

MetricReusableDataMarshaler를 사용해 데이터를 OTLP 바이트로 마샬링 후 GrpcExporter를 사용해Http, gRPC등 적절한 채널로 실어 보냅니다.

AggregationTemporalitySelector를 통해 CUMULATIVE, DELTA 방식을 선택합니다.

CUMULATIVE 방식은 총합을 유지하는 방식이고 DELTA 방식은 직전 값과 이전값의 차이만 보내는 방식입니다.

DefaultAggregationSelector로 계측기의 타입별 기본 집계 방식을 선택합니다.

마샬링 시 메모리를 REUSEABLE, 재사용해서 G.C의 부하를 줄이지만 데이터가 덮어 쓰거나

IMMUTABLE, 메모리를 바꾸지 않아 안전하지만 G.C의 부하를 조금 줄지 결정합니다.

@ThreadSafe
public final class OtlpHttpMetricExporter implements MetricExporter {

  private final HttpExporterBuilder<Marshaler> builder;
  private final HttpExporter<Marshaler> delegate;
  // Visible for testing
  final AggregationTemporalitySelector aggregationTemporalitySelector;
  // Visible for testing
  final DefaultAggregationSelector defaultAggregationSelector;
  private final MetricReusableDataMarshaler marshaler;

  OtlpHttpMetricExporter(
      HttpExporterBuilder<Marshaler> builder,
      HttpExporter<Marshaler> delegate,
      AggregationTemporalitySelector aggregationTemporalitySelector,
      DefaultAggregationSelector defaultAggregationSelector,
      MemoryMode memoryMode) {
    this.builder = builder;
    this.delegate = delegate;
    this.aggregationTemporalitySelector = aggregationTemporalitySelector;
    this.defaultAggregationSelector = defaultAggregationSelector;
    this.marshaler = new MetricReusableDataMarshaler(memoryMode, delegate::export);
  }

  /**
   * Returns a new {@link OtlpHttpMetricExporter} using the default values.
   *
   * <p>To load configuration values from environment variables and system properties, use <a
   * href="https://github.com/open-telemetry/opentelemetry-java/tree/main/sdk-extensions/autoconfigure">opentelemetry-sdk-extension-autoconfigure</a>.
   *
   * @return a new {@link OtlpHttpMetricExporter} instance.
   */
  public static OtlpHttpMetricExporter getDefault() {
    return builder().build();
  }

  /**
   * Returns a new builder instance for this exporter.
   *
   * @return a new builder instance for this exporter.
   */
  public static OtlpHttpMetricExporterBuilder builder() {
    return new OtlpHttpMetricExporterBuilder();
  }

  /**
   * Returns a builder with configuration values equal to those for this exporter.
   *
   * <p>IMPORTANT: Be sure to {@link #shutdown()} this instance if it will no longer be used.
   *
   * @since 1.29.0
   */
  public OtlpHttpMetricExporterBuilder toBuilder() {
    return new OtlpHttpMetricExporterBuilder(
        builder.copy(),
        aggregationTemporalitySelector,
        defaultAggregationSelector,
        marshaler.getMemoryMode());
  }

  @Override
  public AggregationTemporality getAggregationTemporality(InstrumentType instrumentType) {
    return aggregationTemporalitySelector.getAggregationTemporality(instrumentType);
  }

  @Override
  public Aggregation getDefaultAggregation(InstrumentType instrumentType) {
    return defaultAggregationSelector.getDefaultAggregation(instrumentType);
  }

  @Override
  public MemoryMode getMemoryMode() {
    return marshaler.getMemoryMode();
  }

  ...
  
}

Exporter의 주요 메소드들

export((Collection<MetricData> metrics))

한 사이클에 있는 배치를 Marshaler가 직렬화하고 즉시 전송합니다.

리턴값은 CompletableResultCode, 비동기로 전달 받습니다.

  @Override
  public CompletableResultCode export(Collection<MetricData> metrics) {
    return marshaler.export(metrics);
  }

flush()

gRPC같은 경우는 내부적으로 버퍼를 둬서 값을 보내는데 위와 같은 경우, 버퍼에 남아있는 데이터를 모두 전송합니다.

HTTP는 버퍼를 사용하지 않기에 즉시 리턴값을 받습니다.

리턴값은 동기로 받습니다.

  @Override
  public CompletableResultCode flush() {
    return CompletableResultCode.ofSuccess();
  }

shutdown()

메모리 누수 등을 방지하기 위해 사용하던 전송 채널, 스레드, 버퍼 등을 닫습니다.

  @Override
  public CompletableResultCode shutdown() {
    return delegate.shutdown();
  }

로그 ((Log))

OTel의 레코드는 일반적으로 생각하는 서비스의 printf 와 같은 문자열 로그가 아니라

구조화된 이벤트 값입니다.

LogRecordBuilder

로그의 값을 담고, emit() 메소드를 통해 로그를 Collector로 전송합니다.

로그에는 로그 발생 시각, 관측 시각, 심각도, 본문 메시지, TraceId, SpanId, Flag, 환경 정보, 이벤트 명과 같은 값들이 들어갑니다.

/** SDK implementation of {@link LogRecordBuilder}. */
class SdkLogRecordBuilder implements LogRecordBuilder {

  protected final LoggerSharedState loggerSharedState;
  protected final LogLimits logLimits;

  protected final InstrumentationScopeInfo instrumentationScopeInfo;
  protected long timestampEpochNanos;
  protected long observedTimestampEpochNanos;
  @Nullable protected Context context;
  protected Severity severity = Severity.UNDEFINED_SEVERITY_NUMBER;
  @Nullable protected String severityText;
  @Nullable protected Value<?> body;
  @Nullable protected String eventName;
  @Nullable private AttributesMap attributes;

  SdkLogRecordBuilder(
      LoggerSharedState loggerSharedState, InstrumentationScopeInfo instrumentationScopeInfo) {
    this.loggerSharedState = loggerSharedState;
    this.logLimits = loggerSharedState.getLogLimits();
    this.instrumentationScopeInfo = instrumentationScopeInfo;
  }

  @Override
  public SdkLogRecordBuilder setEventName(String eventName) {
    this.eventName = eventName;
    return this;
  }

  @Override
  public SdkLogRecordBuilder setTimestamp(long timestamp, TimeUnit unit) {
    this.timestampEpochNanos = unit.toNanos(timestamp);
    return this;
  }

  @Override
  public SdkLogRecordBuilder setTimestamp(Instant instant) {
    this.timestampEpochNanos =
        TimeUnit.SECONDS.toNanos(instant.getEpochSecond()) + instant.getNano();
    return this;
  }

  @Override
  public LogRecordBuilder setObservedTimestamp(long timestamp, TimeUnit unit) {
    this.observedTimestampEpochNanos = unit.toNanos(timestamp);
    return this;
  }

  @Override
  public LogRecordBuilder setObservedTimestamp(Instant instant) {
    this.observedTimestampEpochNanos =
        TimeUnit.SECONDS.toNanos(instant.getEpochSecond()) + instant.getNano();
    return this;
  }

  @Override
  public SdkLogRecordBuilder setContext(Context context) {
    this.context = context;
    return this;
  }

  @Override
  public SdkLogRecordBuilder setSeverity(Severity severity) {
    this.severity = severity;
    return this;
  }

  @Override
  public SdkLogRecordBuilder setSeverityText(String severityText) {
    this.severityText = severityText;
    return this;
  }

  @Override
  public SdkLogRecordBuilder setBody(String body) {
    return setBody(Value.of(body));
  }

  @Override
  public SdkLogRecordBuilder setBody(Value<?> value) {
    this.body = value;
    return this;
  }

  @Override
  public <T> SdkLogRecordBuilder setAttribute(AttributeKey<T> key, @Nullable T value) {
    if (key == null || key.getKey().isEmpty() || value == null) {
      return this;
    }
    if (this.attributes == null) {
      this.attributes =
          AttributesMap.create(
              logLimits.getMaxNumberOfAttributes(), logLimits.getMaxAttributeValueLength());
    }
    this.attributes.put(key, value);
    return this;
  }
  
  ...
 
 }

로그 json 예시

{
  "time_unix_nano": "1723782150000000000",
  "observed_time_unix_nano": "1723782151000000000",
  "severity_number": 17,
  "severity_text": "ERROR",
  "body": {
    "stringValue": "Payment failed"
  },
  "attributes": [
    {
      "key": "order.id",
      "value": { "stringValue": "912345" }
    },
    {
      "key": "user.id",
      "value": { "intValue": "1001" }
    }
  ],
  "trace_id": "4fd0b9b76e4c9f6cb1f4431a6a68e5b2",
  "span_id": "6e0c63257de34c92",
  "flags": 1,
  "resource": {
    "attributes": [
      {
        "key": "service.name",
        "value": { "stringValue": "payment-service" }
      },
      {
        "key": "service.version",
        "value": { "stringValue": "1.2.3" }
      }
    ]
  },
  "instrumentation_scope": {
    "name": "io.opentelemetry.example.PaymentLogger",
    "version": "1.0.0",
    "schemaUrl": "https://opentelemetry.io/schemas/1.18.0"
  },
  "event_name": "order.payment.failed"
}

emit()

만들어진 로그를 Collector로 전송합니다.

지정하지 않은 속성들은 emit()가 실행될 때 자동으로 채우고 LogRecord객체로 만듭니다.

이후 Processor로 넘깁니다.

public void emit() {
  if (loggerSharedState.hasBeenShutdown()) { return; }

  Context ctx = (this.context == null) ? Context.current() : this.context;

  long observed = (this.observedTimestampEpochNanos == 0)
      ? loggerSharedState.getClock().now()
      : this.observedTimestampEpochNanos;

  loggerSharedState.getLogRecordProcessor().onEmit(
      ctx,
      SdkReadWriteLogRecord.create(
          loggerSharedState.getLogLimits(),
          loggerSharedState.getResource(),
          instrumentationScopeInfo,
          timestampEpochNanos,
          observed,
          Span.fromContext(ctx).getSpanContext(), // traceId/spanId 여기서 추출
          severity,
          severityText,
          body,
          attributes,
          eventName));
}

LogRecordProcessor

LogRecord를 emit()을 통해 전달받습니다.

이후 LogRecord들을 Exporter를 통해 Collector나 외부로 전송합니다.

Processor가 SimpleLogRecordProcessor라면 즉시 Exporter로 보내고

BatchLogRecordProcessor라면 큐에 넣고 배치 단위로 Exporter로 전송합니다.

Composite

SimpleLogRecordProcessor, BatchLogRecordProcessor, 사용자 정의 Processor 등

여러개의 LogRecordProcessor를 하나로 묶어주는 역할을 합니다.

아래는 composite을 사용해서 SdkLoggerProvider를 만드는 예시코드입니다.

SdkLoggerProvider loggerProvider =
    SdkLoggerProvider.builder()
        .addLogRecordProcessor(
            LogRecordProcessor.composite(
                SimpleLogRecordProcessor.create(exporterA),
                BatchLogRecordProcessor.builder(exporterB).build()
            )
        )
        .build();

@ThreadSafe
public interface LogRecordProcessor extends Closeable {

  static LogRecordProcessor composite(LogRecordProcessor... processors) {
    return composite(Arrays.asList(processors));
  }

  static LogRecordProcessor composite(Iterable<LogRecordProcessor> processors) {
    List<LogRecordProcessor> processorList = new ArrayList<>();
    for (LogRecordProcessor processor : processors) {
      processorList.add(processor);
    }
    if (processorList.isEmpty()) {
      return NoopLogRecordProcessor.getInstance();
    }
    if (processorList.size() == 1) {
      return processorList.get(0);
    }
    return MultiLogRecordProcessor.create(processorList);
  }

 ...
 
}

onEmit

로그를 Exporter로 전송합니다.

구현체 ((SimpleLogRecordProcessor, BatchLogRecordProcessor))에 따라

바로 Exporter로 전송하거나 큐에 적재하고 나중에 Exporter로 전송합니다.

  ...
  void onEmit(Context context, ReadWriteLogRecord logRecord);
  ...
 }

SimpleLogRecordProcessor

logRecord.toLogRecordData()을 통해 로그 리스트로 변환합니다.

logRecordExporter.export(logs) 추출합니다.

반환된 CompletableResultCode를 pendingExports 콜백을 전달받습니다.

결과적으로 로그 한 줄당 Export가 한번씩 발생합니다.

  @Override
  public void onEmit(Context context, ReadWriteLogRecord logRecord) {
    try {
      List<LogRecordData> logs = Collections.singletonList(logRecord.toLogRecordData());
      CompletableResultCode result;

      synchronized (exporterLock) {
        result = logRecordExporter.export(logs);
      }

      pendingExports.add(result);
      result.whenComplete(
          () -> {
            pendingExports.remove(result);
            if (!result.isSuccess()) {
              logger.log(Level.FINE, "Exporter failed");
            }
          });
    } catch (RuntimeException e) {
      logger.log(Level.WARNING, "Exporter threw an Exception", e);
    }
  }

BatchLogRecordProcessor

SimpleLogRecordProcessor는 들어온 로그를 바로 전송하지만,

BatchLogRecordProcessor는 큐에 넣어두고 일정 크기만큼 모였거나, 특정 주기가 지나면 배치를 통해 전송합니다.

BatchLogRecordProcessor는 고정 길이의 큐를 가지고 있는데,

큐가 가득 차 있는 상태에서 새로운 로그가 emit()되면 drop하게 됩니다.

drop된 로그의 내용은 기록하지는 않지만 drop된 count는 체크합니다.

워커 스레드를 하나 만드는데, 해당 스레드는 백그라운드에서 계속 큐를 바라봅니다.

추가적인 스레드를 사용하기에 emit() 호출은 큐에 넣는 작업만 하게되고 export하는 호출은 만들어진 워커 스레드에서 백그라운드에서 처리합니다.

이렇게 메인스레드와 워커스레드를 분리하기에, 실제 추적 시스템이 존재하는 메인스레드의 부하를 줄일 수 있습니다.

배치도 maxExportBatchSize 라는 크기와 scheduleDelayNanos라는 주기를 기준으로 워커 스레드가 배치의 값들을 진짜 exporter로 전송합니다.

run()

먼저 updateNextExportTime()을 사용해서 scheduleDelayNanos 값을 기준으로 다음 export시간을 계산합니다.

이후 내부 큐에서 로그를 배치 리스트에 담습니다.

이때 maxExportBatchSize 차거나, 지정된 시간, scheduleDelayNanos이 경과하면 내보냅니다.

배치에 모인 로그가 Exporter로 전달되면, 성공 여부에 따라 processedLogsCounter를 기록합니다.

큐가 비어 있으면 다음 export 시간까지 대기하고, 일시적으로 대기((poll))상태로 들어갑니다.

이 때 워커 스레드는 block상태가 되는게 emit()메소드가 실행되며 signal값이 true가 되면 run()이 다시 실행됩니다.

    ...
 
    @Override
    public void run() {
      updateNextExportTime();

      while (continueWork) {
        if (flushRequested.get() != null) {
          flush();
        }
        while (!queue.isEmpty() && batch.size() < maxExportBatchSize) {
          batch.add(queue.poll().toLogRecordData());
        }
        if (batch.size() >= maxExportBatchSize || System.nanoTime() >= nextExportTime) {
          exportCurrentBatch();
          updateNextExportTime();
        }
        if (queue.isEmpty()) {
          try {
            long pollWaitTime = nextExportTime - System.nanoTime();
            if (pollWaitTime > 0) {
              logsNeeded.set(maxExportBatchSize - batch.size());
              signal.poll(pollWaitTime, TimeUnit.NANOSECONDS);
              logsNeeded.set(Integer.MAX_VALUE);
            }
          } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return;
          }
        }
      }
    }
    
    ...

자동 연동(로깅 프레임워크 브리지)

OTel은 OTel Java 에이전트를 사용해, 서비스에서 사용하는 로깅 프레임워크에 자동으로 TraceId, SpanId를 주입해줍니다.

자동연동을 사용하는 방법은 간단한데 -javaagent:opentelemetry-javaagent.jar 와 같은 명령어를 사용합니다.

아니면 xml파일에 추가하는 방법도 존재합니다.

아래는 logback에 OTel의 TraceId, SpanId를 추가하는 예시입니다.

<!-- logback.xml --> 
<configuration> 
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> 
<encoder> <!-- %X{trace_id}, %X{span_id} : MDC 값 --> <pattern>%d %-5level [%thread] trace=%X{trace_id} span=%X{span_id} %logger - %msg%n</pattern> </encoder> </appender>
<root level="INFO"> 
<appender-ref ref="CONSOLE"/> </root> 
</configuration>

OTel은 MDC를 사용해서 TraceId와 SpanId를 저장합니다.

MDC는 SLF4J 계열에서 사용하는 스레드 로컬 기반 key-value 저장소입니다.

예를 들어 지금 스레드에서 MDC.put("userId", "1") 을 저장하면

해당 스레드에서 찍는 모든 로그 패턴에서 {userId}와 같은 방식으로 value를 사용할 수 있게되는데

이를 사용해 OTel 에이전트에서 현재 TraceContext((TraceId, SpanId)) MDC에 자동으로 주입하여 로깅 프레임워크와 연동됩니다.

참조 : https://opentelemetry.io/docs/concepts/signals/traces/

실시간 대용량 데이터에서 사용되는 알고리즘(Reservoir Sampling, HLL, CMS,Bloom Filter)들에 대해 알아보자

겅겅겅 — Fri, 30 May 2025 22:53:51 +0900

스트리밍 시스템에서 모은 많은 데이터들은 시스템 안에서 효율적으로 분석되고 집계되어야합니다.

아무래도 실시간이고 방대한 데이터를 대상으로 하는 만큼 '확률적인 알고리즘'이 많이 사용됩니다.

또 대량의 데이터에 대해서 랜덤 추출, 카더널리티, 빈도, 이전 유입 여부를 확인하는 4개의 알고리즘들에 알아보겠습니다.

무작위 샘플 데이터 추출 - 레저부아 샘플링(Reservior Sampling)

스트림 데이터에서 무작위로 샘플 데이터 추출이 필요할 때가 있습니다.

만약 시스템에서 분당 1,000만 건의 로그가 들어온다고 했을 때, 우리는 모든 로그를 다 메모리에 저장해서 빠르게 분석할수는 없습니다.

이런 상황에서는 랜덤 표본 데이터를 추출해서 원하는 비즈니스 결과를 만들 수 있습니다.

레저부아 샘플링 알고리즘은 스트림 데이터 중 무작위 k개를 동일한 확률로 선택하는 알고리즘 입니다.

즉 전체 데이터를 모두 확인하지 않아도 공평하게 샘플을 확인 할 수 있습니다.

핵심 개념은 이렇습니다.

k개의 데이터를 저장 할 수 있는 저장소 '레저부아'를 가지고 있고, '레저부아'가 가득 찬 상태에서 새로운 데이터가 도착하면 그 데이터를 '풀' 안에 데이터로서 추가, 즉 교채할 것인지, 추가하지 않을 것인지를 결정합니다.

n번째 데이터가 들어오면 "k/n" 확률로 레저부아 풀에 저장 여부를 결정합니다.

k는 풀의 크기, n의 n번째로 들어온 데이터입니다.

위 그림과 같은 상황이라면 15/16확률입니다.

이 확률을 확인하기 위해 0과 1사이 난수를 생성합니다. 만약 n/k 미만이라면 저장소에 저장하고, 저장소의 데이터 중 하나를 랜덤으로 결정해 내보내고, n번째 데이터를 풀에 넣습니다.

레저부아 샘플링을 사용하면 어떤 데이터든 저장소에서 추출될 확률이 1/n이 되는데,

이에 대한 수학적 증명은 이렇습니다.

$k$: Reservoir 크기
$n$: 전체 데이터 수
$A_1, A_2, \dots, A_n$: 입력 데이터
$P_j$: $A_j$가 최종 Reservoir에 남을 확률

j번째 데이터 $A_j$가 저장소에 저장될 확률은 아래와 같습니다.

    $$
    P_{\text{select}}(j) =
    \begin{cases}
    1 & \text{if } j \le k \\
    \frac{k}{j} & \text{if } j > k
    \end{cases}
    $$

이후 데이터는 계속해서 저장소에 들어오게되는데,

$A_j$ 이후에 들어오는 모든 데이터 $j+1, j+2, \dots, n$번째 데이터에 들어와도 $A_j$가 유지될 확률을 구합니다.

$t > j$ 라고 했을 때,

$t$번째 데이터가 들어오면 $\quad \frac{k}{t}$ 확률로 레저부아 저장소 중 하나의 데이터를 교체하고 그 중 $\quad \frac{1}{k}$ 확률로 $A_j$가 선택합니다.

따라서 $A_j$가 $t$에서 교체될 확률은 아래와 같습니다.

$$ \frac{k}{t} \cdot \frac{1}{k} = \frac{1}{t} $$

즉 $A_j$가 에서 살아남을 확률은 아래와 같습니다.
$$
1 - \frac{1}{t}
$$

결국 $A_j$가 이후 모든 단계 $t = j+1$ 부터 $n$까지 저장소에서 교체되지 않고 유지될 확률은 아래와 같이 계산 할 수 있습니다.
$$
P_{\text{keep}}(j) = \prod_{t = j+1}^{n} \left(1 - \frac{1}{t} \right)
$$

최종적으로 따라서 $A_j$가 저장소에 남을 확률은 이렇게 계산 할 수 있고

$$
P_j = P_{\text{select}}(j) \times P_{\text{keep}}(j)
$$

즉, $j > k$일 때

$$
P_j = \frac{k}{j} \cdot \left(1 - \frac{1}{j+1}\right) \cdot \left(1 - \frac{1}{j+2}\right) \cdots \left(1 - \frac{1}{n}\right)
$$

이후 이를 전개하면

$$
P_j = \frac{k}{j} \cdot \frac{j}{j+1} \cdot \frac{j+1}{j+2} \cdots \frac{n-1}{n} = \frac{k}{n}
$$

결국 모든 $j \in \{1, 2, \dots, n\}$ 에 대하여 아래와 같은 공식을 얻을 수 있습니다.

$$
P_j = \frac{k}{n}
$$

카더널리티 구하기 - HyperLogLog(HLL) 알고리즘

스트림 데이터의 카더널리티를 카운트하는 기능은 시스템에서 필요합니다.

거의 실시간 환경에서 수많은 로그를 비교적 정확하게 카운트하려면 확률적 알고리즘을 적용해야하고,

그 중 비트 패턴 기반(Bit-pattern based) 알고리즘 HyperLogLog이 일반적으로 많이 사용되고 있습니다.

HyperLog++알고리즘이라고도 합니다.

적은 메모리를 사용해서 카너럴리티를 빠르게 근사 추정하는 알고리즘입니다.

동작 방식은 이렇습니다.

1. 데이터의 id를 해시함수로 해시 데이터를 만듭니다.

2. 이후 그렇게 나온 해시 데이터를 이진수 값으로 변경하고 정해둔 최하위 몇자리 비트(m)를 10진수 변환하여 인덱스로 사용합니다.

3. 이진수의 앞자리부터 1이 나올때 까지의 0의 수 (leading zeros) 를 새고 그 값을 idx로 하여 레지스터[idx],value 를 대상으로 max연산을 사용해 큰 값을 레지스터에 넣습니다.

위 그림처럼 만약 값이 '0000101100010'이고 m=4로 한다면 인덱스는 '0010', 배열의 인덱스는 '2'가 되고

인덱스에 들어갈 데이터는 0이 연속된 횟수 + 1 즉, (leading zeros) +1, 즉 5가 됩니다.

0으로 시작하지 않는 데이터의 (leading zeros)값은 1이 됩니다.

레지스터에 높은 값들이 들어 있다면 높은 (leading zeros) 값이 나온 데이터라는 의미고, 엄청나게 많은 유니크 값들이 시스템에 들어왔다는 의미가 됩니다.

이후 배열의 조화평균을 구하여 전체 데이터의 카더널리티의 근사치를 알 수 있습니다.

Java의 HashSet으로 10MB의 메모리가 필요한 계산이 있을때, HLL을 사용하면 결과는 정확한 값과 3%의 차이가 있지만 HashSet이 필요로 하는 메모리 크기의 1/2,500인 512바이트만 사용해서 구현할 수 있다고 합니다.

추가로 HLL의 논문에 따르면 1.5kb의 메모리 만으로 2%이내의 상대 오차로 10억개의 구별되는 데이터 개수를 계산 할 수 있다고 합니다.

HLL에서 m값이 커질수록 정밀도는 높아지지만 메모리 사용량도 커집니다.

HLL의 동작원리는 간단하지만 어떻게 "저 방식이 카더널리티를 확인 할 수 있다는거지?"라는 생각이 듭니다.

여기서부터 궁금한 부분 하나씩 해결해보려 합니다.

왜 leading zeros가 높다고 많은 데이터가 들어왔다고 하는걸까?

어떤 수의 (leading-zeros)값이 k가 될 확률은 $10^L$

hash함수를 통해 이진수로 변경된 수를 기준으로 계산하면 $2^L$ 입니다.

HLL의 레지스터에 높은 값들이 들어 있다면 높은 (leading-zeros) 값이 나온 데이터라는 의미고, 즉 엄청나게 많은 유니크 값들이 시스템에 들어왔다는 의미가 됩니다.

이 개념이 HLL알고리즘의 기본적인 뼈대가 되는 Flajolet-Martin Algorithm 이며, HLL알고리즘은 Flajolet-Martin Algorithm의 틀을 가지고 문제점을 개선한 알고리즘입니다.

Flajolet-Martin Algorithm

앞서 잠깐 설명하였듯이 Flajolet-Martin Algorithm은 데이터를 해시하고, 그 결과를 이진값으로 변경한 뒤, 해당 값에서의 (leading-zeros) 값(L)을 읽어 레지스터에 저장하면서 들어온 데이터들의 카더널리티를 판별하는 알고리즘입니다.

이 결과는 $2^L$이 되는데,

이렇게 계산한 $2^L$은 이론상으로는 균등하지만 현실적으로는 데이터 수가 너무 적으면 (L)값이 편향이 생긴다는걸 통계를 통해 발견했습니다.

그래서 보정값 $\phi \approx 0.77351$을 나누어 최종적으로 Flajolet-Martin Algorithm에서 통해 집합의 카더널리티를 구하는 공식은 아래와 같습니다.

$$
\\{Cardinality}_{\text{Flajolet-Martin}} = \frac{2^L}{\phi}
$$

LogLog Algorithm

Flajolet-Martin Algorithm에서 발생하는 이상치 문제를 더 개선한 알고리즘입니다.

HLL과 이제 조금 유사해지는데, 배열에 (L)값을 저장합니다.

이진수의 앞의 몇자리(b)를 잘라 십진수로 변환 후 배열의 인덱스로 사용하고, 나머지 이진수의 값에서 (leading-zeros) 값을 구합니다.

배열의 길이(m)는 앞에서 자르는 수 b을 활용합니다.

$$m = 2^b$$

이후 배열에서 가장 값이 큰 (leading-zeros)들의 평균 (L) 을 낸 다음 (m)을 곱해 카더널리티(k)를 구할 수 있습니다.

$$ \text{Cardinality}_{\text{LogLog}} = m2^L$$

이제 보정상수를 추가해서 최종적인 수식을 만듭니다.

표준 오차는 1.3/√m 입니다.

$$
\text{Cardinality}_{\text{LogLog}} = m \cdot \frac{2^L}{\phi}
$$

SuperLogLog Algorithm

LogLog보다 더 개선된 알고리즘입니다.

배열의 값들의 평균(L)을 내기 전에 가장 큰 (leading-zeros) 값들을 제외하면 더 정확한 카더널리티를 추출 할 수 있음을 발견했습니다.

그래서 SuperLogLog는 평균(L)을 계산할 때 하위 70%까지의 값들 만을 사용해서 평균을 내고 단순한 보정 상수 (0.7)을 곱해서 계산합니다.

$$
\text{Cardinality}_{\text{SuperLogLog}} = 0.7m \cdot \frac{2^L}{\phi}, \quad L = \text{Avg}(\text{Smallest } 70\% \text{ of } L)
$$

이렇게 해서 개선된 SuperLogLog의 표준 오차는 1.05/√m 입니다.

HyperLogLog Algorithm

HLL알고리즘은 SuperLogLog

HLL알고리즘에서는 배열의 데이터들에 대해 조화평균(H)이 사용됩니다.

조화평균은 큰 이상치 (outlier)를 처리하기에 유용합니다.

\[
H = \frac{n}{\displaystyle\sum_{i=1}^{n} \frac{1}{x_i}}
\]

HLL 수식은 배열의 값들의 평균(L)에 대해 조화평균을 구한 값을 사용합니다.

$$
\text{Cardinality}_{\text{HyperLogLog}} = m \cdot \frac{\text{Harmonic Mean}\left(2^{L_i}\right)}{\phi}
$$

m은 12~14의 값으로 권장된다고 하며, 상대 오차 (Relative Error) 는 1.04/√m로 개선되었습니다.

빈도 추정 - Count-Min Sketch (CMS) 알고리즘

스트림 시스템에서는 어떤 범위에서 특정 데이터가 몇번 발생했는지 아는것은 중요합니다.

요구사항을 만족하기 위해 일반적으로는 Count-Min Sketch (CMS) 알고리즘을 사용합니다.

CMS는 적은 메모리를 사용해서 데이터에서 빈도를 측정하는 알고리즘입니다.

HLL처림 확률적 알고리즘이고, 약깐의 오차는 있을 수 있지만 과소추정은 하지않는다는 특징이 있습니다.

CMS 알고리즘을 사용하면 아래와 같은 기능을 구현할 수 있습니다.

포인트 쿼리(Point Query) : 특정 데이터가 얼마나 많이 존재하는지
레인지 쿼리(Range Query): 주어진 범위에서 데이터 빈도를 알고 싶은 경우
이너 프로덕트 쿼리(Inner Product Query) : 두 스케치 알고리즘의 결합을 알고 싶은 경우

동작 과정은 이렇습니다.

들어온 데이터를 각 해시함수에 넣어 정수값을 각각 추출하고 그 정수값을 인덱스로하여 행에 +1을 합니다.

같은 데이터가 들어오면 같은 방식으로 계속해서 배열에 값을 증가시킵니다.

데이터가 들어온 수를 조회할때는 데이터를 추가할때 사용했던 동일한 해시함수(h1,h2,h3,h4)를 사용해서 해당 데이터의 인덱스 값들을 찾습니다.

그렇게 찾은 인덱스를 통해 카운터 안의 값들 중 가장 작은 값을 해당 횟수 데이터가 들어온 근사치로 취급합니다.

즉, 위의 사진과 같은 상황에서는 해당 데이터가 들어온 횟수는 '4'회가 됩니다.

논문에 따르면 배열의 길이가 128인 배열 8개를 사용할 때 상대 오차는 약 1.5%이고 추정치가 정확할 확률은 99.6%라고 합니다.

유입된 데이터 확인 - 블룸 필터 (Bloom Filter)

'이전에 유입된 데이터 인지' 확인하는 요구사항이 있을 수 있습니다.

하지만 수많은 스트림 데이터들에 모두 id를 지정하는건 힘든일이고 id를 이용해서 데이터가 이전에 들어왔었는지, 확인하는것은 더욱 더 어려운 일입니다.

이를 위해 '블룸 필터'를 사용합니다.

볼룸 필터의 특징은 블룸 필터를 통해 들어온 데이터가 '이전에 입수된 적 있다'는 응답이 100% 믿을 수 없다는 것 입니다.

하지만 '이전에 입수된 적 있다'는 응답은 100% 믿을 수 있습니다.

즉 긍정오류(False Positive)는 가능하지만 부정오류(Flase negative)는 불가능하다고 할 수 있습니다.

크롬에서 악성URL을 판별하거나 CDN에서 cache hit여부를 확인하는데도 블룸 필터가 쓰인다고 합니다!

지금 설명하는 아주 기본적인 블룸 필터입니다.

전체적인 동작 방식은 비교적 간단합니다.

먼저 블룸 필터는 길이가 m인 이진수 배열과 k개의 독립적인 해시 함수가 필요합니다.

데이터가 들어오면 각 해시 함수를 통해 해시값을 추출 후,

추출된 해시값을 인덱스로 하여 이진수 배열에 값이 0이면 1을 더하고 이미 1이라면 변경하지 않습니다.

그림처럼 데이터의 해시 값이 2,5,7,9가 나온다면 각 인덱스의 값을 1로 변경합니다.

만약 이후 같은 데이터가 들어오면 동일하게 해시값이 나오게 되고, 그 해시 값들의 인덱스가 모두 1이라면 해당 데이터는 이전에 들어온 적 있다고 판단하고, 아니라면 해당 데이터는 들어온적 없는 데이터라고 판단합니다.

그렇기에 배열의 크기 (m)을 결정하는게 아주 중요합니다.

m은 아래와 같은 공식으로 정할 수 있으며 bit 크기를 의미합니다.

여기서 n은 삽입할 예상 데이터 수, p는 허용 가능한 오차입니다.

$$
m = - \frac{n \cdot \ln p}{(\ln 2)^2}
$$

k는 m을 이용해 구합니다.

$$
k = \frac{m}{n} \cdot \ln 2
$$

만약 1,000,000개 데이터에 대해 1% 허용 오차를 만들고 싶으면 아래와 같이 데이터를 넣습니다.

그리고 그 결과물을 8로 나누어 byte 배열 크기로 만들면 약 1.15가 나옵니다.

이 알고리즘을 통해 아주 작은 리소스로 유입 데이터 여부를 효율적으로 확인 할 수 있습니다.

$$
m = - \frac{1,000,000 \cdot \ln(0.01)}{(\ln 2)^2} \approx 9,585,058 \text{ bits}
$$
$$
\frac{9,585,058}{8 \times 1024 \times 1024} \approx 1.15 \text{ MB}
$$

참조

실시간 데이터 파이프라인 아키텍쳐
https://chengweihu.com/hyperloglog

슬라이딩 윈도우와 텀블링 윈도우에 대해 알아보자

겅겅겅 — Tue, 27 May 2025 23:08:20 +0900

실시간 데이터 처리를 공부하다가 윈도우 기법에 대해서 보게되었습니다,

슬라이딩윈도우는 네트워크나 알고리즘을 공부하다 볼 수 있기에, 비교적 익숙했지만 텀블링 윈도우는 잘 몰랐습니다.

스트림 시스템에서 두 기법에 어떤 차이가 있는지 또 어떻게 쓰이는지 한번 정리해보려 합니다!

타임 스큐 (Time skew)

프로그램을 만들고 운영하다 보면 시간을 다루는일이 참 많습니다.

시스템에 진입한 시점을 말하는 스트림 시간(Stream time) 실제 이벤트가 발생한 이벤트 시간(Event time) 크게 두가지로 볼 수 있을 것 같습니다.

예를들어 스마트 워치에서 피트니스 데이터를 수집 할 때 스트리밍 시스템으로 데이터가 전송된다고 합시다.

여기서 스트림 시간은 피트니스 데이터가 시스템의 어떤 단계에 들어온 시점이고, 이벤트 시간은 워치의 센서가 데이터를 수집한 시점을 의미합니다.

당연히 이 두 숫자는 다를 수 있습니다!

스트림 시간과 이벤트 시간의 차이를 타임 스큐 (Time skew)라고 합니다.

시간 윈도우(Windows of time)

모든 스트림 데이터는 개념상 무한하기에 메모리에 모두 보관할 수는 없습니다.

그래서 시간단위로 잘라서 사용하는데 이렇게 잘려진, 즉 계산을 수행할 수 있도록 잘려진 데이터를 "윈도우(Window)"라고 합니다.

모든 윈도우 기법에는 트리거 조건(Trigger)과 추출 조건(Eviction policies)라는 공통 속성이 있습니다.

트리거는 "데이터를 내보낼 조건을 정하는 규칙(시간, 카운트, 이벤트 기반)"이고 추출 조건은 "윈도우 내부의 데이터를 어떻게 처리할지"에 대한 조건입니다.

슬라이딩 윈도우(Sliding windows)

슬라이딩 윈도우는 윈도우 길이(Window lenght), 슬라이딩 간격(Sliding interval)이라는 이름으로 시간에 기반한 추출조건과 트리거 조건을 사용합니다.

윈도우 길이는 추출조건이고, 슬라이딩 간격은 트리거 조건입니다.

예를들어 위 그림 처럼 윈도우 길이가 2초고 슬라이딩 간격이 1초라면,

1초마다 2초간 들어온 데이터를 담을 수 있는 윈도우를 만들게 됩니다. (데이터 중복 허용가능)

4초간 데이터가 들어왔다면 (0,2), (1,3), (2,4), (3,5)총 4개의 윈도우가 만들어 지고

슬라이딩 간격은 2초이기에 각 윈도우에는 순서대로 (A,B), (B,C), (C,D), (D) 이렇게 데이터가 들어가게 됩니다.

텀블링 윈도우(Tumbling window)

텀블링 윈도우에서 트리거 조건은 윈도우 내부 데이터가 일정 갯수 이상일때, 또는 미리 정해둔 시간(t) 두가지입니다.

그렇기에 텀블링 윈도우는 카운트기반, 시간 기반 2가지가 종류가 있습니다.

추출 조건은 시간일수도 있고 윈도우 갯수일수도 있습니다.

카운트 기반 윈도우

시간(t) 기반 윈도우

다음 포스팅에서는 이렇게 모든 데이터들을 취합하고 분석하는 방법에 대해 다루겠습니다!

스트리밍 데이터 아키텍쳐- 2 저장소, 접근

겅겅겅 — Sun, 18 May 2025 21:01:45 +0900

이전 포스팅에 이어서 스트리밍 시스템에서 사용하는 패턴의 아키텍쳐를 공부해보고자 합니다.

실시간 데이터 파이프라인 아키텍쳐를 보고 공부한 내용을 다룹니다!

스트리밍 데이터 아키텍쳐

스트리밍 아키텍쳐는 크게 6가지 단계로 나눌 수 있습니다.

본 포스팅에서는 수집, 접근 단계에 대해 정리해 보려합니다.

수집

열심히 수집하고 분석한 데이터는 비즈니스에 맞게 적절하게 저장되어야합니다.

장기 스토리지(Long-term storage)에 저장

스트리밍 시스템에서 처리한 데이터를 S3, HDFS 또는 RDBMS와 같은 장기 저장소에 저장하는 경우가 있습니다.

이는 주로 배치 또는 오프라인 접근을 위한 저장입니다.

분석단계에서 매시지를 보낼때 즉시 저장하거나, 배치로 장기 저장소에 저장할수도 있지만,

배치로더를 통해 저장할수도 있습니다.

직접 저장 (Direct writing)

직접 저장은 일반적인 저장방법, 분석단계에서 임시로 메시지를 가지고 있다가 장기 스토리지에 저장하는 배치 방식입니다.

두 방법은 데이터를 빠른 속도로 처리할 경우 데이터의 크기와 속도가 증가하면 대응이 어렵습니다.

그렇기에 배치로 데이터를 가져온뒤 상황에 맞게 처리하는 경우가 많습니다.

간접 저장 (indirect writing)

간접 저장은 직접 저장보다는 다소 복잡하지만 분석 단계와 장기 스토리지의 커플링을 분리하는데 도움이 됩니다.

먼저 분석이 완료된 스트림 데이터를 큐에 저장합니다.

특이한 점은 최종적으로 배치 로더(Batch loader)를 사용해 장기 스토리지에 저장합니다.

간접 저장 방식을 사용하면 메시지 큐 단계는 스트림 데이터 처리 속도와 볼륨에 대응 할 수 있고, 대용량 저장 처리는 배치 로더에 위임해서 성능 발생이 줄어들 수 있습니다.

캐싱 시스템(Caching system)

캐싱 시스템을 사용하면 메모리(DRAM)에 데이터를 저장할 수 있습니다.

Read-through

Read-througt는 캐싱 시스템이 캐시에 없는 데이터를 요청받았을 때 영구 저장소에서 데이터를 읽어옵니다.

Refresh-ahead

Refresh-ahead는 캐시가 만료 또는 삭제되기 전에 최근에 접근했던 데이터로 캐시의 값을 새롭게 변경합니다.

캐시가 만료되면 영구 저장소에 접근해야하는 Read-through전략에 비해 상대적인 성능이점이 있습니다.

스트림 데이터에서 쉬운일은 아니지만 데이터를 새로고침하는 주기를 데이터 업데이트 빈도와 거의 동일하게 설정한다면 캐시는 영속 저장소에 있는 데이터와 거의 동일한 값을 가질수도 있습니다.

Write-through

데이터가 들어오면 캐시와 영속 저장소에 동시에 저장하는 방식입니다.

상대적으로 쓰기 비용이 다른 캐싱시스템에 비해 높다는 단점이 있습니다.

Write-around

write-around에서는 캐싱시스템은 캐시가 영속 저장소를 업데이트합니다.

하지만 이 경우 캐시는 영속 저장소의 기록되거나 변경되는 사항을 알 수는 없습니다.

영속 저장소에 데이터가 업데이트되고 나면 캐시를 업데이트 하기 위한 별도의 프로세스가 실행됩니다.

영속 저장소와 캐시 두곳에 각각 다른 방식으로 데이터를 업데이트 해야한다는 복잡성이 있지만 두 저장소가 연결되어 있지 않을 수 있다는 장점이 있습니다.

Write-back (Write-behind)

write-around에서 캐싱시스템은 캐시가 영속 저장소에 새로운 값을 쓰는 방식입니다.

Write-through와 조금 다르게 케시에 대한 쓰기가 된 후 바로 백그라운드를 통해 영속 저장소에 값을 쓰거나 업데이트합니다.

인메모리 데이터베이스, 인메모리 데이터 그리드, 캐싱 시스템의 차이

캐싱 시스템은 데이터를 빠르게 읽기 위한 임시 저장소로 영속성을 보장하지 않습니다.

반면 IMDB(In-Memory Database), IMDG(In-Memory Data Grids)는 캐싱 시스템과 다르게 영속성을 보장하기 위해 메모리에 우서 저장을 하고 이후 디스크에 저장한다는 차이점이 있습니다.

IMDB와 IMDG는 캐싱 시스템이 발전함에 따라 점점 차이점이 사라지고 있지만 전통적으로 몇가지 차이점이 존재합니다.

IMDG는 분산 아키텍쳐를 사용하여 주로 대용량 데이터를 처리하며, RDBMS에서 익숙한 저장 프로시저와 유사한 동작을 할 수 있고,

IMDB는 메모리에 전체 데이터를 저장해 빠른 처리와 트랜잭션을 제공합니다.

또한 IMDG는 SQL을 통해 API접근을 제공하는 반면, IMDB는 비SQL API를 사용합니다.

데이터 접근

스트리밍 시스템의 마지막 단계입니다.

우리가 여러 단계를 거쳐 데이터를 모으고 가공한 이유는 결국 마지막에 클라이언트에 보여주기위해서 입니다.

아무리 스트리밍 시스템이라도 할지라도 클라이언트와의 통신에서도 반드시 연속적인 통신이 필요한것은 아닙니다.

일반적인 PUSH/PULL 방식뿐만 아니라 데이터 동기화 방식, RMI/RPC, 심플 메시지, 구독/발행 등 다양한 패턴이 가능합니다.

데이터 동기화

데이터 동기화는 클라이언트와 API간 통신이 아닌, API의 데이터베이스 또는 저장소와 동기화하는 방식을 의미합니다.

서버에서 스트리밍 분석을 마치고 데이터의 변경사항을 감지하여 스트리밍 클라이언트에 데이터를 보내는 방식입니다.

이 패턴은 크게 두가지로 나뉘는데

클라이언트가 처음 API로 연결될 때 분석된 데이터를 요청합니다.

이후 데이터들에 대한 변경사항은 클라이언트로 푸시하거나 클라이언트가 데이터를 가져오는 방식으로 진행됩니다.

RMI와 RPC

RMI(Remote Method Invocation)/RPC(Remote Procedure Call)패턴은 API서버에 새로운 데이터가 도착하거나 클라이언트가 필요로 하는 데이터가 도착했을 때, 클라이언트에 있는 메서드를 원격으로 호출하는 방식입니다.

스트리밍 데이터 API서버는 분석 단계에서 처리 완료된 데이터가 저장소에 저장되었는지 모니터링하고, 저장소의 데이터가 변경되면 원격 메소드를 호출하여 클라이언트에 변경된 데이터를 전송합니다.

하지만 RMI와 고전적인 RPC 방식은 현재는 잘 사용되지 않으며, 구글의 gRPC가 상황에 따라 주로 사용됩니다.

심플 메시징

클라이언트는 스트리밍API 서버의 가장 최근에 데이터를 요청하고 응답으로 가장 최신의 데이터만을 전달하는 방식입니다.

그렇기에 심플 메시징 방식은 'xxxx보다 최신인 데이터를 요청', 'xxxx기간 동안 변경되지 않은 데이터의 요청'과 같은 명령에는 적합한 방식이 아닙니다.

하지만 클라이언트는 계속해서 신규 데이터를 요청하기에 통신량이 많을 수 있습니다

발행 - 구독 패턴

클라이언트가 특정 채널을 구독하고, API는 데이터가 변경될 때 해당 채널을 구독하고 있는 모든 클라이언트에 메시지를 보내는 방식입니다.

스트리밍 시스템에서 가장 널리 사용되는 방식입니다.

클라이언트에 데이터 전달 프로토콜 방식

스트리밍 API에서는 웹훅, 롱풀링, SSE, 웹소켓과 같은 통신 패턴이 사용됩니다.

SSE는 롱풀링의 단점을 극복하고 나온 방식이기에 웹훅, SSE, 웹소켓에 대해 알아보겠습니다.

웹훅(Webhook)

새로운 데이터가 도착하거나 기타 조건이 충족되면 클라이언트를 HTTP엔드포인트로 호출하는 방식으로 사용됩니다.

호출은 HTTP의 POST를 통해 실행됩니다.

최초 클라이언트가 HTTP POST를 사용하여 콜백을 등록하기 위한 요청을 보냅니다.

콜백이 저장되면 이후 이벤트 조건이 충족되면 콜백을 호출합니다.

결제 완료 알림이나, 깃 커밋 푸시시 슬랙이나 CI로 전달하는 깃허브 웹훅과 같은 방식에서 사용됩니다.

SSE (Server Sent Events)

W3C의 권장 서버 -> 브라우저간 단방향 프로토콜입니다.

클라이언트가 먼저 스트리밍 API 연결 후 맺어진 네트워크를 통해 모든 이벤트가 지속적으로 전송됩니다.

조회만을 위한 간단한 실시간 서비스라거나 서버 로그 스트리밍에서 주로 사용됩니다.

비연결 푸시 (Connection push)

SSE는 클라이언트와의 지속적인 연결이 필수적입니다.

그렇기에 모바일 디바이스와 같은 상황에서는 배터리 소모 이슈, 네트워크 측면에서는 리소스 이슈가 있습니다.

하지만 비연결 푸시 방식을 사용하면 SSE의 단점인 지속적인 연결을 해결할 수 있습니다.

푸시 프록시 서버를 사용하여 어플리케이션이 꺼져있어도 메시지를 보낼 수 있습니다.

먼저 클라이언트(여기서는 모바일 디바이스)가 스트리밍 API와 연결을 하고 이벤트를 수신합니다.

이후 클라이언트에서 지정한 시간, 조건이 지나면 디바이스는 절전모드로 전환됩니다.

이 때 푸시 프록시 서버와 연결 상태를 유지하기 위한 통신(마지막으로 받은 이벤트의ID를 전송)을 시작합니다.

푸시 프록시 서버가 이벤트를 수신하면 모바일 푸시 시스템(FCM,APNs)을 사용해서 클라이언트로 이벤트를 전송합니다.

클라이언트에서는 메시지를 처리하기 위해 절전모드를 일시 해제하고 다시 절전모드에 들어갑니다.

특정 시점이 되면 푸시 프록시가 스트리밍API와 연결을 끊고 연결이 종료됩니다.

웹소켓

웹소켓은 스트리밍 시스템에서 가장 대중적이고 효율적인 방법중 하나입니다.

초기 핸드 쉐이크에서는 HTTP를 사용하고 이후 통신은 TCP를 사용합니다.

아래 그림에서 "저속 (Slow down)"으로 표시딘 부분은 통신이 양방향으로 이루어지고 클라이언트가 종류와 전송 시점을 결정하여 서버로 언제든지 메시지를 보낼 수 있다는 의미입니다.

클라이언트가 데이터를 빨리 읽지 못할 경우, 서버에게 요청해서 데이터 전송 속도를 낮출 수 있습니다.

연결을 올바르게 종료하려면 종료 헨드쉐이크를 사용해서 서로 TCP 통신을 끊습니다.

기본적인 스트리밍 시스템의 구조에 대해서 알아보았는데,

아무래도 실무적인 부분과 직접 연관짓기에는 조금 부족한 글인것 같습니다..

조만간 직접 만들어 보고 부족한 부분들을 더 채워넣으면 좋겠다는 생각이 듭니다!

다음 포스팅에서는 스트리밍 시스템에서 사용하는 알고리즘을 알아보고자 합니다.

스트리밍 데이터 아키텍쳐-1 수집 단계, 큐, 분석 단계

겅겅겅 — Sun, 4 May 2025 00:20:10 +0900

일반적인 스트리밍 시스템에서 사용하는 패턴의 아키텍쳐를 공부해보고자 합니다.

실시간 데이터 파이프라인 아키텍쳐를 보고 공부한 내용을 다룹니다!

스트리밍 데이터 아키텍쳐

스트리밍 아키텍쳐는 크게 6가지 단계로 나눌 수 있습니다.

수집 단계

클라이언트에서 생성되는 데이터가 시스템에 들어오는 스트리밍 시스템의 첫 단계입니다.

수집을 위한 몇가지 패턴들이 존재하며 이중 하나를 선택하여 사용합니다.

요청/응답 패턴
발행/구독 패턴
단방향 패턴
요청/확인응답 패턴
스트림 패턴

요청/응답 패턴 ((Request/response pattern))

클라이언트가 서버로 요청을 보내면 서버가 응답하는 웹 브라우저에서 자주 사용되는 일반적인 패턴입니다.

반비동기(Half-async), 비동기(Full-async) 방식으로 요청/응답 패턴을 구현할 수 있습니다.

요청/응답 확인 패턴 ((Request/acknowledge pattern))

요청/응답 패턴과 유사하게 통신을 해야하지만 서버에서 반환하는 응답이 클라이언트에는 필요하지 않는 경우에 사용됩니다.

확인응답으로 전달되는 데이터는 현재 요청 상태를 확인하는 용도의 데이터나 다음 요청에 사용할 데이터를 내려주기도 합니다.

예를들어 고객이 접속한 모든 페이지에 대한 정보와 클릭한 링크에 대한 데이터를 수집해야한다고 한다면,

첫 요청이 들어올때 서버는 다음요청에서 고객이 사용할 고유의 식별자를 넘겨줍니다.

이후 식별자는 고객이 방문하는 모든 페이지들을 추적하는데 사용됩니다.

이러한 정보들을 토대로 고객의 구매성향을 분석 할수도 있습니다.

발행/구독 패턴 ((Publish/subscribe pattern))

일반적인 메시지 기반 데이터 시스템에서 자주 사용되는 패턴입니다.

프로듀서가 브로커에세 메시지를 전달하는 것으로 시작됩니다.

메시지는 토픽(Topic)으로 전송되며, 전송 이후 토픽을 구독하는 모든 컨슈머(Consumer)에게 메시지가 전송됩니다.

브로커는 토픽을 관리하는 논리적인 클러스터입니다.

단방형 패턴 ((One-way pattern))

단방향 패턴은 요청하는 시스템이 응답이 필요하지 않을 때 사용합니다.

'발사 후 망각' (Fire and forgot) 패턴과 유사합니다.

요청/응답 확인 패턴과 유사하지만 서버가 응답을 보내지 않아도 됩니다.

일부 데이터의 유실을 허용하고 통신의 단순화, 리소스 감소, 전송 속도를 보장해야하는 환경에서는 단방향 패턴이 적합합니다.

스트림 패턴 ((Stream pattern))

스트림 패턴은 앞서 다루었던 패턴들과 조금 다릅니다.

보통 클라이언트가 서버로부터 응답을 받거나 받지않으며 클라이언트에서 출발하는 한번 한번의 요청이 주를 이루었다면

스트림 패턴에서는 한번에 데이터를 모두 전달하지 않고 지속적으로 데이터를 응답으로 보내는 특징을 가집니다.

서버는 원천 스트림 데이터와 연결하여 지속적으로 원천 스트림 데이터를 가져갈 수 있습니다.

서버의 요청을 보내기 위해 클라이언트를 개발할 필요 없이, 스트림 패턴을 활용하면 스트림 데이터가 존재하는 부분에 연동하여 데이터를 지속적으로 처리 할 수 있습니다.

스트림 패턴((Stream pattern))의 수평확장

스트림 패턴에서는 지속적인 연결과 상태 유지를 전제로 하기 때문에, 일반적인 수평 확장처럼 단순히 인스턴스를 늘리는 방식은 비효율적일 수 있습니다.

이를 해결하기 위한 방법 중 하나는 버퍼링((Buffering layer))를 사용하는 방법입니다.

버퍼링 계층과 수집서버는 서로 상호 배타적((Mutually execlusice))이지 않으며 스트림 데이터의 유입량이나 크기에 따라 둘 다 적절한 상태로(크기, 갯수) 설계되어야 합니다.

내결함성 설계

모든 소프트웨어는 장애에 대한 설계가 필요합니다.

수집 단계에서는 원천 데이터가 수집 서버로 들어오는 시점, 수집 서버에서 큐로 넘어가는 시점 크게 두곳에서 장애가 발생 할 수 있습니다.

내결함성을 달성하기 위해 체크 포인팅((Checkpointing))과 로깅((logging)) 방식이 사용됩니다.

체크 포인팅((Checkpointing))

체크포인팅의 두가지 키워드는 전역 스냅샷(Global snapshot)과 데이터 유실 가능성(Potential for data loss)입니다.

전역 스냅샷(Global snapshot) : 시스템 전역 상태에 대한 스냅샷을 정기적으로 특정 저장소에 저장합니다.
데이터 유실 가능성(Potential for data loss) : 가장 최근에 기록된 전역 상태까지 복구할 수 있도록 합니다. 이후 시점에 처리되고 생성된 메시지는 유실됩니다.

여기서 복원하는 전역상태는 영속성 저장소(Persistent store)에 저장되어있는 상태를 의미합니다.

일반적인 스트리밍 시스템에서 체크포인팅을 사용하는건 조금 어려움이 있습니다.

스트리밍 시스템은 단계별로 데이터가 이동할 때 마다 모든 시점에 대한 스냅샷 데이터를 일관성있게 유지하는것이 어렵고, 각 단계별로 각각 다양한 기술(스택, 프레임워크 등)들로 구성되어 있기 때문입니다.

로깅 ((Logging))

로깅의 기본적인 아이디어는 '메세지를 제처리 할 수 있다면, 시스템은 전역 스냅샷이 없어도 전 구간에서 일관돤 상태에 도달할 수 있다' 입니다.

즉 로깅방식은 시스템을 구성하는 각 단계가 수신한 모든 메시지를 자체적으로 저장하고 장애가 발생하면 저장된 메시지를 재처리하는 방식입니다.

로깅은 RBML((Receiver-Based Message Logging))과 SBML((Sender-Based Message Logging)) 이 두 방식을 합친 HML(Hybrid Message Logging)이 있습니다. ((HML방식은 RBML방식과 SBML방식의 장점만을 합친 방식입니다.))

RBML은 서버가 데이터를 받을 떄, SBML방식은 데이터를 다음 단계로 보낼 때 데이터의 유실을 방지합니다.

로깅방식 ((RMBL, SBML, HML))

RBML((Receiver-Based Message Logging))

RBML은 전달받은 모든 메시지를 저장소에 저장한 이후에 로직을 처리하는 방식입니다.

이 방식은 소프트웨어에 장애가 발생하더라도 이미 저장되어 있던 데이터를 바탕으로 재처리하여 복구 할 수 있습니다.

다만 저장소의 성능이 따라주지 않으면 시스템의 성능에 큰 영향이 있을 수 있습니다.

장애가 발생하면 수집서버는 프로듀서로 부터 더 이상 메시지를 받지 않습니다.

RBML로거는 메시지가 저장된 저장소에서 처리되지 않는 메시지를 읽고 기존 순서대로 로직을 처리합니다.

중지되었던 모든 메시지가 처리되고 나면 수집서버가 복구된 것으로 간주합니다.

1. 데이터 프로듀서 (클라이언트 등)가 메시지를 전송합니다.

2. 데이터 프로듀서가 보낸 메시지는 RBML로거 서버로 전달되고 저장소로 전달합니다.

3. 메시지가 저장소에 저장됩니다.

4. 비즈니스 로직 수행

5. 수집단계의 다음 단계인 큐 단계로 메시지가 전달됩니다.

SBML((Sender-Based Message Logging))

SBML은 서버가 처리한 데이터를 다음 단계로 보내기 전 수집서버에서 외부로 나가는 모든 메시지를 로깅합니다.

RBML과 SBML의 중요한 차이점은 RMBL은 메시지를 처리하기 전에 저장하고 SMBL은 다음단계로 넘어가기 전에 처리합니다.

즉 RBML은 원천데이터이고 SBML은 로직을 통해 한번 가공된 데이터입니다.

장애가 발생하면 수집서버는 RBML과 동일하게 프로듀서로 부터 데이터를 받지 않게됩니다.

SBML에서 메시지가 다음단계로 잘 넘어갔는지 확인하려면?

SBML에서 넘어간 데이터가 잘 처리되었는지 알 수 있는 방식은 메시지 큐 단계에서 메시지를 정상적으로 받았다고 수집 단계에 확인 응답을 보내주는 것입니다.

메시지 큐에 정상적으로 전달되었으면 수집단계에서 이상 수집 단계에서 데이터를 보관할 필요가 없으니 저장소에서 삭제하는 등 비즈니스에 따라 해당 메시지에 대해 전송완료 표시를 해두면 됩니다.

만약 메시지 큐에서 전달응답을 보낼 수 없는 경우에는 6,7 단계를 생략하고 수집 단계에 영속 저장소에서 삭제하는 방식을 사용합니다.

HML((Hybrid Message Logging))

HML은 RBML과 SBML의 장점을 최대한 활용하도록 설계되었습니다.

만약 3가지 로깅구조에서 하나만 선택해야한다면 HML을 선택하는게 일반적인 정답입니다.

HML에서는 메시지를 저장할 때 저장을 비동기로 처리한다는 특징이 있습니다.

메시지 큐 단계

소프트웨어 설게에서는 서버들간의 디커플링이 중요합니다.

서버들간의 통신 및 디커플링을 위해 '메시지 큐'를 많이 사용합니다.

'메시지 큐'를 통해 수집단계와 분석단계의 커플링을 끊고 통신을 할 수 있습니다.

프로듀서, 브로커, 컨슈머

메시지 큐는 프로듀서, 브로커, 컨슈머로 구성되어 있습니다.

브로커는 실제 메시지 큐들을 관리하는 추상화된 논리적 클러스터입니다.

메시지 큐 단계에서는 위 3가지 구성요소들끼리 통신합니다.

메시지 큐는 아래와 같은 순서대로 동작합니다.

프로듀서는 브로커에세 메시지를 보낸다.
브로커는 큐에 메시지를 넣는다.
컨슈머는 브로커로부터 메시지를 읽는다.

메시지의 지속적저장 ((Durable Messaging))

만약 수집단계에서 대량의 데이터가 들어온다면, 메시지 큐 단계에서는 데이터의 유실없이 적절하게 처리할 수 있는 방법이 필요합니다.

메시지의 지속적 저장((Durable Messaging))은 컨슈머가 데이터를 천천히 읽어가거나 일시적으로 컨슈머의 연결이 끊기더라도 다시 데이터를 읽어갈 수 있는 방법입니다.

또한 메시지의 지속적 저장이 가능한 큐를 Durable Queue라고 합니다.

만약 컨슈머가 장애나 성능등의 이유로 메시지를 읽지 못하면 큐에 쌓여버린 메시지들은 소멸되거나 유실될 수 있습니다.

하지만 Durable Queue는 메시지를 지속적 저장소((파일시스템. JDBC, 전용 시스템))등에 백업해두기에 메시지의 소실을 예방 할 수 있습니다.

RabbitMQ는 Queue 생성 시 durable=true, 메시지 deliveryMode=2 설정해야 디스크 저장이 되고,

Kafka는 기본적으로 모든 메시지 로그는 디스크 저장됩니다.

메시지의 전달 시맨틱 ((Messaging Delivery Semantics))

메시지가 컨슈머에게 어떻게 전달되고, 몇 번이나, 어떤 조건에서 도착해야 하는지에 대한 규칙입니다.

1. 최대 한 번 ((At-most-once))

일부 메시지가 유실될 수 잇습니다. 유실된 메시지는 컨슈머에 도달하지 못합니다.

2. 적어도 한 번 ((At-least-once))

메시지가 절대 유실되지 않습니다. 그러나 컨슈머에서 동일 메시지를 두번 이상 처리할 수 있다.

3. 정확히 한 번 ((Exactly-once))

모든 메시지는 절대로 유실되지 않으며, 컨슈머는 반드시 한 번만 메시지를 처리합니다.

일반적으로는 '정확히 한 번'이 당연히 가장 이상적이고 완벽한 방법입니다.

그렇기에 '정확히 한 번'을 구현하는건 어려운 일입니다.

그 이유는 사실상 각 큐의 요소간 모든 통신은 유실위험이 존재하며,

'정확히 한 번'을 구현하려면 큐의 각 요소에서 메시지 소실 및 재전송이 발생 할 수 있는 상황들을 알고 고려해야합니다.

(('정확히 한 번'은 매번 정답이 아니며 비즈니스에 따라 적절한 시맨틱을 선택해야합니다. 실제로 카프카도 0.11.0.0 버전 이전까지는 정확히 한 번 기능을 제공하지 않았습니다.))

'정확히 한 번'을 위해 고려해야하는 부분들

'정확히 한 번'을 구현하기 위해서는 각 요소간에서 발생할 수 있는 문제들을 미리 알아두어야합니다.

프로듀서에서 위험요소

프로듀서 내부에서 메시지가 생성된 후 네트워크 통신을 통해 브로커로 보내기 직전 프로듀서 장애 발생 시 메시지 유실가능
프로듀서가 정상적으로 메시지를 보냈지만 브로커에서 메시지를 전달받았다는 응답을 받지 못하면 동일한 메시지가 브로커로 한번 더 전달 될 수 있음

프로듀서와 브로커 간 네트워크 통신간 위험요소

프로듀서와 브로커 간 네트워크 사이 통신에 이슈가 발생하면 프로듀서는 브로커로 메시지를 보내지 못함
브로커가 메시지를 저장했지만 저장 완료되었다는 응답을 프로듀서에 보내지 못하면 동일한 메시지가 두 번 전달될 수 있음

브로커에서의 위험요소

브로커에 장애가 발생하면 저장소에 저장하기 직전에 메모리가 가지고 있던 메시지가 유실 될 수 있음
프로듀서로 메시지를 전달받았다고 응답을 보내기 전에 장애가 발생하면 프로듀서는 동일한 메시지를 두 번 보낼 수 있음

메시지 큐에서의 위험요소

저장소에 장애가 발생하면 디스크에 저장된 메시지 중 일부가 유실될 수 있습니다.

컨슈머와 브로커 간 네트워크 통신간 위험요소

컨슈머와 브로커 간 네트워크 이슈 발생 시, 브로커가 컨슈머로 메시지를 보낼 수 없음
컨슈머가 처리한 마지막 메시지 정보가 브로커에 전달되지 않으면 동일한 메시지가 두 번 이상 컨슈머에서 처리될 수 있습니다.

컨슈머에서의 위험요소

브로커로부터 메시지를 전달 받은 후, 데이터를 처리하기 전에 장애가 생기거나 커밋정보를 브로커로 전달하지 못하면 동일한 메시지를 두번 이상 처리할수도 있습니다.
여러 컨슈머가 동일한 메시지를 여러 번 읽는 경우도 발생할 수 있습니다.

결론적으로 프로듀서와 컨슈머에서 정확히 한 번을 지원하기 위해서는 메시지를 두번 보내지 않아야하고, 마지막으로 처리한 메시지의 메티데이터를 저장해야합니다.

아파치 카프카, 아파치 Active MQ의 메시징 시스템에서도 이렇게 메타데이터를 이용해 정확히 한 번 처리를 구현합니다.

메시지를 두 번 보내지 말 것

정확히 한 번 처리를 위해 반드시 구현되어야하는 기능입니다.

프로듀서가 브로커로 메시지를 보낼 때 각 메시지들을 추적해야합니다.

만약 프로듀서와 브로커 사이 응답이 유실되거나 연결이 끊기면, 프로듀서가 이전에 보낸 데이터를 브로커가 정상적으로 받았는지 브로커로 요청하고 확인응답((Acknowledgement))를 받습니다.

예를들어 프로듀서가 브로커로 응답을 보내고 브로커는 응답을 받은 직후 네트워크가 끊겨 프로듀서가 브로커의 응답을 받지 못하면, 프로듀서는 다시 동일한 메시지를 보내게 됩니다.

이때 프로듀서가 메시지에 고유 ID((메타데이터))을 붙여 보내게 되면,

브로커는 고유 ID를 통해 프로듀서가 이전과 동일한 메시지를 보냈는지, 즉 중복된 메시지를 보냈는지 판단하여 프로듀서가 메시지를 두 번 보내지 않도록 합니다.

마지막으로 처리한 메시지의 메타데이터 저장

저장해야하는 메타데이터의 종류는 메시징 시스템에 따라 다릅니다.

JMS 기반 시스템을 사용할 경우 JMS의 메시지ID를 사용하면 됩니다.

아파치 카프카를 사용할때는 메시지의 오프셋을 저장합니다.

결국 중복해서 처리하지 않기 위한 메시지 구분을 위한 메타데이터를 저장하면 됩니다.

또한 메타데이터는 장애복구 시 컨슈머가 어디서부터 메시지를 읽을지 기억하는 기준이 되기도 합니다.

메시지 큐 단계에서의 장애처리

장애처리는 어떤 단계에서든 중요한 부분입니다.

큐에서는 크게 브로커, 브로커간 통신, 저장소에서의 장애가 주된 위험지점이 될 것 같습니다.

브로커에서 장애 위험요소 및 처리방안

브로커가 내부 저장소에 저장하기 직전에 장애가 발생 할 수 있습니다.

이 때 메모리에 가지고 있던 메시지를 처리하는 방법은 3가지 정도가 있을 것 같습니다.

프로듀서와 브로커간 확인응답(Acknowledgment)를 활용(메시지 전달 시멘틱 방법과 동일!)
큐가 별도의 브로커로 메시지를 복제하여 백업
메시지를 저장하는 메모리의 사용률을 줄이고 저장소에 저장하도록 변경 (속도저하 가능성 있음)

브로커 통신간 장애 위험요소 및 처리방안

큐 소프트웨어들은 최소 1개 이상의 브로커에 메시지를 저장하여 안전하게 저장되도록하며,

브로커간 네트워크의 문제가 발생했을때도 복구 이후 각 브로커에 저장된 메시지를 동기화 하는 기능이 존재합니다.

큐를 직접 구현하는게 아니라면 '브로커 통신간 네트워크 장애 발생 시 또는 복구 시' 큐 소프트웨어가 어떻게 동작하는지 확인한 다음,

비즈니스에 맞는 몇가지 기준을 만들고 그에 적합한 큐 소프트웨어를 선택해야합니다.

저장소에서 장애 위험요소 및 처리방안

저장소에서 유실된 데이터에 대한 백업을 만들어 두어야합니다.

분석 단계 ((스트림 프로세싱 아키텍쳐))

수집과 큐 단계를 거쳐 모인 데이터들이 모여 어떠한 비즈니스적 가치를 만들어내는 단계입니다.

여러 알고리즘들이 존재하기만 분석 알고리즘을 따로 포스팅하고 분석단계에서 사용되는 스트림 프로세싱 아키텍쳐를 위주로 다루어 보려고합니다.

전통적인 DBMS와 스트리밍 시스템의 데이터 접근에 대한 차이

아래 그림은 전통적인 DBMS와 스트리밍 시스템의 데이터 접근에 대한 차이입니다.

스트리밍 시스템에서는 사용자가 쿼리를 한번 등록하면 결과값은 지속적으로 클라이언트에게 푸시됩니다.

스트리밍 분석은 사용자 행동 추적, 실시간 분석 등 여러 비즈니스 요구사항을 풀 수 있습니다.

인플라이트 데이터(In-flight Data)와 연속 쿼리(Continuous quries)

인플라이트 데이터는 시스템의 파이프라인 속에서 이동 중이거나 처리 중인 데이터를 의미합니다.

시스템에 따라 인플라이트 데이터는 디스크에 저장되거나 사용 후 소멸되기도 합니다.

연속쿼리는 시스템에서 실시간으로 들어오는 데이터에 대해 즉시 실행되고, 그 실시간 결과를 지속적으로 반환하는 쿼리를 의미합니다.

즉 데이터가 들어올 때 마다 자동으로 실행되는 쿼리입니다.

스트리밍 시스템을 사용하는 사용자 입장에서 생각해보면 스트리밍 시스템의 쿼리(연속쿼리)를 실행하면 데이터가 지속적으로 들어오게 됩니다. 이러한 쿼리들을 조합한 일련의 형태 모델을 '연속 쿼리 모델'((Continuous query model))이라 합니다.

이렇게 쿼리로 추출된 데이터는 다음 단계로 PUSH됩니다.

분산 스트림 프로세싱 아키텍쳐

분석 단계는 많은 리소스를 필요로 하는 단계이기에 여러 서버를 사용하는 분산 시스템이 동반된 아키텍쳐를 도입해야합니다.

분석 단계에서 많이 사용되는 스트림 프로세싱 소프트웨어는 아파치 스파크, 스톰, 플링크 등이 있습니다.

각 소프트웨어마다 명칭과 아키텍쳐가 조금씩은 다르지만,

인기있는 스트리밍 어플리케이션의 구조를 일반화 해서 그려보면 아래와 같습니다.

어플리케이션 드라이버

개발자가 작성한 스트리밍 job 코드가 존재합니다.

작성한 job코드는 스트리밍 매니저와 연동되어 실행되어집니다.

job의 결과도 수집하며 이를 활용하여 통해 job의 생명주기 또한 관리합니다.

스트리밍 매니저

스트림 프로세서를 생성, 모니터링을 하며 생명주기를 관리하고, job을 할당합니다.

때떄로 스트림 프로세서가 필요로하는 리소스를 요청하거나 제어 할 수 있습니다.

스트림 프로세서

원천 데이터를 받아서 필터링, 집계, 패턴 감지 등 비즈니스 로직이 실행됩니다. (작성한 job 로직이 실행되는 장소)

스트림 프로세싱 프레임워크의 핵심 기능

메시지 관리 시맨틱

메시지 큐 단계에서 다루었던 메시지 관리 시맨틱에 대한 부분은 원천 데이터와 스트림 프로세서간 통신에서도 동일한 문제가 나타 날 수 있습니다.

그렇기에 스트림 프레임워크에서도 최대 한 번, 적어도 한 번, 정확히 한 번 등의 시맨틱을 제공합니다.

동일하게 비즈니스에 맞는 시맨틱을 선택하면 됩니다.

상태 관리 ((State management))

스트림 시스템에서 계속 흘러가는 데이터들이 외부 데이터와 연동되거나 이전에 처리된 메시지를 참조하는 등 데이터를 다루는 로직이 복잡해지면, 프로세서가 데이터의 상태(State)를 기억하여 값을 안전하게 관리해야합니다.

예를 들어 '방문자의 지난 한 시간 동안 페이지 수 뷰'를 추출해야 한다면 시스템은 '해당 사용자가 한 시간 동안 방문한 페이지 수 데이터'의 값, 즉 상태를 유지해야합니다.

스트리밍 프레임워크는 순수 인 메모리 ((In-Memory))를 활용하는 방법에서 복제 기반 쿼리 영구 저장소 ((Replicated Queryable Persistent Storage))를 활용하는 등 몇가지 상태관리 기능을 제공합니다.

장애 허용 설계 ((Falut tolerance))

분석 단계에서는 다양한 위치에서 장애가 발생 할 수 있습니다.

스트림 데이터 입수, 네트워크 통신, 저장소, 어플리케이션 드라이버에서 장애가 발생하면?

위 4가지 상황에서의 장애는 프레임워크가 통제할 수 있는 상황은 아니지만 장애를 대응 할 수 있는 방법을 만들어 두는것이 좋습니다.

메시지 큐 자체는 스트림 프로세싱 프레임워크의 동작에 영향을 받지 않지만 '큐 단계 시스템'에서는 장애가 발생 할 수 있습니다.

이 경우 스트림 프로세싱 프레임워크는 메시지 큐 단계의 데이터를 사용할 수 없거나 접근이 불가능할 경우에도 정상적으로 동작해야합니다.

그리고 네트워크, 저장소, 어플리케이션 드라이버 장애 또한 동일하게 스트림 프로세스 시스템에 영향을 미칠 수 있기에 적잘한 장애 대응 방법을 고려하는것이 좋습니다.

스트림 프로세서에서 장애가 발생하면?

코드가 실행되는 부분이기에 작성한 코드에서나 소프트웨어 서버에 장애가 발생 할 수 있습니다.

장애가 발생하면 스트리밍 매니저는 프로세서들을 다시 실행하거나 다른 서버로 프로세스를 옮겨 실행해야합니다.

헤드리스 실행((Running headless))이란?

매니저에 장애가 발생하는 상황을 '헤드리스 실행(Running headless)' 이라고 합니다.

스트리밍 매니저의 통제 없이 스트림 프로세서가 계속해서 실행되는 상황을 의미합니다.

따라서 매니저에 장애가 발생하면 프로세서의 통제가 되지 않기에 신규 프로세서 생성이나 장애발생 프로세스 복구가 불가능합니다.

k-내결함성((k-fault tolerant))

장애를 다루기 위한 모든 기술은 복제(Replication)과 조정(Coordination)을 기반으로 합니다.

스트림 매니저가 계산 중인 데이터의 상태를 다른 스트림 프로세서로 복제하고, 장애가 발생하면 미리 복제해둔 데이터를 활용하여 복구합니다.

k-내결함성 시스템에서 k는 장애를 허용하는 노드의 수를 말하며, 분산시스템에서는 투표를 위해 일반적으로 2k+1 의 노드가 있어야합니다.

상태 머신((State-machine))과 롤백복구((Rollback recovery))

상태머신 방식은 스트리밍 잡을 복제하고 동일한 입력을 모든 노드에 동일한 순서로 복제 데이터를 만드는 방식입니다.

그렇기에 복제 데이터를 받을 프로세서가 필요합니다.

자원이 들지만 빠르게 복구가 가능하기에 침입 감지 시스템과 같은 서비스에 적합합니다.

반면 롤백 복구 방식은 스트림 프로세서가 주지거으로 상태를 체크포인트로 다른 스트림 프로세서 노드 또는 디스크와 같은 비휘발성 데이터에 저장합니다.

디스크에 저장하기에 상대적으로 지연이 발생 할 수 있기에 내결함성이 중요하고 어느정도 지연이 허용되는 상황에 유용합니다.

---

이후 단계((저장, 접근))는 다음 포스팅에서 다루겠습니다!

핵심 데이터 모델링 후기

겅겅겅 — Wed, 9 Apr 2025 21:26:55 +0900

이제부터 읽었던 책들에 대해서 블로그에 간단히 개인적인 후기를 남겨놓으려고 합니다.

저의 첫 독서 후기는 유동오님의 책 '핵심 데이터 모델링' 후기입니다!

이 책을 선택한 이유?

처음 회사에서 일을 하면서, 우리 시스템의 데이터 모델들이 과연 잘 정리되어 있는 걸까? 라는 의문이 들 때가 종종 있었습니다.

하지만 그럴 때마다 저는 그저 "잘 되어 있겠지", "원래 이렇게 쓰는 거겠지.." 하면서 명확한 기준이 없는 상태로 사내 데이터 모델링들이

막연하게 정답이라고 생각하고 받아들였습니다.

데이터의 효율적인 적재와 활용은 개발자의 중요한 업무 중 하나라고 생각했지만,

부끄럽게도 저 스스로 데이터 모델링에 대해 본격적으로 공부하지 않았던 제 모습을 반성하기 위한 첫 시작으로 이 책을 결정했습니다.

(쓰다보니까 생각한거보다 글이 조금 장황해지는 느낌이 있는데..ㅠ 그냥 해보겠습니다.)

후기

ER 모델과 기본적인 정규화 이론들 부터 시작해서,

개념 - 논리 - 물리 모델링 방법론들을 적절한 데이터들을 통해 설명해줍니다.

또한 DA컨설턴트 입장에서 클라이언트와 잘 일하기 위한 노하우(?)들도 많이 적혀있습니다.

전반적인 이론보다 실제 데이터(금융, 이커머스)들을 예시로 설명해줘서 익숙한 느낌의 설계들도 많이 보였습니다.

공통코드 설계와 이력관리 테이블 반정규화 방법론 등 도메인 데이터가 아니지만, 필수적인 데이터들에 대한 내용들이

실무에서 보고 배워왔던 방법들과 비슷하게 기술되어있는걸 보고,

오늘날의 데이터 모델링은 '다양한 시스템 속에서 많은 사람들이 만들어놓고 안정시켜 놓은 방법이구나'라는 생각이 들었습니다.

데이터 모델링이 무었인지, 실무에서는 어떤식으로 이론을 적용해야하는지를 공부 할 수 있는 좋은 도서라고 생각됩니다.

개인적으로 아쉬운점

물리 모델링 설계에 대한 내용들이 RDB 설계에만 국한되어 있고,
NoSQL 기반 DB나 데이터 웨어하우스(DW) 환경에서의 모델링 접근 방식은 다뤄지지 않아 약간 아쉬웠습니다.
최근처럼 다양한 형태의 최근처럼 다양한 형태의 저장소와 데이터 구조가 공존하는 환경에서의 모델링 사례나 설계 전략도 함께 소개되었으면 더 좋았을 것 같습니다.

RedBlackTree에 대해서 알아보자

겅겅겅 — Wed, 2 Apr 2025 20:40:46 +0900

RedBlackTree란?

이진 탐색 트리를 사용하다 보면, 데이터들이 불균형하게 생성되는 경우가 있습니다.

불균형한 상태의 이진 트리는 검색효율을 심각하게 저하시키는 원인이 됩니다.

Red Black Tree는 이진트리에 몇가지 규칙들을 더 사용하여 데이터를 균형있게 쌓음으로서, 트리의 높이가 최소한으로 유지되게끔 하여

검색효율을 보장합니다.

균형잡힌 구조 덕분에 Red Black Tree는 시간복잡도 O(LogN)을 유지합니다.

RedBlackTree의 특징

Red Black Tree의 특징은 아래와 같습니다.

모든 노드는 빨간색이거나 검은색이다.
Root노드는 검은색이다
Leaf노드는 검은색이다.
빨간색 노드의 자식들은 모두 검은색이다. (검은색 노드는 빨간색, 검은색 노드 모두 자식으로 가질 수 있다.)
Root노드와 Leaf노드 사이에 있는 검은색 노드의 수는 모두 동일하다.

그리고 그림을 보면 모든 리프노드가 'NIL'로 되어있는데, 이러한 NIL노드들을 센티넬 노드라고도 합니다.

아무 데이터도 가지고 있지 않지만 색깔만 검은색인 더미 노드를 의미합니다.

구현을 용이하게 만들기 위해 존재하는 노드이며, 규칙 3번을 지키기 위해서 존재하는 노드입니다.

RedBlackTree의 사용처

삽입/삭제가 빈번한 환경에서 뛰어난 성능을 보여줄 수 있습니다.

가장 대표적으로는 리눅스 커널의 CFS (Completetly Fair Scheduler), 즉 공정스케줄러에서 프로세스의 실행시간을 정렬해서 적절하게 cpu에 배분할때도 Red Black Tree를 사용합니다.

또한 자바의 TreeMap과 TreeSet, C++의 STD (std::map, std::set, std::multimap, std::multiset)에서도 키값들이 자동 정렬되는데 내부적으로 RedBlackTree를 사용합니다.

즉 키 기반으로 빠르게 데이터를 넣고, 찾고, 삭제해야 하는 곳에서 유용하게 사용 할 수 있습니다.

RedBlackTree의 높이

h(x)는 x자신으로 부터 leaf노드까지의 가장 긴 간선(edge)의 거리입니다. (트리의 깊이)

bh(x)는 x부터 leaf노드까지의 경로상의 '검은노드의 수'입니다.

RedBlackTree의 4번 규칙에따라 h(x) >= hx(x)가 성립하게되며, (red노드는 Black노드 사이에는 하나밖에 올 수 없기에)

따라서 트리의 최소 노드 수(n)는 n >= 2^bh(x) - 1이라는 식을 만들 수 있습니다.

n ≥ 2^bh(x) - 1

그리고 아래와 같은 부등식도 얻을 수 있습니다.

bh(x) ≤ h(x) ≤ 2 × bh(x)

이후 n에 대한 식을 bh(x)에 대한 식으로 변형한다음

n ≥ 2^bh(x) - 1
n + 1 ≥ 2^bh(x)
log₂(n + 1) ≥ bh(x)

부등식에 대입해주면 높이를 구하는 공식을 얻을 수 있습니다.

h(x) ≤ 2 × log₂(n + 1)

구현

Red Black Tree는 기본적으로 이진트리입니다.

따라서 탐색 알고리즘은 이진트리의 알고리즘을 거의 동일하게 사용하면 됩니다.

다만 이진트리의 노드의 삽입, 삭제와 같은 로직에서 Red Black Tree의 규칙을 위배하게되는 상황이 발생하기에 그 무너진 규칙들을 바로잡아주는 과정들이 Red Blakc Tree에 필요합니다.

회전 (Rotate)

Red Black Tree의 규칙을 재정비하기 위한 하나의 방법으로 '회전(rotate)'이 필요합니다.

우회전 : 왼쪽자식을 부모의 위치 이동시키면서 우회전, 이후 왼쪽 자식노드의 오른쪽 자식노드를 원래 부모노드의 왼쪽 자식으로 연결합니다.

좌회전 : 오른쪽 자식을 부모의 위치로 이동시키면서 좌회전, 이후 오른쪽 자식노드의 왼쪽 자식노드를 원래 부모노드의 오른쪽 자식으로 연결합니다.

노드 삽입 (Insert)

레드 블랙 트리에 삽입되는 새 노드는 빨간색이어야하고 NIL노드를 새 노드의 양쪽 자식으로 연결해야합니다.

여기서 NIL노드는 모든 레드 블랙 트리의 실제 리프노드에 연결되어있기에, NIL노드에 계속해서 heap공간을 할당하지 않고 하나의 NIL노드를 계속 재활용합니다.

새로운 노드를 삽입하는 과정에서 신경써야하는 레드 블랙 트리의 4번 규칙입니다.

4. 빨간색 노드의 자식들은 모두 검은색이다. (검은색 노드는 빨간색, 검은색 노드 모두 자식으로 가질 수 있다.)

4번 규칙이 위배되는 상황은 '삽입된 노드의 부모가 빨간색'일 떄 발생합니다.

이 경우에 트리의 규칙을 유지하기 위해 색변경과 회전(Rotate)이 필요할 수 있습니다.

만약 삽입된 노드의 부모가 빨간색이라서 트리의 재구성일 필요하다면 재구성 작업 전 추가적으로 몇가지 더 고려해야하는 부분이 있습니다.

삼촌노드도 빨간색인 경우
삼촌노드가 검은색이며, 새로 삽입한 노드가 부모노드의 오른쪽 자식인 경우
삼촌노드가 검은색이며, 새로 삽입한 노드가 부모노드의 왼쪽 자식인 경우

삽입 연산의 모든 예시에서는 부모노드가 조부모노드의 왼쪽 자식이라고 가정합니다.

부모노드가 오른쪽 자식일때는 아래 설명에서 왼쪽과 오른쪽을 바꾸어서 생각하면 됩니다!

1. 삼촌노드도 빨간색인 경우

부모노드와 삼촌노드를 검은색으로 칠하고 조부모 노드를 빨간색으로 칠합니다.
빨갛게 칠해진 조부모노드가 다시 4번 규칙을 위배 할 수 있기에 새로 삽입한 노드로 간주하고 다시 트리의 재구성 작업 시행

2. 삼촌노드가 검은색이며 새로 삽입한 노드가 부모노드의 왼쪽 자식인 경우

부모 노드를 검은색, 조부모노드를 빨간색으로 칠한 다음 할아버지 노드를 우회전시킵니다.

3. 삼촌노드가 검은색이며 새로 삽입한 노드가 부모노드의 오른쪽 자식인 경우

부모노드를 좌회전시켜 2번과 동일한 상황으로 만듭니다.

노드 삭제

삭제연산은 삽입에 비해 조금 까다롭습니다.

노드가 삭제되면 왼쪽 자식노드는 부모노드보다 작아야하고, 오른쪽 자식노드듣 부모노드보다 커야한다는 기본적인 이진트리 규칙에 더해

레드 블랙 트리의 규칙을 위한 후속조치도 필요하기 때문입니다.

다행인 부분은 빨간색 노드가 삭제되면 트리의 어떤 규칙도 위배되지 않기에 검은색 노드가 삭제되었을때만 고려하면됩니다.

삭제된 노드가 검은색일때 삭제 연산이 무너뜨릴 수 있는 첫번째 규칙은

5번 'Root노드와 Leaf노드 사이에 있는 검은색 노드의 수는 모두 동일하다' 입니다.

그리고 삭제된 노드의 부모와 자식이 모두 빨간색이면 4번 '빨간색 노드의 자식들은 모두 검은색이다.' 규칙도 위배됩니다.

하지만 4번, 5번 규칙을 지키기 위해 트리는 삭제된 노드를 대체하는 노드를 검은색으로 칠함으로 4번, 5번 규칙을 지킬 수 있습니다.

만약 자식노드가 검은색이라면, 4번 규칙은 위배되지 않고 5번 규칙만 위배됩니다.

하지만 이 경우에도 트리는 대체 노드에 검은색을 칠합니다.

이렇게 검은색이 두번 칠해진 노드를 '이중 흑색 노드'라고 합니다.

이중 흑색 노드가 생기면 1번 규칙 '모든 노드는 빨간색이거나 검은색이다.' 규칙이 무너지게 됩니다.

이를 처리하는 방법은 네 가지 경우로 나뉩니다.

형제가 빨간색인 경우
형제가 검은색이고 형제의 양쪽 자식이 모두 검은색인 경우
형제가 검은색이고 자식은 빨간색, 오른쪽 자식은 검은색인 경우
형제가 검은색이고, 형제의 오른쪽 자식이 빨간색인 경우

아래 이중 흑색 노드 처리의 모든 예시에서는 흑색노드가 부모노드의 왼쪽 자식인 경우에 한합니다.

오른쪽 자식인 경우에는 아래 설명에서 왼쪽과 오른쪽을 바꾸어서 생각하면 됩니다!

루트노드가 이중 흑색 노드가 된다면 검은색 노드로 처리합니다.

1. 형제가 빨간색인 경우

형제를 검은색, 부모를 빨간색으로 칠합니다.
부모를 기준으로 자식노드를 좌회전 시킵니다.
아직 이중 흑색 노드는 그대로지만 형제 노드는 검은색으로 바뀝니다.
이중 흑색 노드는 '검은색 형제 노드 처리 방법 (2,3,4)' 유형에 맞게 처리합니다.

2. 형제가 검은색이고 형제의 양쪽 자식이 모두 검은색인 경우

형제노드를 빨간색으로 칠합니다.
이중 흑색 노드가 가지고 있던 검은색을 부모노드에게 넘겨줍니다.
부모가 넘겨받은 검은색은 1,3,4 유형에 맞게 처리합니다. (부모노드가 빨간색이면 검은색으로 변경, 검은색이면 이중흑색으로 변경)

3. 형제가 검은색이고 형제의 왼쪽 자식은 빨간색, 오른쪽 자식은 검은색인 경우

형제 노드를 빨간색으로 칠합니다.
왼쪽 자식을 검은색으로 칠한다음, 형제 노드를 기준으로 왼쪽 자식을 우회전합니다.
이중 흑색 노드는 그대로라면 1,2,4 유형에 맞게 처리합니다.

4. 형제가 검은색이고, 형제의 오른쪽 자식이 빨간색인 경우

이중 흑색 노드의 부모 노드가 가지고 있는 색을 형제 노드에 칠합니다.
부모 노드와 형제 노드의 오른쪽 자식노드를 검은색으로 칠합니다.
부모노드를 기준으로 좌회전합니다.
이중 흑색 노드의 흑색 하나를 루트노드에 넘겨 이중흑색을 처리합니다. (루트노드는 이중 흑색 노드가 되지 않습니다.)

RedBlackTree 구현 코드 (C)

#include <stdio.h>
#include <stdlib.h>
#include <string.h> 

typedef int ElementType;

/*
 RedBlackTree 규칙

 1.모든 노드는 빨간색이거나 검은색이다.
 2.루트노드는 검은색이다
 3.리프노드는 검은색이다
 4.빨간색 노드의 자식은 모두 검은색이다.
 5.리프노드와 루트노드 사이에 있는 검은색 노드의 수는 모두 동일하다
*/
typedef struct tagRBTNode {
    struct tagRBTNode* Parent;
    struct tagRBTNode* Left;
    struct tagRBTNode* Right;
    enum {RED, BLACK} Color;
    ElementType Data;
} RBTNode;

RBTNode* Nil;

/* 노드 생성 */
RBTNode* RBT_CreateNode(ElementType NewData){
    RBTNode* NewNode = (RBTNode*)malloc(sizeof(RBTNode));
    NewNode->Parent = NULL;
    NewNode->Left = NULL;
    NewNode->Right = NULL;
    NewNode->Data = NewData;
    NewNode->Color = BLACK;
    return NewNode;
}

/* 노드 삭제 */
void RBT_DestroyNode(RBTNode* Node) {
    free(Node);
}

/* 트리 삭제 */
void RBT_DestroyTree(RBTNode* Tree) {
    if (Tree->Right != Nil){
        RBT_DestroyTree(Tree->Right);
    }
    if (Tree->Left != Nil){
        RBT_DestroyTree(Tree->Left);
    }
    Tree->Left = Nil;
    Tree->Right = Nil;
    RBT_DestroyNode(Tree);
}

/* 노드 찾기 */
RBTNode* RBT_SearchNode(RBTNode* Tree, ElementType Target){
    if (Tree == Nil) return NULL;
    if (Tree->Data > Target) {
        return RBT_SearchNode(Tree->Left, Target);
    }
    else if (Tree->Data < Target){
        return RBT_SearchNode(Tree->Right, Target);
    }else {
        return Tree;
    }
}

/* 작은노드 찾기 */
RBTNode* RBT_SearchMinNode(RBTNode* Tree){
    if (Tree == Nil) {
        return NULL;
    }
    if (Tree->Left == Nil) return Tree;
    else {
        return RBT_SearchMinNode(Tree->Left);
    }
}

/* 우회전 */
void RBT_RotateRight(RBTNode** Root, RBTNode* Parent) {

    RBTNode* LeftChild = Parent->Left;
    Parent->Left = LeftChild->Right; // 왼쪽 자식노드 자리에 왼쪽 자식노드의 오른쪽 자식노드 세팅

    // 왼쪽 자식노드의 오른쪽 자식노드의 부모노드를, 왼쪽 자식노드의 부모노드로 세팅
    if (LeftChild->Right != Nil){
        LeftChild->Right->Parent = Parent;
    }

    // 왼쪽 자식노드의 부모노드를 부모노드의 부모노드로 세팅 (추후 왼쪽 자식노드가 부모노드가 되어야하기에, 할아버지 노드가 없으면 Root로)
    LeftChild->Parent = Parent->Parent;
    if (Parent->Parent == NULL) {
        (*Root) = LeftChild;
    }else { // 부모노드가 할아버지 노드의 왼쪽에 있으면
        if (Parent == Parent->Parent->Left){
            Parent->Parent->Left = LeftChild; // 왼쪽 자식노드를 부모노드 자리에 위치 (rotate)
        }else { // 부모노드가 할아버지 노드의 오른쪽에 있으면
            Parent->Parent->Right = LeftChild; // 왼쪽 자식노드를 부모노드 자리에 위치 (rotate)
        }
    }
    LeftChild->Right = Parent; // 왼쪽 자식노드(현재 부모노드 위치)의 오른쪽 자식노드를 오른쪽으로 옮김
    Parent->Parent = LeftChild; // 옮겨진 노드의 부모노드를 왼쪽 자식노드(현재 부모노드 위치)로 변경 
}

/* 좌회전 */
void RBT_RotateLeft(RBTNode** Root, RBTNode* Parent) {
    RBTNode* RightChild = Parent->Right;
    Parent->Right = RightChild->Left; // 오른쪽 자식노드(R)의 왼쪽 자식노드(A)를 부모노드(P)의 오른쪽 자식으로 변경

    if (RightChild->Left != Nil) {
        RightChild->Left->Parent = Parent; // 오른쪽 자식노드(R)의 왼쪽 자식노드(A)의 부모를 P로 설정
        RightChild->Parent = Parent->Parent; // P의 부모(G)를 R의 부모로 지정
    }

    // G의 자식을 R로 설정 
    if (Parent == Parent->Parent->Left) {
        Parent->Parent->Left = RightChild;
    }else {
        Parent->Parent->Right = RightChild;
    }

    RightChild->Left = Parent; // P를 R의 왼쪽 자식으로 설정
    Parent->Parent = RightChild; // P의 부모를 R로 설정
}

/*이진 탐색의 InsertNode역할을 수행 */
void RBT_InsertNodeHelper(RBTNode** Tree, RBTNode* NewNode) {
    if ((*Tree) == NULL) {
        (*Tree) = NewNode;
    }
    if ((*Tree)->Data < NewNode->Data){
        if ((*Tree)->Right == Nil) {
            (*Tree)->Right = NewNode;
            NewNode->Parent = (*Tree);
        }else {
            RBT_InsertNodeHelper(&(*Tree)->Right, NewNode);
        }
    }
    else if ((*Tree)->Data > NewNode->Data) {
        if ((*Tree)->Left == Nil) {
            (*Tree)->Left = NewNode;
            NewNode->Parent = (*Tree);
        }else {
            RBT_InsertNodeHelper(&(*Tree)->Left, NewNode);
        }
    }
}

/* 노드 삽입 후 규칙 복구 */
void RBT_RebuildAfterInsert(RBTNode** Root, RBTNode* X) {

    // 빨간색노드의 자식은 반드시 검은색이어야 한다는 규칙 위배
    while (X != (*Root) && X->Parent->Color == RED) {
        // 부모 노드가 할아버지 노드의 왼쪽 자식인 경우
        if (X->Parent == X->Parent->Parent->Left){
            RBTNode* Uncle = X->Parent->Parent->Right;

            // 1. 삼촌노드가 빨간색인 경우
            // 부모노드와 삼촌노드를 검은색으로 칠하고, 할아버지노드를 빨간색으로 변경합니다.
            // 할아버지 노드가 변경되었으니 할어버지 노드를 자식노드로 취급하여 재점검 시행
            if (Uncle->Color == RED) {
                X->Parent->Color = BLACK;
                Uncle->Color = BLACK;
                X->Parent->Parent->Color = RED;

                X = X->Parent->Parent;
            }
            // 삼촌노드가 검은색인 경우
            else 
            {
                // 2. 삼촌노드가 검은색이며 새로 삽입한 노드가 부모노드의 오른쪽 자식인 경우
                // 부모노드를 좌회전시켜 상황을 3의 경우와 같게 만듭니다.
                if (X == X->Parent->Right) {
                    X = X->Parent;
                    RBT_RotateLeft(Root, X);
                }
                // 3. 삼촌노드가 검은색이며 새로 삽입한 노드가 부모노드의 왼쪽 자식인 경우
                // 부모노드를 검은색, 조부모 노드를 빨간색으로 칠한 뒤 조부모노드를 우회전 시킵니다.
                X->Parent->Color = BLACK;
                X->Parent->Parent->Color = RED;

                RBT_RotateRight(Root, X->Parent->Parent);
            }
        }else { // 부모 노드가 할아버지 노드의 오른쪽 자식인 경우
            RBTNode* Uncle = X->Parent->Parent->Left;
            if (Uncle->Color == RED){
                X->Parent->Color = BLACK;
                Uncle->Color = BLACK;
                X->Parent->Parent->Color = RED;

                X = X->Parent->Parent;
            }
            else {
                if (X==X->Parent->Left){
                    X = X->Parent;
                    RBT_RotateRight(Root, X);
                }
                X->Parent->Color = BLACK;
                X->Parent->Parent->Color = RED;
                RBT_RotateLeft(Root, X->Parent->Parent);
            }
        }   
    }
    (*Root)->Color = BLACK; // 루트노드는 항상 검은색
}

/* 노드 삽입 */
void RBT_InsertNode(RBTNode** Tree, RBTNode* NewNode) {
    RBT_InsertNodeHelper(Tree, NewNode); // 이진탐색트리의 노드 삽입
    NewNode->Color = RED; // 새로운 노드는 빨간색으로 칠하고 Nil을 양쪽 지식으로 연결합니다.
    NewNode->Left = Nil;
    NewNode->Right = Nil;
    RBT_RebuildAfterInsert(Tree, NewNode); // 무너진 Red-Black Tree 규칙 고치기 (빨간삭 노드의 자식들은 모두 검은색이다.)
}

/* 노드 삭제 후 규칙 복구 */
void RBT_RebuildAfterReMove(RBTNode** Root, RBTNode* Successor){
    RBTNode* Sibling = NULL;
    while (Successor->Parent != NULL && Successor->Color == BLACK)
    {
        if (Successor == Successor->Parent->Left) {
            Sibling = Successor->Parent->Right;
            if (Sibling->Color == RED) {
                Sibling->Color = BLACK;
                Successor->Parent->Color = RED;
                RBT_RotateLeft(Root, Successor->Parent);
            }else {
                if (Sibling->Left->Color == BLACK && Sibling->Right->Color == BLACK){
                    Sibling->Color = RED;
                    Successor = Successor->Parent;
                }else {
                    if (Sibling->Left->Color == RED){
                        Sibling->Left->Color = BLACK;
                        Sibling->Color = RED;

                        RBT_RotateRight(Root,Sibling);
                        Sibling = Successor->Parent->Right;
                    }
                    Sibling->Color = Successor->Parent->Color;
                    Successor->Parent->Color = BLACK;
                    Sibling->Right->Color = BLACK;
                    RBT_RotateLeft(Root, Successor->Parent);
                    Successor = (*Root);
                }
            }
        }else {
            Sibling = Successor->Parent->Left;

            if (Sibling->Color == RED) {
                Sibling->Color = BLACK;
                Successor->Parent->Color = RED;
                RBT_RotateRight(Root, Successor->Parent);
            }else {
                if (Sibling->Right->Color == BLACK && Sibling->Left->Color == BLACK){
                    Sibling->Color = RED;
                    Successor = Successor->Parent;
                }else {
                    if (Sibling->Right->Color == RED){
                        Sibling->Right->Color = BLACK;
                        Sibling->Color = RED;

                        RBT_RotateLeft(Root, Sibling);
                        Sibling = Successor->Parent->Left;
                    }

                    Sibling->Color = Successor->Parent->Color;
                    Successor->Parent->Color = BLACK;
                    Sibling->Left->Color = BLACK;
                    RBT_RotateRight(Root, Successor->Parent);
                    Successor = (*Root);
                }
            }
        }
    }
    Successor->Color = BLACK;
}

/* 노드 삭제 */
RBTNode* RBT_RemoveNode( RBTNode** Root, ElementType Data) {
    RBTNode* ReMoved = NULL;
    RBTNode* Successor = NULL; // Successor는 ReMoved의 자식 노드 중에서 부모와 연결할 대체 노드를
    RBTNode* Target = RBT_SearchNode((*Root), Data);

    if (Target == NULL) return NULL;

    if (Target->Left == Nil || Target->Right == Nil) {
        ReMoved = Target;
    }
    else {
        ReMoved = RBT_SearchMinNode(Target->Right); // MinNode를 ReMoved로 지정 (기본 트리구조 유지를 위해)
        Target->Data = ReMoved->Data; // MinNode의 데이터로 Target의 데이터를 변경
    }

    // 삭제될 노드의 후임자(Successor) 찾기
    if (ReMoved->Left != Nil) {
        Successor = ReMoved->Left;
    }else {
        Successor = ReMoved->Right;
    }

    if (Successor != Nil) {
        Successor->Parent = ReMoved->Parent;
    }

    if (ReMoved->Parent == NULL){
        (*Root) = Successor;
    }else {
        if (ReMoved == ReMoved->Parent->Left){
            ReMoved->Parent->Left = Successor;
        }else {
            ReMoved->Parent->Right = Successor;
        }
    }
    if (ReMoved->Color == BLACK){
        RBT_RebuildAfterReMove(Root, Successor);
    }

    return ReMoved;
}

void RBT_PrintTree(RBTNode* Node, int Depth, int BlackCount) {
    int i = 0;
    char c = 'X';
    int v = -1;
    char cnt[100];

    if (Node == NULL || Node == Nil) {
        return;
    }
    if (Node->Color == BLACK) BlackCount++;

    if (Node->Parent != NULL) {
        v= Node->Parent->Data;
        if (Node->Parent->Left == Node) c = 'L';
        else c='R';
    }

    if (Node->Left == Nil && Node->Right == Nil) {
        sprintf(cnt, "========= %d", BlackCount);
    }else {
        strncpy(cnt, "", sizeof(cnt));
    }

    for (i = 0; i<Depth; i++) printf("   ");

    printf("%d %s [%c, %d] %s \n", Node->Data, (Node->Color == RED)?"RED":"BLACK", c, v, cnt);

    RBT_PrintTree(Node->Left, Depth+1, BlackCount);
    RBT_PrintTree(Node->Right, Depth+1, BlackCount);
}

int main(void) {
    RBTNode* Tree = NULL;
    RBTNode* Node = NULL;

    Nil = RBT_CreateNode(0);
    Nil->Color = BLACK;

    while (1)
    {
        int cmd = 0;
        int param = 0;
        char buffer[10];

        printf("Enter command number : \n");
        printf("(1) Create a node, (2) ReMove a node, (3) Search a Node \n");
        printf("(4) Display Tree (5) quit \n");
        printf("command number : ");

        fgets(buffer, sizeof(buffer)-1, stdin);
        sscanf(buffer, "%d", &cmd);

        if (cmd < 1 || cmd > 5){
            printf("Invalid command Number: \n");
            continue;
        }
        else if (cmd == 4){
            RBT_PrintTree(Tree,0,0);
            printf("\n");
            continue;
        }
        else if (cmd == 5){
            break;
        }

        printf("Enter the parameter (1~200) :\n");
        fgets(buffer, sizeof(buffer)-1, stdin);
        sscanf(buffer, "%d", &param);

        if (param < 1 || param > 200) {
            printf("Invalid parameter : %d \n", param);
            continue;
        }

        switch(cmd) {
            case 1:
                RBT_InsertNode(&Tree, RBT_CreateNode(param));
            break;
            case 2:
                Node = RBT_RemoveNode(&Tree, param);
                if (Node == NULL){
                    printf("not found node to delete : %d", param);
                }else {
                    RBT_DestroyNode(Node);
                }
                break;
            case 3:
            Node = RBT_SearchNode(Tree, param);
            if (Node == NULL) {
                printf("Not found Node :%d \n", param);
            }else {
                printf("Found Node : %d(Color:%s) \n", Node->Data, (Node->Color == RED)?"RED":"BLACK");
            }
            break;
        }
        printf("\n");
    }
    RBT_DestroyTree(Tree);
    return 0;
}

NandToTetris : 운영체제-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Sun, 16 Mar 2025 21:13:39 +0900

이 책의 마지막 장인 운영체제입니다.

OS는 컴퓨터에서 실행되는 모든 프로그램을 지원해야하기에 효율이 매우 좋아야합니다.

OS의 시간 및 공간 효율성이 높을수록 응용프로그램의 성능 또한 올라갑니다.

운영체제는 보통 고수준언어로 작성되어 바이너리 형식으로 컴파일됩니다.

let n = Keyboard.readInt("Enter a number : ")

위와 같은 명령어가 실행되면, 프롬프트에 Enter a number: 라는 문자열이 표시됩니다.

그러려면 String 객체가 생성되고 각 글자를 char 값 배열로 초기화합니다.

이후 문자열을 스크린에 한 번에 하나씩 렌더링하며, 다음 문자가 물리적으로 표시되어야하는 커서 위치를 업데이트합니다.

또한 사용자가 키보드의 특정키를 누를때까지 기다리는 루프 또한 준비되어야하고 이를 위해서는 키 입력 감지, 문자 입력, 문자열에 해당 문자 추가, 문자열을 정수로 반환하는 등 여러 작업이 필요합니다.

즉 let n = Keyboard.readInt("Enter a number : ") 과 같은 명령이 실행되면 객체 사용을 위한 메모리 할당, 입력 작업, 출력 작업, 문자열 처리와 같은 다양한 os함수들이 호출됩니다.

문자열 처리뿐만 아니라 아래 그림 처럼 수학연산, I/O 드라이버, 네트워크 등 운영체제가 하는일들은 많고 다양합니다.

Jack OS

Jack OS에서 지원하는 서비스들입니다.

Math : 수학관련 클래스

Memory : Memory 클래스 (peek, alloc 등)

Screen : 화면에 도형을 그릴 수 있는 클래스

Output : 화면에 text를 출력하는 클래스

Keyboard : 사용자의 입력을 받는 클래스

String : 문자열 관련 클래스

Array : Jack에서 사용되는 배열 클래스

Sys : 몇가지 유용한 함수가 들어있는 클래스 입니다. (halt, error, wait)

Jack OS : Math

곱셈

먼저 jack의 word size는 16bit입니다.

x는 27, y는 9이고 두 숫자를 곱하는 연산을 한다고 하면

먼저 이진수로 27과 9을 만들고 남는 크기는 모두 0으로 채웁니다.

이제 연산을 시작하는데 아래와 같은 방법으로 연산한다고 생각하면 조금 이해가 쉽습니다.

356 * 73 = (356 * 70) + (356 * 3)

먼저 x를 왼쪽으로 옮기고 (shift) 계속해서 한번씩 왼쪽으로 옮깁니다.

위에 예시에서는 y의 bit(4)만큼 x에 대해 shift가 실행되었습니다.

shift가 완료되었다면 y의 값을 세로로 적은다음, y값의 bit가 1인 행들끼리만 더합니다.

위 예시에서는 첫줄과 마지막줄을 더하면 됩니다.

나눗셈

나누기는 우리가 어릴때 배웠던 나눗셈 방법 '정제법'을 사용합니다.

조금 다른점은 2진수를 사용한다는건데

예를들어 10(1010)를 3(0011)으로 나눈다면 먼저 몫을 담을 비트와 나머지를 담을 비트를 0으로 초기화 합니다.

나눠지는수 '1010'에서 각 bit를 하나씩 왼쪽으로 shift하여 나머지 bit에 추가합니다.

그 후 나머지에서 나누는 수(0011)을 뺍니다. 그 결과가 0 이상이면 몫비트에 1을 넣고 음수라면 몫 비트에 0을 널습니다.

이 과정을 비트수만큼 반복합니다.

제곱근

제곱근은 수학문제 풀듯이 풀어서 찾을 수 있습니다.

제곱근(√)을 구하는 방법은 이진 탐색(Binary Search), 제곱근의 역함수 y = x²,

제곱근 함수와 역함수는 모두 단조 증가함수기에 감소하지 않고 계속 커진다는 특성 이 3가지를 이용해 구할 수 있습니다.

y = √x을 구하는 것은 y² ≤ x < (y + 1)²인 값을 찾는 것과 같습니다.

그래서 제곱근을 찾는 문제는 결국 역함수의 값을 찾는 문제가 됩니다.
그리고 함수다 양의 방향으로만 증가하는 함수기에, 중간값(mid)을 기준으로 범위를 절반씩 줄여갈 수 있습니다. (이진 탐색)

Jack OS : String

String은 Jack OS 표준 라이브러리입니다.

컴퓨터는 숫자를 내부적으로 2진 코드로 표현하지만 사람이 숫자를 읽거나 입력해야할 때는 10진수로 변환(cast)되어야합니다.

String -> int 형변환

int2String()은 숫자를 재귀적으로 문자열로 변환하고,

string2Int()는 각 문자를 숫자로 변환하며 왼쪽에서 오른쪽으로 조합하는 방식으로 동작합니다.

Jack OS : Memory

os에서 메모리를 관련 클래스의 메소드는 peek, poke, alloc, deAlloc이라는 함수가 있습니다.

이 메서드들은 컴파일러에서 생성자 및 소멸자를 처리할 때 저수준 코드에 포함되거나, 아니면 고수준언어에서 직접 호출되기도 합니다.

heap의 자원 관리는 os에서 하며 os가 실행되면 heapBase라는 포인터를 RAM에서 heap의 시작주소로 초기화 합니다.

jack에서는 스택에 끝에 위치하며 heapBase는 2048입니다.

peek & poke

프로그램은 계속해서 RAM에 접근합니다.

운영체제는 고수준 프로그램와 RAM의 인터페이스입니다.

peek & poke는 RAM의 주소에 대한 함수입니다.

Memory.peek(addr)은 RAM의 주소 addr을 반환하고 Memory.poke(addr, value)는 RAM주소와 value를 받아서 해당 주소의 RAM을 value로 설정합니다.

peek & poke를 구현하기 위해서는 RAM에 주소에 직접 접근해야합니다.

메모리 클래스에서 먼저 init 함수를 이용해서 array ram을 0으로 초기화합니다.

변수를 0으로 초기화 함으로서 인덱스를 이용해 ram의 주소 어디든 접근할 수 있게됩니다.

그 뒤에 peek & poke를 사용해서 메모의 값을 조회하거나 변경 할 수 있습니다.

alloc & dealloc

운영체제에서 동작하는 프로그램들은 수많은 객체들과 배열을 생성하고 참조합니다.

생성된 객체와 배열들은 heap에 저장되고 stack은 데이터가 저장된 heap주소를 가지고있습니다.

alloc함수는 argument에 지정한 사이즈만큼의 메모리를 사용할 수 있는 메모리 주소를 반환합니다.

dealloc은 argument지정한 객체나 배열의 주소를 가져와서 재활용 할 수 있도록 해제합니다.

록

클래스의 생성자가 실행되면 alloc(argument 수)명령어가 실행되는데

argument의 수 만큼 heap에서 공간을 할당하고 stack에 그 시작 주소를 저장합니다.

객체가 필요없을때는 deAlloc 메서드를 사용해 그 객체를 제거할 수 있습니다.

자바나 c++에서 gc는 생성되는 모든 객체에 대한 모든 참조를 추적합니다.

프로그램이 동작하면서 그 객체에 대한 온갖 종류의 역참조가 발생하게 됩니다.

계속 동작하면서 특정 포인터를 가리키는 참조 수가 감소되어 결국 0이되면 gc가 동작해서 deAlloc 함수를 실행합니다.

하지만 jack은 gc를 사용하지 않고 명시적으로 제거하는 방법을 선택했습니다.

heap management

os가 heap을 관리하는 방법에 대해 알아보겠습니다.

init()함수에서 heapBase의 주소를 freeList라는 LinkedList에 저장합니다.

LinkedList에는 크기(size)와 다음 빈 블록을 가리키는 포인터(next)가 저장됩니다.

alloc heap management

alloc함수가 실행되면 적절한 block을 찾은 뒤 FreeList에서 제거하고 호출자에게 제공합니다.

alloc(3)함수가 실행되었을 때 세그먼트의 크기가 size+2보다 크면 해당 세그먼트를 제공합니다.

size+2인 이유는 2만큼의 필수 필드값(size, next)을 넣어야하기 때문입니다.

적합한 세그먼트를 찾는 방법은 best-fit, first-fit 두가지가 있습니다.

first-fit은 freeList를 탐색하면서 최초로 찾은 적합한 세그먼트를 사용하는 방식입니다.

best-fit은 가능한 작은 세그먼트를 찾는 방법입니다.

추가로 최초의 freeList의 크기는 heap 전체입니다.

deAlloc heap management

dealloc이 하는일은 객체로 사용되고있는 block을 다시 freeList의 뒤에 붙이는 작업입니다.

그렇기에 dealloc이 많이 실행될수록 freeList는 더 많이 파편화됩니다.

하지만 freeList가 많이 파편화되면 alloc이 적합한 size의 블록을 찾기 점점 어려워집니다.

그래서 defrag라는 알고리즘을 통해 파편화된 freeList들을 합치는 작업이 필요합니다.

(실제로 모든 os에서 defrag가 가끔식 실행됩니다.)

Jack OS : Array

Array 클래스의 new는 생성자가 아니라 함수입니다.

os함수인 Memory.alloc을 호출하여 배열을 위한 메모리를 할당합니다.

그리고 dispose()를 통해 Memory.deAlloc을 호출하여 해제합니다.

Jack OS : Graphics

jack의 Screen클래스는 기본적인 그래픽 그리기 알고리즘만을 제공합니다.

우리는 맨 왼쪽 상단의 좌표가 (0,0)인 흑백스크린에 연결되어있다고 가정합니다.

스크린은 전용 RAM의 메모리맵 영역과 연결됩니다.

컴퓨터 외부의 프로게스가 1초당 한번씩 메모리 맵에 따라 스크린을 새로고침합니다.

vector graphics, bitmap graphics

jack에서는 vector, bitmap 두가지 방식으로 그래픽 구현이 가능합니다.

벡터 그래픽은 수학적 도형(선, 사각형, 원 등)의 명령어를 기반으로 그래픽을 표현하는 방식이고

비트맵 그래픽은 픽셀 하나하나를 직접 지정하여 저장하는 방식입니다.

화면을 2D 배열의 형태(0과 1)로 표현하며, 각 픽셀이 켜짐(1) 또는 꺼짐(0) 상태를 가집니다.

vector 그래픽은 이미지를 픽셀이 아닌 수학적 개념으로 저장하며, 크기를 확대해도 깨지지 않으나

bitmap은 픽셀 단위로 저장되므로, 확대하면 깨지는 문제가 발생할 수 있습니다.

픽셀 그리기 (bitmap)

drawPixcel 함수를 통해 메모리맵을 조작하며 픽셀을 그리게됩니다.

한 개의 RAM 주소는 16개의 픽셀을 저장하기에 픽셀 좌표 (x, y)를 RAM 주소로 변환해서 위치를 찾습니다.

y 좌표 찾기

화면은 512(16*32) 픽셀의 가로 해상도를 가지고 있습니다. 즉 한 줄에 32개의 word size(16bit)가 존재합니다

따라서 y 번째 줄의 시작 RAM 주소는 16384 + (y * 32)로 계산합니다.

x 좌표 찾기

픽셀 x 좌표는 16픽셀 단위로 저장되므로, x가 0~15이면 첫 번째 RAM 단어(16384), x가 16~31이면 두 번째 RAM 단어(16385)

이기에 x / 16계산을 통해 좌표를 찾습니다.

즉 메모리맵의 주소는 address = 16384 + (y * 32) + (x / 16);이 됩니다.

bitMask (픽셀 on/off)

이후 bitMask 연산("1 << (15 - (x % 16))")을 통해 픽셀의 on/off를 설정할수 있습니다.

and연산으로 픽셀을 끄고 or 연산으로 픽셀을 킵니다.

// 픽셀 키기
Memory.poke(address, Memory.peek(address) | bitMask);
// 픽셀 끄기
Memory.poke(address, Memory.peek(address) & (~bitMask));

선 그리기 (vector)

선은 픽셀들을 지그제그로 그려나가는 모양입니다.

아래 그림처럼 선을 그리는 함수 drawLine은 결국 drawPixel의 연속입니다.

x1,y1에서 x2,y2까지 선을 그리는 함수 drawLine(x1,y1,x2,y2) 가 있을때 drawLine함수에는 좌표값(x1, y1)의 이동을 위한 a,b 지역변수가 존재합니다. (a는 오른쪽으로 몇 픽셀이동했는지 알려주고 b는 위로 몇 픽셀 이동했는지 알려줍니다.)

drawLine함수가 실행되면 먼저 x1,y2를 그립니다.

이제 픽셀이 오른쪽으로 이동할지 위쪽으로 이동할지 결정합니다.

b/a가 dy/dx보다 크다면 오른쪽으로 아니라면 위쪽으로 이동합니다.

두 값을 비교를 위해 diff라는 변수를 사용합니다.

어디로 이동할지 정해졌다면 이제 이동을 시작합니다.

오른쪽으로 가야한다면 a를 증가시킵니다. 그 후 while로 다시 돌아와서 변경된 좌표(x+1, y)에 픽셀을 그립니다.

위로 가야한다면 위로 한칸(x+1, y+1) 이동해서 픽셀을 그립니다. (대각선으로 이동하는 경우는 없습니다)

원 그리기 (vector)

원을 그리는 메서드 drawCircle또한 원의 근사치를 만드는 방향으로 구현합니다.

중심의 좌표 x,y와 원의 반지름 r을 argument로 받고, y+dy, x를 지나는 선들을 이용해 원을 그립니다.

x좌표는 반지름과 dy를 이용한 피타고라스의 정리를 통해 구할 수 있습니다.

그렇게 drawCircle에 대한 메소드를 만들 수 있습니다.

Jack OS : Output

문자집합은 출력 가능한것과 불가능한것으로 나뉩니다.

출력 가능한 문자들은 모두 화면에 표시되는 bitmap이미지가 있어야하고 그 이미지들을 font라고 합니다.

(jack에서는 11*8 픽셀을 사용합니다.)

jack os의 Output 클래스에서는 initMap이라는 init시 발생하는 함수를 통해 font에 대한 bitmap들을 저장합니다.

font를 만드는 작업은 사용할때마다 처리하지 않고 최초 Init시에만 설정합니다.

Jack OS : Keyboard

jack에서는 keyboard를 위해 단일 16bit 레지스터를 할당합니다.

키보드에 어떤 키도 누르지 않으면 레지스터의 값은 0입니다.

키보드 클래스는 4가지 메소드로 만들어집니다.

keyPressed() : 키보드에서 눌린 내용이 반환됩니다.

readChar() : 사용자가 마지막으로 누른키를 반환합니다.

readLine() : 문자를 입력하면 enter, return 키를 눌렀을때 입력이 완료

readInt() : readLine과 유사하지만 숫자만 허용

아래 표는 keyboard에서 사용하는 아스키코드값입니다.

Jack OS : Sys

부트스트래핑은 전원을 키거나 전반적인 재설정이 일어날때 컴퓨터의 메모리에 기본적인 소프트웨어를 로드하는 과정입니다.

특히 os가 필요에 따라 소프트웨어를 로드하게됩니다.

부트스트래핑이 일어나기 위해 jack 플랫폼에서는 몇가지 약속이 필요합니다.

1. 컴퓨터가 실행되거나 재설정될 때 ROM[0]에 위치한 명령어가 실행되어야합니다.

2. vm번역기에서 프로그램을 변환할떄 항상 ROM[0]에 sp=256, call Sys.init

3. 실행되는 프로그램은 반드시 Main이라는 클래스가 있어야하고 클래스 내에 main이라는 함수가 필요합니다.

4. Sys init은 os를 초기화하고 반드시 Main.main()을 호출합니다.

Sys클래스의 init함수는 필요한 각 클래스들을 초기화 하고 Main.main을 호출합니다.

동일하게 Sys에 있는 halt, wait함수도 있는데

wait함수는 주어진 밀리초 동안 기다렸다가 반환하는 함수이고

halt는 프로그램 실행을 중단합니다. (while루프로 구현)

---

NandToTetris 후기

어느 시점부터 과제를 안했는데, 그러다보니 책의 내용 그대로만 작성만하게 된 것 같다.

나중에(2026년쯤) 다시 처음부터 개선부분까지 과제를 진행하며 git에 올려봐야겠다는 생각이 강하게 들었다.

지금은 내 기록용 포스팅들이 되어버렸지만 다시 리마스터해서는 조금 더 좋은 내용들을 담아서 리마스터 하고싶다.

NandToTetris : 컴파일러 2: 코드 생성-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Mon, 10 Mar 2025 19:25:05 +0900

컴파일러

고수준 프로그램을 vm코드로 변경해주는 일종의 번역기입니다.

고수준 언어는 객체와 배열등 다양한 추상적 개념들이 있지만 컴파일러의 vm코드에서는 스택과 가상 세그먼트만 사용 가능합니다.

잭 컴파일러는 jack 코드를 vm 코드로 변환합니다.

각각의 파일들은 각각의 vm코드로 변환되며 (filename.jack -> fileName.vm)

서브루틴(생성자, 메서드 등)들은 fileName.subName으로 변환됩니다.

앞장에서 다뤘던 요소 Tokenizer를 포함하여 총 5개의 모듈이 만들어져야 합니다.

1. JackCompiler

입력된 jack 파일을 vm파일로 변환하는 핵심 모듈 , JackToknizer를 호출해여 입력을 전달하고 vm파일을 반환합니다.

이후 SymbolTable, VMWriter를 이용해 최종 vm파일을 만들고 반환합니다.

2. SymbolTable

jack파일에는 여러 종류의 변수들과 scope가 존재하는데 클래스가 컴파일될때 클래스레벨 변수와 서브루틴 레벨 변수를 나누어 테이블을 생성하고 각 변수에 실행 인덱스를 제공합니다.

3. VMWriter

vm코드를 생성하고 출력 vm파일에 보냅니다.

4. ComplitaionEngine

Tokenizer로 부터 부터 입력을 받고 VMWriter를 통해 출력을 작성합니다.

code generator

앞서 구문 분석기를 알아보았고 이제는 실행 가능한 vm코드를 만드는 코드 생성기 code generator입니다.

code generator를 구현하기 위해서는 파서 parsor 의 기능이 일부 필요합니다.

Jack프로그램은 여러 클래스로 이루어져있고 각 클래스 파일들은 개별적으로 컴파일됩니다.

그리고 클래스에서는 class-level code와 subroutine-level code 2가지로 나누어서 컴파일됩니다.

그리고 각 subroutine들을 하나씩 컴파일합니다.

서브 루틴을 컴파일할때는 아래 그림처럼 서브 루틴 내에 존재하는 변수, 표현식, if, while, 객체, 배열들이 모두 컴파일되어야합니다.

변수 처리

앞서 언급한 것 처럼, 변수 또한 class-level과 subroutine-level 두가지 관점에서 존재하며

각 변수들은 식별자와 타입 (int, char 등), 종류 (locak, static), 범위 (scope)를 가집니다.

(핵 플랫폼에서는 class scope와 subroutine scope 2개만 존재!)

Symbol Table

변수, 상수, 서브루틴, 클래스 등 프로그램에서 사용되는 식별자(identifier)에 대한 정보를 관리하는 자료구조이며 해시 테이블 추상화로 구성됩니다.

클래스 마다 class-level, subroutine-level의 식별자들이 각각 다른 symbol table에 존재합니다.

클래스는 컴파일 될 때 마다 새롭게 symbol 테이블을 가지게됩니다.

subroutine symbol 테이블의 첫번째 로우(this)의 type은 항상 해당 클래스를 가지며 argument 0으로 정의됩니다.

만약 x + 17이라는 명령이 있다면 먼저 x가 subroutine수준의 변수인지 확인하고, 이 작업이 실패하면(subroutine 수준이 아니면)

컴파일러는 x가 정적변수나 필드변수인지 확인합니다.

컴파일러는 symbol table들을 LinkedList로 연결하여 사용하고있기에 현재 범위와 관련된 테이블에서 값을 찾고 관련 테이블에서 그 값을 찾지 못하면 리스트의 다음 테이블에서 찾는 방식으로 찾아나갑니다.

만약 어느 테이블에도 없으면 undefined 에러를 발생시킵니다.

Jack 문자열 컴파일

일반적을 객체지향 언어들은 Stringd이라는 클래스 인스턴스로 문자열을 처리합니다.

문자열 상수가 나올 때 마다 컴파일러는 String 생성자를 호출해서 새로운 String 객체를 생성하고 반환하는 코드를 생성합니다.

이 초기화는 문자열 상수마다 String메서드의 appendChar를 연달아서 호출하는 방식으로 이루어집니다.

현대의 언어 (Java, Python)은 gc를 제공하여 사용하지 않는 클래스들을 처리하고, 객체의 효율적 활용을 위해 다양한 최적화와 특화된 문자열 클래스를 제공합니다.

잭 OS는 하나의 String 클래스만 지원하며, 최적화는 지원하지 않는다고 합니다.

Jack 표현식 컴파일

잭은 중위표기법을 사용해서 표현식을 작성합니다. {a * (b + c)}

반면 우리가 컴파일할 목적 언어는 후위표기법 입니다. {a b c + *}

vm머신은 스택기반이기에 중위표현식을 직접 처리 할 수 없습니다.

그래서 후위표현식으로 변환 후 스택 연산을 이용해 vm코드로 변경하는 작업이 필요합니다.

위에 그림에서 나와있듯이 parse tree를 통해 표현식들을 변환합니다.

표현식은 컴파일은 compileExpression 루틴에서 처리됩니다.

codewrite 알고리즘

codewrite알고리즘은 전달받은 표현식을 vm명령으로 변경합니다.

들어온 값이 상수라면 push c 상수를 push하는 명령어를 만듭니다.

아래 예시와 같이 x + g(2,y -5, -z)같은 표현식이 들어오면

x에 대한 코드를 먼저 생성하고 g에 대한 코드를 모두 생성하고 op를 생성합니다.

전체 Jack 표현식

Jack언어의 표현식 문법입니다.

Jack 명령문 컴파일 (let, do, return)

return 명령문은 compileExpression 루틴을 호출해서, 표현식의 값을 계산하여 스택에 넣는 vm코드를 생성합니다.

이후 return vm명령을 생성합니다.

let 명령문 (let varName = expression)은 varName을 기억하는것 부터 시작합니다.

이후 compileExpression을 호출하여 표현식의 값을 스택에 넣고 마지막으로 pop varName vm명령을 생성합니다.

여기서 varName은 실제로 symbol 테이블에서 varName에 매핑됩니다. (local 3, static 1 등)

do 명령문 (do className functionName(exp1, exp2, ..., expn))은 서브루틴의 반환값은 무시하고 서브루틴의 기능만을 호출하기 위한 명령문입니다.

compileExpression를 호출하고 pop temp 0 명령으로 최상위 스택 항목을 제거하면 됩니다.

Jack 명령문 컴파일 (while, if)

while, if문들은 vm언어의 goto, if-goto, label로 변형되어야합니다.

if, while문의 경우에는 항상 expression의 true, false를 통해 실행할 코드가 변경됩니다.

if 문은 먼저 expression의 값을 계산하고 그 결과에 대해 부정합니다.

만약 부정한값이 참이면 L1으로 이동하고 거짓이면 L2로 이동합니다.

while문은 label (L1)을 만들고 expression을 계산하는 코드를 생성합니다.

그리고 계산된 expression을 부정합니다. 값이 참이면 label L2로 가서 빠져나갑니다.

Jack 객체 컴파일

객체 지향 언어들은 객체 object라는 집합적인 추상 개념을 다룰 수 있는 수단을 제공합니다.

객체들은 static, field, local, argument로 참조되는 메모리 블록으로 구현되며,

객체 변수 또는 포인터라고 하는 참조 변수들은 메모리 블록의 시작 주소를 담고있습니다.

잭은 heap을 통해 객체를 구현합니다.

p객체의 foo메소드가 있다고 생각해봅시다.

p.foo()와 같은 호출이 호출되면 (피호출) foo안의 코드들은 this위에서 동작해야합니다.

즉 메서드가 실행될 때, 해당 메서드가 호출된 객체의 필드(인스턴스 변수)를 변경할 수 있도록 this를 올바르게 설정해야합니다.

말이 조금 어려운데, 예를들어 Jack 컴파일러가 피호출되는 p.foo();를 VM 코드로 변환할 때,
아래와 같이 this 세그먼트가 p 객체의 필드와 연결되도록 설정하는 과정이 필요합니다.

배열 또한 Array 클래스의 인스턴스로 구현되어 있기에 배열을 사용할때도 객체의 방법과 유사하게 동작합니다.

push argument 0   // p 객체의 주소 (현재 메서드가 실행되는 객체) 
                  // 메서드는 항상 첫 번째 인자로 자신을 호출한 객체의 주소를 받음
pop pointer 0     // this = p; 객체의 주소 저장

Jack 생성자 컴파일

생성자 관점에서의 호출 컴파일과 피호출자 관점에서의 컴파일 두가지가 존재합니다.

생성자 호출 컴파일 (caller)

객체 생성은 크게 2가지 단계로 나뉩니다.

1. var Point p와 같이 클래스 타입 변수가 선언될 때

2. let p = Point.new(2,3)과 같이 클래스 생성자를 호출해서 그 객체가 인스턴스로서 생성 될 때

먼저 인스턴트 생성 명령문을 let p = Point.new(2,3)이 실행되면

생성자가 Point인스턴스를 나타내는 크기만큼 메모리를 할당하고 그 값을 초기화해야하고,

p가 이 블록의 시작 주소를 참조하도록 합니다.

위 그림에서 2개의 객체가 생성되었는데, 생성자는 각각 두 객체의 메모리를 할당합니다.

이렇게 컴파일이 되면 symbol 테이블이 업데이트되고 저수준 코드가 생성되지만, 그 이후에는 어떠한 동작도 하지않습니다.

객체는 런타임, 즉 컴파일된 코드가 실행될 때 생성되고 변수에 바인딩됩니다.

생성자 호출 컴파일 (callee)

이제 생성자가 실행될 때 생성자의 관점 (피호출자)에서도 알아보겠습니다.

생성자는 argument와 local변수 그리고 명령문을 사용 할 수 있는 서브루틴이며 컴파일러도 생성자를 서브루틴으로 취급합니다.

새 객체를 생성하려면 먼저 객체의 크기만큼 RAM에 공간을 할당해야합니다.

컴파일러는 Memory.alloc(size)라는 os함수를 실행하여 객체가 필요한만큼의 공간크기를 지정하고 그 주소를 반환합니다.

Memory.alloc(size)을 호출하기 전 컴파일러는 필요한 메모리 블록의 크기를 계산합니다.

예를 들어 Point객체에 int x, y가 있다면 push constant 2, call Memory.alloc 명령을 생성해서 Memory.alloc(2)함수를 실행합니다.

alloc은 크기가 2인 사용 가능한 메모리 블록을 찾고 그 시작 주소를 stack에 push합니다.

그 후 pop point 0명령을 실행하여 this를 alloc이 반환한 주소로 설정합니다.

위 그림의 코드를 보면 이렇게 this가 처리된 후 let x = ax;라는 명령이 실행됩니다.

컴파일러는 x가 어떤 변수인지 세그먼트 확인을 위해 symbol 테이블을 참조합니다. (x는 this 0, ax는 argument 0입니다.)

그 후 compileLet 루틴이 push argument 0, pop this 0명령을 생성합니다.

그리고 잭의 모든 생성자는 return this로 끝나야 합니다.

그렇기에 컴파일러는 생성자 컴파일의 마지막에 push pointer 0, return을 붙이게 됩니다.

Jack 메소드 컴파일

각 클래스들은 별도의 컴파일 단위입니다.

일반적으로 객체지향 언어에서 코드를 작성하다보면 클래스에서 다른 클래스의 메소드를 호출하게 되는데

클래스의 메소드는 호출되는 클래스 (callee)에 의해 캡슐화 되어있습니다.

하지만 vm언어에는 객체나 메서드에 대한 개념이 없기에 객체지향이 아닌 절차지향 언어처럼 처리합니다.

잭 언어는 두 종류의 메소드 호출을 지원합니다.

varName.methodName(exp1, ..., expn) : varName이 참조하는 객체에 메소드 적용 (caller)
methodName(exp1, ..., expn) : 현재 객체에 객체에 메소드 적용 (callee)

varName.methodName(exp1, ..., expn) caller시점

먼저 메소드 호출 varName.methodName(exp1, ..., expn) 컴파일되면

기본 주소 push varName 명령을 시작하여 모든 argument와 기본주소(p1)를 stack에 push합니다.

이후 compileExpresion을 n번 호출합니다.

마지막으로 call className.methodName n+1을 실행합니다. (만약 argument가 없다면 n+1이 아닌 1)

methodName(exp1, ..., expn) (callee)

methodName(exp1, ..., expn) 처럼 현재 객체에서 실행되는 메소드도 존재합니다.

이미 this 세그먼트가 설정되어 있기 때문에, 이 경우에는 this가 없이, 필요한 인자를 바로 사용할 수 있습니다.

즉 argument만 스택에 push하고 필요햔 명령어를 실행하면 됩니다.

마지막으로 void메소드는 고수준언어 시점에서는 값을 반환하지 않지만 잭 컴파일러에서는 반드시 값을 반환해야합니다.

그러므로 컴파일러에서는 void메소드의 마지막에 push constant 0, return 명령을 실행합니다.

이후 caller코드는 pop temp 0를 실행하여 스택에서 불필요한 값을 제거합니다.

Jack 배열 컴파일

고수준언어에서 var Array arr가 선언되면 컴파일러는 이 배열을 local 0로 초기화합니다.

이후 Array 클래스의 서브루틴을 호출해서 배열에 해당하는 공간을 heap에 할당합니다.

새로 할당된 heap주소는 local 0에 저장됩니다.

symbol테이블에는 local, 0, Array, arr 이 4개의 컬럼을 첫 로우에 추가합니다.

위 그림의 vm 코드를 보면 push local 0으로 배열의 주소를 초기화하고

배열의 크기인 constant 2도 push 후 add합니다. 이 결과로 대상 주소가 스택에 push됩니다.

다음으로 pop point 1로 주소를 that 세그먼트에 추가합니다.

that에 arr의 주소가 들어갔기에 이제 배열을 조작할 수 있습니다.

위 그림의 코드에는 없지만 push 17, pop that 0 명령을 사용해서 배열에 값 17을 추가합니다.

(배열에 다른 인덱스에 값을 넣을때는 offset을 추가해서 사용합니다.

이후 push that 0, pop local 1과 같은 명령을 통해 배열에 값을 참조 할 수 있습니다.

하지만 위와같은 방식에 하나의 문제가 있습니다.

바로 let a = b[j]같은 명령에는 동작하지만 let a[i] = b[j]처럼 할당 명령 왼편에도 인덱스가 있는 경우에는 실패합니다.

그래서 위와같은 let arr[expression1] = expression2 에서도 제대로 동작하기 위한 전략이 조금 필요합니다.

아래 그림은 let arr[expression1] = expression2와 같은 코드가 동작하기 위한 vm코드입니다.

let arr[expression1] = expression2 을 위한 전략

먼저 state1 까지 코드가 실행되면 a[i], b[j]의 RAM주소가 stack에 들어갑니다.

이후 stack의 b[j]의 기본주소를 pop하여 pointer 1에 넣습니다.

that 0가 b[j]와 정렬되었기에 b[j]에서 찾은 값을 temp 0에 넣습니다.

pop pointer 1을 실행해서 a[i]주소도 정렬하고 stack을 비웁니다.

이러한 방법으로 a[i] = b[j]를 가능하게 만들 수 있습니다.

---

어느 순간부터 바쁘다는 핑계로 과제를 안하고있는데, 이제 마지막장 운영체제만 남았으니 일단 마저 내용만 다 정리한다음 나중에 다시 보면서 과제를 진행해야겠다..ㅠㅠ

NandToTetris : 컴파일러 1: 구문 분석-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Sun, 9 Mar 2025 21:32:34 +0900

컴파일 과정은 크게 둘로 나뉩니다.

먼저 프로그램의 구문(syntax)를 이해하고, 그 구문을 통해 프로그램의 의미(semantics)를 찾습니다.

예를 들어 프로그램 코드를 분석(parsing)해서 배열을 선언하거나 객체를 조작하려고 한다는 사실을 파악했다고 하면,

그 언어의 구문을 이용해 코드를 다시 표현 할 수 있습니다. 이를 구문 분석(syntac analysis)라고 부릅니다.

구문 분석기는 tokenizer와 parser로 나뉩니다.

두번째 과정인 코드 생성(code generation)은 다음장에서 다룹니다.

핵 플랫폼에서는 구문 분석기가 소스코드의 구문 구조를 반영하는 xml 마크업 파일을 출력하도록 하는 것 입니다.

구문 분석기에서 만든 xml 파일을 code generator가 사용합니다.

Tokenizer

구문 분석기에서 입력된 문자들을 토큰이라는 언어의 기본 요소들로 분류하는 tokennizing 단계를 처리하고

토큰들을 의미가 있고 구조화된 명령문들로 분석하는 단계입니다.

어휘 분석

Tokenizer에 입력이 들어오면 먼저 들어온 문자들을 어휘(lexicon)에 맞게 분류합니다.

프로그래밍 언어의 명세에는 언어가 인식하는 token 또는 단어의 유형이 존재합니다.

우리의 jack 언어는 다섯 가지 유형으로 분류됩니다.

이런 유형으로 정의되는 토큰들을 모아서 언어의 어휘 (lexicon)이라 부릅니다.

키워드(class, while)
기호(+,<)
정수형 상수(17,314)
문자열 상수("FAQ", "Frequently Asked Questions")
식별자(변수, 클래스, 서브 루틴의 이름을 뜻하는 텍스트 레이블)

가장 가장 단순한 형태의 컴퓨터 프로그램은 텍스트 파일에 저장된 문자열입니다.

구문 분석의 첫 단계는 공백, 주석을 무시하고 문자들을 언어 어휘로서 정의된 토큰으로 분류하는 것 입니다.

이 단계는 어휘 분석 analysis, 스캐닝 scanning, 토큰화 tokenizing로 불리며 모두 같은 뜻입니다.

아래 그림에서 jack언어의 어휘(lexcion)들과 일반적인 코드들이 어떻게 처리되는지 볼 수 있습니다.

문법

토큰 또는 단어스트림으로 인풋으로 주어진 텍스트를 처리하고 나면, 그 단어들을 유효한 문장으로 묶을 수 있습니다.

문법적으로 유효한 문장을 만들기 위한 문법은 메타 언어 meta-language (언어를 기술하는 언어)로 작성됩니다.

# if조건문 문법
# 규칙 이름 : 문법
ifStatement: 'if' '(' expression ')' '{' statements '}'

Jack의 if문은 'if' 키워드로 시작해야 함
다음에 '(' (여는 괄호) expression (조건식, 예: x > 5) ')' (닫는 괄호)
'{' (여는 중괄호) statements (실행할 코드)'}' (닫는 중괄호)

문법은 3가지 요소로 순서대로 구성되는데

단말 terminal, 비단말 non-terminal, 한정자 quailifier 입니다.

단말 Terminal : 토큰, 오른쪽이 상수로만 구성된 규칙
비단말 Non-Terminal : 다른 규칙의 이름과 상수로 구성된 규칙
한정자 Quailifier : |, *, ?, (, )의 다섯가지 기호

한정자 quailifier 는 특정요소가 몇번 등장 할 수 있는지 나타내는 기호입니다.

예를들어

statements: statement* 는 let y = 10; if (x > y) { let x = y; } 이런식으로 여러개의 statement를 허용한다는 의미입니다.
statement: letStatement | ifStatement | whileStatement → statement는 let, if, while 중 하나만 선택 가능하다는 의미가 됩니다.
expression: term (op term)? → term은 필수, (op term)은 0개 또는 1개만 허용된다는 의미입니다.

아래 표에서

단말 Terminal은 아래 그림에서 if, let 처럼 굵게 처리된 단어들입니다.

비단말 Non-Terminal은 기울임꼴로 적혀있는 단어들입니다.

파싱 트리

토큰화된 코드를 문법적 구조로 변환하는 과정에서 생성하는 트리입니다. (xml로 변환)

파싱트리를 통해 jack 프로그램이 올바른 구문을 따르는지 확인하고, 이후 코드 생성 단계에서 이를 활용합니다.

핵 플랫폼에서는 파싱 트리 구조를 반영하는 마크업 형식의 xml파일을 파서의 출력이 되도록 했습니다.

아래 그림을 보면 문법을 기준으로 구문들을 분리하고, 들어가서 또 분리하기를 반복하며 (재귀)

모든 토큰들을 분류하여 트리구조로 만듭니다.

아래 그림은 whileStatement 서브루틴이 실행되면 어떤 결과로 파싱트리가 만들어지는지 보여줍니다.

파서 Parser

파서는 토큰을 순서대로 입력받아 대응하는 파싱 트리를 xml파일로 생성합니다.

파싱 트리를 구성하는 알고리즘이 몇 가지 있는데, 그중 재귀 하향 파싱 recursive descent parsing 방법을 사용해 언어 문법에 사용된 중첩 구조를 이용해 토큰화된 입력을 재귀적으로 분석합니다.

파싱 트리는 들어온 구문들을 토큰단위로 분리하기 위해 계속해서 재귀적으로 구문을 처리합니다.

whileStatement는 compileWhileState()로 처리되는데

저 compileWhileState()메소드 안에는 아래 그림처럼 재귀적으로 각 구문들을 처리하는 함수들이 필요합니다.

위에 whileStatement는 간단하지만 클래스 static 변수와 인스턴스 field 변수를 정의하는 규칙에서는 더 복잡해집니다.

아래 그림은 클래스 static 변수와 인스턴스 field 변수를 정의하는 규칙입니다.

맨 앞에 static, field 두가지 토큰이 다 시용 가능하고, 클래스의 static 변수와 인스턴스 필드 변수 선언은 여러 변수를 한 번에 선언할 수 있습니다.

compileClassVarDec() 함수는 입력에 있는 여러 변수 선언을 처리하기 위해 반복문을 사용합니다.

이 반복문은 하나의 변수 선언을 처리한 후, 또 다른 변수 선언이 있을 경우 다시 반복하여 처리하는 방식으로 동작합니다.

LL 문법

컴파일러는 LL 문법을 사용하여 코드를 파싱합니다.

LL 문법이란, 왼쪽에서 오른쪽으로 읽으며, 왼쪽(L) 파생을 사용하는 문법을 의미합니다.

LL(1): 첫 번째 토큰만 보고 어떤 문법을 적용할지 결정할 수 있는 경우
LL(2): 첫 번째 토큰만으로 구별할 수 없어서, 두 번째 토큰까지 확인해야 하는 경우

앞서 var, let, while을 사용하는게 컴파일러를 만들 때 유리하다고 언급되었는데 여기서 그 이유가 나옵니다.

var, let, while 같은 키워드를 앞에 두면 컴파일러는 첫 번째 토큰을 읽는 순간 바로 어떤 구문인지 알 수 있기 때문에
백트래킹없이 빠르고 효율적인 파싱이 가능해집니다.

첫번째 토큰으로 어느 문법 규칙을 봐야할지 판단할수 있으면 LL(1),

첫번째 토큰으로 모호하면 LL(2)로 두번째 토큰까지 확인합니다.

이렇게 하면, 파서가 첫 번째 토큰만 보고 어떤 규칙을 따라야 하는지 결정할 수 있어 백트래킹 없이도 효율적인 파싱이 가능합니다

Jack문법 정리

jack 언어의 문법은 아래와 같은 문법을 따르며

구문 분석기도 아래와 동일한 규칙을 사용해 파싱합니다.

구문 분석기 구현목록

핵 플랫폼에서는 구문 분석기를 만들기 위해서는 아래의 3가지 모듈을 구현하는것을 제안합니다.

다음장에서 기호테이블과 vm코드 생성기를 추가로 만들면 컴파일러가 완성됩니다.

JackAnalyzer : 다른 모듈을 불러오고 설정하는 메인 프로그램

JackTokenizer : 토큰화 모듈

ComplicationEngine : 재귀 하향식 파서 (추후 컴파일 엔진 역할도 함)

JackTokenizer

입력 스트림의 주석과 공백을 제거하고 한번에 하나의 토큰에 접근하도록 만들어줍니다.

아래는 JackTokenizer의 함수들입니다.

ComplicationEngine

구문 분석기에서 컴파일 엔진은 JackTokenizer를 통해 들어온 입력코드를 xml태그로 변환해 출력합니다.

출력은 xxx를 컴파일하는 compilexxx루틴들이 생성합니다.

대응되는 compilexxx이 없는 문법 규칙들 (type, className, subroutineName, varName, statement, subroutineCall 등) 은

구조화를 위해 따로 함수(compileXXX())로 만들지 않습니다.
대신, 해당 문법 규칙이 필요한 다른 compileXXX() 함수 안에서 직접 처리합니다.

대부분 LL(1)으로 처리되지만 term, subroutineCall과 같은 경우를 처리할 때에는 LL(2)가 반드시 필요하게됩니다.

subroutineCall 예시 : bar(x + 2)

term 예시 : (x + 1), arr[2]

JackAnalyzer

JackTokenizer와 ComplicationEngine를 통해 전체 구문분석을 진행하는 모듈입니다.

Xxx.jack 파일마다 JackAnalyzer 모듈은 아래와 같은 작업을 합니다.

(Jack 파일을 컴파일하려면 가장 먼저 compileClass가 실행되어야합니다.)

1. Xxx.jack 파일마다 JackTokenizer를 생성합니다.

2. XXX.xml이라는 출력파일을 생성합니다.

3. JackTokenizer와 ComplicationEngine를 사용하여 입력파일을 파싱하고 파싱된 코드를 출력파일에 기록합니다.

NandToTetris : 고수준 언어 Jack-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Fri, 7 Mar 2025 21:45:46 +0900

이제는 핵 플랫폼의 고수준 언어 Jack이 드디어 나타났습니다.

기본적으로 java, c++같은 객체기반 언어라고 합니다.

상속은 지원하지 않지만, 여러가지 응용프로그램을 만들수 있다고합니다.

잭은 여기 플랫폼에서만 사용되는 언어이기에 잭을 학습한다기 보다는

'컴파일러와 os를 개발할 때 지지대 역할을 하는 언어'정도로만 생각하고 학습하려합니다.

Hello World

컴파일된 잭 프로그램이 실행될 때는 항상 Main.main함수에서 실행됩니다.

잭은 표준 클래스 라이브러기가 존재하며 이를 잭 OS라이브러리라고 합니다.

절차적 프로그래밍과 배열 처리

변수 할당 및 반복을 처리하는 전형적인 명령문들입니다.

keyboard와 Output은 os라이브러리의 클래스입니다.

잭에서 Array객체는 타입과 상관없이 모든 값들을 저장 할 수 있습니다.

추가로 잭에서는 기본데이터 타입으로 int, char, boolean을 지원합니다.

클래스 사용하기

아래 사진에 Fraction 클래스가 있는데,

접근자, 생성자, this등 객체지향과 관련된 익숙한 명령들이 보입니다.

jack은 가비지 컬랙터가 없기에 사용한 객체는 명시적으로 free가 필요하고, 서브루틴은 항상 return문으로 종료해야합니다.

아래는 Main함수에서 Fraction 클래스를 사용하는 예제입니다.

메모리 관점에서 class

클래스와 클래스 인스턴트를 2개 생성하는 main함수가 있습니다.

컴파일러에 생성자를 컴파일 할때 os를 호출하고 이때 os가 사용가능한 RAM 공간를 찾아서 RAM 공간에다가 객체를 저장합니다.

a인스턴트의 local 변수에는 15087이 들어있고 이 변수를 포인터로 취급해서 값을 찾으면 heap에 있는 값 '2' 을 찾을 수 잇습니다.

다음 heap의주소에는 a인스턴스의 다른 값이 들어있습니다.

List

리스트의 각 데이터들의 주소는 통제할 수 없습니다.

생성자가 동작하면 데이터들은 메모리 전체에 분산되지만, vm머신은 시작주소만 알고있다면 다음 요소의 위치를 계산해서 다음 데이터를 읽을 수 있습니다.

아래 코드처럼 리스트를 구현해서 LinkedList를 만들어 사용할 수 있습니다.

잭 언어 구문

jack 언어에서 임의의 수의 공백, 주석으로 구분되는 기호, 예약어, 상수, 식별자입니다.

클래스

잭의 기본 프로그래밍 단위는 클래스입니다.

클래스들은 xxx.jack이라는 개별파일에 저장되며, 각각 별도로 컴파일됩니다.

클래스 선언 이후에는 하나 이상의 서브루틴을 생성 할 수 있으며 각각 생성자, 함수, 메서드 중 하나를 정의합니다.

기본 문법

//, /* */ 으로 주석을 표시합니다.

while, function 등 약 70개 정도의 keyword가 있습니다.

var, let, do는 컴파일러 작성을 쉽게하기위해 의도적으로 만들어졌습니다. (추후 컴파일러에서 알게된다고 함)

상수에는 int, string, boolean 상수가 있습니다.

타입 변환

jack에서 문자(char)와 숫자타입은 타입변환이 가능합니다.

string을 char를 변환하려면 charAt()를 통해 변환해야합니다.

Array를 선언할때 조금 특이한 문법이 있는데,

arr = 5000 이런식으로 숫자를 사용해서 배열을 초기화하는데 이는 배열의 기본주소가 5000에서 시작한다는걸 의미합니다.

그리고 Fraction 객체를 x를 정의한 다음, 배열객체 arr을 넣는데

이렇게 되면 x는 arr배열을 가리키게 되며, x.print와 같은 Fraction의 메소드를 사용 가능하게됩니다.

자바와 c++에서도 객체를 배열로 쉽게 직렬화가 가능한데 jack은 그런 관계를 더 명확하게 정의했다고 합니다.

그리고 jack은 연산 우선순위가 없어서 4 + 3*3라는 계산식이 21이 나올수도 있습니다.

괄호를 필수적으로 적용해야합니다.

클래스에서는 서브루틴에서 접근가능한 정적 변수, 클래스 단위에서 정의되어 사용되는 필드 변수

하나의 서브루틴 안에서만 사용되는 로컬 변수, 서브루틴에 전달되는 파라미터 변수 총 4가지가 있습니다.

명령문

고수준 언어에서 익숙한 명령문들의 문법입니다.

jack application 개발

직접 작성한 jack언어와 jack os라이브러리(graphics, inputs, Math, String, Array, Memory, Sys, Output)를 사용해서

아래와 같은 다양한 프로그램을 만들 수 있습니다.

jack 클래스 파일을 만들고 jack언어로 프로그램을 만든다음 jackCompiler에 파일이나 directory를 넣어서 컴파일합니다.

컴파일러는 vm파일을 만들고 vm에뮬레이터를 통해 실행시킵니다.

NandToTetris : 가상머신2-제어-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Wed, 26 Feb 2025 23:41:50 +0900

런타임 시스템

모든 컴퓨터 시스템은 런타임 시스템 모델을 정의해야합니다.

프로그램 실행을 시작하는 방법, 프로그램 종료시 수행해야하는 작업,

한 함수에서 다른 함수로 인수를 전달하는 방법, 실행 중인 함수에 메모리 리소스를 할당하는 방법, 더 이상 필요없는 메모리를 해제하는 방법 등, 모든 필수적인 질문들에 대한 정의가 필요합니다.

핵 플랫폼에서는 이 문제들을 HACK 플랫폼의 표준 맵핑과 함께 VM 언어 명세로 다룹니다.

명세에 따라 vm 번역기를 개발하면 최종적으로 실행 가능한 런타임을 구현 할 수 있습니다.

특히 vm 번역기는 vm명령 (push, pop, add)등을 어셈블리 명령어로 번역할 뿐 아니라, 위에서 언급한 모든 질문들에 대한 대답을 어셈블리어로 만들 수 있습니다.

고수준 마법

위와 같은 수식은 고수준 언어를 이용하면 실제 수직과 거의 유사한 형태로 만들 수 있습니다.

뿐만아니라 if와 같은 분기문을 이용해서 더 고수준의 논리를 적용 할 수도 있습니다.

하지만 컴파일러 및 vm 에서는 저수준에서 분기 명령 및 함수 호출-반환 명령을 구현해야합니다.

함수

모듈식 프로그래밍의 기본 단위로서, 특정 기능을 수행하도록 서로를 호출 할 수 있는 독립적인 프로그래밍 단위를 말합니다.

solve라는 함수는 sqrt() 함수를 호출하고 또 sqrt()는 power() 함수를 호출 할 수 있습니다.

어떤 경우에는 재귀적으로 깊이 들어갈수도 있습니다.

일반적으로 호출하는 함수 (caller)는, 호출 받는 함수를 콜리 (callee)에게 인수를 전달하고, 호출되는 함수가 실행을 완료 할 때 까지 실행을 일시 중단합니다.

콜리는 전달받은 인수를 활용하여 무언가를 실행하거나, 계산한 후 다음 호출자에게 값을 반환합니다.

말로만 들으면 간단하게 끝날 것 같지만,

한 함수가 다른 함수를 호출할 때마다 아래와 같은 추가작업(overhead)들이 필요합니다.

콜러가 콜리 호출 시 발생하는 오버헤드

- 콜리가 실행을 마친 후 제어를 반환해야하는 주소 저장

- 콜러의 메모리 자원 저장

- 콜리에서 필요한 메모리 자원 할당하기

- 콜러가 전달한 인수를 콜리에서 사용할 수 있도록 만들어야함

- 콜리 코드를 시작

콜리가 값 반환시 발생하는 오버해드

- 콜리의 리턴 값을 콜러에서 사용할 수 있도록 만들어야함

- 콜리가 사용했던 메모리 자원 반납

- 콜리 연산 전, 콜러를 멈출 때 저장했던 메모리 자원 복원

- 이전에 저장해둔 반환 주소 되찾기

- 반환 주소부터 콜러의 코드 다시 시작

분기

저수준 프로그래밍에서 분기는 goto destination 명령으로 실행됩니다.

목적기 (destination)에는 여러 형식이 있지만, 가장 기초적인건 다음에 실행될 실제 메모리의 주소입니다.

저수준 언어에서 코드 내 특정 위치에 기호 레이블을 설정 할 수 있는 레이블 지시문이 있다면,

실제 메모리에 바인딩 되는 기호 레이블을 지정하는 방식으로 나름대로 추상적인 지정도 가능합니다.

핵 플랫폼에서 만드는 vm언어에서는 label symbol이라는 구문으로 레이블 지시문을 사용 할 수 있습니다.

vm언어에서는 무조건 분기 (unconditional branching), 조건부 분기 (conditional branching) 두가지가 존재합니다.

vm언어에서는 불 표현식을 스택에 넣는 방식으로 조건을 지정합니다.

예를 들어 if (n<100) goto LOOP를 push n, push 100, lt, if-goto LOOP로 번역합니다.

무조건 분기 (unconditional branching)

- goto symbol 명령으로 수행

- 코드에서 label symbol바로 다음 명령으로 점프해서 그 명령을 실행하라는 뜻

조건부 분기 (conditional branching)

- if-goto symbol몀령으로 수행

- 스택의 최상위 값을 pop하여, 그 값이 true이면 label symbol 명령의 바로 다음 명령으로 점프해 그 명령을 실행하고, false면 코드에서 바로 다음 명령을 실행하라는 뜻

분기처리 예시

x와 y에 대한 함수가 있습니다. (sum = sum + x, y times)

while문에 조건을 이용하면 간단하지만 vm 코드에서는 vm의 분기명령인 goto, if-goto, lable을 이용해 루프를 구현합니다.

함수

위 사진의 vm코드쪽을 보면 push나 sub같은 명령어들은 이제 익숙하지만 call Math.multiply라는 함수를 호출하는 명령어가 등장합니다.

앞서 구현했던 ALU에 곱셈은 없기에 핵 컴퓨터에서 곱셈연산을 하기위해선 Math.multiply라는 운영체제의 함수가 필요합니다.

vm언어는 운영체제와 인터페이스가 가능합니다!

함수는 자신만의 작업스택과 메모리 세그먼트를 사용합니다.

예시

함수는 일반적으로 지역(local)변수와 인수(argument)변수들을 사용합니다.

메모리 세그먼트는 함수가 실행 될 때 할당되었다가, 함수가 반환될 때 반납되어야 합니다.

런타임동안 각 함수 호출들은 다른 호출과 독립적으로 실행되어야하고, 자신만의 스택과 지역 변수 및 인수 변수를 유지 및 관리해야합니다.

먼저 main함수는 3,8,5를 스택에 넣고 mult 2 함수를 실행합니다.

mult 2 함수는 실행되면 자신만의 독립적인 스택공간들을 가집니다.

함수의 0번줄 : argument세그먼트에 스택에 들어있던 2개의 인수 8,5가져오고, local 세그먼트는 인수를 2개로 받았기에 2개의 공간을 0으로 초기화 합니다.

함수의 1~4번줄 : 함수는 push constant 0, pop local 0, push constant 1, pop local 1 명령을 실행해 로컬 세그먼트를 0,1로 초기화 시킵니다.

함수의 7~8번줄 : 함수는 local 1의 값과 argument 1의 값을 함수의 private 스택에 추가합니다.

이후 연산이 수행되고

마지막에 20번줄에서 push local 0명령어를 통해 연산된 값 40을 함수의 private 스택에 추가합니다.

그 후 값은 caller로 반환되어 main함수의 스택에 값 40이 들어갑니다.

다른 예제도 간단하게 확인해 보겠습니다.

아래 예제에서는 main -> hypot -> mult 순서대로 함수가 호출되는데 이렇게 프로그램에 실행에 관련된 모든 함수를 개념적으로 가리키기 위해 이와같은 상황 및 함수들의 관계를 콜링 체인 (calling chain)이라고 부릅니다.

main 함수가 hypot을 실행하면 hypot 함수에 기존 stack에 있던 인자 3,4가 hypot 함수의 stack에 들어갑니다.

이후 hypot함수는 인자로 들어온 x(3)을 함수의 private 스택에 2번 넣고 mult 함소를 호출합니다.

mult함수에서는 local 세그먼트의 인덱스를 sum, i로 표기하고

16 ~ 19번 명령을 통해 초기화합니다.

연산이 수행되고 36번줄에서 확인해보면 multi함수의 private 스택에는 연산결과 9를 확인 할 수 있고 이 값은 hypot로 반환됩니다.

이후 hypot 함수의 private 스택에는 mult의 결과값인 9가 남고, 이후 yy도 동일하게 하여 9,16을 만듭니다.

Function Call And Return

함수가 호출될때와 종료될때에 대해 알아보겠습니다.

1. Sets arg

caller에서 함수를 호출하면 stack에는 먼저 callee로 전달될 인수(argument)들이 필요합니다.

현재 작업하고있는 스택의 바로 아래서부터 callee가 필요한 인수만큼 만큼 argument들의 주소가 할당됩니다.

2. Saves the caller's frame

callee가 호출되면 caller는 작업하던 상태를 보관하고 callee로 넘어가야합니다.

그 와중에 callee는 callee의 지역 변수, 매개변수, this, that과 같은 포인터가 사용되는데 이때 caller의 정보들에 덮어씌우면 안되기에

caller만의 정보를 저장해 두어야 한다. 이때 caller의 정보를 스택에 쌓아두는데 이 값들을 모두 합쳐 프레임이라고 부릅니다.

3. Jumps to execute callee

위와같은 작업이 끝나면 callee로 이동합니다.

이제 callee에서 어떤일이 일어나는지 알아보겠습니다.

1. Sets up the local segment of the called function

호출된 함수에 대한 지역 변수 세그면트(LCL)를 생성하고 값을 초기화 합니다.

2. Retuen

함수에 정의된 작업이 끝나면 응답을 반환해야합니다.

callee는 리턴값을 argument[0]에 저장합니다. (이렇게 하면 callee의 리턴값이 caller의 스택 가장 위에 들어가게 됩니다.)

이후 sp를 arg + 1로 조정해서, caller가 함수를 호출했던 반환 주소로 돌아갑니다.

그후 caller의 LCL, ARG, THIS, THAT을 복구합니다. (이 과정에서 callee의 LCL과 ARG는 사라짐)

마지막으로 return address로 jump합니다.

Global Stack (전역 스택)

위에서 하나의 caller와 callee를 살펴보았는데, 프로그램은 무수히 많은 caller와 callee쌍이 존재합니다.

이 모든 정보들 또한 stack에 존재하는데 이 스택을 Global Stack이라고 부릅니다.

Global Stack에서 현재 실행 중인 caller와 callee들을 block이라고 합니다.

callee가 종료되고 caller가 실행 되면서, 기존에 frame들과, callee에서 사용했던 값들은 이후 caller가 실행되며 값들이 덮어씌우면서 재사용 됩니다.

예제

고수준 코드를 컴파일하게 되면 vm코드가 생성됩니다.

그 과정에서 어떻게 스택이 사용되는지 알아보겠습니다.

vm코드를 순서대로 따라가 보면

push 3을 해서 global stack에 3이 들어갑니다.

이후 call factorical 명령이 실행되어 argument[0]이 3을 바라보게 하고,

main함수의 frame들을 저장합니다.

이제 f(3)의 명령어들이 실행됩니다.

push argument 0 (n) , push constant 1을 비교(eq)합니다.

같지 않기에 BASECASE로 이동하지 않습니다.

push argument 0 (n), push argument 0 (n), push constant 1, sub 가 실행되면서

stack에 3,2가 들어갑니다.

이제 f(2)가 호출됩니다.

새로운 callee가 생성됨에 따라, global stack에는 f(3)의 frame이 추가됩니다.

f(2)의 argument 세그먼트도 새롭게 생성됩니다.

f(2)는 f(3)과 argument만 다른 상태로 동일한 적업을 수행하고,

스택에 f(2)의 프레임, f(1)의 argument를 생성하며 f(1)이 시작됩니다.

하지만 f(1)에서는 eq명령에 따라 BASECASE로 jump되고 push constatn 1 명령이 실행되고 f(1)함수가 반환됩니다.

argument[0]에 f(1)의 리턴값(1)이 복사됩니다. f(2)와 f(3)도 동일하게 반환되면서 main함수는 최종 리턴값을 얻게됩니다.

vm 머신 정리

우리의 vm모델은 스택기반입니다.

push/pop 명령을 통해 스택과 메모리 세그만트 사이에 데이터를 전송하고, 분기와 함수를 이용하여 산술 및 논리 연산을 수행합니다.

vm번역기는 컴파일러가 생성한 vm언어들을 어셈블리어로 변경하는 프로그램입니다. (FileName.vm -> FileName.asm)

RAM에 지정된 메모리를 이용해서 vm의 스택을 표현하며, RAM 블록의 밑바닥은 고정된 기본 주소가 되고, 최상단은 스택에 따라 변화하게 됩니다.

따라서 고정 주소(stackbase)가 주어지면, 스택의 최상단 값 바로 뒤의 RAM 주소를 추적하는 스택포인터 (sp)를 통해 스택을 관리합니다. (push x 명령은 RAM[SP] = x, SP++, pop x명령은 SP-, x = RAM[SP] 와 같은 의사코드로 구현 가능)

vm프로그램은 잭과 같은 고수준 프로그램 언어로 생성되며,

잭 컴파일러를 적용하면 Test.jack 클래스의 파일들은 -> Test.vm으로 번역됩니다.

컴파일 이후 Main.jack 파일 내의 bar라는 이름의 생성자, 함수, 메서드들은 vm함수로 번역되며 vm함수는 전역적입니다.

그렇기에 함수의 이름은 Test.FuncName 처럼 고유한 이름이 됩니다.

프로그램의 진입점은 반드시 Main.jack이어야 하고, 이 파일에서 vm함수 하나는 이름이 Main.main이 됩니다.

vm프로그램이 실행을 시작할 때, 항상 실행되는 첫 번째 함수는 인수가 없는 Sys.init이라는 함수로 os의 일부분입니다.

이 os함수는 사용자 프로그램에서 진입점이 되는 함수를 호출하도록 되어있습니다.

Sys.init은 잭 프로그램에서는 Main.main을 호출합니다.

RAM활용

vm에서 RAM을 활용하는 방식은 아래와 같습니다.

세그먼트의 기본 주소들은 각각 LCL, ARG, THIS, THAT레지스터에 저장됩니다.

이 세그먼트에 접근하려면 push segument Name i라는 명령이 필요한데 이는 (base+i)RAM주소로 접근하라는 어셈블리 코드로 변경되어야 합니다.

부트스트랩 코드

핵 플랫폼에서는 RAM이 256부터 매핑되고, 실행을 시작하는 첫 vm함수가 OS함수인 Sys.init이어야 한다고 규정합니다.

ROM[0]주소에 SP=256이 실행되고 이후 call Sys.init 명령어가 실행됩니다.

운영체제의 일부인 Sys.init함수는 응용프로그램의 main함수를 호출하고 무한루프에 들어가게됩니다.

그리고 이 작업으로 번역된 vm프로그램이 실행됩니다.

프로그램 구조

책에서는 vm번역기는 3가지 모듈 VMTranslator, Parser, CodeWriter로 구현하기를 권장한다고 말합니다.

VMTranslator

Parser와 CodeWriter를 이용해서 번역 과정을 수행하는 메인 프로그램입니다.

입력 소스 파일명에 .vm파일을 받아 해당 파일을 파싱하기 위한 Parser모듈을 생성하고 번역된 어셈블리 명령어들을 출력할 기록파일 .asm을 만듭니다.

이후 파일 내 vm명령어들을 반복하는 루프를 실행해 명령을 번역합니다.

Parser

vm 파일의 파싱(구문 분석) 처리, 이 모듈은 vm 명령을 읽고 명령을 다양한 구성 성분으로 분석하고,

그 성분들에 편리하게 접근 하도록 도와줍니다. (분기 및 함수명령을 포함한 모든 vm명령을 처리)

간단하게 말하면 vm코드 파일을 읽고, 명령을 해석합니다

예를들어 아래와 같은 명령어가 있다면 'push constant 10' 같은 vm코드가 들어오면 명령유형 (push), 첫번째 인자 (constant), 두번쨰 인자 (10)을 CodeWriter에 전달합니다.

CodeWriter

파싱된 vm명령을 핵 어셈블리 코드로 변환합니다.

예를 들어 writePushPop (C_PUSH, 'local',2)를 호출하면 push local 2라는 vm명령을 구현하는 어셈블리 명령어들이 생성되어야 합니다.

함수 호출과 반환

함수를 호출하고, 함수를 반환받는 이벤트에서는 호출자(caller)의 관점과 피호출자(callee)의 관점이 있습니다.

두 관점 보두 call, function, return 명령어 처리에 기대되는 동작과 책임이 존재합니다.

call은 호출자의 스택을 프레임에 저장하고, 피호출자 실행으로 점프하는 코드를 실행합니다.

function은 피호출자의 지역변수를 초기화합니다.

return은 반환값을 호출자의 스택 최상단에 복사하고, 호출자의 세그먼트 포인터를 복원 후, 반환 주소 다음부터 실행하도록 점프하는 코드를 실행합니다.

vm번역기가 사용하는 특수기호 목록

SP와 LCL, ARG, THIS, THAT은 익숙하기에 생락하구..

R13-15s : 임시 저장용 레지스터. 보통 리턴 주소나 임시 데이터 저장 등에 사용됩니다.

Xxx.i : Xxx.vm 파일의 i번째 정적 변수는 어셈블리어에서 Xxx.i로 변환됩니다.

functionName : 함수 시작 지점을 나타냅니다.

functionName$ret.i : 함수에서 i번째 리턴 후 시작될 위치를 나타냅니다.

functionName$label : 함수 내부의 특정 위치를 나타냅니다. (조건문에서 분기할 때 사용)

vm코드 예시

function Main.main 0  

  push constant 3    
  push constant 4    
  call Multiply 2    // 프레임 및 리턴주소(Main.main$ret.1) 생성

  call CheckEven 1   // 프레임 및 리턴주소(Main.main$ret.2) 생성

  goto Main$End      // 프로그램 종료

function Multiply 0  
  push argument 0    
  push argument 1    
  mul                
  return             // (Main.main$ret.1)로 이동

// CheckEven 함수 (짝수 판별)
function CheckEven 0  
  push argument 0    
  push constant 2    
  mod                
  if-goto Main$Failure  // 나머지가 0이 아니면 실패 (홀수)
  goto Main$Success     // 나머지가 0이면 성공 (짝수)

// 성공 label
(Main$Success)   
  label Main$Success
  // 여기서 성공 처리
  goto Main$End

// 실패 label
(Main$Failure)   
  label Main$Failure
  // 여기서 실패 처리
  goto Main$End

// 프로그램 종료 label
(Main$End)  
  label Main$End

NandToTetris : 가상머신1-프로세싱-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Wed, 19 Feb 2025 23:46:06 +0900

가상 머신 패러다임

프로그램들은 컴퓨터에서 실행되려면 기계어로 번역되어야 합니다.

많은 고수준 언어들이 생겨남에따라, 동일하게 컴파일러들도 생겨났고 이러한 컴파일러들은 원본언어에 종속적이게 되었습니다.

현대에는 이 종속성을 분리하기 위해 전체 컴파일 과정을 두 단계로 나누었습니다.

첫 단계는 고수준 언어의 구문을 분석(parse)하여 그 명령들을 중간처리단계로 번역합니다. (컴파일러)

두 번째 단계에서는 이 중간 단계를 다시 대상 하드웨어의 기계어로 번역합니다. (VM번역기)

두 단계(컴파일러, vm번역기)를 이어주는 인터페이스를 가상 머신 (virtual machine)이라고 합니다.

고수준 언어가 기계어로 번역되는 과정

컴파일러가 고수준 코드를 중간 VM 명령으로 번역
vm 변역기가 중간 vm 명령을 기계 명령어로 번역

java로 예시를 들면 컴파일러인 javac가 .class코드를 생성합니다.

가상머신 jvm은 .class코드를 읽어 직접 기계어로 변환합니다.

(jvm은 어셈블리없이 바로 바이트코드 -> jvm에서 어셈블리어 변환 후 다시 기계어 변환)

vm방식으로 생성된 기계코드는 c에서 사용하는 고전적인 1단계 컴파일러에 비해 장황하고 복잡한 코드가 되어 다소 효율성이 저하됩니다.

하지만 프로세서가 최적화 되고 vm구현이 최적화 되어 크게 눈에 띄지는 않습니다.

물론 고성능이 필요한 응용프로그램이나 임베디드 시스템에서는 항상 보다 효율적인 코드가 필요합니다.

vm 추상화와 스택 머신

vm 명령은 고수준언어와 저수준언어의 인터페이스이기에 컴파일러가 적절히 구조화된 vm 코드를 생성할 수 있도록

충분히 '고수준'이면서 동시에 vm번역기가 효율적인 기계어 코드를 생성할 수 있도록 충분히 '저수준'이기도 해야합니다.

고수준, 저수준 언어를 인터페이스 하기 위해 가상환경을 제공해야하는데 이를 vm추상화라고 합니다.

vm추상화는 메모리 세그먼트와 스택 두가지 방법이 존재합니다.

vm추상화를 달성하기 위한 방법 중 하나로 스택을 사용하게 되면, 스택 머신이라는 추상적인 아키텍처를 중간 vm 언어의 기반으로 사용합니다.

두 방법의 차이는 아래와 같습니다.

메모리 : 모든값에 인덱스가 존재하며 접근 가능, 값을 읽을 때는 메모리 상태가 아무런 영향을 받지 않음, 메모리 주소에 값을 쓰기에 그 주소에 값이 덮혀쓰여짐
스택 : 최상단만 접근 가능, 최상단 값을 읽으려면 해당 값을 스택에서 삭제해야함, 최상단에만 값을 추가하며 나머지 값들은 변화 X

참고로 스택에 최상단 값 바로 아래 위치는 sp (stack pointer)라는 이름으로 참조합니다.

스택 머신

스택머신은 사실 우리에게 익숙한 자료구조 스택 그 자체입니다. 즉 컴퓨터에서의 추상적인 설계일 뿐입니다.

스택머신이 어떻게 메모리의 데이터와 관계되어 있는지 알아보겠습니다.

위에 그림과 같이 constant 17, 즉 상수 17을 스택에 넣는다면 스택에서는 값 17이 들어가고 sp는 스택의 다음 자리를 가리키게 됩니다.

이제 실제 메모리에서는 어떻게 스택머신이 구현되는지 알아보겠습니다.

메모리에서는 스택머신을 위한 몇가지 초기 설정들이 되어있습니다.

sp (stack pointer)는 RAM[0]를 의미합니다.
스택에 들어가는 데이터는 RAM[256]부터 시작합니다.

먼저 위에 그럼의 스택에는 이미 12, 5 두 데이터가 들어가 있기에 현재 스택포인터는 256 + 2 즉 258을 가리키고 있습니다.

여기 새로운 값 17이 추가되면 sp가 가리키는 위치 258에 17이 추가되고 sp의 값, RAM[0]의 값은 259로 업데이트 됩니다.

스택 산술

스택 머신에서 x op y와 같은 연산들은 아래와 같이 수행됩니다. (op는 +, - 등등)

1. 피연산자 x,y를 스택 최상단에서 꺼냅니다. (pop)

2. x op y를 계산합니다.

3. 계산된 값이 스택 최상단에 들어갑니다. (push)

스택 머신은 산술 및 논리 표현식이 아무리 복잡하더라도 스택 위에서의 단순한 연산들로 체계적으로 변환하고 계산할 수 있습니다.

따라서 고수준 산술 및 논리 표현식을 순차적인 스택 명령들로 번역하는 컴파일러를 만들 수 있다.

덧셈(add)과 부호반전(neg)을 처리하는 스택산술 과정

d = (2-x) + (y+9)의 스택 산술 과정

( x < 7 ) or (y == 8) 을 처리하는 논리 표현식 과정

가상 메모리 세그먼트

고수준 언어는 x,y,sum 같은 기호 변수를 지원합니다.
이러한 기호 변수들은 클래스 레벨에선 정적 변수, 인스턴스 레벨에서는 객체 필드 변수, 메서드 레벨에서는 지역 변수 또는 인수가 될 것 입니다.

하지만 가상 머신에서는 기호 변수가 존재하지 않습니다.

대신 변수들은 static, this, local, argument 같은 이름의 가상 메모리 세그먼트 내 항목들로 표현된다.

특히 컴파일러는 고수준 프로그램에서 나오는 첫번쨰 두번째 세번째 정적 변수들을
static 0, static 1, static 2 같은 식으로 매핑합니다.

그리고 다른 종류의 변수들도 비슷하게 this, local, argument 세그먼트로 매핑됩니다.

예를 들어 지역 변수 x와 필드 y가 각각 local 1과 this 3에 매핑된 경우, 컴파일러는 let x = y 같은 고수준 명령문을 push this 3, pop local 1로 번역합니다.

추가로 핵 vm 모델은 아래와 같은 8개의 메모리 세그먼트를 지원합니다.

vm 명령은 세그먼트 이름 다음에 인덱스(음수 X)를 사용하는 방법을 사용해 메모리 세그먼트에 접근합니다.

포인터 조작

핵 컴퓨터에서 메모리 세그먼트를 사용할때는 포인터를 이용한 조작이 많습니다.

D = *p라는 vm명령어는 핵 어셈블리어에서 아래와 같이 표현됩니다.

@p // p는 0와 동일합니다. 즉 A레지스터에 0값을 설정합니다.

A=M // RAM[0]의 값 257이 다시 A레지스터에 설정됩니다.

D=M // RAM[257]의 데이터 23을 D에 지정합니다.

핵 vm모델의 메모리 세그먼트 종류

총 8개의 메모리 세그먼트가 존재하며,

각각 세그먼트들의 정의와 주소는 아래 표와 같습니다.

argument : 함수의 인수를 나타냅니다.
local : 함수의 지역 변수를 나타냅니다.
static : 함수에서 볼 수 있는 정적 변수를 나타냅니다.
constant : 상수 변수 0,1,...,32767을 나타냅니다.
this, that, pointer, temp : 우리가 익숙한 그것들,,

핵 컴퓨터에서 RAM은 0~15는 레지스터, 16~255는 정적 변수, 256~2047은 스택 영역으로 사용됩니다.

이름	위치	내용
SP	RAM[0]	스택 포인터 주소, 최초 256으로 초기화
LCL	RAM[1]	local 메모리 세그먼트 기본주소
ARG	RAM[2]	argment 메모리 세그먼트 기본주소
THIS	RAM[3]	this segment의 기본주소
THAT	RAM[4]	that segment의 기본주소
TEMP	RAM[5-12]	temp segment를 저장
R13, R14, R15	RAM[13-15]	VM 번역기가 생성한 어셈블리 코드에서 별도의 변수가 필요할 때 사용하는 레지스터

각 메모리 세그먼트간 데이터 입출력 예시

stack머신은 아래와 같이 각 세그먼트들과 데이터를 전달받고 전달합니다.

예를들어 위와 같은 상황에서 let static 2 = argument 1과 같은 vm 명령을 작업을 해야한다면

스택에 push argument 1, pop static 2와 같은 명령이 필요합니다.

Local 세그먼트

로컬 세그먼트의 기본 주소(LCL)는 1015입니다.

LCL은 SP와 다르게 스택의 값이 변경되어도 값이 변하지 않습니다.

즉 LCL의 계속해서 최초주소 1015를 가지고 있습니다.

대신 pop/push local i 가 실행되면 addr=LCL + i를 하여 로컬 세그먼트 기본주소(1015)에 해당 로컬 변수의 번호를 더한 주소에 값을 넣거나 가져옵니다.

이후 *SP = *LCL+i, SP++/-- 연산을 진행합니다.

즉 RAM[LCL+i]의 값을 스택 포인터가 가리키고 있는 위치에다가 대입하고, SP를 ++/--합니다.

추가로 Argument, This, That 세그먼트들도 Local 세그먼트와 동일하게 동작합니다.

만약 위와 같이 pop local 2 명령이 실행 되면

메모리 관점에서는 스택의 최상단 값(*SP-1)을 꺼내(pop) RAM[LCL+2]에 저장시키고 SP를 1 감소시킵니다.

local pop 2 핵 어셈블리어로는 아래와 같이 동작 할 것 같습니다.. (R[13]~R[15]를 이렇게 쓰는지 확신이 없습니다 ㅠㅠ)

@LCL    // A = LCL
D=M     // D = RAM[1015]
@1      // A = 1
D=D+A   // D = 1015 + 2 = 1017

@R13    // 임시 저장소 사용 (RAM[13]에 local 2 주소 저장)
M=D     // RAM[13] = 1017

@SP     // A = SP
M=M-1   // SP--
A=M     // A = SP
D=M     // D = RAM[SP]

@R13    // A = R13 (저장된 local 2 주소 1017)
A=M     // A = 1017
M=D     // RAM[1017] = 스택에서 꺼낸 값

local push 1 는 아래와 같이 동작 할 것 같습니다.

@LCL    // A = LCL
D=M     // D = RAM[1015]
@1      // A = 1
A=D+A   // A = 1015 + 1 = 1016
D=M     // D = RAM[1016]

@SP     // A = SP
A=M     // A = RAM[0]
M=D     // RAM[256] = RAM[1016] (local 1 값 복사)

@SP     // A = SP
M=M+1   // SP++

Constant 세그먼트

Constant 세그먼트에서는 pop명령이 따로 존재하지 않습니다

Static 세그먼트

foo.vm 파일에 저장된 vm프로그램 내에 static i변수가 있다면, 어셈블리 기호 Foo.i로 변환합니다.

그 후 static 변수들은 RAM[16] ~ RAM[255] 사이에 vm명령이 들어오는 순서대로 매핑됩니다.

Temp 세그먼트

Temp 세그먼트는 RAM[5] ~ RAM[12] 사이에 매핑됩니다.

temp i에 대한 접근은 RAM[5+i]와 같은 방식으로 진행됩니다.

Pointer 세그먼트

this와 that의 주소를 저장하는 특수한 세그먼트입니다.
RAM[3]에 this의 주소, RAM[4]에 that의 주소가 저장됩니다.
this와 that이 가리키는 메모리 위치를 바꿀 때 사용됩니다.

즉, pointer 0 = this, pointer 1 = that이 됩니다.

this : 현재 객체(혹은 특정 메모리 영역)를 가리킬 때 사용

that : 다른 메모리 공간(배열 등)을 가리킬 때 사용

예를 들어 push pointer 0 (THIS의 주소를 스택에 저장)

라는 명령은 아래와 같이 처리 될 수 있고

// push pointer 0
@3     // A = pointer 0 (THIS)
D=M    // D = RAM[3] (THIS의 주소)

@SP    // A = 스택 포인터
A=M    // A = RAM[SP] (현재 스택의 위치)
M=D    // RAM[SP] = THIS의 주소 (스택에 저장)

@SP    // A = 스택 포인터
M=M+1  // SP++

push pointer 1 (스택에서 값을 꺼내 THAT의 주소로 저장) 은 아래와 같이 처리됩니다.

@SP    // A = 스택 포인터
M=M-1  // SP--
A=M    // A = RAM[SP] (스택의 최상단)
D=M    // D = RAM[SP] (스택에서 꺼낸 값)

@4     // A = pointer 1 (THAT)
M=D    // RAM[4] = 스택에서 꺼낸 값 (THAT이 가리키는 주소 변경)

NandToTetris : 어셈블러-밑바닥부터 만드는 컴퓨팅 시스템, 어셈블러 구현 X

겅겅겅 — Tue, 18 Feb 2025 23:48:27 +0900

해당 장 과제인 어셈블러 구현은

고수준 프로그래밍 언어로 구현하기에 포스팅에서 생략합니다!

어셈블러

모든 컴퓨터에는 명령어가 0과 1의 연속으로 작성되는 이진 기계어와 인간이 이해하기 쉬운 표현을 사용하여 명령어를 표현하는 어셈블리 언어가 있습니다.

두 언어 모두 정확히 동일한 작업을 수행하며 완전히 동등합니다.

하지만 어셈블리로 프로그램을 작성하는 것이 바이너리로 작성하는 것보다 훨씬 쉽고 안전합니다.

이러한 이점을 누리기 위해서는 누군가 심볼릭 프로그램을 컴퓨터에서 그대로 실행할 수 있는 바이너리 코드로 번역해 주어야 합니다.

이 번역 서비스를 어셈블러가 수행합니다.

어셈블리어는 2진 코드와 직접 대응되므로, 어셈블러를 구현하는 일은 그렇게 어렵지 않습니다.

다만 어셈블리 프로그램에서 메모리 주소를 기호로 참조하는 기능이 필요합니다.

이 기능은 기호 테이블(symbol table)이라는 일반적인 데이터 구조로 구현됩니다.

배경

기계어는 보통 두 가지 형식, 즉 기호와 2진 형식으로 정의됩니다.

예를들어 2진 명령어가 앞에 8개 비트는 load, 뒤에 8가 bit는 레지스터 R3을 나머지는 7을 나타낸다고 할때

각각의 의미들을 load, R3, 7과 같이 작성하면 자연스러울 것 입니다.

여기서 load같은 연산코드는 연상 기호라 부릅니다.

이러한 기호언어는 어셈블리, 어셈블리를 기계어로 변역하는 도구는 어셈블러라고 합니다.

기호

1. 레이블 : 어셈블리 프로그램은 코드 내 위치를 표시하기 위해 기호를 정의하고 사용합니다. (ex : LOPP, END)

2. 변수 : 어셈블리 프로그램은 기호 변수를 정의하고 사용할 수 있습니다. (ex : i, sum)

3. 선언 기호 : 어셈블리 프로그램은 미리 선언된 기호를 사용해서 컴퓨터 메모리 내의 특정 주소를 참조할 수 있습니다. (ex : SCREEN, KBD)

모든 기호들은 결국 각각 어떤 다른 주소를 의미하게됩니다.

이러한 기호들을 처리하는 작업들이 어셈들러에서 가장 중요한 기능입니다.

주석 및 레이블 선언은 아무런 코드도 생성하지 않습니다.

그 때문에 레이블 선언이 의사 명령어 (pseudo-instruction)이라고도 합니다.

핵 기계어 명세

어셈블리 핵 프로그램은 각 라인은 어셈블리 명령어, 레이블 선언 및 주석으로 되어있습니다.

어셈블리 명령어 : 기호 A명령어 또는 기호 C명령어
레이블 선언 : (xxx) 형식의 라인, xxx는 기호
주석 : 두 개의 빗금(//)으로 시작되는 라인

기호

선언기호, 레이블 기호, 변수 기호로 나뉩니다.

선언 기호

기호들의 값은 핵 RAM의 주소로 해석됩니다.

R0, R1, ... , R15는 각각 0, 1, ... , 15 를 가리킵니다.
Sp, LCL, ARG, THIS, THAT 은 각각 0,1,2,3,4 를 나타냅니다.
SCREEN, KBD는 각각 16384와 24576를 나타냅니다.

레이블 기호

의사명령어(xxx)는 프로그램의 다음 명령어를 저장하고 있는 ROM의 주소를 기호 xxx가 참조하도록 정의합니다.

변수 기호

기호 xxx가 선언기호가 아니거나, 레이블 선언으로 정의되지 않은 경우에는 변수로 취급됩니다.

변수는 등장한 순서대로 RAM주소 16에서 시작하는 RAM위치에 차례대로 매핑됩니다.

어셈블리-2진 코드 번역

어셈블러는 어셈블리 명령어 마다 다음을 수행합니다.

명령어의 필드들을 파싱한다.
각 필드마다 그에 대응하는 비트코드를 생성한다.
명령어에 참조 기호가 있으면, 그 기호를 숫자 값으로 해석한다.
생성된 비트 코드들을 조립하며 16개의 0 또는 1로 이루어진 문자열로 만든다.
조립된 문자열을 출력 파일에 기록한다.

기호 처리

어셈블리 프로그램에서는 기호 레이블을, 그 기호가 정의된 라인 앞부분에서도 사용 할 수 있습니다.

이를 코드를 처음부터 끝까지 두번 읽는 2패스 어셈블러로 구현합니다.

어셈블러가 1차로 코드를 읽을 때는 기호 테이블을 만들고, 레이블 기호들을 모두 테이블에 기록하며 아무런 코드도 생성하지 않습니다.

2차로 코드를 읽을 때 앞에서 만든 기호 테이블을 활용하여 변수 기호들을 처리하고 2진 코드를 생성합니다.

자세한 내용은 아래와 같습니다.

초기화
어셈블러는 기호 테이블을 만들고, 선언 기호와 그 기호에 할당된 값들로 테이블을 초기화합니다.

1 패스
어셈블러는 줄 번호를 추적하면서 한 줄씩 전체 어셈블리 프로그램을 훑는다.

이 줄 번호는 0에서 시작하며 A-명령어나 C-명령어를 만날 때 마다 그 값을 1씩 증가시키며,
주석이나 레이블 선언이 나오면 값을 그대로 둡니다.

어셈블러는 레이블 선언 (xxx)가 나올 때 마다 기호 테이블에 새 항목을 추가하고,
기호 xxx에 현재 줄 번호 + 1 값을 연결시킵니다. (ROM의 주소가 된다.)

1 패스가 끝나면 프로그램의 모든 레이블 기호가 그에 대응하는 값과 함께 기호 테이블에 추가됩니다.

2 패스
어셈블러는 전체 프로그램을 다시 훑으며 각 라인을 다음과 같이 파싱합니다.

먼저 기호가 있는 A명령어 (@xxx에서 xxx가 기호)를 만날 때 마다, 기호 테이블에서 xxx를 조사하고
테이블에 그 기호가 있으면 어셈블러는 그 기호를 대응하는 숫자값으로 교체하고 해당 명령어를 번역합니다.

없으면 그 기호는 새 변수라는 뜻이므로, 어셈블러는 기호 테이블에 <xxx, value> 항목을 추가하는데,
여기서 value는 변수를 위해 RAM 공간 내에서 다음 번으로 사용 가능한 주소를 뜻합니다.

그리고 이 주소를 이용하여 해당 명령어의 번역을 완료합니다.

변수를 저장하기 위해 지정된 RAM 공간의 주소는 16부터 시작하며,
코드에 새 변수가 나타날 때 마다 1씩 증가합니다.

NandToTetris-Hardware simulator / 컴퓨터 아키텍쳐-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Thu, 13 Feb 2025 21:34:38 +0900

폰 노이만 구조

튜링기계는 간단한 추장석 컴퓨터 모델로, 주로 이론 컴퓨터 과학에서 계산의 논리적 기초를 분석하는 데 활용됩니다.

반면 폰 노이만 기계는 모든 현태 컴퓨터 플랫폼을 구성하는 실제 모델로서 폰 노이만 구조는 메모리 장치와 통신하고, 입력 장치에서 데이터를 받고, 출력 장치로 데이터를 내보내는 중앙 처리 장치(CPU)를 바탕으로 합니다.

컴퓨터가 조작하는 데이터 외에 컴퓨터가 수행할 작업을 지시하는 명령어도 메모리에 저장된다는 개념입니다.

메모리

메모리는 물리적관점과 논리적관점에서 바라 볼 수 있습니다.

물리적으로는 주소를 지정 할 수 있는 고정된 크기의 레지스터들을 선형적으로 배열한 것 이며, 레지스터들은 각각의 값을 가집니다.

논리적으로는 데이터 저장과 명령어 저장이라는 두가지 용도로 사용됩니다.

명령어와 데이터 모두 동일한 방식, 비트 열로 표현됩니다.

데이터가 저장되는 전용 메모리 영역은 데이터 메모리 (data memory), 명령어가 저장되는 전용 메모리 영역은 명령어 메모리(instruction memory)라고 합니다.

폰 노이만 구조를 따르는 모델중에서 데이터 메모리와 명령어 메모리가 필요에 따라 물리적으로 동일한 주소공간에서 동적으로 할당 및 관리되는 모델도 존재합니다.

또 다른 모델은 두 메모리가 개별 주소공간을 가집니다.

두 모델 모두 장단점이 존재합니다.

메모리에서 특정 메모리 레지스터에 접근하려면 레지스터의 주소가 필요합니다.

이 작업을 주소지정 (addressing)이라고 합니다.

데이터 메모리

변수, 배열, 객체와 같은 개념은 모두 2진 숫자열로 변환되어 데이터 메모리에 저장됩니다.

주소지정을 통해 데이터들의 개별적인 읽기, 쓰기작업을 할 수 있습니다.

명령어 메모리

고수준 프로그램은 컴퓨터에서 실행되기 전에 먼저 대상 컴퓨터의 기계어로 변역되어야 합니다.
고수준 명령문들은 항상 하나 이상의 저수준 명령어로 번역 되어서 2진, 또는 실행 가능한 버전 프로그램이라는 파일에 2진 값으로 기록됩니다.

프로그램을 실행하려면 먼저 대용량 저장 장치에서 2진 버전 프로그램을 불러온 후
그 명령어를 컴퓨터의 명령어 메모리에 직렬화해야 합니다.

순수한 컴퓨터 아키텍처 관점에서 프로그램을 컴퓨터 메모리에
어떻게 불러오는지는 외부의 문제로 취급합니다.

중앙 처리 장치 : CPU (Central Processing Unit)

CPU는 현재 실행 중인 프로그램의 명령어를 실행하는 일을 합니다.
각 명령어는 CPU에 수행할 계산, 접근할 레지스터, 다음에 불러와서 실행할 명령어를 알려줍니다.
CPU는 산술 논리 장치, 레지스터 집합, 제어 장치를 활용해서 이 작업들을 실행합니다.

ALU(산술 논리 장치)

ALU 칩은 컴퓨터에서 지원하는 모든 저수준 산술 및 논리 연산을 수행하는 장치입니다.
일반적인 ALU는 주어진 두 값을 더하거나, 비트 단위 And를 계산하거나, 두 값이 동일한지 비교하는 일 등을 수행하며,
설계에 따라 ALU가 지원하는 함수가 정해집니다.

레지스터

CPU는 연산 도중에 중간 값을 임시로 저장해야 하는 경우가 많습니다.
이론적으로는 이 값들을 메모리 레지스터에 저장할 수 있지만, CPU와 RAM은 별개의 칩이기에 때문에 신호가 이동하려면 거리가 멀다는 단점이 있습니다. 이때 발생하는 신호 지연을 기아상태(stavation)라고 합니다.

기아 상태를 방지하고 성능을 향상시키기 위해 일반적으로 CPU에는 프로세서에서 곧바로 접근 가능한 메모리 역할을 하는
고속 레지스터들을 적은 용량으로 탑재합니다. 이 레지스터들은 다양한 용도로 활용됩니다.

데이터 레지스터 : CPU의 단기 기억 메모리로 CPU계산의 중간값을 임시로 저장할 떄 사용됩니다.
주소 지정 레지스터 (Addressing Register) : CPU가 메모리접근을 위해 사용하는 레지스터입니다. 명령어에 주소가 포함되지 않는 경우 사용합니다.
프로그램 카운터 : 다음에 불러와서 실행해야하는 명령어의 주소를 저장하는 레지스터입니다.
명령어 레지스터 : 현재 명령어를 저장합니다.

일반 컴퓨터에서는 레지스터가 많이 존재하지만 우리가 만들 HACK에는 어드레스 레지스터, 데이터 레지스터 그리고 프로그램 카운터 3개 입니다.

제어

메모리부터 프로그랭 명령을 순차적으로 꺼내 해독하고, 해석에 따라서 명령어 실행에 필요한 제어 신호를 기억장치, 연산장치, 입출력 장치 등으로 보내는 장치입니다. (프로그램 카운터(PC), 명령 해독기, 부호기, 명령 레지스터 등으로 구성됩니다.)

컴퓨터 명령어는 미리 정의되고 구조화된 마이크로코드의 집합으로,

마이크로코드는 여러 장치에 해야 할 일을 알려 주는 1개 이상의 비트열입니다.

따라서 명령어는 실행되기 전에 마이크로코드로 디코딩되어야 합니다.

그 후 각 마이크로 코드는 CPU 내에 지정된 하드웨어 장치(ALU, 레지스터, 메모리)로
전달되어, 전체 명령어가 실행되기 위해 장치가 수행해야 할 동작들을 알려줍니다.

인출-실행 (fetch-execute cycle)

프로그램이 실행되는 각 주기마다 CPU는 명령어 메모리에서 2진 기계 명령어를 인출하고, 디코딩하고, 실행합니다.

CPU가 실행할 명령어는 메모리에 존재하고, CPU는 Program Counter(PC)를 통해서 다음번에 실행할 명령어를 알 수 있습니다.

실행할 명령어는 주소 버스를 통해 주소 지정 레지스터 (addressing register)에 copy됩니다. (fetch)

이후 명령어 레지스터가 해당 명령어를 읽고 디코딩하여 ALU, 데이터 레지스터 등을 이용하며 메모리와 상호작용 하며 적절하게 명령을 처리합니다. (execution)

하지만 fetch-execution 사이클에는 충돌 문제가 존재합니다.

fetch와 execution이 동시에 일어날 때, fetch 단계에서 pc의 값을 업데이트하는 동안, execution 단계에서 ALU가 연산을 진행하는 중 동일하게 pc에 값에 접근해야할 때 충돌이 일어납니다.

예를들어 execution 단계에서 조건부 분기처리나 jump와 같은 명령어가 있있다면 execution이 끝날 때

pc값이 업데이트 되어야 합니다.

이 때 멀티플렉서(Mux)를 통해 충돌을 방지합니다.

Mux를 통해 선택된 명령어는 IR로 이동하여 실행됩니다. (선택되지 않았던 명령어도 IR로 같이 가서 다음 주기 때 실행됩니다.)

입력과 출력 (메모리 매핑 I/O)

수많은 I/O장치를 컴퓨터와 통신할 수 있도록 컴퓨터는 수많은 장치들을 동일하게 처리하는 기법이 필요합니다.

이를 메모리 매핑 I/O라 합니다.

I/O장치와 컴퓨터가 연결되면 빈 메모리에 해당 장치가 사용할 공간이 할당되며, 일종의 '메모리 맵' 역할을 하는 전용 메모리 영역을 할당합니다.

이러한 작업은 보통 I/O장치의 installer 프로그램과 디바이스 드라이버(device driver)가 담당합니다.

입력장치에 변동이 존재할 때 RAM에 해당 내용을 기록하고,

CPU는 RAM에서 해당 데이터를 받아와 메모리 맵(RAM)에 저장하거나 연산하는 등 상황에 맞게 처리합니다.

I/O 장치는 RAM에서 해당 데이터를 받아와 화면에 출력하는 등 적절하게 동작합니다.

이와 같은 방식으로 I/O장치의 종류와 무관하게 사용이 가능합니다.

핵 하드웨어 플랫폼

이제 핵 하드웨어 플랫폼에 대해 정리하려 합니다.

16bit 폰 노이만 기계로 CPU, 명령어메모리 및 데이터메모리 그리고 두개의 메모리 매핑 I/O 장치(외부장치)인 스크린과 키보드로 구성됩니다.

추가로 핵 플랫폼에서 명령어 메모리는 프로그램이 미리 기록된 ROM 칩으로 물리적으로 구현됩니다.

CPU

핵 기계어로 작성된 명령들을 실행하도록 설계되었습니다.

ALU와 데이터 레지스터(D), 주소 레지스터(A), 프로그램 카운터(PC)로 구성되며,

CPU는 실행을 위한 명령어를 인출해 오는 명령어 메모리(RAM)와, 데이터 값을 읽거나 쓰는 데이터 메모리(ROM)에 연결됩니다.

D는 데이터를 저장하고, A는 데이터, RAM/ROM 주소 등을 저장합니다.

rom은 pc값에 따라 계속 해서 명령어를 출력합니다. 여기서 출력되는 명령어가 CPU의 현재명령어가 됩니다.

A명령어의 경우 16bit명령어는 A레지스터에 그대로 로드되는 2진값(0--- ---- ---- ---- )으로 취급되며. C명령어는 CPU내의 다양한 칩들이 수행되는 여러 마이크로 연산을 가리키는 제어비트(1xxa cccc ccdd djjj)로 처리됩니다.

추가로 C 명령어의 목적지가 M이면 writeM은 쓰기 명령을 위해 1이되고, 그렇지 않으면 0이되고, ALU의 결과는 outM으로 나갑니다.

M이 아니라면 writeM은 0으로 설정되고, outM은 아무 값이나 될 수 잇습니다.

reset이 1이면 pc를 0으로 설정합니다.

fetch-execute cycle 을 통해 CPU가 하는 전반적인 일들을 설명 할 수 있습니다..

execute : pc를 통해 현재 명령어가 여러 칩에 전달됩니다.

주소명령어라면 A 레지스터에 값이 전달되고, 계산 명령어라면 ALU와 레지스터가 명령을 수행합니다.

fetch : ALU의 출력과 jump bit을 비교해 조건이 틀리면 PC++, 조건이 맞으면 PC = A (A로 jump) 를 수행합니다.

다음 CLK때는 PC가 가리키는 명령어가 ROM의 출력이 된다.

데이터 메모리

이 칩은 기본적으로 세 개의 16비트 칩 (RAM16K, 스크린, 키보드) 부품으로 되어있습니다.

RAM = RAM16K + 스크린(RAM8K) + 키보드(레지스터, 읽기전용)

- RAM16K(16K 레지스터 RAM 칩, 범용 데이터 저장소)

- Screen(내장형 8K RAM 칩, 스크린 메모리 맵, 0x4000-0x5FFF)

- Keyboard(내장형 레지스터 칩, 읽기전용, 키보드 메모리 맵, 0x6000)

RAM16K

address에 주소를 통해 out으로 데이터가 출력됩니다.

in에 값(value), load Bit 1을 설정하면 해당 주소에 전달한 값이 저장됩니다.

데이터메모리는 기본적인 범용 데이터 저장공간, 메모리 맵을 통한 I/O 장치를 위한 영역이 존재합니다.

명령어 메모리

ROM32K라고도 불립니다.

0000 0000 0000 0000 ~ 0111 1111 1111 1111 2^15(32K)만큼 접근할수 있고,

한 레지스터가 16비트이기에 출력은 16비트 크기를 가집니다.

쓰기 작업을 위한 in이나 load 단자는 존재하지 않습니다.

입력/출력

화면, 키보드와 같은 I/O장치는 데이터 메모리 RAM에 매핑되고, 클럭마다 반영됩니다.

핵 컴퓨터 플랫폼에서는 스크린 메모리 맵과 키보드 메모리 맵은 Screen과 Keyboard라는 2개의 내장형 칩으로 구현됩니다.

스크린

16비트 레지스터로 된 8K 메모리 칩으로 구현되며, address와 load 입력을 받습니다.

스크린 공간이 8K이기에 주소가 13비트 입력으로 되어있습니다.

칩에 기록한 Bit은 픽셀로 표시됩니다.

키보드

키보드 베이스 어드레스의 위치에 있는 레지스터 하나의 값으로 키보드 입력을 나타내기에,

입력 값이나 주소가 필요없습니다.

키보드에서 키가 눌리면 Keyboard 칩의 output으로 키에 해당하는 문자의 16비트 코드를 출력하고, 아무것도 눌리지 않으면 칩은 0을 출력합니다.

컴퓨터

Hack 시스템의 최상위 칩입니다.

CPU, RAM, ROM, 스크린, 키보드로 구성되어있습니다.

프로그램의 실행을 위해 rom에 미리 Load 해야하고, reset이 0이면 프로그램 실행, reset이 1이면 프로그램을 초기화합니다.

CPU구현

실제 구현에 앞서 잠깐 CPU가 어떤일을 하는지 먼저 정리해보려합니다.

1. 디코딩

먼저 명령어가 들어오는 부분부터 보면

들어오는 명령어가 A명령어인지 C명령어인지 op-code를 통해 구분하는 디코딩작업을 수행해야합니다.

2. 명령어 실행

A명령어의 경우 MSB를 제외한 15비트는 그대로 A 레지스터에 로드되고,

이후 A레지스터의 출력은 M으로 전달됩니다.

C명령어의 경우 111accccccccdddjjj 6개의 제어 비트 ccccccc와 a로 선택된 연산을 수행하고, ddd로 지정한 곳에 연산 결과를 저장합니다.

a비트는 ALU 입력이 A 레지스터 값에서 올지, 아니면 입력된 M 값에서 올지 결정하는 비트입니다.

cccccc 비트는 ALU에서 어떤 함수가 계산될지를 가리키고, ddd 비트는 어떤 레지스터가 ALU 출력을 받아야 할지 지정합니다.

jjj비트는 다음에 인출할 명령어를 결정합니다.

000이 아닌 경우 연산 결과에 따라서 jjj의 조건(0과같거나, 크거나, 작거나 등)에 따라 어드레스 레지스터에 입력된 명령어 주소로 점프합니다.

3. 명령어 가져오기

PC는 일반적으로 다음 순서의 명령어의 주소를 정하고 출력한다. ( PC(t)=PC(t-1)+1 )

하지만 goto 연산(분기문)의 경우 A 레지스터에 이동할 주소를 저장한 뒤 jump 명령어를 사용하면 됩니다.

( If jump(t) then PC(t)=A(t-1) else PC(t)=PC(t-1)+1 )

즉 레지스터의 출력을 PC의 입력으로 연결시키고, jump를 해야할 때 PC의 load를 활성시키켜 PC에 다음명령어를 지정해주면 됩니다.

추가로 프로그램을 종료하려면 reset Bit을 set하여 PC의 값을 0으로 만들어야합니다.

CHIP CPU {
    IN inM[16],          // 데이터 메모리에서 읽은 값 (M=A인 경우)
        instruction[16], // 현재 실행할 명령어 (ROM에서 가져옴)
        reset;           // 프로그램을 처음부터 실행할지 여부

    OUT outM[16],        // 데이터 메모리에 저장할 값
        writeM,          // 데이터 메모리에 쓰기 여부
        addressM[15],    // 데이터 메모리 주소
        pc[15];          // Program Counter 값 (다음 명령어 주소)

    PARTS:
    
    // 명령어의 최상위 비트를 반전하여 A-명령어인지 C-명령어인지 판별 (A-명령어면 ni=1, C-명령어면 ni=0)
    Not(in=instruction[15],out=ni);
    
    // A-명령어이면 instruction 값을 선택하고, C-명령어이면 outtM 값을 선택하여 A 레지스터에 저장할 값 결정
    Mux16(a=outtM,b=instruction,sel=ni,out=i);
    
    // A 레지스터: A-명령어일 경우 값을 저장하고, 해당 값의 하위 15비트를 addressM에 출력 (메모리 주소로 사용됨)
    Or(a=ni,b=instruction[5],out=intoA);
    ARegister(in=i,load=intoA,out=A,out[0..14]=addressM);

    // C-명령어에서 A 레지스터 또는 메모리 값을 선택하여 ALU의 입력으로 전달
    And(a=instruction[15],b=instruction[12],out=AorM);
    Mux16(a=A,b=inM,sel=AorM,out=AM);
    
    // ALU 실행: 입력된 x(D 레지스터)와 y(A/M 레지스터)를 기반으로 연산 수행, 결과를 outM에 출력
    ALU(x=D,y=AM,zx=instruction[11],nx=instruction[10],zy=instruction[9],ny=instruction[8],f=instruction[7],no=instruction[6],out=outtM,out=outM,zr=zr,ng=ng);

    // C-명령어의 D 레지스터 저장 비트를 확인하여 D 레지스터 업데이트 여부 결정
    And(a=instruction[15],b=instruction[4],out=intoD);
    DRegister(in=outtM,load=intoD,out=D);

    // C-명령어의 메모리 쓰기 비트를 확인하여 writeM 결정 (1이면 메모리에 쓰기 수행)
    And(a=instruction[15],b=instruction[3],out=writeM);

    // 점프 로직: 조건을 판별하여 PC를 업데이트할지 결정
    Not(in=ng,out=pos); // 음수 여부 반전
    Not(in=zr,out=nzr); // 0 여부 반전
    And(a=instruction[15],b=instruction[0],out=jgt); // JGT 비트 체크
    And(a=pos,b=nzr,out=posnzr); // 양수이며 0이 아닐 경우
    And(a=jgt,b=posnzr,out=ld1); // 점프 조건 충족 시 ld1 활성화

    And(a=instruction[15],b=instruction[1],out=jeq); // JEQ 비트 체크
    And(a=jeq,b=zr,out=ld2); // 0일 경우 점프 조건 충족 시 ld2 활성화

    And(a=instruction[15],b=instruction[2],out=jlt); // JLT 비트 체크
    And(a=jlt,b=ng,out=ld3); // 음수일 경우 점프 조건 충족 시 ld3 활성화

    // ld1 (JGT) 또는 ld2 (JEQ) 활성화 여부 확인
    Or(a=ld1,b=ld2,out=ldt);
    // ld3 (JLT) 또는 이전 결과(ldt) 활성화 여부 확인
    Or(a=ld3,b=ldt,out=ld);

    // PC 업데이트: 점프 조건이 충족되면 A 레지스터 값으로 설정, 그렇지 않으면 1 증가
    PC(in=A,load=ld,inc=true,reset=reset,out[0..14]=pc);
}

메모리 구현

CHIP Memory {
    IN in[16], load, address[15];
    OUT out[16];

    PARTS:
    DMux(in=load, sel=address[14], a=loadRAM, b=loadScreen);
    RAM16K(in=in, load=loadRAM, address=address[0..13], out=outRAM);
    Screen(in=in, load=loadScreen, address=address[0..12], out=outScreen);
    Keyboard(out=outKeyboard);
    Mux4Way16(a=outRAM, b=outRAM, c=outScreen, d=outKeyboard, sel=address[13..14], out=out);
}CHIP Memory {
    IN in[16], load, address[15];  // 16비트 데이터 입력, 쓰기 신호(load), 15비트 주소 입력
    OUT out[16];                   // 16비트 데이터 출력

    PARTS:
    // address[14] 값에 따라 load 신호를 RAM 또는 Screen으로 분배
    DMux(in=load, sel=address[14], a=loadRAM, b=loadScreen);
    
    // RAM (16K 메모리 블록)
    RAM16K(in=in, load=loadRAM, address=address[0..13], out=outRAM);
    
    // Screen 메모리
    Screen(in=in, load=loadScreen, address=address[0..12], out=outScreen);
    
    // 키보드 입력을 받아 outKeyboard에 출력
    Keyboard(out=outKeyboard);
    
    // address[13..14]에 따라 4개의 데이터 소스 중 하나를 선택하여 out으로 출력
    // a, b -> RAM, c -> Screen, d -> Keyboard
    Mux4Way16(a=outRAM, b=outRAM, c=outScreen, d=outKeyboard, sel=address[13..14], out=out);
}

컴퓨터 구현

최상위 Computer 칩은 CPU, MEMORY, ROM32K 칩으로 구현됩니다.

- 사용자가 reset 입력을 활성화하면, CPU의 pc에서는 0이 출력되고 프로그램의 첫 번째 명령어를 출력합니다.

- CPU는 출력된 명령어를 실행하며, 필요에 따라 적절한 레지스터를 읽고씁니다. 또 다음에 어떤 명령어를 실행할지 결정합니다.

- 다음 명령어가 정해지면 해당 명령어의 주소를 pc 출력으로 내보낸다. (CPU의 PC 출력은 명령어 메모리의 address 입력으로 연결)

- 메모리로 전달된 다음 명령어는 CPU의 instruction 입력으로 연결되어서 fetch-execute cycle을 마무리합니다.

CHIP Computer {

    IN reset;  // 프로그램을 처음부터 실행할지 여부를 결정하는 입력 신호

    PARTS:
    
    // ROM : 프로그램 명령어를 저장하는 32K 크기의 읽기 전용 메모리, PC값을 주소로 명령어를 가져옴
    ROM32K(address=pc, out=instruction);

    // CPU : 명령어를 실행하고, 메모리 및 PC값을 업데이트
    CPU(inM=inM, instruction=instruction, reset=reset, outM=outM, writeM=writeM, addressM=addressM, pc=pc);

    // RAM : CPU 연산결과 저장 및 필요 데이터를 가져옴
    Memory(in=outM, load=writeM, address=addressM, out=inM);
}

NandToTetris-Hardware simulator / 기계어-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Wed, 5 Feb 2025 23:00:50 +0900

기계어

하드웨어(기계)를 제어하는 언어이며, 하드웨어와 소프트웨어 사이 가장 중요한 인터페이스입니다.

CPU가 명령을 처리 할 때 사용되는 언어로 2진수로 되어있습니다.

모든 기계어는 기본적인 산술연산과, And, Or, Not같은 논리연산들을 위한 명령어들을 지원합니다.

기계어에서 수행되는 많은 작업들은 특정메모리에 접근하여 메모리를 조작하는 것과 관련이 있습니다.

아래 예시는 완전한 기계어(2진수)가 아니라 어셈블리어 입니다.

어셈블리어는 어셈블러에 의해 기계어로 변경되어 하드웨어에 전달됩니다.

CPU는 메모리에 올라가있는 명령들을 순서대로 실행하지만,

특정 명령어로 점프하거나, 반복해야하는 경우도 있습니다.

이러한 분기동작을 위한 기능도 존재합니다.

(R1, R2는 레지스터를 의미합니다.)

핵 기계어

책에서 다루는 핵 컴퓨팅 시스템은 폰 노이만 구조를 따르며

16bit 컴퓨터입니다. 즉 CPU와 메모리 장치가 16bit값들을 처리하고 저장하도록 설계되었다는 의미입니다.

메모리

RAM과 ROM 두개의 메모리를 사용하며 두 메모리 모두 폭(width)이 16bit , 주소공간은 15bit입니다.

데이터 메모리(RAM)는 프로그램이 조작하는 데이터(2진수)를 저장하고

명령어 메모리(ROM)는 프로그램의 명령어들을 저장합니다.

각각의 주소공간 (2^15) 마다 width (16bit) 만큼의 데이터를 저장 할 수 있어 총 64kb 의 데이터를 저장 할 수 있습니다.

메모리에 주소는 0 ~ 32k -1까지 존재합니다.

즉 주소지정 가능한 16bit 레지스터가 일렬로 32k -1까지 나열되어있어 있다고 생각하면 편합니다.

레지스터

3개의 16bit 레지스터 데이터 레지스터(D), 주소 레지스터(A), 선택된 데이터 메모리 레지스터(M)이 있습니다.

데이터 레지스터(D)는 16bit값을 저장합니다.

주소 레지스터(A)는 RAM 혹은 ROM의 주소를 지정합니다.

핵 기계어 문법

A-명령어 (op-code가 0일때)

A레지스터에 15bit값을 지정합니다.

레지스터에 들어오는 16bit중 가장 왼쪽 비트는 연산코드(op-code)를 나타내고 나머지 음수가 아닌 이진수를 가리키는 15bit를 A레지스터에 저장합니다.

A레지스터에 값을 저장하면 선택된 레지스터의 주소는 선택된 데이터 메모리 레지스터(M)에도 설정됩니다.

이후 M을 참조하여 다음 C명령어에서 해당 레지스터를 조작 할 수 있게 합니다.

변수지정 : @xxx

핵 명령어 @xxx는 A 레지스터에 값 x를 지정합니다.

A레지스터에 지정한 값 xxx가 주소로 사용될지, 값으로 사용될지는 다음에 나오는 명령어에 따라 달라집니다.

// 예시1 : 데이터 레지스터에 상수값 입력
@23 // A레지스터의 값을 23으로 설정
D=A // 레지스터(D)에 레지스터(A)값 저장 D=23

//예시2 : 주소값 사용
@17 // A레지스터의 값을 17로 설정
M=0 // RAM[17]을 0으로 설정, RAM[17] = 0

// 예시3 : RAM[100]= 17
@17
D=A
@100
M=D 

// 예시 4 : RAM[100] = RAM[200]
@100
D=M
@200
M=D

C-명령어 (op-code가 1일때)

무었을 계산할지 (comp), 어디에 계산된 값을 저장할지(dest), 그 다음 무엇을 할지(jump)에 대한 명령어입니다.

16bit 중 맨 왼쪽은 연산코드(op-code)

다음 두 비트는 사용되지 않는 비트 (관례상 1로 표시)

다음 7개 비트는 comp

다음 3개 비트는 dest

맨오른쪽 3개의 비트는 jump를 나타냅니다.

comp (acccccc)

7비트로 ALU가 수행할 연산을 결정하는 comp 비트입니다.

첫번째 ALU입력은 D레지스터에서 받습니다.

두번째 ALU입력은 A레지스터(a비트가 0일때)나 M레지스터(a비트가 1일때)에서 입력을 받습니다.

comp에서는 a가 0일때와, 1일때 수행하는 연산이 따로 나눠져있습니다.

dest (ddd)

3비트로 ALU 연산 결과를 담을 목적지입니다.

저장하지 않을지(null), M에 담을지(RAM[A]), D 레지스터에 담을지, A레지스터 D레지스터 둘다에 연산 결과를 담을지 결정합니다.

jump (jjj)

jump 비트는 연산 결과에 따라 A레지스터에 지정된 주소의 명령어를 가져옵니다. (점프)

000인경우 점프 없이 다음 명령어를 불러오고,

001 인경우 COMP의 연산 결과가 0보다 크면 점프합니다.

무조건 점프 JMP(111)는 관례상 0;JMP로 정의됩니다.

(A 레지스터를 사용할 때 충돌 방지필요)

핵 컴퓨터는 RAM과 ROM의 주소를 지정할 때 주소 레지스터 하나만 사용됩니다.
따라서 @n 명령어를 실행할 때 RAM[n], ROM[n]이 모두 선택됩니다.
그래서 이어지는 C-명령어가 M을 조작하거나, 점프를 수행하게 된다.
이때 충돌을 피하기 위해서는 M에 대한 참조를 포함하는 C-명령어에서는 점프를 지정하지 않도록 하고,
점프를 지정한 C-명령어에서는 M을 참조하지 말아야 합니다.

예제

1. 두 레지스터(R1, R2)에 값들을 더하고, 그 합에 17을 더한 후 그 결과를 세번째 RAM레지스터에 저장

각 명령어의 의미는 아래와 같습니다.

1. @0 // RAM [0] 지정

2. D=M // 먼저 RAM[0]의 값을 D레지스터로 옮긴다.

3. @1 // RAM[1] 지정

4. D=D+M // 이후 RAM[1]을 선택하여 D레지스터에 들어있는 값과 현재 선택된 메모리 레지스터의 값을 더해 D레지스터에 저장한다.

5. @17 // A레지스터에 정수 17 입력

6. D=D+A // D레지스터에 A레지스터의 값 더함

7. @2 // RAM[2] 지정

8. M=D // 선택된 레지스터 RAM[2]에 D레지스터의 값 (17)을 입력

2. 1+2+3+ ... + n을 계산하시오 (n은 첫번째 레지스터의 값, 두번째 RAM레지스터에 결과 출력)

// i, sum 변수 초기화
    @i
    M=1
    @sum
    M=0
// 반복문 시작
(LOOP)
    @R0 // 반복할 횟수 N이 들어있음
    D=M
    @i
    D=D-M // D = D - i (D는 R0 - i)
    @STOP
    D;JLT // i가 R0보다 크면 STOP으로 점프 (반복 종료)    
    @sum
    D=M
    @i
    D=D+M
    @sum
    M=D
    @i
    M=M+1
    @LOOP 
    0;JMP // 다시 LOOP로 돌아가서 계속 반복
(STOP)
    @sum
    D+M
    @R1
    M=D
(END)
    @END
    0;JMP

3. for i=0...n {do somthing with arr[i]} 를 구현해보자

    @n
    M=0 // RAM[n] = 0
(LOOP)
    @n
    D=M // D = 0
    @R1 // 특정값
    D=D-M // R1과 D의 차 계산
    @END
    D;JEQ // R1과 D가 같은지 비교 -> D가 0일 경우 @END로 점프    
    @R0
    D=M // D = RAM[0] 
    @n
    A=M+D // RAM[n]과 D(R0) 값을 더한 결과 A에 지정
    M=-1  // RAM[A]에 -1 저장     
    @n
    M=M+1 // n값 1증가    
    @LOOP
    0;JMP
(END)
    @END
	0;JMP

NandToTetris-Hardware simulator / 레지스터, 메모리, PC 실습-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Thu, 30 Jan 2025 22:45:08 +0900

이전까지 만들었던 칩들은 시간과 무관한 조합(combination)칩입니다.

여기서 실습할 칩들은 현재시점의 입력과 이전에 처리되었던 칩들의 결과에도 영향을 받는 순차(sequential)칩 입니다.

컴퓨터에서의 시간은 클럭(tick, tock)이라는 2개의 이산신호를 이용해서 구현 할 수 있습니다.

데이터 플립 플롯 (DFF)

컴퓨터에서의 시간 클럭(tick, tock)을 사용하는 논리게이트입니다.

DFF는 클럭 신호에 맞추어 데이터를 출력하며, 이전에 입력되었던 신호를 출력하는 간단한 동작을 구현합니다.

(클럭 신호는 클록 전용 버스를 통해 DDL로 전달됩니다.)

예를들어 DFF의 in에 1이 들어간다면 DFF는 in으로 들어온 데이터 1이 저장되고

다음 클럭 때 DFF에서 가지고 있던 데이터 1을 출력합니다.

// 저번 클럭(t-1) 때 들어온 데이터를 이번 클럭(t)에 출력합니다
out(t)=in(t-1)

레지스터 (Register)

DFF은 이전에 들어온 입력데이터를 계속해서 출력만 하기에

DFF 저장된 데이터를 변경하거나 출력하기 위한 장치, 레지스터가 필요합니다.

레지스터에 저장되는 비트 수는 width라고도 하며, 이 데이터를 word, 크기를 wordsize라고 합니다.

32Bit 운영체제의 wordsize는 32Bit, 64Bit는 64Bit입니다.

데이터 비트를 전달하는 입력 in, 쓰기 기능을 설정하는 load입력, 레지스터의 현재상태를 출력하는 out이 있습니다.

load가 1이면 레지스터의 출력은 in(t)의 값을 저장 후 출력하고,

load가 0이면 레지스터의 출력은 out(t-1), 즉 저번 클럭에 유지된 값을 값을 출력합니다.

1bit 레지스터

레지스터에 입력이 들어오면 먼저 Mux에 의해 선택된 out이 DFF로 전달됩니다.

레지스터에 들어온 load가 0이라면,

레지스터는 이전에 DFF에 존재하던 데이터를 출력해야합니다.

먼저 DFF의 in에는 Mux에 따른 출력(out)이 전달되고 (load가 0이기에 DFF에 0이 전달됨),

DFF에 0이 들어오면 상태가 변하지 않으므로 다음 클럭에 맞추어 이전 출력을 그대로 출력합니다.

만약 레지스터의 load에 1이 전달되면.

in에 따른 MUX의 out이 DFF에 전달되고

DFF는 들어온 in(0 또는 1)에 따라 이전 데이터를 출력하거나 새로운 값을 DFF에 저장하고 다음 클럭에 출력합니다.

(16Bit 레지스터도 구현은 동일합니다.)

CHIP Bit {
    IN in, load;
    OUT out;

    PARTS:
    Mux(a=muxin, b=in , sel=load, out=muxout);
    DFF(in=muxout, out=muxin, out=out); // MUX, 최종out 두 방향으로 전달
}

메모리 (Random-Access-Memory)

메모리 (RAM)는 n개의 레지스터 칩으로 구성되며,

RAM은 각 레지스터마다 특정주소(0 ~ n-1)를 할당하고 이 주소를 이용해 특정 레지스터의 값을 읽거나 쓸 수 있는 입니다.

어떤 레지스터의 주소든 같은 속도로 접근 가능하기에 Random Access Memory라고 합니다.

메모리는 in, load, address 세 개의 입력을 받아 address에 위치한 레지스터에서 읽기 또는 쓰기를 하여 결과를 반환합니다.

읽기,쓰기가 일어나는 '한번의 동작'에서 address로 들어온 주소의 레지스터만 사용합니다.

load가 0과 address가 들어오면 선택한 레지스터의 값을 반환하고,

load가 1, address, in이 들어오면 In에 들어온 값을 레지스터에 저장하고 다음 클럭에 그 값을 반환합니다.

CHIP RAM8 {
    IN  in[16], load, address[3]; 
    OUT out[16];                 

    PARTS:
    Register(in=in, load=sel0, out=r0);
    Register(in=in, load=sel1, out=r1);
    Register(in=in, load=sel2, out=r2);
    Register(in=in, load=sel3, out=r3);
    Register(in=in, load=sel4, out=r4);
    Register(in=in, load=sel5, out=r5);
    Register(in=in, load=sel6, out=r6);
    Register(in=in, load=sel7, out=r7);

    // 주소(address)에 따라 8개의 레지스터 중 하나만 load 활성화
    DMux8Way(in=load, sel=address, a=sel0, b=sel1, c=sel2, d=sel3, 
             e=sel4, f=sel5, g=sel6, h=sel7);

    // 주소(address)에 따라 선택된 레지스터의 데이터를 출력
    Mux8Way16(a=r0, b=r1, c=r2, d=r3, e=r4, f=r5, g=r6, h=r7, 
              sel=address, out=out);
}

프로그램 카운터 (Program Counter)

프로그램 카운터는 CPU가 다음에 실행할 명령어의 주소를 레지스터에 전달해주는 기능을 합니다.

load, inc, reset, in 4개의 제어비트가 있으며

in, load에 데이터가 들어오면 in에 해당하는 값으로 PC의 값을 설정하거나 매 클럭마다 값을 1씩 증가시키는 동작을 합니다.

추가로 카운터를 관리하는 inc와 reset 두가지의 제어비트가 추가로 존재하는데,

inc가 활성화(1) 되어있으면 매 클록 주기마다 상태값을 1씩 증가시키며 (pc++) reset 비트를 활성화(1)하면 카운터(PC)의 상태값이 초기화됩니다.

만약 load, inc, reset모두 0이라면 현재 PC값을 유지합니다.

CHIP PC {
    IN in[16], reset, load, inc;
    OUT out[16];
    
    PARTS:
    // 현재 PC 값을 저장할 16비트 레지스터
    Register(in=pcNext, load=true, out=pcCurrent, out=out);

    // 현재 PC + 1 계산 (자동 증가)
    Inc16(in=pcCurrent, out=pcPlusOne);

    // Mux로 동작 선택
    Mux16(a=pcCurrent, b=pcPlusOne, sel=inc, out=pcInc);   // inc=1이면 증가

    Mux16(a=pcInc, b=in, sel=load, out=pcLoad);            // load=1이면 in 값으로 점프

    Mux16(a=pcLoad, b=false, sel=reset, out=pcNext);       // reset=1이면 0으로 리셋    
}

NandToTetris-Hardware simulator / Adder, Inc ,ALU 실습-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Fri, 24 Jan 2025 22:41:07 +0900

컴퓨터 내부에서 모든것은 2진코드로 표현되며,

레지스터의 wordsize cpu가 한번에 처리 할 수 있는 단위)에 따라 처리할 수 있는 데이터의 단위가 결정됩니다.

cpu아키텍쳐에 따라 wordsize가 32bit라면 4바이트, 64bit라면 8바이트의 단위를 한번에 처리 할 수 있습니다.

예를들어 어떤 컴퓨터가 8bit wordsize를 가졌다면 총 255까지의 숫자를 표현 할 수 있지만, 음수는 표현할 수 없습니다.

이번 글에서는 컴퓨팅 시스템에서 제한된 비트 안에서 어떻게 음수를 표현하는지, 그리고 단순한 가산기부터 ALU를 만드는 실습까지 진행해보려 합니다.

컴퓨터에서의 2진수 처리

덧셈

오른쪽에서 끝 비트인 최하위 비트(least significant bit, LSB)부터 최상위 비트 (most significant bit, MSB)까지 각각 숫자를 더해

더해 2가되면 자리올림비트 (CarryBit)를 만들어 다음자리수에 올려 계산해줍니다.

만약 최상위 비트(MSB)에서 자리올림(오버플로)이 발생한다면 사용하는 bit수에 맞게 버림 처리를 합니다.

2진수의 음수표현과 2의 보수법

2의 보수법

대부분의 컴퓨터에서는 이진수의 음수를 표현하기 위해 2의 보수법을 활용합니다.

보수를 구한다는건 각 양수에 대응하는 음수를 구한다는 의미입니다.

1의 보수로 음수 표기를 하게되면 음의 0, 양의 0이 존재하기에 컴퓨터에서는 2의 보수법을 사용합니다.

예를들어 4bit 2진법 쳬계에서 음수 x를 표현하는 이진코드는 "2^4 - x" 로 나타내게됩니다.

-7을 이진수로 나타낸다면 "2^4-7"이고 십진법으로 계산했을때는 "9", 이진법으로는 1001입니다.

7은 이진법으로 0111이기에 "1001 + 0111 = 0000"이 되어 2의 보수임을 확인 할 수 있습니다.

간단하게 2의 보수를 찾으려면, 모든 bit에 대해서 1의보수(0을 1로, 1을 0으로)를 취한 다음 1을 더해주면 됩니다.

부호비트 (sign bit)

컴퓨터에서는 음수를 표현하기 위해 비트의 가장 왼쪽 비트(MSB)를 부호비트(sign bit)로 사용합니다.

만약 부호비트가 1이라면 음수, 0이라면 양수가 됩니다.

양수만 표현한다면 4비트는 0부터 15까지의 16개의 수를 표현 할 수 있고,

부호비트를 사용한다면 16개의 절반을 음수를 위해 할당합니다.

즉 4비트 안에서 음수까지 표현해야한다면 위의 표와 같이 -8부터 7까지 표현 할 수 있게됩니다.

반가산기

컴퓨터에서 덧셈을 하기 위한 첫 단계로,

두 비트를 더해서 결과 값으로 합(Sum)과 자리올림(Carry)를 bit를 산출합니다.

Xor 과 And 연산을 이용해서 만들 수 있습니다.

CHIP HalfAdder {
    IN a, b;    // 1-bit inputs
    OUT sum,    // Right bit of a + b 
        carry;  // Left bit of a + b

    PARTS:
    Xor(a =a, b =b, out = sum);
    And(a =a, b =b, out = carry);
}

전가산기

3개의 비트를 계산하는 가산기입니다.

출력은 반가산기와 동일하게 carry, sum을 산출합니다.

HalfAdder와 Or를 통해서 만들 수 있습니다.

CHIP FullAdder {
    IN a, b, c;  // 1-bit inputs
    OUT sum,     // Right bit of a + b + c
        carry;   // Left bit of a + b + c

    PARTS:
    HalfAdder(a=a , b=b , sum=sum1, carry=carry1);
    HalfAdder(a=sum1, b=c, sum=sum, carry=carry2);
    Or(a=carry1 , b=carry2 , out=carry );
}

16Bit 가산기

16bit 가산기입니다.

2개의 16bit수를 계산할 수 있습니다.

해당 책에서는 오버플로우는 무시합니다.

CHIP Add16 {
    IN a[16], b[16];
    OUT out[16];

    PARTS:
    FullAdder(a=a[0], b=b[0], c=false, sum=out[0], carry=carry0);
    FullAdder(a=a[1], b=b[1], c=carry0, sum=out[1], carry=carry1);
    FullAdder(a=a[2], b=b[2], c=carry1, sum=out[2], carry=carry2);
    FullAdder(a=a[3], b=b[3], c=carry2, sum=out[3], carry=carry3);
    FullAdder(a=a[4], b=b[4], c=carry3, sum=out[4], carry=carry4);
    FullAdder(a=a[5], b=b[5], c=carry4, sum=out[5], carry=carry5);
    FullAdder(a=a[6], b=b[6], c=carry5, sum=out[6], carry=carry6);
    FullAdder(a=a[7], b=b[7], c=carry6, sum=out[7], carry=carry7);
    FullAdder(a=a[8], b=b[8], c=carry7, sum=out[8], carry=carry8);
    FullAdder(a=a[9], b=b[9], c=carry8, sum=out[9], carry=carry9);
    FullAdder(a=a[10], b=b[10], c=carry9, sum=out[10], carry=carry10);
    FullAdder(a=a[11], b=b[11], c=carry10, sum=out[11], carry=carry11);
    FullAdder(a=a[12], b=b[12], c=carry11, sum=out[12], carry=carry12);
    FullAdder(a=a[13], b=b[13], c=carry12, sum=out[13], carry=carry13);
    FullAdder(a=a[14], b=b[14], c=carry13, sum=out[14], carry=carry14);
    FullAdder(a=a[15], b=b[15], c=carry14, sum=out[15], carry=carry15);
    
}

증분기

주어진수에 1을 더합니다.

추가로 컴퓨터 아키텍쳐를 설정 할 때,

주어진 숫자에 1을 더하는 칩이 있는게 편리합니다.

만약 b에 값을 설정하지 않으면 모두 '0'인 bit입니다

그렇기에 b[0], b의 가장 오른쪽 비트 MSB를 1로 변경합니다.

CHIP Inc16 {
    IN in[16];
    OUT out[16];

    PARTS:
    Add16(a=in, b[0]=true, out=out);
}

ALU (산술논리장치)

cpu의 계산을 담당하는 부분입니다.

두 수의 덧샘, 뺄셈, 불 연산 등등 연산을 할 수 있는 칩입니다.

입력은 x,y 두개와 6개의 제어비트 zx, nx, zy, ny, f, no가 있습니다.

zx가 1이면 x를 0으로 만들고, nx가 1이면 x를 반전시킵니다.

zy, ny는 y에 대해서 1이면 y를 0으로 만들고, ny가 1이면 y를 반전시킵니다.

f가 1이면 변환된 x와 y를 ADD하고, 0이면 AND 연산을 합니다. no가 1이면 반환 값을 반전시킨다.

zr은 위에서 계산한 결과가 0이면 True, ng는 위에서 계산한 결과가 음수이면 True입니다.

(해당 책에서 만드는 cpu는 곱셈연산이 없습니다.)

CHIP ALU {
    IN  
        x[16], y[16],         
        zx, 
        nx, 
        zy, 
        ny, 
        f, 
        no;
    OUT 
        out[16], 
        zr,      
        ng;      

    PARTS:
    Not16(in=x, out=notX);
    Not16(in=y, out=notY);

    Mux4Way16(a=x, b=notX, c=false, d=true, sel[0]=nx, sel[1]=zx, out=newX);
    Mux4Way16(a=y, b=notY, c=false, d=true, sel[0]=ny, sel[1]=zy, out=newY);
    
    Add16(a=newX, b=newY, out=addXY);
    And16(a=newX, b=newY, out=andXY);

    Mux16(a=andXY, b=addXY, sel=f, out=MuxOut);
    Not16(in=MuxOut, out=notMuxOut);
    
    Mux16(a=MuxOut, b=notMuxOut, sel=no, out=out, out[15]=ng, out[0..7]=left, out[8..15]=right);

    Or8Way(in=left, out=orWayOut1);
    Or8Way(in=right, out=orWayOut2);
    Or(a=orWayOut1, b=orWayOut2, out=orOut);
    Not(in=orOut, out=zr);
}

운영시 유용한 Performance, Sys 쿼리 모음

겅겅겅 — Tue, 14 Jan 2025 16:07:01 +0900

DB에서 뭔가 Performance나 sys테이블 봐야할거같은데

어떻게 쿼리를 쳐서 봐야할지 바로바로 생각나지 않는 경우가 많죠

그래서 유용할만한 쿼리들을 포스팅해두려 합니다.

(Real MySQL을 보고 공부한 내용을 다룹니다.)

호스트 접속 이력 확인

MySQL에 접속했던 host들의 전체 목록을 확인합니다.

CURRENT_CONNECTIONS는 현재 연결된 커넥션 수, TOTAL_CONNECTIONS는 연결되었던 총 커넥션 수 입니다.

SELECT * FROM performance_schema.hosts

MySQL 총 메모리 사용량 확인

SELECT * FROM sys.memory_global_total

스레드별 메모리 사용량 확인

SELECT thread_id, user, current_allocated FROM sys.memory_by_thread_by_current_bytes

특정 프로세스 ID의 메모리 사용내역 확인

SELECT thread_id, event_name,
       sys.format_bytes(CURRENT_NUMBER_OF_BYTES_USED)
FROM
performance_schema.memory_summary_by_thread_by_event_name
WHERE thread_id = (SELECT sys.ps_thread_id(<프로세스ID>))

미사용 인덱스 확인

SELECT * FROM sys.schema_unused_indexes

중복된 인덱스 확인

SELECT * FROM sys.schema_redundant_indexes

변경이 없는 테이블 확인 (구동된 시점부터 현재까지 쓰기가 발생하지 않은 테이블)

SELECT * FROM information_schema.tables AS t
JOIN performance_schema.table_io_waits_summary_by_table AS tio
ON tio.OBJECT_SCHEMA = t.TABLE_SCHEMA AND tio.OBJECT_NAME = t.TABLE_NAME
WHERE t.TABLE_SCHEMA NOT IN ('mysql', 'performance_schema','sys')
AND tio.COUNT_WRITE = 0

I/O 요청이 많은 테이블 목록 확인

SELECT * FROM sys.io_global_by_file_by_bytes WHERE file LIKE '%idb'

테이블별 작업량 통계 확인

SELECT table_schema,table_name, rows_updated, rows_inserted, rows_deleted, rows_inserted
        ,io_read, io_write
FROM
sys.schema_table_statistics
WHERE TABLE_SCHEMA NOT IN ('mysql', 'performance_schema','sys')

풀 테이블 스캔 쿼리 확인

SELECT db, query, exec_count, sys.format_time(total_latency),
       rows_examined_avg, rows_sent_avg, last_seen
FROM sys.x$statements_with_full_table_scans

자주 실행되는 쿼리 목록 확인

SELECT db, exec_count, query
FROM sys.statement_analysis
ORDER BY exec_count DESC

실행시간이 긴 쿼리 목록

SELECT query, exec_count, sys.format_time(avg_latency)
     ,rows_sent_avg, rows_examined_avg, last_seen
FROM sys.x$statement_analysis
ORDER BY avg_latency DESC

최근에 정렬 작업을 수행한 쿼리 확인

SELECT * FROM
sys.statements_with_sorting
ORDER BY last_seen DESC LIMIT 1

최근에 임시테이블을 생성한 쿼리 확인

SELECT * FROM
    sys.statements_with_temp_tables
LIMIT 10

트랜잭션이 활성 상태인 커넥션에서 실행한 쿼리 내역 확인

SELECT ps_t.PROCESSLIST_ID,
       ps_esh.THREAD_ID,
       CONCAT(ps_t.PROCESSLIST_USER,'@',ps_t.PROCESSLIST_HOST) as 'account',
       ps_esh.EVENT_NAME,
       ps_esh.SQL_TEXT,
       sys.format_time(ps_esh.TIMER_WAIT) AS 'duration',
       DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status
                                                       WHERE VARIABLE_NAME='UPTIME') - ps_esh.TIMER_START*10e-13 second) AS 'start_time',
       DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status
                                                       WHERE VARIABLE_NAME='UPTIME') - ps_esh.TIMER_END*10e-13 second) AS 'end_time'
FROM performance_schema.threads ps_t
INNER JOIN performance_schema.events_transactions_current ps_etc
ON ps_etc.THREAD_ID = ps_t.THREAD_ID
INNER JOIN performance_schema.events_statements_history ps_esh
ON ps_esh.NESTING_EVENT_ID = ps_etc.NESTING_EVENT_ID
WHERE ps_etc.STATE = 'ACTIVE'
AND ps_esh.MYSQL_ERRNO = 0
ORDER BY ps_t.PROCESSLIST_ID, ps_esh.TIMER_START

특정 세션에서 실행된 전체 쿼리 확인

SELECT ps_t.PROCESSLIST_ID,
       ps_esh.THREAD_ID,
       CONCAT(ps_t.PROCESSLIST_USER,'@',ps_t.PROCESSLIST_HOST) as 'account',
       ps_esh.EVENT_NAME,
       ps_esh.SQL_TEXT,
       DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status
                                                       WHERE VARIABLE_NAME='UPTIME') - ps_esh.TIMER_START*10e-13 second) AS 'start_time',
        DATE_SUB(NOW(), INTERVAL (SELECT VARIABLE_VALUE FROM performance_schema.global_status
                                                       WHERE VARIABLE_NAME='UPTIME') - ps_esh.TIMER_END*10e-13 second) AS 'end_time',
       sys.FORMAT_TIME(ps_esh.TIMER_WAIT) AS 'duration'
FROM
performance_schema.events_statements_history ps_esh
INNER JOIN performance_schema.threads ps_t
ON ps_t.THREAD_ID = ps_esh.THREAD_ID
WHERE ps_t.PROCESSLIST_ID = <PROCESS_ID>
AND ps_esh.SQL_TEXT IS NOT NULL
AND ps_esh.MYSQL_ERRNO = 0
ORDER BY ps_esh.TIMER_START DESC

서비스중인 테이블을 안전하게 변경 ALTER 하는 방법

겅겅겅 — Thu, 9 Jan 2025 13:10:16 +0900

서비스를 운영하다보면 테이블을 변경해야 할 때가 있습니다.

호기롭게 DDL문을 실행했지만 변경하는 시간이 오래 걸리게되면 급격하게 불안해지는 저의 모습을 여러번 보았습니다..

그래서 스키마 변경 중에도 다른 커넥션에서 데이터를 정상적으로 조회 할 수 있도록 도와주는 온라인 DDL알고리즘과 해당 알고리즘을 적용해 테이블을 변경하는 방법들을 정리해보려 합니다.

(Real MySQL 8.0을 보고 공부한 내용을 다룹니다.)

온라인 DDL 알고리즘

스키마 변경 중에도 다른 커넥션에서 데이터를 정상적으로 조회 할 수 있도록 도와주는 MySQL의 기능입니다.

3가지의 알고리즘이 존재하며, ALTER TABLE 실행하면 MySQL은 INSTANT, INPLACE, COPY 순서대로 가능한 알고리즘을 선택하여 적용시킵니다.

INSTANT

테이블의 데이터는 변경하지 않고, 메타데이터만 변경하고 작업을 완료시킵니다.

스키마 변경 중 테이블의 읽기, 쓰기는 대기하지만 작업시간은 매우 짧아 다른 커넥션의 쿼리 처리는 거의 영향을 끼치지 않습니다.

INPLACE

임시테이블로 데이터를 복사하지 않고, 스키마 변경을 실행합니다.

내부적으로 테이블 리빌드가 실행 될 수 있습니다.

레코드의 복사작업은 없지만 테이블의 모든 데이터를 리빌드해야하기에 테이블 크기에 따라 많은 시간이 걸릴 수 있습니다.

하지만 작업중에도 테이블의 읽기 쓰기가 모두 가능합니다.

(최초 시작 시점과 종료시점에는 테이블 읽고 쓰기가 불가능 하지만 시간이 매우 짧아 다른 커넥션에서 큰 영향은 없습니다.)

COPY

변경된 스키마를 적용한 임시테이블을 생성하고, 테이블의 레코드를 모두 임시 테이블로 복사 한 후 최종적으로 임시 테이블을 RENAME해서 스키마 변경을 완료합니다.

테이블 읽기만 가능하고 DML(INSERT, UPDATE, DELETE)는 불가능합니다.

DDL을 적용 할 떄 위에 3개의 알고리즘과 함께 잠금수준도 명시해서 실행하면 원하는 알고리즘으로 테이블 변경을 할 수 있습니다.

잠금 수준도 동일하게 3가지 방법이 있습니다

NONE

아무런 잠금을 걸지 않습니다.

SHARED

읽기 잠금을 걸고 스키마 변경을 실행합니다. (테이블 읽기는 가능, 쓰기작업 불가)

EXCLUSIVE

쓰기 잠금을 걸고 스키마 변경을 실행합니다. (테이블 읽고 쓰기 불가)

예시

DDL아래 알고리즘과 LOCK을 명시해서 사용하면 됩니다.

만약 명시하지 않으면 MySQL이 적절한 알고리즘과 잠금수준을 적용합니다.

ALTER TABLE salaries CHANGE to_date, end_date DATE NOT NULL,
ALGORITHM=INPLACE, LOCK=NONE

INPLACE 알고리즘의 테이블 리빌드란?

INPLACE알고리즘에는 테이블 리빌딩이 일어날 수 있습니다.

예를들어 PK키를 추가하는 작업의 경우 데이터 파일에서 레코드의 저장위치가 변경되어야 하기에 리빌드가 필요합니다.

(컬럼이름 변경작업 같은 경우에는 리빌드 X)

하지만 INPLACE알고리즘에서도 작업 시작, 끝 두 시점에는 X-Lock이 걸리게 됩니다.

X-Lock이 걸렸던 시점에서 발생했던 DML들은 메모리의 온라인 변경 로그 (Oneline alter log)에 쌓기게 되는데

테이블의 변경이 완료되면 해당 로그들을 일괄로 처리됩니다.

만약 온라인 변경 로그의 값이 너무 커지게 되면 온라인 DDL작업은 실패하게 됩니다.

( innodb_online_alter_log_max_size 변수로 크기 조절 가능, 세션단위의 동적 변수임)

안전하게 테이블 변경 DDL 실행하는 방법

아래 두 방식의 알고리즘을 선택하면 다른 커넥션과의 잠금없이 테이블 변경이 가능합니다.

만약 두 방식으로 변경이 안된다면 사용자가 없는 시간대나 서비스 점검을 걸고 작업하는것이 좋습니다.

1. ALGORITHM=INSTANT 방식으로 실행

ALTER TABLE salaries CHANGE to_date, end_date DATE NOT NULL,
ALGORITHM=INSTANT

2. ALGORITHM=INPLACE, LOCK=NONE 방식으로 실행

ALTER TABLE salaries CHANGE to_date, end_date DATE NOT NULL,
ALGORITHM=INPLACE, LOCK=NONE

각 작업별 온라인 DDL 알고리즘 처리 방식

MySQL에서 테이블 변경시 처리되는 알고리즘 처리표입니다. (8.0.21 버전 기중)

MySQL 실행계획 보는 방법

겅겅겅 — Mon, 30 Dec 2024 22:06:40 +0900

DB에서 쿼리를 작성하면 EXPLAIN 또는 DESC 명령어를 통해 실행계획을 확인합니다.

하지만 보다보면 가끔 잘 모르겠는 부분이 있어서..

Real MySQL을 보며 공부한 부분을 정리하려합니다.

통계정보와 히스토그램

실행계획을 보기 전에 옵티마이저가 어떤식으로 실행계획을 만드는지 간단하게 알아보려고합니다.

옵티마이저가 보다 효율적인 실행계획을 만들기 위해 필요한 두가지가 통계정보와 히스토그램입니다.

두 정보를 기반으로 어떤 인덱스를 선택할지 JOIN순서를 어떻게 정할지 결정하기 때문입니다.

통계정보는 디스크에 저장되며 테이블이 생성되거나 데이터가 변경될 때 통계정보가 추가 및 변경됩니다.

히스토그램은 자동으로 수집되지 않으며, 데이터 분포에 대한 통계정보를 제공합니다.

히스토그램은 아래와 같은 명령어로 생성 가능합니다.

ANALYZE TABLE 테이블명 UPDATE HISTOGRAM ON 칼럼명;

출력 포멧

실행계획은 테이블, TREE, JSON 3가지 형태로 출력 할 수 있습니다.

테이블 출력

EXPLAIN SELECT 쿼리

TREE 출력

EXPLAIN FORMAT=TREE SELECT 쿼리

JSON 출력

EXPLAIN FORMAT=JSON SELECT 쿼리

TREE FORMAT에서 쿼리의 단계별 실행시간 및 실행계획 읽는법

EXPALIN ANALYZE 명령어로 단계별 쿼리 시간을 확인 할 수 있습니다.

이는 실제 실행계획은 아니며 MySQL이 가지고 있는 통계정보들을 가지고 예측한 결과를 보여줍니다.

EXPLAIN ANALYZE FORMAT=TREE SELECT o.order_id, u.name, p.name AS product_name, oi.quantity
FROM orders o
JOIN users u ON o.user_id = u.user_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE u.name = 'Alice';

-> Nested loop inner join  (cost=1.8 rows=1) (actual time=0.0732..0.0857 rows=2 loops=1)
    -> Nested loop inner join  (cost=1.45 rows=1) (actual time=0.0648..0.0736 rows=2 loops=1)
        -> Nested loop inner join  (cost=1.1 rows=1) (actual time=0.0495..0.055 rows=1 loops=1)
            -> Filter: (u.`name` = 'Alice')  (cost=0.75 rows=1) (actual time=0.0336..0.0378 rows=1 loops=1)
                -> Table scan on u  (cost=0.75 rows=5) (actual time=0.0306..0.0334 rows=5 loops=1)
            -> Covering index lookup on o using user_id (user_id=u.user_id)  (cost=0.35 rows=1) (actual time=0.0142..0.0153 rows=1 loops=1)
        -> Filter: (oi.product_id is not null)  (cost=0.35 rows=1) (actual time=0.0146..0.0175 rows=2 loops=1)
            -> Index lookup on oi using order_id (order_id=o.order_id)  (cost=0.35 rows=1) (actual time=0.0142..0.0167 rows=2 loops=1)
    -> Single-row index lookup on p using PRIMARY (product_id=oi.product_id)  (cost=0.35 rows=1) (actual time=0.00508..0.00517 rows=1 loops=2)

TREE 형태의 실행계획에서 들여쓰기는 아래와 같은 의미를 가집니다.

들여쓰기가 같은 레벨에서는 상단에 위치한 라인이 먼저 실행된다.
들여쓰기가 다른 레벨에서는 가장 안쪽에 위치한 라인이 먼저 실행된다.

즉 위와 같은 상황에서는

1. Filter: (u.`name` = 'Alice') (cost=0.75 rows=1) (actual time=0.0336..0.0378 rows=1 loops=1)

- actual time은 테이블에서 레코드를 가져오는데 걸리는 시간이며, 첫번째 숫자는 첫번째 레코드, 두번째는 마지막 레코드를 가져오는데 걸린 평균시간입니다.

- users 테이블에서 조건에 맞는 행을 찾습니다.

- 5개의 행을 스캔했고 조건에 맞는 actual rows=1 조건을 만족하는 행은 1개

2.Covering index lookup on o using user_id (user_id=u.user_id) (cost=0.35 rows=1) (actual time=0.0142..0.0153 rows=1 loops=1)

- u.user_id를 기반으로 orders 테이블에서 조건에 맞는(u.name=Alice)데이터를 찾습니다.

- rows=1 매칭된 행 1개, 커버링 인덱스 사용

- loops=1 상위노드(users)에서 하위노드(orders)의 데이터를 읽어오는 작업이 한번 진행되었습니다.

3.Index lookup on oi using order_id (order_id=o.order_id) (cost=0.35 rows=1) (actual time=0.0142..0.0167 rows=2 loops=1)

- o.order_id를 이용해 order_items 테이블에서 데이터를 찾습니다.

- rows=2 매칭된 행 1개

- loops=1 상위노드(order_items)에서 하위노드(orders)의 데이터를 읽어오는 작업이 한번 진행되었습니다.

4.Single-row index lookup on p using PRIMARY (product_id=oi.product_id) (cost=0.35 rows=1) (actual time=0.00508..0.00517 rows=1 loops=2)

- oi.product_id를 이용해 products 테이블에서 데이터를 찾습니다.

- roops=2 상위노드(product)에서 하위노드(order_items)의 데이터를 읽어오는 작업이 한번 진행되었습니다.

EXPLAIN 컬럼들

id (SELECT의 단위)

SELECT 쿼리별로 부여되는 식별자값 입니다.

하나의 SELECT 문장은 하나의 ID값을 가지며, JOIN된 테이블들은 하나의 ID값을 가집니다.

그렇기에 아래와 같이 서브쿼리를 사용하면 다른 ID값을 가진 실행계획을 찾을 수 있습니다.

select_type

SELECT 쿼리에 대한 타입입니다.

SIMPLE

UNION이나 서브쿼리를 사용하지 않는 단순한 SELECT쿼리입니다.

일반적으로 가장 바깥의 문장이 SIMPLE입니다.

PRIMARY

UNION이나 서브쿼리를 가지는 실행계획에서 가장 바깥쪽 문장의 타입입니다.

DERIVED

쿼리의 실행결과로 메모리와 디스크에 임시테이블을 만드는 작업을 말합니다.

UNION

UNION으로 결합되는 쿼리 중 첫번 째 이후 쿼리에 대한 타입입니다. (첫번째는 DERIVED)

첫째 테이블은 4개의 서브쿼리로 조회된 결과를 UNION ALL로 결합해 임시테이블을 이용해 사용하고 있기에 DERIVED 타입을 가지게됩니다.

추가로 UNION이나 UNION ALL로 결합된 쿼리가 외부쿼리에 의해 영향을 받으면 DEPENDENT 타입(DEPENDENT SUBQUERY, DEPENDENT UNION)이 됩니다.

DEPENDENT의 경우에는 외부쿼리가 먼저 실행되고 내부쿼리가 실행되어야 하기에 일반 서브쿼리보다는 느립니다.

SUBQUERY

SELECT TYPE에서 서브쿼리는 FROM절 이외에서 사용되는 서브쿼리만을 의미합니다.

FROM절에서 사용되는 서브쿼리는 DERIVED로 표시됩니다.

MATERIALZED

주로 FROM절이나 IN형태의 서브쿼리에 사용된 서브쿼리의 최적화를 위해 사용합니다

서브쿼리의 내용을 임시로 구체화 한 후 임시테이블을 다른 테이블과 조인하는 형태로 최적화합니다.

TABLE 컬럼

사용된 TABLE을 표시합니다.

<derived숫자>, <union M,N>과 같은 컬럼들은 임시테이블을 의미합니다.

아래 예시와 같은 쿼리에서 <derived3>이라고 되어있는데 여기서 3은 SELECT쿼리의 id값이 3인 실행계획으로 부터 만들어진 파상태이블임을 의미합니다.

즉 id:1 번은 실행되기 위해 id:3번인 users 테이블을 읽어서 만들어진 임시테이블이라는 의미입니다.

PARTITIONS 컬럼

SELECT에서 조회할 때 파티션을 통해 조회했다면 해당 파티션을 확인 할 수 있습니다.

TYPE 컬럼 (JOIN TYPE)

각 테이블의 레코드를 어떤 방식으로 읽었는지 확인합니다.

CONST

pk나 유니크 키를 사용하는 WHERE 조건절을 가지고있으며, 반드시 1건을 반환하는 방식입니다.

유니크 인덱스 스캔이라고도 합니다.

옵티마이저가 쿼리를 최적화 하는 단계에서 해당 쿼리를 먼저 실행시켜 통채로 상수화시킵니다.

그래서 const타입이라고 합니다.

pk조건 중 일부만 사용할때는 const가 아닌 ref방식으로 읽습니다.

eq_ref

join에서 처음 읽은 테이블의 컬럼값을 다른 테이블의 pk나 유니크 키 조건에 사용 할 때를 eq_ref라고합니다.

이 때 처음 읽은 테이블이 아닌 두번째 테이블의 type에 eq_ref라고 표시됩니다.

첫번째 테이블의 조건을 통해 읽는 두번째 테이블의 데이터가 반드시 유니크해야 eq_ref방식을 사용합니다.

ref, ref_or_null

인덱스의 종류와 상관없이 동등(Equal)조건으로 검색할 때에는 ref방식이 사용됩니다.

eq_ref와 다르게 유니크한 값일 필요가 없으므로 const나 eq_ref보다는 느리지만 여전히 빠른 접근방식입니다.

null조건도 함께 검색한다면 ref_or_null 방식이 사용됩니다.

unique_subquery, index_subquery

모두 where조건절에서 사용되는 IN 형태의 쿼리를 위한 접근방식입니다.

unique_subquery는 서브쿼리에서 중복되지 않는 유니크한 값만 반환 할 때 사용되는 방식입니다.

index_subquery는 서브쿼리에서 중복된 결과를 인덱스를 통해 제거 할 수 있을 떄 사용되는 방법입니다.

range

인덱스 레인지 스캔을 의미합니다.

일반적인 어플리케이션 쿼리가 가장 많이 사용하게되는 방법입니다.

index_merge

2개 이상의 인덱스를 이용하여 각각 검색결과를 만들어낸 후, 그 결과를 병합해서 처리하는 방식입니다.

pk컬럼과 인덱스 컬럼을 or 조건처럼 각각 조회하게되는 쿼리일때

MySQL은 pk를 통해 데이터를 찾고, 인덱스를 통해 데이터를 찾은 후 두 결과를 병합하는 형태로 처리합니다.

index

인덱스 풀 스캔을 의미합니다.

아래 방법 중 1+2, 1+3과 같은 상황일 때 사용됩니다.

1. range나 const, ref와 같은 접근방법으로 인덱스를 사용하지 못하는 경우

2. 인덱스에 포함된 컬럼만으로 처리 할 수 있는 컬럼일 경우

3. 인덱스를 이용해 정렬이나 그루핑 작업이 가능한 경우

ALL

테이블 풀 스캔을 의미합니다.

possible_keys 컬럼

옵티마이저가 실행계획을 만들 때 후보로 선정했던 즉 실제 사용되지 않았던 인덱스를 의미합니다.

key 컬럼

옵티마이저가 실제 사용했던 인덱스를 의미합니다.

key의 값이 primary라면 pk를 사용한다는 의미이고, 이 외의 값은 테이블이나 인덱스를 만들었을 때의 그 고유이름이다.

실행계획이 ALL이라면 key컬럼은 NULL로 표시됩니다.

key_lens 컬럼

쿼리를 처리하기 위해 사용했던 인덱스에서 몇개의 인덱스까지 사용되었는지 byte의 길이로 알려줍니다.

name은 varchar(50)이기에 한 문자당 3바이트, 즉 200바이트에 문자열의 길이를 저장하기 위한 1바이트, NULL 허용하기에 1바이트,

key_lens컬럼에서 바이트를 정수로 표현하기 위한 1바이트 총 203바이트가 표시됩니다.

ref 컬럼

참조조건으로 어떤값이 제공되었는지 알려줍니다.

상수값이라면 const, 다른 테이블의 컬럼값이라면 그 테이블과 컬럼명이 표시됩니다.

rows 컬럼

옵티마이저의 실행계획에서 이 처리방식이 얼마나 많은 레코드를 읽고 비교해야하는지 예측해서 산정한 비용입니다.

인덱스를 사용한 조건에만 일치하는 레코드의 예상치이고, 정확한 수치는 아닙니다.

filtered 컬럼

스토리지 엔진에서 가져온 데이터 중 filterd% 만큼이 쿼리조건에 만족한다는 의미입니다. (MySQL엔진에서 처리)

아래와 같은 상황에서는 ix_firstname 인덱스 조건에 일치하는 레코드는 233건이고 그 중 쿼리조건에 맞는 데이터는 16.03%라는 의미입니다.

EXTRA 컬럼

성능 관련하여 중요한 내용들이 표시되는 컬럼입니다.

const row not found

const조건으로 읽었지만 해당 레코드가 1건도 없을 때 나타납니다.

Distinct

distinct, union등이 사용된 쿼리에서 나타납니다.

아래는 두 테이블 전체에서 유니크한 user_id를 가져려는 쿼리입니다.

EXTRA 컬럼에서 users테이블에서는 distinct가 표시되었는데 해당 테이블에서 중복이 제거되어 필요한 유니크한 값들만을 찾았다는 의미입니다.

Full scan on NULL key

쿼리에서 컬럼의 값이 NULL인 경우를 찾을 때,

예를 들어 col1 in (SELECT name FROM USER)와 같은 상황에서 나타날 수 있는 내용입니다.

만약 col1이 NULL이게 된다면 그때는 서브쿼리테이블에 대해서 풀 테이블 스캔을 한다는 내용입니다.

impossible having, impossible where

작성한 having, where조건이 무조건 FALSE일 때 나타나는 내용입니다.

쿼리 재작성이 필요한건 아닌지 확인할 필요가 있습니다.

impossible having, impossible where

작성한 having, where조건이 무조건 FALSE일 때 나타나는 내용입니다.

No matching min/max row

집합함수에 일치하는 레코드가 없다는 내용입니다.

No matching row in const table

조인에 사용된 테이블에서 const방법으로 접근할때 일치하는 레코드가 없을 때 나타납니다.

Using filesort

Order by로 처리되지 못하고 filesort방식으로 정렬했을때 나타납니다.

Using index (커버링인덱스)

인덱스만 읽어서 모든 쿼리를 처리 할 수 있을 때 사용됩니다. (SELECT에서 사용하는 컬럼이 모두 인덱스의 컬럼일 때)

Using temporary

임시테이블을 사용했을때 나타납니다.

Using where

스토리지에서 가져온 데이터를 MySQL 엔진에서 별도의 작업을 했을 때 나타납니다.

스토리지 엔진에서 100건의 데이터를 가져왔다면 filtere처리로 데이터가 MySQL엔진에서 필터링되었다면 Using where조건이 나타납니다.

MySQL 옵티마이저가 하는 일

겅겅겅 — Sat, 21 Dec 2024 19:06:28 +0900

웹서비스를 개발하다 보면 실제 운영서버에 반영하기 전에 만들어둔 쿼리에 대한 테스트 및 성능확인이 필요합니다.

주로 EXPLAIN 명령어를 통해 쿼리의 성능을 평가했는데, 그냥 인덱스를 잘 타는구나~ 이 정도만 확인했던 기억이 있습니다.

그래서 옵티마이저가 인덱스를 어떻게 확인해서 쿼리에 적용하는지 더 나은 인덱스를 태우려면 어떻게 해야하는지 궁금해서

MySQL 옵티마이저에 대해 공부 및 정리해보려고 합니다.

(Real MySQL을 보고 공부한 내용을 다룹니다.)

쿼리의 실행 절차

1. SQL 파싱

사용자로 부터 쿼리요청이 들어오면 'SQL 파서 모듈'에서 문장을 적절하게 쪼개어 MySQL서버가 이해할 수 있는 수준으로 분리합니다.

(파싱 트리 작업)

2. 최적화 및 실행계획 수립 (옵티마이저 일하는 단계)

파싱 트리 작업에서 분리된 내용을 확인하여 적절한 테이블과 인덱스를 선택합니다.

이 단계에서 불필요 조건을 제거하고 복잡한 연산을 단순화 합니다.

임시테이블 필요유무도 이 단계에서 결정됩니다.

3. 레코드 읽기

결정된 인덱스를 사용해 스토리지 엔진으로 부터 데이터를 읽어옵니다.

옵티마이저의 기본적인 데이터 처리 방식

옵티마이저가 언제 풀을 타는지, 언제 인덱스를 타는지

각각의 데이터 조회방식과 그 방식들이 선택되는 이유에 대해서 알아보겠습니다.

풀 테이블 스캔과 풀 인덱스 스캔

테이블의 레코드 수가 적어서 인덱스보다 풀 테이블 스캔이 더 빠를 때 ( 보통 테이블이 페이지 1개로 구성되어 있는 경우 )
WHERE나 ON 조건에서 인덱스를 이용할 수 없을 때
인덱스 레인지 스캔을 하더라도 조건 일치 레코드가 너무 많을 때

풀 테이블 스캔, 풀 인덱스 스캔이 시작되면 처음 몇개의 데이터 페이지는 포그라운드 스레드에서 읽고 특정 시점부터는 백그라운드 스레드에서 작업을 하게됩니다.

백그라운드 스레드의 작업 시점부터는 점진적으로 읽어오는 페이지 수를 4개 8개.. 점점 증가시켜 최대 64개 까지 버퍼풀에 한번에 저장해둡니다.

이렇듯 InnoDB엔진은 특정 테이블의 데이터가 연속해서 읽히면 백그라운드 스레드에서 앞으로 필요할 것 같은 데이터들을 예상해서 미리 디스크에서 버퍼풀로 데이터를 가져다 두고 이를 리드 어헤드 작업이라고 합니다.

임시테이블 (Internal Temporary Table)에 대해

MySQL엔진이 스토리지 엔진으로 부터 데이터를 정렬(ORDER BY)하거나 그룹핑(GROUP BY)할 때 내부적인 임시 테이블을 사용합니다.

임시테이블은 최초 메모리에 생성되었다가 테이블의 크기가 커지면 디스크로 옮겨지며, 쿼리의 처리가 완료되면 자동으로 삭제됩니다.

메모리에 생성되는 임시 테이블은 TempTable (기본값 1GB)이라는 스토리지 엔진을 사용하고,

디스크에 저장되는 임시 테이블은 InnoDB스토리지 엔진을 사용합니다.

임시 테이블이 메모리에 생성되어 있는지, 디스크에 생성되어 있는지 확인하기 위해서는 아래와 같은 명령어로 확인 가능합니다.

Created_tmp_disk_tables : 디스크에 존재하는 임시 테이블 수

Created_tmp_files : 임시 테이블 생성 횟수

Created_tmp_tables : 디스크 + 메모리에 존재하는 임시 테이블 수

SHOW SESSION STATUS LIKE 'Created_tmp%';

쿼리에서 임시테이블이 사용되는 경우

ORDER BY와 GROUP BY에 명시된 컬럼이 다른 쿼리 (임시 유니크 인덱스 사용)
ORDER BY나 GROUP BY에 명시된 컬럼이 JOIN의 순서 상 첫번째 테이블이 아닌 쿼리 (임시 유니크 인덱스 사용)
DINSTINCT나 ORDER BY가 동시에 있거나 DISTINCT가 인덱스로 처리되지 못하는 쿼리 (임시 유니크 인덱스 사용)
UNION, UNION DISTINCT가 사용된 쿼리 (select_type 컬럼이 UNION RESULT인 경우) (임시 유니크 인덱스 사용)
쿼리의 실행 계획에서 select_type이 DERIVED인 쿼리 (임시 유니크 인덱스 사용 X)

임시 테이블은 메모리에 먼저 생성되지만 예외적으로 바로 디스크에 생성되는 경우

UNION이나 UNION ALL에서 SELECT되는 컬럼 중 길이가 512바이트 이상인 컬럼이 있는 경우
GROUP BY, DISTINCT 컬럼 중 길이가 512바이트 이상인 컬럼이 있는 경우
메모리 임시 테이블의 크기가 temporable_max_ram 변수보다 큰 경우

옵티마이저와 ORDER BY 처리

EXPLAIN 명령어로 실행 계획을 확인하다 보면 EXTRA 컬럼에 using filesort라는 문구를 종종 확인 할 수 있습니다.

이는 filesort 방식으로 정렬처리가 되었다는 뜻인데, 즉 인덱스를 타지 않는 방식으로 정렬된 것입니다.

옵티마이저는 크게 3가지 방법으로 정렬을 처리합니다.

추가로 ORDER BY에서 인덱스를 사용하게 되면 MySQL에서 '스트리밍 방식'으로 데이터를 처리하여 빠른 응답이 가능하지만

인덱스를 사용하지 않는 경우에는 '버퍼 방식'으로 데이터를 전달하기에 속도에 차이가 있습니다.

(하지만 JDBC는 기본적으로 '버퍼 방식'을 사용하기에 MySQL에서 스트리밍 방식으로 전달해주어도 JDBC를 통해 응답받게 되면 결국 '버퍼 방식'입니다.)

1. 인덱스를 이용한 처리

인덱스를 이용한 정렬 처리입니다.

EXTRA 컬럼에 별도 내용이 표기되지 않습니다.

인덱스를 통해 읽는 경우에는 실제 인덱스의 값이 정렬되어 있기에 순서대로 데이터를 읽어오면 됩니다. (정렬을 위한 별도 작업 X)

B-Tree인덱스에서만 유효하고,

ORDER BY에 명시된 컬럼이 드라이빙 테이블에 속하고, 인덱스가 생성된 순서대로 ORDER BY의 정렬조건에 있어야합니다.

또한 WHERE조건의 첫번째 컬럼과 ORDER BY는 같은 인덱스를 탈 수 있어야 합니다.

여러 테이블이 조인되는 상황에서는 Nested-Loop 방식에서만 유효합니다.

2. Using filesort를 이용한 처리

filesort 방식은 정렬 작업이 쿼리 실행 시 실행되므로 레코드수가 적으면 인덱스 정렬보다는 빠르지만

레코드가 많다면 속도가 느립니다.

filesort 방식을 사용하는 시점은 아래와 같습니다.

정렬 기준이 많아서 모든 요건별 인덱스 생성이 불가능한 경우
GROUP BY의 결과나 DISTINCT 처리결과를 정렬해야하는 경우
임시테이블의 결과를 정렬해야하는 경우 (union등)
랜덤하게 레코드를 가져와야하는 경우

MySQL은 정렬 시 정렬 버퍼(sort buffer)라는 메모리 공간을 사용하는데,

버퍼의 크기보다 많은 양의 데이터를 읽을때는 버퍼에 담지 못한 데이터를 임시로 디스크에 기록해둡니다.

즉 모든 데이터를 정렬하기 위해서는 계속해서 디스크 읽기가 발생하게됩니다.

(이 작업을 Multi Merge라고 하며 이 횟수는 Sort_merge_passes 변수에 기록되며 SHOW STATUS VARIABLE 명령어로 확인 가능합니다.)

filesort 시 옵티마이저가 사용하는 정렬 방식

1. sort_key, row_id (투 패스 방식)

정렬하는 key와 row_id만 가져와서 정렬하는 방식입니다.

클라이언트 쿼리에서 정렬key와 row_id 외 다른 컬럼이 있다면 정렬 후 추가로 필요한 컬럼을 다시 디스크에서 가져와야하기에 추가 작업이 필요합니다.

BLOB이나 TEXT 컬럼이 있다면 MySQL은 반드시 해당 방식으로 정렬합니다.

정렬할 레코드가 적다면 효율적인 방식입니다.

2. sort_key, additional_fields (싱글 패스 방식)

정렬하는 key와 레코드 전체를 가져와서 정렬하는 방식입니다.

레코드의 컬럼들은 고정사이즈로 메모리에 저장됩니다.

정렬할 레코드가 많다면 효율적인 방식입니다.

3. sort_key, packed_additional_fields (싱글 패스 방식)

정렬하는 key와 레코드 전체를 가져와서 정렬하는 방식입니다.

레코드의 컬럼들은 가변사이즈로 메모리에 저장됩니다.

정렬할 레코드가 많다면 효율적인 방식입니다.

옵티마이저에서 EXTRA 컬럼에 나타나는 file sort 방식은 크게 2가지로 구분됩니다.

2-1. Using filesort (조인에서 드라이빙 테이블만 정렬)

드라이빙 테이블의 컬럼만으로 ORDER BY 절의 조건 작성

드라이빙 테이블만으로 ORDER BY에 조건을 주게되면

먼저 드라이빙 테이블에서 데이터를 가져온 뒤 검색결과를 ORDER BY의 조건을 기준으로 filesort합니다.

2-2. Using temporary; Using filesort (조인에서 조인결과를 임시테이블로 저장 후 정렬)

임시 테이블에 저장된 데이터를 정렬할 때

쿼리에 따라서 join된 테이블들이 임시 테이블에 저장될 수 있는데,

마지막에 쿼리 결과를 보여주기 위해 정렬 할 때 그 임시테이블을 정렬해야하기에 가장 느린 방법입니다.

임시테이블에 저정된 데이터를 정렬하게 될 때 Using tempoary가 사용됩니다.

마지막으로 아래와 같은 명령어를 통해 정렬 관련한 MySQL의 상태를 확인 할 수 있습니다

SHOW STATUS LIKE 'Sort%';

옵티마이저와 GROUP BY 처리

GROUP BY또한 ORDER BY와 같이 인덱스를 사용할수도 사용하지 못할수도 있습니다.

사용하지 못한다면 임시 테이블을 사용합니다.

(ORDER BY와 동일하게 인덱스를 사용하면 스트리밍 방식, 사용하지 않으면 버퍼 방식입니다.)

추가로 HAVING 에 사용된 조건절은 인덱스를 탈 수 없습니다.

인덱스 스캔을 이용하는 GROUP BY (타이트 인덱스 스캔)

조인의 드라이빙 테이블에 속한 컬럼만을 조건으로 GROUP BY 조건을 주었을 때

GROUP BY가 인덱스를 통해 처리되어도 그룹 함수 등의 그룹값을 처리해야 할 때에는 임시테이블이 필요할때도 있습니다.

ORDER BY와 동일하게 인덱스를 통해 처리되면 EXTRA 컬럼에 별도의 문구가 뜨지 않습니다.

루스 인덱스 스캔(Loose index scan)을 이용하는 GROUP BY

단일 테이블에서만 수행되는 GROUP BY에서만 적용됩니다.
Prefix Index (컬럼 앞쪽 일부만 사용하는 인덱스)에서는 사용이 불가능합니다.

Loose index scan은 인덱스의 레코드를 건너뛰며 필요한 레코드들을 가져오는 방식입니다.

분포도가 좋지 않을수록 좋은 성능을 낼 수 있습니다.

이때는 EXTRA컬럼에 Using index for group-by 라고 표시됩니다.

임시 테이블을 이용하는 GROUP BY

인덱스를 사용하지 못할 때 사용되는 방식입니다.

EXTRA 컬럼에 Using Temporary라는 문구가 표시됩니다.

MySQL에서는 GROUP BY가 필요할 때 GROUP BY절의 컬럼들로 구성된 유니크 인덱스를 가진 임시 테이블을 만들어 중복제거와 집합함수 연산을 수행합니다.

그 후 join의 결과를 가져와 한건씩 임시테이블에서 중복체크를 하며 별도의 정렬작업 없이 INSERT, UPDATE 작업을 진행 후 반환합니다.

DINSTINCT 처리

DISTINCT는 임시테이블과 함께 사용될 때에도 Using Temporary 문구가 나오지 않습니다.

추가로 SELECT에서 유니크한 레코드만 가져오려고 할 때 DISTINCT를 사용하면 GROUP BY와 동일한 방식을 통해 MySQL에서 데이터를 가져옵니다.

아래와 같이 DISTINCT를 사용하면 user_id만 DISTINCT되서 나오지 않고 user_id, user_name SELECT절의 모든 컬럼에 대해서 적용됩니다.

DISTINCT는 함수가 아니기에 뒤에 괄호를 자체적으로 제거합니다.

SELECT DISTINCT(user_id), user_name FROM EMP

하지만 아래와 같이 집합함수 내에서 사용한다면 해당 컬럼에 대해서만 적용됩니다.

SELECT COUNT(DISTINCT user_id) FROM EMP

조인 버퍼 (Join Buffer)

옵티마이저에서 Join을 사용할 때 어떠한 방식으로도 Full Table Scan이나 Index Full Scan을 피할 수 없다면

드라이빙 테이블에서 읽은 레코드를 메모리에 캐시한 후 드리븐 테이블과 캐시한 메모리를 Join하는 형태로 처리합니다.

이 때 사용하는 메모리 캐시를 조인 버퍼(Join Buffer)라고 합니다.

조인 버퍼는 사용후 바로 해제됩니다.

추가로 MySQL구조에서 조인처리는 MySQL엔진에서 처리하지만 실제 데이터를 읽는곳은 스토리지 엔진입니다.

Nested Loop Join (조인 버퍼 사용 X)

Nested Loop Join은 드라이빙 테이블의 레코드를 한건 읽어서 드리븐 테이블의 일치하는 레코드들을 찾아서 조인을 수행하는 방식입니다. (일반적인 2중 for문 방식이라고 생각하시면 편할 것 같습니다.)

Join을 위한 인덱스나 정렬과 같은 부가적인 기능을 따로 사용하지 않습니다.

Block Nested Loop Join (조인 버퍼 사용 O)

MySQL에서 사용되는 대부분의 Join방식은 Block Nested Loop Join입니다.

Join의 연결이 되는 조건 컬럼에 인덱스가 있는 경우 사용되는 방식입니다.

MySQL은 조인 대상 테이블 중 하나(드라이빙 테이블 혹은 레코드가 작은 테이블)로부터 레코드를 읽어서 그대로 조인버퍼에 버퍼링합니다.

즉 드라이빙 테이블의 레코드를 읽어서 바로 join하지 않고 조인버퍼에 조인 대상을 버퍼링을 해둡니다.

조인버퍼가 가득 차면 그 때 MySQL엔진은 버퍼링된 레코드를 스토리지엔진으로 한번에 요청합니다.

EXTRA 컬럼을 통해 Join방식을 확인 할 수 있습니다 (8.0.20 버전 부터는 Block Nested Loop Join이 사용되지 않고 Hash Join 방식이 사용되어 block nested loop 방식 및 EXTRA 컬럼에 해당 방식이 나오지 않을 수 있습니다.)

인덱스 머지 (index_merge)

대부분 옵티마이저는 테이블당 하나의 인덱스만 사용하도록 실행계획을 수립합니다.

하지만 종종 하나의 테이블에 대해 2개 이상의 인덱스를 사용해서 쿼리를 사용합니다.

쿼리에 사용된 각 조건이 서로다른 인덱스를 사용 할 수 있고, 그 조건을 만족하는 레코드가 많을것으로 예상될 때 MySQL서버는 인덱스 머지를 사용합니다.

Index_merge_intersection (교집합)

EXTRA 컬럼에 Using intersect 가 표시된다면 '인덱스 머지 교집합'이 사용된겁니다.

쿼리가 여러개의 인덱스를 각각 검색하여 그 결과의 교집합만 반환했다는 의미입니다.

Index_merge_union (합집합)

WHERE절에 사용된 2개 이상의 조건이 각각의 인덱스를 사용하되 OR연산자로 연결된 경우에 사용하는 최적화 방식입니다.

각 조건에서 사용할 수 있는 인덱스의 각각의 검색결과를 Union 알고리즘으로 병합했다는 의미입니다.

두 인덱스에서 중복된 레코드가 가져와 질 수 있는데 테이블의 PK와 우선순위큐를 이용해서 데이터를 병합하기에 별도의 중복 제거 작업은 하지 않습니다.

Index_merge_sort_union (정렬 후 합집합)

인덱스 머지 작업 중 정렬이 필요한 경우는 반드시 존재합니다. (pk로 필터링 불가 등)

그럴 경우에는 중복 제거를 위해 정렬을 해야하는데 Index_merge_sort_union 방식의 sort_union 알고리즘을 사용하며

EXTRA 컬럼에 sort_union 방식이 사용되었다고 표기됩니다.

세미 조인 (semijoin)

실제 join을 수행하지 않고, 다른 테이블에서 조건에 일치하는 레코드의 유무를 체크하는 형태의 쿼리를 의미합니다.

아래와 같은 쿼리에서 원래 MySQL은 employees 테이블을 조회하고 그 후 조건에 있는 IN절의 결과와 비교해서 데이터를 처리합니다.

하지만 실제로 데이터를 조회 할 때에는 semijoin 최적화 기능으로 인하여 IN 절의 조건 dept_emp 테이블을 먼저 조회하고 employees 테이블과 비교합니다.

테이블 풀-아웃 최적화(Table Pull-out)

세미조인 서브쿼리에서만 사용 가능합니다.
서브쿼리 부분이 유니크 인덱스, 프라이머리 키 룩업으로 결과가 1건 일 때 사용 가능합니다.
서브 쿼리의 테이블을 아우터 쿼리로 가져와서 최적화를 수행하기에, 모든 서브쿼리 테이블이 아우터 쿼리로 가져와 질 수 있다면, 서브쿼리 자체는 사라집니다.
'서브쿼리를 최대한 풀어서 사용하라'는 튜닝 가이드가 많은데, Table Pull-out최적화는 해당 가이드를 그대로 실행합니다.
EXTRA 컬럼에 별도로 표기되지 않습니다. 실행계획의 id값으로 해당 최적화 사용 여부를 확인 가능합니다.

세미조인 상황에서 서브쿼리에 사용된 테이블을 아우터 쿼리로 꺼낸 후 쿼리를 join쿼리로 재작성하는 최적화 방식입니다.

아래와 같은 세미조인 형태의 쿼리의 실행계획을 확인해 보았을 때 실행계획의 id값이 동일하다면 서브쿼리 방식이 아닌 join방식으로 처리되었다는 뜻이기에 결국 테이블 풀-아웃 최적화 방식이 사용되었다는 의미로 이해할 수 있습니다.

보다 정확한 확인을 위해서는 SHOW WARNINGS 명령어로 옵티마이저가 재작성한 쿼리를 직접 확인하는 방법도 있습니다.

퍼스트 매치 (FirstMatch)

서브쿼리에서 하나의 레코드만 검색되면 이후 탐색을 멈추는 방식이기에, 그 서브쿼리가 참조하는 모든 아우터 테이블이 조회된 후 실행됩니다.
EXTRA 컬럼에는 FirstMatch(table-N)이 표시됩니다.
최적화는 상관 서브쿼리에도 적용 가능합니다.
GROUP BY나 집합함수가 사용된 최적화에서는 사용 할 수 없습니다.

In형태의 세미조인을 EXIST 형태로 튜닝한 것과 비슷한 방식으로 최적화를 진행합니다.

외부 테이블의 각 행에 대해 서브쿼리의 테이블과 비교해가며 조건이 맞는 행을 찾으면 더 이상 서브쿼리의 테이블을 조회하지 않고

외부 테이블의 다른 행을 기준으로 다시 서브쿼리의 테이블과 비교하는 최적화 방식입니다.

루스 스캔(Loose scan)

EXTRA 컬럼에서 LooseScan으로 표시됩니다.

Loose Index scan으로 서브쿼리 테이블을 읽고, 그 다음 아우터 테이블을 드리븐 테이블로 사용해서 조인을 수행합니다.

아래와 같은 쿼리에서 dept_no로 그룹핑해서 서브쿼리의 테이블의 데이터를 읽어온 다음 departments 테이블과 join을 수행합니다.

구체화 (Materialization)

사용된 임시테이블의 select_type에는 Materlized 라고 표시됩니다.
다른 서브쿼리 최적화와 다르게, 서브쿼리 내에 GROUP BY절이 있어도 사용 가능합니다.
In 절에서 서브쿼리는 상관 서브쿼리가 아니어야합니다.

세미조인에 사용된 서브쿼리를 임시테이블을 사용하여 통째로 구체화하여 최적화 하는 방식입니다.

사용된 임시테이블의 select_type에는 Materlized 라고 표시됩니다.

중복제거(Duplicated Weed-out)

상관 서브쿼리라도 사용 가능합니다.
서브쿼리가 GROUP BY, 집합함수가 사용되었으면 사용 할 수 없습니다.
서브쿼리의 테이블을 JOIN으로 처리하기에 최적화 할 수 있는 방법이 많습니다.

세미조인 서브쿼리를 INNER JOIN 쿼리로 바꾸어 실행하고 마지막에 중복된 레코드를 제거하는 방식입니다.

INNER JOIN + GROUP BY를 실행하는것과 동일한 작업으로 쿼리를 처리합니다.

임시테이블을 사용하기에 start tempoary , end tempoary 문구가 사용되며 그 두 구간 사이에서 중복제거 최적화가 일어났다고 생각하면 됩니다.

컨디션 팬아웃 (condition_fanout_filter)

드라이빙 테이블에서 주어진 조건들에 대해서 드리븐 테이블의 행들이 얼마나 일치할지 예측하는 컬럼입니다.

옵티마이저가 정확한 예측을 할 수 있다면 더 빠른 실행계획을 만들 수 있고,

condition_fanout_filter 최적화 옵션이 활성화 되어있다면 아래 두 경우에 대해서 보다 정확한 예측을 할 수 있습니다.

WHERE조건에 사용된 컬럼에 인덱스가 있는 경우
WHERE조건에 사용된 컬럼에 히스토그램이 존재하는 경우

옵티마이저는 레인지 옵티마이저, 히스토그램, 인덱스의 통계 정보, 추측 순서대로 우선도를 두어 예측을 진행합니다.

파생 테이블 머지 (derived_merge)

아래와 같이 FROM절에 사용되는 서브쿼리를 외부쿼리와 병합하는 최적화입니다.

SHOW WARNINGS 명령어로 최적화된 쿼리를 확인 할 수 있습니다.

하지만 몇몇 상황에 대해서는 derived_merge가 사용될 수 없기에 아래와 같은 경우에는 수동으로 병합하는것이 좋습니다.

집계함수 및 윈도우 함수가 사용된 쿼리
DISTINCT가 사용된 서브쿼리
GROUP BY, HAVING이 사용된 서브쿼리
LIMIT, UNION, UNION ALL을 포함하는 사용된 서브쿼리
SELECT 절에 사용된 서브쿼리
값이 변경되는 사용자 변수가 사용된 서브 쿼리

스킵 스캔 (skip scan)

인덱스를 사용하려면 인덱스가 생성된 순서대로 쿼리를 작성하여야합니다.

인덱스 스킵 스캔은 제한적이긴 하지만 앞서 언급한 인덱스의 제약을 뛰어 넘을 수 있는 최적화 방법입니다.

즉 인덱스의 후행컬럼만을 조건으로 사용해도 인덱스를 사용하여 쿼리 개선을 할 수 있습니다.

대신 인덱스의 선행컬럼이 소수의 유니크한 값을 가질때만 적용됩니다.

해시 조인 (Hash Join)

해시조인은 Best Throughput 전략에 적합하고 네스티드 루프 조인은 Best Response-time 전략에 적합합니다.

그렇기에 일반적인 웹서비스에서는 네스티드 루프 조인이 더 좋은 방식일때가 많지만,

분석과 같은 서비스에서는 해시조인이 더 좋은 방식일 수 있습니다.

MySQL에서는 조인 컬럼이 인덱스가 없거나, 조인 대상 테이블 중 일부의 레코드건수가 매우 적을 때에만 해시조인 알고리즘을 사용합니다.

해시조인은 빌드(build)단계와 프로브(probe)단계로 나뉘어집니다.

빌드 단계 (build phase)

조인 대상 테이블 중 레코드 건수가 적어 해시테이블로 만들기 적합한 테이블을 골라서 메모리에 해시테이블을 생성하는 작업입니다.

만들어진 해시 테이블은 조인버퍼에 저장됩니다.

프로브 단계 (probe phase)

나머지 테이블의 레코드를 읽어 만들어둔 해시테이블과 일치하는 레코드를 찾는 과정입니다.

이 때 나머지 테이블을 프로브 테이블이라 합니다.

NandToTetris-Hardware simulator / 조합 게이트 실습-밑바닥부터 만드는 컴퓨팅 시스템

겅겅겅 — Thu, 19 Dec 2024 22:39:24 +0900

친구의 추천을 받아 '밑바닥부터 구현하는 컴퓨팅 시스템'책을 읽고있습니다.

직접 구현해보는 내용들이 좀 있이서,

공부 내용 정리 및 학습 목적으로 책에서 진행한 실습들을 포스팅해보려 합니다.

실습은 공식 사이트에서 Web IDE를 통해 진행하였습니다.

공식사이트 주소

https://www.nand2tetris.org/software

Software | nand2tetris

Two OS implementations are supplied: (i) a collection of eight .vm class files, written originally in Jack (just like Unix is written in C), and (ii) a faster implementation of all the OS services, embedded in the supplied VM Emulator.

www.nand2tetris.org

웹 IDE 주소

https://nand2tetris.github.io/web-ide/chip/

NAND2Tetris

nand2tetris.github.io

NandGate

NandToTetris에서 기초가 되는 NandGate의 진리표입니다.

NotGate

0이 들어오면 1, 1이 들어오면 0 을 출력하는 게이트입니다.

Not의 경우 NandGate를 그대로 활용하면 원하는 출력을 얻을 수 있습니다.

HDL의 PARTS 섹션에서는 하위 칩들을 사용해 논리를 구현하며, 핀에 신호를 전달하는 과정을 표현합니다.

Nand칩을 사용해 두 입력핀 a,b로부터 out이라는 신호를 생성 후 외부로 전달합니다.

CHIP Not {
    IN in;
    OUT out;

    PARTS:
    Nand(a= in, b= in, out=out);
}

AndGate

1과1이 들어올때는 1, 나머지는 0을 출력하는 AndGate입니다.

Nand과 앞서 만들어둔 Not을 활용하여 만들 수 있습니다.

Nand칩에서 aNandb라는 임시 내부 신호를 만들고 Nand의 출력핀 out이 신호를 Not칩으로 전달합니다.

CHIP And {
    IN a, b;
    OUT out;
    
    PARTS:
    Nand(a= a, b= b, out= NandAB); 
    Not(in= NandAB, out= out);
}

OrGate

a,b 둘중 하나라도 1이면 1을 출력합니다.

두 신호를 Not하고 각각 변경된 신호를 Nand 게이트에 전달합니다.

CHIP Or {
    IN a, b;
    OUT out;

    PARTS:
    Not(in=a, out=notA);
    Not(in=b, out=notB);
    Nand(a= notA, b=notB, out=out );
}

XorGate

두 입력값 중 하나만 1일 때 1을 나머지는 0을 반환합니다.

Not, And, Or을 활용해서 만들 수 있습니다.

CHIP Xor {
    IN a, b;
    OUT out;

    PARTS:
    Not(in=b, out=notB);
    Not(in=a, out=notA);
    And(a=a, b=notB, out=aAndNotB);
    And(a=notA, b=b, out=notAAndB);
    Or(a=aAndNotB, b=notAAndB, out=out);
}

멀티플렉서 (MUL, Selector)

a,b의 데이터 비트와 sel 선택비트 3가지 input을 가집니다.

a,b 중 sel에 의해 선택된 값을 out으로 내보냅니다.

CHIP Mux {
    IN a, b, sel;
    OUT out;

    PARTS:
    Not(in=sel, out=NotSel);
    And(a=a, b=NotSel, out= aAndNotSel);
    And(a=b, b=sel, out= bAndSel);
    Or(a= aAndNotSel, b=bAndSel, out=out);
}

디멀티플렉서

멀티플렉서와 반대의 기능을 합니다.

in과 입력신호(sel)를 각각 하나씩 받아서 2개의 출력(a,b)으로 전달하는데, 입력신호(sel)가 0이면 a에 in을 1이면 b에 in을 전달합니다.

in이 전달되지 않는 신호에는 0을 전달합니다.

CHIP DMux {
    IN in, sel;
    OUT a, b;

    PARTS:
    Not(in= sel, out=NotSel);
    And(a=in, b=NotSel , out=a);
    And(a=in , b=sel , out=b );
}

16BIT And, Or, Not, Mux

16비트 게이트들은 단순하게 앞에서 작업했던 And, Not, Or, Mux들을 각 비트에 맞게 16번씩 반복해주면 됩니다.

Or8Way (M입력 Or)

다입력되는 m개의 비트 중 적어도 하나가 1이면 1을 출력하는 게이트입니다.

들어오는 모든 bit를 순서대로 OR게이트로 비교하면 원하는 결과를 얻을 수 있습니다.

CHIP Or8Way {
    IN in[8];
    OUT out;

    PARTS:
    Or(a=in[0] , b=in[1] , out=out1 );
    Or(a=out1 , b=in[2] , out=out2 );
    Or(a=out2 , b=in[3] , out=out3 );
    Or(a=out3 , b=in[4] , out=out4 );
    Or(a=out4 , b=in[5] , out=out5 );
    Or(a=out5 , b=in[6] , out=out6 );
    Or(a=out6 , b=in[7] , out=out );
}

Mux4Way16 (M입력 N비트 멀티플렉서)

m개의 n비트 입력 중 하나를 선택해서 n비트 출력으로 전달합니다.

00이면 a, 01이면 b, 10이면 c, 11이면 d를 출력합니다.

참고로 2진수에서는 오른쪽이 하위 비트이기에 sel이 01이라면 sel[0]은 1, sel[1]은 0입니다.

CHIP Mux4Way16 {
    IN a[16], b[16], c[16], d[16], sel[2];
    OUT out[16];
    
    PARTS:
    Mux16(a=a, b=b, sel=sel[0] , out=aMuxb);
    Mux16(a=c, b=d, sel=sel[0] , out=cMuxd);
    Mux16(a=aMuxb , b=cMuxd , sel=sel[1] , out=out );    
}

Mux8Way16 (M입력 N비트 멀티플렉서)

Mux8Way16은 앞서 만들었던 Mux4Way16을 이용해서 구현할 수 있습니다.

CHIP Mux8Way16 {
    IN a[16], b[16], c[16], d[16],
       e[16], f[16], g[16], h[16],
       sel[3];
    OUT out[16];

    PARTS:
    Mux4Way16(a=a , b=b , c=c , d=d , sel=sel[0..1] , out=abMuxCd);
    Mux4Way16(a=e , b=f , c=g , d=h , sel=sel[0..1] , out=efMuxGh);
    Mux16(a=abMuxCd , b=efMuxGh , sel=sel[2] , out=out);
}

DMux4Way (M입력 N비트 디멀티플렉서)

멀티플렉서와 반대의 기능을 합니다.

들어온 sel에 따라 a,b,c,d로 출력을 전달합니다.

CHIP DMux4Way {
    IN in, sel[2];
    OUT a, b, c, d;

    PARTS:
    DMux(in=in, sel=sel[1], a=in1, b=in2);
    DMux(in=in1, sel=sel[0], a=a, b=b);
    DMux(in=in2, sel=sel[0], a=c, b=d);  
    
}

DMux8Way (M입력 N비트 디멀티플렉서)

앞서 만들었던 DMux4Way를 활용해서 만들 수 있습니다

CHIP DMux8Way {
    IN in, sel[3];
    OUT a, b, c, d, e, f, g, h;

    PARTS:
    DMux(in=in, sel=sel[2], a=in1, b=in2);
    DMux4Way(in=in1, sel=sel[0..1], a=a, b=b, c=c, d=d);
    DMux4Way(in=in2, sel=sel[0..1], a=e, b=f, c=g, d=h);
}

참고용 부록 진리표

InnoDB 아키텍쳐를 알아보자

겅겅겅 — Thu, 12 Dec 2024 21:39:26 +0900

요즘 APM을 만드려고 하다보니 오픈소스의 아키텍쳐에 대한 관심이 높아져서

Real MySQL을 보고 공부한 InnoDB의 아키텍쳐를 정리해보고자 합니다.

책에서 언급하는 8.0이하에서 발생한 이슈들이나 정보들은 정리하지 않았습니다.

InnoDB 아키텍쳐

레코드 기반 Lock을 제공하기에 높은 동시성 처리가 가능하며 안정적인 엔진입니다.

MySQL에서 기본적으로 사용하는 스토리지 엔진입니다.

InnoDB의 특징

primary key에 의한 클러스터링

InnoDB에 저장되는 테이블 레코드들은 기본적으로 pk에 의해 클러스터링 되어 pk값 순서대로 저장됩니다.

그렇기에 pk를 이용한 레인지 스캔은 빠른 속도로 처리 될 수 있습니다.

또한 세컨더리 인덱스는 레코드의 실제 주소가 아닌 pk의 값을 논리적인 주소로 사용해서 InnoDB의 데이터를 가져옵니다.

foreign key 지원

InnoDB스토리지 엔진 레벨에서 지원하는 기능으로 MyISAM이나 MEMORY테이블에서는 사용할 수 없습니다.

InnoDB에서 fk를 사용하기 위해서는 부모, 자식 테이블 모두 해당 컬럼에 인덱스 생성이 필요하고, 변경시 부모,자식 테이블 모두에게서 데이터가 있는지, 데드락이 걸릴 수 있는 상황 등 고려할 여러 상황들이 많기에 주의해서 사용할 필요가 있습니다.

foreign_key_checks 시스템 변수를 OFF로 설정하면 fk체크 작업을 일시적으로 멈출 수도 있습니다.

SET foreign_key_checks=OFF;
SET SESSION foreign_key_checks=OFF;

MVCC (Multi Version Concurrency Control)

트랙잭션간 다중 동시성 제어를 위한 기능입니다.

즉 트랜잭션 간의 읽기와 쓰기간 작업이 충돌하지 않도록 합니다.

MVCC의 MV(Multi Version)는 하나의 레코드에 대해 여러개의 버전이 동시에 관리된다는 의미입니다.

InnoDB는 Undo Log를 이용하여 MVCC를 구현합니다.

위와 같은 쿼리들이 실행되면 InnoDB에서는 아래 그림과 같은 상황이 됩니다.

버퍼 풀에 작업한 쿼리 내용이 존재하고 디스크에도 동일하게 존재합니다.

이후 아래와 같은 UPDATE문을 실행하면 아래 그림과 같은 상태가 됩니다.

UPDATE 내용을 COMMIT여부와 관계없이 버퍼풀에 반영합니다.

이후 변경되기 전 내용을 언두로그에 보관합니다.

디스크에 변경을 기록하는건 InnoDB의 백그라운드 스레드 (Write Thread)가 작업하기에 UPDATE명령 후 바로 디스크에 업데이트 될 수도 있고 아닐 수도 있습니다.

UPDATE문 이후 COMMIT을 하면 버퍼풀의 내용을 디스크에 영구적으로 저장하고,

ROLLBACK을 하면 언두영역의 데이터를 버퍼풀로 복구하고 언두영역의 데이터를 삭제합니다.

언두 영역의 데이터는 COMMIT이 되었을때 사라지는건 아니고 언두영역을 필요로하는 트랜잭션이 없을때 사라집니다.

위와 같은 구조로 InnoDB가 동작하기에 두가지 버전 (Multi Version)을 관리한다고 하는것이며 어디에 있는 데이터를 읽어올지는 MySQL의 격리수준(Isolation level)에 따라 다를 수 있습니다.

READ_UNCOMMITTED의 경우에는 버퍼풀의 데이터를,

READ_COMMITTED나 그 이상의 격리수준(REPEATABLE_READ, SERIALIZABLE)의 경우에는 아직 COMMIT되지 않았기에 버퍼풀이나, 언두영역의 데이터를 반환합니다.

이러한 작업과 과정을 MVCC라고 표현합니다.

잠금 없는 읽관된 읽기 (Non-Locking Consistent Read)

InnoDB 스토리지엔진은 MVCC를 이용하기에 읽기 작업 시 잠금을 걸지 않습니다.

그렇기에 격리 수준 SERIALIZABLE이 아니라면 INSERT와 관련없는 순수한 읽기 작업은 다른 트랙잭션의 변경 작업과 관계없이 없이 바로 실행됩니다.

즉 다른 사용자가 특정 레코드를 변경하고 COMMIT하지 않았다고 해도 이 트랜잭션이 다른 사용자들의 SELECT를 방해하지 않습니다. (다른 사용자들은 대부분 언두로그를 통해 데이터를 읽음, 격리수준에 따라 다를 수 있음)

이를 '잠금 없는 읽관된 읽기' Non-Locking Consistent Read라고 합니다.

종종 오랜시간 활성된 트랜잭션으로 인해 MySQL서버가 느려진다면 Consistent Read를 위해 InnoDB가 언두로그를 삭제하지 못하고 계속 유지하고 있어서 그런 것일 수 있으니, 트랜잭션은 시작되었다면 가능한 빨리 종료되어야 합니다.

자동 데드락 감지

InnoDB 스토리지 엔진은 내부적으로 잠금이 교착상태에 빠지지 않았는지 잠금 대기 목록을 그래프 형태(Wait-for List)로 관리합니다.

스토리지 엔진은 데드락 감지 스레드를 가지고 있어 주기적으로 잠금 대기 그래프를 검사해 교착상태의 트랜잭션을 찾아 그중 하나를 강제 종료합니다.

종료되는 트랜잭션의 기준은 언두 로그의 양이며, 언두로그를 더 적게 가진 레코드가 일반적으로 롤백 대상이 됩니다.

InnoDB엔진은 상위 레이어인 MySQL엔진에서 관리되는 테이블 잠금(LOCK TABLES 명령으로 잠긴 테이블)은 확인 할 수 없어

데드락 감지가 불확실하기에 innodb_table_locks 시스템 변수를 활성화하여 InnoDB 스토리지 엔진 내부 잠금뿐 아니라 테이블 레벨의 잠금까지 감지하도록 활성하하는게 좋습니다.

동시 처리되는 스레드나 각 트랜잭션의 잠금의 개수가 많아지면 데드락 감지 스레드가 느려집니다.

데드락 감지 스레드는 잠금 목록을 검사하기에 잠금 상태가 변경되지 않도록 잠금 목록이 저장된 리스트(잠금 테이블)에 새로운 잠금을 걸고 데드락 스레드를 찾습니다

데드락 감지 스레드가 느려지면 서비스 쿼리를 처리중인 스레드는 더는 작업을 하지 못하고 대기하게 되므로 서비스에 악영항을 끼칠 수 있습니다.

위와 같은 상황에 대비하여 innddb_deadlock_detect 변수를 통해 데드락 감지 스레드를 OFF할 수 있으나

데드락 감지 스레드가 작동하지 않으면 InnoDB스토리지 엔진에서 2개 이상의 트랜잭션이 데드락이 걸리게 된다면 무한정 대기하게 될 것 입니다.

하지만 innodb_lock_wait_timeout 변수(기본값 50초)를 활성화하여 데드락 상황이 지정한 시간만큼 지나게 되면 에러를 반환하게 할 수 있습니다

InnoDB 버퍼풀

디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해두는 InnoDB의 가장 핵심적인 기능입니다.

쓰기작업을 지연시켜 일괄적으로 처리할 수 있게 해주는 버퍼 역할도 같이하고있습니다.

INSERT, UPDATE, DELETE처럼 데이터를 변경하는 쿼리는 레코드 데이터에 직접 접근해야하기에 매번 랜덤I/O를 발생시킬 수 밖에 없습니다.

그렇기에 버퍼풀을 이용해서 변경된 데이터를 모아서 처리하면 랜덤I/O 작업을 줄일 수 있습니다.

버퍼풀 크기(Memory) 설정

운영체제와 각 클라이언트 스레드가 사용할 메모리를 충분히 고려해서 설정해야합니다.

MySQL서버에서 메모리를 필요로하는 부분은 크게 없지만 가끔 클라이언트 세션에서 테이블의 레코드를 읽고 쓸 때 버퍼로 사용되는 '레코드 버퍼'가 상당한 메모리를 사용하는 경우도 있습니다.

그렇기에 커넥션과 테이블 모두 많은 서비스라면 메모리공간이 꽤 많이 필요할수도 있습니다

레코드 버퍼의 크기는 전체 커넥션수와 각 커넥션에서 읽고 쓰는 테이블 개수에 따라 달라집니다.

다시 버퍼풀의 크기 이야기로 넘어와서, 운영체제의 공간이 8GB 미만이라면 50%정도만 InnoDB버퍼풀로 설정하는게 좋습니다

더 여유가 있는 운영체제를 사용한다면 전체 메모리의 50%에서 시작해서 조금씩 올려가며 최적점을 찾습니다.

전체 메모리 공간이 50G이상인 운영체제를 사용한다면 15GB ~ 30GB정도를 다른 프로그램을 위해 남겨두고 나머지를 InnoDB버퍼풀로 설정하는게 권장됩니다.

innodb_buffer_pool_size 시스템 변수로 크기를 설정 할 수 있으며 동적인 크기 확장도 가능합니다.

버퍼풀은 내부적으로 128MB 청크 단위로 쪼개어져 관리되는데, 이는 크리를 늘리는 단위 크기로 사용됩니다.

그래서 버퍼풀은 반드시 128MB단위로 처리됩니다.

버퍼풀은 innodb_buffer_pool_instances 변수를 통해 여러개로 분리하여 관리 할 수도 있습니다.

기본적으로 8개로 초기화됩니다.

매모리가 크다면 버퍼 풀 인스턴스당 5GB정도가 되도록 개수를 설정하는게 좋습니다.

버퍼풀의 구조

InnoDB스토리지 엔진은 버퍼 풀이라는 메모리 공간을 페이지 크기(innodb_page_size 변수에 설정된)로 쪼개어 InnoDB 스토리지 엔진이 데이터를 필요로 할 때 해당 페이지를 읽어서 각 조각에 저장합니다.

버퍼풀의 페이지를 관리하기 위해 LRU(Least Recently Used)리스트와 플러시(Flush)리스트, 그리고 프리(Free)리스트라는 3개의 자료구조를 관리합니다.

프리 리스트는 버퍼풀에서 데이터로 채워지지 않아 비어있는 페이지들의 목록이며, 클라이언트의 쿼리가 새롭게 디스크에서 데이터를 읽어와야하는 경우에 사용됩니다.

프리 리스트는 LRU(Least Recently Used)와 MRU(Most Recently Used)리스트의 결합입니다.

LRU리스트를 관리하는 목적은 디스크로부터 읽어온 페이지를 최대한 오랫동안 InnoDB버퍼풀의 메모리에 유지해서 디스크 읽기를 최소화 하기 위함입니다.

InnoDB 스토리지 엔진에서 디스크로부터 버퍼풀로 데이터를 가져오는 과정은 아래와 같습니다.

1. 필요한 레코드가 저장된 페이지가 버퍼풀에 있는지 확인

- A. InnoDB 어댑티브 해시 인덱스를 이용해 페이지 검색

- B. 해당 테이블의 인덱스를 이용해 버퍼풀에서 검색

- C. 버퍼풀에 이미 페이지가 있다면 해당 페이지의 포인터를 MRU 방향으로 승급

2. 디스크에서 필요한 페이지를 버퍼풀에 적재하고, 적재된 페이지에 대한 포인터를 LRU 헤더 부분에 추가

3. 버퍼풀의 LRU 헤더 부분에 적재된 데이터 페이지가 읽히면 (Read되면) MRU헤더 부분으로 이동

4. 버퍼풀에 상주하는 페이지는 클라이언트 쿼리가 얼마나 최근에 접근했었는지에 따라 Age가 부여되며, 풀에 상주하는 동안 쿼리에서 오랫동안 사용되지 않으면 결국 페이지는 버퍼풀에서 제거됩니다.

버퍼풀의 데이터 페이지가 쿼리에 의해 사용되면 Age가 초기화 되고 MRU의 헤더 부분으로 옮겨집니다.

5. 필요한 데이터가 자주 접근됐다면 해당 페이지의 인덱스 키를 어댑티브 해시 인덱스에 추가합니다.

그렇기에 한번 버퍼풀에 들어간 페이지가 꾸준하게 Read된다면 MRU영역에 계속 존재하게 되고, 사용되지 않는 페이지들은 LRU의 끝으로 밀려나며 결국 버퍼풀에서 제거됩니다.

플러시(Flush)리스트는 디스크와 동기화 되지 않은 페이지 (더티 페이지)의 변경 시점 기준의 페이지 목록을 관리합니다.

디스크에서 읽은 상태 그대로 존재한다면 플러시 리스트에 관리되지 않지만, 변경이 가해진 페이지는 플러시 리스트에 관리되고 특정 시점에 디스크로 기록됩니다.

데이터가 변경되면 InnoDB는 변경 내용을 리두로그, 버퍼풀의 데이터 페이지에 내용을 반영합니다.

그렇기에 리두로그의 각 엔트리는 특정 데이터 페이지와 연결됩니다.

하지만 리두로그가 디스크에 기록되었다고 해서 버퍼풀의 페이지가 디스크로 기록되었다는것을 보장하지는 않습니다.

InnoDB 스토리지 엔진은 체크포인트를 발생시켜 디스크의 리두로그와 버퍼풀의 페이지의 상태를 동기화 시킵니다.

버퍼풀과 리두로그

InnoDB 버퍼풀의 더티 페이지는 특정 리두로그의 엔트리와 관계를 가지고,

체크포인트가 발생하면 체크포인트 LSN보다 낮은 리두로그 엔트리와 관련된 더티 페이지를 모두 디스크로 동기화 시킵니다.

(장애복구 및 데이터 무결성을 위한 디스크 동기화)

이제 리두로그, LSN, 체크포인트에 대해 알아보겠습니다.

리두로그는 서버가 비정상적으로 종료되었을 때 데이터파일에 기록되지 못한 데이터를 잃지 않게 도와줍니다.

리두로그는 1개 이상의 고정 크기 파일을 사용하며 '순환 버퍼 방식'으로 사용됩니다.

데이터 변경이 발생하면 로그 엔트리(리두 로그에 기록되는 단위)가 하나의 리두로그 파일에 계속 쓰여집니다

계속 쓰여지다가 어느 순간 새로운 파일에 쓰여지고 모든 파일에 다 쓰여지면 다시 첫번째 파일에 로그 엔트리가 덮어 쓰여집니다.

InnoDB엔진은 로그 버퍼를 사용하여 리두로그 파일에 버퍼링하여 데이터를 씁니다.

리두로그는 아카이빙해서 보관하는 방법 또한 존재합니다.

리두 로그 파일의 '공간'들에는 새로운 엔트리가 계속해서 덮혀쓰여지기에 로그의 고유ID값 LSN(Log Sequence Number)는 계속해서 증가하게 됩니다.

InnoDB엔진은 주기적으로 체크포인트 이벤트를 발생시켜 리두로그와 버퍼풀의 더티페이지를 디스크로 동기화 시킵니다.

이때 발생한 체크포인트 지점의 로그 엔트리의 LSN 보다 낮은 LSN을 가지는 데이터들을 디스크로 동기화 시킵니다.

이 체크 포인트 지점의 LNS을 기점으로 더 큰 LSN을 가지는 데이터가 있는 공간을 활성 리두 로그 (Active Redo Log)공간,

체크포인트 지점의 LSN보다 낮은 LSN을 가지는 공간 즉 디스크로 동기화된 공간은 재사용 가능 공간(Reuseable Space)으로 구분합니다.

# 체크포인트 발생 시 LSN : 2000
# 2000 이상 LSN을 가지고 있는 공간은 재사용 불가능한 Active Log
# 디스크로 동기화된 2000 이하 LSN을 가지고 있는 공간은 재사용 가능

|-- Reusable Space --|-------- Active Redo Log -------|
| LSN: 1500 ---------| LSN: 2000 ------------ 2500    |

활성 리두 공간 (Active Redo Log)공간의 데이터들은 아직 디스크에 동기화 되지 않았기에 덮어쓰여질 수 없습니다.

만약 체크포인트 이벤트가 적절하게 발생하지 않는다면 재사용 가능 공간을 확보할 수 없기에 문제가 발생 할 수 있습니다.

추가로 가장 최근 체크포인트의 LSN과 마지막 리두 로그 엔트리의 LSN의 차이를 체크포인트 에이지 (CheckPoint Age)라고 하며 이는 활성 리두 공간의 크기를 의미합니다.

버퍼 풀 flush (Buffer Pool Flush) (플러시 리스트 flush, LRU 리스트 flush)

버퍼풀은 크게 데이터 캐시, 쓰기 버퍼링 두가지 기능이 있습니다.

버퍼풀에서 디스크로 기록되지 않은 더티페이지들을 효율적으로 디스크에 동기화 하기 위해 쓰기 버퍼링 기능이 존재하고

쓰기 버퍼링 기능을 구현하기 위해서 '플러시 리스트' flush, 'LRU 리스트' flush 2개의 기능을 백그라운드로 실행시킵니다.

이떄 동기화에 사용하는 스레드를 클리너 스레드(Cleaner Thread) 라고 합니다.

(성능 및 클라이언트 데이터 무결성을 위한 디스크 동기화)

1. 플러시 리스트 플러시

InnoDB엔진은 버퍼풀에 더티페이지가 생성되면 리두로그에도 기록되지만 '플러시 리스트'에도 추가됩니다.

그리고 주기적으로 플러시 리스트(Flush_list)의 flush 함수를 호출해서 플러시 리스트에서 오래전에 변경된 데이터 페이지 순서대로 디스크에 동기화하는 작업을 수행합니다.

이 더티페이지 일괄 처리 작업(flush)이 효율적일수록 클라이언트의 쿼리 처리가 악영향을 받지 않고 부드럽게 처리 될 수 있습니다.

버퍼풀에 더티페이지의 양이 많을 수록 Disk IO Burst 현상이 발생할 가능성이 높아지는데,

버퍼풀의 더티페이지 비중이 90%가 넘어가게 되면 InnoDB엔진은 즉시 디스크 기록을 시작합니다.

이때 Disk IO Burst현상이 발생할 가능성이 매우 높기에 innodb_max_dirty_pages_pct_lwn 변수를 이용해 일정 수준이상의 더티페이지가 발생하면 조금씩 디스크로 기록하도록 하는 설정값을 조정해서 Dist IO Burst현상을 예방 할 수도 있습니다 (기본값10%)

2. LRU 리스트 플러시

스토리지 엔진은 LRU리스트에서 사용빈도가 낮은 데이터 페이지들을 제거해서 새로운 페이지들을 읽어들일 공간을 만드는데,

이를 위해 LRU리스트에서 flush함수가 사용됩니다.

LRU리스트의 끝부분부터 시작해서 최대 innodb_lru_scan_depth 시스템 변수에 설정된 개수만큼 페이지들을 스캔합니다.

스캔하면 디스크에 동기화 작업을 진행하고 클린 페이지는 즉시 Free 리스트로 페이지를 옮깁니다.

LRU 리스트를 flush 함으로서 공간을 확보해 클라이언트의 요청 처리 속도를 개선합니다.

버퍼풀 상태 백업 및 조회방법

버퍼풀은 쿼리 성능에 매우 밀접한 관계가 있습니다.

버퍼풀에 사용할 데이터들이 미리 적재되어 있으면 디스크 읽기 없이 데이터를 클라이언트에 반환 할 수 있기 때문입니다.

이런 상태를 Warning Up상태라고 합니다.

버퍼풀에 대한 백업은 데이터 디렉토리에 ib_buffer_pool이라는 이름의 파일로 생성되는데,

실제 버퍼풀의 크기에 비해 매우 작습니다. (몇십MB 이하)

그 이유는 LRU리스트의 데이터 페이지의 메타 정보만 가져와 저장하기 때문입니다.

버퍼풀에 있는 데이터를 조회하기 위해서는 information_schema 데이터베이스에 innddb_cached_indexs 테이블에서

테이블의 인덱스별로 데이터 페이지가 얼마나 버퍼풀에 적재되어 있는지 확인 할 수 있습니다.

SELECT it.name table_name
      ,ii.name index_name
      ,ici.n_cached_pages n_cached_pages
FROM information_schema.INNODB_TABLES it
INNER JOIN information_schema.INNODB_INDEXES ii on  ii.TABLE_ID = it.TABLE_ID
INNER JOIN information_schema.INNODB_CACHED_INDEXES ici on ici.INDEX_ID = ii.INDEX_ID

테이블 전체 페이지중 어느정도 비율이 InnoDB 버퍼풀에 있는지 확인할수도 있습니다.

SELECT
    t.TABLE_NAME
    ,(SELECT SUM(ici.N_CACHED_PAGES) AS n_cached_pages
     FROM information_schema.INNODB_TABLES it
              INNER JOIN information_schema.INNODB_INDEXES ii ON ii.TABLE_ID = it.TABLE_ID
              INNER JOIN information_schema.INNODB_CACHED_INDEXES ici ON ici.INDEX_ID = ii.INDEX_ID
     WHERE it.name = CONCAT(t.table_schema, '/', t.table_name)
    ) AS total_cached_pages,
    ((t.data_length + t.index_length - t.data_free) / @@innodb_page_size) AS total_pages
FROM
    information_schema.tables t
WHERE
    t.table_schema = 'EMP' and t.TABLE_NAME = 'TB_USER'

Double Write Buffer

파셜 페이지(Partial-page), 톤 페이지(Torn-page)라는 용어가 있습니다.

하드웨어의 오작동이나 시스템의 비정상종료 시 페이지중 일부만 기록되는 현상인데 이는 InnoDB 스토리지 엔진에서 디터 페이지를 디스크 파일로 플러시 할때 일부만 기록되기 떄문에 발생합니다.

이러한 현상을 막기 위해 InnoDB엔진에서는 Double-Write 기법을 사용하니다.

버퍼풀애서 더티페이지를 디스크에 쓰기 전에 데이터페이지들을 적당한 위치에 랜덤I/O 방식으로 먼저 DoubleWrite 버퍼에 기록합니다.

이후 버퍼풀에서 디스크에 쓰기가 성공하면 DoubleWrite 버퍼에 저장해두었던 내용은 사라집니다.

하지만 디스크 쓰기 중 비종상 종료가 되어 재시작을 한 상황이라면

재시작 시 DoubleWrite 버퍼에 있는 내용과 데이터 파일의 페이지 내용을 비교해서 다른 내용이 있으면 DoubleWrite 버퍼의 내용을 데이터 파일의 페이지로 복사합니다.

하지만 SSD와 같이 랜덤I/O가 일어나는 저장시스템에서는 해당 기능의 비용이 다소 들 수도 있습니다.

언두로그 (Undo Log)

InnoDB 스토리지 엔진은 트래잭션과 격리수준을 보장하기 위해 DML로 변경되기 이전 데이터를 별도로 백업해둡니다.

이 백업 데이터를 '언두로그'라고 합니다.

리두로그는 데이터 백업과 장애 복구 시 사용하고, 언두로그는 트랜잭션 보장과 서비스의 격리수준을 보장하기 위해 사용됩니다.

위와 같은 DML이 실행되면 트랜잭션을 커밋하지 않아도 실제 데이터와 인덱스 버퍼에는 UPDATE-MySQL-USER라는 이름으로 변경됩니다.

그리고 변경되기 전 데이터(MySQL-USER)는 언두영역에 백업됩니다.

이 상태로 COMMIT이 일어나면 상태가 유지되고, (언두로그가 바로 삭제되지는 않고 삭제예정 처리(Prune) 됨, 백그라운드 작업으로 삭제)

ROLLBACK되면 언두영역의 백업 데이터를 원래대로 되돌립니다.

DML 쿼리를 통해 트랜잭션에 적용되는 레코드들이 많으면 언두로그에 그만큼의 레코드들이 쌓이게 되어 사용량이 늘어나게됩니다.

그리고 트랜잭션이 오래 실행되면 될수록 언두로그의 사용량에 영향을 미쳐 전반적인 쿼리 성능이 느려지게 됩니다.

MySQL에서 활성상태의 트랜잭션이 장기간 유지되는건 좋지 않습니다.

그래서 MySQL 서버의 언두레코드를 모니터링하는것은 반드시 필요합니다.

언두 레코드 수 확인

SELECT count
FROM information_schema.innodb_metrics
WHERE SUBSYSTEM='transaction' AND NAME = 'trx_rseg_history_len';

언두 테이블스페이스 관리

언두로그는 '언두 테이블스페이스'에서 관리됩니다.

하나의 언두 테이블 스페이스는 1 ~ 128개의 롤백 세그먼트를 가지며, 롤백 세그먼트는 1개 이상의 언두슬롯을 가집니다.

하나의 롤백 세그먼트는 InnoDB 페이지 크기를 16바이트로 나눈 값의 개수만큼 언두 슬롯을 가집니다.

InnoDB 페이지 크기가 16KB라면 롤백 세그먼트는 1024개의 언두슬롯을 가집니다.

하나의 트랜잭션이 필요로하는 언두슬롯 개수는 최대 4개입니다.

하지만 대략적으로 2개정도로 계산해서 최대 통시 처리 가능 트랜잭션 수를 예측 할 수 있습니다.

최대 동시 트랜잭션 수 = (InnoDB 페이지 크기) / 16 * (롤백 세그먼트 개수) * (언두 테이블스페이스 개수)

기본 세팅에서는 대략 131072(16*1024/16*128/2)개의 트랜잭션이 동시에 처리 될 수 있습니다.

아래와 같은 명령어로 언두 테이블 스페이스를 동적으로 생성 및 조절할수도 있습니다.

-- 언두 테이블 스페이스 생성
CREATE UNDO TABLESAPCE
-- 언두 테이블 스페이스 삭제
DROP UNDO TABLESPACE

체인지 버퍼

테이블의 레코드가 변경되면 인덱스 또한 변경이 일어나야합니다.

하지만 인덱스를 읽어 변경하는 작업은 결국 랜덤 I/O작업이 일어나게 되고 이는 상당한 자원소모가 발생합니다.

그렇기에 InnoDB엔진은 변경해야할 인덱스 페이지가 버퍼풀에 있으면 즉시 업데이트를 수행하지만

그렇지 않고 디스크에서부터 읽어서 변경해야한다면 즉시 실행하지 않고 임시공간에 저장해둔뒤 먼저 사용자에게 결과를 반환하고 추후 작업을 하게됩니다.

이때 사용하는 임시공간을 체인지버퍼라고 합니다.

기본적으로 체인지 버퍼는 InnoDB 버퍼풀로 설정된 공간에 25%까지 사용 가능합니다. (innodb_change_buffer_max_size 변수를 통해 50%까지 조정 가능)

SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME = 'memory/innodb/ibuf0ibuf'

어뎁티브 해시 인덱스 (Adaptive Hash Index)

사용자가 직접 생성하는 B-Tree 인덱스가 아닌 InnoDB스토리지 엔진에서 사용자가 자주 요청하는 데이터에 대해서 자동으로 생성하는 메모리 기반 해시 인덱스입니다.

자주 읽히는 데이터 페이지의 키 값을 찾아서 '해시 인덱스'를 만들고, 필요할 때 마다 어뎁티브 해시 인덱스를 검색해서 인덱스를 검색해서 레코드에 저장된 데이터를 즉시 찾아갈 수 있습니다.

어뎁티브 해시 인덱스가 생성된 후 어뎁티브 해시 인덱스를 사용할 수 있는 요청이 발생하면 B-Tree인덱스 대신 어뎁티브 해시 인덱스를 사용합니다.

그렇기에 B-Tree의 루트 노드에서 리프노드까지 찾아가는 비용이 줄어들고 CPU의 역할이 줄어들어 쿼리의 성능을 향상시킵니다.

어뎁티브 해시 인덱스는 InnoDB엔진에서 하나만 존재하며 (파티션은 가능)

'인덱스 키 값'과 해당 인덱스 키 값이 저장된 '데이터 페이지 주소'의 쌍으로 관리되는데,

인덱스 키 값은 'B-Tree 인덱스의 고유번호(Id)'와 'B-Tree 인덱스의 실제 키 값'의 조합으로 생성됩니다.

인덱스 키에 B-Tree 인덱스의 고유번호(Id)를 가지고 있는 이유는 'B-Tree 인덱스의 실제 키 값'이 어떤 B-Tree인덱스에 있는지 구분하기 위함입니다.

어뎁티브 해시 인덱스의 value값인 해당 인덱스 키 값이 저장된 '데이터 페이지 주소는 실제 키 값이 저장된 데이터 페이지의 메모리 주소를 가지는데, 이는 InnoDB 버퍼풀에 로딩된 페이지의 주소를 의미합니다.

그렇기에 어뎁티브 해시 인덱스는 InnoDB 버퍼풀에 로딩된 페이지에 대하서만 관리됩니다.

하지만 어뎁티브 해시 인덱스가 성능에 도움이 되지 않는 경우도 존재합니다.

어뎁티브 해시 인덱스는 innodb_adaptive_hash_index 변수를 통해 비활성화가 가능합니다.

어뎁티브 해시 인덱스가 도움이 되는 경우

- 디스크의 데이터가 InnoDB 버퍼풀 크기와 비슷한 경우 (디스크 읽기가 많지 않은 경우)

- 동등 조건 검색이 많은 경우 (동등비교나 IN)

- 쿼리가 데이터 중 일부 데이터에 집중되는 경우

어뎁티브 해시 인덱스가 도움이 되지 않는 경우

- 디스크 읽기가 많은 경우

- 특정 패턴의 쿼리가 많은 경우 (join이나 like)

- 매우 큰 데이터를 가진 테이블의 레코드를 폭 넓게 읽는 경우

아래 명령어를 통해 InnoDB 상태를 확인해보면

INSERT BUFFER AND ADAPTIVE HASH INDEX 항목을 볼 수 있는데

마지막 hash searches/s + non-hash searches/s 초당 번의 검색이 있었는데 hash searches/s 만큼 어뎁티브 해시 인덱스가 실행되었다는 내용입니다.

show engine INNODB status\G

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 34679, node heap has 0 buffer(s)
Hash table size 34679, node heap has 2 buffer(s)
Hash table size 34679, node heap has 2 buffer(s)
Hash table size 34679, node heap has 3 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
Hash table size 34679, node heap has 1 buffer(s)
5.03 hash searches/s, 15.24 non-hash searches/s

MySQL엔진의 아키텍쳐를 알아보자

겅겅겅 — Tue, 10 Dec 2024 20:43:19 +0900

소프트웨어를 만들때 아키텍쳐가 정말 중요한 부분이라는 생각이 점점 커지는 요즘입니다!
그래서 Real MySQL 을 읽고 공부한 MySQL과 InnoDB의 엔진 아키텍쳐를 정리해보고자 합니다.

MySQL 아키텍쳐

MySQL은 MySQL 엔진 + 스토리지 엔진 두가지 엔진으로 이루어져 있습니다.
이 둘을 합하여 MySQL, MySQL서버라고 부릅니다.

MySQL 엔진

클라이언트로 부터 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서 및 전처리기, 쿼리 최적화 실행을 위한 옵티마이저가 존재합니다.
데이터를 디스크에 저장하는 작업 외 전반적인 MySQL기능들은 대부분 MySQL엔진에서 이루어집니다.

스토리지 엔진

요청된 SQL을 분석하거나 최적화 하는 중 DBMS의 핵심입니다.
실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로 부터 데이터를 읽어옵니다.

-- ENGIND 파라미터로 스토리지 엔진을 지정 할 수 있습니다.
CREATE TABLE test_table (fd1 INT, fd2 INT) ENGINE=INNODB;

핸들러API

MySQL엔진은 스토리지 엔진에 읽기 또는 쓰기를 요청하게되는데 이를 핸들로 요청이라 합니다.
이때 사용되는 API를 핸들러 API라고 합니다.

-- 핸들러 API 확인 명령어
SHOW GLOBAL STATUS LIKE 'Handler%';

MySQL 스레딩 구조

MySQL은 스레드 기반으로 동작하며 포그라운드 스레드 백그라운드 스레드로 구분됩니다.
아래 명령어로 실행중인 스레드 목록을 확인 할 수 있습니다.

48번 스레드, thread/sql/one_connection 스레드만 실제 사용자의 요청을 처리하는 포그라운드 스레드입니다.
동일한 이름의 스레드가 있는 이유는 동일한 작업을 병렬로 처리하기 떄문입니다.

SELECT thread_id, name, type, processlist_user, processlist_host
FROM performance_schema.threads ORDER BY type, thread_id;

포그라운드 스레드 (클라이언트 스레드)

포그라운드 스레드는 최소 MySQL서버에 접속된 클라이언트 수만큼 존재하며 클라이언트가 요청하는 쿼리 문장을 처리합니다.
클라이언트와의 커넥션이 종료되면 해당 커넥션을 담당하는 스레드는 다시 스레드 캐시(Thread cache)로 돌아갑니다.
만약 스레드 캐시가 가득 차있다면 스레드는 종료됩니다. (thread_cache_size로 캐시 수를 설정합니다.)

백드라운드 스레드

InnoDB에서는 아래와 같은 일들이 백그라운드 스레드로 처리됩니다.

- 인서트 버퍼(Insert Buffer) 병합
- 디스크에 로그 기록 (Log Thread 사용)
- 디스크에 InnoDB 버퍼 풀의 데이터 기록 (Write Thread)
- 데이터를 버퍼로 읽기
- Lock, DeadLock 모니터링

InnoDB에서도 데이터를 읽는 작업은 주로 클라이언트 스레드에서 처리하지만 버퍼 풀의 데이터를 디스크에 기록하는 Write Thread는 아주 많고 중요한 작업을 처리하기 때문에 충분히 설정해야합니다. (내장 디스크 2 ~ 4 , DAS나 SAN의 경우 디스크 최적량으로)

InnoDB에서 쓰기 작업은 버퍼링하여 디스크에 일괄적으로 저장되도록 처리됩니다.
만약 INSERT, UPDATE, DELETE 쿼리로 데이터가 변경되는 경우 InnoDB 버퍼풀에 존재하였다가 Write Thread를 통해 주기적으로 또는 특정 시점에 데이터가 디스크 파일로 완전히 저장 됩니다.
디스크에는 존재하지 않고 버퍼풀에만 데이터가 존재할 때 'Dirty Page'로 표시되며 읽기 요청이 들어오면 버퍼풀에서 즉시 제공됩니다.

메모리 할당 및 사용 구조

글로벌 메모리 영역, 로컬 커넥션 영역으로 구분됩니다.
글로벌 메모리 영역은 MySQL 서버가 시작되면서 OS로 부터 할당됩니다. (MySQL 시스템 변수로 설정해둔 만큼 할당받습니다.)

글로벌 메모리 영역

하나의 메모리 공간만 할당됩니다.
필요에 따라 2개 이상도 가능하지만 생성된 N개의 글로벌 메모리 영역은 모든 스레드(포그라운드 + 백그라운드 스레드)에 의해 공유됩니다.
버퍼링, 캐싱, 로그기록, 백그라운드 작업에 사용되는 영역입니다.
아래는 대표적인 글로벌 메모리 영역입니다.

- 테이블 캐시
- InnoDB 버퍼 풀 (InnoDB의 주요 캐싱 메커니즘으로, 데이터와 인덱스 페이지를 디스크에서 읽어와 메모리에 캐싱)
- InnoDB 어댑티브 해시 인덱스 (InnoDB 버퍼 풀에 저장된 데이터에서 자주 사용되는 인덱스를 해시 구조로 관리)
- InnoDB 리두 로그 버퍼 (데이터 변경 작업에 대한 로그를 기록)

로컬 메모리 영역

클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역입니다.
클라이언트 메모리 영역, 세션 메모리 영역이라고도 말합니다.

클라이언트 별로 독립적으로 메모리가 할당되며 공유되지 않습니다.
쿼리의 용도별로 필요한 공간이 할당되고 필요하지 않은 경우에는 메모리 공간을 할당하지 않을수도 있습니다.
커넥션이 열려있는 동안에만 계속 할당되어 있는 공간 (커넥션 버퍼, 결과 버퍼), 쿼리를 실행하는 순간에만 할당했다가 다시 해제하는 공간 (소트 버퍼, 조인 버퍼)도 있습니다.
커넥션이 종료되면 할당된 모든 로컬 메모리는 해제됩니다.

대표적으로 아래와 같은 곳에서 사용됩니다.

- 커넥션 버퍼 (클라이언트와 서버 간의 데이터 통신을 위한 기본 네트워크 버퍼)
- 정렬 버퍼(Sort Buffer)
- 바이너리 로그 캐시 (트랜잭션이 커밋되기 전에 로그를 디스크에 기록하기 전 임시로 저장)
- 네트워크 버퍼 (쿼리를 처리할 때 클라이언트에서 받은 데이터가 먼저 네트워크 버퍼에 저장)

플러그인 아키텍쳐, 컴포넌트 아키텍쳐

사용자들의 요구를 만족시키기 위해 MySQL서버에 기능을 확장하기 위한 모델
컴포넌트는 플러그인 아키텍쳐의 단점 (플러그인간 통신 불가, 캡슐화 안됨 등)을 보안하고 나온 차세대 아키텍쳐입니다.

쿼리 실행 구조

쿼리 파서

사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리형태의 구조로 만들어냅니다.
기본 문법 오류를 필터링하고 오류 메세지를 전달합니다.

전처리기

파서 과정에서 만들어진 파서 트리를 기반으로 구조적인 문제 확인
각 토큰을 테이블, 컬럼 이름 또는 내장 함수와 같은 객체를 매핑하여 각 존재여부와 객체의 접근 권한을 확인합니다.
존재하지 않는 테이블이나 컬럼, 함수에 접근한다면 전처리기에서 걸러집니다.

옵티마이저

들어온 쿼리 문장을 가장 효율적인 방법으로 처리하도록 도와줍니다.

실행 엔진

옵티마이저가 계획한 방법을 실행하기 위해 각 핸들러(스토리지 엔진)에게 필요한 작업들을 요청 후 최종 결과를 사용자나 모듈로 전달합니다.
실제 DB내의 데이터를 얻기 위한 인터페이스라고 생각하시면 좋을 것 같습니다.
예를 들어 임시테이블 생성, WHERE조건에 일치하는 레코드 읽기, 읽어온 데이터를 임시테이블 저장, 최종결과 반환 과 같은 작업들을 각 핸들러에게 요청후 각 결과들을 취합하여 반환합니다.

헨들러 (스토리지 엔진)

실행엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크에서 불러오는 역할을 담당합니다.
위의 그림에서 쿼리 실행기에서 스토리지 엔진으로 나가는 화살표라고 생각하시면 좋을 것 같습니다.

복제 (Replication)

복제(Replication)는 1개 이상의 레플리카(replica) 저장소가 소스 저장소와 동기화를 자동으로 유지하는 과정입니다.
source-replica구조로 데이터의 백업이나 보호, 분산저장 등의 목적으로 사용되는 기능입니다.

스레드 풀

(엔터프라이즈 버전은 지원하지만 커뮤니티 버전 지원 X, 플러그인 형태로 추가하여 사용은 가능)

사용자의 요청을 처리하는 스레드 수를 줄여서 동시 처리하는 요청이 많아지더라고 MySQL서버의 CPU가 제한된 개수의 스레드 처리에만 집중 할 수 있게 서버의 자원을 줄이는 것이 목적입니다.
기본적으로 코어의 수만큼 스레드를 생성합니다. (thread_pool_size 시스템 변수로 관리)
thread_pool_size의 스레드가 모두 사용중일때에는 thread_pool_oversubscribe에 지정된 수(기본값3) 만큼 풀에 스레드를 추가로 받아들여 처리합니다.

스레드 풀의 타이머 스레드는 주기적으로 스레드 그룹의 상태를 체크하여 thread_pool_stall_limit 변수에 지정된 밀리초만큼 작업 스레드가 지금 처리중인 작업을 끝내지 못하면 새로운 스레드를 생성해서 스레드 그룹에 추가합니다. (thread_pool_max_threads 크기를 넘을수는 없음)
즉 스레드의 새로운 요청이 들어온다면 무조건 thread_pool_stall_limit 만큼은 요청이 대기되기에 적절한 값을 설정하는것이 중요합니다.

트랜잭션 지원 메타데이터

테이블의 구조정보와 스토어드 프로그램(프로시저, 트리거, 함수 ,,, ) 등 의 정보를 메타데이터 라고합니다.
MySQL서버가 동작하기 위해 기본적으로 필요한 테이블을 시스템 테이블 이라고 하는데, MySQL 8.0이후 에서는 시스템 테이블과 메타데이터 정보를 모두 모아 InnoDB 스토리지 엔진의 mysql DB에 저장됩니다. (mysqlDB는 통째로 mysql.ibd라는 테이블 스페이스에 저장됩니다.)
그렇기에 테이블 구조가 변경되는 스키마 작업같은 경우에 MySQL서버가 비정상 종료가 되어도 완전한 성공, 완전한 실패로 정리됩니다.

추가로 mysqlDB의 시스템테이블과 메타데이터를 확인하려면 information_schema DB의 TABLES, COLUMN과 같은 VIEW를 통해 조회할 수 있습니다.
mysql DB에 실제로 존재하지만 해당 DB가 아닌 다른 DB의 view를 이용해 확인해야합니다.

select * from information_schema.tables;

B-Tree 알고리즘

겅겅겅 — Wed, 30 Oct 2024 21:06:50 +0900

B-Tree란?

B-tree는 Self-balanced Tree 중 가장 유명한 자료구조입니다. Balanced-tree를 의미하며,
이진트리를 확장해 하나의 노드가 가질 수 있는 자식 노드의 최대 숫자가 2보다 큰 트리 구조입니다.
최소차수는 자식수의 하한값을 의미하며, 최소차수가 t라면 M=2t−1을 만족합니다.
최대 M개의 자식을 가질 수 있는 B-Tree를 M차 B-Tree 라고 합니다.
만약 최소차수 t가 2라면 3차 B트리이며, 데이터(key)의 하한은 1개입니다.

https://blocksandfiles.com/2022/04/19/b-tree/

B-Tree의 특징

B-Tree는 아래와 같은 특징을 가집니다.

노드의 데이터(key)는 항상 정렬된 상태로 저장됩니다.
자식 노드의 데이터는 부모 노드의 데이터에 따라 정렬되어 나뉘어집니다.
노드는 최소 M/2-1 ~ M-1개의 데이터(KEY)를 가집니다, M/2가 소수로 나온다면 올림처리
노드는 최대 M/2 ~ M개의 자식노드를 가집니다, M/2가 소수로 나온다면 올림처리
내부노드의 데이터가 k개 라면 자식노드의 수는 언제나 k+1개입니다.
모든 리프노드의 높이는 같습니다.

B-Tree 탐색 과정

1. 루트 노드에서 탐색 시작합니다.
2. K를 찾았다면 탐색을 종료합니다.
3. K와 노드의 데이터(KEY)를 비교하여 적절한 자식노드로 내려갑니다.
4. 해당 과정을 리프노드에 도달할 때 까지 반복하며 리프노드에서도 K를 찾지 못하면 값이 없다고 판단합니다.

1. 루트 노드에서 탐색을 시작합니다. (K : 46)

2. K는 루트노드 보다 큰 값이기에 왼쪽 자식으로 이동합니다.

3. K는 현재노드의 값들 사이에 있는 값이기에 가운데 자식노드로 이동합니다.

4. 리프노드에서 K을 찾아냅니다. 만약 K가 없다면 찾는 값(K)이 없다고 판단합니다.

B-Tree 데이터 삽입

B-Tree 데이터 삽입은 항상 리프노드에서 시작되며

아래와 같은 순서로 B-Tree에 데이터 삽입이 이루어집니다.

1. 트리가 비어있다면 루트노드를 할당하고 K를 삽입합니다.
2. 트리가 비어있지 않다면, 데이터를 넣을 적절한 리프노드를 탐색합니다.
3. 리프 노드에 데이터를 넣고 리프 노드가 적절한 상태에 있다면 종료한다.
4. 리프 노드가 부적절한 상태에 있다면 분할한다.

추가로 B-Tree에 데이터가 삽입 될 때 상황은 2가지로 나뉘어집니다.

노드가 부적절한 상태가 있어 '분할이 일어나는 경우', 적절한 상태에 있어 '분할이 일어나지 않는 경우' 입니다.

적절한 상태?

B-Tree의 조건(특징)을 위배하지 않는 상태를 의미합니다.

노드를 분할한다?

노드가 가질 수 있는 최대 데이터(KEY) 수(M-1)가 초과되면 가운데 데이터를 기준으로 좌우 데이터를 분할하고 가운데 데이터는 부모 노드로 올립니다.

분할이 일어나지 않는 경우

분할이 일어나지 않는 경우는 간단합니다.

적절한 위치의 노드로 찾아간 다음 데이터를 추가합니다.

1. 먼저 K가 들어갈 리프노드를 탐색합니다. (K : 16) 트리는 3차 B-Tree입니다

2. K를 추가하여도 해당 리프노드는 적절한 상태에 있기에 그대로 K를 추가합니다.

분할이 일어나는 경우

적절한 위치의 노드로 찾아간 후 데이터가 추가되었을때 노드 분할이 필요 한 경우에는
해당 노드 데이터의 중앙값(median)을 부모 노드로 올립니다.
부모노드에서도 노드 분할이 필요한 경우 동일한 과정을 반복합니다.

1. K가 들어갈 루트노드를 탐색합니다 (K:13) 트리는 3차 B-Tree입니다

2. 해당 루트노드에 K를 추가합니다.

K가 추가되었을 때 리프노드의 데이터는 최소 데이터 수 (M-1)개를 초과하게 됩니다.

즉 부적절한 상태가 되기에 노드분할을 실시합니다.

3. 노드를 분할하여 중앙값을 부모노드로 올리고 리프노드를 분할합니다.

(만약 해당 작업으로 인해 부모노드가 부적절한 상태가 된다면 동일하게 분할작업을 실시합니다.

B-Tree 데이터 삭제

B-Tree 데이터 삭제 또한 항상 리프노드에서 시작됩니다.
삭제 후 노드의 데이터 수가 최소 데이터수(M/2-1)보다 적어졌다면 트리를 재구조화 합니다.
루트 노드의 데이터 수는 최소 KEY수(M/2-1)를 만족하지 않아도 재구조화 하지 않습니다.

크게 리프노드의 데이터가 삭제 될 때, 내부노드의 데이터가 삭제 될 때로 구분됩니다.

재구조화가 필요한 경우와 재구조화 방법

데이터를 삭제했을때 노드의 '최소 데이터수 (M/2-1)' 보다 작아지게 된다면 트리의 재구조화가 필요합니다.
이럴때 형제, 부모 노드의 값들을 빌려와 재구조화를 진행하게됩니다.

1. 리프노드의 데이터가 삭제 될 때

리프노드의 삭제에서는 삭제 후 노드가 적절한 상태에 있을 때, 적절하기 않고 형제노드의 지원을 받을 수 있을 때

적절하지 않고 형제노드의 지원을 받을 수 없을 때 세가지 경우가 있습니다.

1-1 삭제 후 노드가 적절한 상태에 있어 재구조화가 필요하지 않는 경우

노드에 있는 데이터를 삭제합니다. 추후 별도 작업 X

1-2 삭제 후 적절한 상태에 있지 않아 재구조화가 필요하고 형제노드의 지원을 받을 수 있는 경우

데이터가 삭제 후 노드가 '최소 데이터수 (M/2-1)'를 만족하지 못한다면 재구조화를 시작합니다.
먼저 노드의 형제노드에서 지원을 받을 수 있는지 확인합니다.
형제노드의 데이터가 여유있다면 **부모노드를 통해서 형제노드의 지원을 받습니다.**

1-2-1 . 삭제할 데이터의 노드로 이동합니다. K : 50

1-2-2. 데이터를 삭제하게되면 노드의 '최소 데이터수'를 만족하지 못하기에 데이터가 여유있는 형제노드의 지원을 받습니다.

왼쪽 형제노드가 여유있다면 왼쪽형제 노드에서, 오른쪽 형제노드가 여유있다면 오른쪽 형제 노드에서 지원을 받습니다.

위와 같은 상황에서는 왼쪽 형제노드가 여유있기에 왼쪽 형제 노드에서 부모노드를 통해 지원을 받습니다.

왼쪽 형제노드의 가장 큰 값(46)을 부모 노드로 올리고, 부모노드에서 삭제할 K(50)와 형제노드에서 올라온 값(46) 사이의 값(47)을 K가 있던 노드에 지원받습니다.

1-2-3 삭제 후 적절한 상태에 있지 않아 재구조화가 필요하고 형제노드의 지원을 받을 수 없는 경우 -> 부모노드의 지원을 받는다

만약 형제노드가 여유가 없어 지원을 받을 수 없다면, 부모노드의 지원을 받아야합니다.

여기서는 크게 왼쪽 노드가 존재할때 오른쪽 노드와 존재할때 두가지로 구분됩니다.

부모노드의 지원을 받은 후에는 형제노드와 합칩니다.

- 왼쪽 형제 노드가 존재할때

왼쪽 형제 노드가 있다면 왼쪽 형제 노드의 데이터와 나 사이 데이터를 부모노드로 부터 받습니다.
부모로 받은 데이터와 왼쪽 형제 노드의 데이터를 왼쪽 형제 노드에 합칩니다.
나의 노드를 삭제합니다.

- 오른쪽 형제 노드가 존재할때

오른쪽 형제 노드가 있다면 오른쪽 형제 노드의 데이터와 나 사이 데이터를 부모로부터 받습니다.
부모로 받은 데이터와 오른쪽 형제 노드의 데이터를 내 노드에 합칩니다.
오른쪽의 형제 노드를 삭제합니다.

- 만약 부모노드로 부터 지원을 받다가 부모노드가 적절한 상태가 아니개 된다면?

자식노드의 재조정으로 인해 부모노드가 적절한 상태가 아니게 된다면,

자식노드의 재조정 처리 후 부모노드에서도 동일한 재조정 과정을 진행합니다.

만약 그 부모노드가 루트 노드고 적절한 상태가 아니게 되면 부모 노드, 즉 루트 노드를 삭제합니다.
아래 합쳐진 노드가 루트 노드가 됩니다.

예를들어 아래와 같은 B-Tree에서 '데이터 5'를 삭제한다면

K 삭제 후 형제노드의 지원을 받아야하지만, 형제 노드가 여유가 없어 부모노드의 지원을 받아야합니다.

아래와 같은 작업을 진행합니다.

1. 왼쪽 형제 노드가 존재하기에 왼쪽 형제 노드의 데이터와 K 사이 데이터(3) 를 부모노드로 부터 받습니다.
2. 부모로 받은 데이터와 왼쪽 형제 노드의 데이터를 왼쪽 형제 노드에 합칩니다.
3. 나의 노드를 삭제합니다.

하지만 부모노드로 부터 값을 받아오게 되니 이번엔 부모노드가 부적절한 상태가 되었습니다.

동일하게 부모노드를 기준으로 부모, 형제 노드로부터 값을 빌려오는 작업을 진행합니다.

리프노드와 동일하게 형제노드가 여유있다면 형제 노드로부터, 여유가 없다면 부모노드로 부터 값을 가져오는 작업을 진행합니다.

부모노드 기준 오른쪽 형제노드의 데이터가 여유가 있기에 형제 노드로부터 값을 가져옵니다.

오른쪽 형제노드의 가장 작은 값(40)을 부모 노드로 올리고, 부모노드에서 사라진 값(3)와 오른쪽 형제노드에서 올라온 값(40) 사이의 값(20)을 지원받습니다.

아래와 같이 재구조화가 완료되었습니다.

2. 내부 노드의 데이터 삭제 시

앞에서는 모두 리프노드에서 데이터가 삭제되는 경우만들 다루었지만

내부 노드에서 데이터가 삭제되는 경우도 존재합니다.

내부노드에서 삭제가 일어나는 경우.

삭제하려는 내부노드를 리프노드의 데이터와 위치를 바꾼 후 리프노드의 삭제 방식과 동일하게 진행합니다.
내부노드와 리프노드의 위치를 변경 할 때는 리프노드는 LMAX, RMIN 두 값중 하나를 선택하여 변경합니다.

- LMAX : 나보다 작은 데이터 중 가장 큰 데이터
- RMIN : 나보다 큰 데이터 중 가장 작은 데이터

아래와 같은 상황의 3차 B-Tree가 있을때

내부노드의 데이터 K (20)을 삭제하겠습니다.

삭제할 데이터 K(20)와 LMAX(3)값의 위치를 변경합니다. (K와 RMIN을 변경해도 상관없습니다)

이후 리프노드에서 K(20)을 삭제합니다.

만약 리프노드에서 K삭제 이후 재구조화가 필요한 상태가 된다면, 리프노드에서의 삭제에서 사용했던 방법과 동일한 방법으로 재구조화를 진행합니다.

아래처럼 재구조화가 완료되었습니다.

MySQL(InnoDB)의 Lock에 대해 알아보자

겅겅겅 — Fri, 20 Sep 2024 17:58:02 +0900

MySQL과 InnoDB의 Lock에 대해 알아보자

서비스를 운영하다보면 서비스의 기능들이 갑자기 멈춰버리는 순간들이 찾아오게됩니다.

그럴 때 사무실에서는 '일단 Lock 걸린거 찾아봐' 라는 말을 먼저 듣게되는데,

실제로 서비스에 Lock이 걸려있었다면 Lock을 풀자마자 서비스가 정상적으로 동작하게되는데

처음 이러한 현상을 보았을때 세삼 놀랐던 기억이 있습니다.

백엔드 개발자들이 일하다보면 한번쯤은 꼭 보게되는 RDB의 Lock에 대해 알아보려고 합니다.

트랜잭션이랑 Lock이랑 뭐가 달라?

트랜잭션은 '테이터베이스의 상태 변경 작업 완정성을 보장해주는 것' 입니다
논리적인 작업을 모두 완벽하게 처리(COMMIT)하도록 하거나,
처리하지 못할 경우(ROLLBACK) 원 상태로 복구되어 작업의 일부만 적용되는 현상이 발생하지 않게 만들어주는 기능입니다.

즉 트랜젝션은 데이터의 정합성을 보장하기 위함입니다.

반면 Lock은 동시성을 제어하기 위한 기능입니다.
예를 들어 하나의 회원정보 레코드를 여러 커넥션에서 동시에 변경하려 할 때 Lock이 없으면 하나의 데이터를 여러 커넥션에서 동시에 변경이 가능해집니다.
결과적으로 레코드의 결과값을 예상 할 수 없게됩니다.

그렇기에 Lock은 여러 커넥션에서 동시에 동일한 자원(레코드나 테이블)을 요청 할 경우 순서대로 한 시점에는 하나의 커넥션만 접근하여 변경 할 수 있게 해주는 역할을 합니다.

인덱스와 Lock의 관계

MySQL의 인덱스는 B-Tree 알고리즘으로 만들어져 있습니다.

MySQL의 InnoDB는 레코드 자체가 아닌 인덱스에 Lock을 설정합니다.

B-Tree Index

MySQL에서 데이터를 찾을 때는 Index와 클러스터링 인덱스 (pk)의 B-Tree를 탐색해서 데이터를 찾게됩니다.

아래 그림은 B-Tree Index의 구조입니다. (Index, PK 생성시 B-Tree가 만들어집니다.)

출처 : https://baekjungho.github.io/wiki/database/mysql-index/

Index와 클러스터링 인덱스(pk)는 각각 다른 B-Tree를 사용합니다.

위 그림은 Index의 B-Tree이고 클러스터링 인덱스(pk)도 동일한 구조를 가지지만

Index의 리프노드는 테이블의 pk값을, 클러스터링 인덱스(pk)의 리프노드는 레코드에 대한 테이블 데이터를 가진다는 차이가 있습니다.

즉 Index 키로 특정 레코드를 검색하면 인덱스의 루트 노드에서 시작해 인덱스의 리프노드로 이동하고 인덱스의 리프노드의 값은 pk값이기에 클러스터링 인덱스의 키(pk값)를 찾은 후 리프노드로 이동하여 실제 데이터를 조회하게 됩니다.

그렇기에 특정 ROW들에 Lock이 설정되면 그 ROW범위 만큼 인덱스에 Lock이 걸리게 되고 그 후 PK까지 Lock이 걸리게 됩니다.
(참고로 SELECT로 인덱스가 걸려있는 컬럼만 조회하면 pk까지 조회하지 않고 인덱스가 가지고 있는 값만으로 반환합니다.)

만약 인덱스가 설정되이 있지 않은 테이블이라면 먼저 모든 테이블 레코드에 락을 설정하고, 풀스캔하며 작업을 하게되어
성능 및 동시성에 영향을 미치게 됩니다.

어떻게 Index에 Lock이 걸리는지 데이터를 통해 확인해보겠습니다.

first_name 컬럼에 인덱스가 있는 Employee 테이블이 있고 테이블에 12명의 사원이 있습니다.

세션1번에서 first_name이 John인 레코드에 대한 UPDATE쿼리가 실행됩니다. (John은 테이블에 3명 있습니다.)

-- Lock 조회 명령어
SELECT * FROM performance_schema.data_locks;

위의 명령어를 통해 다른 세션에서 Lock을 확인해보면

세션1에서 실행시킨 UPDATE문은 idx_first_name 인덱스를 통해 first_name이 'John' 데이터를 찾고 Lock을 걸게됩니다.

만약 first_name 조건 외 다른 조건이 있어 변경되는 레코드가 1건이라 하더라도 idx_first_name를 사용한다면 Lock은 first_name이 'John'인 모든 데이터에 걸리게 됩니다.

Update는 X-Lock을 거는 DML이기에 범위 내 인덱스(John)에 X-Lock이 걸리게되고, Intension Lock이 동작해 테이블에는 IX-Lock도 걸립니다.

실제 데이터가 존재하는 클러스터링 인덱스(pk)의 데이터(John)에도 동일하게 X-Lock이 걸리는 모습을 확인 할 수 있으며,

해당 레코드만 잠그는 X,REC_NOT_GAP 과 Next Key Lock을 의미하는 X도 확인 할 수 있습니다.

세션1의 트랜잭션 중 인덱스의 새로운 값 추가를 방지하기 위한 GAP Lock도 걸려있습니다.

Lock의 설정 범위와 종류

앞서 데이터를 통해 설명하면서 IX-Lock , GAP-Lock, Next Key Lock이 언급되었는데, 이는 락의 종류와 범위에 관한 내용입니다.

Lock의 범위와 종류를 알아보겠습니다

Lock의 범위

- ROW (행)

1개의 행에 대해 Lock을 설정합니다. 일반 적인 DML(Update, Insert, Delete) 사용 시 적용되는 범위 입니다.

- Column (열)

1개의 열을 기준으로 Lock을 설정합니다.
컬럼에 대한 접근을 막게되며 설정 및 해제 시 많은 리소스가 사용됩니다.

- 페이지, 블럭 (자주 사용 X)

데이터페이스의 데이터들은 모두 스토리지 엔진에서 파일 형태로 저장되며 페이지 단위로 관리됩니다.
MySQL 페이지의 경우 보통 16KB로 설정되어 있습니다.
페이지,블록에 대해서도 Lock을 설정 할 수 있으며 이 또한 많은 리소스가 사용됩니다.

- 테이블

한 테이블에 대한 락을 설정합니다.
LOCK TABLES table_name [ READ | WRITE ] 명령으로 명시적으로 락을 얻을 수 있습니다.
MEMORY, MyISAM 테이블에서는 묵시적으로 사용될 때도 있습니다.
InnoDB의 경우 레코드 기반의 잠금을 제공하기에 단순 데이터 변경 쿼리(DML)로 테이블락이 설정되지는 않고
스키마를 변경하는 DDL 구문(create, alter, drop)에는 테이블락이 설정됩니다.

- 글로벌 락 (자주 사용 X)

전체 데이터베이스에 대해 Lock을 설정합니다.
명시적으로 FLUSH TABLES WITH READ LOCK 명령어를 사용합니다.
Lock이 걸리게 되면 단 하나의 트랜잭션 즉 하나의 세션만이 DB접근이 가능하게 됩니다.

DB전체 업데이트와 같은 상황, 여러 데이터베이스에 존재하는 MyISAM이나 MEMORY테이블에 대해 mysqldump로 일괄된 백업을 받고자 할때 사용 할 수 있습니다.
하지만 MySQL 8.0이상부터는 백업Lock이 도입되어서 백업시에는 백업Lock을 사용합니다.

락의 유형

- 공유 락 (Shared Lock, S-Lock)

읽기 Lock(Read Lock) 이라고도 합니다.
공유 Lock이 걸린 데이터에 대해서는 SELECT만 가능하며 다른 작업은 불가능합니다.
공유 Lock이 걸린 데이터에 대해서 다른 트랜잭션에서도 똑같이 공유 Lock을 획득 할 수 있으나, 배타 Lock은 얻을 수 없습니다.
즉 공유 Lock이 걸려도 읽기 작업은 가능합니다.

공유 Lock을 사용하여 조회한 데이터가 트랜잭션 안에서 변경되지 않음을 보장 할 수 있습니다.
MySQL에서 일반적인 SELECT은 공유 Lock을 걸지 않으나, 서브 쿼리와 SELECT FOR UPDATE구문에는 공유 Lcok을 겁니다.
명시적으로 공유 Lock을 걸기 위해서는 FOR SHARE 문법을 사용 할 수 있습니다.

select (열) from (테이블) for share

- 배타 락 (Exclusive Lock, X-Lock)

쓰기 Lock (Write Lock)이라고도 합니다.
데이터에 대해 배타 Lock을 획득한 트랜잭션은 읽기, 쓰기 모두 실행 할 수 있습니다.
다른 트랜잭션은 배타 Lock이 걸린 데이터에 대해 읽기쓰기작업 모두 수행 할 수 없습니다.
즉 베타 Lock이 걸려있다면 다른 트랜잭션은 공유 Lock, 배타 Lock 어느것도 획득 할 수 없습니다.

명시적으로 베타 Lock을 걸기 위해서는 FOR UPDATE구문을 사용할 수 있습니다.

select (열) from (테이블) for update

- Intention Lock (Intention Lock)

InnoDB에서는 multiple granularity lock(MGL)을 지원합니다. (다중잠금)
즉 Row Lock과 Table Lock의 공존이 가능합니다.

Intention Lock은 2종류가 있으며 테이블에 Lock을 거는 '테이블 Lock'입니다.
- Intention Shared Lock(IS-Lock)
- Intention Exclusive Lock(IX-Lock)

SELECT FOR SHARE 쿼리가 실행되면 테이블에 IS-Lock을 먼저 설정 후 Row에 S-Lock을 설정합니다.
SELECT FOR UPDATE, INSERT, DELETE 쿼리가 실행되면 테이블에 IX-Lock먼저 설정 후 Row에 X-Lock이 설정됩니다.
즉 Intention Lock은 Row에 Lock을 건다는 '의도'를 알려주는 테이블Lock입니다.

Intetsion Lock(IS-Lock, IX-Lock)은 여러 트랜잭션에서 발생하는 새로운 IS,IX Lock의 동시 접근이 허용됩니다.
하지만 IS,IX-Lock 이후 발생하는 X-Lock, S-Lock을 걸게되는 시점 즉 Row Lock시점에 다른 트랜잭션의 동시접근이 막히게 됩니다.

왜 Intension Lock이 필요할까??

예를들어 트랙잭션A가 특정Row들에 Update쿼리를 시작하고 Row들에 X-Lock을 걸려있는 상황일때
트랜잭션B가 테이블스키마 변경과 같이 테이블 자체에 X-Lock을 설정하는 쿼리를 실행시킨다면
Row 변경 중 테이블 스키마가 변경되면 안되기에 트랜잭션A가 끝나기 전까지 트랜잭션 B는 대기해야합니다.

트랜잭션B는 테이블의 전체 Row데이터를 확인하며 Row-Lock이 걸려있는지 확인해야하지만
트랜잭션A가 테이블에 미리 설정해둔 IS-Lock이 있기에 트랜잭션B에서 테이블에 S-Lock이 존재한다는걸 Row-Level가 아닌 Table-Level 에서 확인 할 수 있기에
트랜잭션B가 굳이 Row를 확인하지 않을 수 있어 성능상의 이점이 존재합니다.

추가로 Lock TABLES, ALTER TABLE, DROP TABLE 같은 쿼리가실행되면 IS,IX Lock 모두 Block하는 별도의 테이블 Lock(Sch-M 락 등)이 설정되며 IS, IX Lock을 얻으려는 트랜잭션은 대기상태가 됩니다.

락 종류간 호환 여부 표 (갈등 = 충돌)

InnoDB의 Lock

- 레코드 Lock

레코드를 잠그는 Lock입니다.

performance_schema.data_locks 테이블에서는 REC_NOT_GAP 으로 표시됩니다.

만약 인덱스가 하나도 없는 테이블이라면 내부적으로 자동 생성된 클러스터링 인덱스(PK)를 통해 잠금을 설정하며
모든 테이블의 레코드에 락을 걸고, 풀스캔하며 적절한 레코드를 찾아 Lock을 걸어주어야 하기에 조회 뿐만 아니라 동시성 성능에 큰 영향을 미치게 됩니다.

- 갭 Lock (사진)

인덱스 레코드가 아닌 '레코드와 인접한 레코드 사이의 간격'만을 잠그는 Lock입니다.

performance_schema.data_locks 테이블에서는 GAP 으로 표시됩니다.
갭락을 사용함으로서 레코드와 레코드 사이에 새로운 레코드가 생성(insert)되는것을 제어하며 펜텀리드를 방지합니다.

주로 넥스트 키 Lock의 일부로서 사용됩니다.

데이터로 갭락을 확인해보겠습니다.

직원 테이블에 급여에 관한 인덱스 idx_second_name을 만들고

세션1에서 FOR UPDATE구문을 사용해 2개의 레코드(조건 : 급여가 52000 ~ 55000)에 X-Lock을 걸은 후

이후 세션2에서 세션1에서 SELECT 범위 내에 값을 추가하는 INSERT문(급여 : 55000)을 실행하고 Lock을 확인해보면 아래와 같이 INSERT가 실패하는걸 확인 할 수 있습니다.

그 이유가 바로 GAP-Lock때문입니다.

세션1에서 Lock을 건 범위가 아닌 부분에 INSERT를 하게되면 정상적으로 수행됩니다.

- 넥스트 키 Lock

레코드 락과 갭락을 합친 형태입니다.

performance_schema.data_locks 테이블에서 X락 뒤에 GAP,REC_NOT_GAP 과 같은 키워드가 없다면 넥스트 키 Lock이라고 생각하시면 됩니다.

SELECT * FROM table WHERE pk > 99;

출처 : https://stackoverflow.com/questions/74965677/next-key-lock-explication-primary-key-for-range

위와 같은 쿼리가 실행되었을때 RDB는 클러스터링 인덱스(pk)를 스캔하면서

pk가 99보다 큰 최초의 레코드 101을 찾아냅니다.

101의 앞뒤 레코드 97, 101 사이에 갭 Lock을 설정하고

이후 pk > 99인 모든 레코드에 갭에 Lock 설정 후, 각 레코드 데이터에 대해서도 레코드 Lock을 설정합니다.

InnoDB의 갭 락이나 넥스트 키 락은 바이너리 로그에 기록되는 쿼리가 레플리카 서버에서 실행될 때 소스 서버와 동일한 결과를 만들도록 보장해줍니다.
그런데 넥스트 키 락과 갭 락으로 인해 데드락이 발생하거나 다른 트랜잭션을 기다리는 일이 자주 발생 할 수 있어 바이너리 로그 포맷을 ROW형태로 바꾸어서 넥스트 키 락과 갭락을 줄이는것이 좋다고 합니다.

- 자동 증가 Lock (Auto Increment Lock)

MySQL은 자동 증가하는 숫자값을 채번하기 위해 AUTO_INCREMENT라는 컬럼 속성을 제공하며, 이는 주로 FK에 사용됩니다.
AUTO_INCREMENT 컬럼은 여러 레코드가 동시에 INSERT 되더라도 중복되지 않고 순차적으로 증가하는 일련번호를 제공하기 위해
내부적으로 테이블 수준의 잠금인 자동 증가 락(Auto Increment Lock)을 사용합니다. (짧은 순간만 걸렸다가 즉시 해제)

INSERT와 REPLACE와 같이 새로운 레코드를 저장하는 쿼리에서만 사용되며,
트랜잭션과 관계없이 INSERT나 REPLACE 문장에서 AUTO_INCREMENT 값을 가져오는 순간에 락이 걸립니다.
자동 증가 락은 테이블에 1개만 존재하기 때문에, 한 쿼리에서 락을 획득하여 채번중이라면 다음 쿼리는 대기합니다.
자동 증가 락은 잠금을 최소화하기 위해 한 번 증가하면 절대 자동으로 줄어들지 않으며 트랜잭션과도 무관합니다.

자동 증가값 채번에 성공 후, 이후 쿼리에서 실패하여 트랜잭션이 롤백되어도 자동 증가값은 복구되지 않고 그대로 남습니다.

OOP(객체 지향 프로그래밍)에 대해 쉽게 알아보자!

겅겅겅 — Thu, 22 Aug 2024 21:30:53 +0900

OOP(object-oriented programming)란?

OOP란 '현실 세계에 가까운 방식으로 프로그램을 만드는 프로그래밍 방법론'입니다.

OOP를 통해 현실 세계의 개념들을, 프로그램 내에서 '객체'로 바라보며
객체들간의 상호작용을 통해 프로그램이 동작하도록 합니다.

이러한 객체들의 상호작용을 '협력'이라고 하며,
각 객체들은 '협력'안에서 '메세지'를 보내 서로 소통하면서 자신의 '역할'을 '책임'을 가지고 수행해야합니다.

OOP방식으로 프로그램을 설계하면 유지보수와 확장에 유리한 프로그램을 만들 수 있습니다.

OOP의 철학 (협력, 역할, 책임 그리고 메세지)

앞서 OOP를 설명하며 중요한 키워드들을 따옴표 안에 넣어서 언급하였습니다.
키워드의 의미를 보다 쉽게 이해하기 위하여 현실 세계의 상황 커피주문을 예시로 간단한 OOP설계를 해보려고합니다.

'커피 주문'을 위해 일어나야하는 일들을 순서대로 정리하면 아래와 같습니다.

1. 손님은 메뉴를 바리스타에게 주문한다.
2. 바리스타는 손님에게 주문받은 메뉴에 맞는 커피를 제조한다.
3. 바리스타는 완성된 커피를 손님에게 전달한다.

커피를 주문하는 프로그램을 OOP방식으로 설계한다면 프로그램의 최종 목적 커피 주문은 '협력'을 의미허며
‘손님’, ‘커피’, '바리스타' 등은 각각의 객체로 정의합니다.
각 객체들은 커피 주문이라는 공통의 협력 안에서 각각 손님, 커피, 바리스타 등 고유한 '역할'과 '책임'부여받습니다.

객체들은 서로 '메세지'를 통해 상호작용하며 프로그램의 목적인 커피 주문이 성공하도록 '협력'해야합니다.
위의 '커피주문 프로그램'에 대한 객체들간의 협력 구조를 OOP적 관점에서 설명하면 아래와 같습니다.

손님객체는 바리스타객체에게 커피를 만들어달라는 요청(request)을 메시지를 통해 전달합니다.
이때 메세지를 보내는 손님객체는 송신자(sender)가 되고 메세지를 받는 바리스타객체는 수신자(receiver)가 됩니다.

요청(request)를 받은 바리스타객체는 요청에 응답할 '책임'이 있기에 스스로 요청을 처리해야합니다.
이때 객체가 요청을 처리하는 방법을 메서드(method)라고 합니다.

바리스타객체는 커피를 만들기 위해 커피객체에 요청(request)을 메세지를 통해 전달합니다.
객체는 스스로 자신의 상태를 결정해야 하기에, 커피객체는 바리스타객체에게 요청을 받고 스스로 만들어집니다. (OOP의 객체는 완전히 현실세계의 개념과 동일 할 수는 없습니다)

커피객체가 만들어졌다면 바리스타객체에게 요청(request)에 대한 응답을 보내고, 응답을 받은 바리스타객체는 손님객체에게 응답을 보냄으로서 협력이 마무리됩니다.

OOP의 요소

OOP에서는 캡슐화, 추상화, 상속, 다형성 크게 4가지 특징이 있습니다.

캡슐화(Encapsulation)

'손님이 커피를 주문했을때 손님은 바리스타가 커피를 만드는 과정을 알 수 없다'

바리스타가 커피를 만드는 과정은 바리스타의 역할이자 책임이기에 손님이 그 과정에 관여 할 수 없습니다.

캡슐화는 구현에 대한 메서드를 외부에서 확인하지 못하도록 은닉하는 행위를 말합니다.

캡슐화를 통해 외부에게 원하는 인터페이스 부분만 노출 할 수 있고, 구현을 은닉함으로서 스스로 자신의 상태를 하며 자율적인 객체를 구현 할 수 있습니다.
자율적인 책임을 가진 객채들이 협력함으로서 객체끼리의 협력을 단순하게 만들 수 있습니다.
또한 구현이 은닉되어 있으므로 구현이 변경되어도 외부 객체에 영향을 끼치지 않아 유지보수가 용이합니다.

자바에서는 접근 제어자 public, default, protected, private를 통해 외부 객체에 대핸 접근범위를 제한 할 수 있습니다.

추상화 (Abstraction)

'손님이 느낄때는 1급 바리스타와 2급 바리스타 모두 그냥 내게 커피를 만들어주는 바리스타일 뿐이다'

커피를 주문하는 손님은 바리스타의 실력에 관계 없이 커피를 주는 바리스타로만 보여집니다.

1급 바리스타와 2급 바리스타는 두 객체는 '바리스타'라는 하나의 형태로 손님에게 추상화 되어 보여집니다.

추상화란 객체의 공통적인 속성과 기능을 추출하여 정의하는 것을 의미합니다.

여러 프로그래밍 언어들은 현실세계의 개념을 어플리케이션의 type으로 정의합니다.

문자들을 string type, 숫자들을 int 타입으로 규정하듯이 현실세계의 개념은 어플리케이션 안에서 객체들은 '행동'을 기준으로 하여 각각의 type으로서 정의됩니다.

객체들이 가진 내부의 타입들과 값들이 다르더라도 동일한 '행동'을 한다면 동일한 type으로 정의 할 수 있고 이는 동일한 '책임'을 가지고 있다는걸 의미합니다.

추가로 OOP관점에서 Type은 크게 두가지로 나눌 수 있습니다.

슈퍼타입과 서브타입

어떤 타입이 다른 타입보다 일반적이라면 슈퍼타입, 특수하다면 서브타입이라고 하며, "일반화와 특수화"라고 이야기하기도 합니다.

특정 타입이 다른 타입의 서브타입이 되기 위해서는 'Is-a 규칙'을 준수해야합니다.

ls-a 규칙이란 흔히 말하는 일반화 관계입니다.

"아메리카노는 커피다." 라는 명제를 예시로 들면

아메리카노는 커피의 부분집합이고 커피는 음료의 부분집합입니다.

아메리카노 입장에서는 아메리타노는 커피의 서브타입이고, 커피는 슈퍼타입이 됩니다.

커피의 입장에서는 커피는 서브타입이고, 음료가 슈퍼타입이 됩니다.

물론 아메리카노는 음료의 서브타입이기도 합니다.

이렇든 슈퍼타입과 서브타입의 관계는 "SubType is SuperType" 이라는 조건을 만족시켜야 합니다.

추상화를 함으로서 우리는 수신을 받는 객체에 대해 다형성을 줄 수 있고, 추상화된 객체에 메세지를 보냄으로서 유연한 협력을 만들 수 있습니다.

자바에서는 추상클래스(abstract)와 인터페이스(interface)를 통해 추상화를 구현 할 수 있습니다.

상속 (Inheritance)

'1급 바리스타와 2급 바리스타는 동일한 바리스타 자격증을 취득하였으며 커피를 만들 수 있는 기술이 있다'

두 바리스타는 동일하게 커피를 만들 수 있는 방법(method)를 알고있습니다.

일반화와 특수화를 객체로 구현하기 가장 좋은 방법은 상속입니다.

크게 인터페이스 상속(interface inheritiance)과 서브클래싱 구현 상속(implemantaion inheritiance) 두가지가 있습니다.

각각 서브타이핑과 서브클래싱이라고도 합니다.

인터페이스 상속은 설계의 유연성을 위해 사용되며

서브클래싱 구현 상속은 주로 코드의 중복제거와 재사용성을 높히기 위해 사용됩니다.

인터페이스 상속과 서브클래싱 구현 상속을 구분하기 위해서는 클라이언트 관점에서 상속과 관련된 객체들이 어떻게 사용되고 있는지 확인해야 합니다.

추가로 서브타입이 슈퍼타입을 대체 할 수 있는 경우에는 인터페이스 상속을 대체 할 수 없는 경우에는 서브클래싱 구현 상속이 주로 사용됩니다.

상속을 받은 어떤 객체가 이해할 수 없는 메시지가 있다면 자신의 상위 클래스에게 책임을 위임(delegration) 합니다.

만약 위임을 받은 클래스도 이해 할 수 없다면 상속의 최상위 클래스까지 그 요청을 계속해서 위임하게됩니다.

상속을 적절히 사용하면 코드의 중복제거와 재사용성을 높히며 설계의 유연성 또한 늘어납니다.

자바에서는 implements와 extand키워드를 사용해 각각 서브타이핑과 서브클래싱을 구현 할 수 있습니다.

다형성 (Polymorphism)

'"아메리카노를 만들어 줘" 라는 요청을 받은 1급 바리스타와 2급 바리스타는 각각 다른 방법으로 커피를 만들 수 있다'

두 바리스타는 동일한 커피를 만들어달라는 요청에 대해 자율적으로 행동해서 응답 할 수 있습니다.

서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 말합니다.
서로 다른 타입의 객체들이 동일한 메시지를 수신 할 경우 서로 다른 메서드를 이용해 메서드를 처리 할 수 있다는 의미입니다.

다형성을 통해 협력이 수행되는 방식(메시지)을 재사용하기 쉬워지며, 협력이 수행되는 방식을 확장 할 수 있습니다.
송신자는 수신자가 메시지를 이해 할 수 있다면 누구라도 관계없이 요청을 보내고 응답 받을 수 있기에 협력이 유연해질 수 있습니다.

자바에서는 오버라이딩(Overriding), 오버로딩(Overloading)을 통해 다형성을 구현합니다.

고루틴에 대해 알아보자

겅겅겅 — Sun, 23 Jun 2024 11:55:44 +0900

1. 동시성(Concurrency)과 병렬성(Parallelism)

동시성과 병렬성은 cpu의 작업 처리방식입니다.

동시성은 싱글코어 프로세서에서 멀티 스레드 환경을 구성하여 프로그램이 '동시에 실행되는 것 처럼'(논리적) 보이게 하는 방법이고,

병렬성은 멀티코어 프로세서에서 여러개의 스레드, 프로세스를 병렬로 돌려 프로그램을 '실제로 동시에 실행'(물리적) 시키는 방법입니다.

동시성으로 작업하는걸 멀티 태스킹, 병렬성으로 작업하는걸 멀티 프로세싱이라고도 합니다.

위에서 동시성은 싱글코어, 벙렬성은 멀티코어에서 사용되는 것 처럼 이야기 했지만,

실제로 운영체제는 두 방법 중 하나를 선택하여 사용하는것이 아닌 섞어서 사용합니다.

예를들어 6코어 12쓰레드의 프로세서가 있다면 6개의 프로세스를 병렬로 실행함과 동시에
6개의 프로세스에서 생성한 스레드 n개를 동시성으로 CPU에서 작업하게됩니다.

동시성으로 프로그램을 실행시키게 되면 'Context Switching으로 인해 발생하는 스위칭 오버헤드','Race Condition','Dead Lock'과 같은 문제들이 발생 할 수 있습니다.
하지만 그럼에도 동시성은 제한된 하드웨어에서 성능을 향상 시키기 위한 효율적인 방법입니다.

2. CSP - GO에서 동시성을 다루는 방법

일반적으로는 동시성을 다루기 위해 '뮤택스', '세마포어' 와 같은 방법으로 동시성문제를 해결하지만,

GO에서 동시성을 다루기 위한 방법으로는 CSP모델을 사용합니다.

CSP의 핵심 철학은 아래와 같습니다.

'공유메모리의 변수에 접근할때 Lock을 걸지 말고,스레드간 통신을 통해 메모리를 공유하라'

Go에서는 '고루틴'이라는 일종의 경량의 가상 스레드를 만들어 Lock이 아닌 고루틴간의 통신을 통해 메모리를 공유합니다.

고루틴에서 고루틴끼리 데이터를 공유할 떄는 'Channel'이라는 객체를 사용하여 send하면서 각 고루틴끼리 communicate 하게됩니다. (OS에서 스레드끼리 공유자원을 이용하는것을 'communicate'한다고 합니다)

고루틴1이 고루틴2에게 데이터를 Channel을 통해 send하면 고루틴2는 고루틴1에게서 데이터가 도착할때 까지 다른 행위를 하지않고 기다립니다. 고루틴2의 이러한 멈춤 상태를 '안정적인 상태'라고 말합니다.

고루틴이 안정적인 상태에 있게되면 기다리는것 외에 어떤 행위도 하지 않기에 공유자원에 대한 Lock이나, sync를 맞출 필요없이
Channel을 통해 공유되는 자원에 대한 동기화를 보장 할 수 있습니다.

하지만 고루틴 또한 일종의 스레드 기반이기에 동시성의 위험을 완전히 해결한것은 아니며,

여러 고루틴이 하나의 값에 대해 접근하는 경우에는 여전히 동기화(sync)가 필요합니다.

3. 고루틴 이란?

앞서 고루틴은 일종의 경량 스레드라고 말했는데,

고루틴이 왜 경량 스레드라고 불리는지 알기 위하여 프로세스와, 스레드에 대해 먼저 알아보고자 합니다.

3-1 프로세스와 스레드

프로세스는 컴퓨터에서 실행되고 있는 프로그램을 의미합니다.

스레드는 프로세스 내에서 실행되는 작업의 단위이며, 하나의 프로세스는 여러 스레드를 가질 수 있습니다.

프로세스의 메모리 구조

Text 영역 (Code 영역) : 실행 가능한 명령이 포함된 파일이나, 메모리에 존재하는 프로그램의 함수들의 코드가 CPU가 해석 할 수 있는 기계어 형태로 저장되어 있습니다. 컴파일 시점에 결정되고 Read-Only로 되어있습니다.

데이터 영역(Data) : 전역 변수, static 변수 등 프로그램이 사용하는 데이터들이 저장되어 있고. data, rodata, bss의 영역으로 나뉘어져 있습니다. rodata영역은 상수선언된 변수, 문자열이 저장됩니다.

초기화된 데이터 세그먼트 : 프로그래머가 초기화하는 전역 변수와 static 변수가 저장됩니다.
초기화 되지 않은 데이터 세그먼트 (bss) : 블록 정적 저장소라고도 불리며, 초기값 없는 전역 변수와 static 변수가 저장됩니다. 프로그램이 시작되기 전 커널에 의해 초기값으로 초기화 됩니다.

스택 영역(Stack) : 호출된 함수가 종료되고 복귀할 주소와 데이터(변수, 리턴값 등)를 임시로 저장하는 공간입니다. 함수의 호출과 동시에 할당되고, 호출이 완료되면 소멸합니다. 너무 많은 양의 함수의 호출되거나 저장되는 데이터의 크기가 영역의 크기를 초과하면 stack overflow가 발생합니다.

힙 영역 (Heap) : 생성자나 인스턴스와 같이 동적으로 할당되는 데이터가 저장되는 영역입니다. 프로세스가 실행되는 동안 크기가 동적으로 변화 하게됩니다. 스택 영역의 함수에서 포인터를 사용하게 되면 힙 영역의 메모리에 엑세스하는데 사용됩니다.

스택과 동일하게 힙 영역도 크기가 동적으로 변화합니다.

멀티스레드 메모리 구조

스레드도 OS에서 함수로 구현되기에 각 스레드에 대한 지역변수, static변수를 가지며 이를 관리하기 위한 프로세스와의 별도의 stack영역을 가집니다. 이 stack 영역을 thread stack이라고 부릅니다.

실행되는 프로세스들은 각각 별도의 메모리 공간을 가지고 있기에 서로 정보를 공유하기 어렵습니다.

그래서 OS에서는 IPC와 같은 방법들를 사용하지만 IPC의 경우 캐시메모리가 초기화 되기에 비용이 크다는 단점이 있습니다.

반면 스레드는 stack 외 프로세스의 영역 Text, Data, Heap 영역을 공유하기에 각 스레드간 통신이 가능합니다.

그렇기에 프로그램에서 동시성 작업이 필요할 때에는 멀티스레드를 사용하는 경우가 일반적입니다.

3-2 스케줄링과 컨텍스트 스위칭

프로세스 컨텍스트 스위칭

물리적으로 하나의 CPU에는 하나의 프로세스만 할당되어 실행 될 수 있습니다.

그렇기에 OS는 '동시성'을 위해 모든 프로세스에 우선순위를 할당하여, CPU에서 실행중인 프로세스의 우선순위가 대기중인 프로세스의 우선순위보다 낮아지게 되면 CPU가 실행시킬 프로세스를 변경 하게됩니다.

OS의 '스케줄러'가 해당 작업을 수행하고 이를 '스케줄링'이라고 합니다.

CPU에 할당된 '프로세스1'이 스케줄링을 통해 다른 프로세스 '프로세스2'로 변경될 때 실행되던 '프로세스1'의 정보를 '프로세스1'의 PCB에 저장하고 '프로세스2'를 CPU에 할당합니다. 이후 '프로세스2'의 PCB에 저장되어있던 '프로세스2'의 정보를 다시 불러온 다음, CPU가 '프로세스2'을 실행시킵니다.

이러한 과정을 Context Switching 이라고 하며, 컨텍스트 스위칭이 일어나면 필연적으로 PCB의 정보가 변경되기에 비용이 발생합니다.

CPU에 할당된 프로세스가 변경되기에 OS는 CPU의 캐시메모리를 무효화(flush)시켜줍니다.

그렇기에 변경된 프로세스는 CPU캐시를 사용하지 못하고 메모리에 직접 접근해야하고 프로세스가 변경되며 참조하는 메모리 주소를 변경하는 등 성능문제도 발생합니다.

위와 같이 컨텍스트 스위칭이 일어나며 발생하는 성능 저하를 Context Switching Overhead라고 합니다.

스레드 컨텍스트 스위칭

여러 프로세스가 동시에 실행되기 위해 Context Switching이 일어나듯, 다중 스레드 환경에서도 동일하게 스레드의 컨텍스트 스위칭과 스케줄링이 일어납니다.

동일한 프로세스의 스레드끼리 컨텍스트 스위칭이 발생하게 되면 프로세스의 컨텍스트 스위칭보다 비용이 훨신 저렴합니다.

(다른 프로세스의 스레드간 컨텍스트 스위칭이 발생하면, 프로세스 컨텍스트 스위칭과 동일한 비용이 발생합니다.)

스레드간 컨텍스트 스위칭이 일어나서 현재 상태를 백업할때에도 불러올 때에도 동일한 프로세스 이기에 PCB가 아닌 PCB안의 'TCB'에 해당 스레드의 정보를 저장하고 불러오게 됩니다.

TCB는 PCB에 비해 적은 정보만 필요하므로 스레드의 컨텍스트 스위칭은 프로세스의 컨텍스트 스위칭보다 더 빠르게 동작합니다.

(고루틴은 TCB보다 더 작은 정보가 필요하여 TCB보다 더 빠릅니다!)

3-3 PCB와 TCB

PCB(프로세스 제어 블록)

OS가 프로세스를 관리하기 위해 프로세스의 정보를 저장해 놓은 구조체 입니다.

프로세스의 상태, 프로그램 카운터(PC), 레지스터에 들어있는 정보, 프로세스의 현재 포인터 와 같은 데이터들이 들어있습니다.

컨텍스트 스위칭이 일어나게 되면 레지스터에 존재하는 현재 실행중인 프로세스의 정보(프로그램 카운터, 스택 포인터 등)를 어딘가에 저장해 두어야 하는데, 이때 OS는 해당 프로세스의 PCB를 사용합니다. PCB는 프로세스 생성과 동시에 생성되고 프로세스가 완료되면 사라집니다.

PCB는 아래와 같은 정보를 가집니다.

프로세스 식별자(Process ID) : 프로세스 고유 번호
프로세스 상태(Process State) : 프로세스의 현재 상태 정보입니다. (생성, 준비, 실행, 대기, 완료)
프로그램 카운터(Program Counter) : 프로세스가 다음에 실행할 명령어의 주소
CPU 레지스터 및 일반 레지스터 : 프로세스가 실행 중에 사용하는 레지스터의 값들이 저장
CPU 스케줄링 정보 : 우선 순위, 최종 실행시각, CPU 점유시간과 같은 값들이 저장
메모리 관리 정보 : 해당 프로세스의 주소 공간, 메모리 크기 등과 같은 값들이 저장
프로세스 계정 정보 : 페이지 테이블, 스케줄링 큐 포인터, 프로세스 소유자, 부모 프로세스 등과 같은 값들이 저장
입출력 상태 정보 : 프로세스에 할당된 입출력장치 목록, 열린 파일 목록들이 저장
포인터 : 프로세스에서 사용하는 데이터(입출력장치, 파일목록 등)의 메모리 주소정보가 저장

TCB (스레드 제어 블록)

TCB는 PCB안에 속해있는 구조체 입니다.

PCB처럼 스레드의 정보가 저장되어 있으며 스레드가 생성될 때 생성되고 종료되면 같이 사라집니다.

multi thread, multi process 환경에서는 프로그램 카운터(PC)를 PCB가 아닌 TCB에 저장합니다.

스레드와 관련된 데이터만 저장되기에 PCB보다 적은 데이터를 가집니다. (고루틴은 TCB보다 더 작은 데이터를 가집니다)

TCB는 아래와 같은 데이터를 가집니다.

스레드 식별자(Thread ID) : 스레드가 생성될 때 운영 체제에서 스레드에 할당하는 고유 식별자
스레드 상태: 스레드가 시스템을 통해 진행됨에 따라 변경되는 스레드의 상태 (New, Runnable, Blocked, Terminated)
CPU 정보: 스레드가 얼마나 진행되었는지, 어떤 데이터가 사용되고 있는지 등 OS가 알아야 하는 모든 정보가 포함스레드
우선 순위: 스레드 스케줄러가 작업을 시작해야 하는 스레드 결정을 위한 우선순위 값
포인터 : 스레드를 생성한 프로세스의 포인터 주소, 스레드가 생성 한 스레드의 포인터 주소, 이 스레드의 stack의 포인터 주소

3-4 스레드 모델

스레드는 크게 유저 스레드(User Threads)와 커널 스레드(Kernel Thread)로 나뉩니다.

유저 스레드는 사용자 수준의 라이브러리에서 관리하는 스레드이고 커널스레드는 OS에 의해 직접 관리되는 스레드입니다.

유저 스레드 (User Threads)

유저 영역에서 동작하는 스레드입니다.

라이브러리를 통해서 생성, 삭제, 스케줄링이 되기에 커널영역에서 유저 스레드를 인지하지 못하며 커널입장에서는 많은 유저 스레드가 있어도 하나의 커널스레드로서 인식하게됩니다.

그렇기에 OS 단계의 컨텍스트 스위칭이 일어나지 않아 커널스레드에 비해 비용이 저렴하지만

시스템 콜과 같은 이유로 하나의 유저 스레드가 블록된다면 모든 유저스레드가 블록되는 상황이 발생하게됩니다.

유저 스레드 정리

프로세스 1개에 커널 스레드 1개가 할당되나, 유저 스레드는 여러개 존재 할 수 있습니다. (커널 입장에서 유저 스레드는 하나의 커널스레드)
유저 영역의 스레드 라이브러리가 스케줄링을 담당한다.
유저스레드의 TCB는 프로세스 내에서 관리됩니다. (커널모드 전환 불필요, 프로그램의 시스템 콜이 일어나면 커널모드 전환)

커널 스레드 ( Kernel Threads)

커널 영역에서 동작하는 스레드입니다.

OS에 의해 생성, 삭제, 스케줄링이 일어나게 됩니다.

OS에서 직접 관리하기에 안정적이지만 대부분의 프로그램들은 사용자 영역에서 동작하기에 프로그램에서 커널스레드를 자주 사용하게 되면 '유저 영역 -> 커널영역'간 호출(시스템콜)이 많아지므로 성능저하가 발생 할 수 있습니다.

커널 스레드 정리

커널 스레드를 사용하면 프로세스 내의 사용자 스레드 1개 당 커널 스레드 1개가 할당된다.
커널이 전체 TCB와 PCB를 관리합니다.
실행중인 스레드가 시스템 콜로인해 블락되어도 해도 해당 프로세스 내 다른 스레드가 CPU에서 실행 될 수 있습니다. (유저 스레드는 커널 입장에서 하나의 커널 스레드이므로 불가능)
OS레벨의 스케쥴링과 시스템콜로 인한 성능저하가 존재합니다.

스레드 모델

유저 스레드와 커널스레드가 따로 존재하기에 두 스레드를 함께 다루기 위한 방법들이 존재합니다.

크게 3가지 방법이 있는데 간단히 알아보겠습니다.

고루틴은 Many To Many 방식을 사용합니다.

Many To One (M:1)

하나의 커널스레드에 N개의 유저 스레드가 연결되어 있는 형태입니다.

한번에 하나의 유저 스레드만 커널에 접근가능하기에 멀티코어 시스템에서 충분한 활용이 어렵다는 큰 단점이 있습니다.

Many To Many (M:N)

여러 유저 스레드가 여러 커널스레드와 연결되는 형태입니다.

M:N 모델이라고도 하며, 오늘날의 멀티코어 환경에서 활용하기 좋은 방식입니다.

고루틴에서 사용하는 스레드모델 방식입니다.

One To One (1:1)

하나의 유저스레드에 하나의 커널 스레드가 연결되는 방식입니다.

멀티코어에서 활용 가능하며 컨텍스트 스위칭이 커널레벨에서만 동작하기에 Many To Many 모델보다 비용이 높습니다.

고루틴이란?

드디어! 고루틴입니다.

앞서 계속해서 언급되었듯 고루틴은 일종의 경량 스레드입니다.

동시성을 만들기 위한 GO의 수단이고, 고루틴 스케줄러에서 M:N모델의 형태로 관리하는 사용자 공간의 스레드입니다.

고루틴은 스레드 보다 가볍습니다

고루틴을 생성하게 되면 2KB의 스택 공간만 생성이 됩니다. (스레드에 비해 500배 가볍습니다.)

고루틴은 필요에 따라 고루틴간 통신을 통해 Heap영역을 공유 및 사용합니다.

쓰레드는 사용할 메모리 공간과 각 메모리 간의 경계 역할을 하는 Guard Page라고 불리는 메모리 영역을 함께 필요로하여 약 1Mb의 메모리 공간을 소모하여 생성됩니다.
Thread 생성이 많아질 수록 프로세스의 스택영역을 더 많이 차지하게 되고 힙과 스택영역은 크기를 공유하기에 스레드가 많이 생성될수록 힙 영역이 작아지게되고 이에따라 OOM이 발생 할 수 있습니다. 그렇기에 자바와 같은 언어에서는 스레드풀을 만들어서 스레드의 수를 관리하지만 고루틴은 가볍기에 위와 같은 문제에서 비교적 자유롭습니다. (고루틴은 Go 런타임에 의해 생성 및 소멸되며 매우 적은 비용으로 이루어집니다. Go 언어는 고루틴의 수동 관리를 지원하지 않습니다.)

고루틴은 Context Switching 비용이 가볍습니다.

스레드가 스케줄링 되며, 컨텍스트 스위칭이 발생 할때 일반적인 스레드는 레지스터의 정보를 저장하고 복구하는 작업을 진행할 때

모든 레지스터를 대상으로 저장과 복구가 진행됩니다.

대표적으로

16개의 범용 레지스터, 프로그램 카운터(PC), 스택 포인터(SP), Segment레지스터

16개의 XMN레지스터, FP coprocessor state, 16개의 AVX 레지스터, 모든 MSR 에 저장과 복구가 이루어 지는데

고루틴의 컨텍스트 스위칭에서는 3개의 레지스터 프로그램 카운터(PC), 스택 포인터(SP), DX를 대상으로만 저장과 복구 작업이 이루어지기에 PCB와 TCB에 비해 Context Switching 비용이 훨신 더 가볍습니다.

프로그램 카운터(PC) : 고루틴 인터럽트 후 복원하기 위한 프로그램 카운터(PC)로 고루틴 내부에 저장
스택 포인터(SP) : 고루틴의 스택을 가르키는 포인터 (SP)
DX : CPU 레지스터 중 DX

4. Go 스케줄러

CPU 스케줄러가 여러 쓰레드의 실행순서를 결정하고, 실행시키듯이 Go에서는 고루틴의 실행방법과 순서를 담당하는 스케줄러가 있습니다.
Go스케줄러는 m:n 모델 스케줄링 기법을 사용하는데 m은 고루틴의 갯수이고 n은 고루틴과 연결될 커널 스레드 수 입니다.
m개의 고루틴이 구동하면 n개의 커널 스레드에서 스케줄링을 시작합니다.

4-1 Go 스케줄러 구성 항목

Go스케줄러는 5개의 구성 항목을 가집니다.

OS스레드(M) : 고루틴을 동작시킬 수 있는 실제 OS의 스레드

- P로 부터 G를 할당받아서 실행시킵니다.

- 실행중인 G,P의 포인터를 가지고 있습니다.

고루틴(G) : Go에서 동시성을 위해 사용되는 경량 스레드

- Go런타임이 관리합니다.

- 컨텍스트 스위칭을 위한 SP, 고루틴 상태정보를 가지고 있습니다.

- LRQ에서 대기합니다.

논리적 프로세서(P) : OS스레드가 특정 고루틴을 실행 시킬 수 있도록 매핑
- Go프로그램에서 사용 가능한 프로세서의 최대 수는 GO의 변수 'GOMAXPROCS' 값에 따라 결정됩니다.
- GOMAXPROCS의 기본값은 컴퓨터의 논리적 CPU 코어 개수

- 프로세스나 스레드의 실행 상태를 저장하고 복원하는 데 필요한 모든 정보(컨텍스트 정보)를 가지고 있으며, LRQ를 가지고 있어서 큐로부터 전달받은 G를 M에 할당합니다.

로컬큐(LRQ) :
- P마다 하나씩 존재합니다.

- 내부적으로 FIFO, LIFO 2개의 큐를 혼합하여 사용합니다.

- P가 고루틴을 생성하거나 스케줄링할 때, 먼저 자신의 LRQ를 사용합니다.

- G를 하나씩 POP하여 논리적 프로세서(P)에 전달합니다.

- GO에는 GRQ와 LRQ 2개의 큐가 존재함으로서 Race Condition과 Lock을 예방 할 수 있습니다.

글로벌큐(GRQ) :
- LRQ에 할당되지 못한 큐가 존재합니다.
- 실행중인 G은 한번에 10ms까지 실행되는데 10ms동안 실행된 G은 대기 상태가 되어 글로벌큐로 이동됩니다.
- 고루틴 생성 시점에 LRQ가 가득 차있으면 글로벌큐에 고루틴이 저장됩니다.

- GRQ는 P의 LRQ가 비어있을 때만 사용됩니다.

로컬큐에서 2개의 큐를 사용하는 이유?

LRQ에서 FIFO와 LIFO를 함께 사용하는 이유는 캐시 지역성(cache locality) 때문입니다.

실행중인 고루틴 G에서 새로운 고루틴 G-1를 만든다고 가정해봅시다.

G가 G-1의 종료되기를 기다려야하는 작업이라면 G입장에서는 G-1가 다른 고루틴들보다 빨리 종료되어야 하며,

G, G-1 모두 동일한 메모리의 위치를 참조할 가능성이 높기에 G-1가 종료되자마자 G가 실행되어야 캐시를 사용할 가능성이 매우 높아지는 등 여러 성능상 이점이 있습니다.

이러한 상황을 고려하여 고루틴은 FIFO, LIFO 2개의 큐를 사용합니다.

- 고루틴 생성 시 (LIFO 큐 사용): 새로운 G가 생성되면 LIFO 큐에 추가됩니다

고루틴 G, G2, G-1가 순서대로 생성됩니다. (G-1은 G에서 생성한 고루틴)
생성된 고루틴들은 LIFO 큐에 들어갑니다.
LIFO 큐 상태: [G-1, G2, G] (나중에 생성된 고루틴 G-1이 큐의 앞쪽에 위치)

- 고루틴 실행 (FIFO 큐 사용): FIFO큐에 들어온 G는 스케줄러에 의해 POP되어 실행됩니다.

실행될 G-1는 LIFO큐에서 POP되어 FIFO큐로 들어옵니다. (가장 마지막에 생성된 G-1이 FIFO 큐에 들어옵니다)
FIFO 큐 상태: [G-1]
G-1가 실행됩니다.
다음으로 G2가 FIFO 큐로 이동하고 실행됩니다.
FIFO 큐 상태: [G2]
G2가 실행됩니다.
마지막으로 G가 FIFO 큐로 이동하고 실행됩니다.
FIFO 큐 상태: [G1]
G1이 실행됩니다.

위와 같은 방식을 통해 cache locality를 확보하며 메모리 접근 시간과 프로그램의 실행속도를 줄일 수 있습니다.

고루틴이 실행되는 전체적인 순서는 이렇습니다.

P와 M의 초기화:
- Go 프로그램이 시작되면, 지정된 GOMAXPROCS 값에 따라 여러 개의 P가 생성됩니다.
- 각 P는 실행 대기 중인 고루틴들을 관리하기 위한 LRQ를 가지고 있습니다.
- OS는 M을 생성하고, M은 P와 연결되어 G을 실행합니다.
고루틴 실행:
- P는 자신의 LRQ에서 G을 꺼내어, 연결된 M에서 실행하도록 합니다.
- M은 P의 컨텍스트 내에서 고루틴을 실행하며, OS가 할당한 시간 동안 이를 수행합니다.
M의 스피닝(Spinning) 상태 진입:
- M이 유휴 상태로 전환되지 않고 계속해서 반복적으로 P의 LRQ에서 다른 고루틴을 찾으며 작업 가능 여부를 확인하며 대기하는 상태를 의미합니다.
- 스피닝 상태에서 M은 P의 LRQ에서 다음 고루틴을 가져와 실행합니다.
- 스피닝을 통해 고루틴이 곧 실행될 수 있는 상황에서는 컨텍스트 스위칭 없이 빠르게 고루틴을 실행할 수 있습니다.
- 스피닝 상태에서는 CPU 사이클을 소비하며 계속해서 LRQ를 확인하므로, 너무 오랫동안 스피닝을 유지하면 CPU 자원을 낭비할 수 있습니다.
고루틴 스케줄링 시작:
- P의 LRQ가 비어 있으면, P는 GRQ에서 고루틴을 가져옵니다, 하지만 GRQ도 비어있다면 다른 P에 존재하는 절반의 고루틴을 가져옵니다.(작업 훔치기 전략)
- 이러한 과정을 통해 고루틴이 효율적으로 스케줄링되고, CPU 자원이 최대한 활용됩니다.

고루틴 스케줄링 예시

Go 프로그램이 시작되면, GOMAXPROCS가 4로 설정되어 있다고 가정합니다.
4개의 P가 생성되고, 각각의 P는 G들을 관리하기 위한 LRQ를 가지고 있습니다.
운영체제는 여러 개의 M을 생성하고, 이들은 각 P와 연결되어 G을 실행합니다.

P1의 LRQ에 고루틴 G1, G2, G3가 있습니다.
M1이 P1과 연결되어 있고, G1을 실행 중입니다.
M1이 할당된 시간 동안 G1의 작업을 완료하면, M1은 스피닝 상태로 전환됩니다.
스피닝 상태의 M1은 P1의 LRQ에서 G2를 가져와 실행을 시작합니다.
P1의 LRQ가 비어 있다면, P1은 GRQ에서 고루틴을 가져오거나 다른 P의 고루틴을 훔쳐올 수 있습니다.

고루틴의 컨텍스트 스위칭 시점은 언제일까?

OS에서 컨텍스트 스위칭은 보통 시스템콜이 일어날때 발생하지만,

고루틴은 GO스케줄러가 관리하기에 아래와 같은 상황에서 컨텍스트 스위칭이 발생합니다.

고루틴간 통신 (unbuffered channel에 접근 시)
시스템 콜
블로킹 작업 (시스템 I/O 등)
고루틴 생성 및 종료
time.Sleep()과 같은 Sleep 함수를 통해 일정시간 대기
runtime.Gosched() Function 같은 로직이 실행

AWS 계정간 S3 데이터 옮기기

겅겅겅 — Sat, 13 Apr 2024 21:25:12 +0900

다른 AWS 계정에서 사용하는 S3 데이터를 옮겨야하는 상황이 발생했습니다.

약 5개 정도의 S3를 옮기면 되어서, 간단하게 AWS CLI를 통해 데이터를 옮기는게 좋다는 생각이 들었습니다.

AWS CLI S3 API를 활용한 데이터 이전 흐름도

오른쪽 : 계정 A (목적지 버킷)

왼쪽 : 계정 B (소스 버킷)

1. 계정 A에서 S3에 대한 정책 생성

계정A에서 목적지 버킷에 대한 GET,PUT,LIST 권한,

소스버킷에 대한 LIST, GET 권한이 존재하는 정책을 생성 후 계정 A의 사용자에게 부여합니다.

s3-migration-policy라는 정책을 생성 아래 JSON을 이용해 생성하였습니다.

아래 JSON은 해당 S3 정책에 대한 예시입니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetObject",
                "s3:GetObjectTagging",
                "s3:GetObjectVersion",
                "s3:GetObjectVersionTagging"
            ],
            "Resource": [
                "arn:aws:s3:::awsexamplesourcebucket",
                "arn:aws:s3:::awsexamplesourcebucket/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:PutObjectTagging",
                "s3:GetObjectTagging",
                "s3:GetObjectVersion",
                "s3:GetObjectVersionTagging"
            ],
            "Resource": [
                "arn:aws:s3:::awsexampledestinationbucket",
                "arn:aws:s3:::awsexampledestinationbucket/*"
            ]
        }
    ]
}

2. 계정A에서 생성한 S3 정책을 계정A의 사용자에게 연결

계정A의 사용자에게 생성한 정책을 추가합니다.

3. 계정B의 소스버킷에 정책 설정

계정B의 소스 버킷 정책에 계정A에 대한 S3정책을 추가합니다.

S3 Statement에 있는 Principal, Resource를 계정A, 목적지 버킷에 대한 정보로 수정합니다.

{
	"Version": "2012-10-17",
	"Statement": [
            {
                "Sid": "AllowForS3Access",
                "Effect": "Allow",
                "Principal": {"AWS": "Account A AccountID"},
                "Action": [
                    "s3:ListBucket",
                    "s3:GetObject"
                ],
                "Resource": [
                        "arn:aws:s3:::awsexamplesourcebucket/*",
                        "arn:aws:s3:::awsexamplesourcebucket"
                ]
            }
	]
}

4. S3권한 정책이 부여된 계정A의 사용자 계정으로 CLI 사용

계정A의 사용자에 대한 AccessKey를 활용하여 CLI를 설정합니다.

아래의 위치에 AWS CLI 사용을 위한 자격증명 파일이 존재합니다.

Windows: C:\Users\username\.aws\credentials
Mac/Linux: ~/.aws/credentials

만약 자격증명 파일이 없다면 명령어를 사용하여 추가 가능합니다.

Set-AWSCredential `
                 -AccessKey 사용자AccessKey `
                 -SecretKey 사용자SecretKey
                 -StoreAs 프로파일명지정

자격증명이 정상적으로 되어있다면 아래와 같은 명령어로 소스버킷의 모든 폴더와 파일을 목적지 버킷으로 옮길 수 있습니다.

aws s3 sync s3://source-s3-bucket s3://target-s3-bucket

Session Manager를 이용해 Private DB 접속하기

겅겅겅 — Fri, 15 Dec 2023 21:11:23 +0900

일반적으로 DB는 Private Subnet 즉 인터넷 엑세스가 불가능한 서브넷에 생성합니다.

하지만 로컬에서 Private Subnet에 있는 DB에 대한 엑세스가 필요하기에

Session Manager와 Bastian Host 이용하여 DB에 접속하는 방법을 정리하려 합니다.

EC2 Session Manager 연결

1. EC2 UserData에 스크립트 추가

Bastian Host UserData에 Session Manager 설치 스크립트를 추가합니다.

#!/bin/bash

yum update -y
yun install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
yum install -y amazon-ssm-agent

echo "session required pam_limits.so" >> /etc/pam.d/su
systemctl enable amazon-ssm-agent
systemctl start amazon-ssm-agent

2. IAM 권한 및 역할 추가

EC2에 SSM권한이 있는 IAM 역할을 추가합니다.

아래 2가지 ssm, ssmmessages 두 정책이 SSM관련 권한입니다.

ssm:* (EC2가 SSM서비스에 엑세스 하기위한 권한)
ssmmessages:* (SSM에서 EC2에 요청을 전달하기 위한 권한)

대표적으로 AWS에서 관리하는 정책인 AmazonEC2RoleforSSM 정책이나 SSM에 필요한 권한이 연결된 Role을 생성해 EC2에 연결합니다.

3. Session Manager 연결 확인

위에 두 조건이 만족되면 Session Manager 연결이 가능합니다.

로컬CMD(윈도우)에서 Session Manager 접속

1. Session Manager 플러그인을 설치합니다.

Session Manager 설치 프로그램 URL (윈도우, 맥)

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/install-plugin-windows.html

Windows에 Session Manager 플러그 인 설치 - AWS Systems Manager

최상의 결과를 위해 Windows PowerShell 버전 5 이상을 사용하여 Windows에서 세션을 시작하는 것이 좋습니다. Windows 10의 Command 쉘을 사용할 수도 있습니다. Session Manager 플러그인에서는 PowerShell 및 Command

docs.aws.amazon.com

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/install-plugin-macos-overview.html

macOS에 Session Manager 플러그 인 설치 - AWS Systems Manager

플러그인에 Python 2.6.5 이상 또는 Python 3.3 이상이 필요합니다. 기본적으로 설치 스크립트는 시스템 기본 버전의 Python에서 실행됩니다. 대체 버전의 Python을 설치하고 이를 사용하여 Session Manager 플

docs.aws.amazon.com

2. 터널링 명령어 실행

ssm에서 bastian host를 이용한 터널링 명령어

aws ssm start-session --target <bastian-host-id> --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters "{\"host\":[\"private subnet의 DB엔드포인트\"],\"portNumber\":[\"실제 DB포트\"],\"localPortNumber\":[\"로컬에서 사용할 포트\"]}"

여러 DB에 대한 터널링을 한번에 실행되도록 저는 bat파일을 만들어 사용했습니다.

아래 bat파일을 실행하게되면 총 3개의 세션 터미널이 열리게됩니다.

@echo off

:: start session
start cmd /c aws ssm start-session --target bastian-host-id --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters "{\"host\":[\"private subnet의 DB1엔드포인트\"],\"portNumber\":[\"3306\"],\"localPortNumber\":[\"13306\"]}"

start cmd /c aws ssm start-session --target bastian-host-id --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters "{\"host\":[\"private subnet의 DB2엔드포인트\"],\"portNumber\":[\"3306\"],\"localPortNumber\":[\"13306\"]}"

start cmd /c aws ssm start-session --target bastian-host-id --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters "{\"host\":[\"private subnet의 DB3엔드포인트\"],\"portNumber\":[\"3306\"],\"localPortNumber\":[\"13306\"]}"

pause

bat 파일 실행 후 화면

SSM 터널링을 이용해 private DB 접속하기

위와 같이 session 터널링 터미널이 열려있는 동안 로컬(인터넷망)에서 bastian host를 통과해 private DB 접속이 가능합니다.

로컬 -> bastian host -> DB로 접속이 진행되기에 host에는 루프백 주소를, 포트는 터널링 포트를 지정해줍니다.

session이 연결된 상태에서 Test Connection을 시도하면 성공합니다.

AWS S3 Gateway Endpoint, Interface Endpoint를 이용하여Private하게 접속하기

겅겅겅 — Sat, 4 Nov 2023 20:39:39 +0900

S3는 기본적으로 Public리소스라서 Private하게 접근하려면 VPC엔드포인트를 이용하여 접근해야합니다.

Gateway Endpoint, Interface Endpoint 2가지 방법으로 Private하게 접속 할 수 있습니다.

Interface Endpoint 와 Gateway Endpoint

2가지 방법으로 S3와 private한 연결을 만들 수 있습니다.

두 Endpoint모두 S3와 Private하게 통신을 할 수 있는 방식이지만 몇가지 차이점이 있습니다.

대표적으로는 Interface Endpoint는 On-Prem등 외부 접속을 허용하고, Gateway Endpoint는 허용하지 않는 차이점이 있습니다.

Interface Endpoint란?

예전에는 S3에 private하게 접속하려면 Gateway Endpoint만을 사용해야했지만, 지금은 interface Endpoint로도 접속이 가능합니다.

On-Prem, 다른 Region 등 외부 리소스와 통신할때 주로 사용됩니다.

SG를 사용하여 접근을 제한 할 수 있습니다.

Interface Endpoint 생성

범주는 AWS서비스, 서비스 이름에서는 Interface유형의 com.amazonaws.ap-northeast-2.s3을 선택합니다.

추가로 Interface Endpoint가 생성될 VPC, Subnet, 보안그룹, 엑세스 정책이 필요합니다.

Interface Endpoint의 도메인

만들어진 Endpoint의 상세 페이지에서 도메인을 확인 할 수 있는데

해당 도메인을 통해 S3로 Private하게 접속 할 수 있습니다.

이 주소를 통해 외부 (On-Prem, 다른 Region)에서 접속이 가능합니다.

Interface Endpoint로 private하게 접속하기

Interface Endpoint가 생성되면 만들어진 도메인 주소로 nslookup해서 확인해보면

PrivateIP를 확인 할 수 있습니다.

추가로 아래 2가지 방법으로 Private하게 통신이 가능합니다.

1. URL로 접속하기 : https://bucket.<interface-endpoint 도메인>/버킷명/S3 데이터 Prefix

2. cli로 접속하기 : aws s3 --endpoint-url <interface-endpoint 도메인> <S3 cli 명령어>

Gateway Endpoint란?

Interface Endpoint와 다르게 On-Prem을 포함한 VPC외부의 접속과 다른 Region에서의 접속을 허용하지 않습니다.

생성 시 VPC내부의 Routing Table의 규칙이 만들어집니다.

IAM 같은 정책을 사용하여 리소스를 제한합니다.

Gateway Endpoint 생성

서비스에서 Gateway유형의 서비스를 생성합니다.

Interface Endpoint는 VPC, 엑세스 정책이 필요합니다. Subnet이 아닌 VPC에 지정되는 리소스이며 SG를 사용하지 않습니다.

Gateway Endpoint로 private하게 접속하기

생성이 성공하면 서브넷의 라우팅 테이블에 라우팅이 추가되고,

Interface Endpoint와 다르게 nslookup을 통해 S3를 질의하여도 privateIP를 확인할수는 없지만

VPC 내부에서 통신 시 IGW가 아닌 VPC의 Gateway Endpoint를 통해 private하게 통신 할 수 있습니다.

실제로 S3의 PublicIP를 이용하여 traceroute를 진행해보면 모두 마스킹 된 값이지만

IGW나 NAT를 타고 나가는 기록은 보이지 않습니다.

AWS S3 Replication과 S3 Batch에 대해 알아보자

겅겅겅 — Tue, 31 Oct 2023 21:06:51 +0900

S3 안의 데이터에 대한 백업이나 동기화가 필요한 순간이 있습니다

그럴때 S3 Replication과 S3 Batch 작업을 통해 구현 가능합니다.

즉 S3 Batch와 S3 Replication 을 이용하면 S3에 대한 복제와 지속적인 동기화가 가능합니다.

AWS S3 복제 (Replication) 란?

S3 복제를 사용하면 CRP (교차 리전 복제) 와 SRR (동일 리전 복제) 두가지 방법으로 S3 데이터를 복제 할 수 있습니다.

다른 계정간 S3 복제 또한 가능합니다.

데이터의 백업을 생성하거나, 더 효율적인 S3 스토리지 클래스를 사용하는 등 다양한 목적을 위해 사용됩니다.

S3 Replication 생성

S3 복제를 하기 위해선 원본 버킷에 복제 규칙을 생성해야합니다.

S3 -> 관리 -> 복제 규칙 생성에서 생성 가능합니다.

규칙 범위 선택

필터를 사용해서 복제될 데이터에 대한 필터를 지정 할수도 있습니다.

저는 백업 용도로 만들기 위해 모든 객체에 적용하여 규칙을 만드려고 합니다.

대상 버킷 설정

복제할 버킷의 수신 버킷 (목적지 버킷)을 지정합니다.

S3 Role

iam 역할은 원본 버킷과 목적지 버킷에 대한 권한이 모두 있어야 합니다.

추후 S3 Batch 작업을 위해 batchoperation에 대한 값도 추가하였습니다.

암호화 설정

암호화는 대상 객체에 대한 암호화를 하는 옵션이기에

대상객체가 사용하는 KMS키를 사용하시면 됩니다.

스토리지 및 추가 복제 옵션

필요시 대상의 스토리지 클래스를 지정 할 수 있고

추가 복제 옵션을 선택 가능합니다.

- RTC : 추가 금액을 지불하고 복제 시간을 제어 할 수 있습니다.

- 복제 지표 : 두 버킷간 복제중 메트릭을 모니터링 할 수 있습니다.

- 삭제 마커 복제 : 원본 버킷에서 삭제한 객체에 대한 삭제마커를 목적지 버킷에서도 적용합니다.

- 복제본 수정 동기화 : 원본 버킷에서 삭제한 객체에 대한 수정를 목적지 버킷에서도 적용합니다.

상태 활성화

복제 규칙이 생성 후 활성화 상태로 지정해주면 만들어준 규칙이 새롭게 생성한 데이터에게 적용됩니다.

복제본 생성 확인

복제 규칙이 활성화된 버킷에 객체가 추가되면 관리 구성의 상태가 Pending이 되고 시간이 지나면 Completed 상태가 됩니다.

복제 구성이 Completed가 되면 목적지 버킷에도 해당 객체가 생성됩니다.

복제된 객체에는 Replica 라는 형태로 표시됩니다.

복제본 삭제 확인

복제 규칙을 만들때 삭제 마커 옵션을 활성화 해두었기에

원본 S3에서 객체를 삭제하면 복제본에서도 동일하게 객체가 삭제됩니다.

원본에서 삭제

복제본에서 조회

ㅂ

AWS S3 배치 작업 (Batch) 란?

복제규칙을 만들어도 기존의 소스 버킷의 데이터들은 목적지 버킷에 존재하지 않습니다.

따라서 S3 배치 작업을 통해 기존 데이터를 한번에 옮기는 작업이 필요합니다.

S3 Batch 작업은 람다를 통해서도 가능합니다.

배치 작업 생성

S3의 배치에서 작업 생성으로 배치작업을 생성 할 수 있습니다.

매니페스트 선택

매니페스트는 배치 프로세스의 일부로서 처리되어야하는 파일 목록과 처리 방법에 대한 정보를 포함하는 파일 및 데이터구조입니다.

매니페스트에는 파일의 경로, S3 버킷 및 키, 파일 처리 방법 등이 들어있고 파일 형식, 인코딩과 같은 옵션 및 구성 정보 또한 들어있습니다.

소스와 필터 지정

배치 작업을 진행할 목적지 버킷을 지정하고, 배치작업의 필터를 지정 가능합니다.

작업 선택

S3 복제 구성을 사용하였기에 매니페스트를 만들때는 '복제'만 사용 가능합니다.

권한 설정

앞선 복제 규칙에 사용했던 원본과 대상 S3에 대해 권한이 있는 권한을 지정합니다.

배치 작업 실행 및 성공

S3 배치 작업 페이지에서 작업을 선택하고 실행할 수 있습니다.

DNS존과 네임서버, AWS Resolver로 On-Prem DNS서버 질의하기

겅겅겅 — Thu, 19 Oct 2023 22:25:52 +0900

DNS Zone이란?

DNS Zone은 도메인 네임스페이스라고도 합니다.

DNS는 트리구조로 되어있는데 최상위에 root 도메인, TLD(Top Level Domain), 서브 도메인으로 이루어져있습니다.

각 도메인 영역마다 별도의 Zone을 만들어서 관리 할 수 있습니다.

예를 들어 TLD인 google.com, 서브도메인 a.google.com , b.google.com 마다 각각의 Zone을 가질 수 있습니다.

영역에 대한 모든 정보는 DNS 영역 파일이라는 이름으로 저장됩니다.

네임서버와 DNS 레코드란?

사용자가 도메인을 질의하거나, 도메인을 통해 통신할때, 도메인의 네임서버에 질의를 하여 설정된 값을 찾아 통신을 하게 합니다.

이때, 네임서버에 설정된 값들을 DNS레코드라고 합니다.

각 DNS Zone 마다 DNS레코드를 가지며, Root DNS 서버는 전 세계에 13개가 존재합니다.

AWS의 Route53에서도 네임서버를 확인 할 수 있습니다.

DNS 레코드 값

도메인 명 : example.com
- DNS 존의 주 도메인 이름을 나타냅니다.
SOA 레코드 (Start of Authority):
- 주 존에 대한 권한을 설정하는 레코드로, DNS 존의 시작을 나타냅니다.
NS 레코드 (Name Server):
- 주 DNS 서버와 관련된 네임서버의 정보를 포함하며, 해당 도메인의 DNS를 관리하는 네임서버를 지정합니다.
- 도메인에 대한 네임서버의 권한을 가지고 있는지 확인합니다.
A 레코드 (Address):
- 호스트 이름(예: www)을 IPv4 주소로 매핑하는 레코드입니다.
- 하나의 도메인에 여러 A레코드를 사용 할 수 있습니다.
AAAA 레코드 (IPv6 Address):
- 호스트 이름(예: www)을 IPv6 주소로 매핑하는 레코드입니다.
CNAME 레코드 (Canonical Name):
- 호스트 이름(예: www)을 다른 도메인 이름(예: another-example.com)에 별칭으로 매핑하는 레코드입니다.
MX 레코드 (Mail Exchanger):
- 이메일을 수신하는 메일 서버의 우선순위 및 호스트 이름을 지정하는 레코드입니다.
TXT 레코드 (Text):
- 텍스트 정보를 포함하며, SPF(Sender Policy Framework) 레코드와 같이 이메일 스팸 방지 정책과 같은 정보를 포함할 때 사용됩니다.
SRV 레코드 (Service):
- 서비스의 위치 및 우선순위를 지정하며, 주로 VoIP 및 SIP 등과 같은 서비스에서 사용됩니다.
PTR 레코드 (Pointer):
- IP 주소를 호스트 이름으로 역으로 해석하는데 사용됩니다.

DNS Resolver란?

DNS Resolver는 클라이언트(사용자)가 DNS 서버에 보내는 요청을 처리합니다.

이러한 요청을 DNS Query라고 하며,

DNS Resolver의 동작 순서는 아래와 같습니다.

클라이언트에서 DNS 쿼리를 발생시킵니다.
DNS 쿼리가 Resolver에 도착하면 도메인 트리구조(Root -> TLD -> SubDomain)에 따라 각 네임서버에 요청하여 응답을 받습니다.
전달받은 요청 DNS의 IP를 클라이언트에 반환합니다.

출처 : AWS

AWS Resolver로 On-Prem과 DNS 질의하기

AWS와 On-Prem 이 합쳐진 하이브리드 환경에서는 두 환경간 DNS 질의가 필요합니다.

DX를 통해 두 인프라의 통신이 가능하다면 AWS Resolver의 Inbound Endpoint, Outbound Endpoint를 이용하여 이를 구현 할 수 있습니다.

각 EndPoint들은 VPC와 연동되며, 1초의 약 10000번의 DNS쿼리를 지원합니다.

Inbound Endpoint (On-Prem -> AWS)

외부(On-Prem) 네트워크가 DNS쿼리를 AWS의 Resolver로 보내게되는 엔드포인트입니다.

Outbound Endpoint (AWS -> On-Prem)

AWS의 네트워크가 DNS쿼리를 외부(On-Prem)의 Resolver로 보내게되는 엔드포인트입니다.

AWS <-> On-Prem Resolver 생성하기

1. Route53의 Resolver에서 인바운드 엔드포인트를 생성

2. 엔드포인트와 VPC, SG 연결

3. 엔드포인트의 IP 주소 지정

HA를 위해 2개의 가용영역에 IP를 지정해야합니다.

여기서 생성된 IP를 이용하여 On-Prem -> AWS DNS질의를 하게됩니다.

두 인프라 간의 DNS 질의를 위한 NAT라고 생각하셔도 될 것 같습니다.

4. Outbound Endpoint의 VPC, SG를 연결합니다.

5. Outbound Endpoint IP 생성

Inbound Endpoint와 동일하게 2개의 IP를 생성합니다.

여기서 생성된 IP는 AWS -> On-Prem으로 DNS 쿼리를 전달할때 사용되는 NAT라고 생각하시면 됩니다.

6. 규칙(Rule) 생성

Resolver의 규칙을 생성합니다.

Resolver에서 해석을 위한 도메인을 지정합니다.

대상 IP주소에는 On-Prem의 NameServer IP와 포트를 지정해주시면됩니다.

생성한 Resolver 확인

Direct Connect로 On-Prem, AWS VPC 연결하기 private VIF

겅겅겅 — Sun, 24 Sep 2023 17:38:55 +0900

업무중 AWS VPC와 On-Prem사이 DX를 통해 전용선 연결이 필요하게 되었습니다.

DX를 연결하며 진행하였던 방법을 공유하려합니다.

Direct Connect (DX)란?

on-prem의 리소스와 AWS 내의 VPC를 전용선으로 연결하기 위한 AWS의 서비스입니다.

전용선으로 연결하기에 인터넷을 통한 연결보다 안전하게 통신 할 수 있습니다.

AS와 ASN

AWS DX를 이해하기 위해서는 AS와 ASN, BGP프로토콜을 알아야합니다.

AS

Antonomous System의 약자로 인터넷에서 라우팅을 관리하고 제어하는 단위이며, 네트워크의 도메인입니다.

ISP, 기업의 on-prem 네트워크, 클라우드 제공자 (AWS,GCP)등이 AS를 가집니다.

각 AS는 ASN이라는 고유 번호를 가지며, 각각의 AS끼리는 BGP프로토콜을 사용하여 서로의 라우팅 정보를 교환합니다.

BGP 프로토콜

AS간의 라우팅 정보를 교환하고 인터넷 트래픽을 전달하는데 사용됩니다,

대규모 네트워크에서 라우팅을 관리하며, AS간 라우팅 정보를 전달하는데도 사용됩니다.

ASN

ASN, Autonomous System Number이란 인터넷에서 라우팅을 관리 및 제어하기 위해 사용되는 AS의 고유 번호입니다.

BGP프로토콜을 아용하여 각 AS끼리 라우팅 정보를 교환할때 각각의 AS를 식별하는 번호로써도 사용됩니다.

DX를 이용해 AWS와 On-Prem을 연결하기위해 ASN을 작성 할 때 VIF와 VGW는 동일한 ASN을 가져야합니다.

가상 인터페이스 (Virtual Interface)

VIF, Virtual Interface는 DX에서 AWS와 온프레미스 환경과 전용 연결을 설정하기 위한 리소스입니다.

DX와 AWS의 논리적 연결 포인트라고 생각하시면 편할 것 같습니다.

VIF의 인터페이스 유형은 다음과 같습니다.

public : s3와 같은 퍼블릭 리소스와 연결
private : VCP같은 pirvate 리소스와 연결
transit : transiant gateway에 연결

최초 VIF를 생성하면 상태가 confriming, VPC상태는 pending, BGP 상태가 down되어 있습니다.

가상 프라이빗 게이트웨이 (Virtual Private Gateway)

VGW (Virtual Private Gateway)는 VPC와 연동하기 위한 DX의 리소스입니다.

이름과 VIF의 ASN을 입력하여 생성 후 VPC와 연결합니다.

하나의 VPC와 연동되기에 DX와 연동할 VPC 갯수 만큼 생성해주시면 됩니다.

추후 DXGW, Direct Connect Gateway와 연동하여 on-prem과 AWS의 여러 VGW를 연결 하여 사용 가능합니다.

VPC 연동 후 모습

Direct Connect Gateway생성

DXGW, Direct Connect Gateway를 통해 VIF와 연결후 VGW를 추가로 연동하여 DX를 통한 전용선 통신을 할 수 있습니다

이름과 VIF의 ASN을 이용해 생성 가능합니다.

생성 후 상세페이지의 게이트웨이 연결을 통해,

DXGW로 연결할 게이트웨이를 지정 할 수 있습니다.

VIF가 transit이면 transiant gateway를, private이라면 VGW를 연결 할 수 있습니다.

VIF가 private이면 transiant gateway를 연결 할 수 없습니다.

접두사는 VGW에 연결된 AWS의 리소스 접두사를 입력해주시면 됩니다.

EX) VPC면 VPC의 cidr주소를 입력하면 됩니다.

DXGW에는 여러 VGW를 연결 할 수 있습니다.

연결되는데 시간이 조금 걸립니다.

가상 인터페이스(VIF)와 DXGW 연결

가상 인터페이스 상세화면에서 이전에 생성한 DXGW와의 연결을 수락합니다.

수락이 성공하면 VIF 상세화면에서

연결은 성공해도 BGP연결은 down이 되게됩니다.

VIF 상태

VIF 상태는 1,2 계층의 연결이 성공적으로 수락되었음을 나타냅니다.

BGP 상태

BGP상태는 3 계층에 대한 연결을 나타내는데, VIF 수락 후 추가적인 작업(라우팅 전파) 후 BGP가 UP이 됩니다.

라우팅 전파속성 설정

VGW에 연결된 VPC의 라우팅 테이블의 VGW에 대한 전파속성을 활성화로 변경해줍니다.

라우팅 테이블에 DX관련 VGW에 대한 CIDR 및 전파 편집 속성이 생기기까지 조금 시간이 걸립니다..!

BGW UP

전파 속성이 활성화되면 VIF에서 BGP옵션이 UP이 되며, on-prem과 AWS VPC의 연결이 완료되게 됩니다.

스프링 서블릿(servlet)에 대해 알아보자

겅겅겅 — Sun, 17 Sep 2023 19:32:00 +0900

업무 중 application.yml에 붙어있던 prefix를 특정 api에서는 제거해야하는 상황이 생겼습니다.
그래서 서블릿을 사용해야 할 것 같아, prefix를 제거하고 새로 서블릿을 만들어 라우팅을 하여 해결하였지만 이해가 부족한 것 같아
서블릿에 대하여 다시 공부하고 정리하려합니다

서블릿이란?

웹 어플리케이션에서 HTTP 요청과 응답 처리를 위한 스프링에서 제공하는 핵심 기능입니다.
스프링 부트에서는 HttpServlet클래스를 상속을 받아 사용하며, Servlet Container에 의해 실행됩니다.
doGet, doPost, doPut, doDelete 등의 메서드를 사용하여 요청을 처리하며
스프링 부트에서는 어노테이션과 HttpServlet 상속을 이용하여 간단하게 생성 할 수 있습니다.

아래 사진은 /apis라는 url이 붙은 요청을 캐치하는 서블릿 예시코드입니다.
추가로 생성한 서블릿에는 MultipartConfig 설정이 있어야 해당 서블릿에서 들어오는 멀티파트 요청을 처리 할 수 있습니다.

서블릿 컨테이너란?

스프링에서 서블릿을 관리해주는 컨테이너입니다.
클라이언트의 요청을 받고 응답하도록 웹서버(nginx 등)와 소켓을 만들어 통신합니다.
서블릿 컨테이너는 쓰레드 풀을 가지며 요청이 도착하면 쓰레드를 가져와 서블릿 인스턴스를 생성하여 요청을 처리합니다.
대표적인 서블릿 컨테이너로 톰캣(Tomcat)이 있습니다.

1. 웹서버와의 통신지원 : 소켓기능들을 API로 제공하여 복잡한 과정을 생략하고, 비즈니스 로직에 대해서만 집중하도록 도와줍니다.
2. 서블릿 생명주기 관리 : 서블릿 클래스를 로딩하여 인스턴스화하고, 초기화 메소드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를 호출합니다.
3. 멀티쓰레드 지원 및 관리 : 서블릿 컨테이너는 요청이 올 때 마다 새로운 자바 쓰레드를 하나 생성하는데, HTTP 서비스 메소드를 실행한 후 쓰레드는 자동으로 됩니다. 이러한 관리를 컨테이너가 알아서 해준다.

서블릿 동작 과정 및 생명주기

추가로 서블릿의 생명주기 관련 메소드 또한 오버라이딩하여
비즈니스 로직을 추가 가능합니다.
init(), service(), destroy()로 서블릿의 생명주기를 관리 할 수 있습니다.

서블릿 동작 과정

1. 클라이언트에서 URL 호출
2. 웹서버에서 URL을 확인하여 해당 서블릿으로 요청 전달, 없으면 서블릿 클래스의 init()으로 생성
3. 서블릿 컨테이너는 요청정보를 HttpServletRequest, HttpServletResponse 두 객체에 저장
4. 서블릿 클래스의 service()메소드 호출 (HTTP Method에 따라 서블릿의 doGet, doPost 호출)
5. 요청 처리 후 HttpServletResponse 객체에 HTTP 데이터를 담아 응답
6. 웹서버가 클라이언트에 응답처리
7. 서블릿의 destroy() 호출하여 GC에 의해 서블릿 종료

디스패쳐 서블릿이란?

서블릿과 함께 스프링을 사용하다보면 항상 듣게되는 디스패쳐 서블릿입니다.
서블릿 컨테이너 앞에서 최초로 가장 먼저 요청을 받고 처리하기에 Front Controller라고 부르기도 합니다.

디스패쳐 서블릿을 이해하기 위해서는 스프링MVC 패턴에 대한 이해가 먼저 필요한데
간단하게 정리하자면 아래 3가지 엔티티를 사용하여 만들어내는 스프링의 구조화된 패턴 방식입니다.

Model : 어플리케이션의 비즈니스 로직 및 데이터
View : Model의 데이터를 사용하여 클라이언트에게 보여줄 사용자 UI
Controller : HTTP 요청을 받아들이고, 모델을 생성 및 가공하여 적절한 뷰를 반환

디스패쳐 서블릿은 다음과 같은 순서로 역할을 수행합니다.

1. 클라이언트에서 최초 요청을 전달받습니다.
2. 요청을 처리할 적절한 핸들러(컨트롤러)에 라우팅합니다. (핸들러 매핑을 통해 요청 URI와 컨트롤러를 매핑합니다.)
3. 적절한 핸들러를 실행시킬 수 있는 Handler Adapter를 통해 선택된 핸들러를 실행시킵니다.
4. 선택된 핸들러(컨트롤러)는 비즈니스 로직을 수행합니다.
5. 핸들러(컨트롤러)가 비즈니스 로직 실행을 마치면 처리 결과를 Model에 설정하여 HandlerAdapter에 view name을 반환합니다.
6. 전달받은 view name을 뷰 리졸버에 반환하고 view name과 맡는 view객체를 반환합니다.
7. 디스패쳐 서블릿은 view에 model을 전달합니다.
8. 렌더링하여 클라이언트에 반환합니다.