본문 바로가기

전체 글

 (26)
헤더/쿠키 다이어트: 전송 바이트 줄여 TTFB 개선하기 TTFB는 왕복 지연, 서버 대기, 첫 바이트 송신까지의 합입니다. 같은 인프라에서도 TTFB가 길게 느껴진다면 요청과 응답의 메타데이터가 실제 콘텐츠보다 무겁기 때문인 경우가 많습니다. 헤더와 쿠키를 정리하면 코드 대수술 없이도 효과가 잘 나타납니다. 아래는 이전 구조를 유지하면서 한 단계 더 깊게 확장한 가이드입니다.1) 왜 헤더/쿠키가 TTFB를 늘리나요청이 크면 첫 패킷 하나에 담기지 못해 분할되고, 손실·재전송 시 지연이 기하급수적으로 커집니다. TLS 핸드셰이크 직후의 초기 혼잡 윈도우에선 작은 바이트 차이가 곧바로 추가 왕복으로 이어질 수 있습니다. 서버 입장에서도 큰 헤더는 파싱·검증·정규식 매칭 경로를 길게 만들고, 보안 모듈이 검사해야 할 표면을 늘립니다. 특히 모든 API 호출에 긴 ..
서비스 메시(Envoy, Istio) 도입 시 레이턴시 오버헤드 관리 서비스 메시가 주는 가치는 분명하지만, 사이드카 프록시를 추가로 경유하는 구조 덕분에 작은 지연이 체인 길이만큼 누적됩니다. 아래는 앞서의 소제목을 유지하면서 한 단계 더 깊게 확장한 운영 가이드입니다. 목표는 측정 가능한 오버헤드 축소와, 배포 후 p95·p99 안정화입니다.1) 오버헤드의 정체: 어디서 지연이 생기나사이드카 경유로 생기는 추가 hop, TLS 종료·재암호화의 CPU 비용, 필터 체인 평가, 통계 집계, xDS 동기화 지연이 주범입니다. 특히 호출 그래프가 길수록 미세 지연이 곱셈처럼 커집니다. 애플리케이션과 사이드카 사이의 로컬 통신도 컨텍스트 스위치와 버퍼링을 동반하므로, 작은 페이로드의 초고빈도 호출일수록 체감이 큽니다. 첫 단계는 서비스별 호출 깊이와 요청 크기 분포를 뽑아, 어..
블루-그린/카나리 배포 시 성능 리스크와 관찰 포인트 배포 방식이 달라지면 같은 코드라도 시간대와 경계 장비, 데이터 상태에 따라 체감 속도가 크게 달라집니다. 아래 글은 앞서 제시한 소제목을 유지하면서 각 항목을 더 깊게 풀어쓴 확장판입니다. 현장에서 바로 쓸 수 있도록 수치 가드레일, 체크리스트, 운영 예시를 덧붙였습니다.1) 공통 성능 리스크 요약콜드스타트와 워밍업런타임이 올라오고 2~5분은 JIT, 캐시, 커넥션 풀이 비어 있습니다. 워밍업 트래픽을 미리 주입해 L3 캐시 히트율과 커넥션 풀 점유를 안정화시키면 p95가 10~30퍼센트까지 내려가는 사례가 많습니다. 워밍업은 읽기 전용 엔드포인트, 캐시 미스 경로, 템플릿 렌더, 모델 로드 같은 무거운 코드 경로를 우선으로 잡습니다.커넥션 드레인 미흡드레인 시간이 keep-alive보다 짧으면 진행 ..
로드밸런서 선택: L4(NLB) vs L7(ALB) 트래픽 특성별 가이드 같은 로드밸런싱이라도 트래픽의 성격, 보안 요구, 비용 구조, 운영 방식에 따라 최적 해법이 달라집니다. 아래는 기존 소제목을 그대로 유지하면서 내용을 더 촘촘히 풀어쓴 확장판입니다. 실무에서 바로 비교·적용할 수 있도록 결정 기준과 체크 포인트를 함께 제시합니다.1) 한눈에 보는 정의와 쓰임새L4(NLB)는 전송 계층의 IP·포트·프로토콜 정보만 보고 분산합니다. 패킷을 최대한 빨리 전달하는 게 목표이므로 지연과 처리량에 강하고, 대규모 연결을 저비용으로 소화하기 좋습니다. 반면 L7(ALB)은 HTTP/HTTPS/gRPC 같은 애플리케이션 계층을 이해해 호스트, 경로, 헤더, 쿠키를 기준으로 세밀하게 라우팅합니다. 실험 트래픽 분리, 멀티 테넌트, 언어·버전 분기, 인증·WAF 같은 정책을 한곳에서 ..
NGINX/Envoy/HAProxy 역프록시 튜닝: 워커/버퍼/큐 최적값 대규모 트래픽에서 체감 성능은 애플리케이션보다 역프록시 레이어가 먼저 한계에 닿습니다. 워커 병렬도, 버퍼 크기, 큐 운영 정책이 조금만 어긋나도 p95 지연과 에러율이 튑니다. 아래 글은 같은 소제목을 유지하며, 운영에서 바로 적용할 수 있도록 한 단계 더 자세히 풀어쓴 확장판입니다. 굵은 글씨나 장식은 빼고 필요한 내용만 담았습니다.1) 워커: CPU에 맞춘 병렬도와 수락 정책워커 수는 물리 코어 수를 기준으로 시작하고, 코어가 많을수록 워커 하나에 과도한 연결을 싣지 않도록 worker_connections, maxconn을 함께 보정합니다. 재시도 폭주나 스파이크 상황에서는 한 워커가 너무 많은 accept를 수행하면 컨텍스트 스위치가 늘어납니다. NGINX의 multi_accept는 과도한 일괄..
TCP 핸드셰이크·Time-Wait·포트 고갈: 서버 커널 파라미터 튜닝 대규모 동시 접속에서 “느림”은 코드보다 커널 네트워킹 경계에서 먼저 옵니다. TCP 핸드셰이크, Time-Wait 폭증, 임시 포트 고갈은 FD·메모리·큐를 잡아먹고 p95/p99 지연과 타임아웃을 끌어올립니다. 아래는 앞서 정리한 내용을 같은 소제목 그대로 더 깊게 풀어쓴 확장판입니다. 현장에서 바로 적용할 수 있는 값, 절차, 함정을 함께 담았습니다.1) TCP 핸드셰이크 비용 줄이기: SYN 큐와 백로그백로그 용량 산정: 피크 rps × 평균 핸드셰이크 시간(초) × 여유 1.5배.예) 피크 8k rps, 평균 12ms라면 8,000×0.012×1.5 ≈ 144 → tcp_max_syn_backlog/somaxconn은 4096 이상으로 시작.listen(backlog) 일치: 앱의 listen(..
QUIC 손실 회복과 패킷 암호화: 내부 동작을 이해해야 빠르다 QUIC 손실 회복과 패킷 암호화는 HTTP/3의 체감 성능을 좌우합니다. “UDP라 빠르다”가 아니라, 손실을 어떻게 감지·해석하고 언제 무엇을 다시 보낼지, 그리고 키를 어떻게 파생·회전하는지가 속도를 가릅니다. 아래는 운영·개발 현장에서 바로 써먹을 수 있도록 기존 소제목을 유지해 더 촘촘히 풀어쓴 가이드입니다.1) QUIC가 빠른 진짜 이유TCP는 커널 레벨 고정 로직과 연결 단위 HOL(헤드 오브 라인) 블로킹 탓에 한 패킷의 손실이 전체 스트림을 멈춥니다. QUIC은 사용자 공간에서 동작하고, 스트림 단위 재전송으로 손실의 영향을 해당 스트림에 국소화합니다. 또한 TLS 1.3과 핸드셰이크를 통합해 0-RTT/1-RTT에 연결을 올려, 초기 지연부터 줄입니다. 즉, 구조 자체가 “빠름”을 위한..
Congestion Control(BBR/CUBIC): 고손실 네트워크 성능 끌어올리기 고손실 구간에서 전송 속도가 무너지는 가장 큰 이유는 혼잡제어(Congestion Control) 가 손실을 곧바로 혼잡 신호로 해석하고, 과격하게 전송률을 낮추기 때문입니다. 특히 모바일·와이파이·위성처럼 손실과 지터가 섞이는 환경에서는 전통 알고리즘이 대역폭을 제대로 활용하지 못하죠. 여기서는 CUBIC과 BBR을 비교하고, 고손실 네트워크에서 체감 성능을 실제로 끌어올리는 실전 팁을 더 깊게 정리합니다.1) 혼잡제어의 기본: 대역폭·RTT·손실의 삼각관계혼잡제어는 송신 윈도우(cwnd)와 전송 속도를 조절해 사용 가능한 대역폭을 최대한 쓰되 지연과 손실을 최소화하는 기술입니다. 핵심은 세 가지 신호의 균형입니다.대역폭(Throughput): 병목 링크가 허용하는 최고 속도. 한계치를 넘으면 큐가 쌓..

티스토리툴바