개체 스토리지
이 전에 국비 교육을 들었을 때 실무자 평가 때, ‘클라우드 객체 스토리지’ 사용에 대해 질의를 받았던 적이 있습니다. 사실 생각하지도 않았습니다
- 사용자가 무단으로 데이터를 올리는 건 어떻게 처리하나?
- Nginx에서 송수신 크기는 알고 있나?
- 누구나 볼 수 있다면 문제인데 이는 어떻게 처리했나?
당시에는 제가 담당하지 않아서 생각하지 않았는데, 까이고 보니 좀 더 깊게 생각해볼걸 그랬나 싶습니다.
저 질문을 하나도 답변하지 못하겠더라고요
저의 장점이자 단점은 실패에 대해 확실히 기억한다는 것입니다. 우선순위가 밀릴뿐이지 언젠가는 다시 도전한다는 점이지만, 너무 실패에 자책한다는 점이 싫기도 합니다.
아무튼 이 부분에 대해 하나씩 풀어서 뜯어보겠습니다.
사용자가 무단으로 데이터를 올리는 건 어떻게 처리하나?
이건 Presigned URL 방식을 여쩌보는 거 였습니다.
S3를 처음 쓰는 입장에선 이 개념이 전혀 없었습니다.
당시에는 처음 도입하는지라 그냥 ‘클라이언트’ -> ‘서버 전송’ -> ‘S3에 업로드’로 팀원끼리 생각하고 있었기 때문입니다.
이러한 방식은 단순한 모든 파일을 public으로 규칙을 설정하는 데 다음과 같은 장단점이 있었습니다
- 장점 : 별도의 관리가 필요없음
- 단점 : 아무나 파일 업로드/다운로드 가능
초보자 입장에선 정답에 가까웠지만, 실무자 입장에선 꽝에 가까운 답이였나봅니다.
Presigned URL이란?
- 사용자가 S3에 대한 접근 권한을 받기 위해 인증 후 올릴 수 있는 ‘미리 서명된 권한’을 발급받는 구조입니다.
쉽게 말하면 임시 권한을 발급 받는데 이는 일정 시간이 지나면 만료되는 URL입니다.
- 파일에 접근 가능한 임시 URL 생성
- 지정한 사람만 공유 가능
- URL의 만료기간 설정 가능
- POST, GET 등 메소드 설정 가능
진짜 좀 알려주면 좋을텐데 개발자들은 직접 생각하게 하는 귀찮음을 교육 과정에서도 듣고 있는다는 것이 기분이 별로 좋진 않네요.
다른 대학의 친구들도 딱히 생각해본 적 없었나봅니다. 인프라가 할 일이라 그런가..?
Nginx에서 송수신 크기는 알고 있나?
- 1MB
이건 client_max_body_size로 크기 조정할 수 있다는데, 클라이언트한테 Presigned URL 던져주고 업로드 하는 형태로 교체했습니다.
굳이 크기 늘려서 서버 부하의 가능성을 줄 필요는 없더라고요.
이것 생각하니 게시글 최대 수도 계산해서 50만자 정도로 제한해둬야할 거 같습니다.
장점은 운영 서버 부하가 줄어든다는 점이고, 단점은 비동기 검증 로직을 추가해야한다는 점이네요.
- 속도나 안정성 측면은 후자이니 때문에 코드 복잡성은 늘어나도 이후로는 public으로 박는 짓은 안하고 있습니다.
누구나 볼 수 있다면 문제인데 이는 어떻게 처리했나?
이것도 결국 Presigned URL이 정답이더라고요.
그냥 실무자가 S3 썻다길래 기대하면서 Presigned-URL 썻는 지 코드 보고, 안써서 실망해서 물어본 거 같습니다.
TIP개체 스토리지, S3에 대해 물어본다면?
- Presigned URL을 생각하자
- 아, 저는 비용 절감상 R2 쓰고 있는데 동일하게 S3 기반이여서 Presigned URL은 구현할 수 있습니다.
- 혹여나 S3만 된다 생각한다면 그건 아니라고 말씀드립니다. GCP나 Azure은 잘 모르겠습니다.