트래픽이 갑자기 몰릴 때 Node.js 서비스가 무너지는 이유는 단순히 요청 수가 많아서가 아닙니다. 더 자주 문제를 만드는 것은 처리 속도보다 입력 속도가 더 빠른데도 계속 받아들이는 구조입니다. 읽는 쪽보다 쓰는 쪽이 느린 스트림, 소비보다 적재가 빠른 작업 큐, 응답이 밀리는데도 무한히 재시도하는 외부 API 호출이 대표적입니다. 이때 필요한 개념이 backpressure입니다. backpressure는 데이터를 더 빨리 밀어 넣는 대신, 시스템이 감당 가능한 속도에 맞춰 흐름을 조절하는 설계입니다. 이 글에서는 Node.js에서 backpressure가 왜 중요한지, 스트림·큐·HTTP 호출 구간에 어떻게 적용하는지, bulkhead·adaptive concurrency 같은 패턴과는 어떤 관계인지 실무 관점에서 정리합니다.

Node.js backpressure는 왜 중요한가

H3. 과부하는 순간적인 폭주보다 처리 불균형이 오래 지속될 때 더 위험하다

운영 환경에서 과부하는 보통 한 번의 스파이크로 끝나지 않습니다. 문제는 입력과 처리 속도 차이가 몇 초, 몇 분씩 누적되는 상황입니다. 예를 들면 아래 같은 흐름입니다.

  • 업로드 요청은 빠르게 들어오는데 썸네일 생성 작업이 천천히 처리됨
  • 이벤트는 초당 수천 건 들어오는데 DB 적재가 지연됨
  • 외부 API 응답이 느려졌는데 내부에서는 계속 병렬 호출을 늘림
  • 로그·메시지 스트림 소비 속도보다 생산 속도가 더 빨라 메모리가 불어남

이런 구조에서는 처음엔 버텨 보입니다. 하지만 내부 버퍼, 큐, 메모리, 커넥션 풀이 점점 차오르면서 결국 지연 증가 → 타임아웃 증가 → 재시도 증가 → 추가 과부하의 악순환이 시작됩니다. backpressure는 이 악순환을 끊기 위한 기본 장치입니다.

H3. 많이 받는 것보다 적절히 거절하거나 늦추는 편이 전체 안정성에 유리하다

많은 시스템이 “요청을 최대한 다 받는 것”을 친절하다고 착각합니다. 하지만 감당할 수 없는 입력을 계속 받는 것은 결국 더 큰 실패로 이어집니다. Node.js에서는 특히 메모리 버퍼링과 비동기 작업 누적이 조용히 쌓이다가 뒤늦게 크게 터지는 경우가 많습니다.

그래서 backpressure의 핵심 질문은 단순합니다.

  • 지금 이 입력을 받아도 downstream이 처리 가능한가
  • 처리 대기열이 이미 위험 수준인데 더 쌓아도 되는가
  • 늦게 성공시키는 것과 빨리 실패시키는 것 중 무엇이 더 나은가

이 질문에 답하지 못하면, 서비스는 바쁠수록 더 비효율적으로 망가집니다.

backpressure는 어떻게 동작하나

H3. 생산자 속도를 소비자 처리 능력에 맞춰 조절하는 것이 본질이다

backpressure는 복잡한 기술 하나를 뜻하지 않습니다. 핵심은 생산자(producer)가 소비자(consumer)의 처리 속도를 존중하게 만드는 것입니다. 이를 위해 흔히 아래 같은 방법을 씁니다.

  • 버퍼가 찼을 때 일시 정지하거나 대기하기
  • 큐 길이가 임계치를 넘으면 적재를 제한하기
  • 동시 실행 수를 고정하거나 동적으로 줄이기
  • 느린 downstream 앞에서 timeout과 fast-fail 적용하기
  • 사용자 요청을 429, 503 등으로 조기에 거절하기

즉 backpressure는 “무조건 처리”가 아니라 안전하게 처리 가능한 양만 흘려보내는 운영 규율에 가깝습니다.

