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

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

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

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

당시 배포 경계

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 원본 요청으로 간주하지 않아야 한다고 생각해야할 것이라 생각된다.

관측값

참고용 UI 표시값

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

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

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

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

이 불일치 때문에 17.42k를 시간당 방문자나 순간 동시 접속자로 재해석하지 않지만, 정확한 피크 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와 latency 기준은 이번 화면에서 관측된 값이 아니라 다음 피크를 판단하기 위한 운영 경보다. 실제 데이터가 쌓이면 이 기준을 관측 분포에 맞춰 조정해야할듯 싶다.

결론

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

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

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

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