이미지를 처리할때 메모리에 올라가지 않을정도로 크다면 어떻게 해야할까?
+수정) 적용해봤다!

webRTC를 잠깐 공부했던 기억이 나서 음성데이터를 바이너리 데이터로 변환한거처럼 이미지 파일도 청크단위로 나눠서 처리하면 어떨까? 라고 생각했다.

면접이 끝나고 청킹을 통한 이미지 처리를 찾아보니, 여러 단점이 존재했다.

1. 우선 코드가 복잡하다
   -청크를 관리하는 클래스, 인터페이스가 필요하다
   -상태관리, 동시성 처리 문제가 있다.

2. 메모리관리에 이슈가 있다
   -GC 타이밍이 예측하기 어렵다

3. 에러처리가 복잡하다
   -부분 실패시 복구 메커니즘이 필요하다
   -청크별 재시도 로직이 필요하다

4. 각 청크마다 HTTP 요청이 발생한다

그렇다면 실시간으로 상태표시가 필요하거나, 정밀한 이미지 처리 로직이 없다면 더 단순한 방법으로 처리하는게 용이하다고 생각해서 찾아보았다.

presignedURL

"접근 권한에 대한 인증을 마치면 S3에 대해 시간 제한이 있고 특정 작업과 리소스에 대한 권한만 가진, AWS 인증 정보가 포함된 임시 URL을 발급해 주는데, 이 URL을 preSigned(pre-signed) URL이라고 한다."

그럼 presignedURL를 사용하면 어떤 flow로 이미지 처리가 이뤄질까?

1. 클라이언트가 서버에 Presigned URL만 요청
2. 서버는 URL만 생성해서 반환 (매우 가벼운 작업)
3. 클라이언트가 받은 URL로 S3에 직접 업로드
4. 서버 부하 최소화
5. 업로드 속도 향상

기존 이미지 업로드 방식과 비교하면 차이가 확실하다

1. 클라이언트 → 서버 → S3 순서로 데이터가 이동
2. 서버 리소스(메모리, CPU) 사용
3. 서버 대역폭 사용
4. 업로드 시간 증가
5. 서버 장애시 업로드 실패

그럼 이 방법이 만능이냐?
만능이다 는 아니고 상황에 맞는 적절한 방법을 사용하면 된다!

---

++ 이미지 가공을 위한 방법

이미지 가공을 위한 서버리스 아키텍처 (AWS Lambda)

핵심 특징

요청 부하에 따른 자동 스케일링
실제 사용한 만큼만 과금
더 작은 단위의 리소스 관리

Lambda vs Kubernetes 비교

관리 복잡도

Lambda: 간단한 관리
K8s: 복잡한 인프라 관리 필요

스케일링 특성

Lambda: 즉각적인 스케일링, 작은 단위
K8s: 상대적으로 느린 스케일링, 큰 단위

비용 효율성

Lambda: 정확한 사용량 기반 과금
K8s: 인프라 유지 비용 발생

권장사항

초기/중기 서비스: Lambda 사용
고도화 단계: K8s 고려

---

++ 이미지를 s3에서 관리하는 이유는?

정적 데이터 관리 (S3 + CloudFront)

S3 활용

안정적인 스토리지
확장성 걱정 없음
서버 부하 감소

CloudFront(CDN) 연동

글로벌 캐싱
사용자와 가까운 엣지 로케이션 활용
빠른 응답 속도
특히 글로벌 서비스에 효과적

장점

서버 부하 관리 불필요
글로벌 확장 용이
높은 가용성
비용 효율적