해커뉴스 메인에 등록되고나서 기록

상태: 관측된 L1(1선) 피크 기준선
사건: Hacker News 메인 페이지 노출
관측 화면 캡처일: 2026-07-29 (KST)

이번에 실제 공개 트래픽에서 관측한 운영 기준으로 적어두려고 한다.
아마 내 홈페이지 특성상 주로 프로그래밍 관련 글이다 보니, 유입자가 적은 편이며, 평소 일일 유입자는 약 600~900명이며, 2026년 6월의 일평균은 약 637명이었다.

앞으로 “현재까지 관측된 Hacker News 메인 노출 기준 최대 유입”을 현재 서비스의 L1 피크로 취급 하려고 한다.

당시 배포 경계

Text

Browser
  -> Cloudflare (DNS, WAF, edge cache)
  -> Vercel / Next.js (공개 Web과 Web BFF)
  -> Cloudflare api.makonea.com
  -> 4 GB Lightsail (Nginx, BFF, content/assets/RAG, PostgreSQL)

Cloudflare의 zone 전체 수치에는 Vercel이 처리한 Web 요청, RSC와 prefetch처럼 의도적으로 우회된 요청, api.makonea.com 요청이 함께 포함될 수 있다고 생각된다.

따라서 Cloudflare의 “캐시되지 않음”을 전부 Lightsail 원본 요청으로 간주하지 않아야 한다고 생각해야할 것이라 생각된다.

관측값

지표	관측값	출처 및 집계 단위	해석
총 고유 방문자 추정치	21.48k	Cloudflare, 화면상 `이전 24시간`	실제 사람 수나 세션 수와 동일하지 않은 Cloudflare 집계값
총 요청	444.46k	Cloudflare, 화면상 `이전 24시간`	Zone 전체 요청 수
캐시된 요청	233.95k	Cloudflare, 화면상 `이전 24시간`	Cloudflare 캐시에서 처리된 요청
캐시되지 않은 요청	210.51k	Cloudflare, 화면상 `이전 24시간`	원본으로 전달된 요청이나, 원본이 반드시 Lightsail인 것은 아님
총 대역폭	13.04 GB	Cloudflare, 화면상 `이전 24시간`	Cloudflare를 통과한 전체 전송량
캐시된 대역폭	10.04 GB	Cloudflare, 화면상 `이전 24시간`	캐시 응답으로 처리된 전송량
캐시되지 않은 대역폭	2.99 GB	Cloudflare, 화면상 `이전 24시간`	원본 응답으로 처리된 전송량
Lightsail CPU 최고 평균	17.57%	2026-07-29 06:40 KST, 10분 평균	4GB Lightsail 인스턴스의 관측 최고 평균값
Lightsail CPU 버스트 잔량	100%	Lightsail 1일 그래프	관측 해상도에서 유의미한 burst capacity 감소 없음

지표: 총 고유 방문자 추정치
관측값: 21.48k
출처 및 집계 단위: Cloudflare, 화면상 이전 24시간
해석: 실제 사람 수나 세션 수와 동일하지 않은 Cloudflare 집계값

지표: 총 요청
관측값: 444.46k
출처 및 집계 단위: Cloudflare, 화면상 이전 24시간
해석: Zone 전체 요청 수

지표: 캐시된 요청
관측값: 233.95k
출처 및 집계 단위: Cloudflare, 화면상 이전 24시간
해석: Cloudflare 캐시에서 처리된 요청

지표: 캐시되지 않은 요청
관측값: 210.51k
출처 및 집계 단위: Cloudflare, 화면상 이전 24시간
해석: 원본으로 전달된 요청이나, 원본이 반드시 Lightsail인 것은 아님

지표: 총 대역폭
관측값: 13.04 GB
출처 및 집계 단위: Cloudflare, 화면상 이전 24시간
해석: Cloudflare를 통과한 전체 전송량

지표: 캐시된 대역폭
관측값: 10.04 GB
출처 및 집계 단위: Cloudflare, 화면상 이전 24시간
해석: 캐시 응답으로 처리된 전송량

지표: 캐시되지 않은 대역폭
관측값: 2.99 GB
출처 및 집계 단위: Cloudflare, 화면상 이전 24시간
해석: 원본 응답으로 처리된 전송량

지표: Lightsail CPU 최고 평균
관측값: 17.57%
출처 및 집계 단위: 2026-07-29 06:40 KST, 10분 평균
해석: 4GB Lightsail 인스턴스의 관측 최고 평균값

지표: Lightsail CPU 버스트 잔량
관측값: 100%
출처 및 집계 단위: Lightsail 1일 그래프
해석: 관측 해상도에서 유의미한 burst capacity 감소 없음

