개발과 일상

개요저번에도 언급했지만, 구글 드라이브와 같은 파일 저장소 서버를 계속 개발하고 있다. 올 4월 전시회 출품하는 단계까지는 개발을 완료했지만, 우려되는 부분이 많아서 고민들 중 하나를 정리해보려고한다. 가장 걱정되는 부분 중 하나가 업로드다. 현재 구현 방식에는 문제가 있을 수밖에 없다. 이전 글도 사실 파일 업로드를 어떻게하면 효과적일지에 대한 고민을 하면서 작성한 글이었다. MultipartFile에서 부터 찾아들어간 Multipart/form-data 전송 방식. 그리고 chunked 업로드 그리고 결론부터 말하면, 내가 고민한 것에 대한 정답은 이미 나와있었고 의외의 곳에서 힌트를 얻었다. 문제점현재 서비스의 업로드의 가장 큰 문제는 서버가 파일 업로드/다운로드를 중개해준다는 것이다.사용자 ..

개요사실 로그 파이프라인은 인프라 초기 설계 단계에서 함께 고민했어야 했지만, ECS 기반 인프라를 구성할 당시에는 방법을 몰라 한동안 손대지 못하고 있었다. 그 대신 임시 방편으로 로그를 데이터베이스에 저장하고, 단순히 스택 트레이스를 확인할 수 있게만 만들어둔 상태였다. 하지만 로그를 DB에 저장하는 방식은 여러모로 바람직하지 않다.첫째, 서비스 로직에 필요한 DB 커넥션 풀을 로그 기록 때문에 점유하게 된다.둘째, 불필요한 DB I/O가 발생해 비용 낭비로 이어진다.셋째, 로그는 개발자나 운영자를 위한 정보인데, 이를 위해 운영 데이터 저장소의 용량을 소모하게 된다.그리고 마지막으로, 검색과 필터링도 DB 쿼리로 해야 하기 때문에, 로그 시스템 고유의 장점인 빠른 탐색/집계 기능을 기대하기 어렵다...

개요현재 프로젝트에서 파일 저장소로 S3를 사용하고 있다. 파일을 저장하면서 몇 가지 요구 사항이 붙게 됐다.  1. 업데이트를 하면 파일이 새로 업로드됨2. 그런데 업데이트 하기 전 파일로 롤백하려는 요구 사항이 있을 수 있음3. 그럼 업데이트된 파일을 어떻게 관리할 것인가? 사용하지 않는 파일에 아이디를 일일히 부여하는게 맞는가? 그럼 로우가 계속 늘어날텐데?4. 그러면 삭제 정책이 필요한데, 얼마나 저장할 것이며 어떻게 삭제할 것인가? 스케줄러를 돌리는 것도 말이 안되지 않나? 이런식으로 계속 꼬리질문이 나오는 상황에서 S3를 뒤져보던 중 객체 버저닝이란 것을 알게 됐다.https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/versioning-w..

문제 상황FE에서는 그동안 CloudFront URL로 만들어진 이미지 URL을 BE로부터 전달 받아서 img 태그에 넣어주기만 했었다. 그런데 이번 개선으로 이미지를 다운로드를 받아서 사용할 일이 생겼다. 그런데 웬걸 CORS 에러가 발생하기 시작했다. FE에서는 fetch를 이용해 이미지를 blob형태로 받으려 했고, 이 과정에서 CORS가 발생했다고 한다. 이 문제의 원인을 찾아가는 과정이다. 문제 분석1. CloudFront에서 특정 HTTP Method를 막아놨나?- 이전에 CloudFront로 POST 요청이 필요한 경우가 있었는데, 이 Method가 막혀 있을 때 비슷한 에러가 났었다.그러나 fetch는 GET 방식이고, CloudFront에서 GET 방식은 무조건 열려있다.  2. S3의 ..

