AWS S3 이전 작업

😕AWS S3이전 작업이란 무엇인가?

경매야는 BtoC 플렛폼으로 회사 또는 공인중개사가 경매 물건을 등록하게 된다. 경매야 프로젝트 적은 인원과 약 2달 반이라는 시간이라는 짧은 기한 안에 진행한 프로젝트로 기능의 선택과 포기를 했어야 했다. 포기한 기능중 하나가 등록 물건의 이미지 또는 문서를 관리하는 서버를 제작하는 것이였다. 당시에는 파일을 관리해야 하는 서버를 따로 구축을 해야한다는 결론이 나왔기 때문에 차 선택으로 서버 내부에 파일시스템 구조로 파일들을 관리를 하기로 결론을 내렸다. 하지만 서비스 오픈 이후 등록 물건의 증가와 관리자 페이지의 필요성, 공인중개사 페이지 제작을 고려해서 더 이상 파일시스템 기반의 관리가 어려워서 파일 데이터를 위한 서버를 개발하기로 했다. 기술 검색을 하니 대부분의 서비스들이 AWS S3 기반의 파일 서버를 운영 한다는 것을 알게 되었고, 처음으로 AWS서비스를 사용한 개발을 하게 되었다.

🌈개발리소스

투입 인력

• FE개발자에서 Fullstack지향 개발자로 전향한 1명

개발소요기간

• 2021-05-01 ~ 2021-05-21(약 3주)

기술스텍

• AWS S3
• AWS Lambda(Node.js)
• AWS CloudWatch
• Serverless Framework
• Nest.js(API)
• Nexus.js(GraphQL)
• TypeScript

💬서비스 설계

필요 기능

1. 이미지(파일) 업로드(create)
2. 이미지 업데이트(update)
3. 이미지 삭제(delete)
4. 이미지 링크 FE서버에 제공(read)
5. 이미지 용량 제한
6. exif orientation값에 대한 브라우저 별 다른 이미지 회전 처리 이슈 해결
7. 물건 상세 이미지 우선순위

문제 해결 과정

개발 기능 선별

• 이미지 업로드 기능은 여러 파일 업로드를 제한하고 단일 파일업로드로 제한한다.
• 이미지 업데이트는 삭제, 업로드 기능으로 대체한다.
• 이미지 삭제는 단일 삭제로 제한한다.
• 여러 파일 업로드 또는 삭제 기능은 FE에서 단일 처리를 다중 처리 처럼 보이게 구현한다.
• 이미지 용량은 5MB로 제한한다.
• 이미지 회전 문제는 S3 trigger 기능으로 exif값을 제거하고 이미지를 회전 시켜 png 타입으로 재 업로드 시킨다.
• 물건 상세 이미지 우선순위는 이미지 별로 메타데이터에 기록을 하는 방법을 생각 했지만 우선 순위 변경시 관리가 어렵다는 점, 필수 요구 사항이 아닌점을 고려해서 배제했다.

S3 버킷 구조 설계

버킷은 staging과 production으로 나눴다. 버킷 최 상단에는 auction, sale, banner, default로 나뉘었고, 그 내부는 각각의 id로 구분 했다.

• 버킷 구조
  

• default구조
  

파일 업로드 설계

• S3에 이미지를 업로드하고 삭제를 히려고 하면 IAM키가 필요하다 그럼으로 FE에서 직접 S3 접근하는 방식은 채택 할 수 없었다. 또한 관리자 또는 공인중개사 라는 특수 권한에 대해서만 기능을 제한해야 했기 때문에 client가 BE서버로 파일을 보내고 S3에 업로드를 대리해주는 구조를 생각 했다.
  
• 하지만 위의 같은 구조는 BE Server에 부화를 준다고 판단을 했다. 그럼으로 AWS API Gateway와 AWS Lambda를 사용해 대신 파일을 업로드 해주는 구조를 생각 했다.
  
• 위와 같은 구조도 처음의 구조의 문제를 해결 하지 못한 부분이 있었다. 바로 파일이 쓸데 없이 하나의 서버를 거처야 한다는 부분이다. 이는 통신에 있어서 비효율적이고 시간이 더 걸릴 수 밖에 없었다. 그래서 개발 커뮤니티에 해당 문제를 질문했다. 열무라는 분이 pre signed url이라는 방식을 제안해주었다. 이 방식은 약속된 규칙으로 서명이된 url을 통해 FE에서도 키 노출 없이 파일을 업로드를 할 수 있는 방식이였다. 나는 정말 충격을 받았다. 왜냐하면 FE에서는 키가 노출되기 때문에 절대 S3에 파일을 업로드 할 수 없다고 생각 했다. 나 나름 긴 시간을 고민하고 팀원들에게도 공유했지만 이런 방법도 있었다니...
  

이미지 링크 제공 기능

이미지 링크는 FE에서 물건과 베너관련 랜더에 필요 했다. AWS Lambda를 사용해서 이미지의 링크를 제공하는 API를 제작 할까 고민 했지만, FE에서는 요청을 두번 해야 하는 상황이 발생 하기 때문에 기존 Nest기반 API와 Nexus기반 GraphQL에 같이 보내주는 방식으로 제공 했다.

😂어려웠던점

• s3 trigger구현을 위해 serverless framework를 이용해 코드 배포를 했는데 처음 사용하는 프래임워크라 어려웠다.
• 예기치 못한 이유로 이미지가 업로드 되지 않았을 때의 상황에서 defualt처리와 bucket의 구조 설계에 고민을 많이 했다.
• 파일 업로드의 최적의 방법을 찾으려고 노력을 많이 했다.
• 처음 접해보는 AWS생태계의 꼬리에 꼬리를 무는 연관 기술들을 습득하는데 정말 힘들었다.(s3... lambda... ApiGateWay ...cloudWatch 등등)
• s3 트리거가 루프를 도는 현상을 해결하는데 힘들었다.
• exif 가만 안두겠어....

😎느낀점

• AWS Lambda에 대한 기술을 검색하면서 유튜브에 빙글 이상현
  님의 serverless 강연을 보게 되었는데 너~무나 신선한 충격을 받았다. BE서버를 구축하기 위해서는 express, spring 같은 프래임워크를 사용하는 방식만 생각했는데 서버를 micro 단위로 쪼개 서비를 재공한다는게 정~말 신선했다. AWS의 생태계를 격어보면서 개발자로서의 시야가 넓어지는 계기가 되었던것 같다.
• 파일 업로드 기능을 구현하기 위해 며칠을 고민을 했는데, 커뮤니티에 질문 하나로 모든 고민을 해결 할 수 있던 경험으로 역시 개발자는 넓은 세상에서 개발을 해야하지 않을까...
• Nest.js와 Nexus.js를 사용해서 기능을 개발 했는데 BE프래임워크에 친해 질수 있는 기회지 않았나 생각했다.