dh_0e

[Cloud] K8s 요청 처리 단계, Service Account

dh_0e — Mon, 8 Jun 2026 11:00:43 +0900

Kubernetes API Server의 요청 처리 3단계

Authentication(인증 - 사용자 식별): HTTP 요청을 검사하여 메시지를 보낸 주체가 누구인지 식별
- SSO 시스템이나 인증서 등을 통해 확인하며, 미리 구성된 인프라를 활용함 (Authenticator App)
Authorization(권한 부여 - 권한 확인): 인증된 사용자가 요청한 리소스에 대해 해당 작업(R/W/D 등)을 수행할 권한이 있는지 확인
Admission Control(승인 제어 - 유효성 검사 및 수락): 리소스 생성/수정/삭제 요청 시, 컨텐츠(Spec)에 잘못된 부분은 없는지 확인하고, 필요시 수정함
- 이러한 플러그인은 여러 개 설치할 수 있으며, 요청은 모든 플러그인을 거쳐야 함
- ex) "Pod 만드는데 CPU 10,000개 할당해 줘" 같은 무리한 요청이 들어오면 거절

Admission Control Plugins 종류

Service Account

Service account: Pod가 API 서버와 통신하기 위해 사용하는 계정으로 요청 처리 과정 전반에 걸쳐 사용됨
- API 서버에 접속하는 클라이언트는 실제 사람(Human)과 내부 Pod로 나뉨

Pod가 만들어지면 특정 Service Account와 연결되며, Pod는 이 계정의 토큰을 사용해 API 서버와 통신함
Pod 생성 시 계정을 따로 지정하지 않으면 해당 namespace의 기본 Service Account가 자동으로 부여됨
- 위 사진에 나와있듯이, 다른 namespace의 Service Account에 연결할 수 없음
이를 통해 각 Pod가 어떤 리소스에 접근할 수 있는지 제어할 수 있음

Example of Service Account Using in Pod YAML

Authorization & RBAC (역할 기반 접근 제어)

A리소스만 접근 가능한 것을 Role로 확인

K8s는 권한을 관리하기 위해 RBAC 플러그인을 주로 사용하여 Service Account에 권한을 적용함
RBAC(Role Based Access Control): HTTP 메서드에 따라 동사(get, list, create, update 등) 단위로 권한을 나누어 줌
- Role(역할): 어떤 리소스에 대해 어떤 작업을 할 수 있는지 정의한 권한의 집합
  - ex) 특정 리소스 A만 조회 가능
- Role Binding(역할 바인딩): 만들어둔 Role을 외부 사용자(User)나 Pod의 계정(Service Account)에 연결(적용)해주는 객체
- ClusterRoleBinding: 특정 namespace를 넘어, Cluster 전체 범위에 Role을 바인딩하는 것

HTTP 메소드

ex) Role YAML file

service라는 리소스를 조회(get, list)할 수 있는 권한을 가진 Role

이러한 Role과 Role Binding을 통해, 특정 namespace나 리소스에 대한 접근 권한을 제어하여 결과적으로 사용자의 kubectl 명령어 실행 권한을 부여하거나 해제할 수 있음
- kubectl 명령어도 결국 http 요청이기 때문
위와 같이 Role을 만든 뒤, 아래와 같이 'kind: RoleBinding' YAML 파일을 따로 작성해서 service-reader와 연결해줘야 함

# Service Account 생성
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa      # 신분증 이름
  namespace: foo       # 아까 Role이 있던 namespace와 동일하게 맞춤
  
# RoleBinding 생성
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-services-binding  # 이 바인딩 규칙의 이름
  namespace: foo
subjects:                     # 1. 누구에게 권한을 줄 것인가? (대상)
- kind: ServiceAccount        # 대상의 종류는 ServiceAccount!
  name: my-app-sa             # 방금 위에서 만든 그 신분증!
  namespace: foo
roleRef:                      # 2. 어떤 권한을 줄 것인가? (참조할 Role)
  kind: Role                  # 연결할 대상은 Role!
  name: service-reader        # 아까 사진에서 만든 그 권한(Role) 이름!
  apiGroup: rbac.authorization.k8s.io

"Service account(Pod)에 Role(Resources 사용 권한)을 붙여주는 것이 Role binding이다."

[Cloud] Service Routing & Pod Networking (CNI Plugin)

dh_0e — Sun, 7 Jun 2026 22:53:51 +0900

Service & Endpoints

Endpoints로 로드 밸런싱 효과를 얻을 수 있음

ClusterIP(Frontend): 쿠버네티스 내부에서만 사용하는 가상의 IP 주소
Backend pool: 서비스 조건(Pod Selector)에 들어맞는 실제 파드들의 묶음
Endpoints
- 서비스가 생성될 때 쿠버네티스가 자동으로 만들어주는 객체 (Master Node 안에 존재)
- 트래픽을 넘겨받을 '실제 파드들의 IP 주소 목록'을 보관함
Endpoints Controller: 파드들의 상태(Ready condition)를 지속적으로 감시하여, 트래픽을 받을 준비가 된 건강한 Pod들의 IP 목록만을 Endpoints 객체에 최신 상태로 유지해 주는 관리자 역할

Q: Master Node 내부의 endpoints에는 private 주소가 담겨있는데, 어떻게 이것만 보고 Pod를 찾아갈 수 있는지? 라우터가 있는 건지?
A: Master Node는 Endpoints라는 주소록 데이터만 보관하고 있을 뿐, 실제로 Pod를 찾아가서 트래픽을 꽂아주진 않음. 라우터 역할을 실질적으로 수행하는 것은 각 노드(Worker Node 포함)에 설치된 Kube-proxy와 CNI 플러그인(Calico, Cilium 등)으로 다음과 같은 순서로 패킷을 전달함
1. Master Node 안에서 동작하는 Endpoint Controller가 Pod들의 상태를 감시하며 건강한 Pod들의 Private IP 목록을 수집하여 Endpoints라는 객체로 만들고 API 서버에 저장
2. 클러스터를 구성하는 모든 노드에는 Kube-proxy라는 에이전트가 항상 실행되고 있음. 이 kube-proxy들이 API 서버를 계속 보고 있다가, Endpoints가 업데이트되면 그 정보를 자기 노드로 가져옴
  - kube-proxy는 자기가 속한 노드의 리눅스 커널에 다음과 같은 규칙을 작성
  - "클라이언트가 Service IP로 요청을 보내면, 방금 Master Node에서 받아온 Pod의 Private IP(Endpoints) 중 하나로 목적지를 바꿔라"
3. CNI는 BGP 라우팅 프로토콜을 사용해 노드끼리 본인 노드의 Pod 대역을 알려주며 경로를 서로 학습하게 만들거나, VXLAN 같은 캡슐화/터널링 기술을 써서 Private IP 패킷을 실제 물리 노드의 IP 패킷으로 감싸서 안전하게 다른 노드로 배달해 줌
  - 각 노드에 존재하는 CNI(Container Network Interface) 플러그인은 Pod 네트워크를 구성하고 라우팅 경로를 전파하는 등, 실질적인 라우터와 네트워크 스위치의 역할을 수행함

Kube-proxy

정의: 클러스터의 모든 노드에서 실행되는 네트워크 에이전트
- 현재는 거의 CNI 플러그인에 대체됨
3가지 작동 모드를 지원함

1. Iptables 모드 (기본값)

IPtables mode

Kube-proxy의 기본 동작 모드로, 리눅스 커널의 NAT(DNAT) 기능을 활용함
DNAT(목적지 주소 변환): 클라이언트가 패킷을 ClusterIP로 보내면, iptables 규칙이 그 패킷의 목적지 IP를 서비스 IP에서 실제 Pod의 IP로 바꿔치기하여 전달 (하단 그림 참고)
- NodePort나 LoadBalancer 방식도 포트 번호를 기준으로 비슷한 규칙을 사용함

NodePort and LoadBalancer

성능 한계
- 클러스터 내의 서비스(Pod) 개수가 늘어날수록 iptables 규칙 목록도 선형적으로 길어져 성능이 저하됨
- 업데이트가 발생할 때마다 전체 테이블을 새로 덮어써야 해서 시간이 오래 걸림

2. IPVS(IP Virtual Server) 모드

IPVS mode

리눅스 커널에 내장된 고급 로드밸런싱 기술
리스트를 위에서부터 훑어보는 iptables와 달리 해시 테이블을 사용하여 목적지 Pod를 즉시 찾아내기 때문에 대규모 환경에서도 속도가 매우 빠름
Service IP 주소(key) : 목적지 Pod 주소 (value)

3. Userspace(CNI를 통한 완전 대체)

최신 트렌드에서는 Kube-proxy 자체를 아예 빼버리고, Cilium 같은 고급 CNI 플러그인이 라우팅을 직접 통제하기도 함
- Cilium: 리눅스 커널의 강력한 도구인 eBPF를 사용하여 데이터 플레인 수준에서 트래픽을 처리하며, 이 역시 해시 테이블을 사용해 초고속으로 endpoints를 찾아냄