참고용 UI 표시값

아래 값은 화면의 선택 범위와 표시 단위가 일치하지 않아 용량 계산에는 사용하지 않는다.

지표	화면 표시값	문제점
최대 고유 방문자 버킷	17.42k	선택 범위는 `이전 24시간`이나 단위는 `1주당`으로 표시됨
최소 고유 방문자 버킷	690	선택 범위는 `이전 24시간`이나 단위는 `1주당`으로 표시됨

지표: 최대 고유 방문자 버킷
화면 표시값: 17.42k
문제점: 선택 범위는 이전 24시간이나 단위는 1주당으로 표시됨

지표: 최소 고유 방문자 버킷
화면 표시값: 690
문제점: 선택 범위는 이전 24시간이나 단위는 1주당으로 표시됨

Cloudflare 화면의 선택 범위는 이전 24시간이지만, 고유 방문자 그래프의 최대·최소 값은 1주당 단위로 표시되어 있다. 따라서 17.42k와 690은 시간당 방문자, 순간 동시 접속자 또는 명확한 24시간 내 집계 버킷으로 해석하지 않아야 되는걸로 보인다.
두 값은 화면 캡처 당시의 참고용 UI 표시값으로만 보존하며, 용량 판단과 파생 지표 계산에서는 제외한다.

지표	관측값	출처 및 단위
최대 요청 집계 버킷	9.39k requests	2026-07-28 23:30, 화면상 집계 버킷
순간 peak RPS	`Unknown`	1분 이하 해상도 자료 없음

지표: 최대 요청 집계 버킷
관측값: 9.39k requests
출처 및 단위: 2026-07-28 23:30, 화면상 집계 버킷

지표: 순간 peak RPS
관측값: Unknown
출처 및 단위: 1분 이하 해상도 자료 없음

Cloudflare 화면의 선택기는 이전 24시간이지만 고유 방문자 그래프의 가로축과 최대/최소 단위는 1주당으로 표시되어 있다.

최대 요청 버킷 화면의 총 요청은 132.15k로, Zone 전체 화면의 444.46k와 일치하지 않는다. hostname, 필터, 봇 포함 여부, 분석 제품 또는 조회 구간의 차이가 있을 수 있으므로 두 값을 같은 모집단으로 직접 결합하지 않아야 할 것 같다.

이 불일치 때문에 17.42k를 시간당 방문자나 순간 동시 접속자로 재해석하지 않지만, 정확한 피크 RPS와 동시 접속자 수는 이 자료만으로는 알 수 없었다.

파생 지표

지표	계산값	해석
요청 기준 캐시율	약 52.64%	233.95k / 444.46k
요청 기준 미캐시율	약 47.36%	210.51k / 444.46k
대역폭 기준 캐시율	약 76.99%	10.04 GB / 13.04 GB
대역폭 기준 미캐시율	약 22.93%	2.99 GB / 13.04 GB, 반올림 오차 존재
방문자당 요청	약 20.69회	444.46k / 21.48k
24시간 평균 요청률	약 5.14 req/s	피크 RPS가 아닌 기간 평균
24시간 평균 미캐시 요청률	약 2.44 req/s	원본 RPS와 동일하지 않음

지표: 요청 기준 캐시율
계산값: 약 52.64%
해석: 233.95k / 444.46k

지표: 요청 기준 미캐시율
계산값: 약 47.36%
해석: 210.51k / 444.46k

지표: 대역폭 기준 캐시율
계산값: 약 76.99%
해석: 10.04 GB / 13.04 GB

지표: 대역폭 기준 미캐시율
계산값: 약 22.93%
해석: 2.99 GB / 13.04 GB, 반올림 오차 존재

지표: 방문자당 요청
계산값: 약 20.69회
해석: 444.46k / 21.48k

지표: 24시간 평균 요청률
계산값: 약 5.14 req/s
해석: 피크 RPS가 아닌 기간 평균

지표: 24시간 평균 미캐시 요청률
계산값: 약 2.44 req/s
해석: 원본 RPS와 동일하지 않음

정적 자산처럼 바이트가 큰 응답은 대체로 edge가 흡수했다. 요청 수 기준 캐시율이 대역폭 기준보다 낮은 것은 RSC, prefetch, API, 인증/관리 경계처럼 작지만 의도적으로 캐시하지 않는 요청이 섞였을 가능성과 일치하는걸로 보인다.

정확한 원인은 hostname, path, cache status, content type별 분석 전에는 Unknown으로 보인다.

용량 판정에 대해서

결론