S3를 퍼블릭으로 관리하게 되면서, 파일을 주기적으로 지워야하는 정책이 추가됐다. S3에서는 다행히 주기적으로 파일을 삭제하는 기능이 있다. 바로 수명 주기 규칙이다. S3 > 버킷 > 버킷 선택 > 관리 > 수명 주기 규칙 생성으로 들어간다.  수명 주기 규칙은 알아보기 쉽게 짓고, 내 목적은 파일 전체를 지우는 거기 때문에, 버킷의 모든 객체 적용을 선택. 그리고 이전 버전 영구 삭제를 하루로 설정한다.  다만, 수명 주기 규칙 생성은 최소 단위가 1일이다. 이 간격을 더 짧게 만드는 가장 쉬운 방법은 람다나 서버에서 스케줄러를 돌려서 주기적으로 데이터를 지워주는 방식이다. 심플하지만 재미없는 방식이다. 조금 색다른 아이디어를 내보자면, S3에 저장된 객체만 퍼블릭하게 접근할 수 있는 시간을 지정할 ..

온라인에서 문서를 PDF로 변환하는 프로젝트를 진행 중이다. 가장 큰 걸림돌이라 예상됐던, PDF 변환 솔루션은 다행히도 잘 동작하고 있다. (몇몇 확장자는 지원한다더니 안되지만 말이다) 문제는 사용자에게 파일 크기가 큰 파일을 어떻게 사용자에게 전달할 것인가? 였다. 가장 먼저 떠오르는 방식은 Base64나 ByteArray로 변환하고 FE에서 파일로 변환하는 거였지만, 사용자가 요청하는 파일 크기가 커진다면 응답의 크기가 얼마나 커질지 알 수가 없다. 이런저런 방법을 알아보다가 퍼블릭한 S3를 만들어서 S3 경로를 던져주고 PDF 뷰어는 브라우저에게 맡기는게 가장 손이 덜 가는 방법이라는 결론을 짓게 됐다. 퍼블릭한 S3 버킷를 만드는건 어렵지 않을거라 생각했다. 왜냐면 생성할 때 주는 옵션이 있기 ..

현재 서비스는 대부분 Java/Kotlin으로 구현되어 있어 갑자기 진행된 Python 프로젝트를 어떻게 배포할까에 대한 고민이 있었다. 스케줄러로 하루에 한번돌기 때문에 부담은 없지만, 내부 패키지를 많이 사용하는 프로젝트다. 대략 3가지 방안이 논의됐다. 1. AWS Lambda에 배포 2. Spot EC2에 배포 3. 쿠버네티스 컨테이너에 배포 DB를 따로 사용하지 않기 때문에, 1번 방안부터 알아봤다. 결론부터 이야기하면, 해당 프로젝트에 이미지 프로세싱이 들어가있어서 AWS Lambda는 후보군에서 바로 제외됐다. 그래도 serverless 프레임워크를 써서 파이썬 Lambda를 생성해봤기 때문에 정리하고 넘어가려고한다. python만의 특이한 옵션들이 있어서 프로젝트 생성/관리에 조금 어려움이..

이전 글들은 이 글을 쓰기위한 빌드업이 었다. 1. AWS S3와 CloudFront 연동 끝까지 가보기 2. WSL/WSL2에 Go(Golang) 설치하기 3. Go + serverless framework로 Lambda 관리하기 4. 꼭 읽어줬으면 하는 AWS Lambda@Edge의 특이 사항들 정리 개인적으로는 Lambda@Edge를 시작하기전에 4번은 꼭 훑고 갔으면 좋겠다. 1번 글의 마치며에서도 언급한 내용이지만, 이미지가 아직 CloudFront(CDN)에 등록되지 않았을 경우 첫 로딩에 문제가 발생할 수 있다. 그리고 그 문제는 이미지의 크기가 커질수록, 더 커질 것이다. 그래서 이미지의 사이즈를 작게 만드는 과정이 필요하다. (리사이징이든, 확장자 변환이든 여러가지 방법이 있다) 하지만 ..