
1. 설정 방법

cloudflare에 로그인해서 개료의 버킷생성을 클릭한다.

버켓생성시 이런 화면을 볼수있다. 이름 입력하면되며 관할지 지정은 굳이 변경할 필요가 없다 자동으로 잡아줘야 가까운데로 가니까 서비스를 외국에서 하신다면 거기에 맞게 해주셔야 겠죠...?
기본 저장 클래스는 표준으로 선택하면 되는것이. Infrequent Access는 한달 한번 미만 접근하는 백업 아카이브용에 가깝다고 한다.

생성이 됐다면 계정 개요 -> 계정 세부 정보 의 관리를 누르자

그럼 API 토큰 생성 창이 나온다.
Account API 토큰은 서버 같은 서비스가 계속 쓰는 키이고, User API 토큰은 내 개인 계정에 묶인 테스트용 키에 가깝다. DecisionLog 백엔드가 R2에 계속 파일을 업로드하고 조회해야 하므로, 개인 사원증 같은 User API 토큰보다 서비스용 공용 출입카드에 가까운 Account API 토큰을 선택했다.

다음은 토큰 설정이다.
- 관리자 일기 및 쓰기 : 관리자가 할수있는 버킷 생성 버킷 삭제 버킷 설정 변경등을 할수있어서 이걸 굳이 안하면 권한 줄 필요없다.
- 개체 읽기 및 쓰기 : 파일 업로드 다운로드 삭제 목록 조회가 가능하니 니걸 선택한다.
- 버킷 지정은 특정 버킷 지정으로 하여 내가 방금 생성한 버킷 전용 api 키로 만든다.
- TTL은 키를 사용할 수 있는 기간을 말하는데 원하는 기간으로 설정하면된다.
- 주소 필터링의 경우 local 컴퓨터 ip를 알면 그걸로설정해도되지만 짧은 TTL의 제한없는 토큰을 만들어서 로컬에서 쓰고 나중에 prod나 dev로 서버에 올리면 서버의 ip를 등록한 api key를 만들어서 주소를 제한하자

토큰 값들은 다시는 보여지지 않으니 꼭 어디다가 저장해두자 내가 볼수있는 곳에다만 저장해두자
이제 이를 활용해주면된다.
2. 왜 R2 인가
난 돈이 없다. 더더욱 서버 관리하는데 돈을 많이 쓰고 싶지 않다. 하지만 파일 저장은 하고싶었다.
DecisionLog라는 내가 운영하는 서비스에서는 경험을 블로그처럼 저장하는 기능이있다.
아래사진 처럼 글작성을 할 수 있다.

이기능을 개발하기 전에는 단순 텍스트만 저장하면되어 DB와 localStrorage로 관리할수 있었으나 이미지와 본문관리를 하려니 지금 방식이 마음에 들지 않았다.
사유는 다음과 같다.
- 서버 재배포시 파일이 날아갈 염려가 있다.
- 서버 디스크 용량을 계속 신경 써야하며 나중에 서버 옮길시 파일 마그레이션이 필요하다.
- 무엇보다 애플리케이션 서버가 파일 저장소 역할까지 하는 아키텍차가 마음에 들지 않았다.
그래서 선택지는 3가지였다.
- 기존방식으로 일단한다.
돈도 안들고 가장 쉽고 뭔가를 더안해도 됐다. - S3를 쓴다.
가장 표준 선택이고 레퍼런스도 많으며 기업들이 요구로 하는 스팩이 될수 있다. - R2쓴다.
S3 호환이되며 비용부담이 적다.
내가 가장 집중하는 부분이 비용이였기 떄문에 R2를 선택했다. 스텍이야 나중에 필요할때 다시 채우면 되는거 아닐까...????
'Software > Architecture' 카테고리의 다른 글
| [SWA/Structure] MSA(Micro Services Architecture) vs Monolih (단일체 아키텍쳐) (0) | 2024.04.01 |
|---|---|
| [SWA/RESTful API] RESTful API (0) | 2024.03.21 |