VIRGIL ABLOH

PostgreSQL Shared Buffer 영역(작성중)

VIRGIL ABLOH — Sun, 19 Apr 2026 13:43:08 +0900

일단 shared buffer 영역이 존재하는 이유는 매번 쿼리를 날릴때마다 DB는 디스크에 접근해서 데이터를 가져오기엔 비용과 부하가 발생한다.

이걸 해결하려면 메모리에 데이터를 미리 캐싱해서 올려두면 매번 디스크 IO를 발생시키지않고 응답속도와 비용절감을 가능케할 수 있다.

일단 책을 읽어보면서 buffer descrioptor는 무슨 역할을 하는지 궁금하게 했다.

순수하게 텍스트로 보면 그냥 버퍼 설명하는 주체?라고 생각하게 된다.

책에서는 Lock이라는 설명이 들어있었다 그래서 내가 아는 비관적/낙관적 락을 관리하는 주체인가? 해서 제미나이한테 물어보니 내가 아는 락이 아니라 shared pin이라고 shared buffer영역에서 사용되는 개념이였다. 말그대로 쿼리로 인해서 해당 테이블 데이터를 사용중이라는 lock 즉 pin을 건다는 개념인것이다.

그래서 예시를 들어서 개념을 확고하게 해보았다.

PostgreSQL은 보통 Clock Sweep이라는 알고리즘을 사용합니다. 시계 바늘이 돌면서 "너 요즘 자주 쓰이니?"라고 물어보고 다니는 방식이죠.

상황 가정
1번 버퍼 (1번 테이블): Usage Count = 11, Pin = 0 (아무도 안 쓰는 중)
2번 버퍼 (2번 테이블): Usage Count = 7, Pin = 1 (현재 질문자님이 읽는 중)
새로운 3번 테이블: 메모리로 들어오고 싶어 함 (자리 없음)
진행 과정
희생양 찾기: 시계 바늘이 돌면서 어떤 버퍼를 비울지 검사합니다.
2번 버퍼 검사: Usage Count가 7로 낮지만, Pin이 1인 것을 확인합니다.
결과: "오, 이건 누군가 지금 쓰고 있네? 건드리면 큰일 나겠다!" 하고 무조건 건너뜁니다. (Pin의 위력)
1번 버퍼 검사: Usage Count가 11로 높습니다. 시계 바늘은 이 카운트를 하나 깎습니다 ($11 -> 10$).
만약 모든 버퍼가 다 바쁘다면 바늘이 여러 바퀴 돌겠죠? 그러다 Usage Count가 0이 되고 Pin이 0인 녀석을 발견하면 그게 바로 희생양이 됩니다.

해시함수

간단히 이야기하면 어느 buffer descriptor에 있는지 태그해놓은 정보를 모아놓은 공간이다.

이렇게하면 모든 buffer descriptor에 있는 정보들을 확인하지 않아도 찾으려는 테이블의 페이지를 빨리 찾을 수 있다.

Hash(key) -> Mod(key, length) -> HashValue(result)

위의 공식을 이용해서 어떻게 해시값을 얻는지 정리해보자

key는 가변길이의 입력값, length는 해시 테이블의 길이라고 하자.

1. 유저가 abc라는 값을 저장하고 싶다. 그리고 해시 테이블의 길이는 100

2. 내부에서는 컴퓨터가 알아들을수 있도록 abc값을 hash함수를 이용해서 정수값으로 변환

3. 반환받은 정수값을 이용해서 Mod(-785388649, 100)로 계산하면 나머지값을 반환, 결과값: -49

4. 결과값이 음수일 경우라면 내부적으로 양수로 변환하여 49, 결국 해당 위치에 실제 데이터가 있다고 길을 알려줌

해시 테이블

해시 테이블의 내부 구조에 대해서 백화점의 보관함을 예시로 들어보자

#   도서관 수장고 비유로 보는 PostgreSQL 데이터 검색

### 1. 입력 키 (Key): "조선왕조실록 태조편"
* **상황:** 내가 찾고 싶은 책 제목입니다.
* **동작:** 이 제목을 '해시 함수'라는 자동 분류기에 넣으면 **256**이라는 숫자가 튀어나옵니다.

---

### 2. 해시 테이블 (Bucket [256])
* **상황:** 수장고에 있는 수만 개의 보관함 중 **256번 보관함**을 가리킵니다.
* **동작:** "태조편은 무조건 256번 함에 있다"라는 규칙에 따라 해당 위치로 바로 이동합니다.

---

### 3. 버퍼 파티션 (Buffer Partition)
* **상황:** 256번 보관함이 있는 **'제1구역'의 관리자**입니다.
* **동작:** 관리자에게 "256번 함을 열겠습니다"라고 허락을 구합니다(Lock). 
    * *덕분에 다른 구역(파티션)에서 책을 찾는 사람들과 서로 동선이 겹치지 않습니다.*

---

### 4. 디렉토리 및 해시 세그먼트
* **상황:** '제1구역' 안에 나열된 **보관함들의 복도**입니다.
* **동작:** 관리자의 허락 하에 복도를 따라 256번 보관함 앞에 도착합니다.

---

### 5. 해시 엘리먼트 (Buffer Tag)
* **상황:** 256번 보관함을 열었을 때 들어있는 **실제 책들과 이름표**입니다.
* **동작:** 보관함 안에 여러 권의 책이 있을 수 있으므로(해시 충돌), 책에 붙은 태그를 하나씩 확인합니다.
    * 1번 책 태그: '고려사' (Pass)
    * 2번 책 태그: **'조선왕조실록 태조편' (Match!)**
