5분 브리핑 (1차)

1. 문제 정의 (Why)

저희와 같은 신입개발자가 취업을 하기위해 부단한 노력을 하는데 도움이 되도록
이력서를 튜터님과 같은 선임개발자에게 피드백을 받으면 좋겠다
라는 생각으로 프로젝트를 진행하게 되었습니다.
이에 저희는 이력서를 업로드하여 저장하는 부분이 필요하게 되었고 제가 담당하였습니다.

2. 해결 방법 & 기술 선택 (How)

DB에 파일을 직접 올리는 것도 하나의 방법이겠지만,
성능저하, DB 관리와 개발, 배포의 복잡성 그리고 보안과 접근제어의 문제 등 이유로
직접 저장하지 않는 것은 개발자 사이에서 널리 알려져 있습니다.

따라 저는 저장 서비스 기술을 이용해야 했고
AWS S3, Google Cloud Storage, Azure Blob Storage 중
가장 대표 되는 AWS S3 기술을 사용하기로 했습니다.

이 기술을 선택한 이유는 사용비용에 대한 저렴함과 저장 할 수 있는 데이터가 무한하다고
평가 받는 걸 알았고, 데이터에 보안에 다양한 기능을 제공하며
전 세계 어디서나 데이터를 손쉽게 업로드 및 다운로드를 할 수 있기에
추후 확장성도 고려하여 선택하게 되었습니다.

3. 구현 내용 설명 (What)

먼저 properties에서

aws.s3.bucket=spring6th-feedprep
aws.credentials.access-key=${FEEDPREP_ACCESS_KEY}
aws.credentials.secret-key=${FEEDPREP_SECRET_KEY}

제 버킷이름를 설정하고 액세스키와 시크릿키는 인텔리제이의 환경변수로 입력 받도록 설정 했습니다.

그다음 S3폴더를 하나 만들고 Config와 Service,ServiceImple 클래스를 각각 만들었습니다.
서비스를 나누어 놓은 이유는 현재는 업로드와 삭제만 기능 구현 했지만 추가적인 기능 구현 할 수 있으니
확정성을 위해 나누어 뒀습니다.

Config는 Region.AP_NORTHEAST_2를 사용해 지역을 서울로 설정하고 액시스키와 시크릿키를 넣어 작성했습니다.

ServiceImpl에는 먼저 private 메소드로 getBucketName() 설정해서 버킷이름을 설정해주고
uploadFile()와 deleteFile() 메소드를 구현하였습니다.

uploadFile()에서는 파일명 중복 방지를 위해 UUID.randomUUID() 기능을 사용하여 원래 파일명과
합쳐서 새로운 파일명을 만들어서 S3에서는 키값으로, DB에서는 파일명으로 저장하였습니다.

deleteFile() 같은 경우 비동기 어노테이션(@Async)을 사용하여, 제가 문서 삭제 기능 구현 할때
문서 삭제 기능를 먼저 처리하고 추후에 AWS S3 파일이 삭제하여 빠른 응답을 가능하도록 만들었습니다.

4. 결과와 효과 (Impact)

해당 이미지의 파일명은 'test-image-20'이며 이것을 postman을 이용하여
S3에 업도르 되었는지 확인 할 것이다.

데이터가 잘 업로드 됬었음을 알 수 있다.

또한

데이터가 삭제가 되는 것도 확인 할 수 있다.

이렇게 데이터가 저장되었으니 피드백 신청 기능을 이용해서
튜터가 취업생의 이력서를 확인 할 수 있는 저장소를 만들 수 있게 되었다.

5. 회고 (Reflection)

1. 파일 업로드 기능을 만들때 UUID.randomUUID() 기능을 처음 써 보았는데, 무한의 가까운 랜덤한 값을 얻을 수 있다. 이것을 파일명칭과 조합해서 중복가능성이 매우 희박한 새로운 파일명칭으로 만들어서 파일을 명칭으로 관리 할 수 있었다.

2. 파일 삭제 기능에 비동기 어노테이션(@Async)을 사용하여 DB에 먼저 삭제 후 S3에서 파일 삭제를 기다리지 않고 바로 완료 됬음을 표기하게 만들 수 있었다. 하지만 실제로 S3 파일 삭제가 실패하는 일이 발생 했는데, 표기에는 파일삭제가 완료되었다고 뜨고 실제 DB에서도 데이터가 삭제 되었지만, S3에 파일이 남은 현상이 발견하여서 이것을 어떻게 처리해야 하는지 추후 생각해야 할 과제가 되었다.

3. S3에 파일 업로드는 잘 되지만 파일 삭제는 안되는 이상한 상황이 발생했다. 발생 시점 전날에는 분명 잘 작동해서 삭제된 것을 직접 S3에서 확인까지 했다. 이유를 모르겠어서 여러가지 방법을 찾아보았다. AI에게 물어보기도 하고 AWS 공식 문서를 보기도 하고 튜터님에게 물어보았지만 비슷한 것조차 찾을 수 없었다. 그렇게 한동안 고민하다가 비슷한 상항을 다른 개발자도 하지 않았을까 생각에 이르였고. 하나의 블로그에서 해답을 찾을 수 있었다. 다른 팀원 한명이 실수로 properties에서 액시스키와 시크릿키를 환경변수로 안쓰고 직접 넣어 사용해서, 이것이 깃허브에 올라갔고, AWS에 발견되어 즉각 정책 부과 처리를 해서 삭제 기능을 막아둔 것이였다. 나는 급하게 IAM에서 기존 액세스키를 파기하고 새로운 액세스키를 발급한다음 부과된 정책을 삭제하여 S3 파일 삭제 기능을 복구 할 수 있게 되었다.