write()와 fsync() 사이, 데이터가 머무는 네 장소 🔍 진짜 시리즈 - Chap1. write()와 fsync() 사이, 데이터가 머무는 네 장소 개요 Redis의 AOF, MySQL의 redo log, Kafka의 세그먼트 파일은 모두 "저장했다"는 말을 자기 방식으로 정의합니다. 그 정의를 따라 내려가면 결국 같은 자리에 도착합니다. 프로그램이 write()를 부르고, 커널이 페이지 캐시에 받아 두고, 언젠가 fsync()가 디스크에 내려보내는 경로입니다. 이 시리즈는 오픈소스가 그 경로의 어느 지점에서 무엇을 호출하는지, 그 사이에 프로세스가 죽거나 전원이 나가면 어디까지 남는지를 실제로 실행하고 측정해서 확인하는 것을 목표로 합니다. 첫 글은 그 공통 경로 자체를 다룹니다. Go로 쓴 작은 프로그램을 Linux VM에서 돌리고, strace와 /proc/meminfo로 데이터가 어디에 있는지 따라갑니다. 본문의 수치와 실험 결과는 모두 실제 측정값입니다. 1.

집에서 굴리는 온프레미스 쿠버네티스 클러스터에 GPU 노드를 한 대 붙였습니다. ASUS Ascent GX10, NVIDIA DGX Spark 계열의 워크스테이션입니다. 기존 클러스터는 control-plane 3대와 worker 3대로 돌아가고 있었고, 노드를 늘리는 일은 그동안 몇 번 해 봤기 때문에 한 줄이면 끝날 거라고 생각했습니다. 실제로는 조인이 붙고 나서도 노드가 정상 상태가 되기까지 네 군데에서 막혔습니다. 원인은 전부 이 노드가 기존 여섯 대와 다른 지점에서 나왔습니다. 유일한 arm64이고, OS 이미지가 벤더가 만든 것이고, GPU와 CPU가 메모리를 공유하고, 네트워크 인터페이스 이름이 다릅니다. 하나하나는 사소한데, 클러스터 쪽 설정이 나머지 노드를 기준으로 맞춰져 있다 보니 전부 걸림돌이 됐습니다. 클러스터는 v1.30.14, CNI는 Cilium(native routing), 런타임은 containerd입니다. 본론에 들어가기 전에 이 하는 일을 짚어 두

Pod Security Standards, Linux capability, seccomp는 컨테이너 프로세스가 호스트 커널에 요청할 수 있는 범위를 줄입니다. 를 적용하고 capability를 모두 내려놓더라도, 허용된 시스템 콜을 처리하는 주체는 여전히 호스트 커널 하나입니다. gVisor는 이 경계를 다른 위치에 둡니다. 컨테이너의 시스템 콜을 호스트 커널에 바로 넘기지 않고, user-space에서 실행되는 별도 프로세스가 먼저 처리합니다. 이 글에서는 gVisor가 줄이려는 공격면과 Sentry·Gofer·systrap의 역할, 이 구조에서 생기는 호환성 및 성능 비용을 정리합니다. 1. 컨테이너 격리가 실제로 나누는 것 컨테이너는 하이퍼바이저 없이 도는 프로세스입니다. 격리는 커널이 제공하는 몇 가지 기능을 조합해서 만듭니다. namespace가 프로세스가 보는 자원 목록을 분리하고, cgroup이 CPU·메모리·I/O 사용량의 상한을 걸고, capability가 root

지난 넉 달간 나온 이름들을 모아봤습니다. harness engineering, loop engineering, graph engineering, loopcraft. 그 안에 다시 agent loop, verification loop, event-driven loop, hill climbing loop이 있습니다. 다른 글에서는 같은 것을 heartbeat loop, cron loop, hook loop, goal loop으로 나눠 부릅니다. 그래프 쪽에는 org graph와 work graph가 있고, 그것들을 돌리는 graph harness가 있습니다. 이 목록을 정리하다가 어릴 때 장난감마다 이름을 지어주던 기억이 떠올랐습니다. 장난감이 늘어나면 이름도 늘어나야 하고, 이름을 붙이는 동안은 그게 꽤 중요한 일처럼 느껴집니다. 이름이 붙은 것들의 실체 heartbeat loop, cron loop, hook loop, goal loop을 이름 없이 옮기면 이렇게 됩니다. 짧은 주

Pod 하드닝의 출발점은 보통 네임스페이스에 Pod Security Standards를 강제하는 일입니다. 라벨 한 줄이지만, 이미 그 네임스페이스에서 돌고 있던 워크로드에는 파급이 큽니다. 저는 이 라벨을 걸고 기존 nginx Deployment를 그대로 다시 올렸다가 서로 다른 이유로 네 번 연속 실패했습니다. 원인은 admission 거부, 파일 권한, 그리고 Linux capability set과 커널의 전이 규칙까지 네 층에 걸쳐 있었습니다. 각 실패마다 필요한 개념(//, UID/GID 기반 파일 권한, capability의 다섯 가지 set)을 등장한 순서대로 정리합니다. 1. 라벨을 걸고 기존 Deployment를 올리다 는 Pod Security Standards 세 프로파일(, , ) 중 가장 엄격한 단계입니다. 컨테이너가 root로 실행되는 것을 막고, capability를 전부 제거하며, privilege escalation과 seccomp 설정까지 함께 요구

"서버가 터졌습니다." 서버가 터졌다는 말은 대체 뭘 의미하는걸까요? 누가 서버가 왜 터졌냐고 물어보면, 단순히 "트래픽이 너무 많이 들어와서"라고 답변하는 것은 부족할지 모릅니다. 본 포스트에서는 서버가 터지는 과정을 low-level 네트워크부터 커널스페이스, 유저스페이스, 크게는 인프라 전체에 걸쳐서 바텀업 방식으로 살펴보고자 합니다. 물리 서버 4대가 있다고 합시다. 1대는 nginx로 reverse proxy 역할을 하고, 나머지 3대(A, B, C)가 각각 같은 웹 서비스를 구동하며 트래픽을 1/3씩 나눠 받습니다. 어느 순간 서버 A가 모종의 이유로 멈춥니다. 그리고 오래지 않아 B와 C도 차례로 멈추면서 시스템 전체가 불능 상태가 됩니다. A 한 대의 장애가 어떻게 나머지 두 대의 자원까지 끌고 내려가는지, 그리고 애초에 "자원이 부족하면 요청을 거부하면 되지 않나"라는 질문에 왜 실제 시스템들은 그렇게 하지 않는지를 커널부터 인프라까지 순서대로 따라가 보겠습니다. 이