* **최종 결과:** 태그에 적힌 **Buffer ID**를 보고 메모리상의 실제 데이터 위치를 찾아냅니다.

---

위 예시에서 3번 동작에서 Lock을 건다라고 하는데 해당 락은 Light Weight Lock으로 내부 병목현상을 발생하지 않게하기 위해 경량화 락을 사용한다.

그리고 버퍼 파티션마다 LW Lock을 부여하여 동시에 접근요청이 오더라도 분산하여 관리하기 때문에 오랜 대기 및 부하를 줄이도록 하였다.

근데 지금까지보면 데이터를 금방 찾아오는 방법에 대해서 내부구현을 설명했다.

생각해보니 빨리 찾아오는거면 이건 결국 인덱스 라는 개념이지 않을까 하는 생각이 들었다.

제미나이에게 물어보니 인덱스와 해시 테이블은 결국 영구적인지 임시적인 매커니즘인지에 대한 차이라고 한다.

인덱스는 영구적인 데이터 위치 지도이고, 해시 테이블은 postgresql의 메모리에 있는 임시적인 데이터 위치 지도인것이다.

그래서 만약 메모리에 없으면 직접 디스크 IO를 발생시켜서 데이터를 가져오기때문에 비용문제와 함께 메모리에서 가져오는 방식보다는 시간이 걸릴것이다. 그래서 이런 구멍을 메우기 위해 인덱스 방식이 존재하는 것이다.

만약 '서울시' 와 '부산시'가 같은 해시값을 반환하게 되어 같은 위치의 버킷에 할당하게 되면

해시 충돌이 일어난다. 만약 '서울시' 라는 값이 해시 버킷에 저장되어있고 그 다음에 '부산시'가 같은 해시 버킷에 들어오면 '부산시' 앨리먼트 '서울시' 앨리먼트와 연결이 된다. 즉 '부산시' 앨리먼트는 해시 버킷에 저장되지 않고 '서울시' 앨리먼트와 연결이 되는걸 의미하는 단어로 chaining 이라고 부른다.

해시 엘리먼트

해시 엘리먼트는 버킷에 들어있는 실제 값을 의미하며 해시 엔트리라고도 불린다.

내부에는 hash value, 버퍼 태그, 버퍼 ID 구성되어있다.

hash value는 해시함수를 이용하여 생성된 값을 의미한다. 내부에서 고유한 값

버퍼 ID는 버퍼 풀이라는 거대한 보관함 전체를 의미한다고 하면 버퍼는 그 중의 칸 하나하나를 의미하고 버퍼 ID는 보관함 칸 한개의 ID를 생각하면 될것 같다.

버퍼 태그는 메모리에 올라와있는 데이터를 식별할수 있는 메타데이터라고 보면 될것같다. 즉, 실제 데이터가 어느페이지에 있는지 알 수 있다.

SELECT
    b.bufferid AS "버퍼 ID",
    b.reltablespace AS "SpcNode(OID)",
    t.spcname AS "테이블스페이스명",
    b.reldatabase AS "DbNode(OID)",
    d.datname AS "데이터베이스명",
    b.relfilenode AS "RelNode(OID)",
    c.relname AS "테이블/인덱스명",
    b.relforknumber AS "포크 번호",
    b.relblocknumber AS "블록 번호"
FROM
    pg_buffercache b
        LEFT JOIN pg_database d ON b.reldatabase = d.oid
        LEFT JOIN pg_class c ON b.relfilenode = c.relfilenode
        LEFT JOIN pg_tablespace t ON b.reltablespace = t.oid
WHERE
    b.reldatabase = (SELECT oid FROM pg_database WHERE datname = current_database())
  AND c.relname IS NOT NULL and c.relname = '테이블명'
ORDER BY
    b.bufferid

위 쿼리를 이용해서 해당 테이블 데이터가 메모리 어디에 할당받고 있는지 알수 있다.

값	항목명 (이전 그림 기준)	의미와 해석 (비유)
1286	버퍼 ID (Buffer Id)	"현재 이 데이터는 메모리(공유 버퍼)의 1286번 칸에 들어있습니다." 가장 핵심이 되는 보관함 번호입니다.
1663 pg_default	테이블스페이스 OID 테이블스페이스명	"이 데이터의 하드디스크 상 저장 구역은 기본 구역(pg_default)입니다." PostgreSQL이 설치될 때 기본적으로 만들어지는 디스크 저장 위치를 뜻합니다.
5 postgres	데이터베이스 OID 데이터베이스명	"이 데이터는 postgres라는 데이터베이스 소속입니다." 건물로 치면 'postgres'라는 회사의 사무실(5번 방) 물건입니다.
16512 users	릴레이션 OID 테이블/인덱스명	"이 데이터는 users라는 테이블의 데이터입니다." 사무실 안의 16512번 서랍장(users 테이블)에서 꺼내온 물건입니다.
0	포크 번호 (ForkNum)	"이것은 테이블의 '진짜 본문 데이터(Main)'입니다." PostgreSQL에서 0번은 실제 데이터 본문을 의미합니다. (참고로 1번은 빈 공간 정보, 2번은 데이터 표시 여부 등 관리용 정보입니다.)
0	블록 번호 (BlockNum)	"이것은 users 테이블 파일의 가장 '첫 번째 조각(블록)'입니다." 데이터베이스는 데이터를 8KB 크기의 블록으로 쪼개서 저장하는데, 그중 0번째(맨 처음) 페이지라는 뜻입니다.

