궁금한 것 알아보고 정리하는 블로그

서론

EKS를 알아보던 중 EKS Fargate에서 사용하는 Firecracker을 우선 조사해보기로 했다. Firecracker는 AWS lambda, EKS 등에서 사용하는 경량화 VM 기반 가상화 기술이다.

경량화 VM 가상화가 필요한 이유

Lambda는 여러 고객의 코드를 같은 물리 서버 위에서 실행하는데, 고객마다 올리는 코드는 신뢰할 수 없으므로 각 함수는 보안적으로 완전히 분리되어야 한다. 이는 도커와 같은 컨테이너 기술로는 구현할 수 없다. EKS 를 Fargate 모드(Pod 단위로 서버리스처럼 사용)로 사용할 경우 비슷한 보안상의 이유로 보다 커널수준 격리가 필요한다. Firecracker는 VM을 이용해 커널까지 격리되는 완전한 운영체제 수준의 격리를 제공하면서도 성능 저하를 최소화할 수 있다.

Firecracker 가 가벼운 이유

커널까지 격리하는데도 속도가 느리지 않은 이유는 복잡한 하드웨어 에뮬레이션 없기 때문. 

전통적인 VM은 컴퓨터 시스템 전체를 가상화하는 것이 목적이었지만, 그렇지 않다면 생략하여 최소한의 장치(Virtio)만 제공할 수 있음

• Virtio는 가상 머신 환경에서 표준화된 가상 디바이스 인터페이스로, 실제 하드웨어 대신 커널이 직접 입출력을 다뤄주는 방식

KVM

Firecracker는 KVM(커널 기반 가상화) 위에서 동작함.

KVM은 리눅스 커널에 내장된 하이퍼바이저 기능으로, 하드웨어 가상화 지원을 이용해서 VM을 돌리는 엔진

EKS와 Firecracker

EKS 모드

• EC2 모드: EC2 인스턴스 안에서 컨테이너를 띄움
• Fargate 모드: 파드 단위로 서버리스처럼 동작함. Firecracker 사용해서 파드를 MicroVM 위에서 띄움

참고

https://www.youtube.com/watch?v=BIRv2FnHJAg

https://firecracker-microvm.github.io/

배경

우리 서비스는 웹과 앱을 모두 운영하고 있는데, 웹 사용성을 고려하여 업로드 한 대용량 이미지가 일부 구형 기기에서 앱 크래시를 일으키는 이슈가 있었다.

요약

CloudFront(CDN)와 Lambda@Edge를 활용하여 클라이언트로부터 받은 파라미터에 따라 S3에 저장된 원본 이미지를 람다(AWS 서버리스 앱)가 리사이즈 하도록 했다.

구조와 흐름

유저가 CDN에 이미지를 원하는 크기와 함깨 요청하면 뷰어 요청에 트리거되는 람다(좌측 상단)가 요청 URL의 크기 정보를 CDN 과 S3에서 사용되는 경로로 변환하여 CDN에 전달한다.

• 이 경로의 이미지가 있으면 CDN에서 바로 이미지를 응답한다.
• 이 경로의 이미지가 없으면 CDN은 요청을 S3에 전달하고, S3은 응답한다.
  
  • 이 때 오리진 응답에 트리거되는 람다(우측 하단)가 실행된다.
    • S3로부터 403 코드를 응답받으면(대부분의 경우) CDN은 요청 URL 로부터 원본 이미지 경로를 파싱하여 S3에 재요청하고 이를 리사이즈한다.
    • 1MB미만이면 유저에게 응답하고, 그렇지 않은 경우 S3에 저장 후 해당 경로로 리다이렉트한다.

작업순서

1. CloudFront 생성
2. CloudFront 의 오리진에 기존 S3 연결
3. 기존 이미지 요청 시 사용하던 도메인을 S3 에서 CloudFront로 변경
4. Lambda@Edge 2개 생성
5. Lambda@Edge의 트리거에 각 CloudFront 뷰어요청, 오리진(S3) 응답 등록
6. Lambda@Edge 모두 S3에 접근할 수 있도록 람다 IAM role 생성하여 Trust Relationship(신뢰관계) 설정 확인
7. Lambda@Edge 배포 (serverless 프레임워크 사용)

기타, 회고

Lambda@Edge 와 연결된 CloudWatch와 로그는 연결된 CloudFront가 요청을 받은 리전(Edge)에서만 확인할 수 있다. 이 부분을 놓쳐 코드가 제대로 동작하는지 확인하는 데 헤맸다.

Lambda@Edge는 Lambda 와 비교하여 실행시간(5초), 응답 크기(1MB), 메모리(기본값 128MB) 등 더 많은 제한이 있어 까다로웠다.

아래 링크의 코드와 달리 S3에서 파일이 없는 경우 404가 아닌 403 코드를 응답하여 디버깅하는 데 오래 걸렸다.

참고

https://aws.amazon.com/blogs/networking-and-content-delivery/resizing-images-with-amazon-cloudfront-lambdaedge-aws-cdn-blog/