H3. Node.js에서는 스트림의 drain, highWaterMark, 큐 제한이 실전 도구가 된다

Node.js는 backpressure를 다루기 위한 기본 도구를 이미 많이 제공합니다. 대표적으로 스트림은 내부 버퍼가 가득 차면 write()가 false를 반환하고, 이때 생산자는 drain 이벤트까지 기다려야 합니다. 또한 highWaterMark를 통해 버퍼 임계치를 조절할 수 있습니다.

이 원리는 스트림 밖에서도 그대로 확장됩니다.

  • 작업 큐에서는 최대 대기 건수 제한
  • HTTP 호출에서는 기능별 concurrency limit
  • 메시지 소비에서는 consumer pause/resume
  • 배치 처리에서는 chunk 크기 조절

결국 형태만 다를 뿐, 본질은 모두 같습니다. 처리 속도보다 빠른 유입을 그대로 방치하지 않는 것입니다.

Node.js에서 어떤 구간에 먼저 적용해야 할까

H3. 스트림, 작업 큐, 외부 API 호출 구간이 1차 적용 대상이다

실무에서 가장 먼저 점검할 곳은 아래 세 군데입니다.

  • 파일 업로드·다운로드·로그 처리 같은 stream 기반 구간
  • BullMQ 같은 background job queue 구간
  • 결제·알림·추천 등 외부 HTTP API 호출 구간

이 셋은 공통적으로 “들어오는 속도”와 “처리 완료 속도”가 쉽게 어긋납니다. 그리고 한 번 밀리기 시작하면 메모리 사용량, 지연 시간, 실패율이 연쇄적으로 흔들리기 쉽습니다.

특히 Node.js에서는 외부 API가 느려질 때 단순히 await가 많아지는 문제가 아니라, 동시에 대기 중인 promise와 응답 객체, 재시도 작업, 큐 backlog가 함께 불어나는 문제로 번지는 경우가 많습니다.

H3. 배치 적재와 실시간 요청이 같은 자원을 먹고 있다면 거의 반드시 손봐야 한다

운영 환경에서 자주 보는 패턴은 배치가 조용히 실시간 경로를 압박하는 경우입니다. 예를 들면 아래와 같습니다.

  • 대량 CSV 업로드 파싱이 API 서버 메모리를 잠식함
  • 재처리 배치가 Redis queue를 가득 채워 실시간 작업이 늦어짐
  • webhook 재전송이 외부 API 호출 슬롯을 모두 점유함

이 경우 backpressure 없이 재시도와 적재만 계속하면 문제는 더 커집니다. 반대로 대기열 상한, chunk 분할, concurrency 축소, 일시 정지를 적용하면 같은 장애에서도 훨씬 예측 가능하게 운영할 수 있습니다.

Node.js backpressure 구현 예시

H3. 스트림에서는 write 반환값과 drain 이벤트를 무시하지 않는 것이 기본이다

아래 예시는 writable stream의 처리 여유를 확인하면서 안전하게 데이터를 쓰는 방식입니다.

import fs from 'node:fs';
import { once } from 'node:events';

const writer = fs.createWriteStream('./app.log', {
  highWaterMark: 64 * 1024
});

async function writeLines(lines) {
  for (const line of lines) {
    const canContinue = writer.write(`${line}\n`);

    if (!canContinue) {
      await once(writer, 'drain');
    }
  }
}

여기서 중요한 점은 write()가 false를 반환했을 때도 계속 밀어 넣지 않는 것입니다. 이 신호를 무시하면 내부 버퍼가 커지고 메모리 사용량이 빠르게 증가할 수 있습니다.

H3. 외부 API 호출은 동시성 제한과 큐 상한을 함께 둬야 효과가 난다

HTTP 호출은 스트림처럼 눈에 보이는 drain 이벤트가 없어서 더 위험합니다. 그래서 보통은 concurrency limit + queue 상한 + timeout 조합이 잘 맞습니다.

import pLimit from 'p-limit';

