본문 바로가기

전체 글

 (26)
캐시 스탬피드 방지: 요청 합치기·서킷브레이커·확률적 만료 트래픽 피크 때 캐시가 동시에 만료되면, 수많은 요청이 한꺼번에 오리진으로 몰리는 캐시 스탬피드(cache stampede) 가 발생합니다. 결과는 간단합니다. QPS 폭증 → 지연 증가 → 오류율 상승 → 연쇄 장애. 이 글은 운영자가 즉시 적용할 수 있는 세 가지 축, 요청 합치기(request coalescing)·서킷브레이커·확률적 만료(early/soft TTL) 를 중심으로 실전 설계·운영 체크리스트를 제공합니다.1) 왜 캐시 스탬피드가 생기나동시 만료: 동일 키가 같은 시각에 만료되면, 미스 난 모든 워커가 동시에 오리진 조회를 시작.비싼 생성 비용: DB 조인·외부 API 호출·이미지 변환처럼 고비용 연산이 꼬리에 꼬리를 무는 구조.락 부재/부적절한 TTL: 락 없이 “먼저 오는 요청부터 ..
Multi-CDN 설계 체크리스트: 장애 회피와 비용 최적화 단일 CDN만으로는 글로벌 품질·장애·비용을 모두 잡기 어렵습니다. Multi-CDN은 서로 다른 네트워크 강점을 묶어 장애 회피(가용성) 와 비용 최적화(egress 단가·정책) 를 동시에 달성하는 전략이에요. 아래 체크리스트만 따라도 안전하게 시작할 수 있습니다.1) 목표 정의: 무엇을 최적화할 것인가가용성 우선: 특정 지역/통신사 장애를 자동 우회성능 우선: 국가·ISP별 최저 레이턴시 CDN으로 라우팅비용 우선: 시간대·볼륨에 따라 가중 분산으로 egress 단가 최소화혼합 지표: p95 TTFB, 오류율, egress 비용(GB당), 캐시 히트율을 공통 KPI로 고정2) 트래픽 스티어링 레이어 선택DNS 기반(Geo/Latency/가중치): 가장 보편적, 관리가 쉬움. TTL 60~300초 권장..
CDN 이미지 최적화: AVIF/WEBP, 리사이즈, DPR 대응 전략 웹 성능의 절반은 이미지가 좌우합니다. CDN 이미지 최적화는 포맷(AVIF/WEBP) 전환, 리사이즈/크롭, DPR(디스플레이 배율) 대응을 묶어 바이트를 줄이고 LCP를 당기는 기술 패키지예요. 이 글은 운영자가 바로 적용할 수 있는 설계 원칙·캐시 전략·모니터링까지 한 번에 정리합니다.1) 포맷 전략: AVIF/WEBP 자동 협상기본 원칙: 브라우저의 Accept 헤더 기반 자동 포맷 협상 → 가능하면 AVIF, 다음은 WebP, 마지막은 원본 JPEG/PNG.장단점 핵심AVIF: 압축 효율 최고, 텍스처·그라데이션 우수. 인코딩 비용 높음(서버/에지에서 캐시로 상쇄).WebP: 폭넓은 호환성·인코딩 속도 우수. 텍스처 복잡한 사진은 AVIF가 더 작게 나오는 편.PNG/JPEG: 레거시 폴백. 투..
CDN 캐시키 설계: 쿠키/쿼리스트링/디바이스별 분기 베스트프랙티스 CDN 성능은 “얼마나 잘 캐시하느냐”에서 갈립니다. 그리고 캐시의 성패는 캐시키(Cache Key) 설계가 80%를 좌우해요. 같은 리소스인데 쿠키, 쿼리스트링, 디바이스 구분 때문에 키가 쓸데없이 달라지면 히트가 쪼개지고 비용만 늘어납니다. 오늘은 운영자 입장에서 안전하게 히트를 키우는 설계법을 정리해드릴게요.1) 캐시키의 기본 원리: “동일한 건 동일하게”캐시키는 CDN이 “이 요청은 어떤 오브젝트와 같냐”를 판단하는 기준입니다.기본 구성 요소는 보통 스킴(https), 호스트, 경로, 쿼리스트링, 헤더, 쿠키, 디바이스 시그널이에요.원칙은 간단합니다.동일 콘텐츠는 동일 키 → 캐시 적중률↑, 오리진 부하↓컨텍스트가 달라 콘텐츠가 달라지면 그때만 키를 다르게즉, 최소 키(minimal key) 철학..
Anycast DNS와 지리 기반 라우팅: 전세계 응답속도 낮추는 법 글로벌 서비스의 첫 체감 속도는 DNS 응답 지연과 사용자→엣지까지의 라우팅 품질이 좌우합니다. 이 글은 Anycast DNS로 권위 네임서버 응답을 가깝게 만들고, 지리 기반(Geo)·지연 기반(Latency) 라우팅으로 사용자를 최적 엣지로 보내는 방법을 실무 관점에서 정리했습니다.1) Anycast DNS란? 왜 빠른가개념: 전 세계 여러 지점에서 동일한 IP(권위 DNS IP) 를 BGP로 광고합니다. 사용자는 가장 가까운 라우팅 경로로 연결되어 DNS 응답이 짧아집니다.효과DNS 왕복(RTT) 단축 → TTFB·LCP 개선의 선행 조건리전 장애 시 가까운 다른 PoP로 자동 우회(BGP 수렴)대규모 DDoS 분산 흡수(트래픽이 여러 PoP로 퍼짐)팁: 리졸버(8.8.8.8 등)도 Anycast를..
DNS 튜닝 가이드: TTL, CNAME 체인, 프리패치 최적화 페이지가 느린 이유, 서버만 탓할 순 없습니다. DNS 조회(이름 해석) 는 첫 바이트 이전에 반드시 거치는 단계라 미세한 최적화만으로도 TTFB·LCP가 눈에 띄게 개선됩니다. 이 글은 운영자가 바로 적용할 수 있는 TTL 설계, CNAME 체인 단축, 프리패치 전략을 실무 중심으로 정리합니다.1) TTL 설계: 오래 vs 짧게의 트레이드오프TTL(Time To Live) 은 레코드가 리졸버 캐시에 유지되는 시간입니다. 길면 쿼리 수가 줄고, 짧으면 변경이 빨라집니다. 핵심은 변경 가능성에 따라 차등 적용하는 것.정적 자원 도메인(static, img, cdn): 변경 드뭄 → A/AAAA/CNAME TTL 1~24시간 권장애플리케이션 메인 도메인(www, api): 롤백·장애 우려 → 60~300초(..
TLS 1.3과 0-RTT: 보안 유지하면서 핸드셰이크 단축하기 TLS 1.3은 “더 안전하면서 더 빠른” 웹을 목표로 설계됐습니다. 핵심은 핸드셰이크 왕복(RTT) 축소와 암호 스위트 단순화, 여기에 0-RTT(early data) 로 재방문 사용자의 체감 지연을 크게 줄이는 점이에요. 다만 0-RTT에는 재생 공격(replay) 같은 위험이 동반되므로, 안전한 범위를 정해 도입해야 합니다. 이 글은 TLS 1.3과 0-RTT를 구조적으로 이해하고, 운영에서 바로 쓰는 체크리스트까지 제공합니다.1) TLS 1.3 한눈에 보기: 왜 기본이 빨라졌나왕복 감소: TLS 1.2는 (대부분의 경우) 2-RTT가 필요했지만, TLS 1.3은 1-RTT로 암호화 채널을 완료합니다. 그만큼 TTFB가 줄어들고, 특히 모바일·해외 구간에서 이득이 큽니다.암호 스위트 단순화: 취약하..
HTTP/2 멀티플렉싱 vs HOL 블로킹: 체감 성능 차이는? HTTP/2로 바꾸면 항상 빨라질까요? 절반은 맞고 절반은 아닙니다. 멀티플렉싱 덕분에 요청을 한 연결로 동시 전송할 수 있지만, TCP 기반 특성 때문에 HOL(Head-of-Line) 블로킹이 생기면 체감 성능이 오히려 흔들릴 수 있어요. 이 글은 두 개념을 구조적으로 정리하고, 사이트에서 무엇을 점검해야 하는지 실천 팁까지 담았습니다.1) 멀티플렉싱: 단일 연결에서의 병렬 전송정의: HTTP/2는 하나의 TCP 연결 위에 여러 스트림을 얹어 CSS, JS, 이미지 등을 병렬로 전송합니다. HTTP/1.1 시절처럼 도메인 샤딩이나 요청 수를 억지로 분산하지 않아도 됩니다.장점 요약초기 연결·핸드셰이크 수를 줄여 지연 비용 절감중요 리소스를 먼저 보내는 우선순위 제어 가능HPACK 헤더 압축으로 중복 ..

티스토리툴바