randommagic 님의 블로그

Rclone - CloudFlare R2에서 AWS S3로 파일 이전

randommagic — Fri, 9 May 2025 17:20:36 +0900

기존에는 파일을 AWS S3에 저장하고 있었지만, Egress 요금 부담을 줄이기 위해 Cloudflare R2를 도입해 보기로 했다.
S3에 저장되어 있던 파일들을 R2로 이전하는 과정에서는 Cloudflare에서 제공하는 On Demand Migration (Sippy) 기능을 활용했다. (참고로, Cloudflare의 Data Migration 서비스도 고려했지만, 계속 오류가 발생해서 사용하지 못했다.)

그런데 내부적인 사정으로 인해 다시 파일 저장소를 R2에서 S3로 되돌려야 하는 상황이 발생했고, 결국 R2에 저장된 파일들을 다시 S3로 옮기게 되었다.

그런데 R2 공식 문서를 읽어봐도 S3-> R2 파일 이전 방법 또는 S3 API에 대해 사용 방법에 대해서는 나와 있었지만, 다시 이 파일들을 S3로 옮기는 방법에 대해서는 찾지 못했다.

그렇다고 수백수천개 쌓인 파일들을 직접 하나하나 다운받아서 S3에 올릴수는 없는 노릇이라 웹을 더 뒤진 결과.. RClone 이라는 오픈소스 툴을 찾게 되었다.

RClone 은 다양한 클라우드 저장소 간의 파일 이동, 복사, 동기화 등을 지원하는 명령줄 기반의 툴로, S3, R2, Google Drive 등 70가지가 넘는 스토리지 서비스를 지원하고, 특히 대용량 데이터 이전이나 자동화된 작업에 적합하다.

.. 고 하니 써보기로 결정했다.

1. R2 준비

R2 버킷

내 R2 버킷을 준비하였고, 4개의 파일들이 들어있다.

버킷의 설정 - General 메뉴에 들어가자.

S3 API가 https://~~~~.r2.cloudflarestorage.com/버킷명 되어 있을 텐데,

뒤의 /버킷명 을 제거하고 https://~~~.r2.cloudflarestorage.com 부분만 따로 메모장 등에 복사해 둔다.

이제 R2 API Key를 생성해 보자.

R2 메뉴에서 API -> API 토큰 관리 -> Account API 토큰 생성 클릭

적당한 이름으로 설정하고, 권한은 개체 읽기 전용으로.

(만약 R2 버킷이 source가 아닌 target 일 경우 개체 읽기 및 쓰기로 해야 하겠다. 하지만 나는 R2에서 파일을 가져오기만 할 것이기 때문에 읽기 전용)

버킷도 옮길 대상이 되는 버킷을 설정하거나, 혹은 그냥 모든 버킷에 적용을 선택해도 무방하다.

그러면 Access Key ID 와 Secret Access Key 가 나오는데, 다시 보여주지 않으므로 안전한 곳에 따로 저장해 둘것.

2. S3 준비

S3도 파일이 복사될 버킷을 미리 생성해 둔다.

R2에서 API Key를 생성했던것 처럼, S3도 그에 접근 권한이 있는 Key를 생성해야 한다.

일단 IAM 정책 생성 부터.

AWS 콘솔에 접속 후 IAM -> 정책 -> 정책 생성 메뉴로 들어간다.