const limit = pLimit(8);
let queued = 0;
const MAX_QUEUE = 100;

async function fetchProfile(userId) {
  if (queued >= MAX_QUEUE) {
    const error = new Error('server overloaded');
    error.statusCode = 503;
    throw error;
  }

  queued += 1;

  try {
    return await limit(async () => {
      const response = await fetch(`https://api.example.com/users/${userId}`, {
        signal: AbortSignal.timeout(1500)
      });

      if (!response.ok) {
        throw new Error(`upstream error: ${response.status}`);
      }

      return response.json();
    });
  } finally {
    queued -= 1;
  }
}

핵심은 두 가지입니다. 첫째, 동시에 처리할 양을 제한합니다. 둘째, 이미 대기열이 과도하게 쌓였다면 더 받지 않습니다. 이 둘 중 하나만 있으면 보호 효과가 약해집니다.

H3. 메시지 큐 소비자는 pause와 resume 전략을 함께 가져가야 한다

Kafka, RabbitMQ, Redis stream 같은 메시지 시스템에서도 backpressure는 매우 중요합니다. 소비 속도가 적재 속도를 따라가지 못할 때 무작정 poll만 늘리면 처리 지연이 더 커집니다. 그래서 아래 같은 전략이 자주 쓰입니다.

  • 처리 중 작업 수가 임계치에 도달하면 consumer pause
  • backlog가 내려오면 resume
  • batch 크기 축소
  • 실패 메시지는 별도 DLQ로 이동

중요한 점은 “메시지를 많이 읽는 것”이 아니라 읽은 메시지를 책임 있게 끝낼 수 있는가입니다. 읽기만 빨라지고 완료는 느리면 시스템은 더 불안정해집니다.

bulkhead, adaptive concurrency와는 어떻게 다를까

H3. backpressure는 흐름 제어, bulkhead는 자원 격리, adaptive concurrency는 제한값 자동 조절에 가깝다

이 개념들은 비슷해 보이지만 초점이 조금 다릅니다.

  • Backpressure: 감당 가능한 속도만 흘려보낸다
  • Bulkhead: 한 영역 과부하가 다른 영역으로 퍼지지 않게 자원을 나눈다
  • Adaptive concurrency: 현재 지연과 오류 상황에 맞춰 동시성 한도를 동적으로 조절한다

실무에서는 이 셋을 함께 쓰는 편이 좋습니다. 예를 들어 추천 API가 느려졌을 때 아래 조합이 자연스럽습니다.

  1. 추천 호출 전용 풀로 bulkhead 적용
  2. 동시성 한도를 adaptive concurrency로 자동 조정
  3. 내부 큐 길이가 임계치를 넘으면 backpressure로 신규 적재 제한

관련해서 자원 격리 설계를 먼저 보고 싶다면 Node.js Bulkhead Pattern 가이드를 함께 읽어보면 좋습니다. 또 동시성 한도를 자동으로 다루는 방법은 Node.js Adaptive Concurrency Limit 가이드에서 이어서 볼 수 있습니다.

H3. 재시도는 backpressure 없이 늘리면 보호가 아니라 증폭 장치가 된다

많이 놓치는 함정이 재시도입니다. 실패했다고 곧바로 다시 밀어 넣으면 시스템은 회복할 시간을 얻지 못합니다. 특히 이미 느린 downstream 앞에서 aggressive retry를 걸면 대기열과 동시성 슬롯이 더 빨리 고갈됩니다.

그래서 재시도는 아래 원칙과 함께 가야 합니다.

  • exponential backoff 적용
  • jitter 추가로 동시 재시도 분산
  • 최대 retry 횟수 제한
  • 사용자 요청 경로와 background retry 분리
  • overload 상태에서는 retry보다 fast-fail 우선

실패 전파를 빨리 차단하는 설계는 Node.js Circuit Breaker 가이드와 함께 보면 전체 그림이 더 잘 잡힙니다.

운영하면서 꼭 봐야 할 지표