K8S Networking Considerations

K8s의 모든 Pod들은 NAT 없이 단일 네트워크처럼 작동하게끔 함
Pod 간 통신을 위해 구성해야 할 5가지 핵심 요소가 있음

1. IPAM(IP Address Management): 클러스터 내부의 Pod들에 IP를 할당하는 메커니즘

클러스터를 초기화할 때 전체 IP 대역(CIDR)을 설정하며, 개별 노드는 이 전체 대역 중 일부(기본적으로 /24 크기)를 쪼개어 할당받아 사용
- CIDR(Classless Inter-Domain Routing): 유연하게 IP 주소를 할당하고 관리하기 위해 사용되는 표준 IP 주소 표기 및 분류 방식 ("IP 주소/서브넷 마스크"로 표기하는 분류 방식)

IPAM example

2. Routing Protocol: 파드의 IP 주소 간 트래픽이 올바르게 전달되도록 라우팅 경로를 전파

대표적으로 BGP가 사용되며, 이를 통해 호스트 커널의 라우팅 테이블이 업데이트됨
- BGP(Border Gateway Protocol)
  - 일반적으로 사용되는 네트워크 프로토콜로 Calico에서 사용됨
  - 커널 라우팅 테이블을 수정하여 각 잠재적 워크로드에 대한 경로를 포함함

Calico에서 사용되는 BGP 및 라우팅 테이블

주의) IPAM example 사진과 CIDR IP가 다름

3. 캡슐화와 터널링 (Encapsulation and Tunneling)

K8s 내부 네트워크와 실제 물리 네트워크를 분리하기 위한 기술
출발지/도착지 Pod IP가 적힌 패킷을 실제 호스트 노드의 IP 패킷으로 감싸서 전송하며, k8s CNI에서는 여러 프로토콜(VXLAN, Geneve, GRE) 중 VXLAN 프로토콜이 가장 널리 쓰임

K8s 패킷 구조

4. 워크로드 라우팅 (Workload Routability)

외부 클라이언트가 클러스터 내부망에 있는 Pod에 접근할 수 있게 해주는 Service Routing 메커니즘
주로 Ingress Controller나 Load Balancer를 통해 외부 트래픽을 받아 내부 Pod로 연결해 줌

Ingress Controller 사용 예시

5. 네트워크 정책 (Network Policy)

Pod로 들어오거나(Ingress) 나가는(Egress) 트래픽의 허용 여부를 정의하는 방화벽 역할
- AWS의 인바운드/아웃바운드 규칙과 유사

podSelector: {} (적용 대상)
- 비어있는 것은 이 네임스페이스의 모든 Pod에 적용된다는 뜻
ingress: (들어오는 트래픽 - Inbound)
- 정의된 IP 범위, protocol로 port에서 들어오는 트래픽 등을 허용
egress: (나가는 트래픽 - Outbound)
- 정의된 namespace, label, protocol로 port의 워크로드로 전송되는 트래픽을 제한함

기본 k8s 방화벽은 너무 원시적이라, IP가 자주 바뀌는 외부 API 통신이나 복잡한 L7 제어나 거대한 클러스터 관리가 어려움
Calico나 Cilium이 제공하는 독자적인 고급 NetworkPolicy 기능을 써야 함
1. Complex condition evaluation (복잡한 조건 평가)
  - 기본 K8s: "A 파드가 B 파드로 가는 것 허용"처럼 아주 단순한 AND 조건 정도만 가능
  - CNI 고급 기능: 훨씬 복잡한 논리를 짤 수 있음
    - ex) "A 파드이면서 동시에 B 라벨이 없고, 트래픽이 평일 업무 시간에만 발생할 경우 허용(OR, NOT 조건 등 활용)" 같은 세밀하고 복잡한 조건을 걸어 방화벽을 통제 가능
2. Resolution of IPs based on DNS records (DNS 레코드 기반 IP 해석)
  - 기본 K8s: 외부로 나가는 트래픽(Egress)을 제어할 때, 고정된 IP 주소(CIDR)로만 허용/차단 목록을 만들 수 있음
    - (예: 142.250.190.46 접속 허용)
  - CNI 고급 기능: IP 대신 도메인 이름(DNS)을 통과 조건으로 쓸 수 있음 (예: *.google.com 접속 허용)
    - 외부 클라우드 서비스나 API들은 IP가 수시로 바뀌기 때문에, 실무에서는 IP를 직접 입력하는 대신 도메인 기반 정책이 반드시 필요함
3. L7 rules (host, path, etc.) (L7 애플리케이션 계층 규칙)
  - 기본 K8s: L3/L4 계층인 IP와 Port(예: TCP 80번 포트)만 보고 트래픽을 통제하기 때문에, 패킷 안에 무슨 데이터가 들었는지는 모름
  - CNI 고급 기능: 패킷의 속을 까서 HTTP 통신(L7 계층)의 내용까지 보고 통제
    - ex) 같은 웹 서버(TCP 80)로 가는 요청이더라도, GET /api/v1/users (조회)는 허용하지만 POST /api/v1/users (생성/수정)는 차단하는 식으로 훨씬 정교한 통제가 가능해짐
4. Cluster-wide policy (클러스터 전역 정책)
  - 기본 K8s: 네트워크 정책은 철저하게 네임스페이스(Namespace) 단위로만 갇혀 있음
    - 만약 "모든 파드는 사내 보안망을 거쳐야 한다"라는 규칙을 만들려면, 클러스터에 네임스페이스가 100개 있으면 똑같은 정책 파일을 100번 복사해서 일일이 다 넣어줘야 함
  - CNI 고급 기능: 'GlobalNetworkPolicy' 같은 기능을 제공하여, 클러스터 전체에 한 번만 딱 적용하면 모든 네임스페이스가 일괄적으로 따르도록 통제할 수 있어 관리자의 수고를 덜어줌

CNI Plugin

Pod 간 네트워크 통신을 담당하는 소프트웨어
Cluster 안에 있는 어떤 Pod던지 간에 직접 통신을 할 수 있게끔 Pod에 주소를 주고, Routing table을 업데이트 해줌

[C++] Class vs Struct (+friend), static_cast, RTTI, vector, inline 함수, virtual, wchar/wstring

dh_0e — Sat, 6 Jun 2026 21:48:55 +0900

Class vs Struct

Class와 Struct의 가장 큰 차이는 기본 접근 제어자
- Class는 접근 지시자를 생략했을 때 기본 접근 지시자가 private, Struct는 public임 (생각해 보면 당연한)
struct를 쓰는 경우 (Plain Old Data, POD):
- 멤버 변수만 모아둔 데이터 전송 객체(DTO) 일 때
- 별도의 로직(함수)이 거의 없고 단순히 값을 묶어서 전달할 때
  - ex) Point { int x, y; }, Rect { int w, h; }
class를 쓰는 경우:
- 내부에 복잡한 로직이나 함수가 들어갈 때
- 상속이나 다형성(Virtual function)을 활용할 때
- private 변수를 두고 public 메서드로 접근을 제어(캡슐화) 해야 할 때
C++는 Java처럼 접근 지시자의 종류가 4가지가 아니라 default를 뺀 3가지(public, private, protected)
default 느낌을 사용하고 싶으면 friend를 사용하여야 함
- friend: 특정 외부 함수나 클래스에게 자신의 private 및 protected 멤버에 접근할 수 있는 권한을 부여
  - 일방향성 (Not Mutual): A가 B를 friend로 선언했다고 해서, A가 B의 비밀번호를 알 수 있는 건 아니며, B도 A를 friend로 선언해 줘야 서로 공유가 가능
  - 전이되지 않음 (Not Transitive): A가 B의 친구고, B가 C의 친구라고 해서 A가 C의 private 멤버에 접근할 수 없음
  - 상속되지 않음 (Not Inherited): 부모의 친구라고 해서 자식인 클래스와도 친구인 것은 아님

#include <iostream>

// ==========================================
// 1. 일방향성 (Not Mutual)
// ==========================================
class Mutual_A {
private:
    int secretA = 10;
    friend class Mutual_B; // B에게 내(A) 비밀을 볼 수 있는 권한 부여
};

class Mutual_B {
private:
    int secretB = 20;

public:
    void ShowA(Mutual_A& a) {
        // [성공] B는 A의 friend이므로 A의 private 접근 가능
        std::cout << "[일방향성] A의 비밀: " << a.secretA << std::endl; 
    }
    
    // 만약 Mutual_A 클래스에서 Mutual_B의 secretB에 접근하려 한다면?
    // ❌ 컴파일 에러 발생! B는 A를 friend로 선언한 적이 없기 때문
};

// ==========================================
// 2. 전이되지 않음 (Not Transitive)
// ==========================================
class Trans_A {
private:
    int secretA = 100;
    friend class Trans_B; // B를 친구로 인정
};

class Trans_B {
private:
    friend class Trans_C; // C를 친구로 인정
};

