PostgreSQL를 이미지 저장소로 활용하기 (Raw HTML)

<img src="https://blog.atj.sh/post-attachments/v/0194e507-718f-7380-8cb2-cb96a164684c" width="100%"/>

<br />

<p>
  이 블로그는 네이버 블로그나 티스토리 등의 서비스 없이 운영되고 있다. 글에 첨부되는 이미지들을 위한 별도의 클라우드 서비스 또한 사용중이지 않다. 블로그에서 보여지는 모든 이미지는 PostgreSQL DB에 저장되고, 이미지 조회 요청이 오면 서버가 DB에 저장된 이미지 이진 정보를 불러와서 사용자에게 보여주고 있다.
</p>


<h2>
  동기
</h2>

<p>
  처음 블로그를 완성할 당시에는 이미지 업로드 기능이 없었다. 이 이미지 업로드 기능이 없는 것 때문에 글을 쓸 때 아쉬운 상황이 많아졌고, 이제는 제발 구현해놓기로 결정했다. 
</p>

<p>
  이 블로그의 기술 스택은 아래와 같다.
</p>

<ul>
<li><a href="https://www.rust-lang.org/" target="_blank">Rust lang</a> - 프로그래밍 언어</li>
<li><a href="https://github.com/tokio-rs/axum"target="_blank">axum</a> - Rust 기반 웹 프레임워크</li>
<li><a href="https://aws.amazon.com/ko/lambda/"target="_blank">AWS Lambda</a> - 컴퓨팅 인프라스트럭쳐</li>
<li><a href="https://postgresql.org/"target="_blank">PostgreSQL</a> - DB</li>
<li><a href="https://kit.svelte.dev/"target="_blank">SvelteKit</a> - Svelte 기반 웹 프레임워크</li>
<li><a href="https://pages.cloudflare.com/"target="_blank">Cloudflare Pages</a> - 무료 웹 호스팅 서비스</li>
<li><a href="https://supabase.com/"target="_blank">Supabase</a> - BaaS & 무료 PostgreSQL 호스팅 서비스</li>
</ul>

<br />

<p>
  나는 이 기술 스택을 변함 없이 유지하고 싶었다. 무언가 서비스를 더하기도 싫었다. 일단 시도해봤다. 
</p>

<h2>
  메인 아이디어: DB에 이미지를 저장하자
</h2>


<p>
  DB는 데이터를 오랫동안 저장하는 역할을 한다. 실무에서는 DB에 수치값이나 이메일 정보와 같은 숫자, 텍스트 정보를 저장하곤 한다. 
</p>

<p>
  보통 이미지 파일은 DB가 아닌 다른 곳에 저장된다. 예를 들면 NAS나 클라우드 스토리지에 저장되곤 한다. 관리의 용이성과 데이터 성격에 따른 분리 때문이다.
</p>

<p>
  그런데 나는, 숫자나 텍스트나 이미지나 결국 0과 1로 이루어진 이진 데이터라고 생각했다. 그래서 그냥 DB에 전부 보관해보기로 했다.
</p>

<p>
  기술적으로 살펴보니, 지금 사용중인 DB인 <a href="https://www.postgresql.org/docs/current/datatype-binary.html" target="_blank">PostgreSQL에서 이진 정보 저장을 지원</a>한다는 사실을 확인했다. 이게 된다면 이미지 저장이나 더 나아가서 일반 파일 저장도 가능해진다.
</p>

<h2>
  테이블 설계
</h2>

<p>
  파일을 저장하기 위한 테이블을 다음과 같이 설계했다.
</p>

<pre>
  CREATE TABLE public.post_attachment (
    id UUID NOT NULL,
    content BYTEA NOT NULL,
    written_by_id INTEGER NOT NULL,
    file_extension VARCHAR(20) NOT NULL DEFAULT '',
    mimetype VARCHAR(255) NOT NULL,
    PRIMARY KEY (id)
);
</pre>

<ul>
  <li>id: 인터넷에서 파일에 접근하기 위한 URL. UUID 형식이며, URL에 다음과 같이 할당된다. <code>https://blog.atj.sh/post-attachments/v/<b>0194e521-339c-7e10-b205-a2a9416fdb97</b></code></li>
  <li>content: 파일의 이진 정보.</li>
  <li>written_by_id: 파일을 업로드한 사람의 ID.</li>
  <li>file_extension: 파일의 확장자. 파일이 업로드될 때 파일의 이름에서 가져와 DB에 저장한다. 파일의 원래 이름은 저장되지 않고 대신 확장자만 저장된다.</li>
  <li>mimetype: 파일의 mimetype. 파일이 업로드될 때 <a href="https://developer.mozilla.org/en-US/docs/Web/API/Blob#instance_properties"><code>Blob.type()</code></a> 메소드를 통해 가져와져서 DB에 저장된다.</li>
</ul>

<h2>
  업로드 시나리오
</h2>

<p>
  내가 글을 쓰며 이미지를 첨부할 때 서버에서 이루어지는 작업이다.
</p>

