서론
진정한 테토 호소인 는 선크림도 바르지 않고, 걱정도 하지 않는다.
그치만 언니가 고민해 보라고 했으니 고민이라는 것을 해보겠다.
트래픽이 증가한다
트래픽은 서버의 데이터 전송량을 의미한다. 외부에서 해당 서버에 접속하는 사용자가 많아질수록 트래픽은 증가한다.
만약 서버가 감당할 수 있는 한계를 초과한 트래픽이 지속적으로 유입되면, 서버는 정상적으로 동작하지 못하고 결국 다운된다.
따라서 평소보다 트래픽이 10배 이상 급증한다면, 별도의 대비가 없는 서버는 분명히 다운된다.
Next.js에서 트래픽 증가
Next.js를 사용한다고 가정해보자.
Next.js는 싱글 스레드 기반의 자바스크립트 런타임인 Node.js 위에서 동작하며, 서버에서 리소스를 미리 렌더링한 뒤 브라우저에 전달하는 SSR(Server Side Rendering) 방식을 지원한다. Node.js는 I/O 작업에는 뛰어난 성능을 보이지만, CPU 중심 작업에서는 단일 스레드만 사용하기 때문에 적절한 구성 없이 많은 작업을 처리할 경우 성능 문제가 발생할 수 있다.
(1) 서버 병목현상
또한 싱글 스레드 환경에서는 병렬 처리가 제한되므로 작업을 순차적으로 처리하게 된다. 따라서 복잡한 페이지를 SSR하는 동안 서버는 다른 요청을 즉시 처리하지 못하고 대기 상태에 놓일 수 있다.
(2) 대규모 트래픽 처리 한계
소수의 요청만 처리할 때는 큰 문제가 없지만, 초당 수백 명 이상의 사용자가 동시에 접속하는 상황에서는 순차 처리로 인해 응답 시간이 증가하고 서버가 다운될 가능성도 존재한다. 결국 단일 스레드 기반 환경에서는 병목 현상과 블로킹 현상이 발생할 수 있으며, 과도한 서버 부하는 렌더링 성능 저하로 이어질 수 있다.
해결책
캐싱 전략을 사용하면, 서버가 동일한 데이터를 반복적으로 렌더링하지 않아도 되어 서버 부하를 줄일 수 있고, 응답 속도가 개선되어 대규모 트래픽 상황에서도 안정적인 서비스 운영이 가능해진다.
캐싱전략 : 자주 사용하는 데이터를 빠르게 접근할 수 있도록 저장해 성능을 최적화하는 전략
강제캐싱(force-cache)
우리가 fetch API로 캐싱을 수행할 때 별도의 옵션을 지정하지 않으면, 브라우저는 사용자가 이전에 동일한 요청을 보낸 적이 있는지 HTTP 캐시를 먼저 확인한다.
- HTTP 캐시에 최신 데이터가 있다면 : 서버 요청 없이 캐시 데이터를 즉시 반환
- HTTP 캐시에 오래된 데이터가 있다면 : 서버에서 데이터 변경 여부를 확인한 뒤 캐시를 사용하거나 갱신할 수 있는 조건부요청 발신
- 일치하는 캐시가 없다면 : 서버에 새 요청을 보내 응답 데이터를 캐시에 저장
하지만 이러한 과정에서는 캐시의 최신 여부를 검사하기 위한 추가 요청이 발생하므로 일정한 시간이 소요된다.
따라서, 강제캐싱 (force-cache) 을 사용한다면,
- 서버로부터 받은 응답 데이터를 캐시에 저장
- 최신화되었는지 여부를 판단하지 않고, 사용자 요청시 일치하는 데이터가 있다면 즉시 반환
하여 위 과정을 축소하고 서버로 보내는 요청 수를 줄여 서버 부하를 줄일 수 있다.
예시
// 강제캐싱을 헤더에 사용하는 경우
fetch('/api', { cache: 'no-store' })
// 강제캐싱을 응답에 사용하는 경우
fetch("some.json", { cache: "force-cache" }).then((response) => {
/* 상세 생략 */
});
Revalidation
강제 캐싱은 서버 요청 수를 줄여 성능을 향상시킬 수 있지만, 캐시된 데이터의 최신성을 보장하지는 않는다.
따라서 데이터 변동성이 높은 서비스에서는 일정 주기마다 캐시를 재검증하고 갱신하는 Revalidation 전략을 사용하여 이를 보완할 수 있다.
※ 재검증 과정에서 추가적인 서버 요청이 발생하므로 강제 캐싱에 비해 응답 속도가 조금 느려질 수 있다.
감안하여 사용하자.
예시
// 30초간 캐싱하고, 이후에는 새로운 요청보내기
fetch('/a', { next: { revalidate: 30 } })정리
| 항목 | 강제 캐싱 (force-cache) | Revalidation (revalidate) |
|---|---|---|
| 동작 방식 | 캐시 데이터를 우선적으로 사용 | 일정 시간이 지나면 캐시를 갱신 |
| 최신 데이터 확인 | 확인하지 않음 | 지정된 시간마다 재검증 |
| 서버 요청 | 캐시가 있으면 서버 요청 없이 반환 | 재검증 시 서버 요청 발생 |
| 성능 | 매우 빠름 | 상대적으로 약간 느림 |
| 서버 부하 | 매우 적음 | 주기적으로 발생 |
| 데이터 최신성 | 낮을 수 있음 | 일정 수준 유지 가능 |
| 사용 목적 | 성능 최적화 | 성능 + 최신성 균형 |
| 적합한 데이터 | 공지사항, 정적 콘텐츠 | 게시글, 뉴스, 랭킹 |
| Next.js 예시 | cache: 'force-cache' | next: { revalidate: 30 } |
| 특징 | 오래된 데이터도 즉시 반환 | 일정 주기로 새 데이터 반영 |
ISR(Incremental Static Regeneration)을 이용한 페이지 캐싱
웹 페이지를 미리 생성하는 렌더링 기법인 ISR(Incremental Static Regeneration)을 사용하면, 최초 요청 시 생성된 정적 페이지를 캐싱하여 빠르게 제공할 수 있다.
최초 렌더링 이후 변경되는 데이터는 필요한 시점에만 SSR(Server Side Rendering), CSR (Client Side Rendering) 등으로 다시 렌더링함으로써, 성능 최적화와 데이터 최신성을 모두 고려한 효율적인 렌더링이 가능하다.
예시
※ ISR을 대규모 서비스 환경에서 안정적으로 운영하기 위해서는 데이터 요청 처리 외에도 Redis와 같은 별도의 캐싱 서버를 구축하여 캐싱된 페이지 데이터를 중앙에서 관리하는 작업이 필요하다.
여러 개의 Node.js 서버 인스턴스가 각각 독립적으로 캐시를 생성하고 관리하는 구조에서 발생할 수 있는 캐시 불일치 문제를 해결해야하기 때문이다.
// 페이지 라우터
export const getStaticProps = async () => {
// 데이터 요청
const data = await fetch('/a')
.then((res) => res.json())
return {
// 컴포넌트에 전달할 props
props: { data },
// 30초마다 페이지 재생성(Revalidation)
revalidate: 30
}
}
function Page({ data }) {
// 캐싱된 정적 페이지 반환
return <div>{data.title}</div>
}
// 앱라우터
// → 해당 페이지를 30초 주기로 재생성
export const revalidate = 30
async function Page() {
// fetch 결과를 캐싱
const data = await fetch('/a')
.then((res) => res.json())
// 캐싱된 페이지 반환
return <div>{data.title}</div>
}
export default Page씨스터디 결론
💚🌼 msms804 🌼💚 : 트래픽이 갑자기 10배 늘어나면 가장 먼저 걱정할 것은 무엇인가요?
Profitah : 평소보다 예측하기 어려운 수준의 트래픽이 발생한 만큼, 가장 먼저 우려되는 것은 과도한 서버 부하와 이로 인한 서버 다운 가능성입니다.
사용자가 서비스 이용 중 불편을 겪으면 이탈로 이어지고, 이는 매출 감소로 직결될 수 있습니다.
따라서 빠른 장애 대응과 안정적인 서비스 복구를 최우선으로 문제 해결에 집중하겠습니다.
우선 이상 트래픽이 감지되는 즉시 웹페이지를 일시적으로 제어하고 서버 점검 안내를 선제적으로 제공하여 사용자 불편을 최소화하겠습니다. 이어서 서버 사양을 높이고 대수를 늘리는 방식으로 급증한 트래픽을 분산 처리할 수 있는 환경을 구축하겠습니다.
서버가 안정화된 뒤에는 서비스 특성에 맞는 렌더링 방식과 캐싱 전략을 적용해 서버 부하를 줄이고 응답 속도를 개선하겠습니다. 최신 데이터 반영이 중요한 게시판은 서버 사이드 렌더링(SSR)을 적용하고, 데이터 변경이 적은 정적 페이지는 재검증 기반 캐싱(ISR) 또는 정적 사이트 생성(SSG)과 브라우저 캐싱을 활용해 서버 부담을 분산하겠습니다.
참고문서