class Trans_C {
public:
    void TryAccessA(Trans_A& a) {
        // ❌ [컴파일 에러] 
        // C는 B의 친구일 뿐, A의 친구가 아니므로 A의 private 접근 불가
        std::cout << a.secretA << std::endl; 
    }
};

// ==========================================
// 3. 상속되지 않음 (Not Inherited)
// ==========================================
class Parent {
private:
    int parentSecret = 111;
    friend class Uncle; // Uncle(아저씨)을 부모의 친구로 인정
};

class Child : public Parent {
private:
    int childSecret = 222; // 자식만의 비밀
};

class Uncle {
public:
    void CheckSecrets(Parent& p, Child& c) {
        // [성공] 부모의 친구니까 부모의 private 접근 가능
        std::cout << "[비상속성] 부모의 비밀: " << p.parentSecret << std::endl; 

        // ❌ [컴파일 에러] 
        // 부모의 친구라고 해서 자식의 private까지 접근할 수는 없음
        // std::cout << "자식의 비밀: " << c.childSecret << std::endl; 
    }
};

// ==========================================
// 메인 함수 실행
// ==========================================
int main() {
    // 1. 일방향성 테스트
    Mutual_A mA;
    Mutual_B mB;
    mB.ShowA(mA);

    // 3. 상속성 테스트
    Parent p;
    Child c;
    Uncle u;
    u.CheckSecrets(p, c);

    return 0;
}

static_cast의 역할

C++에서 C 스타일의 강제 형변환은 매우 위험할 수 있음
static_cast
- 명시적 형변환: "데이터가 잘릴 가능성이 있다는 거 나도 알고 있어. 그래도 내 의도대로 타입을 바꿔줘."라고 명시하는 것
- 경고 제거: 컴파일러의 "데이터 손실 위험" 경고를 깔끔하게 없애줌
- 컴파일 타임 체크: C 스타일의 강제 형변환(ex: (int32)size)보다 훨씬 안전함
  - 서로 아예 관련 없는 타입(예: 포인터를 정수로 바꾸는 등)으로 변환하려고 하면 컴파일러가 에러를 뱉어 런타임 에러를 방지함

lockId = static_cast<int32>(_nameTold.size());
// _nameTold가 unordered_map이라면, _nameTold.size()를 호출했을 때 반환되는 값의 타입은 size_t
// 64비트 시스템에서 size_t(8바이트)를 int32(4바이트)로 변환

size_t: 보통 64비트 시스템에서 8바이트(64비트) 부호 없는 정수
int32: 이름 그대로 4바이트(32비트) 부호 있는 정수
원래는 큰 바구니(size_t)에 담긴 물건을 작은 바구니(int32)로 옮기려고 하니, 컴파일러 입장에서는 "야, 이거 데이터 넘쳐서 잘릴 수도 있는데 괜찮겠어?"라고 경고(Warning)를 보냄
- static_cast를 사용하면 명시적인 형변환을 통해 경고를 합리적으로 잠재우는 역할을 함

RTTI (Run-Time Type Information)

프로그램이 실행 중(Run-Time)에 객체의 실제 데이터 타입 정보를 알아내는 메커니즘
- C++은 기본적으로 컴파일 타임에 모든 타입을 결정짓지만, 객체 지향의 다형성으로 인해 런타임에 객체의 실제 데이터 타입을 알아내기 힘들 수 있음

1. typeid 연산자

객체의 정확한 타입 정보를 담고 있는 type_info 객체를 반환
주로 객체의 실제 클래스 이름을 출력하거나, 두 객체가 같은 타입인지 비교할 때 사용
'typeinfo' 헤더 필요

#include <iostream>
#include <typeinfo> // typeid를 사용하기 위해 필요

class Parent { public: virtual ~Parent() {} };
class Child : public Parent {};

int main() {
    Parent* p = new Child();
    
    // 포인터 자체의 타입은 Parent*
    std::cout << typeid(p).name() << std::endl;  
    
    // 포인터가 가리키는 실제 알맹이의 타입은 Child
    std::cout << typeid(*p).name() << std::endl; 
    
    if (typeid(*p) == typeid(Child)) {
        std::cout << "이 객체의 진짜 정체는 Child입니다!" << std::endl;
    }
    
    delete p;
    return 0;
}

2. dynamic_cast

static_cast가 컴파일 타임에 억지로 형변환을 한다면, dynamic_cast는 실행 시점(Run-Time)에 안전하게 형변환을 시도
만약 부모 포인터가 가리키는 객체가 내가 원하는 자식 타입이 맞다면 변환된 포인터를 주고, 아니라면 nullptr 반환

Parent* p1 = new ChildA();
Parent* p2 = new ChildB();

// p1이 가리키는 객체가 ChildA가 맞는지 확인하면서 캐스팅
if (ChildA* childA = dynamic_cast<ChildA*>(p1)) {
    childA->SpecialSkillA(); // ChildA만 가진 고유 스킬 사용
} else {
    std::cout << "ChildA가 아닙니다." << std::endl;
}

RTTI는 꼭 필요할 때(외부 라이브러리의 객체를 판별해야 하거나, 특정 자식 객체만의 고유한 이벤트를 반드시 강제 호출해야 할 때)만 제한적으로 사용하는 것이 좋다.

Vector 초기화와 안전한 접근

초기화 방법: vector<int> vec(10, -1); (크기 10, 모든 원소를 -1로 초기화)
안전한 포인터 반환: v.data();
- &v[0]: 만약 벡터가 비어있다면(empty), 0번째 원소가 존재하지 않으므로 에러(정의되지 않은 동작)가 발생할 수 있음
- v.data(): 벡터가 비어있어도 함수 호출 자체가 안전하며, nullptr을 반환해 줌 (현대적이고 안전한 방식)

inline (인라인 함수)

컴퓨터가 함수를 실행할 때 보통은 함수가 있는 메모리 주소로 점프했다가, 실행이 끝나면 다시 돌아오는 과정을 거침
- 하지만 inline을 붙이면 컴파일러가 함수를 호출하는 대신, 함수의 내용물을 호출하는 자리에 그대로 복사해서 붙여 넣어 버림

inline void Set(T* ptr) { ... }

"이 함수는 반환값이 없고(void), 아주 짧아서 호출하는 곳에 코드를 직접 박아 넣는 방식(inline)으로 최적화하겠다"는 선언

장점
- 함수 호출 오버헤드가 사라짐: void f(){ _ptr = ptr; }처럼 한두 줄밖에 없는 아주 짧은 함수들은 호출하는 시간보다 코드 한 줄 실행하는 시간이 더 짧기 때문에 인라인화 하는 게 성능 최적화에 유리함
- 헤더 파일 정의: 헤더(*.h) 파일에 함수를 직접 구현할 때 inline을 붙이면, 여러 소스 파일에서 include 하더라도 중복 정의 에러를 방지할 수 있음
컴파일러의 판단: 요즘 똑똑한 컴파일러들은 inline을 안 써도 알아서 처리해주기도 하지만, 개발자가 "이건 진짜 짧으니까 무조건 인라인으로 해줘!"라고 힌트를 주는 역할을 함

Virtual 소멸자

virtual: "실행 시점(Runtime)에 진짜 정체가 무엇인지 확인하고 동작하라"는 명령
C++에서 상속 관계를 다룰 때 부모 클래스의 소멸자에 virtual을 붙이는 것은 선택이 아닌 필수에 가까움
- 정적 바인딩 (Static Binding): 컴파일러가 소스 코드를 보고 "포인터 타입이 Parent네? 그럼 Parent 함수를 실행해!"라고 결정하는 것 (virtual이 없을 때의 기본 동작)
  - virtual이 없으면 컴파일러는 포인터 타입만 보고 부모의 소멸자만 호출 (자식 객체의 메모리는 누수됨)
- 동적 바인딩 (Dynamic Binding): 프로그램이 실행 중일 때 "포인터는 Parent지만, 실제 가리키는 알맹이는 Child네? 그럼 Child 함수를 실행해야지!"라고 결정하는 것 (virtual을 붙였을 때 동작)
  - virtual을 붙이면 실행 시점에 가상 함수 테이블(VTable)을 확인하여 실제 객체의 타입(Child)에 맞는 소멸자를 찾아 호출함

class Parent {
public:
    ~Parent() { cout << "~Parent()" << endl; }
};

class Child : public Parent {
public:
    int* data = new int[100]; // 자식만 가진 자원
    ~Child() { 
        delete[] data; 
        cout << "~Child()" << endl; 
    }
};

// 사용 예시
Parent* p = new Child();
delete p;

실행 결과: ~Parent()만 호출되고 끝
문제점: Child 객체의 메모리는 할당되었는데, ~Child() 소멸자가 호출되지 않아 내부의 data 메모리가 해제되지 않아 메모리 누수 발생
해결 방법: ~Parent()에 virtual 추가 (virtual ~Parent() { ... } )
1. 가상 함수 테이블 확인
2. ~Child() 호출
3. ~Parent() 자동 호출
  - C++의 기본 객체 파괴 규칙에 따라 부모의 소멸자가 자동으로 이어서 호출됨

