beautifulsoups.dev
Published on

Rust로 개발하는 고성능 네트워크 서비스 실전 가이드

Authors

서버가 느려지는 이유는 대개 “언어가 느려서”가 아니라, I/O 모델·동시성 제어·메모리 관리·타임아웃/백프레셔 설계가 엉키기 때문입니다. Rust는 제로 코스트 추상화와 강력한 타입 시스템, 그리고 런타임 선택의 유연성 덕분에 고성능 네트워크 서비스에 특히 잘 맞습니다. 다만 Rust로 빠른 서버를 만드는 일은 단순히 tokio를 쓰는 것 이상입니다. 이 글에서는 실무에서 바로 적용할 수 있는 설계 포인트와 코드 패턴을 중심으로, “빠르고 안전하며 운영 가능한” 네트워크 서비스를 만드는 흐름을 안내합니다.

목표 아키텍처: 빠름, 안전, 운영가능

고성능 네트워크 서비스의 현실적인 목표는 보통 아래 4가지를 동시에 만족하는 것입니다.

  • 낮은 지연시간: p99 지연이 튀지 않게 만들기
  • 높은 처리량: CPU 바운드와 I/O 바운드를 분리하고 병목을 제거
  • 안정성: 타임아웃, 백프레셔, 리소스 상한을 명시적으로
  • 운영성: 메트릭·트레이싱·로그로 문제를 재현 가능하게

특히 타임아웃은 “있냐 없냐”가 아니라 전파(Propagation) 가 핵심입니다. gRPC 계열을 쓰든 HTTP를 쓰든, 호출 체인 전체에 데드라인을 일관되게 전달하지 않으면 지연이 누적되어 장애가 됩니다. 관련해서는 gRPC 타임아웃 지옥 탈출 - 데드라인 전파 설계 글의 개념을 네트워크 서비스 전반에 그대로 적용할 수 있습니다.

런타임과 I/O 모델 선택: Tokio를 기본으로, 경계를 분리

Rust 네트워크 서비스에서 가장 흔한 선택은 tokio입니다.

  • 성숙한 생태계: hyper, axum, tonic, tower
  • 고성능 이벤트 루프 기반 비동기 I/O
  • 작업 스케줄링, 타이머, 동기화 프리미티브가 풍부

중요한 설계 원칙은 비동기 경로에서 CPU 바운드 작업을 오래 붙잡지 않는 것입니다. CPU 바운드 작업은 spawn_blocking 또는 별도 워커 풀로 보내고, I/O 경로는 최대한 짧게 유지합니다.

TCP 에코 서버로 보는 기본 뼈대

고성능의 시작은 “올바른 기본”입니다. 아래는 Tokio로 작성한 간단한 TCP 서버 예시입니다.

use tokio::{
    io::{AsyncReadExt, AsyncWriteExt},
    net::TcpListener,
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let listener = TcpListener::bind("0.0.0.0:9000").await?;
    loop {
        let (mut socket, addr) = listener.accept().await?;
        tokio::spawn(async move {
            let mut buf = [0u8; 4096];
            loop {
                let n = match socket.read(&mut buf).await {
                    Ok(0) => return,
                    Ok(n) => n,
                    Err(_) => return,
                };

                if socket.write_all(&buf[..n]).await.is_err() {
                    return;
                }
            }
        });

        // addr는 필요하면 로그/메트릭 태그로 사용
        let _ = addr;
    }
}

여기서 실무로 넘어가면 바로 다음 문제가 등장합니다.

  • 무제한 spawn으로 인한 리소스 폭주
  • 느린 클라이언트가 쓰기 버퍼를 막아 지연 전파
  • 타임아웃 부재로 인한 연결 고착

이 3가지를 해결하는 것이 “고성능”의 핵심입니다.

백프레셔: 무제한 동시성을 끊어라

가장 흔한 장애 패턴은 “트래픽 급증”이 아니라 “처리량보다 더 많은 동시성”을 허용해서 생기는 메모리/큐 폭발입니다.

세마포어로 동시 연결 상한 두기

연결을 무제한으로 받지 말고, 상한을 두고 거절하거나 대기시키세요.

use std::sync::Arc;
use tokio::{net::TcpListener, sync::Semaphore};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let listener = TcpListener::bind("0.0.0.0:9000").await?;
    let sem = Arc::new(Semaphore::new(10_000));

    loop {
        let (socket, _) = listener.accept().await?;
        let permit = match sem.clone().try_acquire_owned() {
            Ok(p) => p,
            Err(_) => {
                // 과부하: 즉시 close 또는 짧은 에러 응답 후 close
                drop(socket);
                continue;
            }
        };

        tokio::spawn(async move {
            let _permit = permit; // 스코프 종료 시 자동 반환
            let _ = handle(socket).await;
        });
    }
}

