개요

블로그를 어떻게 할까에 대한 고민 중 큰 축이 바로 미디어 파일이다.

문제

아주 뿔이 난다 이 말입니다.
이게 무엇인가, 옵시디언 디지털 가든에서 간혹 웹 호스팅 레포지토리에 이미지를 넣지 않아서 생기는 문제다.
이미지 url 경로에 실제 이미지가 있지 않아서 생기는 것이다.
왜 간혹 레포지토리로 사진을 전송하지 않는가를 묻는 것 자체는 사실 차치할 근거가 있다.
결국 이미지가 많아지면 깃헙 레포의 제한을 넘기게 되고, 현재 문제를 해결하더라도 더 큰 문제에 부닥치게 될 것이다.
그러므로 단순히 이미지가 레포에 업데이트되지 않는 것을 넘어서 다른 방식으로 이미지 파일을 웹에 게시할 필요가 있다.
웹 호스팅 중인 블로그 사진들도 결국 전부 깃헙에 저장되고 있는 관계로 다른 원격 저장소가 필요하기는 하다는 것.

가능성 고려

나스 호스팅

첫번째는 열심히 구축해둔 나스.
사실 이러려고 나스 산 거 아니냐! 싶긴 한데, 트래픽을 훌륭히 감당할 만큼 좋은 사양을 산 것도 아니고..

요즘 이 친구는 열심히 ip 차단하느라 여념이 없다.
그래도 파일스테이션에서 api를 제공할 방법이 있는지 찾아봤다.
있긴 한데, 함부로 파일스테이션 api를 쓰는 방향도 공격표면을 넓히는 꼴이라 지양하는 게 좋다는 글을 보았다.
사실 더 파고들면 못할 건 없는데, 시간이 조금 많이 소요될 것 같은 느낌.

imgur 플러그인

사실 최근에 이 녀석을 많이 썼다.^[1]
그러나 imgur의 문제는, 올리는데 시간이 오래 걸리는 것뿐만 아니라 요청량이 많은 타임에 올리려고 하면 실패를 한다는 것이다.
후자가 매우 큰 문제로, 실패를 하게 되면 귀찮게 현 문서에 에러 정보까지 나오면서 텍스트가 추가되어 이를 지우기 위해 내가 손을 대야 하는 것이 늘어나게 된다.

네이버?

네이버 마이박스도 생각했는데, 이 녀석은 개발자 api가 제공되지 않는다.
이때 떠올린 기발한 방법 중 하나는 네이버 카페를 이용하는 것인데.. 이쪽은 무조건 도메인을 요구하는 것 같다.
내 로컬에서 올리기 쉽지 않을 가능성이 있다는 것을 염두해야 한다.

구글

구글 포토도 알아봤다.

이쪽은 실제 미디어 파일 자체의 경로를 60분만 활성화시킨다.

드롭박스

api가 잘 되어 있는 것 같지 않고, 용량을 많이 제공하지도 않는 것 같고.
이 친구는 많이 알아보진 않았다.

원드라이브

마소 학교 정책 변화로 인해 내 학교 계정 원드라이브가 1테라에서 50기가로 폭삭 다이어트를 했다.
여기엔 내 강의들이 저장되어 있어 사용할 공간이 없다.

깃헙

gist

지금은 일단 이것을 써보고 있다.^[2]
gist로 이미지를 올리는 플러그인이다.

뭔가 했는데, gist에 사진을 base64로 인코딩해서 올리고 이를 제공하는 방식이다.

그래서 이런 식으로 직접 url을 치면 이렇게 나온다.
근데 이거 조금 문제가 있는 게, 이렇게 하면 웹으로 호스팅할 때 제대로 동작할까?
결국 base64로 나오는 건 쿼리로 주어진 url이고, 결국 itg.singhinder 사이트를 사용하니까 상관은 없는 것 같다.

그런데, 해당 사이트는 무엇인가?
이 플러그인을 만든 개발자의 이름이 도메인인 사이트인데, 이 유저가 직접 만든 서버인 것으로 생각된다.
달리 말하자면 이 유저의 서버에 url을 요청으로 보내면 해당 서버에서 base64를 디코딩하고 사진 파일로 만들어서 리턴을 해준다는 것이다.
또 달리 말하자면 해당 유저의 서버의 역량에 내 데이터가 좌지우지 된다는 것인데, 나는 이것에 대해서는 상당히 회의감이 든다.
더 찾아봤는데, 이러한 내 의혹에 대한 답이라도 하듯이 해당 서버의 코드도 유저가 올려뒀다.[^5]
이 서버는 캐디를 이용한다는 것 같은데, 찾아보니까 caddy는 그냥 리버스 프록시 서버인데..?
딱히 퍼블리싱을 해주는 게 아닌데, 그럼 해당 사이트는 무어란 말인가.
역시 불안한 느낌이 든다.
사실 어차피 gist에 올리는 이상 퍼블릭하게 노출되어 있는 거긴 하지만..

이틀 써본 지금 이 친구도 완벽하지 않다 느끼는 게, 본인 서버의 요청량 제한을 걸어두었다.
시간당 30개라 했던가, 아무튼 열심히 사용하다보니 금새 제한이 걸렸다.

레포지토리

또다른 방편, 깃헙에 올리기..
아예 이미지를 올리는 레포지토리를 판다.
그리고 레포지토리가 꽉 찰 때마다 새로운 레포지토리를 두면 된다.
아니면 깃헙 페이지를 사용해도 좋다.

대충 하나 올렸다.

그럼 이런 식으로 보는 것이 가능하다.

