randommagic 님의 블로그

기존에는 파일을 AWS S3에 저장하고 있었지만, Egress 요금 부담을 줄이기 위해 Cloudflare R2를 도입해 보기로 했다.S3에 저장되어 있던 파일들을 R2로 이전하는 과정에서는 Cloudflare에서 제공하는 On Demand Migration (Sippy) 기능을 활용했다. (참고로, Cloudflare의 Data Migration 서비스도 고려했지만, 계속 오류가 발생해서 사용하지 못했다.)그런데 내부적인 사정으로 인해 다시 파일 저장소를 R2에서 S3로 되돌려야 하는 상황이 발생했고, 결국 R2에 저장된 파일들을 다시 S3로 옮기게 되었다. 그런데 R2 공식 문서를 읽어봐도 S3-> R2 파일 이전 방법 또는 S3 API에 대해 사용 방법에 대해서는 나와 있었지만, 다시 이 파일들을 ..

현재 상황기존에는 릴리즈 서버쪽으로 가기 전 stage 나 qa서버가 없이 운영하였음그래서 릴리즈 이후에 조그마한 버그가 생기면, 다시 릴리즈를 해야 하는 주먹구구식 운영을 하고 있었다. 그와는 별개로 릴리즈는 아니지만, 실제로 서비스를 릴리즈 전 테스트를 해야 할 상황이 있었고, 별다른 서버가 없었기 때문에 개발서버에 연결시켜서 테스트를 진행하고 있었음, 그런데 개발서버에서는 계속 신규기능을들 개발하고 추가하다 보니, 빈번하게 CICD를 통해 배포되었고, 기존 테스트 버전으로 나간 기기쪽에서 문제가 나는 상황이 발생했다. 결국 문제점을 정리하자면1. 개발서버를 QA로 사용하다 보니, 서버 다운 등의 이슈로 인해 테스트 시연 등이 필요한 상황에서 안정적인 테스트를 할 수 없는 상황이 있었다. 2. 릴리즈..

새 프로젝트에서 api 구성 중 요청에 대해서 400대 응답과 500대 응답에 대해서 다른 방식으로 리턴해야 할 필요가 생겼다.그래서 custom filter를 만들어 error 또는 exception을 상황에 맞게 처리하려고 했음. 일단 모든 exception 을 잡는 filter와, httpexception만을 잡는 filter 2개를 만들었다. // all-exception.filter@Catch()export class AllExceptionsFilter implements ExceptionFilter { catch(exception: unknown, host: ArgumentsHost) { const ctx = host.switchToHttp(); const request = ctx..