너무 느리다.

진짜 개느리다.

몇일 후 출시 예정인데, 사용자가 화병나서 사용 안할것같은 느낌이다.

어느정도냐면

이 화면에서 개 산책 동호회, 공개 동호회 테스트 이미지를 불러오는데 0.5초~1초 정도 걸린다.
출시..할 수 있을까?(😅😅😅😅)

원인분석

지금 현재의 구조는

DB 에 presinged url 을 저장후 , Get api가 호출 되는 경우마다, 저장된 presigend url을 던져주는 구조.

하지만 !! 이 presigned url은 말그대로 Presigned , 영속한 값이 아니다.
알고보니, 전 팀원께서 이 url의 유효기간을 7일로 설정해두었던것.

ExpiredAt = 7days .. 

그래서, 7일 뒤에 만료 된 Url로 접근하는 경우가 생겼고,

이에 대한 해결책으로 DB에 s3 presigned url을 저장하는것이 아니라, 영속한 값인 s3key를 저장하게 되었다.

URL 형태가 아니라

s3://eum-voice-staging/voice/club/8/seed-club-8.m4a

이렇게 s3key형태로 저장후, Get api가 호출될때마다 Global interceptor가 해당 s3key값으로 URL을 만들어 반환하는 구조로 구현이 되어있다.

return next.handle().pipe(
      mergeMap(async (data) => {
        const payload = data === undefined ? ({} as unknown as T) : data;
        const transformedPayload =
          await this.s3ObjectUrlService.transformClientUrlFields(payload);

        return {
          resultType: 'SUCCESS' as const,
          success: { data: transformedPayload },
          error: null,
          meta: {
            timestamp: new Date().toISOString(),
            path: req?.originalUrl ?? req?.url ?? '',
          },
        };
      }),
    );

위의 코드에서처럼 transformPayload를 통해서 url을 매번 Global intercetptor로 생성해준다.

해결 ?

하지만 이 구조가 절대 해결책이 아니었다는 사실 ㅋㅋ ..

(이것때문에 DB Reset, 데이터 전부 밀었는데 헛수고였다🥵🥵)

오히려 더 비효율적이게 되었다.

그 이유는 Get api를 호출할때마다 다른 url이 발급되어서 , 프론트엔드에서의 캐시 효율이 매우 떨어지게된것이다.

프론트엔드에서 가지고있던 Url과 값이 달라 항상 miss되어, 매번 새로운 url로 이미지를 다운로드하는 비효율적인 상황인것이다.

CloudFront란 무엇일까?

AWS 인프라를 구성하다 보면 S3, EC2, ALB와 함께 자주 등장하는 서비스가 있습니다. 바로 CloudFront입니다.

CloudFront는 AWS에서 제공하는 CDN(Content Delivery Network) 서비스입니다. 쉽게 말하면, 사용자가 서버나 S3에 직접 접근하지 않고, 전 세계 여러 지역에 분산된 캐시 서버를 통해 더 빠르게 콘텐츠를 받아볼 수 있도록 해주는 서비스입니다.

예를 들어 한국에 있는 사용자가 미국 리전에 있는 S3 이미지에 접근한다고 가정해보겠습니다. 매번 미국 리전까지 요청을 보내면 네트워크 거리가 멀기 때문에 응답 속도가 느려질 수 있습니다. 하지만 CloudFront를 사용하면, 사용자의 위치와 가까운 엣지 로케이션에서 캐싱된 파일을 전달받을 수 있습니다. 결과적으로 이미지, 영상, 정적 파일, API 응답 등을 더 빠르고 안정적으로 제공할 수 있습니다.

CloudFront가 필요한 이유

일반적으로 클라이언트가 S3나 서버에 직접 접근하는 구조는 단순합니다.

Client → S3 또는 Server

하지만 이런 구조에는 몇 가지 한계가 있습니다.

첫째, 사용자의 위치에 따라 응답 속도가 달라질 수 있습니다. 서버가 특정 리전에만 존재한다면, 멀리 떨어진 사용자는 상대적으로 느린 응답을 경험하게 됩니다.

둘째, 모든 요청이 원본 서버로 직접 전달되기 때문에 트래픽이 많아질수록 서버 부담이 커집니다. 이미지, CSS, JavaScript, 음성 파일, 영상 파일처럼 자주 요청되는 정적 리소스까지 매번 원본 서버에서 처리하면 비효율적입니다.

셋째, S3 버킷이나 백엔드 서버를 외부에 직접 노출해야 하는 경우가 생깁니다. 보안적으로도 더 안전한 구조를 만들기 위해서는 중간에 CloudFront를 두고, 사용자는 CloudFront를 통해서만 접근하게 만드는 방식이 더 적절할 수 있습니다.

CloudFront를 적용하면 구조는 다음과 같이 바뀝니다.