<img src="https://blog.atj.sh/post-attachments/v/0194e521-339c-7e10-b205-a2a9416fdb97" class="full-unrounded"/>

<p>
  이미지 압축의 경우에는 원래 CloudFlare Pages 서버단에서 처리되도록 하려고 했는데, <a href="https://community.cloudflare.com/t/rendering-svg-using-canvas-with-cloudflare-workers/90952" target="_blank">이미지 압축에 핵심적으로 필요한 Canvas API가 지원되지 않아서 관뒀고</a>, AWS Lambda에서 처리하기에는 <a href="https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html" target="_blank">허용 요청 크기가 6MB 수준</a>이라서 요청이 거부되는 상황이 발생할 것으로 예상했다.
</p>

<p>
  따라서 네트워크 요청을 타기 전에 브라우저 안에서 이미지 압축을 미리 진행하도록 구현했다. 결론적으로는 네트워크 트래픽이 절약되고 DB에 저장되는 데이터의 크기 또한 작아졌다. 
</p> 

<p>
  압축 알고리즘은 <a href="https://ko.wikipedia.org/wiki/WebP">WebP로 압축하는 방법</a>을 사용했는데, 12MB 이미지를 100KB 정도의 크기로 압축할 정도로 효율이 좋았다.
</p>


<h2>
   조회 시나리오
</h2>
<p>
  방문자가 이미지를 볼 때 서버에서 이루어지는 작업이다.
</p>

<img src="https://blog.atj.sh/post-attachments/v/0194e521-2c4a-71d3-bb0b-fcf2bb5419c4" class="full-unrounded"/>

<p>
  CloudFlare Pages에서 자체적으로 지원되는 <a href="https://developers.cloudflare.com/workers/runtime-apis/cache/">Cache API</a>를 적용했다. 덕분에 DB 조회로 인한 부하가 조금이나마 줄어들었다. 또한 브라우저에서 알아서 캐싱할 수 있도록 <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control" target="_blank">Cache-Control 헤더</a>를 적용했다. 
</p>

<img src="https://blog.atj.sh/post-attachments/v/0194e539-fa72-7c10-a22e-0d1a2bf03c76" width="100%" />

<p>
  이미지 파일을 제공할 때 브라우저에서 자연스럽게 제공될 수 있도록, 이미지의 형식을 HTTP 응답 헤더에 정확하게 기입하는 작업이 필요했다. 이미지가 서버에서 조회될 때 <a href="https://github.com/atjsh/rust-blog/blob/ad708e876d7def1683e282fe13576fa14f6b7e94/server/src/routers/post_attachment.rs#L44" target="_blank">이미지의 메타데이터가 HTTP 응답 헤더에 잘 담겨서 전달되도록 구현</a>하였다. <br /> 개인적으로는 이 작업을 하면서 HTTP Mimetype과 이미지 확장자의 차이를 좀 더 명확하게 알 수 있었다.
</p>

<h2>결론: 구현에 성공했지만 개선의 여지는 있음</h2>

<p>
  이 글에서 사용된 이미지들은 모두 위 로직을 통해 DB로부터 조회되어 브라우저에 렌더링된 것이다. 이미지들이 잘 보인다면 구현이 안정적으로 완료되었다는 뜻일 것이다. 만약 이미지가 안 보인다면, 중간에서 미처 발견 못한 버그가 있어 브라우저까지 이미지가 도달하지 못한 것으로 보면 된다.
</p>

<p>
  HTTP 캐싱을 적용하긴 했지만 완벽히 파악하진 못해서 일부분만 구현했다. 기회가 되면 더 완전하게 구현하고 싶다.
</p>

<p>
  1MB 크기보다 작은 이미지 제공은 성공했지만, 그보다 큰 이미지나 대용량 파일 제공은 위에서 설명한 바와 같이 여러 제한 때문에 힘들다. 심지어 10MB 정도의 파일 제공도 지금은 불가능한 상황이다. 이미지의 경우에는 WebP 압축이 워낙 효율적이라 불편한 점이 없는 상황이지만, 다른 파일의 경우에는 용량 제한이 크게 다가올 수 밖에  없다. 
</p>

<p>
  기술 스택을 유지하는 동시에 더 큰 파일을 서빙하기 위한 방법을 연구해봐야겠다.
</p>

<h2>
  소스코드
</h2>

<p>이 블로그의 소스코드는 오픈소스이다. 내 <a href="https://github.com/atjsh/rust-blog" target="_blank">GitHub</a>에서 확인 가능하다.</p>


<p>
  이번 기능이 추가된 커밋 내역은 다음 링크에서 확인 가능하다. <a href="https://github.com/atjsh/rust-blog/compare/89958ca4f61585c1a8c0036d6b31301769cccb3c...ad708e876d7def1683e282fe13576fa14f6b7e94?diff=unified" target="_blank">atjsh/rust-blog - 89958c...ad708e</a>
</p>

<h2>
  굉장히 만족
</h2>

<p>
  거의 2달간 미룬 작업인데 하루만에 구현을 끝냈다. 드디어 끝내서 속이 후련하다.
</p>