Bansanka

Database는 매 요청마다 disk의 data page를 즉시 안전하게 고쳐 쓰지 않습니다.대부분의 storage engine은 memory 안에서 page를 먼저 바꾸고, 변경 기록을 log에 남긴 뒤, 실제 data page flush는 나중에 처리합니다.이때 장애가 나면 자연스럽게 질문이 생깁니다.“COMMIT이 성공했다고 응답했는데 서버 전원이 꺼지면 데이터는 어디까지 살아남을까?”이 질문의 핵심에 있는 개념이 WAL, 즉 Write-Ahead Log입니다. WAL의 핵심은 data page를 영구 저장소에 반영하기 전에, 그 변경을 복구할 수 있는 log record를 먼저 durable 하게 기록하는 것입니다. WAL은 commit durability와 crash recovery를 연결하는..

서비스가 커지면 하나의 cache node나 storage node에 모든 key를 넣기 어렵습니다.그래서 여러 node로 key를 나누는 sharding을 사용합니다.가장 단순한 방식은 hash(key) % node_count이지만, node가 추가되거나 제거되는 순간 많은 key가 한꺼번에 이동하는 문제가 생깁니다.Consistent hashing은 이 문제를 줄이기 위해 hash space를 ring처럼 보고, key가 이동해야 하는 범위를 제한하는 방법입니다. Consistent hashing의 핵심은 node 수가 바뀌어도 전체 key를 다시 나누지 않고, 바뀐 node 주변의 key만 이동시키는 것입니다. Consistent hashing은 cache sharding, distributed s..

브라우저 주소창에 도메인을 입력하면 애플리케이션은 곧바로 서버에 연결하는 것처럼 보입니다.하지만 실제로는 먼저 도메인 이름을 IP address로 바꾸는 DNS Lookup 과정이 필요합니다.이 과정은 보통 매우 빠르게 끝나지만, 장애가 나면 “서버는 살아 있는데 접속이 안 된다”, “일부 사용자만 예전 서버로 간다”, “배포 후 트래픽 전환이 예상보다 늦다” 같은 문제로 나타납니다.오늘은 DNS Lookup이 어떤 순서로 일어나는지, Cache TTL이 왜 중요한지, 실무에서 어떤 지점을 봐야 하는지 정리해보겠습니다. DNS Lookup은 도메인 이름을 IP address로 바꾸는 과정이고, TTL은 그 결과를 resolver와 client가 얼마나 오래 cache할 수 있는지 정하는 값입니다. DNS..

성능 이슈를 볼 때 algorithm complexity만 확인하면 충분하다고 생각하기 쉽습니다.하지만 같은 O(n) 코드라도 data layout과 memory access pattern에 따라 실제 실행 시간은 크게 달라질 수 있습니다.CPU는 main memory에서 값을 매번 직접 읽지 않고, cache line 단위로 데이터를 가져와 L1, L2, L3 cache를 통해 접근 비용을 줄입니다.이 구조를 이해하면 왜 연속된 배열 접근이 빠르고, 왜 멀티스레드 코드에서 서로 다른 변수만 수정해도 느려질 수 있는지 설명할 수 있습니다. Cache locality는 CPU가 이미 가져온 cache line을 얼마나 잘 재사용하는가의 문제이고, false sharing은 서로 다른 data가 같은 cac..

프로그램에서 pointer 값을 출력하면 마치 실제 memory 주소를 직접 보는 것처럼 느껴질 때가 있습니다.하지만 현대 운영체제에서 application이 보는 주소는 대부분 Virtual address입니다.실제 Physical memory의 어느 위치를 쓰는지는 MMU, Page table, 운영체제 memory manager가 함께 결정합니다. Virtual memory는 Process가 독립된 address space를 가진 것처럼 보이게 만드는 모델이고, Page fault는 필요한 page가 현재 Physical memory에 없을 때 운영체제가 개입하는 사건입니다. 이번 글에서는 Virtual memory, Page table, Page fault, TLB가 각각 어떤 역할을 하는지, 그..

