dh_0e

SCS(Subcarrier Spacing, 부반송파 간격)개념: 데이터를 전송할 때 전체 주파수 대역을 아주 얇은 실처럼 여러 개로 쪼개서 데이터를 실어 보내는데, 이 쪼개진 실 하나하나를 부반송파(Subcarrier)라고 하고, 이들 사이의 간격을 SCS라고 함SCS 크기에 따라 시간 축의 길이(Slot 기간)가 달라짐주파수 간격이 넓어지면(대역폭을 많이 쓰면) 데이터를 보내는 속도가 빨라지므로, 데이터를 전송하는 데 걸리는 시간은 반비례해서 짧아짐LTE vs 5GLTE: SCS가 15㎑로 고정되어 있음5G: 상황에 따라 15, 30, 60, 120㎑ 등 다양하게 간격을 늘릴 수 있음시간 계산: 15㎑일 때 한 슬롯이 1㎳인데 그게 시프팅될 때마다 슬롯 주기가 짧아지는 원리SCS 15㎑ 일 때: 1 S..

이동 통신 기초5G의 Usage ScenarioeMBB(Enhanced Mobile BroadBand) - 초고속mMTC(Massive Machine Type Communications) - 초연결 URLLC(Ultra-reliable and low latency communications) - 초저지연 통신 표준전 세계의 통신 장비와 단말기는 여러 회사들이 개발하고 제조함따라서, 전 세계 어디에서도 동일하게 통신이 가능하도록 통신 규약(3GPP)을 결정해야 함통신 표준의 예: LTE원래 통화는 Circuit(회로/HW) 기반, 데이터는 Packet 기반이었는데 4세대(LTE)부터 통화도 Packet 기반으로 통신 5G(5세대 이동통신)초고속: LTE의 20배 속도초저지연: LTE 10분의 1 수준의 지..

5G NR Scheduling & Link Adaption Process 1. 무선 신호 품질 지표 (RSRP, RSSI, SINR)기지국과 단말의 통신 품질을 나타내는 대표적인 지표RSRP (Reference Signal Received Power): 단말과 연결된 기지국의 순수 신호 세기만 측정 (수신 파워)RSSI (Received Signal Strength Indicator): 기지국 신호뿐만 아니라 주변 노이즈, 다른 셀의 간섭까지 모두 합친 전체 수신 전력량SINR (Signal-to-Interference-plus-Noise Ratio): 노이즈와 간섭 대비 내가 원하는 '유효 신호'의 비율통신 품질(속도)을 결정하는 가장 핵심적인 지표SINR이 높아야 고차 변조(256QAM 등)를 사용 ..

5G 초기 접속 및 RACH 절차 1. DL: 기지국 탐색 및 동기화 (SSB 수신 및 MIB 추출)SSB(Sync Signal Block): 기지국에서 주기적으로 수신하는 신호 블록UE가 기지국을 처음 발견하고 연결을 시작하기 위해 가장 먼저 수신하는 신호 묶음"여기 기지국이 있습니다!"를 알려주는 첫 번째 신호특정 구간(SSB Burst)에 묶어서 브로드캐스팅함SSB(SS/PBCH Block) 구성요소PSS(Primary Synchronization Signal): 시간 동기 획득 및 1차 Cell ID 결정가장 먼저 찾는 신호로 셀과의 시간, 주파수 동기를 맞출 수 있게 되고, Cell ID의 일부를 결정함SSS 전송 타이밍을 알 수 있음PSS 찾기 == 기지국 찾기SSS(Secondary Sync..

5G SA Call FlowNR(New Radio) 단독모드: 즉, 5G SA(StandAlone)는 말 그대로 "오직 5G 기술만으로 기지국 접속부터 데이터 통신까지 모든 과정을 온전히 처리하는 방식"을 뜻함5G 초기 상용화 때는 주로 4G LTE 망과 5G 망을 섞어서 사용하는 NSA(비단독모드)를 사용함빨간색으로 표시한 부분이 5G 초기 접속 및 RACH 절차 부분MSG1 ~ MSG4: 스마트폰(UE)이 기지국(gNB)의 존재를 파악(MIB/SIB1)하고, 서로 신호를 주고받으며 무선 연결 통로를 뚫는 과정 FDD & TDDFDD(Frequency Division Duplex): 왕복 2차선 도로원리: 업로드용(UL) 주파수 대역과 다운로드용(DL) 주파수 대역을 아예 따로 분리해서 사용특징: 상/..

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

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

Class vs StructClass와 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..

무중단 Update 종류Blue Green Update: 구버전(Blue)과 신버전(Green)을 나란히 배포하고 신버전으로 일제히 전환하는 방법Canary Update: 지정한 서버 혹은 특정 사용자에게만 새로운 버전으로 업데이트를 시켰다가 정상적인 동작을 확인한 후에 전체를 업데이트하는 방법Rolling Update: 전체를 무중단으로 업데이트하는 방법새로운 이미지의 컨테이너가 배포된 Pod는 점진적으로 추가이전 이미지의 컨테이너가 배포된 Pod는 점진적으로 삭제 Blue Green UpdateLoad Balancer: 트래픽 분산 처리기장점: 빠른 Rollback(예전 버전으로 돌아가는 것)이 가능하며 버전관리가 용이단점: 시스템 자원이 두 배로 필요옛날 버전을 얼마나 붙들고 있는지가 중요ex) 에..

