딘퐁 형님
json압축해서 api 전송 nginx gzip 옵션 댓글
S3 presigned URL은 왜 하면 안되는가?
스토리가 뻔하다.
클라이언트 -> 서버 -> S3를
클라이언트 -> S3 단계로 줄여주는 기능인데
너도나도 복사붙여넣기해서 면접관도 보면 무슨말할지 줄줄 나온다
블로그나 AI에게 물어보면 세팅법도 기가막히게 알려준다.
그러면 대체 어떻게 작성하란 말인가?
AI가 잘 못하는 것 중 하나가 fit하게 해주는 것이다.
"우리 회사에 적합한 방식"
nginx에는 gzip 옵션이 있다.
쉽게 말해서 json body 용량이 큰 경우 네트워크 전송 시간이 오래 걸리는데
(그전에 json body가 커서 지연이 느린 현상이 선행되어야 한다)
이것을 압축해서 용량을 줄여서 전송하고
브라우저 단에서 압축을 풀어서 랜더링 하는 원리다.
gzip 압축 레벨은 “얼마나 강하게 압축할 것인가”를 정하는 값입니다.
보통 1부터 9까지 설정할 수 있습니다.
숫자가 낮을수록
압축은 빠르지만 압축률은 낮습니다.
숫자가 높을수록
압축률은 좋아지지만 CPU 사용량이 증가합니다.
압축률은 CPU 사용량에 대한 트레이드오프이다.
현재 내 프로젝트와 클라우드에 배포된 인스턴스
스펙에 맞는 압축 레벨은 몇인가?
이에 대한 답을 쉽게 할 수 없을 것이다.
json body가 큰 페이지를 하나 잡고 초당 요청 수를 가정하여
압축 레벨을 조정하면서 테스트하며 최적의 레벨을 찾아 가야한다.
(물론 실제 사용자 패턴까지 유사하게 테스트 환경을 구축하긴 쉽지 않다..)
사실 그냥 적당히 레벨6으로 잡으면 별 문제가 안생긴다.
누군가는 별거 아닌 사소한 것으로 저평가할 수 있지만
(SI는 저런거 별 관심 없을수도 있다.. 실제로 json body가 그렇게 큰 경우가 많진 않다.
실제로 나도 안해봐서 얼만큼 cpu부담을 주는진 모른다.. 생각보다 부담이 없을수도
현업에서 저런 옵션은 DevOps 엔지니어 담당이라 개발자에겐 적합하지 않을 수 있다.)
저런 탐구 정신이 누군가에게는 좋은 인상을 줄 수 있다.
최선을 다했어도 모두를 만족시킬 순 없다.
공채에서는 정작 저런 부분보다 소프트 스킬(협업,소통능력)이 더 중요하게 보는 경우도 많으니 너무 실망하지마라..
감사합니다 형님...
좋다
인프라 엔지니어 포폴로 ㄱㅊ을듯
좋은 접근법 배워갑니다
웹땔감이면 nginx gzip 안씀. 톰캣에서 gzip 컴프레션 해주는데 낭비임. 그리고 사실 요즘은 http compression 은 zstd가 대세임. 압축률 더 높고 더 빠름
감사합니다 저쪽 전문은 아니라 몰랏네요 더좋은 방법이 있다면 그게좋을거같습니다 - dc App
아하.. 근데 사실 클라이언트도 압축방식을 지원(이해) 해야함 가령 request header에 accept-encoding 필드에 gzip이라고 적어서 들어오는데, 이건 gzip으로 압축한 데이터도 수용가능하다 라는 의미임, 왠만하면 이런 메타들을 지켜주는게 좋음.. 상대방이 이해못하면 자원낭비니.. 범용적으로는 gzip이 더 실효성 있을것 같아
이 부분도 고려해야 한다고 생각함..
gzip은 cpu 부하가 꽤 크고 클라이언트의 네트워크 자원이 비싸면 고려해볼만하지 않나, 그리고 요청, 응답 데이터가 큰 컨텐츠라면 고려할것 같긴 한데 아니면 무의미하지 않을까 더군다나 데이터가 압축되어 있으면 디버깅 할때 불편할지도,
맞아 현대 웹서비스는 페이징 처리를 해서 일반적으론 쓸 상황이 많진 않은거 같아 - dc App
내가 사내에서 저걸 써서 큰 효과를 봤는데 db에 저장된 큰 html 파일 한번에 여러개를 가져오는 상황이었음 - dc App
istio proxy가 처리해주는 gzip압축 - dc App