파일을 읽고, 로그를 쓰고, 네트워크 socket으로 데이터를 보내고, DB connection을 여는 일은 모두 평범한 application code처럼 보입니다.하지만 이 작업들은 대부분 어느 순간 운영체제 kernel의 도움을 받아야 합니다.개발자가 작성한 함수 호출만으로는 disk, network, process, memory protection 같은 자원에 직접 접근할 수 없기 때문입니다. System call은 user mode에서 실행 중인 program이 kernel mode의 운영체제 기능을 안전하게 요청하는 경계입니다. 이번 글에서는 System call이 무엇인지, User mode와 Kernel mode는 왜 나뉘는지, Context switch와는 무엇이 다른지, 그리고 작은 IO..

C++에서 지역 변수는 stack에 잡히고, new로 만든 객체는 heap에 잡힌다는 설명을 한 번쯤 들어봤을 것입니다.그런데 실무에서 memory 문제를 볼 때는 이 문장만으로 부족합니다.stack overflow, memory leak, dangling pointer, large allocation, recursion, global object 초기화 문제는 모두 Process memory layout을 이해해야 제대로 해석할 수 있습니다. Process memory layout은 프로그램 코드, 전역 데이터, 동적 할당 객체, 함수 호출 정보를 운영체제가 한 Process의 Virtual address space 안에서 어떻게 구분해 관리하는지 보여주는 지도입니다. 이번 글에서는 Text, Data..

웹 페이지가 열리고, 앱이 API를 호출하고, 서버가 DB에 연결하는 과정 뒤에는 대부분 TCP connection이 있습니다.개발자는 보통 HTTP 요청, SQL Query, socket read/write 같은 application level을 먼저 보지만, 실제 통신이 시작되기 전에는 TCP 3-way handshake가 먼저 일어납니다.그리고 통신이 끝난 뒤에도 connection은 바로 사라지지 않고 TIME_WAIT 같은 상태로 잠시 남을 수 있습니다. TCP 3-way handshake는 양쪽이 통신 가능한 상태인지 확인하고, TIME_WAIT은 닫힌 connection 주변의 늦은 packet을 안전하게 정리하기 위한 상태입니다. 이번 글에서는 TCP connection이 어떻게 만들어지는..

DB Index를 처음 배우면 이런 생각을 하기 쉽습니다.“Index를 만들었으니 이 Query는 빨라질 것이다.”하지만 실무에서는 Index가 있는데도 Query가 느린 경우를 자주 만납니다.이때 문제를 제대로 보려면 Index 존재 여부가 아니라, Optimizer가 실제로 어떤 Execution plan을 선택했는지를 확인해야 합니다. Index는 “만들면 무조건 쓰이는 장치”가 아니라, Optimizer가 Cost를 계산해 선택할 수도 있고 선택하지 않을 수도 있는 Access path입니다. 이번 글에서는 DB Index가 있어도 Query가 느려지는 이유를 Selectivity, Composite index, 함수로 감싼 컬럼, Execution plan 관점에서 정리해보겠습니다. Ind..

멀티스레드와 운영체제를 공부하다 보면 race condition이라는 표현을 자주 만나게 됩니다.한국어로는 보통 경쟁 상태라고 부릅니다.말 그대로 여러 실행 흐름이 같은 데이터나 자원을 두고 경쟁하면서, 실행 순서에 따라 결과가 달라지는 문제입니다.프로세스와 스레드, 데드락을 이해했다면 그다음으로 반드시 짚고 넘어가야 하는 동시성 개념입니다. Race condition은 여러 작업이 공유 자원에 동시에 접근하고, 그 접근 순서가 결과를 바꿀 때 발생하는 동시성 버그입니다. 이번 글에서는 race condition이 무엇인지, 왜 재현하기 어려운지, C++ 코드와 DB 예시에서는 어떻게 나타나는지, 실무에서는 어떤 기준으로 예방해야 하는지 정리해보겠습니다. 1. Race condition은 무엇인가?Rac..