Virtual World

목차1. 문제 배경: Redis는 왜 갑자기 죽었을까?2. 배경 지식: Redis의 BGSAVE와 Copy-on-Write3. 실험 목적: Copy-on-Write가 실제로 OOM을 유발하는가?4. 실험 환경: Docker 기반 Redis 컨테이너 구성5. 실험 과정: Copy-on-Write 상황 유발 및 메모리 관측6. 실험 결과: Copy-on-Write로 인한 메모리 폭증은 실제로 발생했다7. 실험을 통해 알게 된 것8. 결론9. Github 링크1. 문제 배경: Redis는 왜 갑자기 죽었을까?Redis가 예고 없이 종료될 수 있습니다.Redis의 maxmemory는 6GB로 설정되어 있었고,컨테이너의 메모리 제한은 7GB였으며,메모리 사용량이 한계에 가까운 시점에서 BGSAVE가 실행되었고,그..

들어가기에 앞서 좌측 그림은 데이터를 메모리에 선형적(Row-Major)으로 저장, 탐색하는 방식,우측 그림은 Z-order 기반으로 정사각형 블록 단위로 저장, 탐색하는 방식입니다.이 두 가지 방식의 차이가 공간 데이터 처리 성능에 어떤 영향을 미치는지 살펴보겠습니다. 현대의 지도 서비스, 자율주행 시뮬레이션, 지리 정보 시스템(GIS) 등은 방대한 공간 데이터를 실시간으로 탐색하고 처리해야 합니다.하지만 이러한 데이터를 단순히 행렬 순서(예: Row-Major)로 저장하면, 지리적으로 가까운 두 점이 메모리 상에서는 멀리 떨어져 저장될 수 있습니다. 이는 CPU 캐시 효율을 낮추고 데이터 접근 성능을 저하시키는 주된 원인이 됩니다. 이러한 문제를 해결하는 대표적인 방식이 Z-order Indexing..

들어가기에 앞서 일반적인 서버의 목적은 클라이언트 요청에 대해 적절한 응답을 빠르고 효율적으로 반환하는 것입니다.즉, 대부분의 서버는 다음과 같은 단순한 I/O 루틴을 반복합니다. "입력(요청)을 받고 → 출력(응답)을 보낸다." 예를 들어, 웹 서버는 클라이언트의 요청에 따라 정적 파일(HTML, 이미지 등)을 전송하고,WAS(Web Application Server)는 DB에서 읽어온 사용자 데이터를 API 응답으로 보내며,FTP 서버는 파일을 반환합니다. 이러한 동작들은 모두 단순한 코드로 표현할 수 있습니다.read(fd, buffer, size);send(socket, buffer, size);하지만 이 단순한 동작 이면에서는 여러 번의 데이터 복사와 사용자 공간(user space)과 커널..

로그는 왜 중요할까요?단순한 기록처럼 보이던 로그가, 어떻게 시스템 간 데이터 흐름, 복구, 재처리, 확장을 가능하게 만드는 걸까요?이 글에서는 로그 기반 아키텍처의 핵심 철학을 정리했습니다. 들어가기에 앞서 우리는 서비스를 만들 때 다양한 시스템을 함께 사용합니다.데이터베이스(DB): 사용자 정보, 거래 내역 등 구조화된 데이터를 저장캐시(Redis 등): 빠른 응답을 위해 임시로 데이터를 저장검색엔진(Elasticsearch): 텍스트 기반 검색과 분석을 지원분석 시스템(Hadoop, Spark): 데이터를 수집하고 집계하여 비즈니스 인사이트를 도출이 각각의 시스템은 서로 다른 목적과 다른 형식의 데이터 처리 방식을 갖고 있습니다. 문제는 여기서 시작됩니다.이 시스템들이 하나의 흐름 속에서 유기적으로..

시분할(Time Sharing)은 하나의 컴퓨터 자원을 여러 사용자가 시간을 나눠가며 동시에 사용하는 것처럼 보이게 만드는 기술입니다.혹은, 한 사용자가 여러 작업을 동시에 수행하는 것처럼 보이게 만들기도 합니다. 예를 들어, 컴퓨터로 노래를 들으면서 게임을 하고 있는데, 그 와중에 친구에게 카카오톡 메시지가 도착했다고 해봅시다.사실 컴퓨터는 한 번에 하나의 작업만 처리할 수 있는 구조입니다.하지만 CPU는 각 작업에 아주 짧은 시간(몇 밀리초)을 번갈아가며 배정해주기 때문에 사용자는 마치 노래, 게임, 메신저가 동시에 작동하는 것처럼 느끼게 됩니다.이처럼 짧은 시간 단위로 작업을 나누어 번갈아 실행하는 방식이 바로 시분할(Time Sharing)입니다. UNIX는 이 시분할(Time Sharing) 개..

목차1. 3D Tiles 개요2. B3DM (Batched 3D Model)3. B3DM이 필요한 이유4. B3DM이 제공하는 해결책5. B3DM의 식별성과 속성 관리6. B3DM 내부 구조  6-1. Header  6-2. Body    6-2-1. Feature Table (* 필수)    6-2-2. Batch Table (선택)    6-2-3. Binary glTF 또는 GLB (* 필수)7. B3DM Padding 정렬 규칙8. B3DM 요약9. 참고 자료3D Tiles 개요3D Tiles는 대규모 3차원 공간 데이터를 웹에서 효율적으로 스트리밍하고 렌더링하기 위한 오픈 표준 포맷입니다.주로 CesiumJS, Google Maps, NVIDIA Omniverse와 같이 3D GIS, BIM, ..