Pod의 AutoScaling 방법운용 중인 Pod의 서비스 상황에 따라 Pod의 수 또는 Pod에 할당된 리소스의 양을 자동으로 조정수요변화와 서비스 품질등을 고려하여 적정하게 자동으로 스케일링HPA(Horizontal Pod Autoscaler, 수평 스케일링)Pod의 개수를 늘리거나(out) 줄임(in)Scale out, Scale inVPA(Vertical Pod Autoscaler, 수직 스케일링)해당 워크로드를 위해 이미 실행 중인 Pod에 더 많은 자원(메모리, CPU) 할당(up) 또는 해제(down)Scale up, Scale down HPA (Horizontal Pod Autoscaler)개념Application의 부하에 따라 Deployment나 ReplicaSet 등에 적용하여 포함..

StatefulSet정의: "상태가 있는(Stateful) 애플리케이션"을 관리하기 위해 Pod의 순서와 고유성을 보장하며 배포하는 컨트롤러Pod들은 동일한 컨테이너 스펙으로 생성되지만, 서로 교체할 수 없는 고유한 식별자와 상태를 가짐재스케줄링(Pod 재생성) 시에도 Pod의 이름과 네트워크 식별자, 스토리지 볼륨이 그대로 유지됨주요 사용처(Use Cases)데이터베이스 및 클러스터링 시스템: MySQL, MongoDB, Redis, Kafka 등 상태와 데이터 유지가 필수적인 워크로드의 90% 이상에 사용워크로드: 컴퓨팅 리소스가 작업 완료 또는 결과 도출을 위해 수행하는 처리 작업의 유형과 양안정적이고 고유한 네트워크 식별자가 필요한 경우안정적인 영구 스토리지(PV)가 필요한 경우순차적인 Pod의..

PacketHandler네트워크 통신(Session)과 게임 로직(Content) 사이를 연결하는 추상화 클래스기존에는 Session 클래스의 OnRecvPacket에서 직접 패킷을 분석하고 처리함패킷의 종류가 늘어날수록 Session 코드가 비대해지는 것을 방지하기 위해 패킷의 생성과 해석만을 전담하는 별도의 클래스 [ GameServer ]ServerPacketHandler.h#pragma once/*------------------------ ServerPacketHandler------------------------*/enum { S_TEST = 1 };struct BuffData { uint64 buffId; float remainTime;};class ServerPacketHandler {p..

Downward APIPod가 자기 자신의 정보(이름, IP, label 등)를 ConfigMap이나 Secret에 미리 정의하지 않고도 런타임에 가져올 수 있게 해주는 기능핵심 개념: k8s 마스터 서버를 통하지 않고, 환경 변수나 볼륨 파일을 통해 포드/컨테이너의 메타데이터를 주입하는 방식환경 변수: 개별적인 값을 하나씩 변수에 할당할 때 사용 (가장 흔한 방식)볼륨 마운트: 정보를 파일 형태로 제공하여 label이나 annotation처럼 내용이 수시로 변할 수 있는 정보를 실시간으로 반영하기에 좋음응용 프로그래머들이 자주 사용함ex1) Redis, MongoDB 같은 분산 시스템을 구축할 때ex2) 모니터링을 위해 여러 Pod에서 로그를 수집할 때ex3) JVM이나 Node.js에서 리소스 제한에..

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