char vs wchar, string vs wstring

char / string: 1바이트 기반의 문자열 (ASCII 등)
wchar_t / wstring: Wide Character의 약자로, 보통 2바이트 이상을 사용하여 유니코드(다국어)를 표현할 때 사용
- Windows API나 게임 개발에서 한글 처리를 위해 자주 쓰임

[Cloud] Pod(Application) Update 종류 및 실습

dh_0e — Wed, 3 Jun 2026 18:14:17 +0900

무중단 Update 종류

Blue Green Update: 구버전(Blue)과 신버전(Green)을 나란히 배포하고 신버전으로 일제히 전환하는 방법
Canary Update: 지정한 서버 혹은 특정 사용자에게만 새로운 버전으로 업데이트를 시켰다가 정상적인 동작을 확인한 후에 전체를 업데이트하는 방법
Rolling Update: 전체를 무중단으로 업데이트하는 방법
- 새로운 이미지의 컨테이너가 배포된 Pod는 점진적으로 추가
- 이전 이미지의 컨테이너가 배포된 Pod는 점진적으로 삭제

Blue Green Update

구버전(Blue)과 신버전(Green)

Load Balancer: 트래픽 분산 처리기
장점: 빠른 Rollback(예전 버전으로 돌아가는 것)이 가능하며 버전관리가 용이
단점: 시스템 자원이 두 배로 필요
- 옛날 버전을 얼마나 붙들고 있는지가 중요
  ex) 에러 나면 롤백해야 되기 때문에, 근데 그냥 갖고 있기는 비용이 나감

실습 예시

Endpoints 구성 방식을 확인
- 실제 최종 End Pod의 IP 주소가 나와있음

Node 껐다 켜면 IP 주소 바뀜
- Controller manager가 바꿔줌

Canary Update

소수의 사용자(10%)만 장애를 느낄 수 있음
- 로드 밸런서 기능을 설정하여 관리자만 10%로 빠지게 만들 수 있음
장점
- 위험을 빠르게 감지할 수 있는 배포전략
- 트래픽 일부를 신버전으로 분산하여 오류 확인이 가능

실습 예시

Rolling Update

무중단 배포 방식: 서비스 접속자의 연결을 끊지 않고, 구 버전 Pod를 하나씩 죽이면서 동시에 새 버전 Pod를 띄워 자연스럽게 교체하는 k8s의 기본 업데이트 전략
배포 조건: Deployment의 Pod 템플릿 정보가 변경될 때 자동으로 트리거 됨
- 가장 흔한 사례: 컨테이너의 이미지 버전을 변경할 때

// 이미지 버전을 nginx:1.19로 바꾸면 롤링 업데이트가 즉시 시작됨
kubectl set image deployment/my-app my-app=nginx:1.19

업데이트 상태 제어: 롤링 업데이트는 진행 속도나 상태를 명령어로 직접 제어 가능
- 잠깐 멈춤(Pause): 업데이트를 진행하다가 새 버전에 에러가 발생하는 등의 이유로 Pod 교체를 멈춰야 할 때 사용
- 다시 시작(Resume): 문제없음을 확인하고 남은 Pod들도 마저 교체하라고 명령할 때 사용
- 이전으로 되돌리기(Undo): 새 버전에 심각한 버그가 있어서 아예 업데이트 전의 구 버전으로 롤백할 때 사용

kubectl rollout pause deployment/my-app		// Pause
kubectl rollout resume deployment/my-app 	// Resume
kubectl rollout undo deployment/my-app 		// Undo

Rolling Update Scenario

Rolling Update Scenario 1/2

Rolling Update Scenario 3/4 시

Rolling Update 실습 예시

Rolling Back 실습 예시

[Cloud] HPA (Horizontal Pod Autoscaling)

dh_0e — Wed, 3 Jun 2026 16:12:27 +0900

Pod의 AutoScaling 방법

운용 중인 Pod의 서비스 상황에 따라 Pod의 수 또는 Pod에 할당된 리소스의 양을 자동으로 조정
- 수요변화와 서비스 품질등을 고려하여 적정하게 자동으로 스케일링

Scale Out(In) / Scale Up(Down)

HPA(Horizontal Pod Autoscaler, 수평 스케일링)
- Pod의 개수를 늘리거나(out) 줄임(in)
- Scale out, Scale in
VPA(Vertical Pod Autoscaler, 수직 스케일링)
- 해당 워크로드를 위해 이미 실행 중인 Pod에 더 많은 자원(메모리, CPU) 할당(up) 또는 해제(down)
- Scale up, Scale down

HPA (Horizontal Pod Autoscaler)

개념
- Application의 부하에 따라 Deployment나 ReplicaSet 등에 적용하여 포함된 Pod 수를 자동으로 조정
- CPU 사용률, 메모리 사용량, 사용자 정의 메트릭 등 특정 메트릭 기반
  - 메트릭: 시스템 상태를 수치로 나타낸 값 (예: CPU 사용률, 메모리 사용량, 초당 요청 수(RPS) 등)
- ex) 부하가 늘어나면 Pod를 일시적으로 늘리고, 부하가 줄어들면 다시 Pod의 숫자를 줄여 서버 내 자원을 효율적으로 관리
Metric 종류
- 리소스 메트릭: CPU 사용률과 메모리 사용률을 모니터링하여 스케일링 결정
- 사용자 정의 메트릭: Application 요구에 맞게 정의한 메트릭
  - ex) HTTP 요청 수, 응답 시간 등
- 외부 메트릭: Kubernetes 외부에서 수집된 메트릭
  - ex) 외부 API 응답 시간, 클라우드 서비스 제공자의 서비스 사용량 등

Need for HPA

장점
- 서비스 품질 향상
- 비용 관리 향상

Metric을 통한 HPA 과정

메트릭 서버: Kubelet으로부터 메트릭을 가져옴
HPA 컨트롤러: 15초마다 메트릭 서버에서 메트릭을 조회
HPA 컨트롤러: 원하는 복제본 수를 계산함
HPA 컨트롤러: API 서버를 통해 관련 Deployment를 업데이트
Deployment 컨트롤러: 이를 처리하여 ReplicaSet을 업데이트, 그 결과로 Pods의 수가 변경

Metrics Server

Metrics Server는 K8s 클러스터에서 CPU 및 메모리와 같은 메트릭 데이터를 수집하고, 클러스터 운영 및 오토 스케일링(HPA, VPA)에 필요한 실시간 모니터링 정보를 제공해 줌
- HPA와 VPA와 같은 오토스케일러는 직접 Pod 상태를 보는 것이 아니라, API Server를 통해 제공되는 메트릭 정보를 읽어서 스케일링 여부를 결정함

HPA 구동방법

"kubectl autoscale" 명령을 통해 horizontalPodAutoscaler(HPA) 생성
- 또는 yaml 파일로 kubectl apply -f 해서 배포 가능

HPA yaml file

min, maxReplicas: 스케일링 시에 최대, 최소 Replica 개수
metrics.type: 어떤 타입의 metric 인지
metrics.resource
- name: metric 종류
- target: 어떤 조건에서 스케일링하는지
  - averageUtilization(cpu 혹은 memory 사용량)이 50%가 되면 Scale up
  - 현재 resource.name이 cpu이므로 cpu 사용령이 50%가 되면 Scale up

metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Resource       # 메모리 조건 추가
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 60  # 메모리가 60%를 넘을 때

CPU와 Memory를 모두 감시하기 위한 yaml 파일의 metrics
위와 같이 설정하면, CPU가 50%를 넘거나, 메모리가 60%를 넘을 때 HPA 작동

HPA 작동 방식

메트릭 모니터링
- 일정 주기(Default: 15s)마다 CPU 사용량, 메모리 사용량, 커스텀 메트릭 or 외부 메트릭을 모니터링
- Kubernetes API 서버에 등록된 메트릭 서버나 외부 모니터링 도구를 통해 수집
  - 외부 모니터링 도구 ex) 외부 API 응답 시간(Kubernetes와 직접 연관되지 않은 외부트래픽에 따른 값)
임계값 평가
- HPA는 목표 메트릭 값(Target Metric)과 현재 메트릭 값을 비교하여 임계값 초과 여부를 평가
  - ex 1) 목표 CPU 사용률이 60%로 설정된 경우, 현재 CPU 사용률이 70%를 넘는다면 Scale out이 필요하다고 판단
  - ex 2) 현재 CPU 사용률이 50%라면 Scale in이 필요하다고 판단
Pod 스케일링
- 측정된 메트릭 값이 임계값을 초과하면 HPA는 Pod 수를 늘려서 부하를 분산
- 측정된 메트릭 값이 임계값 이하로 떨어지면 불필요한 Pod 수를 줄여 리소스 낭비를 방지
- 목표 메트릭 값 대비 현재 메트릭 값의 비율을 계산하여 Pod 수 결정

HPA가 Pod 수를 결정할 때 사용하는 뼈대가 되는 공식 (현재는 다양한 커스텀 Metrics 사용)