async fn handle(_socket: tokio::net::TcpStream) -> anyhow::Result<()> {
    Ok(())
}

이 패턴은 HTTP 서버에서도 동일합니다. 요청 단위로 제한할지, 연결 단위로 제한할지, 또는 “핫한 엔드포인트”만 별도 제한할지 정책을 세우는 것이 운영의 핵심입니다.

채널 기반 워커 풀로 CPU 바운드 분리

CPU 바운드 작업을 async 태스크가 붙잡으면 다른 I/O 작업이 밀립니다.

use tokio::sync::mpsc;

#[derive(Debug)]
struct Job {
    payload: Vec<u8>,
}

#[tokio::main]
async fn main() {
    let (tx, mut rx) = mpsc::channel::<Job>(1024); // 큐 길이가 곧 백프레셔

    // 워커
    for _ in 0..8 {
        let mut rx = rx.clone();
        tokio::spawn(async move {
            while let Some(job) = rx.recv().await {
                let _ = tokio::task::spawn_blocking(move || heavy(job.payload)).await;
            }
        });
    }

    let _ = tx.send(Job { payload: vec![1, 2, 3] }).await;
}

fn heavy(_v: Vec<u8>) {
    // 압축, 암호화, 복잡한 파싱 등
}

mpsc::channel의 버퍼 크기는 단순 설정이 아니라 서비스의 메모리 상한과 지연 특성을 결정합니다. 버퍼가 너무 크면 지연이 쌓이고, 너무 작으면 스파이크에 취약해집니다.

타임아웃: 모든 I/O 경로에 데드라인을 걸어라

타임아웃이 없는 네트워크 코드는 결국 리소스를 고정합니다. 읽기, 쓰기, 업스트림 호출, 락 획득 등 “기다림”이 발생하는 지점은 모두 타임아웃 후보입니다.

Tokio timeout으로 읽기/쓰기 제한

use tokio::{
    io::{AsyncReadExt, AsyncWriteExt},
    net::TcpStream,
    time::{timeout, Duration},
};

async fn handle(mut s: TcpStream) -> anyhow::Result<()> {
    let mut buf = [0u8; 4096];

    let n = timeout(Duration::from_secs(5), s.read(&mut buf)).await??;
    timeout(Duration::from_secs(5), s.write_all(&buf[..n])).await??;

    Ok(())
}

실무에서는 “고정 5초” 같은 단일 값 대신, 요청별 데드라인을 만들고 내부 호출에 전파해야 합니다. 그렇지 않으면 프론트는 타임아웃 났는데 백엔드는 계속 일하는 “좀비 작업”이 남습니다. 데드라인 전파 설계는 gRPC 타임아웃 지옥 탈출 - 데드라인 전파 설계에서 다룬 전략을 HTTP나 메시지 처리에도 그대로 적용할 수 있습니다.

프로토콜 파싱: 복사 최소화와 프레이밍

고성능 네트워크에서 병목은 종종 “파싱”입니다. 특히 길이 프리픽스 프레이밍, JSON 파싱, 압축 해제 등이 비싼 편입니다.

  • 가능한 경우 바이너리 프로토콜 또는 gRPC를 고려
  • 텍스트 기반이라면 프레이밍을 명확히 해서 부분 읽기 처리
  • 버퍼 재사용으로 할당을 줄이기

Tokio 생태계에서는 bytes::BytesMut를 사용해 재할당을 줄이고, 프레임 단위로 처리하는 패턴이 흔합니다.

use bytes::BytesMut;
use tokio::io::{AsyncReadExt, AsyncWriteExt};
use tokio::net::TcpStream;

async fn handle(mut s: TcpStream) -> anyhow::Result<()> {
    let mut buf = BytesMut::with_capacity(8 * 1024);
    loop {
        buf.resize(8 * 1024, 0);
        let n = s.read(&mut buf).await?;
        if n == 0 {
            break;
        }
        s.write_all(&buf[..n]).await?;
    }
    Ok(())
}

위 예시는 단순화된 형태이고, 실제로는 buf에 누적된 데이터에서 “프레임 하나를 완성할 수 있는지”를 검사한 뒤 처리합니다.

HTTP 서비스: Axum + Tower로 미들웨어 체계화

실무에서 가장 많이 쓰는 조합은 axum과 tower입니다.

  • 라우팅과 핸들러는 axum
  • 타임아웃, 리트라이, 레이트리밋, 로드셰딩은 tower

예시로, 타임아웃과 동시성 제한을 서비스 레벨에서 강제할 수 있습니다.

use axum::{routing::get, Router};
use std::time::Duration;
use tower::{ServiceBuilder, limit::ConcurrencyLimitLayer, timeout::TimeoutLayer};

async fn health() -> &'static str {
    "ok"
}