PacketSessionSession 클래스(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 스레..

SendBuffer목적메모리 파편화 해결: 작은 패킷을 보낼 때마다 메모리를 할당/해제하면 시스템 성능이 저하됨할당 비용 감소: 고성능 서버에서는 매 초당 수만 개의 패킷이 오가는데, 그때마다 커널에 메모리를 요청하는 것은 비효율적임수명 보장: 비동기 I/O(IOCP) 특성상 WSASend가 완료될 때까지 버퍼가 살아있음을 보장해야 함전송 흐름Send(): 버퍼를 당장 보내는 것이 아니라 _sendQueue에 일단 담고 RegisterSend가 이미 돌아가고 있다면 종료RegisterSend(): RegisterSend가 준비(_sendRegistered==false)됐다면 큐에 쌓인 모든 버퍼를 _sendEvent의 sendBuffers 벡터에 옮김이때, Scatter-Gather를 위해 wsaBufs..

RecvBuffer 하나의 큰 공용 버퍼를 readPos와 writePos로 관리하는 방식으로 주로 Ring buffer나 Circular buffer 형태를 사용장점단일 버퍼 방식: 하나의 큰 메모리 블록을 미리 할당(Pre-allocation)하여 관리하므로 메모리 관리가 예측 가능하며 시스템 전체의 부하를 줄임포인터 관리: readPos와 writePos만 조절하면 데이터를 실제로 옮기지 않고도 "어디까지 읽었는지"와 "어디에 써야 하는지"를 즉시 알 수 있어, CPU 사이클을 아끼는 결정적인 요인이 됨공용 버퍼: writePos는 계속 뒤로 밀리며 데이터를 채우고, readPos는 완전한 메시지 단위가 구성되었을 때만 이동하면 되므로 데이터의 흐름을 제어하기가 훨씬 수월함TCP와 같은 스트림 기반..

Storage ClassPVC: 사용자가 PV를 배정해 달라고 요청하는 것을 Spec으로 정의해 놓은 것Storage Class: 관리자가 리소스를 통해 생성할 수 있는 PV 유형을 정의해 놓은 것 (PV 생성 및 연결을 추상화한 것)이후 사용자가 PVC를 통해 원하는 Volume을 정의해 놓으면 후에 Pod가 생성될 때 자동으로 PV가 생성되고 PVC에 매핑되어 자동으로 Pod에 마운트 되게 됨 ConfigMap, Secret사용 목적: 설정 정보와 애플리케이션 코드를 분리하기 위함필요 상황 예시: database의 위치정보(IP 주소 or URL)가 이를 이용하는 응용 프로그램 코드 상에 기록하여 사용하는 상황에서 해당 DB의 service IP 주소가 변경되거나 URL이 변경되면 아래의 과정이 필요..

Session 송수신 관련 함수Register (행동 등록)RegisterConnect(): ConnectEx 등록RegisterDisconnect(): DisconnectEx 등록RegisterRecv(): WSARecv() 등록RegisterSend(): WSASend() 등록Process (행동 실행)ProcessConnect(): Client 등록 이후 행동 실행 or 다른 서버에 등록되었을 때 사용ProcessDisconnect(): 서버 Disconnect 시 행동 실행ProcessRecv(): Recv Data 확인 및 처리 (OnRecv() 실행)ProcessSend(): Send Data 확인 및 처리 (OnSend() 실행)On (컨텐츠 코드에서 오버로딩할 함수들)OnConnected(..

IocpObject Ref CountGetQueuedCompletionStatus로 이벤트를 꺼내올 때, 해당 이벤트를 보낸 객체(Listener나 Session)가 종료나 타임아웃으로 인해 메모리에서 해제되었을 가능성 발생이를 방지하기 위해 스마트 포인터 도입(IocpCoreRef, IocpObjectRef, SessionRef, ListenerRef, ServerServiceRef)enable_shared_from_this 상속: IocpOjbect가 자기 자신의 스마트 포인터를 안전하게 반환할 수 있도록 해 줌IocpEvent 내 Owner 보관: IocpEvent 구조체 내에 IocpObjectRef owner를 보관함으로써, 예약된 IO가 완료될 때까지 관련 객체의 참조 카운트가 유지되도록 보장..