PostgreSQL FORK 영역

VIRGIL ABLOH — Sun, 22 Mar 2026 13:56:22 +0900

create table tab_OID(id integer); --테이블생성
-- 위에서 생성한 테이블의 oid 조회
select OID, relname from pg_class where relname ='tab_oid'; --16426,tab_oid
select 'tab_oid'::regclass::oid; --16426

생성한 테이블의 OID 조회 가능

main fork에 대해서

데이터를 저장하는 파일의 용량이 1GB를 넘기게 되면 DB는 해당 파일을 세그먼트로 나눠서 관리하게 된다 이때 relfilenode이라고 명칭한다.

예들을어 oid=111인 객체 즉 테이블(relfilenode=16000으로 테이블 생성시 선언되는 값)이 1GB를 넘기게 되면 새로운 파일의 relfilenode은 16000.1, 16000.2, 16000.3 ... 이라고 세그먼트 파일이 생성된다. 만약 VACUUM FULL이 동작해서 delete된 파일들을 정리해서 새로운 relfilenode이 생기면 17000로 생성하여 해당 파일에 남은 데이터들을 이동한다.

위의 내용을 정리한 표이다.

구분	상세 내용
기본 파일명	테이블 생성 시 pg_class의 relfilenode 값을 이름으로 가짐 (예: 16000)
세그먼트 분할	파일이 1GB에 도달하면 16000.1, 16000.2 식으로 확장됨
일반 VACUUM	기존 파일(16000) 내부의 쓰레기만 치움. 파일명 유지.
VACUUM FULL	새 파일(17000)을 만들어 유효 데이터만 이사 시킴. 파일명 변경.
연결 고리	파일명이 바뀌면 pg_class 장부의 relfilenode 컬럼 값도 새 번호로 갱신됨

free space map(fsm)

데이터가 변경되면 빈공간이 생기게 된다. 그이후에 추가되는 값은 어느 relfilenode에 저장할지 판단해야된다.

이때 fsm을 확인해서 해당 테이블의 relfilenode의 어느 페이지(page)로 갈지 판단한다.

relfilenode를 조회했을때 16000이면 fsm 파일명은 16000_fsm으로 생성된다.

만약 새로 생성한 테이블이면 oid값과 relfilenode값은 서로 같을수 있다.

위의 내용을 정리한 표이다.

구분	상세 내용
데이터 변경(Update/Delete)	기존 자리에 구멍(빈 공간)이 생김
FSM 업데이트	VACUUM이나 일반적인 작업 중에 "이 페이지에 자리가 났다"고 _fsm 파일에 기록함
새 데이터 입력(Insert)	_fsm 지도를 보고 빈 구석을 찾아 들어가서 공간을 알뜰하게 재활용함
연결	relfilenode(실제 파일) + _fsm(빈자리 지도) + _vm(청소 지도)은 항상 세트로 움직임

fsm 확인방법

CREATE EXTENSION pg_freespacemap;
create table t1
(
    id   integer,
    name char(2000)
);
alter table t1 set(autovacuum_enabled=false);

insert into t1
select i as id, 'aaa' as name
from generate_series(1, 20) a(i);

select * from pg_freespace('t1');

update t1 set name='bbb';
select * from pg_freespace('t1');

데이터 업데이트를 하면 데드 튜플이 증가되어 페이지 갯수는 2배로 증가함을 확인 가능

vaccum을 동작시켜서 dead tuple을 정리

vacuum t1;

select *, round(100 * avail / 8192, 2) as freespace_ratio
from pg_freespace('t1');

업데이트된 tuple은 유지되고 dead 처리된 tuple들은 비활성화되어서 freespace가 초기화됨을 확인

VM(Visibility Map)

VM(Visibility Map)은 테이블의 페이지 단위로 해당 페이지의 모든 tuple이 visible한지(all-visible) 를 관리한다.
Vacuum은 VM을 참고하여 이미 all-visible인 페이지는 스캔을 건너뛰어 성능을 높인다.
즉 all-visible하지 않은 페이지라면 vaccum에게 해당 페이지 확인해서 vaccum처리하라고 알려주는 파일이다.
또한 VM의 all-visible 정보 덕분에 Index Only Scan이 가능하며, 이 경우 heap(실제 테이블)을 직접 조회하지 않아도 된다.

SHOW data_directory; --/var/lib/postgresql/data
select pg_relation_filepath('테이블명'); --base/5/16412

해당 path들을 검색해서 postgresql에서 관리하는 fork 영역을 관리하는 파일들을 직접 확인 가능하다.

select 쿼리 동작

먼저 해당 테이터 index에서 id를 조회하여 어느 페이지에 저장되었는지 찾는다.
해당 페이지의 vm을 확인해서 all-visible하면 index에 저장된 값을 바로 반환한다.(비용절감됨)
만약 all-visible하지 않은 데이터라면 실제 데이터가 저장된 디스크에서 읽어서 값을 반환한다.

all-visible과 all-frozen

all-visible은 해당 페이지는 인덱스에 저장된 값을 바로 반환해도 된다는 의미

vaccum에게도 skip해도된다는 의미지만 낮은 확률로 vaccum 동작할수 있음

all-frozen은 해당 페이지는 절대 값이 변하지 않는다는 의미