Client → CloudFront → S3 또는 Server

사용자는 CloudFront 도메인으로 요청을 보내고, CloudFront는 필요한 경우 원본 서버에서 데이터를 가져옵니다. 이후 같은 파일이 다시 요청되면 원본 서버까지 가지 않고 CloudFront 캐시에서 바로 응답할 수 있습니다.

CloudFront의 핵심 개념

CloudFront를 이해하기 위해서는 몇 가지 개념을 알아야 합니다.

1. Origin

Origin은 CloudFront가 실제 데이터를 가져오는 원본 저장소입니다.

대표적인 Origin은 다음과 같습니다.

- S3 버킷
- EC2 서버
- Application Load Balancer
- API 서버
- 외부 HTTP 서버

예를 들어 이미지 파일을 S3에 저장해두고 CloudFront를 연결한다면, 이때 S3 버킷이 Origin이 됩니다.

2. Edge Location

Edge Location은 CloudFront가 콘텐츠를 캐싱하고 사용자에게 전달하는 지점입니다.

CloudFront는 전 세계 여러 지역에 엣지 로케이션을 가지고 있습니다. 사용자가 요청을 보내면, CloudFront는 사용자와 가까운 엣지 로케이션에서 콘텐츠를 제공하려고 합니다.

이 덕분에 사용자는 원본 서버의 위치와 상관없이 더 빠르게 콘텐츠를 받을 수 있습니다.

3. Cache

CloudFront의 가장 중요한 기능 중 하나는 캐싱입니다.

처음 사용자가 특정 이미지를 요청하면 CloudFront는 Origin에서 해당 이미지를 가져옵니다. 그리고 그 이미지를 엣지 로케이션에 저장합니다. 이후 다른 사용자가 같은 이미지를 요청하면 CloudFront는 Origin까지 다시 가지 않고 캐싱된 이미지를 바로 반환합니다.

즉, 다음과 같은 효과를 얻을 수 있습니다.

- 응답 속도 향상
- 원본 서버 부하 감소
- 데이터 전송 비용 최적화
- 안정적인 콘텐츠 제공

4. Distribution

Distribution은 CloudFront 설정 단위입니다.

어떤 Origin을 사용할지, 어떤 도메인을 연결할지, HTTPS 인증서는 무엇을 사용할지, 캐시 정책은 어떻게 설정할지 등을 하나의 Distribution에서 관리합니다.

CloudFront를 사용한다는 것은 보통 CloudFront Distribution을 생성하고, 여기에 S3나 서버를 Origin으로 연결하는 것을 의미합니다.

CloudFront와 S3를 함께 사용하는 이유

CloudFront는 S3와 함께 자주 사용됩니다.

S3는 이미지, 동영상, 음성 파일, 문서 같은 정적 파일을 저장하기 좋은 서비스입니다. 하지만 S3 URL을 클라이언트에게 직접 노출하면 몇 가지 문제가 생길 수 있습니다.

예를 들어 S3 객체가 public으로 열려 있다면 누구나 직접 접근할 수 있습니다. 반대로 private으로 설정하면 접근 제어를 따로 처리해야 합니다. 또한 S3 리전과 사용자의 위치가 멀 경우 응답 속도가 느려질 수 있습니다.

CloudFront를 S3 앞단에 두면 다음과 같은 구조를 만들 수 있습니다.

Client → CloudFront → S3

이 구조에서는 사용자가 S3에 직접 접근하지 않고 CloudFront를 통해 파일에 접근합니다. 그리고 CloudFront가 S3의 파일을 캐싱해두기 때문에, 반복 요청에 대해 더 빠른 응답이 가능합니다.

또한 S3 버킷은 private으로 유지하고, CloudFront만 S3에 접근할 수 있도록 설정할 수도 있습니다. 이렇게 하면 보안적으로도 더 좋은 구조가 됩니다.

🧹 정리

CloudFront는 AWS에서 제공하는 CDN 서비스입니다. 사용자가 원본 서버나 S3에 직접 접근하지 않고, 전 세계 엣지 로케이션을 통해 빠르게 콘텐츠를 받을 수 있도록 도와줍니다.

그래서 CDN 서비스 곧바로 도입하자!! 고 생각하였지만 ,, 출시가 바로 코앞에 닥쳐있는 현 상황과 현재 저희가 가지고있는 자원들을 생각해서 조금 더 고민해보기로 하였습니다 .. !

그래도 이런 문제들을 해결하기 위한 서비스들이 이미 존재하는것을 보고

역시 현대시대 , 대 AI시대에는 내가 겪은 문제들은 모두 이미 다른 사람들이 겪어 보았고, 이에 대한 해결책들도 이미 많이 제시되어있다는 것을 깨달았다 ..

나도 언젠가는 이런 문제들을 해결하는 엄청난 서비스를 개발하는 사람이 되기를..