서버리스 커넥션 풀링이란?

서버리스 커넥션 풀링은 소수의 실제 데이터베이스 연결을 수명이 짧은 다수의 함수 인스턴스가 공유하게 하는 기법입니다. 이 기법이 존재하는 이유는 두 확장 모델이 서로 맞지 않기 때문입니다. 서버리스 컴퓨팅은 부하에 인스턴스를 늘리는 방식으로 대응하는 반면, 데이터베이스는 모든 연결을 메모리를 점유하는 비싼 자원으로 취급하며 엄격한 상한을 둡니다. 둘을 단순하게 결합하면 적당한 트래픽 급증만으로도 too many connections 장애가 됩니다.

핵심 요약

데이터베이스에서 관찰한 장애

-- 서버리스 트래픽 급증 중 데이터베이스가 보는 모습:
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;
--  active               |   14
--  idle                 |  483     ← 웜 함수 인스턴스가 붙잡아 둔 연결
SHOW max_connections;    --  100    ← 이미 뚫려 버린 상한

-- 각 연결은 실제 메모리를 점유하는 실제 프로세스입니다.
-- 그래서 상한이 존재하며, 상한을 올리는 것은 해결책이 아닙니다.

문제의 형태는 이렇습니다. 함수 인스턴스마다 자체 연결을 열고, 호출 사이의 유휴 시간에도 그 연결을 유지하며, 인스턴스 수는 개발자가 아니라 트래픽이 결정합니다. 재사용은 웜 인스턴스 안에서만 일어나고 인스턴스 사이에서는 결코 일어나지 않으므로, 동시성 300은 연결 하나짜리 풀 300개를 뜻합니다. max_connections를 올리면 실제 메모리 비용을 치르고 여유를 확보할 뿐, 더 큰 급증이 오면 다시 한계에 부딪힙니다.

관리형 백엔드에서는 애플리케이션 코드가 이 문제에서 완전히 벗어납니다. SDK 호출은 무상태 HTTPS 요청이며, 어떤 클라이언트도 데이터베이스 연결을 보유하지 않습니다.

// JavaScript / Node.js — Back4app JS SDK
// Inside a serverless function: no driver, no pool, no connection to leak.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com';

export async function handler(event) {
  const query = new Parse.Query('Order');
  query.equalTo('status', 'pending');
  query.limit(20);
  const orders = await query.find();  // request returns; nothing stays open
  return orders.map((o) => o.id);
}
// 1,000 concurrent invocations = 1,000 HTTP requests,
// not 1,000 database connections.

// Flutter / Dart — Back4app Flutter SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
await Parse().initialize(
  'APP_ID',
  'https://parseapi.back4app.com',
  clientKey: 'CLIENT_KEY',
);

