모던 애플리케이션 백엔드는 어떻게 확장할까?

모던 애플리케이션 백엔드 확장은 트래픽이 늘어도 속도를 유지하도록 컴퓨팅, 데이터베이스, 전송 계층의 용량을 늘리는 과정입니다. 하드웨어 광고가 건너뛰는 부분이 있습니다. 확장은 구매이기 이전에 속성입니다. 무상태 서비스, 인덱스가 걸린 쿼리, 페이지네이션된 읽기 위에 세운 백엔드는 머신을 추가하는 것으로 확장되지만, 이런 속성이 없는 백엔드는 추가되는 머신을 모두 공유 병목 앞의 구경꾼으로 만들 뿐입니다. 이 페이지는 결정 프레임워크입니다. 어떤 수단이 있고, 어떤 순서로 쓰며, 각각이 언제 시기상조인지를 다룹니다. 단계별 구축 과정은 확장 가능한 백엔드 구축 완벽 가이드에서 다룹니다.

핵심 요약

쿼리 안에 있는 가장 저렴한 확장

인프라를 바꾸기 전에 요청 자체가 첫 번째 수단입니다. 선택적 필드, 인덱스가 걸린 필터, 테이블 스캔 대신 한 페이지, N번의 왕복 대신 배치 하나:

// The cheapest scaling is the request you never make.
// A read path that stays fast at 10x the data: selective, indexed, paginated.
const query = new Parse.Query('Order');
query.equalTo('status', 'open');       // hits the status index
query.select('total', 'createdAt');    // only the fields the list renders
query.descending('createdAt');         // matches the index order
query.limit(50);                       // a page, never "fetch all"
const page = await query.find();

// Writes that batch: one round trip for the whole cart, not N.
const items = cart.map((i) => new Parse.Object('LineItem', i));
await Parse.Object.saveAll(items);

// The cheapest scaling is the request you never make.
// Selective, indexed, paginated read — fast at 10x the data.
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'open')          // hits the status index
  ..keysToReturn(['total', 'createdAt'])    // only what the list renders
  ..orderByDescending('createdAt')          // matches the index order
  ..setLimit(50);                           // a page, never "fetch all"
final page = await query.query();

// Writes that batch: one round trip for the whole cart, not N.
final items = cart.map((i) => ParseObject('LineItem')..set('sku', i.sku)).toList();
await ParseObject('LineItem').saveAll(items);

// The cheapest scaling is the request you never make.
// Selective, indexed, paginated read — fast at 10x the data.
var query = Order.query("status" == "open")   // hits the status index
query.select = ["total", "createdAt"]          // only what the list renders
query.order = [.descending("createdAt")]       // matches the index order
query.limit = 50                               // a page, never "fetch all"
let page = try await query.find()

// Writes that batch: one round trip for the whole cart, not N.
let items = cart.map { LineItem(sku: $0.sku, qty: $0.qty) }
try await LineItem.saveAll(items)

// The cheapest scaling is the request you never make.
// Selective, indexed, paginated read — fast at 10x the data.
val query = ParseQuery.getQuery<ParseObject>("Order")
    .whereEqualTo("status", "open")            // hits the status index
    .selectKeys(listOf("total", "createdAt"))  // only what the list renders
    .orderByDescending("createdAt")            // matches the index order
    .setLimit(50)                              // a page, never "fetch all"
val page = query.find()

// Writes that batch: one round trip for the whole cart, not N.
val items = cart.map { ParseObject("LineItem").apply { put("sku", it.sku) } }
ParseObject.saveAllInBackground(items)

이를 모든 곳에서 실천하는 백엔드는 “진짜” 확장이 필요해지는 시점을 트래픽이 열 배로 늘 때까지 미루는 경우가 많습니다. 그리고 확장이 실제로 닥쳤을 때, 추가된 용량이 제값을 하게 만드는 것도 바로 이 습관입니다.

수직 vs. 수평 확장

대부분의 프로덕션 시스템이 도달하는 실용적인 결론은 이렇습니다. 무상태 애플리케이션 계층은 수평으로, 데이터베이스는 먼저 수직으로 확장합니다. 복제본과 샤드는 더 큰 데이터베이스 머신으로 충분하지 않게 될 때만 씁니다.

확장의 사다리

각 단계는 복잡성이라는 점점 비싸지는 값을 치르고 용량을 삽니다. 무상태는 입장료입니다. 로드 밸런서는 어떤 인스턴스든 어떤 요청이든 처리할 수 있을 때만 도움이 됩니다. 인덱스와 페이로드 규율은 각 요청이 치르는 작업을 줄입니다. CDN은 정적 트래픽을 백엔드에서 완전히 걷어냅니다. 커넥션 풀링은 탄력적으로 늘어나는 컴퓨팅이 데이터베이스의 목을 조르지 않게 하고, 읽기 복제본은 읽기 부하를 분산합니다. 샤딩과 다중 리전 복제는 의도적으로 맨 마지막에 둡니다. 실제 문제를 해결하지만, 앞선 모든 단계가 피해 가는 일관성 트레이드오프를 끌어들이기 때문입니다.

