최종 팀 프로젝트[back] openAPI image 이슈

https://github.com/sdoram/b4_exhibitions_frontend

GitHub - sdoram/b4_exhibitions_frontend: B4조 지금은 전시상황 프론트엔드

https://github.com/sdoram/b4_exhibitions_backend

GitHub - sdoram/b4_exhibitions_backend: B4조 지금은 전시상황 백엔드

1.db에 openAPI data로 게시글을 작성할 때 image를 url로 저장한 뒤 필요할 때 url을 통해서 이미지를 불러오기 

장점 : db에 용량을 최소한으로 저장 가능하다 

단점 : 게시글을 불러올 때 마다 url로 image를 요청하는 과정이 필요하다. API가 제공하는 이미지가 압축되지 않은 원본 파일을 다운로드하여 브라우저에 보여주는 과정에서 mb단위의 넘는 요청이 지속적으로 발생하며 백엔드 서버에 부담 발생 

결론 : 로컬에서 진행할 때는 괜찮지만 배포 과정에서 사용하기에는 적합하지 않은 형태의 저장 방식인 것 같다. 

 

2. openAPI data 최초 저장시 url을 통해서 이미지 저장하기 

장점 : 저장된 이미지를 불러올 경우 배포 환경에서 속도와 서버 부담이 줄어든다. 

단점 : 단순 url에 비해 추가적인 로직 작성 필요, 이미지가 저장되는 만큼 db에 용량 부담, 최초 저장시 모든 이미지 저장필요 

결론: 배포 환경에서 서버 안정성, 과금 문제등을 고려하면 1번 방법보다 더 나은 선택지다. 

 

3. openAPI data 저장시 확장자 변환을 통한 image 용량 개선 

장점 : db에 저장되는 데이터양을 줄이면서 요청을 할때도 성능 개선을 기대할 수 있다. 

단점 : db에 저장 시 변환하는 로직을 추가해야함, 최초 데이터 생성시 로직이 추가되는 만큼 서버에 순간적인 부하 가능성 존재 

결론 : 2번의 방법으로 서버에서 저장에 성공했을 경우 이 방법을 시도하여 추가적인 개선 시도 필요 

 

1. 이미지 로딩속도와 서버 부담 개선하기 

 문제점

서비스 배포 후 유저 피드백으로 이미지 로딩 속도가 느리다는 의견과 예상 이상으로 발생하는 서버 비용 문제 인식 

 시도해 본 것들

 

API에서 제공하는 이미지 URL이 압축되지 않은 채로 제공되며 브라우저에서 요청할 때마다 이미지를 다운받아서 보여주며 문제 발생

 

 

이미 API 탐색에 많은 시간을 투자해 사용하고 있는 API 이므로 DB에 최초 저장시 이미지 저장 코드를 추가하여 해결

 

이렇게 해결했지만, 저장된 이미지가 EC2로 업로드 되며 백엔드 서버 운영에 영향을 끼치는 것을 파악, s3사용과 같은 해결책 필요 

 알게 된 점

직접 데이터를 만드는 것이 아닌 다른 데이터를 가져올 때 내가 일반적으로 생각하는 결과와 다른 결과가 나타날 수 있음을 인지하고 사용하자