비트값이 1 즉 true면 해당 페이지는 vaccum이 아예 동작하지 않아도 된다는 의미

all-visible/all-frozen

테이블 생성되고 데이터가 입력되면 vm의 값은 0,0 조합

vaccum이 동작되면 vm의 값은 1,0 또는 1,1 상태가 된다.(vaccum이 동작했기때문에 all-visible=true가 된다.)

vaccum freeze 옵션으로 동작시키면 무조건 1,1이 된다.

delete,update 쿼리가 수행하면 항상 0,0이 된다.

vm 정보 확인 테스트

drop table t1; -- 기존 테이블 삭제

create table t1
(
    id   integer,
    name char(2000)
); -- 테이블 생성

insert into t1
select i as id, 'aaa' as name
from generate_series(1, 10) a(i); -- 데이터 입력

select blkno, all_visible, all_frozen
from pg_visibility('t1');

빈 페이지에 insert가 발생하면 all-visible,all-frozen은 0 즉 false로 반환된다.

빈 페이지에 데이터가 저장되면 모든 값은 false

vacuum t1; -- vaccum 동작

select blkno, all_visible, all_frozen
from pg_visibility('t1'); -- 조회

vaccum을 동작시키면 all-visible은 true

update t1
set name = 'ccc'
where id = 1; -- update로 인해 dead tuple 발생

dead tuple이 발생하여 all-visible이 false

잠깐! 왜 where절로 한개의 로우만 업데이트 했는데 두개의 페이지가 all-visible=false처리되었냐면 update쿼리는 변경된 값을 insert 처리하기 때문에 dead tuple이 발생한 페이지와 업데이트되어 insert된 페이지 총 2개의 페이지가 all-visible=false처리가 된다.

vacuum freeze t1; --vaccum freeze 수행

select blkno, all_visible, all_frozen
from pg_visibility('t1'); -- 확인

모든 페이지의 all-visible과 all-freeze가 true

이렇게 되면 '현재 노출할 수 있는 데이터는 최신화 데이터라서 더이상 확인할 필요가 없다' 라는 의미가 된다.

PostgreSQL 대해

VIRGIL ABLOH — Tue, 17 Feb 2026 16:56:11 +0900

PostgreSQL은 시스템 메모리가 1GB 이상일 경우 전체 메모리의 약 25%를 shared_buffers로 설정하는 것이 일반적이다.
PostgreSQL은 DB 내부 버퍼(shared_buffers)와 OS의 페이지 캐시를 함께 활용하는 구조이기 때문에, shared buffer를 과도하게 크게 설정하지 않는다.
데이터 조회 시 ① shared buffer → ② OS page cache → ③ 디스크 순으로 접근하여 최대한 디스크 I/O를 줄인다.
반면 Oracle은 DB 내부 메모리를 크게 사용하는 구조이며, PostgreSQL은 OS 캐시와 협력하는 방식으로 전체 시스템 메모리 효율을 높이는 전략을 사용한다.

공유 메모리

shared buffer: 일반적인 데이터베이스의 버퍼영역과 동일하며 디스크 IO를 줄여주는 역할. 128KB를 기본값

WAL(write ahead log): 변경사항들을 바로 디스크에 반영하지않고 메모리에 기록해두는 영역이며 일정시간 혹은 조건을 만족하면 디스크에 반영을 하는데 이때 WAL 세그먼트에 반영

Clog(comiit log): 트랜잭션별로 결과를 저장하는 영역이며 트랜잭션이 진행중이면 in-progress, 정상적인 commit이되면 "commited", rollback되면 "aborted" 결과를 반환한다.

SELECT txid_current();
-- 751
SELECT txid_status(751);

락 스페이스: 데이터베이스에서 락을 관리하는 장부이며 누가(PID), 무엇을(table/row), 어떤 종류의 락(exclusive/shared)을 점유하고 있는지 알수 있음.

로컬 메모리

backend 프로세스가 관리하는 영역이며 쿼리를 실행후 결과를 전송

세션/트랜잭션별로 단위 메모리를 설정 가능

CNI 개념

VIRGIL ABLOH — Sat, 17 Jan 2026 11:32:43 +0900

[Kubernetes] CNI, Flannel, 그리고 Service의 차이 완벽 정리

쿠버네티스를 공부하다 보면 네트워크 부분에서 머리가 아파옵니다. CNI, Flannel, Service... 다 통신을 하게 해주는 것 같은데, 도대체 무슨 차이가 있을까요?

이번 글에서는 쿠버네티스 네트워크의 핵심 개념들을 **"도로"와 "내비게이션"**에 비유하여 아주 쉽게 정리해 보겠습니다.

1. CNI (Container Network Interface)란?

한 줄 요약: 쿠버네티스 네트워크의 "표준 규격(인터페이스)"

쿠버네티스는 직접 네트워크 기능을 만들지 않았습니다. 대신 **"IP는 이렇게 주고, 연결은 이렇게 하라"**는 규칙(Interface)만 정해두었습니다. 이 규칙이 바로 CNI입니다.

CNI의 역할: 파드(Pod)에게 IP 주소를 할당하고, 네트워크 인터페이스를 관리합니다.
플러그인: 이 규칙을 지켜서 만든 실제 제품들이 Flannel, Calico, AWS VPC CNI 등입니다.

비유: USB 포트

CNI = USB 포트: 삼성 마우스를 꽂든, 로지텍 키보드를 꽂든 작동하게 해주는 표준.
Flannel = 특정 마우스 제품: 그 포트에 꽂아서 실제로 동작하는 도구.

