발자취

[AI] 딥러닝 개념정리

usingsystem — Tue, 3 Mar 2026 22:29:23 +0900

1. 신경망(Neural Network)과 딥러닝

신경망은 중요한 feature를 사람이 직접 설계하지 않고, 데이터로부터 스스로 특징을 학습하고 가중치(weight)를 부여하는 모델이다.
여러 층(layer)에 걸친 내부 파라미터를 학습하여 복잡한 패턴을 표현할 수 있으며, raw data를 거의 그대로 입력으로 사용 가능하다는 장점이 있다.
이러한 특성 때문에 컴퓨터 비전, 자연어 처리 등 다양한 분야에서 활용된다.

신경망은 지도학습(supervised learning)과 비지도학습(unsupervised learning) 모두에 사용될 수 있다.

신경망은 기본적으로 입력층(input layer), 은닉층(hidden layer), 출력층(output layer)으로 구성된다.
은닉층이 없는 경우 단층 퍼셉트론(perceptron) 또는 선형 모델과 유사한 형태가 된다.

뉴런(Perceptron)과 활성화 함수

신경망에서 하나의 뉴런(neuron)은 퍼셉트론(perceptron)이라고도 불리며, 하나의 함수로 볼 수 있다.
뉴런 내부에는 pre-activation과 activation(활성화 함수) 단계가 존재한다.

z=w1x1+w2x2+bz = w_1 x_1 + w_2 x_2 + b

위 식이 pre-activation 값이며, 여기에 활성화 함수를 적용하면 다음 레이어로 전달되는 출력값이 된다.

만약 히든레이어없이 입력층과 출력층만 존재하고 출력층에 Linear Regression을 한다면 전통적인 머신러닝의 Linear Regression과 다를게 없다.

activation Functions 종류

sigmoid - output에서 많이 사용됨 범위 (0~1)

tanh - 시계열 데이터 처리에서 많이 사용됨 (-1 ~ 1)

relu - 현대 deep learning은 거의 relu사용 범위 ( 0~x), 기울기가 항상 1

activation(출력) 종류

Softmax Activation Function - 출력값의 다중 class 분류를 위해 출력값에 대해 정규화 (확률 분포 출력)

1) Neural Network 훈련의 핵심 방법

손실함수 → 역전파로 gradient 계산 → 경사하강법으로 업데이트

이 세 가지는 훈련 과정에서 모두 필수적으로 연결되어 동작합니다.

(1) 손실함수

경사하강법과 오차 역전파가 동작하려면 손실함수가 필요. 모델의 예측과 정답 사이의 차이를 수치로 나타냅니다.

비용함수(cost function), 목적함수(object function) 등으로 불리며 경사하강법이 가능하도록 미분 가능한 함수를 정의

손실함수는 모델 전체가 아니라 출력값에만 적용된다.

Input → Hidden Layers → Output Layer → Loss Function

딥러닝을 사용하여 문제를 해결 하기 위한 대표적 손실함수(loss) 구하는 3가지 ( 대부분 이 3가지를 사용 )

Linear Regression (선형회귀 문제에서) - MSE(Mean Squared Error) 실수 값을 예측하는 회귀 문제에서 사용된다.
Binary Classification (이진분류 or Logistic Regression 문제에서) - Binary-Cross-Entropy Sigmoid 출력과 함께 사용되며, 두 클래스 간 확률 예측에 사용된다.
Multi-Class Classification (다중분류 문제에서) - 항상 활성화함수(activation)은 softmax로 사용해야하며 loss함수는 Categorical-Cross-Entropy 출력층에 함께 사용된다, 이 때 softmax를 사용하기 위해서는 one hot encoding을 필수적으로 해줘야한다. 여러 클래스 확률 분포를 학습한다. so

(2) Backpropagation (오차 역전파)

손실 함수를 기준으로, 각 가중치가 얼마나 손실에 기여했는지 미분 해서 기울기(gradient 를 구합니다.즉 손실함수를 최소화 하는 방향으로 신경망 전체의 parameter(w혹은 b)가 어느 방향으로 얼마나 바뀌어야 하는지(gradient)를 계산하는것 (경사하강법에 사용할 방향을 구하는 부분임.)

(3) Gradient Descent (경사하강법)

미분에 의한 함수 기울기를 구해 최소값을 찾아가는 방법으로 오차 역전파로 계산된 gradient(기울기 방)를 사용해 가중치를 실제로 업데이트합니다.

목적 - 실제값과 예측값의 차이를 최소화 하는 parameter(w혹은 b) 발견

방법 - 손실함수를 정의하여 손실함수의 값이 0으로 수렴하도록 parameter (w혹은 b) 조절

new w = old w - (learning rate) * (gradient)

ㄴ learning rate - 이동속도

ㄴ gradient - 미분 기울기 방향 cost function, 음의기울기면 +, 양의 기울기면 -

개념	역할
손실 함수	예측이 얼마나 틀렸는지 평가
역전파(backprop)	모든 파라미터의 gradient 계산
경사하강법(optimizer)	gradient를 이용해 실제 파라미터 업데이트

2) 경사하강법안에 Global Minimum, Learning Rate, Optimizer

경사하강법은 손실 함수의 global minimum을 찾기 위해, learning rate를 사용하여 optimizer 방식으로 파라미터를 업데이트하는 과정이다.

(1) Global Minimum: 손실 함수의 최종 목표( 경사하강법의 목적지)

Global Minimum은 손실 함수가 가질 수 있는 전역 최소값을 의미한다. 손실 함수는 모델이 예측한 값과 실제 값의 차이를 수치로 표현한 것이며, 이 값이 작을수록 모델의 성능이 좋다고 볼 수 있다.

손실 함수의 값을 지형으로 비유하면, 다양한 언덕과 골짜기가 있는 복잡한 지형이 된다. 이때:

Local Minimum은 특정 영역에서 가장 낮은 지점이며
Global Minimum은 전체 지형에서 가장 낮은 지점이다.

딥러닝 모델의 학습 목표는 이론적으로는 Global Minimum에 도달하는 것이지만, 실제로는 파라미터 수가 매우 많고 지형이 복잡하기 때문에 Global Minimum을 정확히 찾는 것은 거의 불가능하다. 대신, 일반화 성능이 좋은 적절한 Local Minimum에 도달하는 것이 현실적인 목표가 된다.

(2) Learning Rate: 파라미터 업데이트 크기 (경사하강법의 한 걸음 크기)

Learning Rate는 한 번의 학습 단계에서 파라미터를 얼마나 크게 업데이트할지를 결정하는 하이퍼파라미터이다.

Learning Rate가 너무 크면 손실 함수의 최소점을 지나쳐 발산하거나 진동할 수 있고, 너무 작으면 학습 속도가 매우 느려지거나 최적점에 도달하지 못할 수 있다. 따라서 Learning Rate는 딥러닝 모델 학습에서 가장 중요한 하이퍼파라미터 중 하나로 간주된다.

(3) Optimizer: 파라미터를 어떻게 업데이트할 것인가 (경사하강법의 내려가는 방법)

Optimizer는 손실 함수에 대한 기울기(gradient)를 이용하여 파라미터를 어떤 방식으로 업데이트할지를 결정하는 알고리즘이다.

가장 기본적인 Optimizer는 Gradient Descent이며, 실제 딥러닝에서는 다음과 같은 알고리즘들이 널리 사용된다.

SGD (Stochastic Gradient Descent): 미니배치 단위로 파라미터를 업데이트하며, 노이즈를 통해 Local Minimum에서 탈출하는 데 도움이 된다.
Momentum: 이전 기울기 정보를 누적하여 진동을 줄이고 빠르게 수렴하도록 한다.
RMSProp: 파라미터별로 학습률을 조절하여 안정적인 학습을 돕는다.
Adam: Momentum과 RMSProp의 장점을 결합한 알고리즘으로, 현재 가장 많이 사용되는 기본 Optimizer로 간주된다.

Optimizer는 Learning Rate를 활용하여 파라미터 업데이트를 수행하며, 학습 속도와 안정성에 큰 영향을 미친다.

(4) 세 개념의 관계 정리

딥러닝 학습 과정에서 이 세 개념은 다음과 같은 흐름으로 연결된다.

손실 함수가 정의되고 Global Minimum이 이론적 목표가 된다.
Backpropagation을 통해 각 파라미터에 대한 gradient가 계산된다.
Optimizer가 Learning Rate를 사용하여 파라미터를 업데이트하고, 손실 함수의 최소값을 향해 이동한다.

즉, Global Minimum은 목표, Learning Rate는 이동 크기, Optimizer는 이동 전략이라고 볼 수 있다.

2. Hyper-parameter와 과적합 방지 기법

1) epoch

전체 DataSet의 neural network를 통해 한번 처리(학습)된 것으로 하나의 epoch는 한번에 처리하기 큰 사이즈 이므로 여러 개의 batch로 나누어 처리한다. 훈련을 위해서는 여러 번 epoch를 반복해야한다.

2) Dropout regularization

Dropout은 학습 과정에서 뉴런을 확률적으로 비활성화(drop)하는 정규화 기법으로, 특정 뉴런이나 feature에 대한 과도한 의존을 방지하여 과적합(overfitting)을 줄이기 위해 사용된다.

Dropout은 신경망을 랜덤한 서브네트워크들의 앙상블로 학습시키는 효과를 갖는다.

3. CNN(Convolutional neural network) - 합성곱 신경망

이미지처리에 특화된 딥러닝 네트워크이다.

CNN은 특별한 Layers를 가지고 있다.

1) Convolutionnal Lyaer(합성곱층)

- Image 정보의 공간적 지역 특성 보존

- Kernel(Filter)을 이용한 이미지 특성 추출 (filter란 스스로학습하는 parameter이다.) kenel은 경사하강법과 오차역전파로 나온 학습된 값이다.

출처 : https://wikidocs.net/64066

input(사진픽샐) -> image patch * kernel = ouput

여기서 나오는 output은 같은 값이 나온 거는 같은 패턴이라는 인식을 할 수 있다.

- padding : 합성곱층을 하면 할 수록 입력과 커널의 곱으로 출력층이 작아진다. 만약 중요한 정보가 있으면 유실이 날 수 있다. 이런 현상을 막기위해 주위에 x, y축에 의미 없는 0 값을 둘러주는 것이 padding이다.

합성곱층의 2가지 특성

1. Locality

- kernel size 만큼의 작은 구역(patch)의 인접한 pixel 들에 대한 correlation관계를 비선형 필터를 적용하여 추출한다 이러한 특성을 적용하여 필터를 여러개 적용하면다양한 local특징을 추출 가능하다.

image 전체가 아니라 filter area에만 연결

2. parameter sharing

- input 상의 모든 patch들이 동일한 kernel을 적용하여 next layer의 output을 출력한다. 이럴 경우 parameter의 수를 획기적으로 줄일 수 있다. 즉 동일한 커널(필터)을 이미지 전체에 반복 적용하는 매개변수 공유 덕분에, 각 연결마다 가중치를 갖는 밀집층보다 매개변수가 훨씬 적어 효율적입니다.

2) Pooling Layer(풀링층)

- Image data의 정보 손실 없는 압축 -> 계산량 및 메모리 사용량 축소, 파라미터의 수 감소(과적합 방지)

계산은 하지만 pooling의 뉴런은 가중치가없음. 오로지 사이즈만 줄이는게 목적으로 풀링 최대값을 갖고오는 풀링방법과 평균 값을 가져오는 평균값을 추출하는 연산이 있다. max풀링 방법이 정확도가 더 정확하다.

스트라이드가 커지면 이동 횟수가 줄어들어 결과 이미지의 크기가 더 작아집니다.

출처 : https://wikidocs.net/62306

3) CNN의 기초가 되는 LeNet-5

LeNet-5는 1998년Yann LeCun이 제안한 초기 CNN(Convolutional Neural Network) 모델로 주로 손글씨 숫자 인식(우편번호 인식 등)에 사용되었고, 현대 딥러닝 CNN의 시초라고 볼 수 있다.

Layer	타입	뉴런	커널	Stride	출력크기	파라미터	비고
Input	-	-	-	-	32×32×1	0	흑백 이미지
C1	Conv2d	6	5×5	1	28×28×6	156	Tanh
S2	max Pool	6	2×2	2	14×14×6	12	학습가능 scale, bias
C3	Conv2d	16	5×5	1	10×10×16	1,516	부분 연결
S4	max Pool	16	2×2	2	5×5×16	32	학습가능
C5	dense	120	5×5	1	1×1×120	48,120	Fully Connected Layer
F6	dense	84	-	-	84	10,164	Fully Connected Layer
Output	softmax	10	-	-	10	850	Softmax

출처 : https://d2l.ai/_images/lenet.svg

4) Transfer Learning (전이학습)

Transfer Learning(전이학습)은 이미 대규모 데이터로 사전 학습(pretrained) 된 모델의 가중치(weight)를 가져와
새로운 문제에 재사용하는 기법이다. 특히 CNN 기반 이미지 모델에서 매우 널리 사용된다.

CNN 구조는 크게 두 부분으로 나뉜다:
1) Convolutional Layers

특징(feature) 추출 역할, 일반적인 이미지 특징 학습, 재사용 가능

2) Fully Connected Layers
최종 분류 결정, 데이터셋에 특화된 부분, 보통 새로 학습해야 함

따라서 전이학습에서는 이렇게 구성한다
Pretrained Conv Layers → 그대로 사용
Custom Dense Layers → 새로 추가

전이학습 방식 2가지

1. Feature Extraction 방식

기존 Conv Layer를 freeze (동결) 시킴
가중치 업데이트 안 함
새로 추가한 Dense Layer만 학습

장점 : 학습 빠름, 작은 데이터셋에서 안정적

2. Fine-Tuning 방식

많은 데이터가 있을 때, 일부 Conv Layer도 함께 학습, 가중치 일부 업데이트

장점 : 더 높은 성능 가능, 새로운 도메인에 적응 가능

4. RNN(Recurrent Neural Network)

시퀀스 데이터(시계열 데이터)에 특화 되어있음.

기억 능력을 갖고 있다. 시퀀스데이터는 순서대로 무언가 들어오는 데이터를 기억하고 있다가 어떤 결과가 나오는지 표현해야 하기 때문(새로운 입력이 들어올 때 마다 네트워크는 자신의 기억을 조금씩 수정) 입력을 모두 처리하고 난 후 네트워크에게 남겨진 기억은 시퀀스 전체를 요약함

사용하는 곳

주가 예측
센서 데이터 분석
IoT 데이터
서버 트래픽 예측

Rnn을 순서대로 펼쳐 놓으면 weight를 공유하는 매우 deep한 neural network가 된다.

연결된 backpropagation 을 사용한다.(BPTT라고함)

output은 다중분류일 경우 softmax, 연속된 수일 경우 linear regression을 사용하지만 다중분류를 더 잘 맞춘다.

LSTN(Long Short Term Memory) 가장 많이 사용되는 RNN모델중 하나.

장기기억을 계속 유지하는 long term memory가 존재한다.

5. Autoencoder

오토인코더(Autoencoder)는 입력 데이터를 그대로 출력으로 복원하도록 학습하는 신경망이다. 겉으로 보기에는 단순히 “입력을 복사하는 모델”처럼 보일 수 있지만, 실제 목적은 복사가 아니다. 핵심은 데이터를 압축하는 과정에서 그 데이터의 본질적인 구조를 스스로 학습하도록 만드는 데 있다.

일반적인 신경망은 입력을 받아 정답 라벨을 예측한다. 예를 들어 이미지를 보고 숫자를 분류하거나, 값을 예측하는 식이다. 그러나 오토인코더는 정답 라벨이 필요하지 않다. 입력 자체가 곧 정답이 된다. 모델은 입력을 받아 내부적으로 압축한 뒤, 다시 원래 형태로 복원하도록 학습된다. 이 과정에서 입력과 출력의 차이를 최소화하는 방향으로 가중치를 조정한다.

오토인코더의 구조는 크게 세 부분으로 나뉜다. 첫 번째는 인코더(Encoder)이다. 인코더는 입력 데이터를 점점 작은 차원으로 줄여 나간다. 두 번째는 병목 구간(Bottleneck)이다. 이 부분은 차원이 가장 작으며, 입력 데이터의 핵심 정보만 담고 있는 잠재 표현(latent representation)이 된다. 세 번째는 디코더(Decoder)이다. 디코더는 압축된 정보를 다시 원래 차원으로 확장하여 입력과 유사한 데이터를 만들어낸다.

중요한 점은 병목 구간의 존재이다. 만약 중간 차원을 줄이지 않는다면 모델은 단순히 입력을 그대로 복사하는 방법을 배워버릴 수 있다. 하지만 차원을 강제로 줄이면, 모델은 제한된 공간 안에 데이터를 표현해야 한다. 이 과정에서 불필요한 정보나 노이즈는 제거되고, 데이터의 구조적 특징만 남게 된다. 즉, 오토인코더는 압축을 통해 중요한 패턴을 학습하게 된다.

예를 들어 손글씨 이미지 데이터가 있다고 하자. 각 이미지는 수백 개의 픽셀 값으로 이루어져 있지만, 실제로 숫자를 구분하는 데 중요한 정보는 선의 모양, 굵기, 위치와 같은 특징들이다. 오토인코더는 이러한 핵심 요소를 작은 차원의 벡터 안에 담아 표현하는 방법을 학습한다. 그리고 그 표현을 이용해 다시 이미지를 복원한다.

이러한 특성 때문에 오토인코더는 다양한 분야에서 활용된다. 대표적으로 차원 축소, 노이즈 제거, 이상 탐지 등에 사용된다. 정상 데이터만 학습시켜두면, 이상 데이터는 제대로 복원하지 못하므로 복원 오차가 크게 나타난다. 이를 이용해 이상 여부를 판단할 수 있다. 또한 인코더 부분만 따로 사용하면 데이터의 특징 추출기로 활용할 수도 있다.

결국 오토인코더는 단순한 복원 모델이 아니다. 입력 데이터를 압축하고 복원하는 과정을 통해 데이터가 가진 본질적인 구조를 이해하도록 학습하는 모델이다. 라벨 없이도 데이터의 특징을 스스로 학습할 수 있다는 점에서, 딥러닝에서 중요한 비지도 학습 기법 중 하나로 여겨진다.

오토인코더는 데이터의 구조를 학습하는 모델이다. (분류 모델 아님, 예측 모델 아님 라벨 필요 없음)

비지도 학습 (Unsupervised Learning)

오토인코더의 진짜 역할로는

차원 축소 : PCA보다 강력 (비선형 가능)
노이즈 제거 : Denoising Autoencoder
이상 탐지 : 정상 데이터만 학습 → 이상 데이터는 복원 못함 → 오차 큼
특징 추출 : Encoder 부분만 떼서 feature extractor로 사용

6. GAN(Generative adversarial network)

computer가 이미지, 인간의 목소리, 악기소리 등을 실제와 같이 생성한다.

위조를 담당하는 generator(생성자)와 위조를 판별하는 Discriminator(판별자)의 두개의 Deep Neural network으로 구성된다.

[AI] Apache Spark 개념정리

usingsystem — Mon, 15 Dec 2025 21:31:46 +0900

1. Apache Spark 개념 및 특징 정리

Apache Spark는 대규모 데이터 분석과 분산 처리를 위해 만들어진 오픈소스 프레임워크입니다.
빅데이터 환경에서 빠른 속도, 다양한 데이터 처리 기능, 그리고 확장성을 제공합니다.

특징

1. High Performance (고성능)

In-Memory 연산을 통해 기존 Hadoop MapReduce보다 훨씬 빠른 속도를 제공합니다.
- MapReduce는 디스크 기반으로 데이터를 저장하고 네트워크를 통해 데이터를 주고받는 과정이 많아 속도가 느립니다.
- Spark는 데이터를 메모리에 올려서 연산을 수행하고, 꼭 필요할 때만 디스크나 네트워크를 사용합니다.
덕분에 최대 100배 이상 빠른 성능을 보여주기도 합니다.
머신러닝용 라이브러리(MLlib), 그래프 연산 라이브러리(GraphX) 등을 지원하여 데이터 분석을 더 쉽고 효율적으로 진행할 수 있습니다.

2. Scalability (확장성)

Spark는 수평 확장(Scale-Out) 구조로 설계되어 있습니다.
동일하거나 유사한 사양의 서버(노드)를 여러 대 묶어 하나의 클러스터를 구성합니다.
이를 통해 페타바이트(PB)~제타바이트(ZB)급의 대규모 데이터도 처리할 수 있습니다.
Spark는 다양한 클러스터 매니저 위에서 동작할 수 있습니다:
- Apache Hadoop YARN
- Apache Mesos
- Kubernetes

3. Structured Data 지원

Spark는 정형 데이터뿐만 아니라 비정형(Unstructured) 데이터를 구조화(Structured)하여 분석할 수 있습니다.
SQL처럼 다루기 쉽게 만들어주는 Spark SQL을 제공하며, 다양한 소스(CSV, JSON, Parquet, Hive 등)에서 데이터를 가져올 수 있습니다.

4. Real-Time Data Processing (실시간 처리)

Spark Streaming 라이브러리를 사용하면 실시간 데이터 처리도 가능합니다.
- 실시간 로그 모니터링
- IoT 센서 데이터 분석
- 클릭 스트림(Clickstream) 분석

2. Spark 아키텍처

Spark 클러스터는 크게 마스터 노드(Master Node) 와 워커 노드(Worker Node) 로 구성됩니다.

Master Node
- 드라이버 프로그램(Driver Program)을 실행합니다. 마스터 노드는 스파크 컨텍스트와 드라이버 프로그램을 실행하며, 클러스터의 자원을 관리하고 작업 실행을 조율하는 역할을 합니다.
- SparkContext가 존재하며, 클러스터 매니저(YARN, Mesos 등)에게 작업(Job)을 전달합니다.
Worker Node
- 여러 개의 Executor가 실행됩니다.
- Executor는 실제 연산을 담당하며, 그 안에서 Task 단위로 나누어 실행합니다.
- 필요에 따라 캐시(Cache)를 활용하여 성능을 높입니다.

전체 작업 흐름:
1. 사용자가 Job을 제출 → SparkContext가 클러스터 매니저에게 전달
2. 클러스터 매니저가 워커 노드에 Job을 배분
3. 각 워커 노드에서 Executor가 Task 실행
4. 결과를 모아 사용자에게 반환

3. RDD (Resilient Distributed Dataset)

RDD는 대규모 데이터를 RAM에 올려서 클러스터 여러 노드에 분산 저장하고, 메모리 기반으로 빠르게 처리하며, 장애가 발생해도 연산 기록(lineage)을 이용해 복구할 수 있는 Spark의 기본이되는 핵심 데이터 단위입니다.

특징

Immutable(불변성)
- 한 번 생성된 RDD는 변경할 수 없습니다.
- 데이터를 수정하려면 새로운 RDD가 생성됩니다.
Fault-Tolerance(내결함성)
- 데이터가 손실되거나 손상(Corrupt)되면 자동으로 다른 노드에 있는 복제본(Replica)을 통해 복구합니다.
Parallel Processing(병렬 처리)
- 데이터는 클러스터의 여러 노드에 분산되어 저장·처리되므로 병렬 연산이 가능합니다.
Lazy Evaluation(지연 연산)
- 지연 연산은 변환 작업을 즉시 실행하지 않고 기록해 두었다가, collect(), save() 같은 액션(Action)이 호출되기 전까지는 실제 연산이 수행되지 않습니다.
- 이를 통해 Spark는 최적화된 실행 계획을 세워 효율적으로 연산을 수행합니다.

#가상환경일 경우 패스등록
import os
import sys
os.environ["PYSPARK_PYTHON"] = sys.executable

# 예전 방식
import pyspark
sc = pyspark.SparkContext('local[*]') # Spark 실행 엔진을 로컬 CPU 코어로 켠 것, 메모리 생성

rdd = sc.parallelize(range(1000)) # 0~999까지 숫자를 메모리(RAM)에 분산 저장한 RDD 생성
rdd.takeSample(False, 5)

# 최신방식
from pyspark.sql import SparkSession

spark = SparkSession.builder.getOrCreate() # PySpark의 통합 엔진 DataFrame, SQL, Hive, RDD 작업 모두 여기서 시작
sc = spark.sparkContext # RDD 작업을 할 때 필요

rdd = sc.parallelize(range(1000))
rdd.takeSample(False, 5)

4. Key Value Pair 명령

`reduceByKey`는 동일 키의 값들을 합산과 같은 연산으로 하나로 줄이는 반면, `groupByKey`는 단순히 동일 키의 값들을 하나의 목록으로 묶습니다. `reduceByKey`가 보통 더 효율적일 수 있습니다.

`filter` 변환은 제공된 조건(predicate) 함수를 각 요소에 적용하여 결과가 참인 요소들만 포함하는 새로운 RDD를 반환합니다. 데이터 정제 등에 유용합니다.

`countByValue` 액션은 RDD의 모든 고유 요소와 해당 요소의 발생 횟수를 계산하여 (값, 개수) 쌍의 Dictionarry형태로 편리하게 반환해 줍니다. 워드 카운트 같은 작업에 적합해요.

`collect` 액션은 분산된 RDD의 모든 데이터를 드라이버 프로그램으로 수집하여 로컬 메모리에 파이썬 리스트 형태로 반환합니다. RDD 크기가 클 때는 주의해야 합니다.

import pyspark

sc = pyspark.SparkContext.getOrCreate()
# Key / Value RDD

# creating Key / Value RDD
total_by_brand = rdd.map(lambda brand: (brand, 1))

# # reduceByKey(): Merge the values for each key using an associative and commutative reduce function.
from operator import add
rdd = sc.parallelize([("a", 1), ("b", 1), ("a", 1)])
sorted(rdd.reduceByKey(add).collect())
[('a', 2), ('b', 1)]


# groupByKey(): Group the values for each key in the RDD into a single sequence. Hash-partitions the resulting RDD with numPartitions partitions.
rdd = sc.parallelize([("a", 1), ("b", 1), ("a", 1)])
sorted(rdd.groupByKey().mapValues(f=len).collect())
[('a', 2), ('b', 1)]
sorted(rdd.groupByKey().mapValues(list).collect())
[('a', [1, 1]), ('b', [1])]