n%의 기준점
- HPA가 "CPU 사용량이 50%에 도달했다"라고 판단하려면 전체 100%가 얼마인지 아는 기준점이 필요
- Deployment(php-apache) 안의 Pod 설정 중 resources.requests.cpu에 할당된 값을 기준으로 계산
  - Downward API로 확인할 수 있었음

php-apache.yaml

resources: 필드
- 각 컨테이너에 대한 리소스 요청 및 제한 정의
- limits:
  - 컨테이너가 사용할 수 있는 리소스의 최대치
  - "cpu: 500m"는 컨테이너가 최대 500밀리 코어(0.5 코어)의 CPU를 사용할 수 있도록 제한
- requests:
  - 컨테이너가 기본적으로 필요한 리소스의 양
  - HPA는 request 값을 기준으로 CPU target 사용량(%)을 설정

HPA 급격한 변화 방지

spec >> Scale-down 동작 설정

메트릭 변동으로 인해 Pod 수가 급격하게 변동하는 것을 방지하기 위한 scaleDwon 동작 설정

안정화 윈도우

메트릭 변동으로 인해 Pod 수가 급격하게 변동하는 것을 방지하기 위한 시간 범위 설정
스케일링을 수행하기 전, 지정된 윈도우 동안 수집된 메트릭 값 중 가장 높은 값을 사용하여 스케일링 여부를 결정
- 위 예시) 300s 동안 수집된 메트릭 값 중 가장 높은 값을 사용
불필요한 스케일 다운을 방지하고, 안정성을 유지할 수 있음

통합 예시

[Cloud] StatefulSet

dh_0e — Wed, 3 Jun 2026 14:26:51 +0900

StatefulSet

정의: "상태가 있는(Stateful) 애플리케이션"을 관리하기 위해 Pod의 순서와 고유성을 보장하며 배포하는 컨트롤러
Pod들은 동일한 컨테이너 스펙으로 생성되지만, 서로 교체할 수 없는 고유한 식별자와 상태를 가짐
- 재스케줄링(Pod 재생성) 시에도 Pod의 이름과 네트워크 식별자, 스토리지 볼륨이 그대로 유지됨
주요 사용처(Use Cases)
- 데이터베이스 및 클러스터링 시스템: MySQL, MongoDB, Redis, Kafka 등 상태와 데이터 유지가 필수적인 워크로드의 90% 이상에 사용
  - 워크로드: 컴퓨팅 리소스가 작업 완료 또는 결과 도출을 위해 수행하는 처리 작업의 유형과 양
- 안정적이고 고유한 네트워크 식별자가 필요한 경우
- 안정적인 영구 스토리지(PV)가 필요한 경우
- 순차적인 Pod의 배포, 스케일링, 삭제가 필요한 경우
- PV와 궁합이 잘 맞음
스토리지(Volume) 및 스케일링 특징
- volumeClaimTemplates 사용: 각 Pod가 생성될 때 고유한 PVC를 자동으로 생성해 개별 PV와 1:1로 매핑함
- Deployment는 하나의 PVC를 여러 Pod가 공유하는 방식이 흔하지만, StatefulSet은 이 템플릿을 통해 생성되는 각 Pod마다 자신만의 독립적인 PVC를 자동으로 생성하여 연결
네트워크 (Headless Service)
- StatefulSet은 로드밸런싱 목적인 일반 Service(ClusterIP) 대신 Headless Service(ClusterIP: None)와 짝을 이루어 사용함
- 각 Pod는 <Pod이름>.<Service이름>.<Namespace>.svc.cluster.local 형태의 고정된 내부 DNS 주소를 가지게 되어, 특정 Pod(예: DB Master 노드)를 정확히 지정해 통신할 수 있음

Scale Up/Down of StatefulSet

Scale Down을 해도 PVC가 없어지지 않고 유지됨
Scale Up을 했을 때 기존 PVC로 쉽게 PV와 연결할 수 있음

Deployment vs StatefulSet 차이

Deployment로 만든 여러 개의 Pod들은 고유 ID나 Pod간의 순서가 없으며, 임의의 이름을 할당 받음
- 모든 Pod들은 공유 볼륨을 사용할 수 있음
StatefulSet으로 만든 여러 개의 Pod들은 고유 ID를 가지며, 순차적으로 생성 및 종료됨
- 각 Pod에 개별적인 PV가 필요함

Using PV in Deployment

Using PV in StatefulSet

Deployment 여러 개로 StatefulSet 기능 구현

Stateful Application(Pod) without using StatefulSet

각 Replica(Pod)들은 고유의 Service와 Deployment를 가짐
- Service들은 각 Pod들에게 안정된 주소를 분리시켜 제공함 (Service x 3)
- Deployment들은 각 Pod들에게 모두 다른 PVC를 제공함 (Deployment x 3)
- 공유 주소로 모든 Pod를 함께 노출하고 싶을 경우, 또 다른 서비스(사진의 quiz Service)가 필요함 (+ 1 Service)
만약 사진처럼 3개의 Pod에 각각 고유한 주소와 스토리지를 쥐어주려면, 사진에 나온 것처럼 3개의 Deployment, 3개의 개별 Service, 1개의 공통 Service 등 엄청나게 많은 리소스(YAML 파일)를 직접 관리해야 하는 복잡성이 있음
- StatefulSet을 활용하면 이를 단 2개의 리소스로 압축해 줌
  1. StatefulSet: 사진 속의 파란색(Deployment)과 초록색(PVC) 상자들의 역할
  2. Headless Service: 사진 속의 노란색(개별 Service) 상자들 역할

Headless Service

Headless Service for StatefulSet

일반적인 Service에서는 자신만의 고유한 IP(Cluster IP)를 가짐
- 로드밸런싱: 외부에서 이 IP로 요청을 보내면 Service가 알아서 뒤에 있는 여러 Pod 중 무작위로 트래픽을 넘겨줌
StatefulSet은 Pod들이 각각 고유 번호가 있기 때문에 Cluster IP를 주지 않는 Headless Service를 사용
- Service 자체의 대표 ClusetrIP(Head)를 없애버린 것
- 대표 IP가 없는 대신, 쿠버네티스 내부의 DNS 서버(주황색 원통)에 각 Pod들의 고유한 이름과 실제 IP 주소를 매핑하여 저장
- 이 덕분에 랜덤한 Pod가 아니라, 내가 원하는 정확한 Pod를 콕 집어서 찾아갈 수 있게 됨

"StatefulSet의 Pod들은 각각 자기만의 고유한 역할과 데이터가 있기 때문에 아무 데나 랜덤하게 접속하면 안 된다. 그래서 대표 IP를 지워버린 Headless Service를 사용해, DNS를 통해 각 Pod의 고유한 도메인 주소(FQDN)로 직접 찾아가게 만든다."

StatefulSet YAML

Headless Service yaml, StatefulSet yaml

Headless Service (왼쪽 코드)

kind: Service
metadata.name: nginx
clusterIP: None (핵심)
- 일반 Service를 Headless Service로 바꿔주는 옵션
- 자신만의 대표 IP(머리)를 가지지 않고, 뒤에 연결될 Pod들의 IP를 DNS에 묶어주는 역할만 수행하겠다고 선언하는 것

StatefulSet (중간/오른쪽 코드)

kind: StatefulSet
serviceName: "nginx" (연결 고리)
- 앞서 만든 Headless Service와 StatefulSet을 짝지어주는 역할
- 내가 만드는 Pod(web-0, web-1, web-2)들의 고유 도메인 주소를 nginx라는 이름의 Headless Service DNS에 등록해 주라는 의미
replicas: 3
- web-0, web-1, web-2 3개의 Pod를 순차적으로 찍어냄
volumeClaimTemplates (스토리지 자동화)
- 이전에 봤던 "각 Pod마다 따로 PVC를 만들어주는 번거로운 작업"을 해결해 주는 템플릿
- storage: 1Gi
  - Pod를 3개 만들면서, 이 템플릿을 바탕으로 3개의 독립적인 1Gi PVC를 알아서 생성하고 각각의 Pod에 1:1로 마운트 해줌 (mountPath: /usr/share/nginx/html)

한계점

스토리지(PV) 사전 준비 필수 (인프라 구성 난이도 상승)
- 주어진 Pod의 스토리지는 요청된 스토리지 클래스를 기반으로 PV Provisioner(StorageClass)에 의해 제공되거나, 인프라 관리자에 의해 사전 제공되어야 함
자동 삭제되지 않는 볼륨 (데이터 유지됨)
- StatefulSet을 삭제하거나 Scale-down(축소)해도 StatefulSet과 관련된 볼륨은 삭제되지 않음
- 테스트가 끝난 후 리소스를 완전히 정리할 때 관리자가 수동으로 PVC를 지워주지 않으면 클라우드 환경에서 계속 스토리지 과금이 발생할 수 있음
현재 포드의 네트워크 동일성을 책임지기 위해 Headless Service가 항상 필요함
StatefulSet이 삭제될 때 Pod의 종료에 대한 보장을 제공하지 않음
- StatefulSet을 "kubectl delete"로 한 번에 날려버리면, Pod들이 순서를 지키지 않고 동시다발적으로 강제 종료될 위험이 있음
- 분산 서버나 데이터베이스라면, 디스크에 안전하게 저장(Flush)할 시간이 필요하므로, 반드시 "replicas: 0"으로 먼저 Scale-down을 지시하여 제일 마지막 번호의 Pod부터 0번까지 차례대로(역순으로) 안전하게 마무리 작업을 하고 꺼지도록 유도해야 함