2. Flannel과 Cross-Node 통신

핵심 질문: 서로 다른 컴퓨터(Node)에 있는 파드끼리는 어떻게 통신할까?

쿠버네티스 클러스터는 여러 대의 컴퓨터(Node)로 이루어져 있습니다. 문제는 Node A에 있는 파드가 Node B에 있는 파드에게 데이터를 보낼 때 발생합니다.

1) CNI(Flannel)가 없을 때

각 노드는 **"고립된 섬"**입니다.

내 컴퓨터(Node A) 안에 있는 파드끼리는 통신이 됩니다.
하지만 **다른 컴퓨터(Node B)**로 데이터를 보내려고 하면 길을 잃습니다. 물리적인 라우터나 공유기는 파드의 가상 IP(예: 10.244.1.5)를 모르기 때문입니다.

2) CNI(Flannel)가 있을 때

Flannel은 노드들 사이에 **"가상의 터널(Overlay Network)"**을 뚫습니다.

포장(Encapsulation): 파드의 데이터가 노드 밖으로 나갈 때, Flannel이 겉포장을 한 번 더 쌉니다. ("이거 사실 Node B로 가는 거야"라고 표시)
전송: 물리 네트워크를 타고 Node B로 이동합니다.
개봉(Decapsulation): Node B의 Flannel이 포장을 뜯고, 안에 있는 파드에게 데이터를 전달합니다.

참고 (Flannel ID / VNI): 이때 Flannel은 패킷을 구분하기 위해 VNI(VXLAN Network Identifier)라는 식별자(보통 1번)를 붙여서 전송합니다.

3. Service와 CNI의 차이점

가장 헷갈리는 부분입니다. 둘 다 통신을 돕는데 무엇이 다를까요?

구분	CNI (Flannel 등)	Service (ClusterIP 등)
비유	도로 & 터널	내비게이션 & 목적지
역할	물리적으로 "갈 수 있는 길"을 만듦	논리적으로 "누구에게 갈지" 안내함
문제 해결	"다른 컴퓨터까지 어떻게 가지?"	"파드 IP가 자꾸 바뀌는데 누굴 찾지?"
작동 계층	L2/L3 (네트워크 연결)	L4 (부하분산 및 포워딩)

상황극으로 이해하기

Service: "고객님, 목적지는 백엔드 파드입니다. 주소는 10.244.1.5로 찍고 가세요." (안내)
CNI: "네, 그 주소(10.244.1.5)로 가시려면 제가 뚫어놓은 이 터널을 통과해서 옆 동네 컴퓨터로 건너가시면 됩니다." (이동)

4. (심화) AWS EKS는 다르다?

일반적인 쿠버네티스는 Flannel 같은 오버레이(Overlay) 방식을 쓰지만, AWS EKS는 기본적으로 AWS VPC CNI를 사용합니다.

Flannel: 파드에게 가짜(가상) IP를 주고 포장해서 보냄. (조금 느림)
AWS VPC CNI: 파드에게 **진짜 AWS IP(VPC IP)**를 줌.
- 포장할 필요 없이 EC2 통신하듯이 바로 쏠 수 있음. (빠르고 성능이 좋음)

5. 요약

CNI는 쿠버네티스 네트워크의 도로 공사 담당이다. 파드 간의 물리적인 연결 길을 뚫어준다.
Flannel은 CNI의 구현체 중 하나로, **패킷을 포장(캡슐화)**해서 다른 노드로 배달해 주는 역할을 한다.
Service는 내비게이션이다. IP가 자주 바뀌는 파드들을 대신해 고정된 주소를 제공하고 올바른 파드로 안내한다.
CNI가 없으면? 도로가 끊긴 것과 같다. 같은 노드 내에서만 통신되고, 다른 노드로 나가는 순간 통신이 두절된다.

1. CNI (Container Network Interface)

역할: "IP 할당 및 네트워크 연결 담당"
동작: 쿠버네티스(Kubelet)가 파드를 만들 때 CNI를 호출합니다. CNI는 사용 가능한 IPv4 주소를 할당하고, 파드 내부에 **네트워크 인터페이스(eth0)**를 생성하여 통신이 가능한 상태로 만들어줍니다.

2. Service (서비스)

역할: "부하 분산 및 트래픽 포워딩 담당"
동작: 파드는 생성과 삭제가 반복되면서 IP가 계속 바뀝니다. 서비스는 이 변동되는 파드 IP 목록(Endpoints)을 실시간으로 관리합니다. 외부나 내부에서 요청(Request)이 오면, 서비스는 관리 중인 IP 목록 중 하나로 트래픽을 안전하게 **연결(Forwarding)**해 줍니다.

Kubernetes 개념정리

VIRGIL ABLOH — Sun, 11 Jan 2026 12:12:57 +0900

[Kubernetes] Kind로 실습하며 정리한 핵심 개념 요약 (노드, 컨트롤러, 서비스)

로컬 쿠버네티스 학습 도구인 **Kind(Kubernetes in Docker)**를 사용하여 실습하면서 알게 된, 초심자가 헷갈리기 쉬운 핵심 개념들을 정리해 보았다.

1. 인프라: Kind 노드의 정체 (가면무도회)

kind create cluster로 노드 3개를 띄웠을 때, 내 컴퓨터에서는 무슨 일이 일어난 걸까?