# sortByKey(): Sorts this RDD, which is assumed to consist of (key, value) pairs.
tmp = [('a', 1), ('b', 2), ('1', 3), ('d', 4), ('2', 5)]
sc.parallelize(tmp).sortByKey().first()
('1', 3)


# keys(), values(): Create a RDD of keys or just values
rdd = sc.parallelize([("a", 1), ("b", 1), ("a", 1)])
rdd.keys()
['a', 'b', 'a']

# join, rightOuterJoin, leftOuterJoin, cogroup, subtractByKey
x = sc.parallelize([("a", 1), ("b", 4)])
y = sc.parallelize([("a", 2), ("a", 3)])
sorted(x.join(y).collect())
[('a', (1, 2)), ('a', (1, 3))]


# Efficiency is the key for performance!!!
# if you only need values, use mapValues() or flatMapValues()

`countByValue` 액션은 RDD의 모든 고유 요소와 해당 요소의 발생 횟수를 계산하여 (값, 개수) 쌍의 사전 형태로 편리하게 반환해 줍니다. 워드 카운트 같은 작업에 적합해요.

spark는 yeild와 궁합이 좋다.

flatMap은 각 원소가 여러 개의 결과를 만들 수 있도록 설계됨
함수에서 yield를 쓰면 이터레이터(iterator)를 반환
flatMap은 이 이터레이터를 받아 결과를 펼쳐(flatten) RDD에 넣음
장점: 메모리를 많이 쓰지 않고 대용량 데이터 처리 가능

def get_data(line, header):
    if line != header:
        col = line.split(',')
        city = col[6].strip("\"")
        avg_temp_fahr = col[4]
        yield (city, avg_temp_fahr)
		return [(city, avg_temp_fahr)]  # 이렇게도 가능하지만 느림
        
parsed_line = lines.flatMap(lambda line: get_data(line, header))

map vs flatMap

`flatMap`은 각 입력 항목에서 0개 이상의 여러 출력을 생성하고 그 결과를 단일 목록으로 평면화합니다. 반면 `map`은 항상 각 입력 항목에 대해 정확히 하나의 출력 항목만 생성한다.

map: 각 원소를 단순 변환할 때
- 예: 모든 숫자에 10 더하기, 문자열 소문자로 변환 등
flatMap: 각 원소를 여러 개로 나누거나 토큰화할 때
- 예: 문장 → 단어, CSV 행 → 여러 값 등

함수	입력 RDD 원소	출력 RDD 원소	특징
map	1개	1개	각 원소를 1:1로 변환
flatMap	1개	0개 이상	각 원소를 0~n개로 변환 후 평탄화(flatten)

rdd = sc.parallelize(["hello world", "hi spark"])

rdd_map = rdd.map(lambda x: x.split(" "))
print(rdd_map.collect())

출력 : [['hello', 'world'], ['hi', 'spark']]

rdd_flat = rdd.flatMap(lambda x: x.split(" "))
print(rdd_flat.collect())

출력 : ['hello', 'world', 'hi', 'spark']

5. 데이타프레임(Dataframe)과 SparkSQL

Spark를 제대로 쓰려면 RDD → DataFrame → SparkSQL 흐름을 이해해야 합니다.

1) 데이터프레임(DataFrame) 이란?

Spark의 DataFrame은 RDD(기본 데이터 구조)위에서 동작하는 더 고수준의 구조화된 데이터 모델로 더 빠르고 구조적 이다. 형태는 Pandas DataFrame과 비슷하지만 엄청 큰 데이터(수십 GB~TB)를 클러스터에서 병렬 처리할 수 있다는 점이 다릅니다.

DataFrame의 특징

(1) 스키마(Schema)를 가진다 ( structure)

name	age	city
Bob	20	Seoul

RDD는 구조를 모르지만, DataFrame은 구조를 알기 때문에 Spark가 최적화할 수 있음.

(2) Catalyst 옵티마이저로 자동 최적화됨(카탈리스트 최적화 도구)

Spark SQL 엔진이 DataFrame 연산을 분석해서 가장 빠른 방식으로 실행 계획을 자동으로 만들어줌.

쓸데없는 연산 제거
병렬 실행 최적화
디스크/메모리 접근 최소화

→ RDD보다 훨씬 빠르다

(3) SQL처럼 다룰 수 있다

DataFrame은 SQL 테이블처럼 사용할 수 있어서 df.select("name", "age").where(df.age > 20) 이런 식으로 직관적인 표 형태의 연산이 가능.

2) Spark SQL 이란?

DataFrame을 SQL 문법으로 처리할 수 있게 해주는 인터페이로 Spark SQL 엔진이 돌아가면서 DataFrame과 SQL 사이를 연결해줌.

(1) SQL 문법 그대로 사용 가능

데이터를 분석하는 사람들이 SQL을 잘 알기 때문에 복잡한 분석을 바로 SQL로 작성 가능.

(2) 표현력이 쉬움

코드로 하면 길어지는 작업도 SQL 한 줄이면 끝.

(3) 자동 최적화

SQL도 Catalyst 엔진이 알아서 최적화해줌.

DataFrame ↔ SparkSQL 예시( SparkSession)

from pyspark.sql import SparkSession

# SparkContext + SQL + Hive + DataFrame + Catalog 모두 포함한 통합 엔트리포인트
spark = SparkSession.builder.appName("SparkSQL").getOrCreate()  

# DataFrame 생성
lines = spark.sparkContext.textFile("file:///")
#data = spark.read.option("header", "true")\ csv 읽을 때 사용
            .option("inferSchema", "true")\ 데이터를 추론해서 타입맞춰줌
            .csv(csv_file_path)
#data.printSchema()

file_data = lines.map(parse_line)

# SQL로 사용하기 위해 등록
schema_income = spark.createDataFrame(data=file_data).cache()# ram 메모리에 프레임생성고 ㅏ올림
schema_income.createOrReplaceTempView("file_data")# sql을 사용하기 위해 테이블이름 등록

# SQL 사용 가능
result = spark.sql("""
    SELECT city, AVG(temperature)
    FROM table
    GROUP BY city
""")

result.show()

RDD vs DataFrame vs SparkSQL 차이 (정리)

방식	특징	장점	단전
RDD	구조 없는 분산 데이터	유연함	느림, 최적화 X
DataFrame	스키마 + 구조화된 데이터	Catalyst 최적화로 빠름	복잡한 로직은 제한적
SparkSQL	SQL 문법으로 DataFrame 조작	SQL만 알면 분석 가능	SQL에 익숙해야 함

6. Dataframe StructType

dataframe structType이란 만약 csv파일을 읽었을 경우 헤더가 있다면 inferSchema=True를 해서 사용하면 될 것 이다. 하지만 헤더가 없을 경우엔 StructType을 사용해 직접 헤더를 만들 수 있다.

헤더가 있다면

DataFrame의 컬럼 구조를 직접 정의할 때 사용하는 타입
각 컬럼은 StructField로 구성됨
컬럼의 이름, 데이터 타입, NULL 허용 여부 등을 설정할 수 있음

즉, "이 DataFrame은 어떤 컬럼을 어떤 타입으로 가지고 있다" 를 정의하는 것.

# 헤더가 없는 csv일경우 직접 structType 구현
table_schema = t.StructType([
    t.StructField("xxx1", t.StringType(), True),
    t.StructField("xxx2", t.FloatType(), True),
    t.StructField("xxx3", t.StringType(), True)])

csv_file_path = "file:/data.csv"
df = spark.read.schema(table_schema).csv(csv_file_path)

df.printSchema()

# 헤더 있는 csv는 inferSchema true로 사용
data = spark.read.option("header", "true")\ csv 읽을 때 사용
            .option("inferSchema", "true")\ 데이터를 추론해서 타입맞춰줌
            .csv(csv_file_path)
            
data.printSchema()

7. BrodCast와 BroadCast 조인

BrodCast란 모든 워커(worker)에게 동일한 데이터를 네트워크 오버헤드 없이 빠르게 전달하기 위한 캐시 메커니즘으로 Spark에서 작은 DataFrame을 클러스터 전체의 모든 Executor 메모리에 복사해서 배포하는 기능.

Spark는 액션을 실행할 때 워커 노드들이 데이터를 받을 때 네트워크를 통해 계속 전송해야 할 수 있음.

하지만 broadcast 변수를 쓰면 드라이버(driver)가 데이터를 한 번만 보냄 -> 워커들이 로컬 메모리에 저장한 뒤 -> 모든 task에서 재사용 즉, 네트워크 비용 대폭 절감, 속도 엄청 빨라짐

BroadCast 조인이란 작은 테이블을 전체 워커 노드에 브로드캐스트하여, 큰 테이블과 조인을 빠르게 수행하는 방식으로 일반 조인은 큰 테이블끼리 shuffle(데이터 섞기로 데이터를 다른 파티션으로 재배치하는 과정 )을 해서 노드 사이에 엄청난 네트워크 비용이 발생함. 하지만 작은 테이블을 broadcast하면

작은 테이블은 모든 노드에 미리 복제됨
큰 테이블은 shuffle 없이 "로컬"에서 바로 매칭
네트워크 비용 거의 없음

즉, 대규모 데이터 조인을 매우 빠르게 처리하는 최적화

Spark는 기본적으로 작은 테이블이면 자동으로 broadcast한다. 작은 테이블만 broadcast해야 한다. Python UDF 내부에서 broadcast.value를 사용하면 워커가 Python 프로세스를 두 번 넘나들기 때문에 조금 느릴 수 있음.

meta = {"A": 1, "B": 2}

occupation_dict = spark.sparkContext.broadcast(meta)

def get_name(occupation_id: str) -> str:
    return occupation_dict.value[occupation_id]

occupation_lookup_udf = f.udf(get_occupation_name) # 함수를 넣을 수 있게

occupation_with_name = interviewer_count.withColumn("occupation_name", occupation_lookup_udf(f.col("occupation_id")))

occupation_with_name.show(10)

broadcast_meta.value → 실제로 담겨 있는 데이터
워커에서 접근해도 네트워크로 다시 전송되지 않음

8. coalesce와 repartition

1) coalesce

coalesce는 빠르게 파티션 수를 줄이는 최적화 함수로 파티션을 줄일 때 사용한다. 즉 기존 파티션 (데이터를 여러 조각으로 나눠서 여러 워커 노드가 병렬로 처리할 수 있게 만든 단위)중 일부를 병합하는 방식이다.

shuffle(데이터를 다른 파티션으로 재배치하는 과정)이 발생하지 않아 매우 빠르다.

df.coalesce(1)

2) repartition

repartition는 반대로 파티션을 늘리는 용도로 사용하지만 shuffle 발생한다.

repartitionByRange는 특정 키값으로 파티션을 늘리는걸로 repartition, coalesce와 다르게 DataFrame에서만 가능

df.repartition(10)#repartition
df.repartition(200, "city", "job") #repartitionByRange

1) 작업 병렬성을 늘리고 싶을 때 (파티션 ↑)

처음 로딩된 데이터가 파티션이 너무 적으면 CPU 코어가 놀게 됨
→ repartition(n)을 통해 병렬 처리 향상

2) 조인/집계 성능 향상을 위해 파티션을 균등하게 맞추고 싶을 때

데이터 스큐( 데이터가 균등하게 분배되지 않아 특정 Task가 병목이 되는 문제. )가 있을 때 사용
예) 특정 키만 몰려 있을 때 명시적으로 repartition("key")

3) 대규모 저장(write) 작업 전에 필요한 파티션 개수 맞추기

파일 출력을 1개의 파일로 만들고 싶을 때 → coalesce(1)
HDFS에 적당한 파일 개수로 저장하고 싶을 때 → repartition(200)

함수	파티션	셔플	테이터 재분배 방식	사용 목적
repartition(n)	증가	발생	해시 기반 균등 재배치	병렬성 확보, 조인/집계 정확한 분배
repartitionByRange(n, cols)	증가	발생	Range 정렬 기반 파티션 분배	정렬 기반 작업 전 최적화, 스키마 정렬
coalesce(n)	줄임	없음	기존 파티션 일부만 합침	빠른 파티션 감소, 최소 비용

9. 빈 데이터와 시간 포멧 다루는 방법

na.drop 키워드

how : any - 데이터가 하나라도 비어있으면 삭제, all - row에 모든 데이터가 비어있으면 삭제
threash : 하나의 row에 데이터 빈칸의 숫자를 지정해 지정한 숫자만큼 비어있으면 삭제
subset : 특정 컬럼을 지정해 해당 컬럼이 비어있으면 삭제

df.na.drop(how="any").show() 
df.na.drop(thresh=2).show()
df.na.drop(subset=["salary"]).show()

na.fill 키워드

null인 데이터를 채우기위해

# # fill string
df.na.fill("engineer").show()

# # fill integer
df.na.fill(0).show()

# # fill the subset
df.na.fill("NA", subset=["occupation"]).show()

# # fill the mean value
mean_value = df.select(f.mean(df['salary'])).collect()
df.na.fill(mean_value[0][0], subset=["salary"]).show()

date

# # show year
df.select(f.year('date')).show()

# # show month
df.select(f.month('date')).show()

# # show day
df.select(f.dayofmonth('date').alias('day')).show()
df.select(f.dayofyear('date').alias('day')).show()

10. YARN (Yet Another Resource Negotiator) 이란?

하둡의 클러스터 자원을 관리하고, 애플리케이션 실행을 스케줄링해주는 시스템

누가 CPU를 얼마나 쓰는지
메모리를 얼마만큼 배분할지
어떤 노드에서 작업을 실행할지

모두 YARN이 관리한다.

11. Dataframe의 API 카테고리

1) Transformations

스파크 특성상 데이터를 수정할 수 없다. 이 때 Transformations는 RDD/DataFrame을 입력 → 새로운 RDD/DataFrame을 만드는 작업으로 즉시 실행되지 않고, DAG(작업 계획)에만 기록되며 Action을 만나면 실행된다.

DAG는 만들어두면 Spark가 뒤에서 최적화(scheduler)

Transformation	설명	Dependency	이유
map	각 요소를 1:1로 변환	Narrow	파티션 내에서만 처리됨
flatMap	요소 하나 → 여러 요소	Narrow	파티션 내에서만 처리됨
filter	조건에 맞는 요소만 통과	Narrow	파티션 내부만 사용
mapPartitions	파티션 단위 변환	Narrow	부모 파티션 1개에만 의존
sample	샘플링	Narrow	shuffle 없음
coalesce(n, shuffle = false)	파티션 수 줄임	Narrow	데이터 이동 거의 없음
union	두 RDD 합침	Narrow	shuffle 없음 (그냥 두 파티션 나열)

Transformation	설명	Dependency	이유
distinct	중복 제거	Wide	같은 값을 모으기 위해 전체 파티션 재배치(shuffle) 필요
repartition(n)	파티션 수 재조정	Wide	모든 데이터를 섞어서 파티션 재분배
sortBy / orderBy	전체 정렬	Wide	global ordering 위해 shuffle
groupByKey	key 기준 그룹화	Wide	모든 동일 key를 한 파티션으로 모아야 함
reduceByKey	key 기준 reduce	Wide	shuffle 발생하지만 groupByKey보다 효율적
join	RDD/DataFrame join	Wide	key 기준 서로 섞어야 함
cogroup	여러 RDD key-group	Wide	shuffle
distinct	중복 제거	Wide	같은 데이터를 모아야 하기 때문에 shuffle

(1) Narrow Dependency(좁은 의존성) 과 Wide Dependency(넓은 의존성)

Dependency란 RDD/DataFrame Transformation이 이전 Transformation의 어떤 파티션에 의존하는지를 나타내는 개념.

Narrow Dependency는 자식 RDD의 하나의 파티션이 부모 RDD의 소수(일반적으로 하나)의 파티션만 참조하는 경우로 파티션 이동이 없고 네트워크 통신이 없다. 즉 Executor가 자기 파티션만 보면되고 Shuffle이 없어 빠르다.

Wide Dependency는 자식 RDD의 하나의 파티션이 부모 RDD의 여러 파티션에 의존하는 경우로 여러 부모 파티션에서 데이터를 가져와야하고 네트워크 shuffle이 발생해서 비용이 큰 작업이므로 느리다.

textFile → flatMap → map → reduceByKey → sortByKey

flatMap		Narrow	한 파티션이 그대로 변환
map		Narrow	동일
reduceByKey	Wide	같은 key를 하나로 모아야 함 (shuffle)
sortByKey	Wide	전 파티션에서 key 정보를 모아야 함

2) Actions

Transformations로 정의한 DAG를 실제로 실행시키는 명령으로 즉, 결과를 반환하거나 저장할 때 실행된다.

Spark의 모든 동작은 Transformation으로 DAG를 만들고 Action에서 한 번에 실행된다.

Action	설명
collect()	전체 데이터를 드라이버로 가져옴
show()	DataFrame 출력
take(n)	n개만 가져오기
count()	개수 세기
first()	첫 요소
reduce()	모든 요소를 하나로 합침
saveAsTextFile()	파일로 저장
foreach()	각 요소에 대해 함수 실행

rdd = sc.textFile("file.txt")

# Transformation: DAG에만 기록됨
words = rdd.flatMap(lambda line: line.split(" "))
pairs = words.map(lambda w: (w, 1))
counts = pairs.reduceByKey(lambda a, b: a + b)

# Action: 실제 실행
print(counts.collect())

액션	메모리	사용 위치 설명
collect()	드라이버 메모리	모든 데이터를 드라이버로 가져옴 → 위험
count(), reduce(), show()	Executor 메모리	계산은 Executor 메모리에서 수행 후 결과만 드라이버로

12. Logical Plan (논리적 실행 계획)과 Physical Plan (물리적 실행 계획)

Catalyst Optimizer가 SQL/DataFrame 연산을 처리할 때 거치는 핵심 개념으로 왜 Spark가 자동 최적화되고, 어떻게 실행 계획이 만들어지는지 이해할 수 있어 튜닝을 할 때 필요하다.

1) Logicl Plan

사용자가 작성한 쿼리/코드가 무엇을 해야 하는지를 표현한 “논리적” 계획으로 아직 실행 방식(executor, shuffle)은 고려하지 않는다. 즉, 사용자 쿼리를 더 빠르게 실행할 수 있도록 논리 최적화를 수행한 상태이다. Spark는 아래와 같이 Logical Plan을 3단계로 구분한다.

① Unresolved Logical Plan (미해결 계획)

테이블/컬럼이 존재하는지 아직 모름
단지 문자열 기반으로 "filter", "select"만 적혀 있음

② Resolved Logical Plan (해결됨)

컬럼이 실제 존재하는지 검증 완료
스키마 분석 끝
함수(DataFrame API)도 실체로 매핑됨

③ Catalyst Optimized Logical Plan (최적화됨)

predicate pushdown (필터 아래로 내리기)
projection pruning (필요 없는 컬럼 제거)
constant folding (상수는 미리 계산)
join reordering (join 순서 최적화)
filter merge (필터 병합)

2) Physical Plan

Logical Plan을 실제 실행하는 방법으로 바꾼 것 으로 실제 Spark 클러스터에서 어떻게 연산할지, 어떤 방식으로 수행할지를 포함한다.

Spark는 여러 개의 physical plan을 생성한 뒤그중 가장 비용(cost)이 낮은 것을 선택함.

HashAggregate vs SortAggregate
ShuffleHashJoin vs BroadcastHashJoin
Whole Stage Codegen 적용 여부
Exchange(Shuffle) 전략

df.explain()		# Physical Plan 요약
df.explain(True)	# Parsed / Analyzed / Optimized Logical Plan + Physical Plan (전체)
df.explain("formatted")	# 사람이 읽기 편한 트리 형태의 출력
df.explain("cost")	# Cost-based optimizer 비용 정보 포함 (Spark 3+)

13. Spark Memory Allocation

Spark Job을 동작시키는데 포퍼먼스에 중요한 부분을 담당하고 있다. DriverMemory와 ExecutorMemory로 구성되어 있다.

1) Executor Memory

(1) Execution Memory(Handle Computations)

Shuffle, Join, Sort, Aggregate 같은 연산의 중간 결과를 저장하는 공간. 즉 계산용 메모리로 실시간 연산을 위한 메모리 이다.

부족할 경우 성능 저하일어 날 수 있음. Storage memory보다 우선권 있으며 storage가 점유한 메모리를 빌려올 수 있다.

캐싱(Storage Memory)
연산(Execution Memory)
Shuffle 작업
RDD/DataFrame 저장

(2) Storage Memory(Caching)

RDD/DataFrame Cache 메모리 (사용자가 df.cache() 또는 RDD .persist() 했을 때 저장) 즉 캐시된 데이터를 보관하는 공간

(3) User Memory

UDF / 사용자 코드 객체 저장

2) Driver Memory

Spark의 두뇌(플랜 생성/스케줄링/collect 데이터 수신)와 같은 역할을 수행한다.

SparkSession / SparkContext 유지
Logical Plan / Physical Plan 생성
Job / Stage / Task 스케줄링
collect(), show() 시 데이터가 Driver로 모임
메타데이터 관리 (catelog정보, broadcast 변수관리, shuffle파일 위치 정보)

+------------------------------------------------------------+     +-----------------------------------------------------------+
|                        Driver Memory                       |     |                      Executor Memory                      |
|                   (spark.driver.memory)                    |     |                   (spark.executor.memory)                  |
|                                                            |     |                                                           |
|  +------------------------------------------------------+  |     |  +--------------------+   +-----------------------------+ |
|  |  SparkSession / SparkContext                         |  |     |  | Execution Memory    |   | Storage Memory            | |
|  |  Logical Plan / Physical Plan 생성                   |  |     |  | (연산 중간 결과)     |   | (캐시/RDD/Persist)        | |
|  |  DAG 스케줄링(Job / Stage / Task)                   |  |     |  +--------------------+   +-----------------------------+ |
|  |  collect/show 결과 저장                              |  |     |                                                           |
|  |  메타데이터 관리                                      |  |     |   +-----------------------------+                        |
|  |                                                      |  |     |   |        User Memory          |                        |
|  +------------------------------------------------------+  |     |   |   (UDF 객체, 기타 JVM 객체) |                        |
|                                                            |     |   +-----------------------------+                        |
+------------------------------------------------------------+     +-----------------------------------------------------------+
                                                                   |    Memory Overhead (Off-Heap)                           |
                                                                   |    (DirectBuffer, PySpark Worker, Tungsten)              |
                                                                   |    spark.executor.memoryOverhead                         |
                                                                   +-----------------------------------------------------------+

14. AQE(Adaptive Query Execution)

Spark SQL이 실행 도중에 실제 런타임 통계를 보고 쿼리 플랜을 자동으로 최적화하는 기능으로 즉, 쿼리 실행 전에 만든 플랜을 그대로 따르는 게 아니라, 실행 중에 더 좋은 플랜을 찾아서 바꿔버리는 것이다.

Spark은 원래 쿼리 실행 전에 Logical Plan → Physical Plan 을 만든 후, 그 Physical Plan을 그대로 실행했음. 하지만 조인 전략이 잘못 선택이 된다거나 파티션이 너무 작거나 너무 클 수 있다. 이런 경우 초기 플랜이 비효율적이 되어 성능이 팍 떨어지게 된다. 이 때 AQE는 실행 도중에 ”어? 이 파티션 너무 큰데?” “이 조인 작은데 브로드캐스트 가능한데?” 하고 감지함 → 즉시 플랜 수정한다.

AQE는 Physical Plan 단계에서 발생하는 실행 중 최적화하기 때문에 Logical Plan이 아닌 Physical Plan이다.
즉, 실행 중에 Physical Plan을 재작성함(Re-Optimize)

AQE가 하는 핵심 최적화 3가지

1)동적 조인 전략 변경 (Dynamic Join Rewriting)

실행 중에 조인 대상 데이터 크기를 보고 Broadcast Join이 가능하면 자동으로 변경함

가장 큰 효과. 특히 sort-merge join같은 경우 엄청난 비요이듬. 이런걸 자동으로 Broadcast join으로 변경

2) 파티션 자동 병합 / 분할 (Coalescing Shuffle Partitions)

AQE는 실제 셔플된 파티션 크기를 보고 자동으로 너무 작은 파티션들 → 합치고 너무 큰 파티션 → 쪼갬

즉, 파티션 크기를 균일하게 맞춰줌.

3) 데이터 스큐 처리 (Skew Join Optimization)

특정 키에 너무 많은 데이터가 몰린 스큐( 데이터가 균등하게 분배되지 않아 특정 Task가 병목이 되는 문제. )상황을 AQE가 감지해서 스큐 키만 작은 청크로 나눠 처리, 나머지는 정상 처리 조인 스캔이 막혀서 느려지는 것을 방지함.

# spark3.x 대는 자동으로 켜져있음
spark.conf.set("spark.sql.adaptive.enabled", "true")

15. DPP (Dynamic Partition Pruning)

실행 중에 불필요한 파티션을 자동으로 건너뛰도록(Skip) 하는 Spark SQL 최적화 기능이다. 즉, 필요한 파티션만 읽고, 나머지는 읽지도 않는 런타임 파티션 필터링 기능

DPP는 파티션 키 필터가 쿼리 실행 시점에 결정될 때 유용하다. 필요한 파티션만 읽어 I/O와 네트워크 부하를 줄여 성능을 높인다.

16. Spark Cache(재사용)

Spark의 Cache는 자주 사용되는 DataFrame이나 RDD를 메모리(또는 디스크)에 저장해서 나중에 동일한 데이터를 다시 사용할 때 빠르게 읽어오는 기능이다. 즉 비싼 연산(Shuffle, Scan, Join 등)을 매번 다시 계산하지 않고 결과를 저장해두는 메모리 최적화 기능

캐싱은 중간 계산 결과를 메모리에 저장하여 재사용하고 불필요한 재계산이나 I/O를 줄여 성능을 높여요. 데이터 분배는 Repartition, 느린 태스크 복제는 Speculative Execution, 변수 공유는 Accumulator에 해당한다.

Cache는 메모리를 사용하므로 사용이 끝나면 꼭 해제해야 함.

Cache 꼭 써야 하는 경우

