해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 44 - Exploring Firecracker
1. 전통적인 컴퓨팅 환경
서버에서 애플리케이션을 실행하는 방식은 크게 가상 머신 (VM)과 컨테이너로 나뉘며, 각각 명확한 장단점을 가진다.
-
가상 머신 (VM) :
- 정의 : SW를 사용하여 전체 물리적 컴퓨터를 에뮬레이트 (각 VM은 자체 OS를 실행하며 완전히 분리)
- 장점 :
- 완전히 격리되어 호스트 머신에 영향이 없음.
- 수십 년의 경험과 관리 도구가 풍부
- 다중 OS 환경 구축 가능
- 단점 :
- 구동에 수 분이 소요
- 이미지 크기가 기가바이트 (GB) 단위
- 전체 OS를 포함해 서버당 실행 가능한 수가 적음.
- 컨테이너 (Container) :
- 정의 : 애플리케이션 코드와 종속성을 포함한 실행 가능한 소프트웨어 단위 (OS 커널 기능을 공유하여 프로세스를 격리)
- 장점 :
- 구동에 밀리초 단위가 소요
- 이미지 크기가 메가바이트(MB) 단위
- 단일 시스템에 더 많은 컨테이너 호스팅 가능.
- 단점 :
- 기반 OS를 공유하므로 VM보다 보안성이 낮음.
- 동일한 OS 위에서만 실행 가능
- 태계가 여전히 진화 중
AWS는 보안성 (VM의 장점)과 속도/효율성 (컨테이너의 장점), 이 두 가지를 모두 만족하는 새로운 솔루션이 필요하였다.
2. AWS Lambda
AWS Lambda와 같은 서버리스 함수는 예측할 수 없는 빈도와 양으로 요청이 들어오는 단기 워크로드 (Short-lived workloads)에 사용된다.
AWS Lambda는 서버리스 (Serverless) 컴퓨팅의 대표 주자로, 개발자가 서버 관리 없이 코드를 실행할 수 있게 해준다.
이 서비스의 핵심 특징은 코드가 이벤트에 응답하여 실행되는 함수 (Function) 단위이며, 사용자가 코드를 업로드하면 AWS가 자동으로 필요한 컴퓨팅 리소스를 프로비저닝하고 관리한다.
-
효율성 문제:
- 클라우드 제공업체는 수많은 고객의 함수를 단일 물리적 워커 서버에서 실행하여 리소스 활용을 극대화해야함.-> 고밀도(High Density)가 필요한 이유
-
보안 문제:
- 동일한 물리적 서버에서 서로 다른 고객 계정의 함수가 실행될 때 (다중 테넌시 환경), 한 함수의 잠재적 악성 코드가 다른 고객의 데이터나 함수 환경에 접근하는 것을 완벽하게 막아야함. -> 강력한 격리가 필요한 이유
- 동일한 물리적 서버에서 서로 다른 고객 계정의 함수가 실행될 때 (다중 테넌시 환경), 한 함수의 잠재적 악성 코드가 다른 고객의 데이터나 함수 환경에 접근하는 것을 완벽하게 막아야함. -> 강력한 격리가 필요한 이유
이때, 전통적인 VM은 느려서 비효율적이고, 컨테이너는 보안 격리가 충분히 강력하지 않기 때문에 AWS는 이 문제를 해결하기 위해 마이크로 VM이라는 새로운 개념을 개발하였다.
3. Firecracker
Firecracker는 AWS가 이러한 서버리스 환경의 요구 사항을 충족하기 위해 오픈 소스로 개발한 가상 머신 모니터 (VMM)이다.
FireCracker 공식 문서
https://firecracker-microvm.github.io/
파이어크래커의 특징: Secure, Fast, Efficient
-
마이크로 VM 생성:
-
Firecracker는 리눅스 커널 기반 가상화 기술인 KVM (Kernel-based Virtual Machine)을 활용하여 마이크로 VM을 생성
-
마이크로 VM은 VM이지만, 일반 VM에서 필수적이지 않은 모든 기능을 제거하여 매우 작고 단순하게 만든 것
-
-
보안 강화:
-
각 Lambda 함수나 컨테이너 그룹은 자체 마이크로 VM에 의해 가상 머신 장벽으로 캡슐화됨.
-
KVM 기반 가상화의 강력한 보안을 제공하여, 다른 고객의 워크로드가 동일한 머신에서 안전하게 실행될 수 있도록 보장
-
장치 모델을 최소화하여 공격 표면 영역 (Attack Surface Area)을 줄임.
-
-
극도의 속도:
-
커널 로딩 가속화 및 최소 게스트 커널 구성을 통해 마이크로 VM을 수백 밀리초 만에 구동할 수 있음.
-
호스트당 초당 약 150개의 마이크로 VM을 생성하는 속도
-
-
높은 효율성:
-
마이크로 VM의 감소된 메모리 오버헤드 덕분에 단일 서버에 고밀도로 수천 개의 마이크로 VM을 패킹할 수 있음.
-
AWS Lambda의 낮은 운영 비용과 높은 리소스 효율성에 효과
-
4. Firecracker의 한계점과 사용 사례
Firecracker는 AWS Lambda에 최적화된 기술이지만, 모든 상황에 적합한 만능 솔루션은 아니다.
스케줄링, 용량 계획, 모니터링, 노드 자동 스케일링, 고가용성 등의 기능은 Firecracker가 제공하지 않으며, 사용자가 솔루션 내에서 직접 구현하거나 코드를 작성하여 보완해야 한다는 어려움이 존재한다.
추가적으로, Firecracker 기반의 마이크로 VM은 다음과 같은 환경에 최적화되어 있다.
-
컨테이너 보안이 부족한 곳:
- 컨테이너의 성능이 필요하지만, 커널 공유로 인한 보안 위험을 허용할 수 없는 환경 (AWS Lambda, Fargate와 같이 사용자 워크로드를 분리해야 하는 다중 테넌시 플랫폼)
-
단기 워크로드 (Short-lived workloads):
- 함수 실행처럼 짧게 실행된 후 바로 종료되는 환경
-
훈련 및 교육 환경:
- 전체 VM을 구동하기 부담스러울 때, 학습이나 실험을 위한 경량의 격리된 환경이 필요한 경우
결론적으로, AWS Lambda의 성공은 Firecracker가 제공하는 VM 수준의 보안과 컨테이너 수준의 성능이라는 두 마리 이점을 모두 충족시켰기 때문에 가능했다고 볼 수 있다.
