Database on Yarang's Tech Lair

pg_durable 분석: Rust로 구현하는 내구성 있는 함수 실행

Sat, 06 Jun 2026 09:00:49 +0900

최근 Microsoft가 오픈 소스로 공개한 pg_durable은 데이터베이스 내에서 직접 ‘내구성 있는(Durable)’ 함수 실행을 가능하게 하는 실험적인 프로젝트입니다. 전통적인 마이크로서비스 아키텍처에서는 비즈니스 로직이 애플리케이션 계층에 위치하고, 데이터베이스는 단순히 상태를 저장하는 역할에 그치는 경우가 많습니다. 하지만 pg_durable은 로직과 데이터를 물리적으로 가까운 곳에 통합하여, 외부 시스템의 장애나 네트워크 비용을 최소화하는 접근 방식을 제시합니다.

이번 글에서는 pg_durable의 핵심 메커니즘을 분석하고, Rust와 PostgreSQL을 활용해 유사한 패턴을 구현하는 방법을 살펴보겠습니다.

pg_durable의 핵심 메커니즘

pg_durable의 가장 큰 특징은 함수의 상태(State)와 실행 흐름(Execution Flow) 자체를 데이터베이스 레코드로 저장한다는 점입니다. 일반적인 애플리케이션에서 HTTP 요청이 실패하면 메모리에 있던 컨텍스트가 사라지지만, pg_durable은 실행할 함수의 입력(Input)과 현재 단계(Step)를 테이블에 기록합니다.

이를 통해 다음과 같은 이점을 얻을 수 있습니다:

자동 복구 (Auto-Recovery): 서버가 크래시되어도 데이터베이스에는 ‘실행해야 할 작업’이 남아있으므로, 서버 재시작 후 남은 작업을 이어서 수행할 수 있습니다.
정확히 한 번 실행 (Exactly-Once Semantics): 데이터베이스 트랜잭션을 활용해 상태 업데이트와 로직 실행을 원자적으로 처리할 수 있습니다.

Rust로 데이터베이스 트리거 기반 워커 구현하기

pg_durable의 내부 구현은 복잡하지만, 이 패턴을 Rust와 PostgreSQL의 LISTEN/NOTIFY 기능을 사용해 간단하게 재현해 볼 수 있습니다. 이 접근 방식은 데이터베이스를 ‘메시지 브로커’처럼 활용하면서도 별도의 인프라 비용을 절약할 수 있습니다.

1. 데이터베이스 스키마 설계

먼저 작업(Job)을 저장할 테이블을 생성합니다.

CREATE TABLE durable_jobs (
 id SERIAL PRIMARY KEY,
 status TEXT NOT NULL, -- 'pending', 'running', 'completed'
 payload JSONB NOT NULL,
 created_at TIMESTAMP DEFAULT NOW()
);

2. Rust 워커 구현 (sqlx 사용)

Rust의 비동기 런타임과 sqlx를 사용하여, 데이터베이스에 새 작업이 들어오면 이를 감지하고 처리하는 워커를 작성해 보겠습니다.