실체: VM(가상머신) 3대가 아니라, 도커 컨테이너 3개가 생성된 것이다. (docker ps로 확인 가능)
속임수: 이 컨테이너들은 내부에서 systemd 등이 돌아가며 실제 OS처럼 행동한다. 쿠버네티스 마스터는 이들을 "진짜 컴퓨터(Node)"라고 인식한다.
장점: 진짜 VM 3대를 띄우는 것보다 리소스(RAM, CPU)를 훨씬 적게 쓰면서 멀티 노드 환경을 완벽하게 흉내 낼 수 있다.

2. 워크로드: 누가 누구를 관리하나?

우리는 파드(Pod)를 직접 관리하지 않는다. 상위 개념들이 계층적으로 관리한다.

Deployment (채용 담당 매니저):
- "Nginx 파드 3개 유지해!" 같은 **희망 상태(Desired State)**를 정의한다.
- 파드 템플릿의 내용이 점 하나라도 바뀌면(업데이트), 해시(Hash)값이 바뀌면서 새로운 레플리카셋을 생성해 갈아치운다.
ReplicaSet (반장):
- 실제 파드의 **개수(Replicas)**를 맞추는 역할을 한다.
Pod (직원):
- 실제 컨테이너가 돌아가는 곳.
- 중요: 파드는 언제든 죽고 새로 태어나는 **'일회용품(Ephemeral)'**이다. 죽었다 살아나면 IP가 바뀐다.

3. 핵심 원리: 컨트롤러 (The Brain)

쿠버네티스가 사람의 개입 없이 자동으로 시스템을 유지하는 비결은 **'컨트롤러(Controller)'**라는 감시 로봇 덕분이다.

역할: **"현재 상태(Current State)"**와 사용자가 원하는 **"희망 상태(Desired State)"**를 끊임없이 비교하고 맞춘다.
작동 방식 (Reconciliation Loop):
1. 비교: "사용자는 파드 3개를 원하는데(희망 상태), 지금은 2개밖에 없네(현재 상태)?"
2. 조치: "그럼 1개 더 만들어야겠다!" 하고 즉시 실행에 옮긴다.
핵심: 배포할 때만 작동하는 게 아니라, 24시간 내내 무한 루프를 돌며 감시한다. 그래서 파드가 갑자기 죽으면 컨트롤러가 즉시 알아채고 살려내는 것이다.

4. 네트워크: 서비스(Service)가 필요한 이유

파드는 자꾸 죽고 IP가 바뀌는데, 어떻게 접속해야 할까? 여기서 **서비스(Service)**가 등장한다.

역할: 파드의 IP가 바뀌든 말든, 변하지 않는 **고정된 가상 IP(ClusterIP)**를 제공한다. (파드들의 대표 전화번호)
동작 원리:
1. 라벨(Label): 서비스는 "이마에 app: my-web 스티커 붙은 애들 다 모여!"라고 파드를 찾는다.
2. 엔드포인트(Endpoints): 서비스 뒤에는 실제로 연결된 파드들의 최신 IP 목록을 적어두는 '주소록(Endpoints)'이 있다. (kubectl get ep로 확인 가능)
3. 가상 IP: 서비스의 IP는 실제 랜카드에 존재하는 게 아니라, kube-proxy가 네트워크 규칙(iptables)을 조작해서 트래픽을 납치해 파드로 보내주는 논리적인 IP다.

5. 외부 연결: 서비스 타입(Service Type) 4가지

상황에 따라 어떤 '문'을 열지 결정해야 한다.

ClusterIP (기본): "우리끼리만 쓰자."
- 외부 접속 불가. 클러스터 내부 파드끼리 통신할 때 사용. (DB, 백엔드 내부 통신 등)
NodePort: "창문 열어둘게."
- 모든 노드의 특정 포트(예: 30000)를 개방.
- 로컬 개발이나 테스트용으로 가장 적합하다.
LoadBalancer: "정문 안내원 고용."
- AWS, GCP 같은 클라우드 환경에서 사용하며, 실제 공인 IP를 받는다.
- 주의: Kind 환경에서는 로드밸런서를 줄 클라우드가 없어서 <pending> 상태로 멈춘다.
ExternalName: "단축번호."
- 외부의 긴 도메인(예: AWS RDS 주소)을 내부에서 짧은 별칭으로 부르기 위해 사용한다.

6. 실전 팁: 로컬 개발 환경 구성 (Kind + Docker Compose)

Kind에 백엔드를 올리고, 로컬(Docker Compose)에서 프론트엔드를 띄워 연동하려면 어떻게 해야 할까?

추천 방식: 백엔드 서비스를 NodePort 타입으로 만든다.
Kind 설정 필수: Kind는 도커 컨테이너 안에 갇혀 있으므로, 클러스터 생성 시 extraPortMappings 설정을 통해 **[내 컴퓨터 포트] ↔ [Kind 노드 포트]**를 연결해줘야 한다.
결과: 프론트엔드에서 localhost:30000으로 요청을 보내면 → 내 컴퓨터 → Kind 노드 → 파드 순서로 연결된다.

Context Hierarchy-컨텍스트 계층

VIRGIL ABLOH — Tue, 29 Apr 2025 00:03:19 +0900

스프링 컨텍스트 계층은 크게 나누면 자식 컨텍스트인 Servlet-WebApplicationContext가 있고 그의 부모인 Root-WebApplicationContext가 있다.

Servlet-WebApplicationContext엔 주로 웹과 관련된 컨트롤러-뷰-헨들러가 있으며