근데 이것도 조금 찾아봤는데, 한 ip에서 5000개의 요청이 오는 것은 제한한다는 것 같다.^[3]
이 정보는 정확한 것은 아닌 게 문서로 명시된 것이 아니고 그저 깃헙 책임자 중 누군가 언질한 정도에 불과한 거라..
그래도 요청 ip 기반으로 요청량의 개수를 제한하는 것이라면, 사실 img 태그를 통해 요청을 날리는 것은 클라이언트의 브라우저라 상관이 없을 것으로 생각된다.
나는 한 소스 당 제한을 두는 거라 생각해서 조금 걱정했는데, 이러면 사실 상관 없긴 하다.

이 방식은 꽤 좋다고 생각하는 것이, 최소한 내 입장에서는 이미지 경로를 명확하게 예측할 수 있다.
내가 넣을 파일의 이름이 무엇인지 알고 있고 해당 레포지토리 이름을 알고 있으니, 이걸 기반으로 편하게 이미지 임베드를 해낼 수 있다.

그런데 마음에 걸리는 한 포인트는, 왜 여태 이런 방법을 활용하는 플러그인이 개발되지 않았나 하는 것이다.
아니 개좋은 방법 아님?
레포 용량 제한 늘어나면 새 레포 파면 되고, 요청 제한도 꽤나 넉넉한데 말이다.
내가 미처 고려하지 못한 다른 부분이 있는 것인지, 그 부분이 조금 걸린다.

aws

역시 현대의 엔지니어라면 클라우드인가..
그런데 솔직히 돈을 쓰고 싶지 않다.
기왕 산 나스를 이용하지 않는 마당에 돈까지 내면 억울하지.
내더라도 정말 적게 내야 한다.
한 달 백원 이상 넘어가지 않고 싶다.

한다면 S3는 유효한 선택지가 될 수도 있다.
요청이 너무 많이 들어간다면 앞단에 Amazon CloudFront를 배치하면 되는 것이고.
이건 최소한 내 저장소를 마련하는 것이니까 위의 선택지처럼 제한을 고민할 필요는 없다.
내 지갑 제한은 고려해야겠구나

비용 조사

이건 진짜 얼마나 비용이 나올지를 먼저 감안해봐야한다.
이를 위해 다음과 같이 상황을 가정하고자 한다.
이 상황은 최대로 발생할 수 있는 비용을 산정하기 위함이다.

• 이미지 크기
  • 각 이미지는 300Kb를 넘지 않는다.
• 이미지 업로드
  • 매일 30개의 이미지를 업로드한다.
• 이미지 요청
  • 내 옵시디언에서, 웹 호스팅 블로그에서 요청이 매번 발생한다.
  • 내 로컬에서는 매일 100개 가량의 이미지를 요청한다.
  • 20번 가량은 같은 이미지를 요청한다.
  • 웹에서는.. 얼마나 늘어날지는 모르지만 500번의 요청이 있다고 치겠다.
    • 이건 정말 확신이 없는데, 그래도 이 이상이나 보지는 않을 것 같다는 생각이다.
    • 여기에는 같은 이미지가 없다고 가정하겠다.

월간 저장하게 되는 크기는 0.3 * 30 * 30 = 270메가
당연히 월마다 합산되는 방식이다.
이미지 요청은 매월 600번이며, 헤더와 패킷을 쪼개기 때문에 용량을 두 배로 잡는다면?
0.3 * 600 * 30 * 2 = 960메가 정도.
진짜 최대한으로 잡았을 때 그럴 것 같다는 것이다.

s3 스탠다드를 쓴다고 생각해보자.

월 저장 비용은 0.025달러.
점점 늘어나긴 할 것이나, 1달러가 되기까지 400개월이 걸린다.

클라우드 프론트 미사용

전송 비용에 대해서는 두 가지를 고려해본다.
먼저 클라우드프론트를 쓰지 않을 경우에는 모든 요청이 s3로 가게 된다.

인터넷으로 나가는 요금은 월 0.126 달러.

비용 계산기로도 비슷한 정도로 책정된다.

클라우드 프론트 사용

클라우드 프론트는 기본적으로 이정도까지는 무료이다.
위에서 고려한 사항들은 전부 이것을 넘지 않는다.

종합적으로, 환율 미쳐날뛰는 요즘이지만 그래도 200원 가량의 비용이 발생한다고 볼 수 있겠다.
사실 이 정도면 나쁘지는 않다고 생각한다.
비용 예측을 하니, 절대 쓰지 않을 거라 생각했던 s3도 나쁘진 않을 수 있다는 생각으로 바뀌었다 ㅋㅋ

추가 고민

근데 그러면, s3는 이용하지 않고 클라우드프론트만 이용하는 것도 가능하지 않겠는가?
이미지 자체는 깃헙 레포에 올리고, 이것을 클라우드프론트에서 캐싱하도록 해주는 것이다.
그러면 과도한 요청이 발생하더라도 어느 정도 클프에서 보완을 해줄 수 있을 것으로 생각한다.
이 시나리오로 간다면 고민할 것이 더 있는가?

• 플러그인 개발 소요
  • 이미지를 깃헙 레포에 올리는 로직 개발
  • 옵시디언에 붙여넣는 작업을 할 때 자동으로 파일이 업로드된다.
  • 업로드가 완료되고(아니면 비동기적으로) 해당 이미지 url 링크가 옵시디언에 들어간다.
• 클라우드 프론트의 백엔드가 깃헙이 됨으로써 발생하는 비용은 있는가?

이건 설정하는 게 어렵지도 않을 것 같아서 간단하게 poc를 시도했다.
근데 역시 쌈마이 인생은 녹록치 않습니다.

요청은 잘 갔을 것 같은데, 왜 안 될까?
간단하게 설정할 수는 없다는 것만 알고 넘어가려고 한다.

관련 문서

참고