어떤 확장 수단을 먼저 써야 할까?

패턴은 이렇습니다. “확장해야 한다”는 순간의 대부분은 인덱스 하나, 캐시 하나, 풀 하나면 해결됩니다. 비싼 인프라 장치는 값싼 수단이 소진된 뒤에야 그 복잡성에 값하며, 지금 어느 행에 있는지를 알려 주는 것은 모니터링(p95 지연 시간, 연결 수, 복제 지연)입니다.

관리형 백엔드가 흡수하는 것

이 문제의 서버리스 절반과 NoOps 절반이 바로 관리형 플랫폼이 패키징하는 것입니다. 애플리케이션 계층은 구조적으로 무상태이고 로드 밸런싱되며, 컴퓨팅은 트래픽에 맞춰 자동 확장되고, 데이터베이스 연결은 풀링된 채 도착하며, 파일은 별도 설정 없이 CDN을 통해 전달됩니다. 이로써 사다리의 인프라 단계들은 플랫폼 기본값으로 접힙니다. 남는 것은 엔지니어링 절반입니다. 데이터 모델링, 인덱스, 쿼리 형태, 페이지네이션입니다. 어떤 플랫폼도 인덱스 없는 테이블 스캔을 빠르게 만들 수는 없습니다. 제대로 된 플랫폼이라면 개발자가 여전히 만들어 낼 수 있는 느림이 그것 하나뿐이도록 해 줍니다.

일반적인 사용 사례

• 출시 직후의 급증 – 제품이 주말 동안 입소문을 탑니다. 자동 확장되는 무상태 컴퓨팅이 이를 흡수하고, 읽기가 페이지네이션되고 캐시되어 있었기에 데이터베이스가 살아남습니다.
• 꾸준한 성장 – 월간 활성 사용자가 몇 배로 늘어납니다. 사다리는 추측이 아니라 측정값이 요구할 때 한 단씩 오릅니다.
• 읽기 위주 제품 – 콘텐츠, 카탈로그, 대시보드. CDN + 캐시 + 복제본이 쓰기 경로를 건드리지 않고 100:1의 읽기 비율을 감당합니다.
• 버스트형 워크로드 – 캠페인, 한정 판매, 시즌 피크. 탄력적 컴퓨팅과 큐에 넣은 백그라운드 작업이 급증을 평탄하게 만듭니다.
• 글로벌 사용자층 – 오리진에서 멀리 떨어진 지연 민감 사용자. 전송은 먼저 CDN으로 확장하고, 다중 리전 데이터는 데이터 지역성이 정말로 요구할 때만 씁니다.

지금 확장해야 할까? 결정 매트릭스

한계와 트레이드오프

• 복잡성이 화폐입니다. 사다리를 한 단 오를 때마다 운영하고 디버깅해야 할 움직이는 부품(밸런서, 복제본, 무효화, 지연)이 늘어납니다. 측정값이 요구할 때만 복잡성으로 용량을 사야 합니다.
• 캐시는 신선함을 속도와 맞바꿉니다. 무효화는 악명 높게 어렵습니다. 추가하는 캐시마다 이제부터 유지해야 할 일관성 계약이 하나씩 늘어납니다.
• 복제는 지연을 끌어들입니다. 읽기 복제본은 약간 오래된 데이터를 제공하므로, 쓰기 직후에 읽는 코드는 이를 알아야 합니다. 다중 리전은 같은 트레이드오프를 대륙 규모로 감수합니다.
• 샤딩은 되돌릴 수 없는 문입니다. 샤드 간 쿼리와 트랜잭션은 영구적으로 어려워집니다. 인덱스, 캐싱, 복제본을 먼저 소진해야 합니다.
• 확장은 지금 가진 데이터 모델을 증폭합니다. 좋은 스키마는 우아하게 확장되고, 나쁜 스키마는 자신의 병리를 확장합니다. 모델링, 인덱스, 쿼리 형태라는 화려하지 않은 작업이 비싼 인프라 장치의 가치를 결정합니다.

Back4app에서의 백엔드 확장

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 사다리의 인프라 장치는 플랫폼의 기본 자세입니다. 무상태이고 로드 밸런싱되며 자동 확장되는 컴퓨팅, 풀링된 데이터베이스 연결, CDN 뒤의 파일이 그것입니다. 반면 이 글이 여전히 중요하다고 강조하는 수단은 여러분의 손에 남습니다. 시각적 인덱스 관리, 선택적이고 페이지네이션된 읽기를 자연스러운 패턴으로 만드는 쿼리 중심 SDK, 요청을 막아서는 안 되는 작업을 위한 백그라운드 작업이 있습니다. 엔지니어링 단계는 여러분이 오르고, 인프라 단계는 플랫폼이 이미 올라 두었습니다.