[C++ Server] Packet Handler

dh_0e — Sat, 9 May 2026 17:51:39 +0900

PacketHandler

네트워크 통신(Session)과 게임 로직(Content) 사이를 연결하는 추상화 클래스
- 기존에는 Session 클래스의 OnRecvPacket에서 직접 패킷을 분석하고 처리함
패킷의 종류가 늘어날수록 Session 코드가 비대해지는 것을 방지하기 위해 패킷의 생성과 해석만을 전담하는 별도의 클래스

[ GameServer ]

ServerPacketHandler.h

#pragma once

/*------------------------
	ServerPacketHandler
------------------------*/

enum { S_TEST = 1 };

struct BuffData {
	uint64 buffId;
	float remainTime;
};

class ServerPacketHandler {
public:
	static void HandlePacket(BYTE* buffer, int32 len);

	static SendBufferRef Make_S_TEST(uint64 id, uint32 hp, uint16 attack, vector<BuffData> buffs);
};

ServerPacketHandler.cpp

#include "pch.h"
#include "ServerPacketHandler.h"
#include "BufferReader.h"
#include "BufferWriter.h"

/*------------------------
	ServerPacketHandler
------------------------*/

void ServerPacketHandler::HandlePacket(BYTE* buffer, int32 len) {
	BufferReader br(buffer, len);

	PacketHeader header;
	br.Peek(&header);

	switch (header.id)
	{
	default:
			break;
	}
}

SendBufferRef ServerPacketHandler::Make_S_TEST(uint64 id, uint32 hp, uint16 attack, vector<BuffData> buffs) 
{
	SendBufferRef sendBuffer = MakeShared<SendBuffer>(4096);

	BufferWriter bw(sendBuffer->Buffer(), sendBuffer->AllocSize());

	// Reserve로 header가 들어갈 공간 미리 확보
	PacketHeader* header = bw.Reserve<PacketHeader>();

	// id(uint64), 체력(uint32), 공격력(uint16)
	bw << id << hp << attack;

	// 가변 데이터
	bw << static_cast<uint16>(buffs.size());

	for (BuffData& buff : buffs)
	{
		bw << buff.buffId << buff.remainTime;
	}

	sendBuffer->SetWriteSize(bw.WriteSize());

	header->size = bw.WriteSize();
	header->id = S_TEST;	 // 1: Test Msg

	return sendBuffer;
}

송신(Send) 로직 (ServerPacketHandler::MAKE_S_TEST)
- 헤더 예약(Reserve): Reserve를 통해 패킷의 맨 앞부분(PacketHeader) 공간을 미리 비워둠
- 데이터 삽입
  - 고정 데이터: id, hp, attack과 같은 고정 크기 자료형을 버퍼에 삽입
  - 가변 데이터: 보낼 리스트(buffs)의 개수를 기록하고 for 루프를 돌며 각 요소의 상세 데이터(buffId, remainTime)를 순차적으로 기록
- 헤더 완성: 최종적으로 기록된 전체 바이트 크기를 계산하여 아까 비워둔 헤더의 size 필드와 패킷 id를 채워 넣음

[ DummyClient ]

ClientPacketHandler.h

#pragma once

/*------------------------
	ClientPacketHandler
------------------------*/

enum 
{ 
	S_TEST = 1
};

class ClientPacketHandler {
	
public:
	static void HandlePacket(BYTE* buffer, int32 len);

	static void Handle_S_TEST(BYTE* buffer, int32 len);
};

ClientPacketHandler.cpp

#include "pch.h"
#include "ClientPacketHandler.h"
#include "BufferReader.h"

/*------------------------
	ClientPacketHandler
------------------------*/

void ClientPacketHandler::HandlePacket(BYTE* buffer, int32 len) {
	BufferReader br(buffer, len);

	PacketHeader header;
	br >> header;

	// switch case보다 효율적인 방법이 있음. Map?
	switch (header.id)
	{ 
		case S_TEST:
			Handle_S_TEST(buffer, len);
			break;
	}

	
}

// 패킷 설계 TEMP
struct BuffData
{
	uint64 buffId;
	float remainTime;
};

struct S_TEST
{
	uint64 id;
	uint32 hp;
	uint16 attack;
	// 가변 데이터
	// 1) 문자열 (ex. name)
	// 2) 그냥 바이트 배열 (ex. 길드 img)
	// 3) 일반적인 리스트
	vector<BuffData> buffs;
};

void ClientPacketHandler::Handle_S_TEST(BYTE* buffer, int32 len) {
	BufferReader br(buffer, len);

	PacketHeader header;
	br >> header;

	uint64 id;
	uint32 hp;
	uint16 attack;
	br >> id >> hp >> attack;

	cout << "ID: " << id << " HP: " << hp << " ATT: " << attack << endl;

	vector<BuffData> buffs;
	uint16 buffSize;
	br >> buffSize;

	buffs.resize(buffSize);
	for (int i = 0; i < buffSize; i++) {
		br >> buffs[i].buffId >> buffs[i].remainTime;
	}

	cout << "BufSize: " << buffSize << endl;
	for (int i = 0; i < buffSize; i++) {
		cout << "BuffInfo: " << buffs[i].buffId << " " << buffs[i].remainTime << endl;
	}
}

수신 로직 (ClientPacketHandler::Handle_S_TEST)
- 고정 데이터 추출: BufferReader를 이용해 헤더 이후의 고정 데이터(id, hp, attack)를 먼저 읽어옴
- 가변 데이터 복원: 버퍼에서 가변 데이터의 개수(buffSize)를 먼저 읽음
- 루프를 돌며 버퍼의 데이터를 객체에 복원

BufferWriter.h / GameSession.h / GameSession.cpp / DummyClient.cpp / GameServer.cpp 수정

PacketHandler · znfnfns0365/CPP_Server_Practice@e7a287d

+ vector<BuffData> buffs{BuffData{100, 1.2f}, BuffData{200, 3.4}, BuffData{300, 1.9}};

github.com

BufferWriter.h: 오류 수정
GameSession.h / GameSession.cpp: 서버에서 패킷 수신 시 ServerPacketHandler::HandlePacket() 실행
DummyClient.cpp: 클라이언트에서 패킷 수신 시 ClientPacketHandler::HandlePacket() 실행
GameServer.cpp: ServerPacketHandler::Make_S_TEST()로 패킷 전송

Client / Server 실행 결과

[Cloud] Kubernetes Volumes III (Downward API, Job, CronJob, DaemonSet)

dh_0e — Fri, 8 May 2026 14:08:57 +0900

Downward API

Pod가 자기 자신의 정보(이름, IP, label 등)를 ConfigMap이나 Secret에 미리 정의하지 않고도 런타임에 가져올 수 있게 해주는 기능
핵심 개념: k8s 마스터 서버를 통하지 않고, 환경 변수나 볼륨 파일을 통해 포드/컨테이너의 메타데이터를 주입하는 방식
- 환경 변수: 개별적인 값을 하나씩 변수에 할당할 때 사용 (가장 흔한 방식)
- 볼륨 마운트: 정보를 파일 형태로 제공하여 label이나 annotation처럼 내용이 수시로 변할 수 있는 정보를 실시간으로 반영하기에 좋음

응용 프로그래머들이 자주 사용함
- ex1) Redis, MongoDB 같은 분산 시스템을 구축할 때
- ex2) 모니터링을 위해 여러 Pod에서 로그를 수집할 때
- ex3) JVM이나 Node.js에서 리소스 제한에 따른 동적 메모리 설정을 할 때

Downward API를 통해 전달할 수 있는 정보

metadata.labels, metadata.annotations는 볼륨 파일로만 접근 가능한 이유

labels, annotations는 Key-Value 쌍의 집합이기 때문에, 환경 변수 하나에 이 수많은 목록을 다 집어넣기 힘듦
labels는 Pod가 실행 중에도 바뀔 수 있음
- 환경 변수: 한 번 실행되면, 프로세스를 재시작하지 않는 이상 바꿀 수 없음
- 볼륨 파일: 쿠버네티스가 파일 내용을 실시간으로 업데이트해 줌

Using Downward API with Volume Mount

Pod Field(only Volume Mount)

labels, annotations로 metadata.labels, metadata.annotations 환경 변수로 설정
"kubectl exec -it 'pod 이름' -- /bin/bash"로 Pod 안에 들어가서 Volume Mount 경로에 있는 파일 확인

