개발과 일상

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)에 등록되지 않았을 경우 첫 로딩에 문제가 발생할 수 있다. 그리고 그 문제는 이미지의 크기가 커질수록, 더 커질 것이다. 그래서 이미지의 사이즈를 작게 만드는 과정이 필요하다. (리사이징이든, 확장자 변환이든 여러가지 방법이 있다) 하지만 ..

앞서 이야기했지만 Go도 알아야되는 상황이 됐다. 그 이유는 Go로 개발한 Lambda가 있기 때문이다. 아무것도 몰라서 바닥부터 머리를 박아가면서 알게된것들이 많다. Go로 Lambda를 개발할 때 주의할 점이 몇가지 있다. 1. yarn이나 npm 같은 패키지매니저가 없어서 makefile을 이용해 빌드 방식을 관리한다. 2. 올해(2024년)부터는 runtime을 go 1.x보다 Amazon Linux 2를 사용하길 권장한다. 3. binary를 생성하고, Amazon Linux 2에서 사용되는 bootstrap으로 람다에 배포해야한다. 참고자료 : https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/golang-package.html 추가적으로, Go의 함수..

AWS S3는 저장하는 건 저렴한데, S3에 직접 엑세스하는건 비싸고 느리다. 그래서 CDN을 이용해 캐싱을 많이하는데, AWS에서는 CloudFront 서비스를 이용해서 CDN을 사용할 수 있다. CloudFront란? Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됩니다. AWS에서 사용하는 기능이니 고가용성은 기..

이전 글에는 문제가 있다. 현재 DDB Table에는 이미 3천개 이상의 데이터가 쌓여있고, 앞으로 꾸준히 데이터가 쌓일 예정이다. 그런데 조회 쿼리 ScanCommand를 사용했다. 이 조회 방식은 언젠가 문제를 일으킬 것이다. 어떤 문제인지는, AWS의 DDB 스캔 사용 모범사례를 보면 알 수 있다. 일반적으로 Scan 작업은 DynamoDB의 다른 작업보다 비효율적입니다. Scan 작업은 항상 전체 테이블이나 보조 인덱스를 스캔합니다. 그런 후 값을 필터링하여 원하는 결과를 얻기 때문에 결과 세트에서 데이터를 제거해야 하는 단계가 추가됩니다. 가능한 경우, 대용량 테이블 또는 인덱스에서 필터를 사용해 다수의 결과를 제거해야 하는 경우에는 Scan 작업을 최대한 피하는 것이 좋습니다. 여기에 테이블이..

상용 배포를 앞두고, dev 서버에서 잘 동작하던 Lambda에서 문제가 발생했다. Dynamo DB(이하 DDB) 조회해서 데이터의 존재여부를 검증하는데, 분명 조회 데이터가 존재하는데도 Count가 계속 0으로 찍히는 문제였다. dev에선 분명히 잘 동작했고 prod에서도 에러가 나지 않았기 때문에, 오류를 찾기가 너무 힘들었다. 커넥션이 올바르게 되고 있는지부터 쿼리가 올바른지, 로직에 문제가 없는지 다 검증해봤는데, 의외의 곳에서 실마리를 얻었다. prd DDB에 저장된 데이터는 3000개 이상이었는데, 위 조회 방법으로 조회하니 ScannedCount가 709개로 나왔다. 여기서부터 문제가 있음을 인지하게 되었다. 조회 쿼리를 날렸을 때 결과물이 아래와 같이 나왔다. { '$metadata': ..