WeTri 인프라, 배포 구축기 ‐ 5
- WeTri의 기능 중 프로필에 사진을 추가하거나, 게시판에 사진을 넣을 수 있습니다.
- 매주 금요일 마다, 요창님이 진행하시는 마스터 클래스에서 서버리스를 자주 사용한다는 말을 듣고, 이미지 API를 NCP CloudFunction과 API Gateway를 이용하면 되겠다고 생각했습니다.
- 주먹 구구 식이더라도, WeTri 팀에서 인프라, 배포에 대한 걱정은 없게 끔 책임을 가지고 구축해왔었고, 스스로 빠른 시간 내에 많은걸 학습했다고 자부심도 나름 가져서 뒷 일은 생각하지 않고 시도했습니다.
- 결론 부터 말하자면, 크게 실패했습니다. 공식 문서를 봐도, Github에 검색해서 NCP 그룹에 들어가서 코드와 사용법을 보아도, 액션 트리거 개념과 API Gateway 그리고 배포 등 이해가 잘 안되었고 너무 어려웠습니다.
- **될 것같은데 안되는 상황이 반복되자 손절할 타이밍을 놓치게 되고, 투자한 시간이 아까워 꼭 구현하겠다는 욕심만 가득해졌습니다.
- ** 2일차가 될 때 쯤 구현도 실패하고 남은게 없어서 정용님께 사죄의 말씀을 드리고 서버에 Image API를 빠르게 구현을 시작했습니다.
- 이미지 API를 검색하면 블로그 대부분이 AWS S3를 이용한게 나옵니다.
- 대부분의 블로그 들이, Object Storage에서 이미지를 업로드하고, 정적 웹 호스팅을 이용해서 이미지를 불러왔습니다.
- 글을 보면서 들었던 일련의 흐름은 다음과 같았습니다.
- 물론 데이터베이스랑 다르지만, 저장소라는 개념은 컴퓨터 하드 디스크를 생각하게 만들었습니다.
- 프로필, 게시물 사진 등은 한번만 요청이 되는게 아닌 여러번 요청 될 수 있습니다.
- 따라서 컴퓨터 하드디스크에서 계속 받아오게 된다면 값이 비쌀 거라고 생각했습니다.
- 또한 컴퓨터 캐시 메모리 처럼, 캐싱을 해두면 빠르게 대응할 수 있다고 판단했습니다.
- 어떤게 있는지 찾아보던 중 다음을 발견했습니다.
-
캐싱 안정적인 전송, 효율적인 비용 관리가 눈에 띄었습니다.
-
Object Storage에서 데이터를 가져오는 것과 CDN에서 데이터를 가져오는 것 중 어떤게 더 비쌀지 계산기를 두드려 봤습니다.
- 크기가 작은 파일에서는 CDN이 더 비쌌습니다.
- 크기가 클 경우에는, CDN이 더 저렴했습니다.
- 물론 CDN이 주는 요청하는 사용자의 위치에서 빠르게 정적 파일을 제공한다는 점과 Object Storage에 업로드된 이미지의 보안도 높일 수 있었습니다.
- 나름 잘 정리하고 논리적으로 접근해서 멘토님에게 자랑하려고 글을 적었습니다만… 캐싱 정책은 어떻게 하셨나요? 질문에 말을 잇지 못했습니다.
- CDN을 사용했을 때, 캐싱 정책 같은 경우 기본이 7일로 설정 되어있었습니다.
- 프로필이 변경되었을 때, 또는 게시물 이미지가 변경되었을 때 사진을 캐싱했다면 반영이 되지 않고, 7일 뒤에 반영이 될 것입니다.
- 이 부분은 곰곰히 생각해본 결과.. 파일 명을 유저명, 게시물 명으로 매칭시키지 말고, UUID로 랜덤 부여해서 사진을 계속 추가하고 변경 시켜주는 방법으로 해결했습니다.