신규 프로젝트 백엔드(스프링부트) 개발중인데,
인증 서버만 분리된 유사 MSA 구조인데, 내가 개발하는 프로젝트 서비스는 그거 제외하고
그냥 모노리스임.
서비스 이용자만 따로 인증 서버에서 발급해준 permissions 에 서비스 이용 권한 없으면
서비스 이용권한 획득하게 api 따뒀고, 해당 서비스 이용자가 파일을 올리고 뭐 그런 서비스임.
파일을 S3 에 올리고,
버킷, 키값, 누가 올렸는지 언제 올렸는지 이런거는
DB(MySQL) 에 따로 입력해서 관리하게 테이블 짜뒀고,
이 경우 회원이 탈퇴하는 경우에
S3에 올린 데이터도 같이 전부 지우려고 하는데
JPA에서 연관 관계 자체로 데이터베이스 정보 지우는건 상관없는데
이 때 S3에도 콜을 날려서 전부 지우려고 했어.
@PostRemove 뭐 이런걸 이용할까 했는데
S3 관련 객체가 엔티티에 필드로 들어가야해서 이게 맞나 싶기도 하고 해서 다른 방법 찾고있거든
S3 에 파일 올릴때 버킷 파티셔닝 고려해서
파일 업로드 시 랜덤 UUID 를 생성하고, UUID의 첫글자와 두번째 글자를 각각 파티셔닝 값으로 쓰고있는데
예) 파일 uuid 가 e7***... 이런 식이면
prefix/e/7/e7***.확장자 이런식으로 저장하고있어.
차라리 서비스 이용자 식별키도 UUID 인데 이걸 기준으로 파티셔닝하고
사용자 id 로 최종 디렉토리를 s3 버킷에 생성하고 이걸 delete 서비스에서 그냥 날리는게 나을까?
예) 사용자 uuid 가 ab*** 이면
prefix/a/b/ab***/사용자가올린파일들
이런식으로 구성시켜서 서비스 사용자가 서비스 탈퇴 시에 컨트롤러에 연결된 서비스단에서 아예 prefix/a/b/ab*** 이거만 통째로 날려버리는거임.
딱히 이거다 하는게 잘 안떠올라서 질문해봅니다.
사용자 아이디로 디렉토리 구조를 만드는건 좀 별로같은데 파일 구조와 비즈니스 구조는 별도로 가져가는게 좋음 그런식으로 처리하다간 또다른 비즈니스 논리에 의해 디렉토리 구조가 달라져야하는 경우가 생길걸?
s3 디렉토리 삭제 api가 어떻게 동작하는지는 잘 모르겠는데, 수행 시간이 길수도 있어보임 비동기로 동작하는 탈퇴 후처리 서비스를 하나 만들고, 거기서 파일 하나하나 삭제를 하는게 어떨지? 탈퇴 버튼 눌렀을때 한번에 처리하는건 무리수임