대규모 트래픽을 위한 웹사이트 확장 방법

웹사이트가 부하를 견디지 못하는 이유

캠페인 출시, 깜짝 세일, 혹은 갑작스러운 화제몰이 도중에 사이트가 기어가듯 느려지는 원인은 거의 언제나 단 하나의 포화된 리소스입니다. CPU가 100%로 고정되어 있거나, 데이터베이스에 열린 연결이 너무 많거나, 압축되지 않은 이미지를 제공하느라 네트워크 회선이 한계에 도달한 경우입니다. 확장(scaling)이란 그 병목을 찾아 제거하고, 다음 병목을 위한 여유 용량(headroom)을 확보하는 일련의 작업입니다.

이 가이드는 대규모 트래픽을 감당하기 위한 웹사이트 확장의 실용적인 계층들을, 여러분이 다뤄야 할 순서대로 살펴봅니다. 여기서 다루는 기법은 플랫폼에 종속되지 않지만, 모든 명령어와 설정은 오늘 당장 Skyline Cloud VPS 또는 클라우드 서버에서 실행할 수 있는 것들이며, 여러분의 데이터는 사우디아라비아 왕국 내에 상주하고 PDPL/NCA 규정 준수도 대신 처리됩니다.

1단계: 확장하기 전에 먼저 측정하라

맹목적으로 최적화하지 마십시오. 기준선(baseline)을 세워 "충분히 빠르다"가 무엇을 의미하는지, 그리고 시간이 어디에서 소요되는지 파악하십시오.

별도의 머신에서 k6를 사용해 부하 테스트를 실행하십시오.

# install on Ubuntu/Debian
sudo apt-get install -y gnupg ca-certificates
curl -s https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update && sudo apt-get install -y k6

// load.js — ramp to 200 virtual users over 3 minutes
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 50 },
    { duration: '1m', target: 200 },
    { duration: '1m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://example.com/');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

k6 run load.js로 실행하면서 http_req_duration과 오류율을 지켜보십시오. 서버에서는 htop, iostat -x 2, 그리고 데이터베이스의 슬로우 쿼리 로그를 열어 두십시오. 가장 먼저 포화되는 리소스가 여러분의 병목입니다 — 추측이 아니라 바로 그 리소스를 해결하십시오.

2단계: 공격적으로 캐싱하라 — 가장 효율이 높은 승리

읽기 위주의 사이트 대부분은 애플리케이션이나 데이터베이스를 전혀 건드리지 않고도 요청의 상당수를 처리할 수 있습니다.

페이지 및 객체 캐싱. WordPress에서는 Redis로 뒷받침되는 객체 캐시가 반복되는 데이터베이스 쿼리를 없애 줍니다. Redis와 Redis Object Cache 플러그인을 설치하십시오.

sudo apt-get install -y redis-server php-redis
sudo systemctl enable --now redis-server

wp-config.php에 다음을 추가하십시오.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );

앱 가장자리에서의 HTTP 캐싱. Cache-Control 헤더를 설정해 브라우저와 하위 캐시가 응답을 재사용할 수 있도록 하십시오. Nginx에서는 정적 자산을 강력하게 캐싱하고 HTML은 재검증(revalidate)하도록 설정합니다.