Root-WebApplicationContext엔 비즈니스 계층, DB 커넥터와 같은 공통적으로 사용하는 리소스에 대한 빈을 관리한다.

그래서 빈을 조회하면 먼저 자식 컨텍스트에서 조회를 하고 자식에게 빈이 없으면 부모 컨텍스트에서 조회를 하고 빈을 찾으면 자식 컨텍스트에게 주입하여 사용한다.

http 요청시 동작방식(GPT 참고)

HTTP 요청 → DispatcherServlet
클라이언트가 /foo 같은 URL로 요청을 보내면, DispatcherServlet(서블릿 컨텍스트)에서 받음.
웹 전용 빈 조회이때 필요한 인터셉터나 뷰 리졸버 등 웹계층 전용 빈들은 자식(Web) 컨텍스트에서 바로 조회
HandlerMapping → @Controller 빈 → 해당 컨트롤러의 메서드 실행
비즈니스 로직 호출
- 먼저 자식 컨텍스트에 MyService 빈이 있는지 찾고,
- 없으면 부모(Root) 컨텍스트로 올라가서 MyService 빈을 찾아 주입·실행
컨트롤러 내부에서 @Autowired 된 MyService 같은 서비스 빈을 호출하면,
DB 접근 등 인프라 빈모두 부모 컨텍스트에서 조회되어 사용
MyService 안에서 @Autowired 된 DataSource·TransactionManager·MyRepository 같은 빈들도 모두 부모 컨텍스트에서 조회되어 사용

이런 구조를 통해

웹·비즈니스 로직을 깔끔히 분리할 수 있고,
여러 서블릿이 하나의 공통 서비스·리포지토리를 재사용할 수 있다.

InnoDB 클러스터링 및 세컨더리 인덱스: 페이지 분할(.ibd파일)

VIRGIL ABLOH — Thu, 26 Dec 2024 14:47:14 +0900

테이블 최소 생성시

여기서 볼수 있는 포인트는 인덱스도 페이지로 관리된다.

테이블 최초생성후 세컨더리 인덱스 생성시

세컨더리 인덱스도 별도의 페이지로 추가됨을 확인할 수 있다.

327개 로우 추가시

클러스터링 인덱스는 데이터가 증가함에 따라 2개의 페이지(leaf page)로 분리되고 기존의 인덱스(root page)는 새로 분리된 2개의 페이지에 대한 주소값을 갖는다.

위에서 1개 로우 추가시

위에서 330개 로우 추가시

위에서 1개 로우 추가시

Postgrsql에서 라인 포인터의 역할

VIRGIL ABLOH — Wed, 18 Dec 2024 13:54:51 +0900

DB에서 데이터는 책의 페이지처럼 쪽으로 나눠져서 관리되고 있다.

그래서 데이터를 저장할때는 페이지마다 저장되고 있으며 페이지에서는 레코드(로우)들로 저장되며 해당 페이지 상단에는 레코드마다 위치를 가리키는 라인포인터 영역이 있다. 쉽게 이야기하면 페이지 마다 상단에 헤더영역이 있는데 그중에 라인포인터는 데이터의 위치를 가리켜서 데이터를 조회하거나 입력할때 사용된다. 데이터가 입력되면 페이지의 빈공간에서 하단에서 상단으로 채워진다.

만약 데이터가 삭제되면 라인포인터는 해당 로우에 대한 데이터가 비어있다고 저장하며 추후 재사용된다.

Oracle, Postgresql, Mysql(InnoDB)

VIRGIL ABLOH — Sat, 30 Nov 2024 16:00:33 +0900

Oracle

오라클에서 트랜잭션이 커밋되면 트랜잭션 테이블의 undo 세그먼트 헤더의 state 값을 10(active) -> 9(committed) 처리
scn(system change number)에는 현재 커밋시점의 scn으로 업데이트
그 외 ITL(interested transcation list)의 항목들중 일부 컬럼들을 commit시점의 데이터로 정리하는데 이를 블록 클린 아웃
만약 클린아웃할 항목들이 많으면 일단 메모리에 있는 일부만 우선 클린아웃을 하고 나머지들은 해당 데이터를 select할때 동작한다. 이를 dealay block cleanout이라고 한다. 해당 기능은 디비에 과부하를 줄이기 위해 동작한다.

Postgresql

레코드마다 튜플헤더가 존재하는데 이중에 infomask컬럼의 첫번째 byte(하위 4bits)로 해당 레코드의 트랜잭션 상태값을 표현
postgresql은 delete 커맨드가 들어오면 이전 데이터는 delete, 새로운 데이터 insert 처리하여 update하여 insert된 데이터와 새로 insert된 byte는 다름

직접 로컬에서 확인해본결과 일단 postgresql에 확장프로그램을 깔아서 t_infomask를 볼수 있도록 한다.