동일한 DataFrame을 여러 번 사용할 때
복잡한 ETL 파이프라인에서 중간 결과를 재활용할 때
반복 계산(ML 알고리즘, iterative jobs)
Shuffle 이후 결과를 여러 Action에서 재사용할 때

사용하면 안 되는 경우

DataFrame이 너무 커서 메모리에 못 들어갈 때
한 번만 사용하는 데이터
IO가 비싸지 않은 작은 데이터
필터로 작은 Subset만 쓸 때 (필요한 부분만 캐시하는 게 더 효율적)

df.cache()
df.count()   # Action → 캐시가 실제로 저장되는 시점

df.unpersist() # 해제

Level	설명
MEMORY_ONLY	기본 Cache. 메모리에만 저장, 부족하면 재계산
MEMORY_AND_DISK	메모리 부족하면 디스크에도 저장
MEMORY_ONLY_SER	메모리를 더 절약하기 위해 Serialized 형태
DISK_ONLY	디스크에만 저장 (I/O 느림)

17. sql hint(강제 주입)

SQL 쿼리 안에 힌트를 넣어서 조인 전략, 파티션 방식, Broadcast 여부, Shuffle 동작 등을 강제로 제어할 수 있음.

리소스등을 더 잘 활용가능함.

SQL Hint는 사용자가 쿼리 옵티마이저에게 물리적 실행 계획(예: 조인 전략, 파티션 수)에 대한 힌트를 제공하여 성능을 개선하는 방법으로 결과 데이터 변경과는 무관하다.

/*+ BROADCAST(dim) */ 이런식으로 사용함.

자주사용하는 hint

BROADCAST(dim) — 작은 테이블 broadcast
REPARTITION(200) — write 전 파티션 조정
REPARTITION(50, user_id) — 조인/집계 최적화
MERGE 또는 SHUFFLE_HASH — 조인 전략 강제

힌트 종류

hint	설명
BROADCAST / MAPJOIN	작은 테이블을 Broadcast Join으로 강제
MERGE / SHUFFLE_HASH / SHUFFLE_REPLICATE_NL	조인 전략 직접 지정
COALESCE / REPARTITION / REPARTITION_BY_RANGE	실행 시 파티션 수 조절
JOIN HINTS	build side 선택 등 고급 제어

예시

SELECT /*+ BROADCAST(dim) */
       f.user_id, dim.level
FROM fact f
JOIN dim ON f.id = dim.id;

df.hint("broadcast")
df.hint("repartition", 200)
df.hint("repartition_by_range", 50, "age")

18. Accumulator(디버깅)

Spark에서 작업(Task)들이 실행되면서 발생하는 값을 안전하게 누적하기 위해 만든 변수로 디버깅 할때 활용 하면 좋다.

즉 분산 Task들이 생성하는 로그성 통계 모으기에 유용함 ( 예) 에러 로우가 몇 개였는지 count, null 데이터 개수, 필터링된 행 개수

, 어떤 조건에 맞지 않는 값 누적 )

from pyspark.sql import SparkSession

spark = SparkSession.builder.getOrCreate()
sc = spark.sparkContext

# accumulator 생성
acc = sc.accumulator(0)

rdd = sc.parallelize([1, 2, 3, 4, 5])

def process(x):
    if x % 2 == 0:
        acc.add(1)
    return x

rdd.map(process).collect()

print("짝수 개수:", acc.value)

19. Speculative execution

Speculative Execution(추측 실행)은 Spark에서 느리게 실행되는(Task straggler) 작업을 빠르게 하기 위해 뒤에서 같은 Task를 하나 더 실행시키는 최적화 기능이다.

Spark는 클러스터 전체에서 많은 Executor·노드에 작업을 분배함.
그중 하나가…

머신 성능 저하
GC 과다
네트워크 문제가 있는 노드
디스크 I/O 병목
데이터 스큐(skew)
하드웨어 이상

…등의 이유로 특정 Task가 유독 느리게 실행될 수 있음.

그 한 개의 느린 Task 때문에 전체 Stage가 대기 → 결국 전체 Job 전체가 느려짐.

이걸 해결하려고 같은 Task를 하나 더 실행해서 누가 먼저 끝나나 경쟁시키는 게 Speculative Execution.

spark.speculation=true # 설정 옆에꺼 써도됨 spark.conf.set("spark.speculation",true)

#성능 옵션
spark.speculation.quantile=0.75   # 하위 25%가 느리면 speculative 실행
spark.speculation.multiplier=1.5  # 평균보다 1.5배 느리면 대상
spark.speculation.interval=100ms  # 검사 간격

20. Job Scheduling

드라이버(Driver)가 여러 Job을 어떤 순서로, 어떤 리소스로, 어떻게 실행할지 관리하는 메커니즘이다.

Spark Job Scheduling은 여러 Job을 FIFO 또는 FAIR 방식으로 Executor 리소스를 나눠 실행하는 방식이며, TaskScheduler가 Executor에 Task를 배정해 전체 실행 흐름을 관리하는 시스템이다.

Job Scheduling 핵심 구조

Spark 드라이버 내부에서 스케줄링은 다음 구성 요소가 참여해:

Job - 하나의 Action(count(), collect(), save 등)이 실행될 때 생성됨.
Stage - Job은 Shuffle 경계를 기준으로 여러 Stage로 나뉨.
Task - Stage는 여러 Task로 분리되어 Executor에서 병렬로 실행됨.

1) FIFO(First-In First-Out) — 기본 스케줄러

Spark 기본 모드

먼저 제출된 Job이 먼저 실행됨
후순위 Job은 앞 Job이 끝날 때까지 기다림
(단, Executor가 남아 있으면 병렬 수행 가능)

장점: 단순, 예측 가능
단점: 긴 작업이 있으면 뒤 Job이 오래 기다림

2) FAIR Scheduler — 공정 스케줄링 (협업 환경에서 많이 씀)

여러 사용자가 동시에 Job 실행할 때 사용됨.

Job들끼리 Pool(리소스 그룹)로 나누고
각 Pool에 weight 또는 minShare 값을 설정
여러 Job을 동시에 공정하게 병렬 실행

개발자 A job 3개, 개발자 B job 1개 실행
→ Pool weight에 따라 CPU/Executor를 나눠서 공정하게 실행됨

#spark-defaults.conf
spark.scheduler.mode=FAIR

21. Spark Streming

Spark Streaming은 Apache Spark에서 실시간(스트리밍) 데이터 처리를 위한 기능으로 요즘은 주로 Spark Structured Streaming을 의미한다고 보면 된다.

DataFrame / Dataset 기반
SQL, Catalyst Optimizer, AQE 등 Spark SQL 생태계 그대로 사용
Structured Streaming은 무한히 들어오는 데이터를 마치 배치 DataFrame처럼 처리하는 엔진

장애 발생 시

Executor 장애 - Task 재실행, state 복구

Driver 장애 - checkpoint 기반 query 재시작, offset / state 복원

from pyspark.sql.functions import window

df = spark.readStream \
    .format("json") \
    .schema("eventTime TIMESTAMP, userId STRING") \
    .load("/logs/events")

result = df \
    .withWatermark("eventTime", "10 minutes") \
    .groupBy(
        window("eventTime", "10 minutes"),
        "userId"
    ) \
    .count()

query = result.writeStream \
    .outputMode("append") \
    .format("console") \
    .start()

query.awaitTermination()

1) ouputmode

append mode는 결과가 더 이상 바뀌지 않는 시점이 명확할 때 새로들어온 데이터만.(데이터 중복 x)

update mode는 실시간 집계 중간 결과가 필요할 때 사용한다.(현재까지 집계 상황을 보고 싶을 때)

complete는 테스트나 디버깅 용도로 전체 상태를 한눈에 보고 싶을 때 사용한다.(직관적이지만 리소스 비용이 비쌈)

mode	설명
append	확정된 결과만 새로 추가
update	변경된 결과만 갱신
complete	전체 결과를 매번 다시 출력

2) Window & Watermark

Trigger → 언제 실행할지 (시간 / 조건)
Window → 어떻게 묶을지 (시간 구간)
Watermark → 언제 버릴지 (지연 허용 기준)

Window는 시간 구간으로 데이터를 묶어서 집계하는 방법 ex) 10분 단위로 잘라서 집계

window를 사용할 때 지연이 되면 지연된 데이터 상태를 계속 들고 있어야 해서 oom이 뜰 확률이 높음

window의 종류는 tumbling와 sliding 두개가 존재한다.

tumbing은 시간이 겹치지않고 sliding은 overlab시간을 부여한다. 즉 Tumbling Window는 시간을 중복되지 않는, 고정된 크기의 윈도우로 나누고 Sliding Window는 중복이 발생하는 윈도우 방식이다.

from pyspark.sql.functions import window

window_duration = "10 minutes" # tumbing 의미
sliding_duration = "5 minutes" # sliding 의미

df.groupBy(
    window(df.eventTime, window_duration, sliding_duration)
).count()

Watermark는 Structured Streaming 전용으로 이 시간보다 늦게 오는 데이터는 안 받겠다 는 선언

df.withWatermark("eventTime", "10 minutes")

window와 wtermark를 함께 쓰면 메모리 관리에 용의 함. “Watermark 없는 stateful streaming은 위험하다”

Window 상태를 유지
watermark 시점 지나면
- 결과 확정
- state 정리 (GC)

df \
  .withWatermark("eventTime", "10 minutes") \
  .groupBy(
      window("eventTime", "10 minutes")
  ).count()

3) Streaming Fault Tolerance란?

스트리밍 처리 중 장애가 발생해도, 데이터 유실·중복 없이 계속 처리하도록 보장하는 메커니즘Spark Structured Streaming은 장애를 전제로 설계돼 있다. 각 micro-batch를 완전히 처리했을 때만 커밋 , 체크포인트 등 저장해서 재시작 확인 가능

체크포인트는 내결함성의 핵심 목표는 시스템 장애 발생 시 데이터 레코드를 누락하거나 중복 없이 정확히 한 번만 처리하는 End-to-End Exactly Once Semantic을 보장하는 것이다.

4) Stateless와 stateful

서버에서 stateless와 stateful은 session이 유지되냐 안되냐의 뜻 으로 통한다. ex) stateless = rest api, stateful = socket

spark에서의 statelsess와 stateful은 연산이 이전 배치(또는 이전 레코드)의 결과를 기억하느냐 기준으로 나뉜다.

먼저 statelsess는 이전 데이터에 대한 상태를 저장하지 않고 각 배치 / 마이크로배치를 독립적으로 처리한다.

상태 저장 없음
재시작 시 부담 적음
성능, 확장성 좋음
Checkpoint 불필요

select, filter, map, flatMap, expolde, append, update ...

df.select("col")
df.filter($"age" > 30)
df.map(...)
df.withColumn("x", $"a" + 1)

반면 statefull은 이전 데이터의 결과(상태)를 저장하고 다음 배치에서 누적/참조한다.

상태를 메모리/디스크에 유지
Checkpoint 필수
상태 크기 관리 중요 (OOM 위험)
데이터 스큐에 민감

groupBy, count, sum, avg, window, mapGroupsWithState, complete ...

streamDF
  .withWatermark("eventTime", "10 minutes")
  .groupBy(
    window($"eventTime", "5 minutes"),
    $"key"
  )
  .count()

5) streaming join

streaming join에는 2가지가 있다.

(1) streaming dataframe -> static dataframe ( Stream–Batch )

스트리밍-정적 조인은 실시간 스트림에 변화가 적은 기존 데이터를 붙일 때 유용하다. 스트리밍-스트리밍 조인보다 간단하며 워터마크가 필수는 아니다.

스트리밍 Outer Join은 매칭되지 않은 데이터도 결과를 내보내야 하므로, 무한정 기다리지 않도록 Watermark와 이벤트 시간 제약이 반드시 필요합니다.

설비 이벤트 + 설비 마스터, 센서 로그 + 기준 정보 등에 사용 가능

스트리밍 데이터에 대해 “고정된 기준 테이블”을 조회
Static DF는 스냅샷처럼 메모리에 올라간 참조 데이터
거의 Stateless
Streaming 쪽의 이전 상태를 기억할 필요 없음

val userInfo = spark.read.parquet("/users")  // Static

val events = spark.readStream
  .format("kafka")
  .load()

events
  .join(userInfo, "userId")
  .select("userId", "eventType", "userName")

2) streaming dataframe -> streaming dataframe ( Stream-Stream )

이벤트 상관 분석에 사용이 자주됨.

두 스트림에서 온 데이터를 조인하려면 한쪽 또는 양쪽 데이터를 상태 저장소에 임시로 저장하고 기다려야 합니다. 이는 상태를 관리하는 Stateful 변환이다.

두 스트림이 시간 축을 기준으로 매칭
양쪽 모두 계속 들어옴 → 상태 유지 필수
강한 Stateful
양쪽 스트림의 과거 데이터 보관
Watermark 없으면 상태 무한 증가

val impressions = spark.readStream
  .withWatermark("eventTime", "10 minutes")

val clicks = spark.readStream
  .withWatermark("eventTime", "10 minutes")

impressions.join(
  clicks,
  expr("""
    impressions.adId = clicks.adId AND
    impressions.eventTime BETWEEN
      clicks.eventTime - interval 5 minutes AND
      clicks.eventTime + interval 5 minutes
  """)
)

22. Spark MLlib

Spark MLlib는 Apache Spark에서 제공하는 분산 머신러닝 라이브러리로 RDD / DataFrame 기반으로 대규모 데이터를 분산 처리하며 머신러닝 알고리즘을 제공하는 라이브러리이다.

1) 알고리즘

분류 (Classification)

Logistic Regression, Decision Tree, Random Forest, Gradient-Boosted Trees, Naive Bayes

회귀 (Regression)

Linear Regression, Generalized Linear Regression, Decision Tree Regressor, Random Forest Regressor

군집 (Clustering)

K-Means, Gaussian Mixture

2) Feature Engineering

기능	종류
문자열 인코딩	StringIndexer, OneHotEncoder
텍스트	Tokenizer, NGram, TF-IDF
스케일링	StandardScaler, MinMaxScaler
벡터화	VectorAssembler

3) Pipeline

전처리 + 학습 + 예측을 하나의 DAG로 관리

from pyspark.ml import Pipeline

pipeline = Pipeline(stages=[
    tokenizer,
    hashingTF,
    lr
])

model = pipeline.fit(train_df)
pred = model.transform(test_df)

[AI] 전통적인 ML 개념정리

usingsystem — Thu, 27 Nov 2025 16:01:06 +0900

1. 머신러닝 역사 & 기본 개념

전통적 프로그래밍 (Traditional Programming)

전통적인 프로그래밍 방식은 사람이 규칙(rule) 을 직접 만들어주는 rule base 방식이다. 이 방식은 데이터가 많아질수록 규칙을 모두 사람이 정의하기 어려워지는 한계가 있다.

예: if-else 규칙 기반 시스템
특징: 규칙은 알지만, 답은 모르는 방식 → 사람이 "조건"을 정의해야 하고, 컴퓨터는 그 규칙을 실행만 한다.

머신러닝 (Machine Learning)

머신러닝은 전통적인 프로그래밍과 정반대 개념이다. 답을 알고 있어 여러가지 규칙을 만들어 낼 수 있다. 즉, 데이터 속에서 패턴을 스스로 학습해 규칙을 만들어내는 방식이다.

답(정답 데이터)은 알고 있지만,
그 답을 만드는 규칙(패턴) 은 컴퓨터가 도출한다.

2. 머신러닝의 종류

1) 지도학습 (Supervised Learning)

정답(label)이 있는 데이터를 학습으로 패턴 인식 알고리즘이다.
- 분류(Classification): 개/고양이, 스팸/정상 → 범주 예측
- 회귀(Regression): 주가 예측, 집값 예측 → 연속값 예측

딥러닝(Deep Learning)도 지도학습 기반으로 많이 활용되며 정답이 있는 데이터로 패턴을 익혀, 새 데이터의 정답을 예측하는 모델을 만든다.

2) 비지도학습 (Unsupervised Learning)

정답(label)이 없는 데이터를 학습으로 패턴 인식 알고리즘이다.
- 군집화(Clustering): 비슷한 데이터끼리 자동으로 묶기
- 차원 축소(Dimension Reduction)

비지도학습은 “이 묶음이 어떤 의미인지”는 사람이 해석해야 한다.

3) 강화학습 (Reinforcement Learning)

스스로 시행착오를 반복해 최적의 행동을 학습 신경망(neural)알고리즘에 속한다
분류도 회귀도 아니고 의사결정(Decision Making) 을 학습하는 방식
데이터가 미리 정해져 있는 것이 아니라, 행동 → 보상 → 정책 학습 구조를 갖는다.

3. 머신러닝에 주로 사용되는 파이썬 라이브러리

scikit-learn (sklearn) - 전통적인 머신러닝 도구로 전처리, 지도/비지도 학습 알고리즘, 모델 평가
TesorFlow - Google 개발, 딥러닝(Deep Learning) 프레임워크
Keras - TensorFlow 상위 API, 코드가 간단하고 직관적이어서 입문자 친화적
PyTorch - Meta(Facebook) 개발, 연구자 및 딥러닝 커뮤니티에서 가장 많이 사용되는 프레임워크
Matplotlib - 파이썬 기반 데이터 시각화 라이브러리, 그림구조 : Figure > Axes > Axis

4. Scaling(스케일링)과 정규화

스케일링은 각 Feature의 단위와 범위를 맞추는 과정이다. 스케일이 서로 다른 상태에서는 머신러닝 모델이 제대로 학습할 수 없기 때문이다.

1) 큰 값이 모델을 지배함( 특징값의 크기가 다르면 큰 값이 모델을 지배함)

예) 키: 170 | 몸무게: 70 | 연봉: 50,000,000

“연봉” 값이 너무 커서 모델이 연봉만 중요하다고 착각한다.

2) 거리 기반 모델(KNN, K-means)에 영향

distance = sqrt((x1 - y1)^2 + (x2 - y2)^2)

Feature 값의 단위가 다르면 특정 Feature가 거리를 거의 전부 결정해버립니다. → 스케일이 큰 축으로만 거리 계산됨.

즉 단위가 큰 Feature가 전체 거리를 좌우함 → 잘못된 분류 가능.

3) 경사하강법(Gradient Descent)의 최적화 수렴 속도 개선

딥러닝이나 선형 모델은 경사하강법을 쓰는데 스케일이 다르면 손실함수의 모양이 길쭉한 타원이 되어 최적점으로 수렴하는 데 오랜 시간이 걸닌다.
스케일링하면 → 매끄러운 곡면 → 빠르게 수렴

4) 모든 Feature를 동일 기준으로 해석하게 함

모든 Feature를 동일한 기준(0~1 또는 평균 0, 분산 1)으로 맞추면 모델이 Feature 간 중요도를 제대로 비교할 수 있고 학습 과정이 안정적이고 불필요한 큰 값 영향 제거 즉, 학습 효율과 안정성, 성능 모두 좋아짐. 스케일링은 “특징값의 크기·단위 차이”를 없서 모델이 공정하게 학습하도록 만드는 기술.

특정 feature 의 value 가 다른 feature 들 보다 훨씬 크면, 그 값이 목적함수를 지배하게 되므로 정확한 학습이 되지 않음

5. 스케일링 종류

1) Simple Feature Scaling

2) Min–Max Scaling (정규화 Normalization)

최솟값 0, 최댓값 1로 맞춤

장점 : 값이 0~1 범위로 깔끔해짐
단점 : 이상치(outlier)가 있으면 전체 스케일 왜곡됨

3) Standard Scaling (Z-score)

가장 많이 쓰이는 방식으로 평균과 표준편차를 이용하여 scaling 하는 방식이다.

데이터가 평균 0, 분산 1의 형태로 변환
→ 대부분의 머신러닝 알고리즘(특히 선형모델, SVM, 로지스틱 회귀, KNN, PCA 등)은 데이터가 정규분포에 가깝다고 가정하기 때문에 StandardScaler가 가장 잘 맞습니다.
이상치(outlier)의 영향이 상대적으로 적음
Min-Max Scaling은 이상치가 하나만 있어도 전체 스케일이 망가짐. 하지만 Standard Scaling은 평균과 표준편차 기반이라 상대적으로 안정적입니다.

from sklearn.preprocessing import StandardScaler
sc = StandardScaler()
# 평균/표준편차 계산
X_train = sc.fit_transform(X_train)
# 평균/표준편차 계산 안해줌. 테스트데이터나 새 데이터는 평균 표준편차 계산을 하면안됨.
X_test  = sc.transform(X_test)

6. Feature Engineering (특성 or 컬럼)

머신러닝에서 말하는 feature(특성) 은 데이터셋에서의 컬럼(column) 을 의미합니다.하지만 "그냥 컬럼"이 아니라 모델이 학습에 사용하는 의미 있는 컬럼을 뜻합니다.

target과의 높은 관련성이 있어야함. ex. 무작위 숫자, 중복되는 컬럼, 주민등로번호 등은 좋은 feature가 될 수 없다.
prediction(예측) 시점에 알수 있음 ex. sales data는 익월에 집계
numeric 타입이어야한다. 문자열은 머신러닝이 이해하지 못 함.
충분한 데이터 수를 가져야한다.
missing values 처리(.fillna)
편향 처리
Data Normalization -> feature scaling
Binning ( 연속된 숫자의 범위 지정 ) ex) 가격에 범위를 지정해서 비싼지, 중간인지, 싼지를 구분해주면 좋
categorical 변수의 수치화(머신러닝은 numeric 타입만 가능하기 때문) ex. 남자 :0, 여자: 1
- ordinal category (순서/크기가 있는 feature) ex. L>M>S -> 3,2,1
- nominal category (순서/크기가 없는 feature) ex. color의 숫자 표시, 남자 여자
  - one-hot encoding 사용하면됨. 0,1 로 변경하는 방법

#one-hot-encoding
pd.get_dummies(df_titanic)

7. 머신러닝 Model 개발 플로우

문제 정의 -> data 준비 -> model 선택 -> model 작성 -> model 평가 -> model 개선 -> 결과 보고

import libraries - sklearn, numpy, pandas, matplotlib, etc
↓
data load - csv, sklearn.datasets, etc
↓
data 내용 파악 - shape, statistics(특성), visualize(시각화)
↓
train/ test dataset 분할 : sklearn, manual 
↓
feature scaling 정규화
↓
model train : fit() fit은 scikit-learn에서 사용되는 전통적 ml 훈련 메소드
↓
모델평가 및 시각화

8. 전통적인 지도학습 알고리즘

1) 회귀 모델

(1) 단변수 선형회귀(Univariate Linear Regression)

- 한개의 변수로 결과 예측 (ex. 혈압으로 당뇨병 여부 예측)
- x,y가 주어지고 w,b 가 미지수 선형회귀에서 X는 입력(독립변수, feature) y는 출력(종속변수, 정답) 역할을 합니다.
- w,b 를 infer(추정)

y=wx+by = w x + b

w: 기울기 → x가 1 증가할 때 y가 얼마나 증가하는지
b: 절편 → 그래프가 y축을 만나는 지점
w,b 둘 다 학습해야 하는 파라미터

평가 지표: R² Score(결정계수)

from sklearn.metrics import r2_score
r2_score(diabetes_y_test, y_pred)

(2) 다변수 선형회귀(Multivariate Regression)

변수가 여러 개일 뿐 단변수 선형회귀와 개념은 동일

2) 분류 모델

(1) KNN (K-Nearest Neighbors)

- 다른 observation(관측치, x data)과의 유사성에 따른 분류

- 서로 가까이 있는 data 들을 이웃(neighbor)이라고 부름
- 가까이 있는 이웃의 label들 중 가장 많은 것을 unknown case의 predication으로 응답한다.
- 장단점 : 간단하지만 dataset이 커지면 상당히 느려진다. 다차원 공간에서의 unknown 포인트와 새로들어온 데이터 거리를 다 계산해야 하기 때문.

from sklearn.neighbors import KNeighborsClassifier
clf = KNeighborsClassifier(n_neighbors=15, weights='uniform')
clf.fit(X_train, y_train)

(2) Decision Tree (결정트리)

규칙을 if-else로 자동 생성해주는 모델
장점: 해석 용이(white-box model) 즉 설명이 필요한 분야에 주로 쓰임(EX.은행), data preprocessing이 필요없이 데이터를 그대로 사용가능
단점: 과적합(overfitting) 위험 높아 훈련데이터는 잘 맞지만 검증데이터에서는 정답률 낮은 현상이 자주 발생한다. 훈련 데이터의 작은 변화에도 매우 민감하다.

- 추후 앙상블 모델과 밀접한 연관이 있음.
- 모든 가능한 결정 경로(decision path)를 tree 형태로 구성한다.
- 각 node는 test를 의미하고 branch는 test의 결과에 해당한다.
- left node는 classification(분류)에 해당한다.

- 알고리즘 종류
- ID3 기본적 알고리즘 정보이득을 이용한 트리 구성
- CART, C4.5, C5.0, CHAID, MARS

- Decision Tree에서는 엔트로피가 높은 상태에서 낮은 상태가 되도록 데이터를 특정 조건을 찾아 나무 모양으로 구분해 간다.

from sklearn import tree
clf = tree.DecisionTreeClassifier(max_depth=2, criterion='entropy') # max_depth를 잘 조절해야 정답률 차이가남. max_depth를 너무 크게잡으면 새로운 데이터를 못 맞출 확률 높음.
clf.fit(X_train, y_train)

(3) Logistic Regression(로지스틱 회귀)

- 회귀모델중 유일하게 분류 모델로 선형회귀를 분류 문제에 적용할 수 있지 않을까? 라는 의문으로 부터 시작됨. 선형회귀 그래프의 y값의 일정 부분이 넘으면 0으로 이하면 1로 분류 하는 문제이다. (ex. 0.5이상이면 암으로 분류, 이하면 종양으로 분류) 하지만 이런 형태는 애매한 구역 발생. 그래서 Sigmoid 함수가 나옴.
- Sigmoid 함수는 0과 1을 출력하는 이진분류 모델이며 미분가능한 성질을 갖는다.

from sklearn.linear_model import LogisticRegression
lr_classifier = LogisticRegression(solver='lbfgs', random_state=0)
lr_classifier.fit(X_train, y_train)

3) 회귀 분류 앙상블 학습 알고리즘(Ensemble Learning)

