AWS Fargate를 깊게 알아보자

ECS와 EKS를 사용할때 Fargate를 같이 사용하다 보면 이런 생각이 든다. 저건 어떻게 구성되어 있길래 저렇게 동작할까?? 아마 EC2에 Container가 올라가서 거기에 ENI를 하나 할당하여 동작하는 방식 같지만 자세하진 않다. 그래서 찾아보다 보니

https://aws.amazon.com/ko/blogs/korea/firecracker-lightweight-virtualization-for-serverless-computing/

Firecracker – 서버리스 컴퓨팅을 위한 오픈 소스 경량 가상화 기술 공개 | Amazon Web Services

이런 친구를 발견했다.

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

위와 같이 KVM위에 매우 경량화된 VM이 올라가는 형태이다. 그래서 다른 하이퍼바이져 VM보다 빠르게 동작하고 불필요한 서비스가 제거되었기 때문에 보안성도 높다고 한다.

 

그럼 저게 EC2에 올라가는걸까 싶은데 VM위에 VM을 만들어서 Container를 올리는 것은 정말 비효율 적이라 생각된다. 그러면 자료를 찾아보자!

 Continer에 대해서는 누구나 다들 잘 알고 있을것이다.

• Control Group
• Namespace
• etc...

이런 리눅스 기능의 구현체이다.

 

Fargate의 구성 또한 위의 기능을 함께 사용하는데 이건 추후에 설명하겠다. 일단 Fargate를 알아보면

위와 같이 EC2 머신 위에 Fargate Agent와 Runtime이 올라가고 위에 Fargate가 생성되는 구조를 가지고 있다. 하지만 아까도 이야기 했지만 이 구성은 VM위에 Container가 뜨며 테넌트 격리를 위해 Container EC2가 뜨는 불필요한 리소스를 요구한다. 따라서 속도도 매우 느릴것이다.

그러다 보니 디펜턴시도 강하게 생성된다. Control Plane과 Fargate VPC에 생성된 EC2들에 강력하게 묶여있고 그와 다르게 사용자의 ENI가 별도로 할당되어 있다. Namespace가 아무리 격리가 잘 되어 있다고 해도 Container에서 User Namespcae는 격리하지 않는다. 이것은 어찌보면 host 머신의 보안 취약점이 될 수 있다.

 

그래서 위에서 언급한 Firecracker를 도입한것 같다.

Firecracker가 도입되면 위처럼 Geust kernel까지가 폭발 반경이 되며 EC2 인스턴스에는 영향을 주지 않는다. 하지만 EC2 instance VM위에 뜨는게 아니다. 자세히 보면 Bare Metal인데 이것 또한 이유가 있다.

일반적인 EC2 Instance를 사용한다면 위처럼 각각 필요에 따라서 Instnace가 뜰텐데 알다 싶이 EC2는 Type이 있다. 모든게 핏하게 맞다면 리소스가 매우 효율적이겠으나 아니라면? 그건 모두 낭비다.

그래서 위처럼 Bare Metal위에 여러 크리고 분리된 Firecracker를 구성하여 크기에 맟게 Container를 띄우는 형식이다. 이렇게 되면 불필요한 공간 낭비를 줄이고 마치 조각모음 하듯 capa를 관리하며 끼워 넣을수 있다. 또한 ENI도 절약이 된다. EC2마다 뜨는 경우 EC2마다 Agent가 생성되고 ENI가 별도로 생성되는데 Bare Metal을 사용하면 하나의 Agent로 Multi-tenant 지원을 하게끔 구성하여 하나의 ENI로 Control Plane과 통신하며 Fargate를 효율적으로 관리 할수 있다.