현재 구성은 이 L1 피크와 같은 규모의 단기 유입을 버틴 것으로 판정한다.

이번 사건에서 관측 가능한 Cloudflare edge 전송 계층과 Lightsail CPU 계층은 L1-HN 유입을 처리하는 동안 명시적인 포화 징후를 보이지 않았다.

근거:

10분 평균 CPU 최고점 17.57%로 Lightsail의 20% 지속 가능 영역 안에 남았다.
CPU 버스트 잔량이 100%로 유지되어 단기 CPU 비상 여력을 소비하지 않았다.
전체 전송량의 약 77%를 Cloudflare cache가 처리했다.
이 관측 자료에는 CPU 포화나 burst credit 고갈 신호가 없다.

단, 최악 CPU 지점은 지속 가능선보다 2.43%p 낮다.
따라서 이 결과는 동일 규모의 유입에서 Cloudflare edge와 Lightsail CPU 계층에 명시적인 포화 징후가 없었다는 근거다. 다만 종단 간 서비스 품질과 반복 처리 가능성은 오류율·지연 시간·메모리·DB 지표를 추가로 확인해야 한다. 트래픽이 2배로 늘어도 장시간 같은 상태를 유지한다는 근거는 아닌지만,
2배 수준이 지속되면 burst 영역 진입 가능성이 있으므로 별도 부하 시험이나 다음 실트래픽 증거가 필요하다.

이건 아마 해커뉴스 프론트 페이지에 하루종일 있어야 가능한데, 현재로써는 약 6시간 정도 노출된 것으로 체크된다.

다음 피크에서 반드시 함께 수집할 지표

현재로는 아래와 같은 지표가 없었다.

Cloudflare/Vercel/Lightsail별 4xx·5xx 비율
공개 HTML과 API의 p50·p95·p99 응답 시간
Lightsail 메모리, swap, 디스크 I/O와 container restart/OOM 횟수
PostgreSQL connection pool 대기와 slow query
hostname/path/cache status/content type별 미캐시 요청 분포
1분 또는 그보다 짧은 구간의 peak RPS와 동시 요청 수

다음 Hacker News급 유입에서는 최소한 다음 조건을 같이 만족해야 L1 피크를 다시 정상 통과한 것으로 관측해야할 것이다.

상태	판정 기준
정상	핵심 경로 5xx < 0.5%, API p95 < 1초, OOM/restart 없음, CPU가 대부분 기준선 이하, burst 잔량 안정
주의	CPU 기준선 초과가 15분 이상 지속하면서 burst 잔량 감소, API p95 > 1초, DB pool wait 또는 slow query 증가
위험	5xx ≥ 1%, CPU 기준선 초과와 burst 급감이 함께 발생, DB timeout·OOM·container restart 발생

상태: 정상
판정 기준: 핵심 경로 5xx < 0.5%, API p95 < 1초, OOM/restart 없음, CPU가 대부분 기준선 이하, burst 잔량 안정

상태: 주의
판정 기준: CPU 기준선 초과가 15분 이상 지속하면서 burst 잔량 감소, API p95 > 1초, DB pool wait 또는 slow query 증가

상태: 위험
판정 기준: 5xx ≥ 1%, CPU 기준선 초과와 burst 급감이 함께 발생, DB timeout·OOM·container restart 발생

5xx와 latency 기준은 이번 화면에서 관측된 값이 아니라 다음 피크를 판단하기 위한 운영 경보다. 실제 데이터가 쌓이면 이 기준을 관측 분포에 맞춰 조정해야할듯 싶다.

결론

Hacker News 프론트 페이지 노출은 개인 사이트를 운영하면서 얻은 드문 실전 부하 사례였고, 솔직히 기분도 좋았다.

과거 AWS 청구 오류로 약 3천만 원 규모의 비정상 청구가 표시된 사건을 겪은 뒤, 비용을 예측하기 쉬운 Lightsail 중심 구성으로 이전했다. 2GB 인스턴스에서는 메모리와 운영 여유가 부족했지만, 현재 인스턴스에서는 이번 HN 유입 동안 CPU와 burst capacity에 뚜렷한 포화 신호가 없었다.

따라서 현재 관측 범위에서는 비용을 감수할 만한 운영 안정성을 확보한 것으로 판단한다. 다만 인스턴스 비용과 사양은 AWS 청구서 기준으로 다시 확인해야 하며, 다음 피크에서는 CPU뿐 아니라 오류율·지연 시간·메모리·PostgreSQL 지표도 함께 수집할 예정이다.

인프라 운영 부하 경험은 쉽게 얻을 수 없는 경험이었고 이렇게 경험을 남긴다.