Python과 Rust의 가교: 고처리량 LLM 게이트웨이에서의 GIL 경합 완화

OpenAI 호환 오픈 소스 거버넌스 프록시인 Aegis를 구축할 때, 우리는 핵심적인 아키텍처 결정을 내렸습니다. 빠른 개발과 API 적응성을 위해 Python (FastAPI/ASGI)을 사용하되, 고성능 암호화 (cryptography), Write-Ahead Logging (WAL), 그리고 Merkle Mountain Range (MMR) 연산은 PyO3와 Maturin을 통해 컴파일된 Rust 확장(aegis_rust_v2)으로 오프로드(offload)하는 것이었습니다.

하지만 Python의 비동기 이벤트 루프 (asynchronous event loop)와 Rust의 멀티스레드 Tokio 런타임 (multi-threaded Tokio runtime)을 혼합하면서, 우리는 전형적인 시스템 엔지니어링의 벽인 GIL (Global Interpreter Lock) 경합 (contention) 문제에 직면했습니다.

본문에서는 아키텍처, 성능 트레이드오프 (tradeoffs), 그리고 핫 패스 (hot-path) 지연 시간을 2.5 마이크로초 (microseconds) 미만으로 유지하기 위해 우리가 어떻게 투-패스 모델 (two-path model)을 설계했는지 심층적으로 분석합니다.

투-패스 실행 모델 (The Two-Path Execution Model)

LLM 거버넌스에서 프록시 지연 시간이 추가되는 매 마이크로초는 클라이언트 애플리케이션에 대한 페널티입니다. 클라이언트가 인지하는 감사 대기 시간을 제로로 만들기 위해, Aegis는 요청 경로를 다음과 같이 분리합니다:

        ┌──────────────────────── HOT PATH (Awaited) ───────────────────────┐
client →│ smuggling guard → auth → WAF → rate-limit → adapter → forwarder →  │→ upstream
        └───────────────────────────────────┬───────────────────────────────┘
...

ASGI 서버는 감사 (auditing), Shannon 토큰 엔트로피 분석 (Shannon token entropy analysis), 그리고 암호화 해싱 (cryptographic hashing)이 수행되기 전에 업스트림 JSON 응답을 클라이언트에 반환합니다.

핫 패스에서 수행되는 유일한 작업은 태스크를 스케줄링 (scheduling)하는 것입니다. 우리의 벤치마크 환경 (Intel Xeon @ 2.80 GHz, 4 cores)에서 이 스케줄링 블록(asyncio.create_task + 백그라운드 세트 추적 + Prometheus gauge 업데이트)은 p50 기준 2.43 µs, p99 기준 6.78 µs의 비용만 발생합니다.

Rust MMR을 통한 감사 경로 가속화

백그라운드 태스크가 생성되면, 데이터는 CryptographicAuditLedger로 전달됩니다. 바로 이 지점에서 Rust의 진가가 드러납니다.

커밋된 각 트랜잭션은 성장하는 **Merkle Mountain Range (MMR)**의 리프(leaf)를 추가합니다. MMR은 추가 전용(append-only) 로그형 누적기(logarithmic accumulator)로, 클래식한 균형 이진 머클 트리(balanced binary Merkle tree)의 거대한 재균형(rebalancing) 오버헤드 없이도 포함 증명(inclusion proof)과 일관성 증명(consistency proof)을 제공합니다.

Python에서는 리프 해싱(leaf hashing)이 다음과 같이 구현됩니다:

# 순수 Python 폴백 (fallback)
def add_leaf(self, leaf_hash: bytes) -> bytes:
    self.leaves.append(leaf_hash)
...

PyO3를 통해 Rust를 바인딩함으로써, 노드당 할당(allocation) 없이 내부 루프 트리 누적(tree accumulation)을 네이티브로 실행합니다:

// aegis_rust_v2/src/mmr.rs
#[pyclass]
pub struct MmrAccumulator {
...

이 Rust 가속 레이어는 순수 Python 베이스라인 대비 **3.01배에서 3.34배의 안정적인 속도 향상(speedup)**을 제공합니다:

GIL 경합의 벽에 부딪히다

이러한 속도 향상에도 불구하고, 동시 루프백 성능 스윕(concurrent loopback performance sweeps, GET /health가 전체 ASGI, WAF, 속도 제한(rate-limiting), 실시간 원장 확인 스택을 호출하는 과정) 중에 이상 현상을 발견했습니다:

• Concurrency 1: 650 RPS | 1.49 ms p50 | 35.7% CPU
• Concurrency 4: 902 RPS | 4.05 ms p50 | 43.1% CPU
• Concurrency 32: 339 RPS | 65.2 ms p50 | 18.7% CPU
• Concurrency 128: 246 RPS | 297.6 ms p50 | 13.8% CPU

$c=4$를 넘어서면서 처리량(throughput)은 떨어지고 지연 시간(latency)은 기하급수적으로 증가하지만, CPU 사용률은 오히려 감소한다는 점에 주목하십시오.

이는 GIL 경합으로 인해 발생하는 이벤트 루프 헤드 오브 라인 블로킹 (event-loop head-of-line blocking) 현상입니다 [추론]. Python ASGI 루프가 이벤트나 락(lock)을 조정하기 위해 양보(yield)할 때마다, 만약 Rust 스레드(백그라운드 Tokio 풀 또는 PyO3 암호화 호출 실행 중)가 GIL을 점유하고 있다면 Python 루프는 정지됩니다. Rust가 매우 빠르더라도, PyO3의 FFI 인터페이스를 통해 GIL을 획득하고 해제하는 비용은 동시성(concurrency)에 따라 증가합니다.

아키텍처적 시사점

이 벤치마크는 우리에게 경험적인 설계 해답을 제시했습니다: 워커(worker)당 수직 확장(scale up)하지 말고, 수평 확장(scale out)하라.

단일 Python 프로세스에 클라이언트 동시성 (concurrency)을 쌓아 올리고 거대한 스레드 풀 (thread-pools)에 의존하는 대신, Aegis를 위한 최적의 배포 전략은 다음과 같습니다:

1. 물리 코어당 하나의 Uvicorn 워커 프로세스 (worker process)를 실행합니다.
2. 컨테이너 CPU 제한 (CPU limits)을 워커 수와 정확히 일치하도록 제한합니다 (CFS 스로틀링 (throttling) 방지).
3. 테넌트 어피니티 해싱 (tenant-affinity hashing)을 사용하는 로드 밸런서 (예: NGINX, HAProxy, AWS ALB)를 전면에 배치합니다.

워커를 고정(pinning)하고 프로세스당 동시성을 낮게 유지함으로써, 전체 감사 내구성 (audit durability)을 유지하는 동시에 ASGI 이벤트 루프 (event loop)를 FFI 경합 (contention)으로부터 완전히 자유롭게 유지할 수 있습니다.

결론 및 오픈 소스

Aegis는 AGPLv3 라이선스 하에 완전히 오픈 소스로 공개되어 있습니다. 규제가 엄격한 분야에서 생성형 AI 통합을 구축하고 있거나 (또는 단순히 PyO3, Maturin, 그리고 암호학 (cryptography)을 다뤄보고 싶다면), 저희 코드를 확인해 보세요:

👉 GitHub: https://github.com/juanlunaia/aegis-latent-core

👉 Visualizer Dashboard: https://github.com/juanlunaia/aegis-latent-core/tree/main/tools/visualizer

저는 아르헨티나에서 온 22세 학생이며, 이 FFI 아키텍처에 대한 피드백을 적극적으로 구하고 있습니다. 만약 유사한 ASGI/PyO3 스레딩 병목 현상 (bottlenecks)을 해결한 경험이 있다면, 어떻게 해결하셨는지 꼭 듣고 싶습니다!