# Cargo.toml
[dependencies]
tokio = { version = "1", features = ["full"] }
sqlx = { version = "0.7", features = ["runtime-tokio", "postgres", "json"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

이제 Rust 코드로 워커를 구현합니다.

use sqlx::{PgPool, Listener};
use serde::{Deserialize, Serialize};
use tokio::time::{sleep, Duration};

#[derive(Debug, Serialize, Deserialize)]
struct JobPayload {
 user_id: i32,
 action: String,
}

#[tokio::main]
async fn main() -> Result<(), sqlx::Error> {
 // 데이터베이스 연결 풀 생성
 let pool = PgPool::connect("postgresql://user:password@localhost/mydb").await?;
 
 // 데이터베이스 변경 사항 감지 리스너 (pg_notify 활용)
 let mut listener = pool.acquire().await?.listen("job_channel");

 println!("Worker started, waiting for jobs...");

 loop {
 // 알림 수신 대기
 let notification = listener.recv().await?;
 println!("Received notification: {}", notification.payload);

 // 알림을 받으면 실제 작업 처리 시도
 process_jobs(&pool).await?;
 }
}

async fn process_jobs(pool: &PgPool) -> Result<(), sqlx::Error> {
 // 트랜잭션 내에서 'pending' 상태의 작업을 가져와 'running'으로 변경 (Locking)
 let mut tx = pool.begin().await?;
 
 let job_opt = sqlx::query_as::<_, (i32, JobPayload)>(
 r#"
 UPDATE durable_jobs 
 SET status = 'running' 
 WHERE id = (
 SELECT id FROM durable_jobs 
 WHERE status = 'pending' 
 FOR UPDATE SKIP LOCKED 
 LIMIT 1
 )
 RETURNING id, payload
 "#
 )
 .fetch_optional(&mut *tx)
 .await?;

 if let Some((id, payload)) = job_opt {
 println!("Processing job {}: {:?}", id, payload);
 
 // 비즈니스 로직 실행 (예: 외부 API 호출 등)
 // 실제 환경에서는 여기서 무거운 작업을 수행합니다.
 let result = simulate_heavy_task(&payload).await;

 match result {
 Ok(_) => {
 // 성공 시 상태를 'completed'로 업데이트
 sqlx::query("UPDATE durable_jobs SET status = 'completed' WHERE id = $1")
 .bind(id)
 .execute(&mut *tx)
 .await?;
 }
 Err(e) => {
 // 실패 시 상태를 'failed'로 남겨두거나 재시도 로직 추가
 eprintln!("Job {} failed: {}", id, e);
 sqlx::query("UPDATE durable_jobs SET status = 'failed' WHERE id = $1")
 .bind(id)
 .execute(&mut *tx)
 .await?;
 }
 }
 
 tx.commit().await?;
 }
 
 Ok(())
}

async fn simulate_heavy_task(payload: &JobPayload) -> Result<(), Box<dyn std::error::Error>> {
 // 예시: 2초 대기
 sleep(Duration::from_secs(2)).await;
 println!("Task executed for user {}", payload.user_id);
 Ok(())
}

3. 작업 등록 트리거

실제로는 애플리케이션 레벨에서 INSERT 쿼리를 날린 후 NOTIFY를 보내거나, 트리거를 사용해 자동화할 수 있습니다.

-- 트리거 함수 및 트리거 생성 예시
CREATE OR REPLACE FUNCTION notify_job() RETURNS TRIGGER AS $$
BEGIN
 PERFORM pg_notify('job_channel', NEW.id::text);
 RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER job_notify_trigger
AFTER INSERT ON durable_jobs
FOR EACH ROW
EXECUTE FUNCTION notify_job();

아키텍처 적용 시 고려사항

이 패턴(pg_durable 스타일)을 ZeroClaw나 MCP 서버와 같은 고성능 시스템에 적용할 때는 다음 사항을 고려해야 합니다.

데이터베이스 부하: 데이터베이스가 단순한 저장소가 아니라 실행 엔진의 역할을 일부 담당하므로, 워커가 너무 잦은 폴링(Polling)을 하거나 무거운 로직을 수행하면 DB 성능에 저하가 올 수 있습니다. SKIP LOCKED 구문을 사용해 여러 워커 인스턴스가 안전하게 분산 처리하도록 구성하는 것이 필수입니다.
확장성(Scale-out): 앞서 보여준 Rust 코드는 다중 프로세스로 실행하더라도 FOR UPDATE SKIP LOCKED 덕분에 안전하게 작업을 분산 처리할 수 있습니다. Kubernetes 환경이라면 HorizontalPodAutoscaler(HPA)를 통해 큐가 쌓일 때 워커 파드를 늘리는 식으로 유연한 대응이 가능합니다.

결론

Microsoft의 pg_durable은 ‘데이터 중심 아키텍처(Data-Centric Architecture)‘의 진화된 형태를 보여줍니다. 복잡한 메시지 큐(Kafka, RabbitMQ)를 도입하기 전, 데이터베이스의 트랜잭션 기능을 적극 활용해 간단하고 강력한 내구성을 확보해 보는 것은 어떨까요? 위의 예제 코드는 바로 실무에서 테스트해 볼 수 있는 형태이므로, 여러분의 사이드 프로젝트나 백오피스 시스템에 적용해 보시길 권장합니다.

Redis Array의 진화: 대규모 데이터 처리를 위한 아키텍처 분석

Tue, 05 May 2026 09:00:52 +0900

Redis Array의 진화: 대규모 데이터 처리를 위한 아키텍처 분석

안녕하세요! 최근 Hacker News를 통해 흥미로운 기사 하나를 접하게 되었습니다. 바로 Redis의 핵심 개발자 중 한 명인 Oran Agra가 작성한 **“Redis array: short story of a long development process”**입니다. 단순히 기능 하나가 추가된 이야기가 아니었습니다. 이는 25년 된 레거시 코드를 건드리면서 성능을 유지하고, 안정성을 확보하며, 거대한 코드베이스를 밤새 포맷팅했던 개발자들의 집념의 기록이었습니다.

오늘은 이 기사를 바탕으로, Redis 내부에서 Array(배열) 자료구조가 어떻게 진화해왔는지, 그리고 우리가 대규모 시스템을 설계할 때 배울 수 있는 교훈은 무엇인지 깊이 있게 분석해보겠습니다.

1. 문제 제기: 25년 된 레거시 코드의 굴레

Redis의 LIST 자료구조는 내부적으로 QuickList를 사용합니다. QuickList는 양방향 연결 리스트인 ziplist와 linkedlist의 장점을 결합한 구조입니다. 하지만 수천만 개의 요소를 가진 거대한 리스트를 다룰 때, 메모리 파편화(memory fragmentation)와 캐시 미스(cache miss)가 심각한 성능 저하를 일으키는 문제가 있었습니다.

특히, 배열(Array) 타입의 데이터를 처리할 때 기존의 구조는 다음과 같은 병목이 있었습니다.

메모리 오버헤드: 포인터 연결로 인한 추가 메모리 사용.
순차 접근 비용: 캐시 라인을 효율적으로 사용하지 못해 발생하는 지연.

개발팀은 이를 해결하기 위해 C 언어 수준에서 내부 구조를 뜯어고치기로 결심합니다. 여기서 가장 큰 난관은 바로 **“변경하지 않으면 안 되는 레거시 코드”**였습니다.

2. 해결 과정: Formatting a 25M-line Codebase

기사에서 가장 인상 깊었던 부분은 **“Formatting a 25M-line codebase overnight”**입니다. 2,500만 라인에 달하는 코드를 포맷팅하고 리팩토링하는 과정은 단순한 기술적 도전을 넘어 체스와 같은 전략이 필요했습니다.

2.1. 리팩토링을 위한 사전 준비

대규모 리팩토링 시 가장 두려운 것은 **“회귀(Regression)”**입니다. 배열 구조를 변경하는 과정에서 수백 개의 Redis 명령어(LPUSH, RPUSH, LINDEX 등)가 영향을 받을 수 있기 때문입니다.

이를 해결하기 위해 팀은 다음과 같은 접근 방식을 취했습니다.

테스트 커버리지 확대: 기존 명령어에 대한 단위 테스트(Unit Test)를 통과하는지 확인.
CI/CD 파이프라인 강화: 코드 변경 시 즉시 성능 저하가 발생하는지 감시하는 벤치마킹 스크립트 배치.

2.2. Redis Array의 새로운 구조

개선된 Array 구조는 단순히 메모리를 할당하는 방식에서 벗어나, 데이터 지역성(Locality)을 극대화하는 방향으로 변경되었습니다. 핵심은 **“연속된 메모리 블록을 최대한 활용하되, 필요시 분할하여 관리한다”**는 것입니다.

이를 통해 다음과 같은 이점을 얻었습니다.

CPU 캐시 히트율 향상: 연속된 메모리 접근으로 인해 L1/L2 캐시 적중률이 크게 향상되었습니다.
메모리 절약: 불필요한 포인터 연결을 줄여 실제 데이터 저장 공간을 확보했습니다.

3. 실전 가이드: Redis에서 효율적인 배열 사용하기

이론적인 배경은 충분하니, 이제 실제로 어떻게 적용할 수 있는지 코드로 살펴보겠습니다.

3.1. 기존 리스트 사용의 문제점

먼저, 수천만 개의 아이템을 리스트에 넣는 기존 방식을 생각해봅시다. 이는 QuickList 기반으로 동작하며, 아이템 수가 늘어날수록 점프 횟수가 늘어납니다.

# 기존 방식 (QuickList based)
# 10,000,000개의 아이템 추가 (메모리 및 속도 저하 발생 가능)
for i in {1..10000000}; do
 redis-cli LPUSH my_huge_list "item:$i"
done

3.2. Stream과 Hash를 활용한 최적화

Redis Array의 내부 개선은 사용자에게 투명하게 적용되지만, 우리가 설계를 할 때는 **“데이터의 크기”**와 **“접근 패턴”**을 고려해야 합니다. 단순히 순서대로 저장만 하면 된다면 최신 버전의 Redis를 쓰는 것만으로도 이득을 볼 수 있습니다.

하지만 만약 배열 안의 데이터를 검색하거나 수정해야 한다면 LIST 대신 HASH를 사용하는 것이 좋습니다.

import redis
import time

r = redis.Redis(host='localhost', port=6379, db=0)

# 시나리오: 로그 데이터 저장 (대규모)
# 1. List 사용 (순차 보관용)
def push_to_list(count):
 start = time.time()
 for i in range(count):
 r.lpush("logs:timeline", f"log_entry_{i}")
 print(f"List pushed {count} items in {time.time() - start:.4f}s")

# 2. Hash 사용 (검색 및 수정용)
def push_to_hash(count):
 start = time.time()
 pipe = r.pipeline()
 for i in range(count):
 pipe.hset("logs:details", f"entry_{i}", f"log_content_{i}")
 pipe.execute()
 print(f"Hash pushed {count} items in {time.time() - start:.4f}s")

if __name__ == "__main__":
 # 10만 개 데이터 삽입 테스트
 push_to_list(100000)
 push_to_hash(100000)

실행 결과 분석: 최신 Redis 버전(7.x 이상)에서는 내부적으로 Array 구조가 최적화되어 있어 LPUSH 속도가 매우 빠릅니다. 하지만 특정 인덱스의 데이터를 자주 조회해야 한다면 LINDEX는 O(N)의 복잡도를 가지므로, HGET을 쓰는 O(1) 방식이 훨씬 유리합니다.

4. 결론: 개발 문화와 기술의 조화

Redis Array의 개발 과정은 우리에게 중요한 교훈을 줍니다.

성능은 무료가 아니다: 25년 된 코드를 개선하기 위해서는 그에 상응하는 리팩토링과 테스트 비용이 따른다.
도구의 투자: 2,500만 라인의 코드를 포맷팅할 수 있는 자동화 도구와 CI/CD 환경이 있었기에 가능한 작업이었다.

우리가 시스템을 설계할 때, 단순히 “빠르다"는 것만 넘어서 “어떻게 유지보수 가능한 성능을 낼 것인가"를 고민해야 합니다. Redis 팀이 보여준 것처럼, 때로는 아키텍처의 근간을 흔드는 대규모 개선을 두려워하지 말아야 할 때입니다.

5. 참고 자료

감사합니다!