<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>객체 저장소 on 얼쑤 · Team Edo</title><link>https://team-edo.github.io/tags/%EA%B0%9D%EC%B2%B4-%EC%A0%80%EC%9E%A5%EC%86%8C/</link><description>Recent content in 객체 저장소 on 얼쑤 · Team Edo</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Mon, 02 Nov 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://team-edo.github.io/tags/%EA%B0%9D%EC%B2%B4-%EC%A0%80%EC%9E%A5%EC%86%8C/index.xml" rel="self" type="application/rss+xml"/><item><title>저장한 녹음을 30일 삭제에서 빼기</title><link>https://team-edo.github.io/posts/2026/11/protect-saved-recordings-from-purge/</link><pubDate>Mon, 02 Nov 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/11/protect-saved-recordings-from-purge/</guid><description>&lt;p>얼쑤에서는 연주를 분석한 뒤 마음에 드는 기록을 저장하고 나중에 녹음을 다시 들을 수 있습니다. 처음에는 R2의 수명 주기 규칙이 녹음 객체를 생성한 지 30일이 지나면 삭제 대상으로 잡았습니다. 연습 기록을 저장했다는 사실은 DB에 있었기 때문에 같은 접두사 아래의 객체에 적용되는 규칙은 그 차이를 알 수 없었습니다. 저장한 녹음을 계속 들을 수 있게 하려면, 어떤 녹음을 정리할지 정하는 곳부터 바꿔야 했습니다. &lt;a href="https://developers.cloudflare.com/r2/buckets/object-lifecycles/">Cloudflare R2의 객체 수명 주기&lt;/a>&lt;/p></description></item><item><title>동시 업로드에서 접수된 녹음만 남기기</title><link>https://team-edo.github.io/posts/2026/10/concurrent-upload-keep-winning-object/</link><pubDate>Wed, 28 Oct 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/10/concurrent-upload-keep-winning-object/</guid><description>&lt;p>얼쑤에서 녹음을 올리면 서버는 파일을 객체 저장소에 쓴 뒤, 세션에 원본의 키를 기록하고 상태를 &lt;code>PENDING&lt;/code>으로 바꿉니다. 같은 세션에 업로드 요청이 거의 동시에 오면 두 요청 모두 처음에는 상태를 &lt;code>RECORDING&lt;/code>으로 읽을 수 있습니다. DB에서 한 요청만 접수하더라도 저장소에는 두 요청 모두 파일을 쓰는 시점이 생깁니다.&lt;/p>
&lt;p>세션마다 고정된 객체 키를 쓴다고 가정해 봤습니다. 요청 A가 먼저 DB 갱신을 마쳐도, 요청 B가 같은 키에 늦게 쓰면 DB가 가리키는 파일은 B의 바이트가 됩니다. B가 갱신에 실패하고 자신이 쓴 파일을 지우는 경우에도 같은 키라 A의 원본이 사라집니다. DB가 접수 순서를 정하는 것과 별도로, 어느 요청이 어느 파일을 소유하는지 저장소에서도 구분해야 했습니다.&lt;/p></description></item><item><title>녹음 저장소를 바꿔도 지킨 15분 읽기 권한</title><link>https://team-edo.github.io/posts/2026/10/recording-storage-signed-read/</link><pubDate>Tue, 27 Oct 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/10/recording-storage-signed-read/</guid><description>&lt;p>얼쑤에서 연습 녹음을 받으면 백엔드는 원본을 객체 저장소에 보관하고, 분석 서버는 필요한 파일을 가져와 처리합니다. 처음에는 서울 리전과 신규 계정 크레딧을 고려해 Google Cloud Storage(GCS)를 쓰는 설계를 잡았습니다. 다음 날에는 크레딧이 끝난 뒤의 비용과 다운로드 조건, 저장소를 바꿀 때의 구현 부담을 다시 검토해 S3 호환 API를 쓰는 Cloudflare R2로 계획을 바꿨습니다.&lt;/p>
&lt;h2 id="분석-서버에는-15분-동안-한-파일을-읽을-권한만-준다">한 파일에 15분 읽기 권한&lt;/h2>
&lt;p>분석 서버가 해야 할 일은 전달받은 녹음 한 건을 읽는 일이었습니다. 그래서 백엔드가 특정 객체에 대해 &lt;code>GET&lt;/code> 요청만 &lt;strong>15분(900초)&lt;/strong> 동안 허용하는 URL을 서명하고, 분석 서버는 그 주소로 원본을 내려받도록 했습니다. 저장소의 자격 증명은 서명하는 백엔드에만 둡니다. 유효한 URL을 가진 사람도 파일을 읽을 수 있으므로 주소 자체를 노출하지 않는 것도 이 설계의 일부입니다. &lt;a href="https://docs.cloud.google.com/storage/docs/access-control/signed-urls">Google Cloud Storage 서명 URL&lt;/a> · &lt;a href="https://developers.cloudflare.com/r2/api/s3/presigned-urls/">Cloudflare R2 서명 URL&lt;/a>&lt;/p></description></item></channel></rss>