https://team-edo.github.io/tags/aws-sdk/Recent content in AWS SDK on 얼쑤 · Team EdoHugoko-krWed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/storage-sdk-call-budget/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/storage-sdk-call-budget/<p>녹음 업로드 요청은 파일 검사와 객체 저장을 거친 뒤 응답합니다. 코드 리뷰에서 저장소 호출 상한이 <strong>2분</strong>이라는 점을 확인했습니다. 이 경로에서 Nginx의 응답 읽기 제한은 <strong>60초</strong>였습니다. 저장소가 느리면 애플리케이션이 오류 형식을 정해 응답하기 전에 프록시가 연결을 끝낼 수 있었습니다.</p> <h2 id="재시도까지-하나의-예산으로-묶었다">재시도를 포함한 40초 상한</h2> <p>파일 검사 도구에는 10초, 저장소 호출 전체에는 <strong>40초</strong>를 배정했습니다. 두 설정을 더하면 50초입니다. Nginx의 60초는 연속한 읽기 사이의 대기 제한이고, 50초는 이 경로의 두 주요 작업에 배정한 예산입니다. 둘 다 실제 요청 시간의 측정값은 아닙니다. <a href="https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout">Nginx의 응답 읽기 제한</a></p>https://team-edo.github.io/posts/2026/10/signed-chunk-upload-fixture/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/signed-chunk-upload-fixture/<p>녹음 저장소를 붙이면서 작은 파일 하나를 업로드하는 검사를 만들었습니다. SDK를 대역으로 바꾸면 서비스가 SDK를 호출했는지만 볼 수 있습니다. 실제 SDK가 메서드, 경로, 인증 헤더와 본문을 어떤 모양으로 보내는지 보려고 로컬 HTTP 서버를 저장소 주소로 넣었습니다.</p> <p>원본은 <strong>3바이트</strong>였습니다. 대역 서버가 받은 본문은 <strong>175바이트</strong>였고, 본문을 그대로 원본과 비교하던 검사가 실패했습니다.</p> <h2 id="요청-본문에-파일과-서명이-함께-있었다">전송 본문에 붙은 청크 서명</h2> <p>대역이 받은 본문에는 청크 길이와 청크별 서명이 들어 있었습니다. 이 요청의 SDK는 파일 데이터를 <code>aws-chunked</code> 형식으로 감쌌고, 데이터가 끝나는 지점도 크기 0인 청크로 표시했습니다. 그래서 전송 본문의 길이에는 원본 외에 프레이밍과 서명 정보까지 포함됐습니다. AWS 문서에서 <code>x-amz-decoded-content-length</code>는 이 메타데이터를 제외한 원본 길이입니다. <a href="https://docs.aws.amazon.com/AmazonS3/latest/developerguide/sigv4-streaming.html">AWS SigV4 청크 업로드 문서</a></p>