Using Downward API with Environment Variables (1)

Pod Field(Both)

spec.nodeName을 NODE_NAME에 저장하는 방식
metadata.name, metadata.namespace, metadata.uid, spec.serviceAccountName, status.hostIP, status.podIP 들은 Volume mount로도 가능
"kubectl exec -it 'pod 이름' -- env"로 환경변수 확인

Using Downward API with Environment Variables (2)

Container Field(Both)

컨테이너 필드 메타데이터(requests.cpu, requests.memory, limits.cpu)는 환경 변수, 볼륨 파일 모두 가능
"kubectl exec -it 'pod 이름' -- env"로 환경변수 확인

Downward API는 Pod 내의 컨테이너가 자신이 실행 중인 K8s 환경을 스스로 인식할 수 있게 해주는 가장 가볍고 안전한 방법

Job, CronJob

필요 상황: Pod를 한 번만 돌리고 사라지게 하고 싶을 때 (ex. 백업 한 번 하고 잔여 파일 삭제)
Job: 일회성 작업을 수행하기 위한 리소스
CronJob: 주기적인 작업을 수행하기 위한 리소스

Job

특징
- 성공적인 실행 보장: 지정된 작업이 성공적으로 완료될 때까지 Pod를 재시작
- 동시성 설정: 동시에 실행할 수 있는 Pod 수 조정 가능
- 완료 상태 관리: 작업 완료 후 상태 확인 가능
사용 사례
- 데이터 처리 Batch 작업
- 백업 및 복원 작업
- AI/ML Training(학습) Task
- DB Migration

Job 구조 (시험 X)

restartPolicy: 실패 시 컨테이너를 다시 살릴 것인가, 아니면 포드를 새로 만들 것인가?
- OnFailure: 실패 시 재시작 (컨테이너 수준의 재시작)
- Never: 실패 시 포드 새로 생성 (Pod 수준의 재시작)
backoffLimit: Job 컨트롤러가 "이 작업은 가망이 없다"라고 판단하고 포기하기 전까지의 재시도 횟수
- restartPolicy: Never인 경우: 실패한 Pod의 개수가 backoffLimit에 도달하면 종료, Job 실패 처리
- restartPolicy: OnFailure인 경우: 컨테이너의 재시작 횟수가 backoffLimit에 도달하면 해당 Pod를 종료, Job 실패 처리

CronJob

Job 리소스에 스케줄을 추가하여 주기적으로 실행되는 Job
Linux의 crontab 기능과 유사하게 특정 시간 및 주기에 맞춰 작업 수행 가능
사용 사례
- 정기적인 데이터 백업
- 로그 파일 정리
- 정해진 시간에 반복적으로 수행되는 작업
특징
- 지속적으로 주기적인 작업 실행
- 일정에 맞게 Job을 생성하도록 실행 주기 설정 가능

CronJob 구조

Scheduling: * * * * * (분 시 일 월 요일) 형식을 사용

Job & CronJob이 실패했을 때 어떻게 될 것인가?

DaemonSet

클러스터 내의 모든(혹은 특정 조건에 맞는) 노드에 Pod를 딱 하나씩 배치하는 리소스
- Node당 딱 하나만 만들어서 백그라운드에서 돌면서 뭔가 해야 할 일이 주어짐
동작 방식
- 새로운 노드가 클러스터에 추가되면 DaemonSet Pod가 자동으로 그 노드에 생성됨
- 노드가 삭제되면 해당 Pod는 Garbage Collection으로 작동
- RollingUpdate를 통해 노드별로 순차적인 업데이트가 가능
사용 사례
- 로그 수집기: 각 노드에서 발생하는 로그를 수집하여 중앙으로 전송
- 노드 모니터링: 각 노드의 리소스 상태를 감시
- 네트워크 플러그인: 쿠버네티스 네트워킹을 관리

[C++ Server] Buffer Helper (Reader, Writer)

dh_0e — Fri, 8 May 2026 11:59:35 +0900

Buffer Helper

기존 방식: memcpy를 사용하여 구조체나 변수를 직접 버퍼에 복사
- 가독성 저하: buffer + offset 계산이 반복되어 코드가 지저분해짐
- 실수 가능성: 데이터 크기 계산을 Send 할 때마다 하기 때문에 계산 실수 발생 가능
- 가변 패킷 처리: 문자열이나 리스트 등 크기가 변하는 데이터를 다루기 까다로움
Buffer Helper: 이를 해결하기 위해 C++의 연산자 오버로딩과 템플릿을 활용해 Stream 방식으로 데이터를 밀어 넣고 빼낼 수 있는 클래스
- 커서 관리의 자동화: _pos 멤버 변수를 통해 현재 읽기/쓰기 위치를 내부적으로 관리하므로, 개발자가 외부에서 인덱스를 관리할 필요가 없음
- 유연한 메모리 접근: BYTE* 포인터를 직접 다루기 때문에 추가적인 복사 비용을 최소화하면서도 인터페이스는 추상화되어 있음
- 가변 데이터 대응: Write(void* src, uint32 len) 함수를 통해 구조체뿐만 아니라 일반적인 바이너리 데이터나 가변 길이 문자열도 처리 가능

Before / After

BufferWriter

데이터를 버퍼에 쓰는 역할로, 직관적인 패킷 생성을 담당
- 연산자 오버로딩(<<): "bw << id << hp << attack;"와 같이 cout을 쓰듯 직관적으로 데이터 삽입 가능
- Reserve 패턴
  - 패킷의 총크기는 모든 데이터를 Write 해야 알 수 있는 경우가 많음
  - Reserve<PacketHeader>()를 통해 헤더 공간을 미리 비워두고, 데이터를 다 채운 뒤 나중에 헤더 정보를 업데이트할 수 있게 함
- 템플릿 활용: 임의의 타입(T)에 대해 크기를 자동으로 계산하여 복사함

BufferWrtier.h

#pragma once
/*-------------------------
	BufferWriter
-------------------------*/

class BufferWriter {
public:
	BufferWriter();
	BufferWriter(BYTE* buffer, uint32 size, uint32 pos = 0);
	~BufferWriter();

	BYTE* Buffer() { return _buffer; }
	uint32 Size() { return _size; }
	uint32 WriteSize() { return _pos; }
	uint32 FreeSize() { return _size - _pos; }

	template <typename T>
	bool Write(T* src) {
		return Write(src, sizeof(T));
	}
	bool Write(void* src, uint32 len);

	// packetHeader를 마지막에 채울 수 있기 때문에 이를 편하게 하기 위해
	template <typename T>
	T* Reserve();

	template <typename T>
	BufferWriter& operator<<(const T& src);

	template <typename T>
	BufferWriter& operator<<(T&& src);
	// <<로 데이터를 밀어넣는 연산자 만듬

private:
	BYTE* _buffer = nullptr;
	uint32 _size = 0;
	uint32 _pos = 0;
};

template <typename T>
T* BufferWriter::Reserve() {
	if (FreeSize() < sizeof(T))
		return nullptr;

	T* ret = reinterpret_cast<T*>(&_buffer[_pos]);
	_pos += sizeof(T);
	return ret;
}

template <typename T>
BufferWriter& BufferWriter::operator<<(const T& src) {
	*reinterpret_cast<T*>(&_buffer[_pos]) = src;
	// ::memcpy 써도 됨
	_pos += sizeof(T);
	return *this;
}

template <typename T>
BufferWriter& BufferWriter::operator<<(T&& src) {
	*reinterpret_cast<T*>(&_buffer[_pos]) = std::move(src);
	_pos += sizeof(T);
	return *this;
}

BufferWrtier.cpp

#include "pch.h"
#include "BufferWriter.h"

/*-------------------------
	BufferWriter
-------------------------*/

BufferWriter::BufferWriter() {}

BufferWriter::BufferWriter(BYTE* buffer, uint32 size, uint32 pos) : _buffer(buffer), _size(size), _pos(pos) {}

BufferWriter::~BufferWriter() {}

bool BufferWriter::Write(void* src, uint32 len) {
	if (FreeSize() < len)
		return false;

	::memcpy(&_buffer[_pos], src, len);
	_pos += len;
	return true;
}

BufferReader

수신된 버퍼에서 데이터를 순차적으로 읽어와 안전한 패킷 파싱을 담당
- 연산자 오버로딩(>>): "br >> header >> id;"와 같이 cin을 쓰듯 직관적으로 데이터 파싱 가능
- Peek 기능: 데이터를 읽어서 커서(pos)를 옮기지 않고 내용만 확인하고 싶을 때 사용

BufferReader.h

#pragma once

/*-------------------------
	BufferReader
-------------------------*/

class BufferReader {
public:
	BufferReader();
	BufferReader(BYTE* buffer, uint32 size, uint32 pos = 0);
	~BufferReader();

	BYTE* Buffer() { return _buffer; }
	uint32 Size() { return _size; }
	uint32 ReadSize() { return _pos; }
	uint32 FreeSize() { return _size - _pos; }