H3. 평균 응답 시간보다 queue depth와 메모리 증가 속도가 더 빨리 경고를 준다

backpressure가 필요한 시스템은 보통 평균 latency만으로는 이상 징후를 늦게 발견합니다. 오히려 아래 지표가 더 빨리 신호를 줍니다.

  • queue depth와 backlog 증가 속도
  • in-flight request 수
  • promise pending 개수 추이
  • process RSS, heap usage, GC pause
  • event loop lag
  • upstream timeout 비율
  • 429, 503 응답 비율

이 지표를 기능별로 나눠 봐야 의미가 있습니다. 전체 평균만 보면 특정 구간의 포화를 놓치기 쉽습니다.

H3. 어떤 요청을 늦출지와 어떤 요청을 거절할지 미리 정해야 실제 장애 때 덜 흔들린다

backpressure는 결국 우선순위 설계입니다. 자원이 부족해질 때 모든 요청을 똑같이 대할 수는 없습니다. 그래서 미리 정해야 합니다.

  • 로그인과 결제는 끝까지 보호할 것인가
  • 추천, 통계, 관리자 export는 먼저 늦추거나 거절할 것인가
  • 실시간 요청과 배치 작업 중 어느 쪽을 우선할 것인가

이 기준이 있어야 429/503 정책, 큐 상한, worker concurrency, retry 전략이 일관되게 정리됩니다.

Node.js backpressure 적용 체크리스트

H3. 아래 항목에 많이 해당되면 지금이 과부하 제어를 설계할 시점이다

배포 전이나 장애 회고 때 아래 체크리스트를 빠르게 점검해볼 수 있습니다.

  • 입력 속도와 처리 속도 차이를 관찰하는 지표가 없다
  • 큐 길이 상한 없이 작업을 계속 적재한다
  • 스트림 write()의 반환값을 신경 쓰지 않는다
  • 외부 API 호출에 concurrency limit가 없다
  • overload 상황에서도 무조건 retry부터 시도한다
  • 메모리 급증 후에야 장애를 인식하는 일이 잦다

두세 개 이상 해당되면 backpressure 설계를 우선순위에 올릴 만합니다.

자주 묻는 질문

H3. backpressure는 스트림에서만 필요한 개념인가요?

아닙니다. 스트림이 가장 대표적일 뿐이고, 실제로는 HTTP 호출, 작업 큐, 메시지 소비, 배치 처리 등 입력과 처리 속도가 다른 모든 곳에 적용할 수 있습니다.

H3. 트래픽이 작은 서비스에도 backpressure가 필요할까요?

아주 단순한 서비스라면 과할 수 있습니다. 하지만 외부 API, background job, 대용량 업로드처럼 처리 편차가 큰 구간이 있다면 작은 서비스라도 기본적인 상한과 거절 전략은 빨리 넣는 편이 좋습니다.

H3. 503을 반환하는 것은 나쁜 사용자 경험 아닌가요?

무한 대기 끝에 타임아웃이 나는 것보다, 과부하 상태를 빠르게 알리고 재시도 가능성을 안내하는 편이 더 나은 경우가 많습니다. 중요한 것은 무조건 거절이 아니라 어떤 상황에서 얼마나 일찍 실패시킬지를 의도적으로 설계하는 것입니다.

마무리

Node.js에서 backpressure는 성능 최적화 기법이라기보다 서비스가 과부하를 품위 있게 다루는 방법에 가깝습니다. 문제는 요청이 많은 것 자체보다, 감당하지 못할 양을 계속 받아들여 내부에서 조용히 붕괴하는 구조에 있습니다. 그래서 잘 만든 시스템은 바쁠수록 더 많이 버티는 것이 아니라, 바쁠수록 더 정확하게 늦추고 거절합니다.

트래픽 급증은 피하기 어렵습니다. 대신 어디서 멈추고, 무엇을 보호하고, 어떤 요청을 나중에 처리할지는 설계할 수 있습니다. 그 설계의 중심에 backpressure가 있습니다.