여러 개의 모델을 묶어 예측 성능을 높이는 기법으로 여러 모델을 평균내거나(회귀) 투표하거나(분류) 해서 더 좋은 결과를 얻습니다.

다수의 약한 학습기 (weak learner)를 조합하여 더 높은 성능 추출을 목표로 합니다.

분류(Classification)와 회귀(Regression)에서의 앙상블 예시

분류 - 여러 모델의 다수결 투표로 클래스를 결정합니다.

회귀 - 여러 모델의 평균값 또는 가중평균을 사용해 예측값을 계산합니다.

Random Forest Classifier (분류) or Regressor (회귀) (많이 사용됨)
Gradient Boosting Classifier (분류) or Regressor (회귀) (많이 사용됨)
XGBoost / LightGBM / CatBoost (분류 모드 or 회귀 모드)
Voting Classifier(분류) or Regressor(회귀)
Bagging Classifier (분류) or Regressor (회귀)

(1) Bagging (Bootstrap Aggregating)

Bagging은 같은 알고리즘의 모델을 여러 개 만들고, 각 모델이 조금씩 다른 무작위 데이터 샘플(모든 attribute 사용)로 학습하도록 한 뒤예측을 평균(회귀) 또는 투표(분류) 로 합치는 기법입니다. 즉, “데이터 다양하게 뽑아서 여러 모델을 독립적으로 훈련 → 최종 결합”

원본 데이터에서 중복을 허용하며(bootstrap) 랜덤 샘플링
여러 개의 모델을 병렬로 독립적 학습
예측 결과를 평균/투표로 합치기

장점
- 분산(Variance) 감소 → 과적합 방지
- 모델이 안정적이고 일관됨
- 병렬(Parallel) 학습 가능 → 빠름

단점
- 편향(Bias) 감소 효과는 크지 않음
- 단순한 데이터 구조에서 Boosting처럼 고성능은 아님

※ Random Forest (Bagging + Decision Tree) 모델

단순 bagging 알고리즘을 강화한 기법 으로 대표 모델에 속함
bagging은 랜덤하게 추출한 데이터의 모든 attribute를 모두 학습시킨다. 모든 attribute를 가지고 Tree를 만들 경우 매우 강한 attribute가 모든 tree에 항상 포함된다. 이를 막기 위한 방법으로 무작위로 추출한 데이터의 서로 다른 특성으로 Tree를 만드는 기법(ex. 30개중 10개만 random selection) 즉, bagging을 보완한 알고리즘

구분	Bagging	Random forest
데이터 샘플링	O (bootstrap)	O (bootstrap)
특성(feature) 샘플링	없음	있음 (feature bagging)
트리 간 다양성	보통 낮음	훨씬 높음
성능	△	더 좋음(보통)
과적합 억제	보통	더 강함

from sklearn.ensemble import RandomForestClassifier

# Training set 에 대해 Random Forest Classifier model 을 fitting
rf = RandomForestClassifier(n_estimators=10, criterion='entropy', random_state=0)
rf.fit(X_train, y_train)

y_pred = rf.predict(X_test)

print(y_pred)
print("Test set true counts = ", sum(y_test))
print("predicted true counts = ", sum(y_pred))
print("accuracy = {:.2f}".format(sum(y_pred == y_test) / len(y_test)))

# making confusion matrix
print("confution matrix\n", 
      confusion_matrix(y_test, y_pred, labels=[1, 0]))
print("f1 score\n", f1_score(y_test, y_pred, labels=[1, 0]))

(2) Boosting

Boosting은 약한 모델(weak learners)을 여러 개 순차적으로(이전 모델의 오류를 보완하면서) 학습시키는 기법입니다.즉, “앞 모델이 못한 부분을 뒤 모델이 점점 보완해 나가는 것”

※ Gradient Boosting (XGBRegressor)모델

대표 모델에 속함
앞 모델이 만든 오차(잔차, gradient)를 다음 모델이 학습해서 보완하는 방식
"경사하강법(gradient descent)"의 개념을 트리 모델에 적용한 것입니다.
동작 방식
1. 첫 번째 모델 예측 → 오차 계산
2. 오차(=잔차) 를 다음 트리가 학습
3. 계속해서 잔차를 줄이는 방향으로 트리를 추가
4. 모든 트리의 예측을 더해 최종 모델을 완성
장점
- 순차적(병렬x)으로 오류를 줄여 성능이 매우 높다 -> 복잡한 패턴도 차근차근 학습 가능
- 트리라서 데이터 스케일링 필요 없음 - > 정규화/스케일링을 안 해도 됨, 이상치(outlier)에 상대적으로 강함
단점
- 과적합(Overfitting) 위험이 Random Forest보다 큼 -> learning_rate, depth 튜닝 필요
- 순차 학습이라 병렬화 어렵다. -> XGBoost 등장 이유

from sklearn.ensemble import GradientBoostingClassifier
#- min_samples_split : node 분리에 필요한 최소 sample 수 => overfitting 방지  
#- max_depth : tree 깊이 조절 => overfitting 방지
#- learning_rate : 각 tree 의 기여도 조정, n_estimators 와 trade-off 
#- n_estimators : number of sequential trees
gb = GradientBoostingClassifier(learning_rate=0.1, n_estimators=500, max_depth=5)
gb.fit(X_train, y_train)

y_pred = gb.predict(X_test)

print(y_pred)
print("Test set true counts = ", sum(y_test))
print("predicted true counts = ", sum(y_pred))
print("accuracy = {:.2f}".format(
            sum(y_pred == y_test) / len(y_test)))
            
# making confusion matrix
print("confution matrix\n", 
      confusion_matrix(y_test, y_pred, labels=[1, 0]))
print("f1 score\n", f1_score(y_test, y_pred, labels=[1, 0]))

# xgbregressor
from xgboost import XGBRegressor

model_ts = XGBRegressor(
    n_estimators=500, learning_rate=0.05, max_depth=6, subsample=0.8, colsample_bytree=0.8)
model_ts.fit(centeral_X_train, centeral_Y_train)

9. 전통적인 비지도학습 알고리즘

비지도 학습은 개발자도 정답을 모르며 데이터만 가지고 있다. AI에게 데이터를 전달해 패턴을 찾게 시키는 방법이다.

정답을 모르기 때문에 모델이 정답을 맞췄는지 못 맞췄는지 비교하기 어려움이 있다.

clustering(군집화)이란 비슷한 object들끼리 모으는 것 으로 label data가 없는 것이 classification(분류)모델과 차이 라고 할 수 있다.

적용 사례

- 고객의 구매 형태별 분류

- 고객의 취향에 맞는 책, 동영상 추천

- 뉴스 자동 분류 및 추천

- 유전자 분석

- 신용카드 정사 및 비정상 유형 찾기

1) Clustering(군집화) 알고리즘

군집화는 비지도 학습의 한 종류로, 레이블 없이 데이터 자체의 내재된 패턴을 찾아 유사한 데이터끼리 묶는 것입니다. 예측이나 분류와는 다르.

(1) K-Means Clustering

다차원에서 샘플간 거리를 계산하는 방식으로 K-Means는 미리 정한 K개의 중심을 초기화하고, 각 데이터를 가장 가까운 중심으로 할당 후, 중심을 업데이트하며 반복하는 방식으로 군집을 찾는다.

그룹핑을 직접정하기 때문에 아웃라이어(Outlier) 디텍션에 약하다. 그래서 그룹핑을 지정하는 k의 개수를 잘 정하는 것이 중요하다.

Random 하게 k개의 centroid(중심점)를 정한다.
각 centroid로 부터 각 data point 까지의 거리를 계산한다.
각 data point 를 가장 가까운 centroid에 할당하여 cluster를 생성한다.
k centroid 의 위치를 다시 계산한다.
centroid가 더 이상 움직이지 않을 때까지 2~4단계를 반복한다.

from sklearn.cluster import KMeans
from sklearn.datasets import make_blobs

centroidLocation = [[3,2], [1,-1],[-1,2]]

X, _ = make_blobs(n_samples=1500, centers=centroidLocation)

plt.scatter(X[:,0], X[:,1], marker='.')

k_means = KMeans(n_clusters=3)
k_means.fit(X)

from matplotlib.colors import ListedColormap

colors_bold = ListedColormap(['#FF0000', '#00FF00', '#0000FF'])
colors_light = ListedColormap(['#FFAAAA', '#AAFFAA', '#AAAAFF'])

plt.figure(figsize=(8,6))

for i in range(nclusters):
    members = k_means.labels_ == i
    plt.plot(X[members, 0], X[members, 1], '.', 
             color=colors_light(i), markersize=10, label=i)
    plt.plot(centers[i, 0], centers[i, 1], 'o', 
             color=colors_bold(i), markeredgecolor='k', markersize=20)

plt.title("KMeans")
plt.legend()

(2) DBSCAN (Density-based Clustering)

DBSCAN은 밀도 기준에 따라 핵심 포인트, 경계 포인트, 이상치를 구분하며, K-Means와 달리 군집 수를 미리 정하지 않아도 되고 비구형 군집에 강점이 있어요.

K-Means의 경우 임의로 cluster 지정하므로 same cluster 내의 data point 들이 실제로는 유사하지 않을 수 있다. 이런 부분을 보완하기 위해 DBSCAN은 밀도가 높은 지역과 낮은 지역을 서로 분리한다.

Outlier의 영향을 적게 받고, cluster 숫자를 미리 정해주지 않아도 되는 것이 장점이다.

즉 포인트들의 집합간 밀도를 파악 해서 군집화 해서 불규칙한 그룹핑도 가능하기 떄문에 밀도에서 벗어난 아웃라이어(Outlier) 디텍션에 강력하다.

from sklearn.cluster import DBSCAN

epsilon = 0.3 # 반경
minimumSamples = 7
db = DBSCAN(eps=epsilon, min_samples=minimumSamples).fit(X)

(3) Hierarchical Clustering(dendrogram)

생물학에서 많이 쓰이는 알고리즘.

(4) 차원 축소 기법 - PCA (Principal Component Analysis) 주성분 분석

차원이 증가함에 따라 vector 공간내의 spcae도 증가하는데 데이터의 양이 적으면 빈공간이 많이 발생하여 에측의 정확도가 떨어진다. 이런 경우 유사한 성격의 feature( 키, 신장 등)는 하나의 새로운 feature로 성분을 합칠 수 있다.

데이터의 분산을 최대한 보존하면서 서로 직교하는 새 축을 찾아, 고차원 공간의 표본들을 선형 연관성이 없는 저차원 공간으로 변환하는 방법이다.

PCA를 사용하여 해결하고자 하는 주요 문제는 고차원 데이터 공간의 희소성(차원의 저주)를 하결하고자 한다. 차원의 저주는 특성(Feature) 수가 많아질수록 데이터 공간이 기하급수적으로 커져 데이터가 희소해지는 현상으로 PCA는 차원을 줄여 이 문제를 완화한다.

PCA는 데이터의 분산을 가장 잘 설명하는 새로운 축(주성분)을 찾아 데이터를 투영함으로써(이때 분산을 최대한 보존하려함), 원본 데이터의 정보 손실을 최소화하며 차원을 줄인다.

# Apply kernel PCA
from sklearn.decomposition import PCA

pca = PCA(n_components=2) # 2 개 component 로 차원(열) 축소

X_train_pca = pca.fit_transform(X_train)
X_test_pca = pca.transform(X_test)

print(pca.components_.shape)
print("첫번째 주성분(고유벡터) :")
print(pca.components_[0])
print("두번째 주성분(고유벡터) :")
print(pca.components_[1])
print()
print('설명된 분산(고유값)의 비율: {}, 두 성분의 합: {:.2f}'.format(pca.explained_variance_ratio_,sum(pca.explained_variance_ratio_)))
      
# pca를 사용한 축소된 차원 데이터 사용해서 로지스특 돌려보기
clf = LogisticRegression(solver='lbfgs', random_state=0)
clf.fit(X_train_pca, y_train)

10. 평가 지표

1) 지도학습 회귀 모델 성능 평가

(1) MSE (Mean Squared Error)

MSE는 “회귀(regression)”에서 사용하는 대표적인 손실 함수(loss function)

오차(예측값과 실제값의 차이)를 제곱하여 평균방법 으로 값이 작을수록 모델이 잘 맞추고 있는 것

큰 오차에 더 큰 패널티
이상치에 민감

(2) MAE (Mean Absolute Error)

오차의 절대값 평균, 이상치에 덜 민감

MSE vs MAE

MSE: 정규분포 + 큰 오차 잡고 싶을 때

이상치가 거의 없는 데이터, 큰 오차를 더 강하게 잡고 싶을 때

선형회귀처럼 전통적인 회귀 모델, 미분하기 쉬워서 학습이 안정적
→ 수학적으로 예쁘고 최적화에 유리

MAE: 이상치 많은 실제 데이터에서 유리

이상치(outlier)가 있을 가능성이 높음, Robust한(튼튼한) 모델이 필요할 때
에러의 크기를 있는 그대로 반영하고 싶을 때, 오차에 선형적 패널티를 주고 싶을 때
→ 실제 현장 데이터에서 MAE가 더 유리한 경우 많음

최적화(Gradient Descent) 관점

MSE
미분 가능하고 부드러워서 최적화가 쉽다. Gradient가 큰 오차에서 커짐 → 학습 빠름
MAE
|x|은 x=0에서 미분 안 됨. 최적화가 상대적으로 까다롭고 느릴 수 있음

항목	MSE (Mean Squared Error)	MAE (Mean Absolute Error)
수식 의미	제곱 오차의 평균	절대 오차의 평균
큰 오차 영향	아주 크게 반영됨 (벌칙 큼)	반영되지만 선형적으로 증가
이상치(Outlier) 영향	매우 민감함	비교적 둔감함
최적화 특성	미분 가능하여 학습이 쉽고 안정적	기울기 0 구간 존재로 불안정할 수 있음
사용 상황	정규분포·이상치 적은 데이터	이상치 많고 현실 데이터 분포에 적합
패널티 형태	오차 증가 시 패널티가 급격히 증가 (제곱)	오차 증가에 따라 선형 증가
오차 곡선 형태	U자 형태 (parabolic)	절대값 형태 (V자 형태)

(3) R² Score(결정계수)

설명력 지표 (0~1)로 모델이 데이터를 얼마나 잘 설명하는지(설명력)를 0~1 사이에서 표현한 값
모델이 y를 얼마나 잘 설명하는지 평가하는 지표1에 가까울수록 좋고, 0이면 평균 수준, 음수면 매우 나쁨
회귀(regression) 모델의 “성능 점수”라고 보면 됩니다.

R2 = 1−(예측값에 대한 분산의 합/분산의 합)

R² 값	의미
1.0	완벽한 예측
0.0	모델이 실제 평균값을 그대로 사용하는 것과 동일한 수준
음수	평균보다도 못 맞추는 매우 나쁜 모델

from sklearn.metrics import r2_score
r2 = r2_score(y_true, y_pred)
print("R2:", r2)

2) 지도학습 분류모델 성능 평가

Confusion Matrix(혼돈행렬)을 이용한 평가

실제 예측	Positive	Negative
Positive	TP	FN
Negative	FP	TN

classification(분류) 성능의 정확성 측정
TP(True Positive) : 1을 1로 제대로 분류
FP(False Positive) : 0을 1로 잘못 분류
FN(False Negative) : 1을 0로 잘못 분류
TN(True Positive) : 0을 0으로 제대로 분류

from sklearn.metrics import confusion_matrix
cm  = confusion_matrix(y_test, y_pred, labels=[1, 0])

print("confution matrix\n", cm)

plt.figure(figsize=(5,4))

ax = sns.heatmap(cm, annot=True, fmt='d', xticklabels=[1, 0], yticklabels=[1, 0])
ax.set_ylabel('Predicted')
ax.set_title('Confusion Matirx\nGround Truth')

Classification rate(정확도) : (TP+TN) / (TP+TN+FP+FN)

단순히 정확도(Accuracy) 계산(전체 데이터 중 제대로 분류된 데이터 비율)

Precision(정밀성) : TP / (TP+FP)

Model이 sample을 True로 분류했을 때 얼마나 자주 맞췄는가 (1에 가까울 수록 좋음)
더 정확한 데이터만 사용하고 싶을 때

Recall(민감도, 재현율) : TP / (TP+FN)

전체 Positive 데이타 중에서 Positive로 분류한 비율 (1에 가까울 수록 좋음)
Positive한 부분을 놓치기 싫을 때 사용. 잘못 분류된게 많아도 다 알고 싶을 때 사용한다. (정확도는 떨어짐)

from sklearn.metrics import accuracy_score, precision_score, recall_score

# predict는 예측된 클래스 번호 array([0., 0., ...])
y_pred = 모델.predict(X_test)

print("Test set의 실제 true 갯수 = ", sum(y_test))
print("모델이 예측한 true 갯수 = ", sum(y_pred))
print("accuracy = {:.2f}".format(accuracy_score(y_test, y_pred)))
print("precision = {:.2f}".format(precision_score(y_test, y_pred)))
print("recall = {:.2f}".format(recall_score(y_test, y_pred)))
---
# predict_proba는 각 클래스의 확률 [0.85, 0.15]
y_pred_proba = 모델.predict_proba(X_test)
print(y_pred_proba)
---
y_pred_proba_1 = y_pred_proba[:, 1]
threshold = 0.4
y_pred_1 = y_pred_proba_1 > threshold
print("threshold가 {}일 때 1 로 분류된 갯수: ".format(threshold), sum(y_pred_1))
print("precision = {:.2f}".format(precision_score(y_test, y_pred_1)))
print("recall = {:.2f}".format(recall_score(y_test, y_pred_1)))
print("f1 score = ", f1_score(y_test, y_pred_1))

precision과 recall은 반비례를 갖는다.

Confidence(정확도) 수준을 올리고 싶으면 Precision을 높이고 Recall을 낮춰 Threshold를 조정한다.
너무 많은 Case를 놓치고 싶지 않은 경우 ReCall을 높이고 Precision을 낮춘다.

F1-score(조화평균)

전체적 성능 측정에 활용
F1 점수는 정밀도와 재현율의 조화 평균로 계산되며, 두 값이 모두 높을 때 높은 값을 가집니다. 불균형 데이터 세트에서 모델 성능을 평가할 때 특히 유용하게 사용돼요.
F1-Score = 2 * (Precision * Recall) / (Precision + Recall)
0일경우 precision과 recall둘다 좋지 않음, 1일경우 둘 다 좋음.

정밀도·재현율의 조화평균
불균형 데이터에서 특히 중요

from sklearn.metrics import f1_score
f1_score(y_test, y_pred_1)

ROC Curve (수신자 조작 특성 곡선 Receiver operating characteristic Curve)

FPR = FP / (FP + TN)
선 아래 면적(AUC)이 클수록 좋다

from sklearn.metrics import roc_curve, roc_auc_score

y_probas = lr_classifier.predict_proba(X_test)
y_scores = y_probas[:,1]

fpr, tpr, _ = roc_curve(y_test, y_scores)
auc = roc_auc_score(y_test, y_scores)

plt.plot(fpr, tpr, label="auc="+ "{:.2f}".format(auc))
plt.legend(loc=4)
plt.xlabel('False Positive Rate')
plt.ylabel('True Positive Rate')
plt.title('ROC Curve')

12. 용어 정리

1) 회귀(Regression)

연속 값을 예측하는 문제 유형으로 출력값이 연속적인 수치일 때 이를 예측하는 모델을 통틀어 회귀 라고 부릅니다.
X를 설명 변수로 하여 Y(연속 값)를 예측하는 통계 기법 전반을 지칭.
ex) 기온 예측, 집 값 예측,

2) 표준편차 (Standard Deviation)

표준 편차는 데이터가 평균을 중심으로 얼마나 흩어져 있는지 나타내는 통계값이다.

3) 내적 행렬(Dot Product)

왼쪽 행렬의 행 × 오른쪽 행렬의 열을 곱해 더하는 연산
벡터의 유사도, 신경망 계산 등에 널리 쓰임

이 결과는 각 원소별 내적의 합이 되는 스칼라 값이 됩니다. 이는 벡터의 내적을 행렬 곱셈으로 확장한 것이라고 볼 수 있습니다.

4) 사분위수 (Quartile)

데이터를 크기 순으로 나열한 뒤, 전체를 4등분하는 경계값을 말합니다.
가장 많이 사용되는 세 가지 사분위수로는 제1사분위수(Q1), 제2사분위수(Q2), 그리고 제3사분위수(Q3)가 있습니다.

25%(1사분위 수), 50%(2사분위 수), 75%(3사분위 수)

5) Loss function(손실 함수)

실무에서 cost(비용 함수)보다 많이 사용

하나의 데이터에 대해 모델이 얼마나 틀렸는지 측정하는 함수 (개별 데이터 오차)

반드시 미분 가능 해야함. (대표적 모델 선형회귀, 이진분류, 다중분류)

6) Cost function(비용 함수)

전체 데이터에 대한 손실(Loss)의 평균 또는 합 오류 (전체 데이터의 평균 오차) 가설이 얼마나 틀렸는지 측정

7) Objective function (목적 함수)

최적화 대상이 되는 함수(cost 포함 더 큰 개념)

8) 엔트로피(Entropy)

주어진 데이터 집합의 혼잡도(데이터가 분류되지 않고 얼마나 뒤죽박죽이냐). 즉, 우리가 가지고 있지 않은 정보의 양을 의미
혼잡도에 따라 엔트로피가 높으면 혼잡도 높음, 엔트로피가 낮으면 혼잡도가 낮음
(0~1)로 표현하며 혼잡도는 0으로 갈 수록 낮아짐.

9) 데이터 세트 분할

과적합(Overfitting)

Traing Data에 비해 Test data의 Error율이 높게 나타나는 경우를 과적합 이라고 한다.
과적합된 모델을 High Variance Model이라고함.
학습 Data와 실제 Data 분포의 차이에 의한 error가 발생할 수 있다. 이를 줄이기 위해 충분한 복잡도를 갖는 모델의 DataSet의 크기를 늘려야한다.

과소적합(UnOverfitting)

- 반대로 모델이 너무 단순해서 데이터의 내재된 구조를 학습하지 못하는 경우 과소적합 이라고 한다.
과소적합된 모델을 High Bias Model이라고함.
Approximation Model(근사치로 만든 함수)과 true function(실제 데이터) 의 차이에 의한 error가 발생한다. **이를 줄이기 위해 데이터가 충분히 있는 상태에서 모델의 Complexity(복잡도)를 올린다.**

현실에서의 데이터 무한 수집과 true function도 알 수 없을 때 간접적 방법

Traing set과 Testing set은 섞이면 안되고 동일한 분포를 유지해야 한다.(검증할 데이터를 Traing set에 넣을 경우)

Cross Validation(교차검증)

Traing set이 부족하여 testSet으로 나누기 불 충분할경우 사용하는 방법.
traing set을 여러개의 sub-set(ex. 하나의sub-set에 5개의 데이터로 나눴다면 4개는 train, 1개는 test)으로 나누고 각 모델을 이 sub-set의 조합으로 훈련시키고 나머지 부분으로 검증하는 방법이다.
Precision / Recall / F1-Score

dataset split - 3split

데이터 set을 3개로 나누어 학습시키는 방법이 가장 좋다고 한다.
- training : 학습용
- validation : hyper parameter tuning 용(ex. cross validation 등 사용)
- test : test용

10) 경사하강법

오차(loss)가 최소가 되는 지점을 찾기 위해, 기울기(gradient)가 내려가는 방향으로 파라미터를 조금씩 업데이트하는 최적화 방법

11) 아웃라이어(Outlier)

아웃라이어(Outlier)는 데이터 전체의 패턴에서 벗어난 극단적인 값을 의미하며, 통계적으로는 평균이나 중앙값에서 크게 떨어진 값으로 정의됩니다. 아웃라이어는 데이터 분석 결과를 왜곡할 수 있어, 이를 탐지하고 처리하는 것이 중요합니다. 대표적인 탐지 방법으로는 Z-score와 IQR(사분위수 범위)을 이용한 통계적 방법과, 밀도 기반 알고리즘인 DBScan, 트리 계열 알고리즘인 Isolation Forest 등이 있습니다

12) 차원의 저주

차원의 저주는 특성(Feature) 수가 많아질수록 데이터 공간이 기하급수적으로 커져 데이터가 희소해지는 현상으로 PCA를 사용하여 차원을 줄여 이 문제를 완화한다.

13) gradient (기울기)

손실 함수가 가중치가 바뀔 때 얼마나 변하는지 알려주는 값 으로 파라미터를 어느 방향으로 얼마나 바꿔야 loss가 줄어드는지 알려주는 미분값이다. 즉 모델이 데이터를 보고 어디가 틀렸고 어떤 방향으로 고쳐야 하는지 수치로 표현한 신호이다.

Gradient가 너무 크면 학습 불안정 하며 0과 가까울 수록 학습 안됨.