-- 익스텐션 설치
CREATE EXTENSION pageinspect;
-- infomask 식별할수 있는 테이블생성
CREATE TABLE infomask_flags (
                                flag_name text,
                                flag_bits bit(16)
);
-- infomask컬럼의 데이터를 보고 상태값을 볼수 있는 데이터 입력
INSERT INTO infomask_flags VALUES
                               ('HEAP_HASNULL',        B'0000000000000001'),
                               ('HEAP_HASVARWIDTH',    B'0000000000000010'),
                               ('HEAP_HASEXTERNAL',    B'0000000000000100'),
                               ('HEAP_HASOID',         B'0000000000001000'),
                               ('HEAP_XMAX_KEYSHR_LOCK', B'0000000000010000'),
                               ('HEAP_COMBOCID',       B'0000000000100000'),
                               ('HEAP_XMAX_EXCL_LOCK', B'0000000001000000'),
                               ('HEAP_XMAX_LOCK_ONLY', B'0000000010000000'),
                               ('HEAP_XMIN_COMMITTED', B'0000000100000000'),
                               ('HEAP_XMIN_INVALID',   B'0000001000000000'),
                               ('HEAP_XMAX_COMMITTED', B'0000010000000000'),
                               ('HEAP_XMAX_INVALID',   B'0000100000000000'),
                               ('HEAP_XMAX_IS_MULTI',  B'0001000000000000'),
                               ('HEAP_UPDATED',        B'0010000000000000'),
                               ('HEAP_MOVED_OFF',      B'0100000000000000'),
                               ('HEAP_MOVED_IN',       B'1000000000000000');
-- 데이터 출력
SELECT
    hpi.t_ctid,
    hpi.t_xmin,
    hpi.t_xmax,
    hpi.t_infomask,
    string_agg(ifl.flag_name, ', ') AS set_flags
FROM
    heap_page_items(get_raw_page('test_table', 0)) AS hpi
        JOIN infomask_flags AS ifl
             ON (hpi.t_infomask::bit(16) & ifl.flag_bits)::integer::boolean
GROUP BY
    hpi.t_ctid, hpi.t_xmin, hpi.t_xmax, hpi.t_infomask;

위의 커맨드를 동작시키고 일단 데이터 한개를 insert 했을때이다.

xmin 컬럼에 값이 있고 xmax에 값이 없는것을 보니 이건 insert된 데이터인것을 확인할수 있다.

그리고 set-flag를 보면 hasvarwidth는 해당 레코드에 가변 길이 데이터(예: VARCHAR)가 포함되어 있다는 것을 알수 있다.

그리고 xmin-committed는 해당 데이터는 insert하여 comit이 된 데이터라는 점

xmax-invalid인것은 아직 해당 레코드가 update or delete 된 것이 아니라는 점을 알수가 있다.

이제 데이터를 업데이트 해보자

ctid가 같은 값인걸 보니 한 트랜잭션이라는 것을 알수 있다.

xmin=837인 레코드가 새로 입력된 데이터이고 그 이전의 값은 이전 레코드라는 것이다.

두 레코드의 set-flag를 보면 이전의 데이터와 달라진 점을 알수 있다.

이전 레코드는 xmin-committed만 남았고 새로운 레코드는 xmax-invalid, updated 되었다는 것을 알수 있다.

정리하면 두개의 레코드로 알수 있는 점은 수정전의 데이터와 업데이트된 데이터는 존재하고 수정전의 데이터는 xmax값이 있기때문에 vaccum을 동작시키면 타겟팅이 되어 해당 로우는 물리적으로도 삭제되는 데이터라는 점이다.

mysql(InnoDB)

트랜잭션이 커밋되면 해당 커밋시점의 max-trx-id를 언두 블록의 trx-no 컬럼에 저장
롤백 세그먼트 히스토리 리스트에 커밋된 언두 블록을 등록
trx-sys에 active-trx 리스트중에 커밋된 trx-sturcture를 제외시켜 갱신

Mysql(InnoDB)에서 Transaction ID 를 통해 데이터 롤백과정 정리

VIRGIL ABLOH — Sat, 23 Nov 2024 16:40:34 +0900

트랜잭션과 함께 데이터 변경이 발생하면 해당 데이터 로우의 trx_id는 최신 트랜잭션 id를 저장
롤백 세그먼트 영역이 별도로 존재하는데 거기에는 undo 세그먼트가 그 하위에 undo 로그로 변경 전의 데이터를 저장
roll_ptr은 해당 데이터 로우에 존재하며 해당 영역에는 undo 로그의 위치를 저장
아직 커밋이 안된상태에서 select 쿼리가 오면 roll_ptr를 통해 undo 로그에 저장된 변경전의 데이터를 반환
1. 커밋이 되면 해당 undo 로그는 필요하지 않으므로 가비지 콜랙터에 들어가게되어 삭제
2. 롤백이 되면 해당 데이터 로우의 roll_ptr의 undo 로그에 있는 변경전 데이터를 다시 입력하여 데이터 원복

동작 시각화(생성: GPT)

CREATE TABLE test_table (
    id INT PRIMARY KEY,
    value VARCHAR(50)
);

INSERT INTO test_table (id, value) VALUES (1, 'one');


-- 트랜잭션 1: 데이터 변경
START TRANSACTION;
UPDATE test_table SET value = 'two' WHERE id = 1;

-- 데이터 상태 확인 (트랜잭션 중)
SELECT id, value, trx_id, roll_ptr FROM information_schema.innodb_trx;

-- 결과 (예제):
-- id   | value | trx_id | roll_ptr
-- -----|-------|--------|----------
-- 1    | two   | 1001   | 0x12345678 (Undo 로그 위치)


-- 트랜잭션 롤백
ROLLBACK;

-- 데이터 상태 확인
SELECT * FROM test_table;

-- 결과:
-- id   | value
-- -----|-------
-- 1    | one   -- 변경 전 상태로 복원


-- 트랜잭션 Commit
COMMIT;

-- Undo 로그는 일정 시간이 지나면 정리됨