location ~* \.(jpg|jpeg|png|webp|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

올바르게 구성된 캐시 계층은 일상적으로 원본(origin) 부하를 70~90%까지 줄여 줍니다. 더 큰 서버를 사기 전에 이것부터 하십시오.

3단계: 이미 가진 것을 튜닝하라 (수직 확장, scale up)

수직 확장 — 더 많은 CPU, RAM, 더 빠른 NVMe 디스크 — 은 가장 단순한 조치이며 흔히 올바른 첫걸음입니다. Skyline Cloud에서는 몇 분 만에 VPS 사양을 조정할 수 있습니다. 하지만 소프트웨어 자체도 함께 튜닝하십시오.

• PHP-FPM: pm.max_children를 (PHP에 할당 가능한 RAM) / (평균 프로세스 크기)로 산정하십시오. 프로세스 크기는 ps --no-headers -o "rss" -C php-fpm8.2 | awk '{s+=$1} END {print s/NR/1024" MB"}'로 확인할 수 있습니다.
• MySQL/MariaDB: 전용 데이터베이스 호스트에서는 innodb_buffer_pool_size를 RAM의 약 60~70%로 설정해 워킹 세트가 메모리에 상주하도록 하십시오.
• 연결(Connections): 커넥션 풀러를 추가하십시오. PostgreSQL에는 pgbouncer를 사용하고, MySQL에는 영속 연결을 짧고 상한이 정해진 상태로 유지하십시오.

4단계: 로드 밸런서로 확장하라 (수평 확장, horizontal scaling)

단일 서버에는 한계가 있습니다. 더 나아가려면 동일한 애플리케이션 서버 여러 대를 로드 밸런서 뒤에 두고 운영하십시오. 이렇게 하면 복원력도 향상됩니다. 한 노드가 죽더라도 트래픽이 나머지로 옮겨 가기 때문입니다.

최소한의 Nginx 로드 밸런서 설정은 다음과 같습니다.

upstream app_backend {
    least_conn;
    server 10.10.0.11:80 max_fails=3 fail_timeout=10s;
    server 10.10.0.12:80 max_fails=3 fail_timeout=10s;
    server 10.10.0.13:80 max_fails=3 fail_timeout=10s;
}

server {
    listen 443 ssl;
    server_name example.com;
    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

이것이 동작하려면 앱이 무상태(stateless) 여야 합니다. 세션을 로컬 디스크가 아니라 Redis나 데이터베이스에 저장하고, 사용자 업로드 파일도 단일 서버의 파일 시스템이 아니라 공유 객체 스토리지에 보관하십시오. 일단 요청이 어느 노드에든 안전하게 도달할 수 있게 되면, 노드를 자유롭게 추가하거나 제거할 수 있습니다.

5단계: 데이터베이스를 확장하라 (대개 실제 병목)

애플리케이션 서버는 복제하기 쉽지만, 데이터베이스는 그렇지 않습니다. 다음 기법들을 순서대로 사용하십시오.

가장 느린 쿼리에 EXPLAIN을 실행하는 것부터 시작해 누락된 인덱스를 추가하십시오 — 거의 노력 없이 흔히 10배의 성능 향상을 가져옵니다. 그다음 읽기 복제본을 추가하십시오. SELECT 트래픽은 하나 이상의 복제본으로 보내고, INSERT/UPDATE/DELETE는 프라이머리(primary)로 보냅니다. 단일 프라이머리가 정말로 쓰기 부하를 감당하지 못할 때에만 샤딩에 손을 대십시오.

6단계: 앞단에 CDN을 두라

CDN은 정적 자산 — 그리고 점점 더 전체 페이지까지 — 을 사용자와 가까운 엣지 위치에 캐싱합니다. GCC 지역 사용자를 대상으로 한다면, 이미지와 CSS, JavaScript를 가까운 엣지에서 제공하면 지연 시간이 줄고 막대한 대역폭이 원본에서 분산됩니다. CDN을 원본에 연결한 다음, 동적이고 개인화된 경로(장바구니, 결제, 계정)는 캐싱하지 않거나 사용자별로 캐싱하십시오.

7단계: 오토스케일링으로 자동화하라

마지막 계층은 확장을 자동화하는 것입니다. 예를 들어 평균 CPU가 5분 동안 65%를 넘으면 애플리케이션 노드를 추가하고, 부하가 떨어지면 제거하는 스케일링 그룹을 정의하십시오. 여기에 로드 밸런서의 헬스 체크를 결합해, 비정상 노드가 자동으로 로테이션에서 제외되도록 하십시오. 이렇게 하면 트래픽 급증 시에는 빠르게, 한산한 시간에는 군더더기 없이 운영할 수 있습니다 — 이것이 클라우드의 핵심적인 경제적 이점입니다.

합리적인 확장 순서

1. 측정하고 실제 병목을 찾는다.
2. 캐싱한다 (객체, HTTP, CDN).
3. 수직 확장하고 소프트웨어를 튜닝한다.
4. 로드 밸런서 뒤에서 앱 계층을 수평 확장한다.
5. 인덱스, 복제본, 그다음 샤딩 순으로 데이터베이스를 확장한다.
6. 오토스케일링으로 자동화한다.

각 단계는 여유 용량을 사 줍니다. 캐싱 없이 4단계로 곧장 건너뛰면, 더 크고 비싼 클러스터가 피할 수 있었던 일을 하게 만들 뿐입니다.

Skyline Cloud에서 실행하기

위의 모든 내용은 표준 Linux에서 동작하므로 완전히 이식 가능합니다. Skyline Cloud가 더해 주는 차별점은 현지성입니다. 여러분의 데이터는 PDPL, NCA, SDAIA 규정 준수를 위해 사우디아라비아 내에 상주하며, 아랍어 지원을 받을 수 있고, VPS 인스턴스를 사양 조정하거나 로드 밸런싱된 노드를 필요에 따라 추가할 수 있습니다. 클라우드 호스팅 페이지에서 플랫폼을 살펴보고, 사우디아라비아 클라우드 호스팅 허브에서 더 많은 가이드를 둘러보십시오. 그리고 같은 도메인에 안정적인 비즈니스 이메일 호스팅이 필요하다면, 그 부분도 저희가 함께 다룹니다.

가장 바쁜 날에도 땀 한 방울 흘리지 않고 견뎌 내는 무언가를 만들 준비가 되셨나요? Skyline Cloud 계정을 만들고 몇 분 안에 확장 가능한 첫 서버를 띄워 보십시오.