#[tokio::main]
async fn main() {
    let middleware = ServiceBuilder::new()
        .layer(ConcurrencyLimitLayer::new(2048))
        .layer(TimeoutLayer::new(Duration::from_secs(2)));

    let app = Router::new()
        .route("/health", get(health))
        .layer(middleware);

    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

이렇게 “정책”을 미들웨어로 밀어 넣으면, 핸들러가 늘어나도 일관된 SLO를 유지하기 쉽습니다.

관측성: 로그가 아니라 메트릭과 트레이싱으로 본다

고성능 서비스는 “빠르다”보다 “느려질 때 원인을 즉시 찾는다”가 더 중요합니다.

  • tracing: 요청 단위 스팬으로 지연 구간 파악
  • metrics: QPS, p50/p95/p99, 에러율, 큐 길이, 동시성, 메모리
  • 구조화 로그: 장애 시 필터링 가능한 필드 중심

Rust에서는 tracing과 tracing-subscriber가 사실상 표준입니다.

use tracing::{info, instrument};

#[instrument(skip(payload))]
async fn process(user_id: u64, payload: &[u8]) -> anyhow::Result<()> {
    info!(len = payload.len(), "processing");
    Ok(())
}

운영 환경에서는 OOM과 리소스 제한이 성능을 “갑자기” 무너뜨립니다. 쿠버네티스에서 OOMKilled나 프로브 설정 문제로 재시작 루프가 나면, 성능 튜닝 이전에 서비스 자체가 불안정해집니다. 이런 상황은 K8s CrashLoopBackOff - OOMKilled·Probe 5분 진단 체크리스트가 그대로 도움이 됩니다.

메모리와 할당: p99 지연의 숨은 원인

Rust는 GC가 없지만, 할당이 0인 것은 아닙니다. 고성능 네트워크에서 특히 주의할 점은 아래입니다.

  • 요청마다 Vec를 새로 만들지 말고 버퍼 재사용
  • 문자열 파싱에서 불필요한 to_string 남발 금지
  • 큰 구조체를 태스크 간 이동할 때 복사 비용 고려
  • Arc 남발은 원자적 참조 카운트 비용을 만든다

성능을 올리려면 먼저 “어디서 할당이 발생하는지”를 찾아야 합니다. pprof-rs, tokio-console, perf 등을 조합하면 병목이 빨리 드러납니다.

안전한 종료와 배포: SIGTERM, 드레이닝, 커넥션 정리

프로덕션에서 고성능은 배포 순간에도 유지되어야 합니다.

  • SIGTERM 수신 시 새 요청 수락 중단
  • 진행 중 요청은 데드라인 내에서 처리 후 종료
  • 커넥션 드레이닝과 로드밸런서 헬스체크 연동

쿠버네티스에서 Pod가 종료되지 않고 Terminating에 걸리면 롤링 업데이트가 정체되고, 결과적으로 트래픽이 일부 인스턴스에 몰려 지연이 튈 수 있습니다. 이런 문제는 Kubernetes Pod가 Terminating에 멈출 때 - finalizer·grace·SIGTERM 실전 디버깅에서 다룬 포인트를 그대로 참고하면 좋습니다.

실전 체크리스트: 성능과 안정성을 동시에 잡는 순서

마지막으로, Rust로 네트워크 서비스를 만들 때 “효과 대비 비용”이 큰 순서대로 점검 항목을 정리합니다.

  1. 타임아웃 전파: 외부 호출, 내부 큐, 락 대기, 읽기/쓰기 모두
  2. 동시성 상한: 연결 수, 요청 수, 엔드포인트별 제한
  3. 백프레셔: 큐 길이 제한, 과부하 시 드롭/거절 정책
  4. 관측성: p99, 큐 길이, 동시성, 에러율, 업스트림 지연
  5. CPU 바운드 분리: spawn_blocking 또는 워커 풀
  6. 버퍼/할당 최적화: 재사용, 복사 최소화, 파싱 비용 줄이기
  7. 종료/배포 안정화: 드레이닝, SIGTERM 처리, 프로브 점검

마무리

Rust는 네트워크 서비스에서 “빠른 코드”를 쓰게 해주는 언어라기보다, 실수하기 어려운 구조를 강제하면서도 성능을 잃지 않게 해주는 도구에 가깝습니다. Tokio 기반 비동기 I/O 위에 백프레셔·타임아웃·관측성을 먼저 설계하고, 그 다음에 파싱/할당/스케줄링을 최적화하면 p99 지연과 장애 빈도가 눈에 띄게 줄어듭니다.

다음 단계로는 실제 워크로드에 맞춰 HTTP, gRPC, 메시지 큐 중 어떤 인터페이스가 적합한지 결정하고, 메트릭을 기반으로 병목을 하나씩 제거해보세요. 성능 튜닝은 “감”이 아니라 “측정과 정책”의 게임입니다.

Discuss on Twitter • View on GitHub