feat: 이미지 처리 기능을 구현한다

[eom-tae-in]

📄 Summary

• 개인전시회, 팝업스토어 등록시 함께 저장되고 관리되는 이미지에 대한 작업을 완료했습니다.
• 이미지는 서드파티 스토리지(S3)에서 관리됩니다.

🙋🏻 More

• S3에 이미지를 저장하고 조회하는 것은 하나의 요청당 하나의 이미지 처리(저장/조회)가 가능합니다. 그래서 이 작업을 서버에서 하게 되면 메인페이지나 개인전시회/팝업스토어 목록을 보여줄 때 서버에 많은 부하가 걸리게 됩니다. 그래서 이 부분을 최대한 인프라적으로 해결해보려 노력했습니다.

위의 그림처럼 실질적인 관여는 이미지 삭제만 하도록 하여 S3 스토리지와의 의존을 최소화 하였고 S3의 객체 삭제는 저장/조회와 다르게 한번에 1000개 까지 가능하기 때문에 글이 삭제되어 해당 글의 이미지를 삭제할 때 한 번에 요청으로 S3에 있는 글의 객체를 삭제할 수 있습니다.

• 이미지 저장 방식

프론트에서 저장할 이미지를 UUID로 변경하고 API gateway를 통해 람다에게 S3 presigned PUT url을 요청합니다.
이후 람다에서 응답받은 presigned url로 이미지를 업로드합니다. API gateway를 통해 실행되는 람다에게 putObjects 권한을 부여하여
람다에서 문제 없이 presigned PUT url을 발급할 수 있습니다.
API gateway에 요청을 보내는 것은 요금이 들기 때문에 무분별한 요청을 막기위해 쓰로틀링을 설정해두었습니다.(버스트 제한: 500, 요율 제한: 100)
이후 유저가 작성한 팝업스토어/개인전시회 글과 함께 UUID로 변경한 이미지명을 저장하기 위해 서버로 post 요청을 보냅니다.

• 이미지 조회 방식

UUID 이미지명을 데이터베이스에서 targetId(팝업스토어ID/개인전시회ID)로 찾고 이를 바탕으로 cloudfront를 통해 s3에서 이미지를 조회합니다. cloudfront는 원본(S3)에 요청했던 값을 캐싱하기 때문에 빠르게 이미지를 조회할 수 있습니다.(min ttl: 10초, 기본 ttl: 60초, max ttl: 1년)
S3에 CloudFront에서 요청한 getObjects 요청만 가능하도록 버킷 정책을 생성해두어 다른 사용자들은 S3에 접근하여 조회/저장/삭제를 할 수 없도록 설정해두었습니다.

close #102

[sosow0212]

수고하셨습니다! 리뷰 보고 몇 가지 확인만 부탁드릴게요~ 람다 써서 하는 거 인상 깊었습니다 ㅎㅎ 어제 얘기한 것처럼 람다는 관리 포인트가 늘어날 수 있는데, 나중에 람다 방식 말고 다른 방법은 있는지 같이 고민해봐도 좋을 것 같아요! 수고하셨습니다 😎

[sosow0212]

Suggested change

	) {
	public static ImageCreatedEvent createdPopupsImages(final Long targetId, final List<String> imageNames) {
	) {
	public static ImageCreatedEvent createdPopupsImages(final Long targetId, final List<String> imageNames) {

[sosow0212]

해당 클래스와 더불어 아래 클래스들 만약 Bean이 겹쳐서 그런다면 @Qualiier 처리 해주시거나 별도 config 만들어서 profile 별로 주입 다르게 해줘도 좋을 것 같습니다!
당장은 사용하진 않으니 냅둬도 될 거 같은데 issue 만들어서 나중에 제거할지, 빈에 따라 다르게 할지 처리 부탁드릴게요!

[eom-tae-in]

아 이 부분에 대한 변경 사항을 말씀을 안드렸네요...!
람다를 사용하게 되면서 서버에서 이미지 업로드에 대한 로직이 필요가 없게 되었습니다. 이 부분은 추후에 제거하도록 이슈를 만들어놓겠습니다

[eom-tae-in]

람다 사용에 대해 말씀하신 관리 포인트 부분도 충분히 공감합니다. 추후에 다른 방식으로도 시도해보는 건 좋은 아이디어인 것 같아요.
말씀하신 대로 더 나은 방법이 있는지 함께 고민해보면 좋겠습니다!