[C#서버] Akka.net과 Cluster Part.5 적용해보자!

usingsystem — Thu, 27 Nov 2025 16:00:41 +0900

그동안 공부했던 Akka.net과 IOCP 등 여러 기술을 조합하여 Messenger 서버를 개발해 보고 있습니다.

https://github.com/tkddls3319/Akka.net-IOCP-Web-MessengerServer

GitHub - tkddls3319/Akka.net-IOCP-Web-MessengerServer: Akka.net과 IOCP를 결합한 채팅 서버 ( Cluster )

Akka.net과 IOCP를 결합한 채팅 서버 ( Cluster ). Contribute to tkddls3319/Akka.net-IOCP-Web-MessengerServer development by creating an account on GitHub.

github.com

[C#서버] Akka.net과 Cluster Part.4

usingsystem — Thu, 27 Nov 2025 15:59:59 +0900

Akka.NET 클러스터란?

Akka.NET 클러스터는 여러 대의 서버(노드)를 하나의 분산 시스템으로 구성하여 확장성, 고가용성, 그리고 장애 복구 기능을 제공하는 시스템입니다. 각 서버는 독립적인 역할을 수행하며, 클러스터를 통해 서로 협력하여 부하를 분산하고 높은 가용성을 유지할 수 있습니다.

클러스터의 주요 특징과 개념

확장성 및 역할 기반 분산 처리:
- Akka.NET 클러스터는 서버를 필요에 따라 쉽게 추가하거나 제거할 수 있습니다. 이를 통해 시스템은 수평으로 확장 가능하며, 클라이언트 수나 데이터 처리량이 증가해도 효율적으로 대응할 수 있습니다.
- 각 서버는 클러스터 내에서 특정 역할을 맡습니다. 예를 들어, MMORPG 같은 게임에서는 이동 서버, 전투 서버, 채팅 서버 등 기능별로 서버를 나눠 관리할 수 있습니다. 이러한 역할 기반 분산 처리를 통해 각 기능이 독립적으로 운영되며, 시스템의 복잡성을 줄일 수 있습니다.
고가용성 및 자율적 장애 복구:
- 클러스터는 특정 서버가 장애를 겪더라도 나머지 서버가 정상적으로 작동하도록 보장합니다. 이를 위해, 클러스터 리더를 자동으로 선출하여 클러스터의 상태를 모니터링하고 장애 복구를 지원합니다.
- 장애 발생 시 다른 서버들은 장애 노드를 감지하고, 자동으로 대체 서버를 통해 서비스가 지속될 수 있도록 조정합니다. 예를 들어, 전투 서버가 다운되면 클라이언트는 다른 서버의 기능을 계속 사용할 수 있으며, 시스템이 지속적으로 동작합니다.
클러스터 리더와 자율적 운영:
- Akka.NET 클러스터는 중앙 관리 서버 없이도 동작할 수 있도록 설계되었습니다. 클러스터 리더(Cluster Leader)**는 각 서버 간의 상태를 관리하고, 노드 추가/제거 및 장애 감지 등을 자율적으로 수행합니다.
- 클러스터 내의 리더는 고정되지 않으며, 장애 발생 시 다른 노드가 리더 역할을 이어받습니다. 이를 통해 클러스터는 자율적으로 운영되며, 특정 서버에 의존하지 않습니다.
서버 간 연결 관리 및 서비스 디스커버리:
- 클러스터 내에서 각 서버가 연결될 수 있도록, 시드 노드(Seed Node)를 통해 초기 진입점을 설정합니다. 시드 노드는 클러스터 내의 모든 노드가 알고 있어야 하며, 이를 통해 클러스터에 동적으로 참여할 수 있습니다.
- 서버 간의 연결 정보는 정적으로 구성 파일에 설정하거나, 서비스 디스커버리 도구(예: Consul, Kubernetes)를 통해 자동으로 관리할 수 있습니다.
클라이언트와의 다중 서버 연결:
- 클라이언트는 여러 서버와 동시에 연결하여, 다양한 기능을 동시에 이용할 수 있도록 합니다. 예를 들어, MMORPG에서는 클라이언트가 이동, 전투, 채팅 기능을 동시에 사용하기 위해 이동 서버, 전투 서버, 채팅 서버와 각각 연결됩니다.
- 클러스터는 클라이언트가 각 서버와의 개별 연결을 통해 필요한 기능을 사용할 수 있도록 관리하며, 장애가 발생해도 해당 기능을 제외한 다른 기능을 계속 사용할 수 있게 보장합니다.
분산 데이터 및 데이터 일관성:
- 클러스터는 Akka.NET의 분산 데이터(Distributed Data) 기능을 사용하여 여러 서버에 데이터 저장을 분산하고 복제할 수 있습니다. 이를 통해 데이터 손실 위험을 줄이고, 높은 일관성을 유지할 수 있습니다.
- 각 서버가 특정 기능을 맡아 처리하더라도 데이터가 필요할 때 분산 데이터 기능을 통해 접근하여 일관된 데이터를 제공받을 수 있습니다.

사용 사례: MMORPG와 같은 대규모 시스템

MMORPG에서는 각 서버가 다음과 같은 역할을 수행하며 협력합니다:

이동 서버: 플레이어의 위치 및 이동 관련 정보를 처리.
전투 서버: 전투 및 공격/방어 이벤트를 처리.
채팅 서버: 채팅 메시지 전송 및 수신을 관리.
인벤토리 서버: 플레이어의 아이템과 인벤토리를 관리.

클라이언트를 클러스터에 직접 연결해도 될 까?

클라이언트를 Akka.NET 클러스터의 노드로 연결하는 것은 가능하지만, 일반적으로는 클러스터의 내부 노드로 추가하는 대신, 외부에서 API나 TCP/IP 소켓을 통해 통신하는 방식이 더 효율적입니다. 클라이언트를 클러스터 노드로 연결할 경우, 노드 수가 많아지면서 과부하가 발생할 수 있고, 네트워크 대역폭이 많이 소모될 수 있습니다. 또한, 클라이언트의 네트워크 연결이 불안정하거나 자주 끊길 경우, 클러스터의 안정성에 영향을 줄 수 있으며, 보안 정책을 철저히 관리해야 합니다. 따라서 클라이언트가 클러스터의 직접적인 노드로 참여하는 것보다는 클러스터 외부에서 필요한 데이터를 요청하거나 수신하는 방식이 안정적이고 관리가 용이합니다. 클라이언트를 클러스터에 연결할 때는 부하 관리, 연결 상태 유지, 보안 등을 주의 깊게 고려해야 합니다.

Akka.NET 클러스터의 용어

노드(Node):
- 클러스터를 구성하는 각 서버 또는 인스턴스를 의미합니다. 클러스터는 여러 노드가 협력하여 하나의 시스템처럼 동작하며, 노드는 고유한 주소와 포트를 통해 클러스터에 참여합니다.
시드 노드(Seed Node):
- 클러스터의 초기 진입점으로, 클러스터에 참여하려는 새로운 노드가 연결할 수 있도록 안내합니다. 하나 이상의 시드 노드가 설정되며, 모든 노드는 시드 노드를 통해 클러스터에 참여합니다.
- 클러스터가 확장하거나 노드가 재가입할 때 시드 노드는 중요한 역할을 합니다.
클러스터 리더(Cluster Leader):
- 클러스터 내에서 자동으로 선출되며, 노드 추가 및 제거, 장애 감지, 클러스터 조정 등의 중요한 역할을 수행합니다.
- 리더는 특정 노드에 고정되지 않으며, 리더 노드가 장애가 발생하면 다른 노드가 리더로 선출됩니다. 이를 통해 클러스터는 자율적으로 운영됩니다.
Gossip Protocol:
- 클러스터의 각 노드가 정기적으로 서로의 상태 정보를 교환하여 상태를 동기화하는 프로토콜입니다. 이를 통해 모든 노드는 클러스터의 상태를 공유하며, 장애가 발생한 노드를 빠르게 감지할 수 있습니다.
- 클러스터의 장애 복구 및 상태 일관성 유지에 중요한 역할을 합니다.
분산 데이터(Distributed Data):
- 클러스터 내에서 데이터를 분산 저장 및 복제할 수 있도록 하는 기능입니다. 이를 통해 여러 노드가 동시에 일관된 데이터를 공유할 수 있으며, 장애가 발생해도 데이터 손실을 방지할 수 있습니다.
- 분산 데이터는 데이터 일관성을 유지하면서도 높은 가용성을 보장합니다.

클러스터 분산 라우터(Cluster Aware Router):

클러스터의 각 노드에 걸쳐 메시지를 자동으로 분산시킬 수 있는 라우터입니다. 클러스터 내에서 자원을 최적화하여 부하를 고르게 분산시킵니다.

라우터는 클러스터의 상태를 인식하여, 장애가 발생한 노드로의 라우팅을 피하고, 정상 노드에 메시지를 전달합니다.

코디네이티드 셧다운(Coordinated Shutdown):클러스터의 노드를 종료할 때, 모든 노드가 안전하게 종료될 수 있도록 절차를 관리합니다. 이를 통해 데이터 손실이나 불완전한 종료를 방지하고, 모든 연결과 작업이 안전하게 마무리되도록 돕습니다.

역할(Role):클러스터 내 각 노드에 할당되는 역할로, 특정 노드가 특정 작업을 수행할 수 있도록 지정합니다. 예를 들어, 노드에 "이동", "전투", "채팅" 등의 역할을 지정하여, 클러스터 내 기능을 분리하고 역할별로 작업을 분배할 수 있습니다.

파트리셔닝(Partitioning):클러스터 내에서 데이터를 여러 **구역(partition)**으로 나누어 관리하는 방식입니다. 이를 통해 클러스터는 데이터를 보다 효율적으로 분산하고, 특정 파트리션에 장애가 발생해도 전체 시스템이 영향을 덜 받도록 합니다.

쿼럼(Quorum):분산된 환경에서 특정 작업을 처리하기 위해 필요한 최소한의 노드 수를 의미합니다. 쿼럼을 통해 분산 데이터에 대한 작업을 안정적으로 수행할 수 있습니다. 예를 들어, 데이터 복제나 특정 작업의 동의가 필요한 경우 쿼럼을 만족하는 노드들이 참여해야 합니다.

피어(Peer):클러스터 내의 다른 노드들을 지칭하는 용어로, 각 노드는 피어로서 클러스터의 상태 정보 및 데이터를 공유하고, 필요한 경우 상호 간에 작업을 협력합니다.

리밸런싱(Rebalancing):클러스터 내에서 부하를 균등하게 분배하기 위해 데이터를 다른 노드로 이동시키는 작업입니다. 클러스터 상태에 따라 부하가 과중한 노드에서 상대적으로 가벼운 노드로 작업을 이동시켜, 자원을 최적화합니다.

Gossip Protocol 프로토콜

Akka.NET 클러스터의 Gossip 프로토콜은 클러스터 내 모든 노드가 주기적으로 상태 정보를 교환하여 클러스터 상태를 동기화하고, 장애를 감지하며 복구를 지원하는 핵심 통신 방법입니다. Gossip 프로토콜은 비동기적이고 확산적인 방식으로 작동하여, 특정 노드가 다른 노드 몇 개와 상태 정보를 주기적으로 교환하면, 그 정보가 다시 다른 노드로 퍼지면서 클러스터 전체에 전파됩니다. 이렇게 정보를 주기적으로 공유함으로써, 클러스터의 모든 노드는 시간이 지나면서 동일한 상태 정보를 갖게 됩니다.

Gossip 프로토콜은 장애 감지와 자율적인 복구에 중요한 역할을 하며, 특정 노드가 응답하지 않거나 상태 업데이트가 없는 경우 장애로 간주하여 클러스터 전체에 이를 알립니다. 이를 통해 클러스터는 자율적으로 장애 노드를 감지하고, 이를 복구하거나 대체할 수 있도록 조정합니다. Gossip 프로토콜은 확장성이 뛰어나 대규모 클러스터에서도 효율적으로 작동하며, 장애가 발생해도 클러스터의 일관성과 안정성을 유지할 수 있게 해줍니다. Akka.NET 클러스터에서 Gossip 프로토콜은 클러스터가 안정적으로 운영될 수 있도록 상태를 지속적으로 관리하고, 클러스터 내에서 리더 선출, 노드 추가 및 제거 등의 조정 작업에도 도움을 줍니다.

참조

https://petabridge.com/cluster/lesson1.html

Lesson 1 - Working with Akka.NET and Akka.Cluster

petabridge.com

https://getakka.net/articles/clustering/cluster-overview.html

Akka.Cluster Overview | Akka.NET Documentation

Akka.Cluster Overview What Is a "Cluster"? A cluster represents a fault-tolerant, elastic, decentralized peer-to-peer network of Akka.NET applications with no single point of failure or bottleneck. Akka.Cluster is the module that gives you the ability to c

getakka.net

https://afsdzvcx123.tistory.com/entry/AkkaCluster-%EB%9E%80

Akka.Cluster 란?

참조 https://getakka.net/articles/clustering/cluster-overview.html Cluster 란? 클러스터는 단일 실패 지점이나 병목현상이 없는 Akka.NET 애플리케이션의 내결함성, 탄력적, 분산형, peer to peer 네트워크를 나타냅니

afsdzvcx123.tistory.com

https://www.slideshare.net/slideshow/akkanet-ndc2016/61378890#2

Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016)

Akka.NET 으로 만드는 온라인 게임 서버 (NDC2016) - Download as a PDF or view online for free

www.slideshare.net

[C#서버] Akka.net과 Actor모델 Part.3

usingsystem — Thu, 27 Nov 2025 15:59:54 +0900

주요내용

분산 메세지 전달과 Router
Pool Router
ActorSelect와 Route 비교
HOCON을 사용한 Router 설정
비동기 actor간 메시지 전달 PipeTo와 ReceiveAsync
비동기 호출 단순화 akka.Interfaced
액터 메세지 수신 교착 상태 방지와 ReceiveTimeout

1. 분산 메세지 전달 Router

라우터는 다른 actor 그룹으로 메시지를 전달하는 메시징 허브 역할을 하는 특별한 종류의 actor 입니다. 라우터의 목적은 실제 작업을 수행할 배우들(즉, 라우티)을 통해 작업(메시지 스트림)을 분배하고 균형을 맞추는 것입니다.

라우터는 actor이지만 기존 actor와 다르게 한 번에 여러 메시지를 처리할 수 있습니다. 라우터의 목적은 메시지를 처리하는 것이 아니라, 다른 배우에게 전달하는 것입이기 때문에 가능합니다.

라우터는 대량의 데이터 스트림을 쉽게 관리 가능합니다.

라우터에는 두 가지 유형이 있습니다. 풀 라우터와 그룹 라우터입니다.

풀 라우터 (Pool Router)

작업자 배우(라우티)를 생성하고 관리합니다.
사용자가 라우터에 인스턴스 수를 제공하면 라우터가 작업자 배우를 자동으로 생성합니다.

그룹 라우터 (Group Router)

이미 생성된 라우티에 메시지를 전달하는 역할만 합니다.
라우터 생성 시 라우티의 ActorPaths를 지정하여 사용합니다

라우터 구성 방식

절차적 구성 : 코드에서 직접 라우터를 구성하는 방법입니다.
HOCON 구성 : HOCON을 사용하여 라우터 구성

라우팅 전략에는 2가지가 존재한다.

1. 특정 상황 메세지

특정 요구사항이나 상황에 따라 동작하며, 예를 들어 모든 라우티에게 동일한 작업을 요구할 때 유용합니다.

Broadcast 이 라우팅 전략에서는 라우터가 수신하는 모든 메시지를 모든 라우티에 전달합니다.
Random 랜덤 라우팅 전략에서는 라우터가 메시지를 받을 때마다 무작위로 선택된 라우티에 메시지를 전달합니다.
ConsistentHash 라우팅 전략에서는 라우터가 일관된 해싱을 사용하여 메시지의 데이터를 기반으로 라우티를 선택합니다.

2. 부하 분산 라우팅

업을 라우티 간에 고르게 분산시켜 시스템의 효율성을 높입니다.

RoundRobin: 라우티를 순환적으로 선택하여 메시지를 전송합니다. 부하가 비교적 균일하고, 모든 작업자가 비슷한 성능을 가질 때 유용합니다.
SmallestMailbox (풀 라우터 전용) : 각 라우티의 메일박스에 있는 메시지 수를 기준으로 라우티를 선택합니다. 가장 적은 메시지를 보유한 라우티에 새로운 메시지를 전달합니다. 각 라우티의 메시지 큐가 과도하게 쌓이지 않도록 할 수 있습니다.
TailChopping: 이 전략은 메시지를 첫 번째 라우티에 전달한 후, 일정 시간 대기하여 응답을 기다립니다. 만약 첫 번째 라우티가 응답하지 않으면, 다음 라우티로 메시지를 전달합니다. 응답 시간이 중요한 시스템에서 사용됩니다. 예를 들어, 빠른 데이터 조회가 필요한 경우에 유용합니다.
ResizableRouter (풀 라우터 전용) : 이 전략은 풀 라우터가 자동으로 라우티의 수를 조정할 수 있게 해줍니다. 시스템의 부하에 따라 라우티의 수를 늘리거나 줄이는 방식입니다. 사용자 수가 변동이 큰 서비스(예: 온라인 게임, 대규모 이벤트)에서 효과적입니다.
ScatterGatherFirstCompleted: 모든 라우티에 메시지를 전송하고, 가장 먼저 응답한 라우티의 응답만을 받아서 원래 발신자에게 전달합니다. 규모 데이터 처리나, 신속한 결정이 필요한 상황에서 유용합니다. 예를 들어, 실시간 서비스에서 여러 소스에서 정보를 수집할 때 사용할 수 있습니다.

라우트 메시지

Broadcast 메시지: 비 방송 라우터에게 전달하여 모든 라우티에 메시지를 전달하도록 만듭니다.

router.Tell(new Broadcast("ㅎㅇㅎㅇ"));

GetRoutees 메시지: 라우터의 라우티 목록을 반환합니다. 주로 디버깅에 사용됩니다.

router.Tell(new GetRoutees());

PoisonPill 메시지: 수신한 배우를 즉시 종료합니다.

router.Tell(PoisonPill.Instance);

ActorSelect와 Route비교

특성	ACTORSELECT	ROUTE
정의	특정 패턴에 맞는 모든 배우를 선택하는 방법	메시지를 특정 라우티에 전달하는 방법
사용 목적	여러 배우 중에서 특정 조건에 맞는 배우를 찾기 위해	메시지를 여러 라우티 간에 효율적으로 분산하기 위해
구현 방식	ActorPaths 또는 ActorSelection을 사용하여 선택	라우터가 지정된 라우티에게 메시지를 전달
성능	전체 배우 목록을 확인해야 하므로 상대적으로 느림	라우터를 통해 직접 메시지를 전달하여 빠름
유지 관리	동적으로 변경되는 배우의 상태를 반영하기 어려움	라우터가 상태를 관리하여 동적인 부하 분산 가능
응답 방식	응답이 개별 배우에서 오며, 라우터를 우회함	응답이 라우터를 통해 돌아오며, 라우터가 중재함

2. Group Router 사용예제

액터를 직접적으로 생성하지 않는다. 그렇기 때문에 자동으로 액터를 생성하고 감독가능하며 동적으로 크기를 조정하고 자식 액터의 에러가 발생해도 시스템의 방식이 일관되게 유지되는 등 다양한 장점이 있는 pool router를 주로사용한다.

특성	BroadcastGroup	GroupRouter
목적	모든 라우티에 메시지를 전달	미리 정의된 라우티 중 하나에게 메시지를 전달
메시지 전달 방식	모든 라우티에 동일한 메시지를 전달	선택된 하나의 라우티에게만 메시지를 전달
사용 사례	상태 변경 알림, 긴급 알림	데이터베이스 쿼리 요청, 부하 분산

BroadcastGroup 예시

using Akka.Actor;
using Akka.Routing;
using System.Collections.Generic;

public class Worker : ReceiveActor
{
    public Worker()
    {
        // 메시지를 수신할 때 처리할 로직
        Receive<string>(msg => HandleMessage(msg));
    }

    private void HandleMessage(string msg)
    {
        // 수신한 메시지를 출력
        Console.WriteLine($"Worker {Self.Path.Name} received: {msg}");
    }
}

class Program
{
    static void Main(string[] args)
    {
        var system = ActorSystem.Create("MyActorSystem");

        // 여러 작업자 생성
        var workers = new List<IActorRef>
        {
            system.ActorOf(Props.Create<Worker>(), "worker1"),
            system.ActorOf(Props.Create<Worker>(), "worker2"),
            system.ActorOf(Props.Create<Worker>(), "worker3")
        };

        // BroadcastGroup 생성
        var broadcastGroup = system.ActorOf(Props.Empty.WithRouter(new BroadcastGroup(workers)));

        // 모든 작업자에게 메시지 전송
        broadcastGroup.Tell("Hello, everyone!");

        // 시스템 종료
        Console.ReadLine();
        system.Terminate();
    }
}

3. Pool Router 사용예제

액터를 여러 개의 인스턴스로 생성하고, 이러한 인스턴스들 사이에 메시지를 분산시키는 데 사용됩니다.

풀 라우터를 설정할 때 생성할 액터 인스턴스수를 지정하는 매개변수로 NrOfInstances가 있습니다.

풀 라우터와 NrOfInstances는 함께 사용되어 Akka.NET에서 효율적인 액터 관리를 가능하게 합니다. 풀 라우터는 메시지를 처리할 액터 인스턴스를 관리하고, NrOfInstances는 이 인스턴스의 수를 정의하여 시스템의 부하 분산과 성능을 최적화합니다.

var router = Context.ActorOf(Props.Empty.WithRouter(
    new RoundRobinPool(5) // NrOfInstances 5개의 액터 인스턴스를 생성하여 라우팅
));

풀라우팅 감시

풀 라우터는 자신의 경로(routee)로 사용되는 액터들을 직접 생성하여 자식 액터로 관리합니다. 이 의미는 풀 라우터가 이러한 자식 액터들을 자동으로 감독(Supervise)하고 상태를 감시(DeathWatch)한다는 것입니다. 기본적으로 발생하는 오류는 부모 액터로 전파되어, 풀 라우터가 재시작되고 자식 액터들도 함께 재시작됩니다. 이는 시스템의 안정성을 높이고, 오류 발생 시 일관된 처리를 가능하게 합니다. 필요에 따라 감독 전략을 설정하여 이러한 동작을 커스터마이즈할 수 있습니다.

풀 라우터의 기본 동작은 오류가 발생했을 때 다음과 같은 순서로 진행됩니다:

에러 전파: 자식 액터(routee)에서 오류가 발생하면, 이 에러는 풀 라우터의 부모 액터로 전달됩니다.
재시작 지시: 부모 액터는 풀 라우터에 대해 재시작 지시를 발행합니다.
재시작: 풀 라우터는 스스로를 재시작하고, 그 후 자식 액터들을 재시작합니다.

풀라우팅 사용법

1. Smallest Mailbox Router

SmallestMailbox 라우터는 각 액터의 메일박스(즉, 메시지 큐)에 있는 메시지 수를 기반으로 라우팅합니다. 이 라우터는 현재 대기 중인 메시지가 가장 적은 액터에게 메시지를 전송하여 부하를 균등하게 분산하는 전략입니다. 각 액터의 메시지 큐 상태를 고려하여 최적의 라우팅 경로를 선택함으로써, 시스템의 응답성과 처리 성능을 향상시킵니다. 특정 액터에 과부하를 방지하고, 메시지 처리를 효율적으로 할 수 있습니다.

부하 분산: 액터의 메일박스에 있는 메시지 수를 모니터링하여, 메시지를 보낼 때 대기 중인 메시지가 가장 적은 액터를 선택합니다. 이를 통해 모든 액터가 균일하게 부하를 분산받고, 특정 액터에 과부하가 걸리는 것을 방지합니다.
성능 최적화: 메시지가 가장 적은 액터에 전달되므로, 그 액터가 대기 중인 메시지를 빠르게 처리할 수 있습니다. 이는 전체 시스템의 응답성을 높이고, 병목 현상을 줄이는 데 기여합니다.

var router = Context.ActorOf(Props.Empty.WithRouter(
    new SmallestMailboxPool(5) // 5개의 액터 인스턴스를 생성하고, 큐가 가장 작은 액터에 메시지를 전송
));

2. Resizable Router

Resizable Router는 필요에 따라 액터의 수를 동적으로 늘리거나 줄일 수 있는 라우터입니다. 시스템의 부하 변화에 유연하게 대응할 수 있도록 설계되어 있습니다. 시스템의 부하 변화에 유연하게 대응할 수 있도록 설계되어 있으며, 액터의 수를 동적으로 조정하여 리소스를 효율적으로 관리할 수 있습니다.

부하 변화 대응: 예를 들어, 요청량이 급증할 경우 추가 액터를 생성하여 처리 능력을 향상시키고, 부하가 감소할 때는 사용하지 않는 액터를 줄임으로써 리소스를 절약할 수 있습니다. 이는 클라우드 환경과 같은 동적인 리소스 관리에 적합합니다.

var router = Context.ActorOf(Props.Empty.WithRouter(
    new ResizablePool(5) // 초기 5개의 액터 인스턴스를 생성하고, 필요에 따라 수를 조정
));

4. 풀 라우터와 그룹 라우터의 차이점

풀 라우터는 라우트를 생성하고 관리하여 자신이 생성한 액터 인스턴스의 부모가 되며, 이를 통해 생명주기 관리와 상태 모니터링이 가능합니다. 그룹 라우터는 외부에서 주어진 경로를 기반으로 하여 신뢰성이 낮고 고정된 라우트를 관리합니다. 이러한 차이로 인해 풀 라우터는 일반적으로 더 안전하고 효율적인 선택이 됩니다.

특징	풀 라우터 (Pool Router)	그룹 라우터 (Group Router)
라우트 관리	풀 라우터는 자신의 라우트(액터 인스턴스)를 생성하고 관리합니다. 라우트의 부모가 됩니다.	외부에서 주어진 ActorPaths를 기반으로 라우트를 관리합니다. 라우트의 부모가 아닙니다.
신뢰성	액터 인스턴스를 직접 관리하여 더 안전하고 신뢰할 수 있습니다.	라우트의 상태를 알지 못해 신뢰성이 떨어집니다.
라우트 수동 조정	라우트 풀의 크기를 동적으로 조정할 수 있습니다. 액터를 추가하거나 제거할 수 있습니다.	설정된 이후 라우트의 수가 고정되며 조정할 수 없습니다.
라우트 이름 지정	라우트의 이름을 제어할 수 없으며, 라우터를 통해서만 통신할 수 있습니다.	액터의 경로를 알고 있어 직접적으로 특정 액터와 통신할 수 있습니다.

5. Hocon을 사용한 Routers설정

HOCON(Human-Optimized Config Object Notation)은 Akka.NET의 다양한 설정을 쉽게 관리할 수 있는 구성 형식입니다. 라우터를 설정할 때 HOCON을 사용하면 코드와 구성의 분리를 통해 가독성을 높일 수 있습니다. HOCON을 사용하면 원격 배포와 액터의 행동을 코드 수정 없이 구성 변경만으로 조정할 수 있어, 유연성과 유지보수성을 크게 향상시킵니다.

그룹라우터인 broadcastPool을 사용할 때 nr-of-instances가 무시되지만 설정이 무엇인지 명확히 할 수 있는 유용한 주석이된다. 또한 풀라우터가 있을 경우 코드에서 변경없이 사용할 수있다. 기준을 만드는 느낌.

akka {
	actor{
	  deployment{
	   /myRouter{
	      router = broadcast-pool
	      nr-of-instances = 3
	    }
	  }
   }
}

액터를 생성할 때 WithRouter 메서드를 사용해야 라우터가 설정됩니다. 만약 구성 파일에서 정의한 라우터를 사용하고 싶다면 FromConfig 클래스를 활용할 수 있습니다. 이 클래스는 Akka.NET에게 해당 액터에 대한 라우터 사양을 구성에서 찾도록 지시합니다. 예를 들어, FromConfig.Instance를 사용하면 구성에서 정의한 라우터를 그대로 사용할 수 있습니다. 이를 통해 코드 수정 없이도 구성 파일만으로 액터의 동작을 쉽게 변경할 수 있습니다. 즉 액터 라우터 설정의 재사용성

akka.actor.deployment {
/router1 {
    router = round-robin-pool
        resizer {
            enabled = on
            lower-bound = 2
            upper-bound = 3
        }
    }
}

Hocon을 사용한 설정 사용방법

FromConfig.Instance는 Akka.NET에서 라우터를 정의할 때 HOCON 설정에서 라우터 정의를 가져오는 데 사용되는 특수한 객체입니다. 이를 사용하면 코드에서 라우터를 명시적으로 정의하지 않고도 HOCON 파일에 설정된 대로 라우터를 인스턴스화할 수 있습니다.

akka {
  actor {
    deployment {
      /router1 {
        router = consistent-hashing-pool
        nr-of-instances = 3
        virtual-nodes-factor = 17
      }
    }
  }
}

var router1 = MyActorSystem.ActorOf(Props.Create(() => new FooActor()).WithRouter(FromConfig.Instance), "router1");

6. 비동기 actor간 메시지 전달 ( PipeTo와 ReceiveAsync )

1. ReceiveAsync

동기 작업을 현재 액터에서 처리하면서 송신자에게 결과를 직접 전달할 때 유용하지만, 액터 메일박스의 차단으로 인해 상태 관리가 어려울 수 있습니다.

public MyActor()
{
    ReceiveAsync<SomeMessage>(async some => {
        // 비동기 작업을 안전하게 사용할 수 있습니다.
        await SomeAsyncIO(some.Data);
        Sender.Tell(new EverythingIsAllOK());
    });
}

2. PipeTo

PipeTo는 Akka.NET에서 메시지를 한 액터에서 다른 액터로 전달할 때 사용하는 메서드입니다. 비동기 작업의 결과를 다른 액터로 안전하게 전달하고, 액터 간의 메시지 흐름을 명확하게 유지하는 데 유리합니다.

public class WorkerActor : ReceiveActor
{
    public WorkerActor()
    {
        Receive<string>(message =>
        {
            // 비동기 작업 수행
            var resultTask = PerformWorkAsync(message);
            // 결과를 다른 액터에게 전달
            resultTask.PipeTo(Sender);
        });
    }

    private async Task<string> PerformWorkAsync(string input)
    {
        await Task.Delay(1000); // 1초 대기
        return $"Processed: {input}";
    }
}

// 결과를 처리할 액터
public class ResultActor : ReceiveActor
{
    public ResultActor()
    {
        Receive<string>(result =>
        {
            Console.WriteLine(result);
        });
    }
}

3. akka.interfaced

인터페이스를 통한 비동기 호출을 단순화하고, 타입 안전성을 제공하는 데 초점이 있습니다. 액터 외부에서 액터의 메서드를 비동기적으로 호출하고 그 응답을 기다릴 때 유용합니다.

Akka.Interfaced의 메서드는 기본적으로 Task나 Task<T>로 반환되어 비동기 처리를 수행합니다. 호출하는 측에서는 await 키워드를 통해 액터의 응답을 기다리거나, 비동기 호출을 이어갈 수 있습니다.

public interface ICalculator : IInterfacedActor
{
    Task<int> Add(int a, int b);
}
public class CalculatorActor : InterfacedActor, ICalculator
{
    public Task<int> Add(int a, int b)
    {
        return Task.FromResult(a + b);
    }
}

//액터호출
var actorRef = actorSystem.ActorOf<CalculatorActor>();
var calculator = actorRef.Cast<ICalculator>();

// 비동기적으로 호출
int sum = await calculator.Add(5, 3);
Console.WriteLine($"Sum: {sum}");  // 출력: Sum: 8

PipeTo vs ReceiveAsync

PipeTo 패턴이 액터 내부에서 비동기 작업을 수행하는 데 더 선호됩니다. 그 이유는 PipeTo 패턴은 무엇이 발생하고 있는지를 명확하게 나타내기 때문에, 코드의 가독성이 높아집니다. 이는 코드 유지 보수 시 도움이 됩니다. ReceiveAsync에서 await를 사용하면 액터의 메일박스가 계속해서 차단되며, 이는 액터가 "한 번에 하나의 메시지"를 처리한다는 보장을 준수하는 데 도움이 됩니다. 즉, PipeTo를 사용하면 액터의 상태를 안전하게 유지할 수 있습니다.

즉 ReceiveAsync보다 PipeTo가 더 선호되는 이유는 비동기 작업의 흐름을 더 명확하게 하고, 액터의 스레드 안전성을 보다 잘 보장하기 때문입니다.

특징	PipeTo	ReceiveAsync
사용 목적	비동기 작업의 결과를 다른 액터에 전달할 때 사용	비동기 메시지 처리 및 송신자에게 결과를 직접 전달할 때 사용
가독성	명시적이며 코드의 흐름을 쉽게 이해할 수 있음	상대적으로 덜 명시적일 수 있으며, 복잡한 흐름에서는 이해하기 어려울 수 있음
액터 메일박스 관리	액터의 메일박스가 차단되지 않으며, 메시지 처리를 안전하게 보장	await로 인해 메일박스가 차단될 수 있으며, "한 번에 하나의 메시지" 보장을 유지함
비동기 작업 결과 처리	다른 액터로 결과를 전달	현재 액터에서 결과를 처리하고 송신자에게 직접 전달
스레드 전환	비동기 작업의 결과를 다른 스레드에서 처리할 수 있음	비동기 작업이 같은 스레드에서 처리되므로 상태를 쉽게 유지할 수 있음
예외 처리	비동기 작업의 결과가 다른 액터로 전달되기 때문에 예외 처리가 분리될 수 있음	비동기 작업 중 발생하는 예외는 현재 액터에서 처리해야 함
유지 관리	결과를 다른 액터로 전달하기 때문에 더 유연함	송신자에게 직접 결과를 전달하므로 덜 유연함

PipeTo vs Akka.Interfaced

Akka.Interfaced는 외부에서 액터와의 비동기 상호작용을 단순화하고, 인터페이스 기반 호출을 통해 타입 안전성과 코드 가독성을 높이는 데 적합합니다.

PipeTo는 액터가 비동기 작업의 결과를 직접 메시지로 수신하고 처리하는 데 유용하며, 비동기 작업과 병행해 다른 메시지 처리를 가능하게 하는 등 액터 모델의 특성을 잘 활용할 수 있습니

특징	Akka.Interfaced	PipeTo
주요 목적	인터페이스 기반으로 액터와의 상호작용을 단순화	비동기 작업의 결과를 액터에게 직접 전달하여 처리
사용 사례	외부에서 액터의 메서드를 비동기 호출하고 응답을 기다릴 때 사용	액터 내부에서 비동기 작업의 결과를 메시지로 수신하여 처리할 때 사용
비동기 처리 방식	Task 또는 Task<T> 반환을 통해 비동기 응답을 직접 대기	작업 결과를 PipeTo(Self) 또는 PipeTo(다른 액터)로 전달
코드 표현 방식	await를 통해 일반 메서드 호출처럼 비동기 응답 대기	액터가 메시지 수신자로서 결과를 받고, 비동기 작업 중에도 다른 메시지 처리 가능
주요 장점	- 타입 안전성을 제공	- 액터가 비동기 작업 결과를 자연스럽게 수신 및 처리
주요 장점	- 가독성 높은 메서드 호출 방식	- 병렬 처리 가능
적합한 상황	액터의 비동기 메서드를 외부에서 호출하며 타입 검사 및 간결한 코드가 필요할 때	액터가 비동기 작업의 결과를 기다리지 않고 다른 작업을 병행하며 결과를 처리할 때
타입 안전성	인터페이스를 통해 타입 안전성이 높음	일반 메시지 전달 방식으로, 타입 검사는 없음
응답 처리 위치	외부 호출자 (외부에서 액터의 응답을 기다림)	액터 자신 또는 다른 액터 (결과를 수신하여 메시지로 처리함)

7. 교착 상태 방지와 ReceiveTimeout

ReceiveTimeout은 액터가 메시지를 수신하지 않을 때 자동으로 타임아웃을 설정할 수 있는 기능입니다. 이 기능을 사용하면 액터가 일정 시간 동안 메시지를 받지 않으면 자동으로 타임아웃 이벤트를 발생시켜 특정 작업을 수행할 수 있습니다.

시간 초과가 발생하고 다른 메시지가 해당 ReceiveTimeout메시지보다 먼저 actor 사서함에 도착할 수 있습니다. 이 경우 다른 메시지가 해당 메시지보다 먼저 처리되어 ReceiveTimeout무효화됩니다.

타임아웃 설정: 액터가 Context.SetReceiveTimeout(TimeSpan)을 호출하여 타임아웃을 설정합니다. 이 경우, 액터는 지정된 시간 동안 메시지를 수신하지 않을 경우 ReceiveTimeout 메시지를 수신하게 됩니다.

// ReceiveTimeout을 5초로 설정
Context.SetReceiveTimeout(TimeSpan.FromSeconds(5));
// TimeOut 취소
Context.SetReceiveTimeout(null);
//5초 동안 메세지를 받지 못 한다면 자기자신에게 ReceiveTimeout 메세지
Receive<ReceiveTimeout>(timeout =>
{
});

참조

https://github.com/petabridge/akka-bootcamp/blob/master/src/Unit-3/README.md

akka-bootcamp/src/Unit-3/README.md at master · petabridge/akka-bootcamp

Self-paced training course to learn Akka.NET fundamentals from scratch - petabridge/akka-bootcamp

github.com

[C#서버] Akka.net과 Actor모델 Part.2

usingsystem — Thu, 27 Nov 2025 15:59:49 +0900

주요내용

액터 메시지 처리 스레드 관리 Dispatcher
Akka.Net 애플리케이션 설정 HOCON(Human-Optimized Config Object Notation)
ReceiveActor
메세지 예약 Scheduler
퍼블리시 구독 (pub-sub) 패턴
런타임 액터 동작 전환 BecomeStacked와 UnbecomStacked
액터 동작 전환과 메세지 임시저장 Stash

1. Dispatcher ( 액터 메시지 처리 스레드 관리 )

액터를 사용할 때, 메시지가 액터에 도달하는 과정은 매우 중요합니다. 여기서 핵심 역할을 하는 것이 바로 Dispatcher입니다. Dispatcher는 액터의 메일박스에서 메시지를 꺼내어 액터가 실제로 작업을 수행하는 OnReceive() 메서드로 전달하는 중개자입니다. 쉽게 말해, 액터와 스레드 사이의 연결 고리라고 할 수 있습니다.

이 Dispatcher는 액터가 메시지를 처리하는 데 필요한 스레드를 관리합니다. 여러 액터가 동시에 메시지를 수신하고 처리할 수 있도록 도와줍니다. 예를 들어, 사용자가 UI에서 여러 작업을 동시에 수행하는 경우, Dispatcher는 각각의 액터가 독립적으로 메시지를 처리할 수 있게 합니다. 이를 통해 사용자 경험이 매끄럽고 반응성이 좋아지게 됩니다.

Dispatcher의 종류는 다음과 같습니다:

ThreadPoolDispatcher: 기본 형태로, CLR의 스레드 풀을 기반으로 합니다. 최대한 많은 액터가 동시에 실행될 수 있도록 하여, 높은 성능을 제공합니다.
SynchronizedDispatcher: UI와 관련된 작업을 수행할 때 유용합니다. UI 스레드에서 작업을 할 수 있도록 메시지를 스케줄링하여, UI 요소를 안전하게 업데이트할 수 있게 합니다.
SingleThreadDispatcher: 여러 액터가 하나의 스레드에서 실행됩니다. 특정 상황에서 유용하게 사용될 수 있습니다.

Dispatcher 설정 ( 2가지 존재 )

App.config 또는 HOCON:
- Dispatcher의 기본 설정은 일반적으로 App.config 파일이나 HOCON 구성 파일을 통해 정의됩니다. 예를 들어, akka.actor.synchronized-dispatcher를 설정하면 기본 Dispatcher로 사용할 수 있도록 정의할 수 있습니다.
WithDispatcher 사용:
- 특정 액터가 자신의 Dispatcher를 오버라이드하고 싶을 때 WithDispatcher 메서드를 사용하여 코드에서 직접 설정할 수 있습니다. 이 방법은 특정 액터가 별도의 Dispatcher를 사용해야 할 때 유용합니다.

Program.ChartActors.ActorOf(
                Props.Create(() => new ButtonToggleActor(_coordinatorActor, btnCpu, CounterType.Cpu, false))
                    .WithDispatcher("akka.actor.synchronized-dispatcher"));

2. HOCON

HOCON(Human-Optimized Config Object Notation)은 Akka.NET 애플리케이션의 설정을 정의하는 데 사용되는 강력한 구성 형식입니다. HOCON은 사람이 읽기 쉽고 쓰기 쉽게 설계되어 복잡한 설정을 명확하게 표현할 수 있습니다.

HOCON의 가장 큰 장점 중 하나는 가독성입니다. XML 같은 복잡한 형식에 비해 HOCON은 직관적이고 이해하기 쉽습니다. 주석을 추가할 수 있어 각 설정에 대한 설명을 달기 쉽고, 주석은 # 기호로 시작합니다. 이렇게 하면 코드에 대한 해설이나 추가 정보를 제공할 수 있습니다.

HOCON은 유연한 구문을 지원합니다. 예를 들어, 문자열을 따옴표 없이 쓸 수 있고 여러 줄에 걸쳐 작성할 수 있습니다. 이러한 유연성 덕분에 설정을 쉽게 수정하고 관리할 수 있습니다.

강력한 타입 지원도 HOCON의 특징입니다. HOCON에서 반환되는 값은 강력한 타입으로, 예를 들어 정수나 문자열 등을 쉽게 가져올 수 있습니다. 이를 통해 코드에서 설정 값을 안전하게 사용할 수 있습니다.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <!-- 구성 섹션 정의 -->
    <configSections>
        <!-- 'akka'라는 이름의 섹션을 정의하고, Akka의 HOCON 설정을 처리할 수 있도록 지정 -->
        <section name="akka" type="Akka.Configuration.Hocon.AkkaConfigurationSection, Akka" />
    </configSections>

    <!-- Akka.NET 관련 설정 -->
    <akka>
        <hocon>
            <![CDATA[
            akka {
                actor {
                    deployment {
                        # ChartingActor를 구성하기 위한 설정
                        /charting {
                            # ChartingActor가 UI 스레드에서 실행되도록 동기화된 Dispatcher 사용
                            dispatcher = akka.actor.synchronized-dispatcher 
                        }
                    }
                }
            }
            ]]>
        </hocon>
    </akka>
</configuration>

Dispatcher와의 관계

HOCON은 Akka.NET의 다양한 구성 요소를 설정하는 데 사용되며, 특히 액터의 Dispatcher를 구성하는 데 중요한 역할을 합니다. Dispatcher는 액터의 메일박스에서 메시지를 처리하는 방식과 스레드를 관리하는 요소입니다.

HOCON을 사용하면 Dispatcher의 종류나 설정을 손쉽게 조정할 수 있습니다. 예를 들어, HOCON 설정 파일에서 액터의 Dispatcher를 SynchronizedDispatcher로 지정하여 UI 스레드에서 실행되도록 할 수 있습니다. 이렇게 하면 UI와의 상호작용을 매끄럽게 할 수 있고, 스레드 간의 동기화 문제를 피할 수 있습니다.

3. ReceiveActor ( UntypedActor보다 더 간결하고 명확한 패턴 )

ReceiveActor는 UntypedActor를 기반으로 하여, 더 복잡한 패턴 매칭 및 메시지 처리를 쉽게 할 수 있도록 도와줍니다. ReceiveActor는 OnReceive() 메서드를 가지지 않습니다. 대신, Receive 메시지 핸들러를 ReceiveActor 생성자 내에서 직접 연결해야 합니다. 또는 생성자에서 호출되는 메서드 내에서도 가능합니다.

Receive<T> 핸들러는 여러 가지 형태로 사용할 수 있습니다:

Receive<T>(Action<T> handler):
- 메시지가 T 타입일 때만 핸들러를 실행합니다.
Receive<T>(Predicate<T> pred, Action<T> handler):
- 메시지가 T 타입이고, 조건 함수가 true를 반환할 때만 핸들러를 실행합니다.
Receive<T>(Action<T> handler, Predicate<T> pred):
- 위와 동일합니다.
Receive(Type type, Action<object> handler):
- 타입화된 핸들러의 구체적인 버전입니다.
Receive(Type type, Action<object> handler, Predicate<object> pred):
- 위와 동일합니다.
ReceiveAny():
- 모든 객체 인스턴스를 수용하는 핸들러입니다. 이전의 더 구체적인 Receive() 핸들러로 처리되지 않은 메시지를 처리하는 데 사용됩니다.

public class StringActor : ReceiveActor
{
    public StringActor()
    {
        // 이제 예상대로 작동합니다.
        Receive<string>(s => s.StartsWith("AkkaDotNetSuccess"), s =>
        {
            // 문자열 처리
        });

        Receive<string>(s => s.StartsWith("AkkaDotNet"), s =>
        {
            // 문자열 처리
        });
    }
}

4. Scheduler ( 메시지를 나중에 보내기 위한 스케줄러 사용하기 )

Akka.NET의 ActorSystem.Scheduler는 액터에 미래에 메시지를 보내도록 예약할 수 있는 단일 인스턴스입니다. 스케줄러는 한 번만 전송되는 메시지와 반복적으로 전송되는 메시지 모두를 처리할 수 있습니다.

스케줄러 사용 방법

한 번만 전송되는 메시지: ScheduleTellOnce 메서드를 사용하여 특정 시간 후에 메시지를 전송할 수 있습니다.

system.Scheduler.ScheduleTellOnce(TimeSpan.FromMinutes(30), someActor, someMessage, ActorRefs.Nobody);

반복 메시지: ScheduleTellRepeatedly 메서드를 사용하여 정해진 간격으로 메시지를 반복적으로 전송할 수 있습니다.

system.Scheduler.ScheduleTellRepeatedly(TimeSpan.FromMinutes(30), TimeSpan.FromMinutes(30), someActor, someMessage, ActorRefs.Nobody);

메시지 취소c

예약된 메시지를 취소할 필요가 있을 경우, ICancelable을 사용하여 쉽게 취소할 수 있습니다. 메시지를 예약할 때 취소 지원을 추가하면, 나중에 Cancel() 메서드를 호출하여 해당 메시지를 취소할 수 있습니다.

정확성

스케줄러의 정확성은 일반적으로 충분하지만, 높은 부하가 걸리면 예상보다 조금 늦게 실행될 수 있습니다. 15밀리초 이하의 정밀도가 필요한 경우에는 적합하지 않습니다.

    Context.System.Scheduler.ScheduleTellRepeatedly(TimeSpan.FromMilliseconds(250), TimeSpan.FromMilliseconds(250), Self,
        new GatherMetrics(), Self, _cancelPublishing);
}

퍼블리시-구독(pub-sub) 패턴

구독 메시지 정의: 구독자가 퍼블리셔에 자신의 관심을 알리기 위해 보낼 메시지를 정의합니다

구독 메시지 정의: 구독자가 퍼블리셔에 자신의 관심을 알리기 위해 보낼 메시지를 정의합니다.

public class Subscribe { public IActorRef Subscriber; }
public class Unsubscribe { public IActorRef Subscriber; }
public class PublishMessage { public string Content; }

퍼블리셔 액터 구현: 퍼블리셔 액터는 구독자의 목록을 관리하고, 메시지를 발행하는 기능을 포함합니다.

public class PubActor : ReceiveActor
{
    private HashSet<IActorRef> _subscribers;

    public PubActor()
    {
        _subscribers = new HashSet<IActorRef>();

        Receive<Subscribe>(sub =>
        {
            _subscribers.Add(sub.Subscriber);
        });

        Receive<Unsubscribe>(unsub =>
        {
            _subscribers.Remove(unsub.Subscriber);
        });

        Receive<PublishMessage>(message =>
        {
            foreach (var subscriber in _subscribers)
            {
                subscriber.Tell(message); // 구독자에게 메시지 전달
            }
        });
    }
}

구독자 액터 구현: 구독자는 관심 있는 메시지를 처리합니다.

public class SubActor : ReceiveActor
{
    public SubActor()
    {
        Receive<PublishMessage>(message =>
        {
            Console.WriteLine($"Received message: {message.Content}");
        });
    }
}

퍼블리셔와 구독자를 연결하고 메시지를 발행하는 예시입니다.

var system = ActorSystem.Create("MySystem");

var pubActor = system.ActorOf<PubActor>("pubActor");
var subActor1 = system.ActorOf<SubActor>("subActor1");
var subActor2 = system.ActorOf<SubActor>("subActor2");

// 구독 등록
pubActor.Tell(new Subscribe { Subscriber = subActor1 });
pubActor.Tell(new Subscribe { Subscriber = subActor2 });

// 메시지 발행
pubActor.Tell(new PublishMessage { Content = "Hello, Subscribers!" });

5.런타임에 액터 동작 전환 BecomeStacked와 UnbecomeStacked

스위치 가능한 행동은 액터 모델의 핵심 특성 중 하나로, 액터가 처리하는 메시지에 따라 그 행동을 동적으로 변경할 수 있는 기능입니다. 이 기능은 유한 상태 기계(Finite State Machines) 구현이나 다른 메시지에 따라 액터의 메시지 처리 방식을 변경하는 데 매우 유용합니다. 만약 행동 전환을 했다면 이전에 등록한 recive 행동은 모두 무효화된다.

스위치 가능한 행동의 작동 방식

행동 전환: 액터가 새로운 동작으로 전환할 때 BecomeStacked를 호출하여 현재 동작을 스택에 추가하고 새로운 동작으로 변경합니다.
이전 동작 복원: UnbecomeStacked를 호출하면 스택에서 마지막 동작을 제거하고 이전 동작으로 돌아갑니다.

ReceiveActor에서의 행동 전환

Become:현재의 수신 메서드를 새로운 메서드로 교체합니다. 이전 행동은 스택에 남지 않으며, 새로운 행동만 활성화됩니다.
BecomeStacked:새로운 행동을 스택에 추가하고, 이전 행동을 유지합니다. 여러 개의 행동을 쌓아 두고 필요할 때 쉽게 전환할 수 있습니다.
UnbecomeStacked:스택에서 마지막 행동을 제거하고 이전 행동으로 복원합니다.

public class MyReceiveActor : ReceiveActor
{
    public MyReceiveActor()
    {
        // 초기 행동 설정
        Become(Initial);
    }

    private void Initial()
    {
        Receive<Start>(msg =>
        {
            // 행동 전환
            Become(Processing);
        });
    }

    private void Processing()
    {
        Receive<Complete>(msg =>
        {
            // 작업 완료 처리
            UnbecomeStacked(); // 이전 행동으로 복원
        });

        Receive<OtherMessage>(msg =>
        {
            // 다른 메시지 처리
        });
    }
}

UntypedActor에서

Context.Become(Receive rec)- 현재 수신 루프를 새로운 동작으로 교체합니다. 기존의 행동 스택은 제거됩니다.
Context.BecomeStacked(Receive rec)- 새로운 동작을 스택에 추가하면서 이전 동작을 유지합니다. 여러 개의 행동을 쌓을 수 있습니다.
Context.UnbecomeStacked()- 스택에서 마지막 동작을 제거하고 이전 동작으로 복원합니다. 이 메서드는 BecomeStacked와 함께 사용됩니다.

public class MyUntypedActor : UntypedActor
{
    protected override void OnReceive(object message)
    {
        if (message is Start)
        {
            // 행동 전환
            Context.Become(Processing);
        }
    }
    private void Processing(object message)
    {
        if (message is Complete)
        {
            // 작업 완료 처리
            Context.UnbecomeStacked(); // 이전 행동으로 복원
        }
        else
        {
            // 다른 메시지 처리
        }
    }
}

행동 스택의 깊이

행동 스택은 깊게 쌓을 수 있지만, 무한정 쌓을 수는 없습니다. 액터가 재시작될 때 스택은 초기 상태로 돌아갑니다.

6. 메세지 임시 저장 Stash

앞서 알아본 런타임에 액터 행동 전환(behavior transition)은 액터가 다양한 상태를 관리하는 데 중요한 역할을 합니다. 액터가 상태를 전환할 때, 이전 상태에서 수신된 메시지를 처리할 수 없는 상황이 발생할 수 있습니다. 예를 들어

온라인 쇼핑몰에서 주문을 처리하는 OrderActor라는 actor가 있다고 가정해봅시다. 이 actor는 두 가지 주요 상태를 가집니다:

대기 상태: 새로운 주문을 받을 준비가 된 상태입니다.
처리 중 상태: 현재 한 주문을 처리하고 있는 상태입니다.

대기 상태에서의 메시지 처리

OrderActor가 대기 상태일 때, 새로운 주문 메시지(PlaceOrder)를 받으면 이 메시지를 즉시 처리할 수 있습니다. 주문 처리 로직을 실행하고, 고객에게 주문 완료 메시지를 보내는 방식으로 작동합니다.

처리 중 상태에서의 메시지 처리

그러나 OrderActor가 현재 주문을 처리 중인 경우, 새로운 주문 메시지를 받았을 때는 이를 처리할 수 없습니다. 이때 stash 기능을 사용하여 처리할 수 없는 메시지를 임시로 저장하게 됩니다. 즉, actor는 새로운 주문 메시지를 받았지만, 처리할 수 없는 상황이기 때문에 이 메시지를 stash에 저장합니다.

행동 전환 후 메시지 처리

주문 처리가 완료되면 ProcessingComplete라는 메시지를 수신하게 되며, 이때 stash에 저장된 메시지들을 다시 꺼내서 처리할 수 있는 상태로 전환됩니다. 이제 OrderActor는 대기 중이던 새로운 주문 메시지를 처리할 수 있게 됩니다.

즉 행동전환등으로 인해 메시지를 바로 받아 볼 수 없을 경우 메시지를 임시로 저장하고 나중에 처리할 수 있도록 하는 기능입니다. 액터가 현재 상태에서 처리할 수 없는 메시지를 수신했을 때, 이를 스택에 저장해 두고, 적절한 시점에 다시 처리할 수 있게 해줍니다.

임시 저장: 액터가 현재 상태에서 처리할 수 없는 메시지를 스택에 저장할 수 있습니다. 이후 액터의 상태가 변경되면 이 저장된 메시지를 다시 처리할 수 있습니다.
유연한 메시지 처리: Stash를 사용하면 액터가 특정 조건을 충족할 때까지 메시지를 대기시킬 수 있으므로, 복잡한 비즈니스 로직을 보다 유연하게 처리할 수 있습니다.
행동 전환과 함께 사용: Stash는 행동 전환과 함께 사용되며, 특정 행동에서 다른 행동으로 전환할 때, 처리할 수 없는 메시지를 임시로 저장할 수 있습니다.

Stash 메서드

액터 OnReceive나 Receive<T>핸들러 내부에서 호출하여 Stash.Stash()현재 메시지를 맨 위에 놓을 수 있습니다

Stash(): 현재 메시지를 스택에 저장합니다.
Unstash(): 저장된 메시지를 다시 처리할 수 있도록 꺼내는 기능입니다.
UnstashAll(): 스택에 저장된 모든 메시지를 다시 처리할 수 있도록 꺼냅니다.

Stash 유형 정의 인터페이스

1. IWithBoundedStash

제한된 크기를 가진 스태시를 제공합니다. 즉, 저장할 수 있는 메시지의 개수가 미리 정해져 있으며, 이 한계를 초과하면 더 이상 메시지를 저장할 수 없습니다. 이 경우 가장 오래된 메시지가 삭제됩니다.

스태시의 크기를 미리 설정할 수 있습니다. 자원 관리 측면에서 유용하며, 무한정 쌓이는 것을 방지할 수 있습니다.

2. IWithUnboundedStash

크기에 제한이 없는 스태시를 제공합니다. 즉, 저장할 수 있는 메시지의 개수가 제한되지 않으며, 필요한 만큼 메시지를 저장할 수 있습니다.

저장할 수 있는 메시지의 개수에 제한이 없으므로, 필요한 만큼 메시지를 쌓을 수 있습니다., 메모리 사용 측면에서 주의가 필요할 수 있습니다.

// 주문 메시지 클래스
public class PlaceOrder
{
    public string OrderId { get; }
    public PlaceOrder(string orderId)
    {
        OrderId = orderId;
    }
}

// 처리 완료 메시지 클래스
public class ProcessingComplete { }

// 주문 처리 Actor
public class OrderActor : ReceiveActor, IWithUnboundedStash
{
    // IStash 프로퍼티를 통해 stash 사용
    public IStash Stash { get; private set; }

    public OrderActor()
    {
        // 초기 상태에서 주문 메시지를 받는 경우
        Receive<PlaceOrder>(order =>
        {
            // 주문 처리 로직
            Console.WriteLine($"주문 {order.OrderId}을 처리합니다.");
            // 상태를 처리 중 상태로 변경
            Become(Processing);
        });
    }

    // 처리 중 상태
    private void Processing()
    {
        // 새로운 주문 메시지를 받으면 stash에 저장
        Receive<PlaceOrder>(order =>
        {
            Console.WriteLine($"처리 중이므로 주문 {order.OrderId}을 stash합니다.");
            Stash.Stash(); // 메시지를 stash에 저장
        });

        // 주문 처리가 완료되었음을 알리는 메시지 수신
        Receive<ProcessingComplete>(complete =>
        {
            Console.WriteLine("주문 처리가 완료되었습니다. stash에서 메시지를 처리합니다.");
            Stash.UnstashAll(); // stash에서 보관된 메시지를 처리할 수 있는 상태로 전환
        });

        // stash에서 꺼내온 메시지를 처리
        Receive<PlaceOrder>(order =>
        {
            // 보관된 주문 처리 로직
            Console.WriteLine($"stash에서 주문 {order.OrderId}을 처리합니다.");
        });
    }
}

참고

https://github.com/petabridge/akka-bootcamp/blob/master/src/Unit-2/README.md

akka-bootcamp/src/Unit-2/README.md at master · petabridge/akka-bootcamp

Self-paced training course to learn Akka.NET fundamentals from scratch - petabridge/akka-bootcamp

github.com

[C#서버] Akka.net과 Actor모델 Part.1

usingsystem — Thu, 27 Nov 2025 15:59:43 +0900

주요내용

Akka.net 이란?
액터관리와 ActorSystem
액터간 메세지 전달 Tell
액터참조와 IActorRef
액터생성과 Props
액터간 감독과 예외처리 supervision
주소로 액터 찾기 ActorSelection
ActorSelection과 IActorRef 차이점
액터 라이프사이

1. Akka.net이란?

.NET 플랫폼에서 사용할 수 있는 오픈 소스 프레임워크로, Actor 모델을 구현하여 병렬성과 분산 시스템을 쉽게 구축할 수 있도록 도와줍니다.

2. Actor모델 이란?

Actor 모델은 큰 프로젝트에서 여러 작업을 동시에 처리하거나, 많은 사용자가 동시에 접속하는 시스템을 만들 때 매우 유용한 패턴입니다. 이 모델을 이해하기 위해 먼저, 우리가 흔히 사용하는 객체 지향 프로그래밍(OOP)과 비교해볼게요.

객체 지향 프로그래밍에서는 메서드를 호출하고, 객체의 상태를 변경하는 것이 기본입니다. 그러나 동시성 문제를 처리하려면 여러 스레드가 공유하는 메모리와 이를 관리하는 락(lock)이라는 장치를 사용해야 합니다. 하지만 락은 복잡할 뿐만 아니라, 잘못 사용하면 시스템이 멈추거나 성능이 떨어지는 문제가 발생할 수 있어요.

여기서 Actor 모델이 등장합니다. Actor 모델은 이러한 문제를 해결하기 위해 개발된 패턴으로, 핵심 개념은 '모든 것이 독립적으로 동작하는 작은 단위로 나누어져 있고, 이들이 메시지를 통해 서로 소통한다'는 것입니다.

1. Actor의 독립성과 메시지 기반 동작:

Actor는 스스로 동작하는 작은 단위입니다. 각 Actor는 자신만의 상태와 행동을 가지고 있으며, 다른 Actor와 직접적인 상호작용 없이 '메시지'라는 형태로 소통합니다. 예를 들어, Actor가 어떤 작업을 하고 싶다면, 직접 다른 Actor의 메서드를 호출하는 대신, '이거 해줘'라는 메시지를 보냅니다. 이 방식은 서로의 상태를 직접 변경하지 않고, 요청을 보낸 후 처리 결과를 기다리거나 다른 일을 처리할 수 있게 해줍니다.

2. 병렬성과 비동기 처리:

Actor 모델의 또 다른 중요한 개념은 비동기적 동작입니다. 비동기란 작업을 요청한 후 그 작업이 완료될 때까지 기다리는 대신, 다른 일을 계속할 수 있다는 것을 의미합니다. Actor 모델에서는 각 Actor가 메시지를 비동기적으로 받아서 처리하기 때문에, 여러 작업이 병렬로 진행될 수 있습니다. 이때 각 Actor는 독립적인 스레드로 동작하거나 스레드 풀이라는 것을 이용해 효율적으로 관리됩니다.

3. 상태와 동기화:

각 Actor는 자신만의 상태를 가지고 있고, 이 상태는 해당 Actor 자신만 변경할 수 있습니다. 상태를 공유하지 않고 메시지로만 소통하기 때문에, 공유 메모리 문제나 복잡한 동기화(락 사용 등)를 신경 쓸 필요가 없어요. 예를 들어, 게임에서 각 캐릭터가 독립적으로 움직이고 행동하는 것을 Actor라고 생각할 수 있습니다. 이 캐릭터들은 서로의 상태를 직접 변경할 수 없고, 메시지를 보내 어떤 행동을 유도할 수 있습니다.

4. 에러 처리와 계층 구조:

Actor 모델에서는 에러를 처리하는 방식도 체계적입니다. Actor는 부모-자식 관계로 계층 구조를 형성하고, 부모 Actor는 자식 Actor의 상태를 감시하고 관리할 수 있습니다. 자식 Actor에서 문제가 발생하면, 부모가 이를 감지하고 적절한 조치를 취할 수 있죠. 예를 들어, 자식을 재시작하거나, 중지할 수 있습니다. 이를 통해 시스템이 안정적으로 작동하도록 돕습니다.

이런 구조 덕분에 Actor 모델은 복잡한 동시성 문제를 해결할 수 있고, 시스템의 성능과 안정성을 높이는 데 큰 도움이 됩니다. 병렬 작업이 많거나, 시스템의 확장이 중요한 경우에 특히 유용합니다. Actor 모델은 마치 각기 다른 악기를 연주하는 오케스트라 단원들이 서로 간섭하지 않고 지휘자의 지시에 따라 연주하는 것과 비슷하다고 생각하면 이해가 쉬울 것입니다. 각 Actor가 자신의 역할을 하고, 지시에 따라 움직이며, 메시지라는 악보를 통해 조화롭게 동작하는 거죠.

이렇게 Actor 모델을 통해 복잡한 동시성 문제를 풀어나갈 수 있답니다!

비동기적 메서드 호출: 객체 지향 패턴에서 동기적 메서드 호출이 이루어진다면, Actor 모델에서는 메서드 호출이 비동기로 변경됩니다. 이를 통해 병렬성과 비동기 처리를 자연스럽게 구현할 수 있습니다.
Thread 기반 동작: Actor는 독립적인 실행 단위로, 각 Actor는 독립된 스레드 기반 객체입니다. 하지만 반드시 모든 Actor가 하나의 스레드에 할당되는 것은 아니며, 스레드 풀을 통해 관리되어 더 많은 Actor를 효율적으로 실행할 수 있습니다.
메시지 기반 동기화: Actor 모델에서는 상태 공유와 직접적인 동기화 대신 메시지 전달을 통해 동기화 문제를 처리합니다. 이는 각 Actor가 메시지를 수신하고 처리하는 방식으로 내부 상태를 관리하도록 합니다.

Actor 모델이 해결하려는 문제

공유 메모리와 동시성 문제: OOP에서 메서드를 호출하여 내부 객체의 상태를 변경할 때, 공유 메모리에 접근하는 여러 스레드가 존재할 수 있습니다. 이로 인해 데이터 레이스, 동기화 문제, 복잡한 락 관리가 필요하게 됩니다.
락의 문제점: 락(lock)을 사용하면 다음과 같은 문제가 발생합니다:
- 동시성 제한: 락은 한 번에 하나의 스레드만 자원에 접근하도록 제한하여 동시성을 감소시킵니다.
- 비용이 큰 작업: 락과 관련된 스레드의 일시 정지와 복원은 운영체제(OS) 차원에서 높은 비용이 듭니다.
- Deadlock: 잘못된 락 관리로 인해 시스템이 교착 상태에 빠질 위험이 있습니다.
위임된 작업의 에러 처리: 기존의 병렬 처리 방식인 Task-delegate concurrency에서는 작업을 위임할 때 발생하는 에러를 작업을 넘겨준 쪽에서 받기 어렵습니다. Actor 모델은 이러한 문제를 언어 수준에서 해결하고자 합니다.

Actor 모델의 주요 구조와 동작

MailBox(메시지 큐): 각 Actor는 자신만의 메시지 큐를 가지고 있습니다. 이 큐는 비동기적으로 메시지를 수신하고 저장합니다.
메시지: Actor는 메시지를 통해 서로 통신합니다. 특정 메서드를 직접 호출하는 대신, 특정 Actor에게 메시지를 전달하여 행동을 유도합니다. 모든 POCO( Plain Old CLR Object )는 메세지가 될 수 있다.
Behavior: Actor는 수신한 메시지에 따라 특정 행동을 결정하고 실행합니다. 예를 들어:
- 자신의 상태를 변경할 수 있습니다.
- 새로운 자식 Actor를 생성하거나 기존 자식을 제거할 수 있습니다.
- 다른 Actor에게 메시지를 보낼 수 있습니다.
State: Actor의 상태는 Actor 자신만 변경할 수 있습니다. 상태는 init, ready, closed 등의 단계로 나타낼 수 있습니다.
동기화 대신 메시지 전달: Actor 모델에서는 락이나 블로킹 대신 메시지 전달 방식을 사용하여 동기화를 처리합니다. 이는 특정 Actor에게 메시지를 보내는 것으로, 직접적으로 스레드를 실행하는 것을 의미하지 않습니다.

에러 처리와 계층 구조

계층적 구조: Actor 간의 호출 관계를 통해 계층 구조(Hierarchy)가 형성됩니다. 예를 들어, 부모 Actor는 자식 Actor의 상태를 감시할 수 있으며, 자식 Actor에서 오류가 발생하면 이를 감지하고 대응할 수 있습니다.
에러 전파와 관리: 부모 Actor는 자식 Actor의 에러를 관리할 수 있으며, 이를 통해 에러의 전파를 제어할 수 있습니다.

3. 액터 관리 ( ActorSystem )

ActorSystem은 하나의 프로세스 내에서 동작하는 여러 액터들을 조직화하고, 메시지 전달, 액터 생명주기 관리, 스케줄링 등을 담당합니다.

기능

액터 생성 및 관리: ActorSystem은 액터의 부모 역할을 하며, 액터 트리 구조를 유지 관리합니다.
메시지 전달: 액터 간의 메시지 전달을 중개하고, 비동기 메시지 큐를 관리합니다.
설정 및 구성: 시스템 설정 파일을 통해 액터 시스템의 동작을 구성할 수 있습니다.
생명주기 관리: 액터의 시작, 종료, 재시작 등의 생명주기를 관리하여 내결함성을 지원합니다.

ActorSystem은 하나의 애플리케이션에서 여러 개 생성할 수 있지만, 일반적으로 한 개만 사용하는 것이 일반적입니다. 이를 통해 애플리케이션 내의 모든 액터가 같은 컨텍스트 내에서 동작하게 됩니다.

public class HelloActor : UntypedActor
{
    protected override void OnReceive(object message)
    {
        if (message is string msg)
        {
            Console.WriteLine($"Received: {msg}");
        }
    }
}

class Program
{
    static void Main(string[] args)
    {
        // ActorSystem 생성
        ActorSystem MyActorSystem = ActorSystem.Create("MyActorSystem");

        // UntypedActor 생성
        // IActorRef는 Akka.NET에서 액터를 참조하기 위한 인터페이스입니다.
        // 액터 시스템에서 생성된 액터는 직접 참조되는 것이 아니라, IActorRef를 통해 참조됩니다.
        IActorRef helloActor = system.ActorOf(Props.Create(() => new HelloActor()), "helloActor");

        // 메시지 전송
        helloActor.Tell("Hello, Akka.NET!");

        // 시스템 종료
        Console.ReadLine();
        system.Terminate().Wait();
    }
}

4. 메시지 정의 및 처리 ( Tell )

Tell()을 사용하여 Actor에게 메시지를 전달할 수 있다. UntypedActor를 상속받아 Actor를 만들경우 Actor가 처리 방법을 모르는 메시지를 전달받는 다면 무시하거나 무시한 메세지를 Unhandled()를 통해 처리할 수 있다. ReceiveActor를 사용하면 Unhandled 로깅이 자동으로 수행된다.

메세지를 전달받은 Actor는 Sender를 통해 다른 Actor에게 답장을 하거나 메세지를 전달 할 수 있다.

// MyActor 클래스는 UntypedActor를 상속하여 메시지를 처리하는 액터입니다.
public class MyActor : UntypedActor
{
    // 메시지를 수신할 때 호출되는 메서드
    protected override void OnReceive(object message)
    {
        // 메시지가 Messages.InputError 타입일 경우 처리
        if (message is Messages.InputError msg)
        {
            Console.ForegroundColor = ConsoleColor.Red;
            Console.WriteLine(msg.Reason); // 에러 메시지 출력
        }
        else
        {
            // 처리할 수 없는 메시지는 Unhandled() 메서드를 호출하여 무시
            Unhandled(message);
        }
    }
}

5. IActorRef와 Props

액터 참조 핸들러 IActorRef ( http://api.getakka.net/docs/stable/html/56C46846.htm )

IActorRef는 액터에 대한 참조 또는 핸들 역할을 하며, ActorSystem을 통해 액터에게 메시지를 보낼 수 있도록 지원합니다. 액터와 직접 소통하지 않고, IActorRef에 메시지를 보내면 ActorSystem이 이를 전달합니다. IActorRef는 액터가 로컬이든 원격이든 관계없이 메시지를 보낼 수 있는 참조를 제공하며, 해당 액터가 과거에 존재했음을 보장합니다. 액터가 종료될 수 있기 때문에, 종료 알림을 받으려면 IActorContext.Watch를 사용하여 감시할 수 있고, 종료 시 Terminated 메시지를 받을 수 있습니다.

Actor간 직접적인 통신을 하지 않는다.

직접적으로 하는 것이 아니라 ActorSystem을 통해서 이루어집니다.

메시지 관리와 전달 방식: ActorSystem은 모든 메시지를 Envelope로 감싸서 전달하며, 이 Envelope에는 메시지에 대한 메타데이터가 포함되어 있습니다. 액터는 이 메타데이터를 활용해 메시지를 보다 효과적으로 처리할 수 있습니다.
위치 투명성: 액터가 어느 프로세스나 머신에 있는지 신경 쓰지 않아도 됩니다. ActorSystem은 액터의 위치를 자동으로 관리하며, 이를 통해 원격 액터를 지원할 수 있습니다. 이렇게 하면 여러 머신에서 분산 처리하여 시스템의 확장성을 높일 수 있습니다.

메시지가 액터에게 전달되었는지 확인하는 것 역시 ActorSystem이 관리하는 부분입니다. Akka.NET은 메시지 전달을 보장하는 다양한 메커니즘을 제공하므로, 이를 직접 관리할 필요는 없습니다. 현재로서는 메시지 전달이 ActorSystem의 역할이라는 점을 신뢰하면 됩니다.

Actor의 계층 구조

액터는 계층을 형성합니다. 즉, 본질적으로 자신에게 직접 보고하는 "최상위" 액터가 있고 ActorSystem다른 액터에게 보고하는 "자식" 액터가 있습니다. 자식 액터를 만드는 이유는 시스템의 복잡성을 관리하고, 역할과 책임을 분리하여 더 구조적이고 유연한 액터 시스템을 설계하기 위함입니다. 자식 액터는 부모 액터의 일부 작업을 분담하여 처리하거나, 특정 기능을 전담하도록 설계됩니다. 이를 통해 부모 액터는 더 간단한 역할을 유지하며, 자식 액터는 자신만의 상태와 로직을 관리할 수 있습니다. 또한, 자식 액터는 부모 액터가 실패하거나 재시작할 때 함께 관리될 수 있어, 내결함성과 안정성을 향상시킵니다.

계층에 따른 경로가 변경된다.

class MyActorClass : UntypedActor{
    // PreStart는 액터가 시작될 때 호출되는 초기화 메서드이다. 보통 부모 자식 관계를 설정함.
	protected override void PreStart(){
		IActorRef myFirstChildActor = Context.ActorOf(Props.Create(() =>
        new MyChildActorClass()), "myFirstChildActor");
	}
}

IActorRef와 context

Context는 액터의 생명 주기, 자식 액터 관리, 메시지 전달, 로깅, 스케줄링 등의 작업을 지원합니다.

Self: 현재 액터 자신에 대한 참조.
Sender: 현재 메시지를 보낸 액터에 대한 참조.
Parent: 부모 액터에 대한 참조.
Children: 자식 액터들에 대한 참조 목록.
ActorOf: 새로운 자식 액터를 생성.
Become/Unbecome: 행동을 변경하거나 복원.

Self.Tell("Hello, Self!");

액터 설정 Props

액터를 생성하기 위한 설정 정보를 담는 객체입니다. Props는 액터의 타입, 생성 방식, 필요한 인자 등을 정의하며, 액터 시스템에서 새로운 액터 인스턴스를 만들 때 사용됩니다.

new를 통한 인스턴스 객체생성 금지.

Props props = Props.Create(() => new MyActor(..), "...");//람다형식

Props props2 = Props.Create<MyActor>();

6. 액터 계층과 감독

자식 액터 계층 (Child Actor Hierarchy)

액터는 부모-자식 관계를 통해 계층적으로 구성됩니다. 각 액터는 다른 액터를 생성할 수 있으며, 생성된 액터는 생성한 액터의 자식이 됩니다.

부모 액터: 새로운 액터를 생성한 액터로, 자식 액터의 생명주기와 일부 관리 책임을 갖습니다.
자식 액터: 부모 액터에 의해 생성된 액터로, 특정 작업을 수행하거나 부모로부터 특정 역할을 위임받아 행동합니다.

액터 계층은 트리 구조를 형성하며, 루트 액터부터 최하위 자식 액터까지 연결됩니다. 이 계층 구조는 시스템을 더 모듈화하고, 각 액터의 역할을 명확하게 정의하며, 오류를 더 잘 처리할 수 있도록 돕습니다.

감독 (Supervision)

감독은 액터 계층의 부모-자식 관계에서 발생하는 오류를 관리하는 메커니즘입니다. 감독 모델은 부모 액터가 자식 액터의 실패를 감지하고, 해당 실패를 처리하는 방식을 정의합니다. 이러한 전략을 통해, 부모 액터는 자식 액터의 오류에 대응할 수 있으며, 전체 시스템이 하나의 실패로 인해 무너지는 것을 방지할 수 있습니다.

각 액터는 부모 액터가 감독하며, 오류가 발생할 경우 이를 복구하는 데 도움을 줍니다. 계층 구조에서 부모 액터는 자식 액터의 오류를 관리합니다. 자식 액터에 예외가 발생하면 부모가 오류 메시지를 받고, 적절한 지시를 내립니다(재시작, 중지 등) 감독의 기본 전략은 "One-For-One"으로, 특정 자식에만 적용됩니다. "All-For-One" 전략은 해당 자식과 모든 형제 액터에 적용됩니다.

SupervisorStrategy를 통한 감독

부모 액터가 자식 액터의 실패(예외 발생 등)를 감지하고, 그에 따라 자식 액터를 어떻게 처리할지를 결정하는 정보를 제공합니다. OneForOneStrategy( One-For-One )또는 AllForOneStrategy( All-For-One ) 같은 전략을 설정할 수 있습니다:

OneForOneStrategy: 실패한 자식 액터에만 적용
AllForOneStrategy: 한 자식의 실패가 다른 자식들에게도 영향을 미치도록 설정

SupervisorStrategy에서 사용되는 지시문

Resume: 실패한 자식 액터를 그대로 계속 실행합니다. (예외를 무시하고 상태를 유지)
Restart: 자식 액터를 재시작합니다. (상태 초기화)
Stop: 자식 액터를 중지합니다. (액터의 생명주기 종료)
Escalate: 실패를 상위 부모에게 전달하여 처리하도록 합니다.

    public class TailCoordinatorActor : UntypedActor
    {
        protected override void OnReceive(object message)
        {
        }
        // 여기서 기본 SupervisorStrategy를 재정의하고 있습니다
        // 기본 전략은 Restart 지시문이 있는 One-For-One 전략입니다
        protected override SupervisorStrategy SupervisorStrategy()
        {
            return new OneForOneStrategy(
                10, // 최대 재시도 횟수
                TimeSpan.FromSeconds(30), // 시간 범위
                x =>
                {
                    // ArithmeticException은 애플리케이션에 치명적이지 않다고 간주할 수 있습니다
                    // 따라서 오류를 무시하고 계속 진행합니다.
                    if (x is ArithmeticException) return Directive.Resume;

                    // 복구할 수 없는 오류인 경우, 실패한 액터를 중지합니다
                    else if (x is NotSupportedException) return Directive.Stop;

                    // 그 외의 모든 경우에는, 실패한 액터를 재시작합니다
                    else return Directive.Restart;
                });
        }
    }

7. 주소로 액터 찾기 ActorSelection

ActorSelection은 Akka.NET에서 특정 액터를 직접 참조하지 않고, 경로(path)를 통해 액터를 선택하고 메시지를 전송할 수 있는 기능입니다. 이를 통해 액터 시스템 내에서 액터를 유연하게 접근하고, 동적으로 메시지를 전달할 수 있습니다. ActorSelection은 액터의 위치나 정확한 참조를 알 필요 없이 경로를 통해 액터와 통신할 수 있게 해주기 때문에, 분산 시스템이나 액터 구조가 동적으로 변화하는 환경에서 매우 유용합니다.

ActorSelection은 실제 ActorRef를 사용하는 것보다 약간의 성능 비용이 추가됩니다. 따라서 참조를 명확히 알고 있는 경우, 직접 ActorRef를 사용하는 것이 더 효율적일 수 있습니다.

ActorSelection이 생겨나게 된 이유

동적 액터 경로 접근: 액터 시스템에서는 액터가 동적으로 생성, 삭제될 수 있습니다. 특정 액터에 접근하려면 ActorRef가 필요하지만, 모든 액터의 ActorRef를 항상 가지고 있는 것은 어렵습니다. 특히, 분산된 환경에서 특정 액터의 ActorRef를 유지하는 것은 비현실적입니다.
유연한 메시지 전송: 액터 시스템에서 모든 액터의 위치를 명확히 알고 있지 않더라도, 특정 경로를 따라 액터에게 메시지를 전송할 수 있어야 합니다. ActorSelection은 이러한 요구를 충족하기 위해 설계되었습니다.
위치 투명성: 액터 시스템의 중요한 개념 중 하나는 위치 투명성입니다. 즉, 액터가 어디에 있든지 상관없이 동일한 방식으로 접근하고 통신할 수 있어야 합니다. ActorSelection은 경로 기반의 접근 방식을 통해 이 위치 투명성을 지원합니다.

ActorSelection 사용 이유

동적 참조 관리: 액터의 정확한 참조(ActorRef)를 알 필요 없이 경로를 통해 액터를 선택할 수 있습니다. 예를 들어, 자식 액터들이 동적으로 생성되거나 삭제되는 경우, 경로를 통해 유연하게 접근할 수 있습니다.
분산 시스템 지원: 분산된 액터 시스템에서 네트워크를 넘어 원격 액터에게 메시지를 보낼 때 ActorSelection이 유용합니다. 경로를 통해 원격 액터의 위치를 추상화할 수 있습니다.
유연성: 액터 구조가 고정되지 않고 동적으로 변화할 때, ActorSelection은 액터의 경로를 통해 메시지를 보내기 때문에, 구조가 변화하더라도 액터 참조를 지속적으로 관리하지 않아도 됩니다.
브로드캐스트: 특정 경로를 따라 여러 액터가 존재할 경우, ActorSelection을 사용하여 한 번에 여러 액터에게 메시지를 전송할 수 있습니다.

ActorSelection과 IActorRef의 차이점

IActorRef:

액터에 대한 고유 참조입니다.
액터를 생성할 때 반환되며, 이를 통해 해당 액터와 직접 통신할 수 있습니다.

ActorSelection:

특정 경로에 있는 하나 이상의 액터를 선택하는 메커니즘입니다.
경로를 통해 액터를 동적으로 탐색하여 접근합니다.

// 부모 액터 아래에 있는 모든 자식 액터를 선택하는 ActorSelection을 생성합니다.
var childSelection = Context.ActorSelection("/user/parent/*");

// 새로운 ChildActor를 생성하고, 그에 대한 IActorRef를 얻습니다.
IActorRef childRef = Context.ActorOf(Props.Create(() => new ChildActor()), "child1");

using Akka.Actor;

public class ParentActor : UntypedActor
{
    protected override void OnReceive(object message)
    {
        if (message is string msg && msg == "start")
        {
            // 자식 액터를 생성하고, 특정 경로에 액터를 배치
            Context.ActorOf(Props.Create(() => new ChildActor()), "child1");

            // ActorSelection을 사용하여 경로를 통해 자식 액터에 접근
            var childSelection = Context.ActorSelection("child1");

            // ActorSelection을 통해 자식 액터에 메시지 전송
            childSelection.Tell("hello from parent");
        }
    }
}

public class ChildActor : UntypedActor
{
    protected override void OnReceive(object message)
    {
        if (message is string msg)
        {
            Console.WriteLine($"ChildActor received message: {msg}");
        }
    }
}

8. 액터 라이프사이클

Akka.NET의 액터 라이프 사이클은 5단계로 구성됩니다.

액터 라이프 사이클 5단계

1. Starting (시작 중)

이 단계는 액터가 ActorSystem에 의해 초기화되는 상태입니다. 액터가 생성되고 준비되며, 메시지를 받을 준비를 하는 단계입니다.

2. Receiving (메시지 수신 중)

이 단계에서는 액터가 메시지를 받을 수 있는 상태가 됩니다. 액터의 우편함(Mailbox)에 쌓인 메시지들이 차례로 OnReceive 메서드로 전달되어 처리됩니다. 이 단계에서 액터는 주로 메시지 처리 작업을 수행합니다.

3. Stopping (중지 중)

이 단계에서는 액터가 자신의 상태를 정리하는 중입니다. 액터가 중지되는 이유에 따라 이 단계의 행동이 달라집니다:

재시작 중인 경우: 액터가 재시작될 때는, 상태나 메시지를 저장하여 재시작 후 다시 사용할 수 있도록 준비할 수 있습니다. 재시작 후에는 이전의 상태를 이어받아 다시 메시지를 처리할 준비를 합니다.
종료 중인 경우: 액터가 완전히 종료되는 경우, 우편함에 남아 있는 모든 메시지는 ActorSystem의 DeadLetters 우편함으로 보내집니다. DeadLetters는 더 이상 전달할 수 없는 메시지를 저장하는 곳으로, 보통 액터가 이미 종료된 경우에 발생합니다.

4. Terminated (종료됨)

액터가 완전히 종료된 상태입니다. 이 상태에서는 액터가 더 이상 존재하지 않으며, 해당 액터의 IActorRef로 메시지를 보내면 모두 DeadLetters로 전달됩니다. 액터는 재시작될 수 없으며, 만약 동일한 위치에 새로운 액터가 생성된다면, 새로운 IActorRef를 가지지만, 동일한 ActorPath를 가질 수 있습니다.

5. Restarting (재시작 중)

이 단계는 액터가 재시작될 때를 의미하며, 다시 Starting 상태로 돌아갑니다. 액터는 오류나 예외 발생 시 재시작될 수 있으며, 이때 기존 상태를 초기화하고 새롭게 시작합니다.

액터 생명주기 재정의 메소드

PreStart - PreStart는 액터가 메시지를 받기 전에 실행되는 초기화 로직을 넣을 수 있는 메서드입니다. 이곳에 액터의 초기 상태를 설정하거나 필요한 초기화 작업을 수행할 수 있습니다. 액터가 재시작될 때도 호출됩니다. 가장 많이 사용되는 후크 메서드입니다. 액터의 초기 상태 설정과 초기화 로직 실행에 사용됩니다. 새로운 액터가 시작될 때마다 필요한 준비 작업을 수행할 수 있습니다.
- 사용 예: 데이터베이스 연결 설정, 자원 할당, 초기 메시지 전송 등.
PreRestart - 액터가 실패하여(예: 처리되지 않은 예외 발생) 부모 액터에 의해 재시작될 때, PreRestart 메서드가 호출됩니다. 이 메서드에서는 액터가 재시작되기 전에 필요한 정리 작업을 수행하거나, 현재 처리 중인 메시지를 저장해 두어 나중에 다시 처리할 수 있도록 할 수 있습니다. 세 번째로 많이 사용되며, 재시작 전 작업이 필요할 때 사용됩니다. 예를 들어, 메시지를 임시 저장하거나 재처리를 위해 준비하는 작업을 할 수 있습니다. 액터의 작업에 따라 사용 빈도와 방법이 달라질 수 있습니다.
- 사용 예: 현재 상태 저장, 정리 작업 수행, 재시작 전 자원 해제.
PostStop - PostStop은 액터가 종료된 후 호출됩니다. 액터가 더 이상 메시지를 받지 않을 때, 정리 작업을 수행하기에 적합한 곳입니다. 액터가 종료될 때 파일 핸들이나 다른 시스템 자원을 해제해야 할 때 주로 사용됩니다. 이 메서드는 PreRestart 중에도 호출될 수 있지만, 필요에 따라 PreRestart에서 base.PreRestart를 호출하지 않아 이 동작을 피할 수 있습니다. 두 번째로 많이 사용되는 후크 메서드입니다. 액터가 종료될 때, 시스템 자원을 해제하거나 정리 작업을 수행하는 데 사용됩니다. 예를 들어, 파일 시스템 핸들 해제, 네트워크 연결 종료 등을 처리할 수 있습니다.
- 사용 예: 자원 해제, 로그 기록, 네트워크 연결 종료.
PostRestart - PostRestart는 액터가 재시작된 후 호출되며, PreRestart와 PreStart 사이에 호출됩니다. 이 메서드는 재시작의 원인이 된 오류를 추가로 분석하거나, 보고 작업을 수행하는 데 적합합니다. Akka.NET에서 기본적으로 제공하는 오류 처리 외에 추가적인 진단을 수행할 수 있는 기회입니다.
- 사용 예: 오류 원인 분석, 진단 로그 작성, 재시작 후 상태 초기화.

감독과의 관계 (Supervision)

액터가 예기치 않게 충돌하거나 예외를 던지면, 액터의 감독자(supervisor)는 자동으로 액터의 생명주기를 처음부터 다시 시작하게 만듭니다. 이 과정에서 액터의 메일박스에 남아 있는 메시지들은 유지되며, 새로 시작된 액터가 다시 처리할 수 있게 됩니다.

이 때, 부모의 감독 지시(SupervisionDirective)에 따라 액터의 행동이 결정됩니다. 부모는 자식 액터에게 종료, 재시작, 오류 무시 후 계속 작업 등의 지시를 내릴 수 있습니다. 기본 설정은 재시작이며, 이를 통해 문제가 되는 상태를 초기화하고 액터를 깨끗하게 새로 시작할 수 있게 됩니다. 재시작은 비용이 적게 들기 때문에 Akka.NET에서는 이러한 방식이 기본으로 사용됩니다.

using Akka.Actor;
using System;

public class MyActor : UntypedActor
{
    // PreStart: 액터가 시작될 때 호출됩니다.
    protected override void PreStart()
    {
        base.PreStart();
        Console.WriteLine("MyActor is starting.");
        // 초기화 작업 예: 데이터베이스 연결 설정 등
    }
    // PreRestart: 액터가 재시작되기 전에 호출됩니다.
    protected override void PreRestart(Exception reason, object message)
    {
        base.PreRestart(reason, message);
        Console.WriteLine($"MyActor is restarting due to: {reason.Message}");
        // 재시작 전 작업 예: 현재 상태 저장, 메시지 임시 저장 등
    }
    // PostStop: 액터가 종료된 후 호출됩니다.
    protected override void PostStop()
    {
        base.PostStop();
        Console.WriteLine("MyActor has stopped.");
        // 종료 후 자원 해제 예: 파일 핸들 닫기, 네트워크 연결 종료 등
    }
    // PostRestart: 액터가 재시작된 후 호출됩니다.
    protected override void PostRestart(Exception reason)
    {
        base.PostRestart(reason);
        Console.WriteLine("MyActor has restarted.");
        Console.WriteLine($"Reason for restart: {reason.Message}");
        // 재시작 후 추가 작업 예: 상태 초기화, 추가 로깅 등
    }
    // 메시지를 처리하는 메서드
    protected override void OnReceive(object message)
    {
        // 메시지 처리 로직을 여기에 작성합니다.
        Console.WriteLine($"Received message: {message}");
    }
}

참고자료

https://petabridge.com/blog/when-should-I-use-actor-selection/

When Should I Use Actor Selection?

petabridge.com

https://github.com/petabridge/akka-bootcamp

GitHub - petabridge/akka-bootcamp: Self-paced training course to learn Akka.NET fundamentals from scratch

Self-paced training course to learn Akka.NET fundamentals from scratch - petabridge/akka-bootcamp

github.com

https://github.com/akkadotnet/akka.net?tab=readme-ov-file

GitHub - akkadotnet/akka.net: Canonical actor model implementation for .NET with local + distributed actors in C# and F#.

Canonical actor model implementation for .NET with local + distributed actors in C# and F#. - akkadotnet/akka.net

github.com

https://www.youtube.com/watch?v=BzTAdSxtrq0

[AI]AI 서버의 메모리 구조와 LLM 메모리 동작 원리 (양자화 등)

usingsystem — Thu, 6 Nov 2025 20:16:57 +0900

AI와 LLM을 공부하면서 “GPU 메모리와 시스템 메모리는 각각 어떤 역할을 할까?”라는 의문이 들었다.
처음엔 단순히 처음엔 단순히 “GPU가 빠르니까 무조건 좋겠지”라고 생각했는데,
LLM 모델을 직접 다뤄보면서 이게 그렇게 간단한 게 아니라는 걸 알게 됐다.
공부하면 할수록 두 메모리의 역할이 확실히 다르다는 걸 알게 됐다.

이 글은 내가 공부하면서 직접 정리한 내용들을 중심으로,
AI 서버의 메모리 구조와 LLM이 실제로 어떻게 메모리를 사용하는지 정리한 것이다.

1. GPU 메모리(VRAM)와 시스템 메모리(RAM)의 차이

일단 간단하게 말하면,

VRAM(GPU 메모리) → 계산이 직접 일어나는 공간
RAM(시스템 메모리) → 계산을 준비하고 관리하는 공간

이렇게 구분할 수 있다.

예를 들어 이미지를 분류하는 AI 모델이 있다고 하자.
데이터를 GPU로 바로 던지는 게 아니라,
CPU에서 먼저 데이터를 읽고 가공해서 GPU로 넘긴다.
이 중간 단계에서 RAM이 역할을 한다.

RAM은 데이터를 GPU가 쓸 수 있게 ‘정리’하고 ‘보관’하는 곳이고,
VRAM은 그걸 받아서 ‘실제로 연산’을 하는 곳이다.

즉,

RAM은 일꾼에게 도구를 정리해 주는 조수 같은 역할,
GPU는 직접 망치질을 하는 기술자 같은 역할이다.

2. 학습(Training) 과정에서 메모리의 역할

모델 학습은 GPU 위에서 돌아가지만,
데이터는 보통 한 번에 다 못 올린다.
그래서 다음처럼 흐른다.

[디스크] → [RAM] → [VRAM]

하드디스크(또는 SSD)에서 데이터를 읽어 RAM에 잠시 저장해두고,
RAM에서 GPU VRAM으로 일부씩 옮겨가면서 학습을 진행한다.

이 과정을 배치(batch) 단위로 반복한다.
RAM이 넉넉하면 데이터를 미리 캐싱해둘 수 있어서
GPU가 쉴 틈 없이 계속 연산할 수 있다.

RAM이 부족하면 디스크에서 직접 데이터를 읽게 되는데,
그럼 속도가 느려지고 학습 효율이 떨어진다.

그래서 GPU만큼이나 RAM 용량도 학습 성능에 영향을 준다.

3. 추론 과정에서의 메모리 흐름

학습이 끝나고 추론을 할 때도 비슷한 구조로 움직인다.
모델이 저장되어 있는 경로에서 데이터를 읽어 GPU로 전달하는데,
그 과정이 이렇게 된다.

[Disk] → [RAM] → [VRAM] → (결과 계산) → [RAM]

즉, 모델이 처음 로드될 때는 RAM에 올라갔다가
그 다음 GPU로 전달되어 실제 연산이 이루어진다.
GPU가 결과를 계산하면 다시 CPU로 결과가 돌아오고,
RAM에서 후처리를 거쳐 사용자에게 응답을 보낸다.

이 과정에서 RAM이 적으면
모델을 불러오는 속도나 응답이 느려질 수 있다.
특히 LLM 모델처럼 용량이 큰 모델일수록 이 차이가 커진다.

4. 모델을 올릴 때 메모리가 점점 늘어나는 이유

처음 모델을 GPU에 올리면
VRAM에는 기본적으로 “모델 파라미터(가중치)”가 올라간다.
예를 들어 모델 크기가 12GB라면
기본적으로 VRAM 12GB를 차지한다.

그런데 막상 추론을 해보면 12GB 이상을 차지한다.
그 이유는 모델이 계산을 하면서
입력 텐서, 중간 연산 결과, 출력 텐서 등이
추가로 VRAM을 쓰기 때문이다.

즉,

VRAM 사용량 = 모델 파라미터 + (입력 + 중간 계산 + 출력)

이 중간 계산값들은 추론이 끝나면 사라지지만,
요청이 많거나 동시에 여러 요청을 처리할 땐
이 임시 버퍼가 겹쳐져서 VRAM이 급격히 늘어난다.

5. 직관적으로 이해하기 list 예시

이걸 조금 더 쉽게 설명하자면,
마치 list[int] 타입 변수를 만드는 것과 비슷하다.

처음엔 int 하나라서 4byte만 차지하지만,
리스트에 데이터를 추가할수록 4byte씩 계속 늘어난다.

GPU도 이와 비슷하게,
모델을 VRAM에 올려두고 추론을 계속 수행하면
임시 텐서(입력, 출력, 중간값 등)가 늘어나면서 VRAM 사용량이 점점 커진다.

물론 실제 GPU는 이렇게 단순히 선형적으로 증가하진 않지만,
개념적으로는 이렇게 생각하면 훨씬 이해하기 쉽다.

6. max_length, batch_size, torch_dtype가 메모리에 미치는 영향

VLLM을 사용하거나 모델을 로드할 때
max_length, batch_size, torch_dtype(양자화 옵션) 값을 조정하면
메모리 사용량이 눈에 띄게 달라진다.

max_length : 한 번에 처리할 최대 토큰 수 → 커질수록 VRAM 폭증
batch_size : 동시에 처리할 입력 샘플 수 → 커질수록 VRAM 크게 증가
torch_dtype : 모델 가중치 정밀도 (fp32, fp16, int8 등)

GPU는 모델을 올릴 때 단순히 가중치(weight) 만 올리는 게 아니라,
추론 중에 사용할 버퍼 공간(buffer) 도 미리 확보한다.
그래서 이런 설정값들이 VRAM 사용량에 직접적인 영향을 미친다.

7. Billion 단위 모델과 양자화(Quantization)의 이해

모델에는 3B, 8B, 16B 같은 단위가 붙는다.
여기서 B(Billion) 은 “가중치의 개수”를 뜻한다.
즉, 3B 모델은 약 30억 개의 weight를 가지고 있다는 의미다.

이제 본격적으로 양자화(Quantization) 를 살펴보자.
양자화는 단순한 압축이 아니라 정밀도(precision)를 낮춰 계산량과 메모리 사용량을 줄이는 기술이다.

딥러닝 모델은 사실상

입력 × 가중치(weight) = 출력
으로 작동하는 거대한 수치 계산기다.

그래서 가중치를 다루는 비트 수를 줄이면
모델 크기와 메모리 사용량이 함께 줄어든다.

예를 들어,
fp32 가중치는 4byte이고,
3B 모델이라면 4byte × 3,000,000,000 = 12GB를 차지한다.
하지만 GPU VRAM이 10GB밖에 없다면 로드가 불가능하다.
이럴 때 양자화를 사용하면 된다.

fp16으로 바꾸면 2byte가 되어 크기가 절반으로 줄고,
int8이면 1byte, int4면 0.5byte로 더 작아진다.

타입	크기	절감	비교

FP32	4byte	1x	가장 정확하지만 무거움
FP16	2byte	2x 감소	학습용으로 많이 사용
INT8	1byte	4x 감소	추론용으로 자주 사용
INT4	0.5byte	8x 감소	LLM 서빙용, 극단적 압축

8. 정밀도가 줄어드는데 정확도는 괜찮을까?

처음엔 “숫자를 줄이면 정확도가 떨어지는 거 아닌가?” 싶었는데,
실제로는 거의 차이가 없다고 한다.

예를 들어 0.8723151과 0.87231의 차이는
추론 결과에 거의 영향을 주지 않는다.
그래서 fp16, int8로 줄여도 결과값은 거의 동일하게 나온다.

9. 가중치는 -1 ~ 1인데, 어떻게 양자화시 int로 동작하지?

이 부분도 궁금해서 찾아봤는데,
정답은 스케일(scale) 이었다.

가중치를 일정한 스케일로 변환해서,
실제로는 0~255 같은 정수를 쓰지만
이를 실수 범위로 다시 환산해 근사값으로 계산한다.

예를 들어 아래처럼 계산된다고 한다.

scale = (float_max - float_min) / (int8_max - int8_min) = (1.0 - (-1.0)) / (127 - (-128)) = 2.0 / 255 ≈ 0.007843

이런 방식으로 int 값도 실수처럼 근사 동작하게 되는 것이다.

결국 양자화의 본질은

“모델의 수를 적은 비트로 근사 표현해서 VRAM과 계산량을 줄이는 기술”
이라고 정리할 수 있다.

10. 근데 왜 같은 7B 모델인데 크기가 다르지?

허깅페이스 같은 곳에서 모델을 보면
7B 모델인데 어떤 건 13GB, 어떤 건 20GB다.

앞에서 B과 모델 크기는 7B에 flaut32일 경우 28GB에 해당할 것 이다.
이건 단순히 파라미터 수가 같다고 해서 크기도 같지 않기 때문이다.

이유는 크게 두 가지다.

저장 포맷의 차이 — .safetensors, .gguf 등 저장 방식이 다르다.
구조적 요소의 차이 — 레이어 개수, hidden size, embedding 구조 등이 모델마다 다르다.

또한 모델 파일에는 weight 외에도

옵티마이저 상태
학습 통계 (running mean, variance)
토크나이저 정보
메타데이터(config, dtype, version 등)
이런 정보들이 함께 포함되기 때문에 실제 크기는 달라질 수 있다.

[NetWork] 기업에서 VPN과 ACL를 사용하는 이유

usingsystem — Tue, 5 Aug 2025 16:33:24 +0900

VPN(Virtual Private Network)란?

VPN은 공용 네트워크(예: 인터넷)를 통해 사설 네트워크에 안전하게 접속할 수 있도록 하는 암호화된 터널로 인터넷을 통해도 내부망처럼 동작가능합니다 이런 동작이 가능한 이유는 IP마스킹을 통해 사용자 IP를 숨기고 사내망 IP로 대체 하기 때문입니다.
즉 VPN은 인증된 사용자만 원격 접속을 가능하게 하는 고급 암호화 및 인증 기법입니다.

기업에서 VPN을 사용하는 이유는 보통 원격 근무 지원, 보안 통신, 내부망 리소스 접근 제어, 지사 간 통신 보안 확보를 위해 사용됩니다.

사용 목적	설명
원격 근무 지원	외부 직원이 사내망에 안전하게 접속 가능
보안 통신	내부 시스템이나 파일 서버 접속 시 데이터 보호
내부망 리소스 접근 제어	VPN을 통해서만 접근 가능한 시스템 구성 가능
지사 간 통신 보안 확보	본사와 지사, 협력사 간 안전한 데이터 송수신 가능

ACL이란?

네트워크 트래픽의 접근을 제어하기 위한 목적으로 방화벽 등에서 특정 IP주소 포트 등에 대해 접근을 허용 또는 차단하는 규칙을 설정할 수 있습니다.
즉 라우터나 방화벽등을 설정해서 접근을 제어합니다.

기업에서 ACL을 사용하는 이유는 보안 강화, 서비스 분리, 악성 트래픽 대응, 네트워크 성능 최적화가 있습니다.

사용 목적	설명
보안 강화	외부에서 내부 시스템으로의 비인가 접근을 차단
서비스 분리	각 부서별로 서버나 서비스 접근을 제한 (예: 인사팀만 인사DB 접근 허용)
DDoS/악성 트래픽 대응	악성 IP나 특정 포트 트래픽을 즉시 차단 가능
네트워크 성능 최적화	불필요한 트래픽을 차단하여 리소스 낭비 방지

VPN + ACL을 사용한다면?

많은 기업은 ACL + VPN을 조합하여 이중 보안 체계를 운영합니다.

VPN을 통해 먼저 인증 → 내부 네트워크로 접근 허용
ACL을 통해 접근 권한 세분화 → 특정 리소스만 접근 가능

EX)
1. 외부망으로 VPN 접속 -> ACL권한에 따라 인사팀만 인사 DB 접근 허용
2. 외부망으로 VPN 접속 -> ACL권한에 따라 특정 IP나 Port만 접근할 수 있게 허용

발자취

[AI] 딥러닝 개념정리

1. 신경망(Neural Network)과 딥러닝

1) Neural Network 훈련의 핵심 방법

(1) 손실함수

(2) Backpropagation (오차 역전파)

(3) Gradient Descent (경사하강법)

2) 경사하강법안에 Global Minimum, Learning Rate, Optimizer

(1) Global Minimum: 손실 함수의 최종 목표( 경사하강법의 목적지)

(2) Learning Rate: 파라미터 업데이트 크기 (경사하강법의 한 걸음 크기)

(3) Optimizer: 파라미터를 어떻게 업데이트할 것인가 (경사하강법의 내려가는 방법)

(4) 세 개념의 관계 정리

2. Hyper-parameter와 과적합 방지 기법

1) epoch