Future<List<String>> pendingOrderIds() async {
  final query = QueryBuilder<ParseObject>(ParseObject('Order'))
    ..whereEqualTo('status', 'pending')
    ..setLimit(20);
  final response = await query.query(); // request returns; nothing stays open
  return response.results!
      .map((o) => (o as ParseObject).objectId!)
      .toList();
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

// iOS / Swift — Back4app Swift SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
ParseSwift.initialize(
  applicationId: "APP_ID",
  clientKey: "CLIENT_KEY",
  serverURL: URL(string: "https://parseapi.back4app.com")!
)

let query = Order.query("status" == "pending")
  .limit(20)
query.find { result in
  if case .success(let orders) = result {
    render(orders)                 // request returned; nothing stays open
  }
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

// Android / Kotlin — Back4app Android SDK
// No driver, no pool, no connection to leak from the client side.
// Each SDK call is a stateless HTTPS request; pooling happens platform-side.
Parse.initialize(
    Parse.Configuration.Builder(context)
        .applicationId("APP_ID")
        .clientKey("CLIENT_KEY")
        .server("https://parseapi.back4app.com")
        .build()
)

val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "pending")
query.limit = 20
query.findInBackground { orders, e ->
    if (e == null) render(orders)  // request returned; nothing stays open
}
// A burst of clients = a burst of HTTP requests,
// not a burst of database connections.

풀러가 팬아웃을 흡수하는 방식

PgBouncer 같은 풀러는 클라이언트 연결을 수천 개 단위로 받아들이고(풀러 쪽에서는 각각의 비용이 쌉니다), 작업이 도착할 때만 소수의 풀에서 실제 서버 연결을 빌려줍니다. 데이터베이스는 안정적인 연결 20개를 보고, 함수 500개는 각자 연결을 하나씩 가졌다고 믿습니다. 수요가 풀을 넘으면 클라이언트는 오류를 받는 대신 대기열에서 몇 밀리초를 기다립니다. 치명적인 실패가 약간의 지연 시간으로 바뀌는 것입니다.

풀 크기 산정은 직관이 가장 크게 틀리는 지점입니다. 데이터베이스의 유효 병렬성은 코어와 디스크에 묶여 있습니다. 처리량은 보통 풀 크기가 수십 개 이내의 낮은 수준, 즉 코어 수의 두 배 근처일 때 정점에 이르고, 연결이 더 늘면 경합이 커져 오히려 떨어집니다. 풀러의 계산이 성립하는 이유는 서버리스 요청이 짧기 때문입니다. 8 ms짜리 트랜잭션을 처리하는 연결 하나는 초당 100건을 훌쩍 넘게 처리할 수 있으므로, 실제 연결 20개로 수천 건의 함수 호출을 넉넉히 흡수합니다. 풀은 편의를 위한 캐시가 아니라, 대기 비용이 싼 곳에 의도적으로 둔 병목입니다.

결정적인 조절 다이얼은 임대가 얼마나 오래 지속되는가입니다.

트랜잭션 풀링 vs. 세션 풀링

트랜잭션 모드는 서버리스 워크로드를 가능하게 만드는 요소입니다. 8 ms 트랜잭션 하나를 실행하는 함수가 몇 분에 걸친 웜 수명 내내 연결을 소유해서는 안 됩니다. 하지만 공짜는 아닙니다. SQL 문 사이에 “내 연결”이 유지된다고 가정하는 모든 것이 미묘한 버그가 됩니다. 일반적인 권장 사항은 요청 트래픽에는 트랜잭션 풀링을, 마이그레이션과 상태가 있는 모든 작업에는 직접 연결이나 세션 풀링 연결을 쓰는 것입니다.

일반적인 사용 사례

• SQL에 접근하는 서버리스 함수와 엣지 함수. 대표적인 사례로, 급변하는 인스턴스 수가 고정된 연결 예산과 맞부딪힙니다.
• 작은 서비스 여럿, 데이터베이스 하나. 서비스 20개 × 기본 풀 크기 10 = 아무도 계획하지 않은 연결 200개. 공유 풀러를 두면 연결 수를 다시 통제할 수 있습니다.
• 멀티테넌트 플랫폼. 테넌트별 워크로드가 연결 수요를 몇 배로 늘리며, 풀링을 쓰면 공유 데이터베이스의 연결 예산을 계속 지킬 수 있습니다.
• 작은 데이터베이스에 몰리는 트래픽 버스트. 출시일의 급증이 데이터베이스에서 오류를 내는 대신 풀러에서 몇 밀리초 동안 대기합니다.
• 장애 중 프라이머리 보호. 고정 크기 풀은 격벽(bulkhead)입니다. 폭주하는 클라이언트는 데이터베이스의 메모리가 아니라 풀러의 대기열을 소진합니다.

자체 풀러를 운영해야 할까? 결정 매트릭스

솔직히 말해 둘은 대등하지 않습니다. 풀러는 연결 고갈을 해결하지만, 관리형 백엔드는 연결 고갈이 생길 여지를 아예 없앱니다. 클라이언트가 자동 생성된 API와 HTTPS로 통신하면 팬아웃은 데이터베이스 계층에 아예 닿지 않습니다. 풀링은 여전히 일어나지만, 직접 운영하는 구성 요소가 아니라 다른 누군가가 충분히 검증한 인프라로서 일어납니다.

한계와 트레이드오프

• 풀러는 하나의 구성 요소입니다. 배포, 모니터링, 장애 조치, 업그레이드가 필요합니다. 자원 문제를 운영 문제와 맞바꾼 것이며, 유리한 거래이긴 하지만 비용이 없는 것은 아닙니다.
• 트랜잭션 모드는 의미를 바꿉니다. prepared statement, 세션 변수, advisory lock이 문서대로 동작하지 않게 됩니다. 실패는 간헐적이고 부하에 따라 달라지는, 가장 나쁜 종류입니다.
• 홉이 하나 더 늘면 지연 시간이 듭니다. 같은 네트워크 안에서는 보통 1밀리초 미만이지만, 모든 쿼리의 경로 위에 있습니다.
• 풀러가 병목이 될 수 있습니다. 단일 스레드 풀러는 격렬한 급증 아래에서 대기열이 깊어집니다. 상한은 이동했을 뿐 사라지지 않았습니다.
• 풀링은 느린 쿼리를 고치지 않습니다. 풀링은 연결을 배급할 뿐이며, 몇 초 동안 연결을 붙잡는 쿼리는 풀을 고갈시킵니다. 빠른 쿼리와 그 뒤의 인덱스가 여전히 진짜 용량 조절 수단입니다.

Back4app에서의 커넥션 풀링

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이 아키텍처는 풀링 문제에 구조적으로 답합니다. 클라이언트 앱과 Cloud Code 함수는 무상태 HTTPS 요청을 보내고, 개발자의 코드가 아니라 플랫폼의 서버 계층이 관리형 데이터베이스에 대해 수명이 길고 적정 크기인 커넥션 풀을 유지합니다. 컴퓨팅 쪽의 인스턴스 팬아웃이 데이터베이스 쪽의 연결 팬아웃으로 이어지는 일은 없으며, 이 글에서 다룬 기법들이 얻으려는 것이 바로 이 속성입니다.