전체 글 (26) 썸네일형 리스트형 HTTP Keep-Alive, TCP 재사용, 커넥션 풀: 대규모 동시성 튜닝 대규모 트래픽에서 가장 먼저 막히는 곳은 애플리케이션 로직이 아니라 연결입니다. 한 번 맺은 연결을 오래·안전하게 쓰고, 필요한 수만큼 효율적으로 돌리는 게 승부처예요. 아래에서는 기존 소제목을 유지하면서, 운영에서 바로 적용할 수 있는 디테일을 더해 자연스럽게 이어가겠습니다.1) 연결 비용을 줄이는 기본기: Keep-Alive와 프로토콜 선택Keep-Alive는 요청마다 TCP/TLS를 다시 맺는 왕복·CPU 낭비를 없애 줍니다. 포인트는 “몇 개를, 얼마나 오래” 유지하느냐예요.최대 동시 연결 수 산정식필요 연결 수 ≈ (초당 요청수 × 평균 처리시간) × 여유 계수(1.1~1.3)예) 5천 rps, 평균 80ms면 400개가 이론치이므로 440~520개로 시작합니다.유휴 시간 정렬상위 계층이 더 짧.. WebSocket vs SSE vs WebTransport: 실시간 전송 프로토콜 선택 같은 “실시간”이라도 트래픽 패턴, 순서 보장, 양방향성, 네트워크 품질에 따라 최적의 선택은 달라집니다. 아래 내용은 기존 소제목을 유지한 채, 각 프로토콜을 더 깊게 비교·확장한 실전 안내입니다. 목표는 간단합니다. 팀의 현재 인프라와 사용자 환경을 고려해 가장 빠르고 안정적인 경로를 고르는 것.1) 한 줄 정의와 핵심 차이WebSocket은 HTTP 핸드셰이크로 업그레이드한 뒤 전이중(Full-duplex) 채널을 엽니다. 텍스트/바이너리를 모두 다루며, 하나의 연결 안에서 메시지 프레이밍만 제공하므로 토픽 분리는 애플리케이션 레벨에서 수행합니다. 브라우저·네이티브·서버 모두 성숙한 라이브러리가 많아 생태계 완성도가 높습니다.SSE(Server-Sent Events) 는 순수 HTTP 연결을 장기 .. gRPC vs REST vs GraphQL: 지연/페이로드/모바일 효율 비교 gRPC vs REST vs GraphQL 는 같은 도메인 모델이라도 체감 성능·운영 난이도·모바일 배터리까지 전부 달라집니다. 이 글은 세 접근을 지연(latency), 페이로드(payload), 모바일 효율 관점에서 깊게 비교하고, 실무에서 바로 선택·조합할 수 있도록 정리합니다.1) 핵심 개념 한 줄 요약gRPC: HTTP/2 위 Protocol Buffers(바이너리) 를 사용한 RPC. 양방향 스트리밍, 멀티플렉싱, 작은 헤더로 저지연. 서버/서버, 네이티브 앱과 잘 맞습니다.REST: 리소스 중심의 HTTP 표준(GET/POST/PUT/DELETE) + JSON. CDN/브라우저 캐시·디버깅·호환성 최고. 공개 API의 기본값.GraphQL: 클라이언트가 필요한 필드만 선언적으로 요청. 엔드포.. 서킷 브레이커·리트라이·백오프·아이템포턴시: 네트워크 안정 패턴 대규모 트래픽과 불안정한 외부 의존성 속에서 서비스 신뢰성을 지키려면, 실패를 없애기보다 예측 가능한 방식으로 다룰 수 있어야 합니다. 네 가지 핵심 패턴 서킷 브레이커, 리트라이, 백오프, 아이템포턴시를 적절히 묶으면 에러율과 p95/p99 꼬리 지연을 동시에 낮추고, 사용자는 “멈추지 않는 서비스”를 체감하게 됩니다.1) 서킷 브레이커: “지금은 보내지 마”의존 대상(외부 API/DB/브로커)의 오류율이나 지연이 임계치를 넘으면, 호출을 잠시 차단(Open) 했다가 상태가 회복되면 부분 허용(Half-Open) 을 거쳐 정상(Closed) 으로 복귀시키는 장치입니다.실무에선 최근 10~30초 윈도우에서 오류율 5~10% 이상, 또는 p95 지연 급등을 기준으로 Open 하도록 잡습니다. 한 번 열리면.. API 게이트웨이 레이트리밋/버스트 제어: 공정성과 안정성 균형 트래픽이 몰리는 순간 게이트웨이는 마지막 안전망이 됩니다. 제한을 너무 빡빡하게 걸면 정상 사용자도 막히고, 너무 느슨하면 백엔드가 먼저 무너집니다. 그래서 레이트리밋은 공정성을 보장하면서도 안정성을 잃지 않는 선으로 설계해야 하고, 짧은 피크를 흡수하는 버스트 제어가 함께 작동해야 합니다.1) 왜 지금 레이트리밋과 버스트 제어인가클라우드 비용은 초 단위로 올라가고, 외부 연동 API는 예고 없이 느려집니다. 레이트리밋은 특정 사용자나 앱이 자원을 독점하지 못하게 하면서, 시스템 전체가 감당 가능한 속도로 요청을 흘려보내는 장치입니다. 여기에 버스트 제어를 더하면 짧은 트래픽 솟구침은 유연하게 받아들이고, 지속적인 과다 사용은 자연스럽게 제동을 겁니다. 결과적으로 정상 사용자는 매끄럽게 이용하고, 과부하.. Core Web Vitals 실전: LCP·CLS·INP를 인프라 관점에서 깎는 법 Core Web Vitals는 프론트 코드만 건드려서는 한계가 있습니다. 사용자가 화면을 보기까지는 DNS, TLS, 라우팅, 캐시, 이미지 파이프라인과 같은 인프라 단계가 겹겹이 쌓여 있고, 이 구간에서의 작은 개선이 LCP·CLS·INP 전체를 동시에 끌어내립니다. 아래 내용은 이미 운영 중인 서비스를 전제로, 설정 몇 가지와 서빙 전략만 바꿔도 숫자가 안정적으로 좋아지는 방법을 흐름대로 정리한 것입니다.1) LCP 낮추기: 네트워크와 리소스 배달 최적화LCP는 결국 “첫 화면의 큰 콘텐츠가 언제 보이느냐”의 문제이므로, TTFB를 줄이고 해당 리소스를 가장 먼저, 가장 가깝게 보내면 빨라집니다. 권위 DNS를 Anycast로 두고, 초기에 반드시 접근하는 외부 도메인에는 preconnect를 걸어 .. 프리커넥트·DNSprefetch·프리로드·우선순위 힌트: 초기 로드 가속 팁 초기 로딩은 DNS 조회부터 TCP/TLS 연결, 그리고 실제 리소스 다운로드까지 단계적으로 진행됩니다. 이 과정에서 병목이 생기면 사용자 체감은 즉시 나빠지죠. 그래서 우리는 dns-prefetch, preconnect, preload, 그리고 우선순위 힌트(fetchpriority/priority) 를 정확한 위치에 배치해 초기 왕복을 줄이고, 브라우저의 다운로드 큐를 올바르게 정렬해야 합니다. 핵심은 “많이 쓰는 것”이 아니라 정말 필요한 지점에만 쓰는 것입니다.1) 언제 무엇을 쓰나 (결정표)먼저 각 기술의 역할을 구분합니다. dns-prefetch는 도메인 이름만 미리 해석해두는 가벼운 힌트로, 상단 접점에서 당장 연결까지 필요하지 않은 외부 출처에 적합합니다. 반면 preconnect는 DNS.. Brotli vs Gzip 압축: 텍스트/이미지/폰트별 최적 선택 같은 서버, 같은 네트워크라도 압축 설정만 잘해도 전송 바이트와 TTFB·LCP가 눈에 띄게 내려갑니다. 대표 코덱은 Brotli와 Gzip. 무엇을 어디에, 어느 수준으로 적용할지가 핵심입니다. 이 글은 텍스트/이미지/폰트별 최적 선택, 정적·동적 전송 전략, 레벨 튜닝을 한 번에 정리합니다.1) 코덱 한눈에 보기Gzip: 가장 널리 호환. 압축·해제 모두 빠르고 CPU 부담이 낮음.Brotli: 텍스트(HTML/CSS/JS)에서 더 높은 압축 효율. 고레벨에서 특히 유리하나 인코딩 CPU가 상대적으로 큼.원칙: 정적 파일(캐시 가능) 은 Brotli 고레벨 선압축, 동적 응답은 CPU 여유에 맞춰 Gzip 또는 Brotli 중간 레벨.2) 텍스트 리소스별 추천안HTML권장: Brotli 레벨 9–11.. 이전 1 2 3 4 다음