정책 편집기 우상단의 (시각적|JSON) 중 JSON 버튼을 눌러 다음과 같이 설정해 주자.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::버킷이름/*",
                "arn:aws:s3:::버킷이름"
            ]
        }
    ]
}

마지막으로 이름은 식별할수 있는 이름으로 정한 후 정책 생성 버튼을 눌러 완료.

정책을 생성했으니 이제 이 정책을 사용할 사용자를 생성하자.

AWS 콘솔 에서 IAM -> 사용자 -> 사용자 생성 선택

사용자 이름 정도에 적당한 이름을 넣어주고 다음으로 넘어가자.

물론 여기 설명대로 사용자를 그룹에 넣고 그룹<->권한 연결 해도 될 것 같다.

직접 정책 연결을 누르고, 위에서 생성했던 권한 이름을 검색하고 체크한 후 다음을 눌러 생성한다.

사용자가 잘 만들어 졌다면, 액세스 키 만들기 버튼을 누르고, 사용 사례 - 기타 를 선택 후 액세스 키를 생성하자.

여기에서도 Access Key ID 와 Secret Access Key를 따로 잘 저장해 둔다.

3. RClone 설정

윈도우에서 사용할 거라, Download 페이지에서 Intel/AMD 64비트용 Windows 버전을 다운로드했다.

설치형 프로그램이 아닌 압축 파일로 되어 있어 직접 C:\ 에 rclone이라는 폴더를 만들고 압축을 해제해 주었다.

그 후 cmd창을 열어서 압축 해제한 rclone 폴더로 이동, rclone 명령어가 실행되는 것을 확인하면 일차적인 준비가 완료되었다.

이제 config 설정을 통해서 R2와 S3 remote를 추가해 주어야 한다.

다음의 명령어를 입력하고 요구하는 정보들을 차례대로 넣어 주자..

rclone config

R2 remote 추가

n 입력 → 새 remote 추가
이름 입력 : r2 (알아 볼 수 있는 이름이면 아무거나 가능)
storage : 4
provider : 6 (Cloudflare)
env_auth : false ( enter 눌러서 패스)
access_key_id : 위에서 준비했던 R2의 Access Key ID
secret_access_key : 위에서 준비했던 R2의 Secret Access Key
region : 1 (auto)
endpoint : 위에서 준비했던 Cloudflare R2 S3 API

r2 config

위 처럼 나오면 성공. y 또는 그냥 엔터를 눌러서 완료하자.

이제 이서어 나오는 config 메뉴에서 다시 n을 눌러서 새로운 remote를 추가하자.

S3 remote 추가

n 입력 → 새 remote 추가
이름 입력 : r2 (알아 볼 수 있는 이름이면 아무거나 가능)
storage : 4
provider : 1 (AWS)
env_auth : false ( enter 눌러서 패스)
access_key_id : 위에서 준비했던 S3의 Access Key ID
secret_access_key : 위에서 준비했던 S3의 Secret Access Key
region : ap-northeast-2 (혹은 자신의 버킷의 region)
endpoint : 없음 (enter 눌러서 패스)
이후 자잘한 옵션도 enter 눌러서 패스 해 준다,.

s3 config

이렇게 두개의 remote config 설정이 완료되었으면, q를 눌러 configuration 메뉴를 나오자.

다음의 명령어로 버킷 내부의 파일 목록을 확인해봄으로써 잘 연결되었는지 확인할 수도 있다.

rclone ls r2:버킷이름

4개의 파일이 잘 나온다.

4. Rclone 파일 복사

파일 복사를 위해 사용할 수 있는 명령어는 copy 와 sync 두가지가 있다.

copy

현재 source 버킷에 있는 파일을 복사하고, 이미 있는 파일은 덮어쓰기
source버킷에는 없는데 target버킷에 이미 있는 파일에 대해서는 아무 작업도 하지 않는다.

rclone copy source:버킷이름 target:버킷이름 --progress

sync

현재 source 버킷에 있는 파일을 target에 복사하되, source에는 없는데 target에 있는 파일들은 삭제한다
말 그대로 완전한 '동기화' 시킴으로써, 두개의 버킷에 있는 파일을 완전히 동기화 한다.

rclone sync source:버킷이름 target:버킷이름 --progress

현재 나는 무엇을 해도 상관 없지만, 파일 삭제를 위한 권한은 위에서 주지 않았으므로 copy를 사용한다.

source에는 config 설정때의 r2 remote를 사용하고,

target에는 s3 remote를 사용하자.

파일들이 잘 복사가 되는 것을 확인할 수 있다.

이렇게 R2-> S3 파일 복사 완료!

stage 서버의 도입과 git 전략에 대해

randommagic — Thu, 20 Mar 2025 16:06:10 +0900

현재 상황

기존에는 릴리즈 서버쪽으로 가기 전 stage 나 qa서버가 없이 운영하였음

그래서 릴리즈 이후에 조그마한 버그가 생기면, 다시 릴리즈를 해야 하는 주먹구구식 운영을 하고 있었다.

그와는 별개로 릴리즈는 아니지만, 실제로 서비스를 릴리즈 전 테스트를 해야 할 상황이 있었고, 별다른 서버가 없었기 때문에 개발서버에 연결시켜서 테스트를 진행하고 있었음,

그런데 개발서버에서는 계속 신규기능을들 개발하고 추가하다 보니, 빈번하게 CICD를 통해 배포되었고, 기존 테스트 버전으로 나간 기기쪽에서 문제가 나는 상황이 발생했다.

결국 문제점을 정리하자면

1. 개발서버를 QA로 사용하다 보니, 서버 다운 등의 이슈로 인해 테스트 시연 등이 필요한 상황에서 안정적인 테스트를 할 수 없는 상황이 있었다.

2. 릴리즈 전 일정 기간동안 안정적으로 테스트를 할 서버가 없어서, 개발 도중 잡지 못한 사소한 오류등이 릴리즈 서버에서 발견되어서 재 배포를 빈번하게 해야 했다.

말이 되지 않는 상황이었고, 이에 대해 개선이 필요하다 느낌.

[NestJs] useGlobalFilter 내부 filter들의 순서

randommagic — Mon, 22 Jul 2024 15:59:08 +0900

새 프로젝트에서 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.getRequest<Request>();
    const response = ctx.getResponse<Response>();
    const status = HttpStatus.INTERNAL_SERVER_ERROR;

    response.status(status).json({
      statusCode: status,
      message: 'all exception',
      path: request.url,
    });
  }
}

// http-exception.filter
@Catch(HttpException)
export class HttpExceptionFilter implements ExceptionFilter {
  catch(exception: HttpException, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const request = ctx.getRequest<Request>();
    const response = ctx.getResponse<Response>();
    const status = exception.getStatus();

    response.status(status).json({
      statusCode: status,
      message: 'http exception',
      path: request.url,
    });
  }
}

그리고 이 두개를 useGlobalFilters를 이용해 전역으로 달아주었다.

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalFilters(new HttpExceptionFilter(), new AllExceptionsFilter());
  await app.listen(8000);
}

이때 내 생각은, HttpExceptionFilter -> AllExceptionFilter 순으로 달았으니, httpexception은 먼저 등록되있는 HttpExceptionFilter 에서 잡힐 것이고, 그 외의 것들은 HttpExceptionFilter 를 지나쳐서 AllExceptionFilter 에서 잡히겠지?

요청

GET /

@Controller()
export class AppController {
  @Get()
  getHello(): string {
    throw new BadRequestException();
  }
}

결과

{"statusCode":500,"message":"all exception","path":"/"}

의도적으로 HttpException을 상속받는 BadRequestException을 냈는데, 왜 HttpExceptionFilter에서 걸러지지 못하고 AllExceptionFilter에서 걸리는가?

해결?

공식 문서도 읽었고, 여러 블로그 글들도 찾다, 겨우 찾은 stackoverflow의 글.

https://stackoverflow.com/questions/54727103/nestjs-how-to-pass-the-error-from-one-error-filter-to-another

나중에 등록된 필터가 가장 높은 우선순위를 가지므로, 가장 구체적인 필터는 마지막에 등록하는 것이 좋다.

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalFilters(new AllExceptionsFilter(), new HttpExceptionFilter());
  await app.listen(8000);
}

그래서 이전과는 다르게 더 구체적인 필터인 HttpExceptionFilter를 뒤에 등록하고 나서, 요청을 다시 시도한 결과

{"statusCode":400,"message":"http exception","path":"/"}

의도했던 대로 AllExceptionFilter에서 잡히기 이전에 먼저 HttpExceptionFilter에서 제대로 잡히는 것을 확인할 수 있었다.

useGlobalFilters의 구현 코드를 살펴 보았으나, 역순에 관한 내용을 찾을 수는 없었음..

검색이 부족한가?