2) Dropout regularization

3. CNN(Convolutional neural network) - 합성곱 신경망

1) Convolutionnal Lyaer(합성곱층)

2) Pooling Layer(풀링층)

3) CNN의 기초가 되는 LeNet-5

4) Transfer Learning (전이학습)

4. RNN(Recurrent Neural Network)

5. Autoencoder

6. GAN(Generative adversarial network)

[AI] Apache Spark 개념정리

1. Apache Spark 개념 및 특징 정리

2. Spark 아키텍처

3. RDD (Resilient Distributed Dataset)

4. Key Value Pair 명령

spark는 yeild와 궁합이 좋다.

map vs flatMap

5. 데이타프레임(Dataframe)과 SparkSQL

1) 데이터프레임(DataFrame) 이란?

DataFrame의 특징

2) Spark SQL 이란?

6. Dataframe StructType

7. BrodCast와 BroadCast 조인

8. coalesce와 repartition

1) coalesce

2) repartition

9. 빈 데이터와 시간 포멧 다루는 방법

10. YARN (Yet Another Resource Negotiator) 이란?

11. Dataframe의 API 카테고리

1) Transformations

(1) Narrow Dependency(좁은 의존성) 과 Wide Dependency(넓은 의존성)

2) Actions

12. Logical Plan (논리적 실행 계획)과 Physical Plan (물리적 실행 계획)

1) Logicl Plan

2) Physical Plan

13. Spark Memory Allocation

1) Executor Memory

(1) Execution Memory(Handle Computations)

(2) Storage Memory(Caching)

(3) User Memory

2) Driver Memory

14. AQE(Adaptive Query Execution)

15. DPP (Dynamic Partition Pruning)

16. Spark Cache(재사용)

17. sql hint(강제 주입)

18. Accumulator(디버깅)

19. Speculative execution

20. Job Scheduling

1) FIFO(First-In First-Out) — 기본 스케줄러

2) FAIR Scheduler — 공정 스케줄링 (협업 환경에서 많이 씀)

21. Spark Streming

장애 발생 시

1) ouputmode

2) Window & Watermark

3) Streaming Fault Tolerance란?

4) Stateless와 stateful

5) streaming join

(1) streaming dataframe -> static dataframe ( Stream–Batch )

2) streaming dataframe -> streaming dataframe ( Stream-Stream )

22. Spark MLlib

1) 알고리즘

2) Feature Engineering

3) Pipeline

[AI] 전통적인 ML 개념정리

목차

1. 머신러닝 역사 & 기본 개념

2. 머신러닝의 종류