작성자 : 김다희
이미지를 현재 S3에 올리고 있고 S3에 올라간 이미지 경로를 받아서 데이터베이스 이미지 필드에 TEXT값으로 저장하고 있다. 그리고 이미지를 수정할 수 있는 기능을 제공한다. 이미지를 수정할 때 새로 올라간 이미지의 S3 이미지 경로를 받아서 데이터베이스 이미지 필드를 update한다. 그럼 이전 이미지는 어떻게 관리해야할까? 크게 3가지 방식이 있을 것 같다.
- 이전 이미지는 관리안함.
- 이 방식은 너무 위험한 것 같다. 이전 이미지는 영영 지울 수 없는 상태가 된다.
- 수정 요청이 오면 이미 S3에 올라간 이미지를 삭제하고 새로운 이미지를 업데이트 한다.
- 유저의 정보가 물리적으로 즉시 삭제되는건 위험한 요소들이 있다.
- 위험 요소 1 : 장애 또는 버그로 원치 않는 데이터가 삭제된다.
- 수정 요청이 오면 이미 S3에 올라간 이미지 정보를 별도의 테이블에 데이터를 저장하고, 새로운 이미지를 업데이트 한다. (소프트 딜리트)
- 데이터가 즉시 삭제되지 않기때문에 위험 요소가 줄어든다.
- 별도 테이블에 저장된 데이터는 서비스 트래픽이 많지않는 시점에 배치 처리로 지울 수 있다.
3번 방식을 채택해보자.
왜 소프트 딜리트를 해야할까?
현 시점에서는 2번을 채택해도 큰 문제는 없을 것이지만 3번 방식을 채택한다면
- 비즈니스 로직을 더 깊게 생각해볼 수 있을것 이고
- 트랜잭션을 어떻게 묶어야할지도 고민할 수 있다.
- 더 나아가 배치처리까지 해볼 수 있다.
때문에 이번 프로젝트에서는 소프트 딜리트를 채택한다.
그럼 어떻게 소프트 딜리트를 처리할 수 있을까?
현재 소프트 딜리트로 관리되어야 하는 리소스는 아래와 같다.
- series table - thumbnail field
- article table - thumbnail field
- user table - profile field
그리고 이 데이터들이 업데이트 요청이 왔을 때 수정되기 전 데이터를 관리하는 테이블을 만들자.
- 이 테이블의 역할은 데이터들의 임시 휴지통 테이블이라고 생각하자.
테이블은 필드 1개당 1개여야할까? 그럴 필요는 없을 것 같다.
- 분리수거까지는 필요없다.
그럼 테이블에는 어떤 필드들이 필요할까? 아래와 같은 데이터가 필요할 것 같다.
처음 생각한 Entity
처음 생각한 Entity(Version 1)
- 유저 아이디
- S3 imageKey
- ImageStatus(는 현재 2가지로 정의한다.)
- created - S3에서 물리적인 삭제가 되지 않음. (물리적인 삭제 대기상태)
- deleted - S3에서 물리적으로 삭제됨.
- S3에서 물리적인 삭제가 되었는데도 deleted 상태로 데이터를 가지고 있어야할까?
→ 데이터가 잘못지워졌을수도 있다.
→ S3 sms 는 특정 기간동안 자체 백업이 가능하다.
- ImageName
- hard_delete_date
처음엔 위와같이 Entity를 설계했는데,
현재는 프로젝트에서 관리하는 리소스가 image만 있기때문에 상관없겠지만, 관리해야하는 리소스가 text file과 같은 파일까지 관리되어야 한다면 위 테이블은 취지에 맞지않게된다. 이미지가 아닌 어떤 파일이 오더라도 가능하게 다시 설계를 생각했다. 즉 관리되어야하는 리소스를 추상화해서 다시 생각했다.
다시 생각한 Entity(Version2)
- domainId
- userId
- S3 fileKey
- Status
- DomainType
- FileCategory
- FileType
- softDeleteDate
- hardDeleteDate
변경된 부분으로는
- 이미지로 네이밍했던 부분을 file로 변경했다.
- 유저 아이디를 추가해서 유저별로 데이터를 관리할 수 있도록 했다.
- 도메인에 대한 정보를 추가해서 도메인별로 관리될 수 있도록 했다.
- 도메인 엔티티 아이디를 추가했다.
- 도메인 타입을 추가했다.
- 파일에 대한 메타데이터를 추가하고, 파일정보별로 관리될 수 있도록 했다.
- 파일 카테고리를 추가했다.
- 파일 타입을 추가했다.
- 리소스 상태를 관리할 수 있도록 했다.
- CREATED - 물리적 삭제 x
- DELETED - 물리적 삭제 o
- 유저가 삭제를 요청한 날짜를 추가했다.
- 물리적으로 S3에서 지운 날짜를 추가했다.
처음에는 이미지만 관리하던 테이블이였다면
개선을 통해 파일을 관리하는 테이블이 되었고,
유저 / 도메인 / 파일 정보에 따라 유의미한 데이터를 관리할 수 있게 되었다.
+ 해당 테이블은 어떠한 테이블과도 연관관계를 맺지않는다.