	// 데이터를 옅보고 싶지만, 커서는 옮기고 싶지 않을 때
	template <typename T>
	bool Peek(T* dest) {
		return Peek(dest, sizeof(T));
	}
	bool Peek(void* dest, uint32 len);

	template <typename T>
	bool Read(T* dest) {
		return Read(dest, sizeof(T));
	}
	bool Read(void* dest, uint32 len);

	template <typename T>
	BufferReader& operator>>(OUT T& dest);
	// >>로 데이터를 꺼내쓰는 연산자 만듬

private:
	BYTE* _buffer = nullptr;
	uint32 _size = 0;
	uint32 _pos = 0;
};

template <typename T>
inline BufferReader& BufferReader::operator>>(OUT T& dest) {
	dest = *reinterpret_cast<T*>(&_buffer[_pos]);
	_pos += sizeof(T);
	return *this;
}

BufferReader.cpp

#include "pch.h"
#include "BufferReader.h"
#include "BufferWriter.h"

/*-------------------------
	BufferReader
-------------------------*/

BufferReader::BufferReader() {}

BufferReader::BufferReader(BYTE* buffer, uint32 size, uint32 pos) : _buffer(buffer), _size(size), _pos(pos) {}

BufferReader::~BufferReader() {}

bool BufferReader::Peek(void* dest, uint32 len) {
	if (FreeSize() < len)
		return false;

	::memcpy(dest, &_buffer[_pos], len);
	return true;
}

bool BufferReader::Read(void* dest, uint32 len) {
	if (Peek(dest, len) == false)
		return false;

	_pos += len;
	return true;
}

연산자 오버로딩에 사용된 reinterpret_cast는 memcpy로 바꿔도 상관없음
- 오히려 안정성과 정렬 문제 예방면에서 더 좋음

// 기존 방식
dest = *reinterpret_cast<T*>(&_buffer[_pos]);

// memcpy 방식 (성능 차이 없음, 더 안전함)
::memcpy(&dest, &_buffer[_pos], sizeof(T));

SendBuffer.h / SendBuffer.cpp / DummyClient.cpp / GameServer.cpp 수정

Buffer Helper(BufferReader, BufferWriter) · znfnfns0365/CPP_Server_Practice@e33f461

+ BufferReader::BufferReader(BYTE* buffer, uint32 size, uint32 pos) : _buffer(buffer), _size(size), _pos(pos) {}

github.com

SendBuffer.h: AllocSize() 추가(SendBuffer Pooling 안 한 상태라 의미 없음), 자료형 uint32로 통일
SendBuffer.cpp: CopyData()의 기능을 BufferWriter에서 해주기 때문에 삭제
DummyClient.cpp: BufferReader로 패킷 파싱
- header.size - sizeeof(PacketHeader) - 8 - 4 - 2: 가변 길이는 나중에 패킷 설계에서 설정해줘야 함
GameServer.cpp: BufferWriter로 패킷 생성
- Reserve로 packetHeader 공간 미리 확보
- sendBuffer→SetWriteSize(bw.WriteSize())
  - Session::RegisterSend()에서 wsaBuf.len에 sendBuffer→WriteSize()를 넣고 있기 때문에,
    bufferWriter의 _pos를 sendBuffer의 _writeSize에 넣어줘야 함

[C++ Server] PacketSession

dh_0e — Thu, 7 May 2026 11:37:28 +0900

PacketSession

Session 클래스(TCP 소켓의 기본 송수신을 담당)를 상속받아 패킷 조립 기능을 얹은 클래스
TCP 특성상 패킷이 모두 도착했다는 보장을 할 수가 없는 TCP 데이터 경계 문제(TCP Boundary Problem)를 해결함
- TCP는 스트림(Stream) 기반이라 데이터의 경계가 없음
- 패킷이 쪼개져서 오기도 하고(Fragmentation), 뭉쳐서 오기도 함(Sticky Packets)

struct PacketHeader {
	uint16 size;
	uint16 id;
};

size(2Byte) + id(2Byte)로 구성된 헤더를 만듦
- size: 패킷 전체 크기 (header + data)
- id: 프로토콜 ID (ex. 1=로그인, 2=회원가입)
OnRecv (final)
- 네트워크 I/O 스레드에서 실제 데이터를 수신했을 때 호출되는 함수
- 역할
  - 패킷 쪼개짐/뭉침 문제를 모두 처리
  - 받은 데이터 버퍼를 읽으면서 헤더의 size만큼 데이터가 다 모였는지 확인
    - 다 모이지 않았다면 다음 수신을 기다림
    - 다 모였다면 온전한 하나의 패킷을 잘라내어 OnRecvPacket() 호출
- final: 하위 클래스에서 실수로 재정의하는 것을 방지
OnRecvPacket (abstract)
- OnRecv에서 온전한 1개의 패킷이 조립되었을 때마다 호출
- 역할
  - 클래스를 상속받을 실제 게임 세션에서 컨텐츠 로직을 구현하는 곳 (원래 OnRecv 역할)
  - 넘어온 데이터가 무조건 결함 없는 1개의 완벽한 패킷이기 때문에, 헤더의 id를 읽고 컨텐츠 처리
GetPacketSessionRef
- 멀티스레드 환경에서 세션 객체의 생명 주기를 안전하게 관리하기 위해 shared_from_this 반환

Session.h

/*--------------------
	PacketSession
--------------------*/
// TCP 특성상 패킷이 모두 도착했다는 보장을 할 수가 없어서 이를 처리하는 세션

struct PacketHeader {
	uint16 size;
	uint16 id;
};

// [size(2Byte)][id(2Byte)][data...]
// size: 패킷 전체 크기 (header + data)
// id: 프로토콜 ID (ex. 1=로그인, 2=회원가입)

class PacketSession : public Session {
public:
	PacketSession();
	virtual ~PacketSession();

	PacketSessionRef GetPacketSessionRef() { return static_pointer_cast<PacketSession>(shared_from_this()); }

protected:
	virtual int32 OnRecv(BYTE* buffer, int32 len) final;
	virtual int32 OnRecvPacket(BYTE* buffer, int32 len) abstract;
};

Session.cpp

/*--------------------
	PacketSession
--------------------*/

PacketSession::PacketSession() {}

PacketSession::~PacketSession() {}

int32 PacketSession::OnRecv(BYTE* buffer, int32 len) {
	int32 processLen = 0;
	while (true) {
		int32 dataSize = len - processLen;
		// 최소한 헤더는 파싱할 수 있는지
		if (dataSize < sizeof(PacketHeader))
			break;

		PacketHeader header = *(reinterpret_cast<PacketHeader*>(&buffer[processLen]));
		// 헤더에 기록된 패킷 크기를 파싱할 수 있는지
		if (dataSize < header.size)
			break;

		// 패킷 조립 성공
		OnRecvPacket(&buffer[processLen], header.size);

		processLen += header.size;
	}
	return processLen;
}

DummyClient.cpp / GameServer.cpp / GameSession.h / GameSession.cpp / Types.h 수정

PacketSession, Disconnect Logic Debug · znfnfns0365/CPP_Server_Practice@c305ec7

+ MakeShared<ClientService>(NetAddress(L"127.0.0.1", 7777), MakeShared<IocpCore>(), MakeShared<ServerSession>, 1000);

github.com

DummyClient.cpp
- OnRecv를 OnRecvPacket으로 바꾸고, OnRecv에서 받은 패킷을 복사, 출력
- 클라이언트 1000개를 만들어 서버 연결 시도
GameServer.cpp / GameSession.cpp: Broadcast를 GameServer에서 주기적으로(250ms) 보내도록 수정
GameSession.h: GameSession이 PacketSession을 상속, OnRecv가 아닌 OnRecvPacket을 재정의 하도록 수정
Types.h: PacketSessionRef 선언

Session.cpp 수정 (Line 43~43 → Line 230~232)

원래 코드에서 Client를 1000개로 늘려서 실행 중 Client를 접속 해제(종료)하면 CRASH 발생

이유: 원래 코드의 로직으로 GameSession::OnRecvPacket에서 Send 처리 중 클라이언트가 접속 해제 시
1. Session::RegisterSend()에서 WSASend 중 HandleError 발생
2. Session::HandleError()에서 Disconnect(L"HandleError"); 호출
3. Session::Disconnect()에서 OnDisconnected() 호출
4. GameSession::OnDisconnected()에서 세션 삭제
  - Send 처리 중 세션을 삭제한다는 뜻 → CRASH (Dangling Pointer) 발생

다음과 같이 OnDisconnected() 호출 부분을 ProcessDisconnect()로 옮겨서 GameSession이 소멸된 이후에 세션을 삭제하게끔 만들어줌
- 기존 (위험): Send 하다가 에러 발생 → 그 즉시 ReleaseSession 호출 → 메모리 해제
- 수정 (안전): 에러 발생 → RegisterDisconnect (끊어달라고 통보만 함) → 나중에 IOCP가 완료 신호를 주면 ProcessDisconnect에서 정리

클라이언트 세션 1000개가 잘 소멸됨