serverless-image-handler | 허원철의 개발 블로그

Serverless Image Handler는 AWS에서 제공하는 다양하고 검증된 서비스들을 조합하여 만들어진 솔루션(?)입니다.

운영하는 서비스에 종속적인 기능들이 아니라면 한번 찾아보면 이미 만들어져 있을 법한 것들이 있기 때문에 한번 서칭해보면 좋을 듯 한데요. 그 예로, 로깅 중앙화, 제가 사용해본 서버리스 이미지 핸들러 등등이 존재합니다.

https://github.com/aws-solutions/

아키텍처

Overview < 출처: https://github.com/aws-solutions/serverless-image-handler >

해당 기능은 말그대로 서버리스 환경에서 이미지를 요청시에 즉시 핸들링해주는 솔루션입니다. 제가 맡고 있는 서비스는 원본 이미지를 다양한 크기로 이미지를 노출시킬 수 있어야 했는데요. 미리 만드는 방법도 있지만 이는 정적이고, 마이그레이션이 다소 불편하며, 관리하는 측면에서 만족스럽지 못 했습니다.

이것 이외에도 CloudFront + Lambda@Edge를 사용하는 방법도 있으니 참고하시기 바랍니다.

기능

이미지를 다양한 형태로 핸들링할 수 있습니다.
- 해당 기능은 런타임 환경이 Nodejs에서 이루어지며, Nodejs에서 이미지 처리하는 라이브러리인 sharp를 사용하고 있습니다.
- 리사이징
- 포맷 변경
- 퀄리티 변경
- ...
이미지 URL 변조
- 만약 우리가 300x300 사이즈의 이미지를 제공하고 이를 어느 누구나 변경해서 요청할 수 있다면 어뷰징 대상이 될 수 있을 것 입니다.
- 300x301, 300x302, 300x303, 300x... 😱
- signature 라는 파라미터를 받아서 이를 변조하지 못하도록 제공하고 있습니다. (해당 기능은 secret-manager를 통해 별도의 키를 만들어서 사용합니다.)
이미지 자르기, Amazone Rekognition을 활용한 분석 등등을 제공합니다.
...

사용방법

Default 방식

const imageRequest = JSON.stringify({
    bucket: "<myImageBucket>",
    key: "<myObjectKey>",
    edits: { 
        resize: {
            width: ...,
            height: ...
        }
    }
});
const url = `${CloudFrontUrl}/${btoa(imageRequest)}`;

<img src=`${url}` />

위 방식은 url을 json문자열을 base64으로 인코딩해서 전달하는 방식으로 json 안에는 bucket, object key, sharp 정보(?) 등을 포함되어 있습니다. sharp 관련된 내용은 관련 문서를 참고해서 적용하면 손쉽게 적용할 수 있습니다.

https://sharp.pixelplumbing.com/

Thumbor 방식

const url = `${CloudFrontUrl}/filter:format(webp)/${object_key}`;

<img src=`${url}` />

위 방식은 기존 url과 비슷하게 유지하면서 사용할 수 있는 방법 중에 하나로, path 중간에 filters:~~~를 넣어 옵션을 적용할 수 있습니다.

스펙 참고: https://docs.aws.amazon.com/solutions/latest/serverless-image-handler/thumbor-filters.html

사용 후기

장점

CloudFormation으로 제공되기 때문에 손쉽게 구축할 수 있습니다.
- AWS 솔루션의 공통적인 장점이겠지만, cdk를 활용해 CloudFormation으로 빌드하여 제공하고 있습니다.
CloudFront를 사용하기 때문에 한번 요청되면 캐시되어 비용 절감이 가능하다.
- CloudFront라는 CDN 서비스를 사용하고 있기 떄문에(사실 누가 CloudFront없이 S3를 바로 붙이겠냐만은...) 응답이 캐싱되어 첫 요청이외에는 비용이 많이 절감됩니다.
On the fly 방식이기 때문에 관리가 용이합니다.

단점

람다 자체가 요청/응답에 대한 페이로드가 6MB 제한이 있기 때문에 큰 이미지를 전달할 수 없습니다.
- base64로 인코딩해서 전달하기 때문에 6MB보다 더 작아야 합니다. 😥
다소 과할 수 있다.
- 어느 것이나 그렇지만 단순하게 쓰고자한다면 조금 과할 수 있다.
6.0.0 버전까진 gif 대응이 안된다.
- sharp가 0.30.0 버전부터 gif를 지원하기 시작했지만, 0.27.0 버전을 사용하고 있기 때문에 대응이 안된다.
- gif를 지원하려면 결국엔 별도 빌드를 거쳐서 사용해야함

결국, 1,3번 단점 때문에 나의 서비스는 api gateway에 별도 path를 추가 및 직접 S3 서비스를 연결해서 사용하고 있습니다.

아키텍처​

기능​

사용방법​

Default 방식​

Thumbor 방식​

사용 후기​

장점​

단점​

아키텍처

기능

사용방법

Default 방식

Thumbor 방식

사용 후기

장점

단점