- EC2 인스턴스의 부팅 시간을 40초에서 5초로 줄이는 것이 가능함
- 이는 특정 작업을 처리하기 위해 새로운 EC2 인스턴스가 필요한 경우 매우 중요
부팅 시간이 오래 걸리는 이유
- 새로운 EC2 인스턴스를 요청할 때 AWS는 여러 작업을 수행함:
- 선택한 AMI에서 루트 EBS 볼륨 생성
- 인스턴스에 사설 IP 주소 할당
- 인스턴스를 위한 호스트 선택
- 실제로 머신 부팅
- 하드웨어가 켜진 후에도 부트로더, 커널, 사용자 공간 프로세스가 시작되어야 함.
문제 회피 방법
- 대기 중인 컴퓨팅 풀을 운영하여 빌드 요청을 이미 실행 중인 EC2 인스턴스로 라우팅함.
- 그러나 모든 작업에 대해 경제적으로 실행 가능하지 않음.
- GitHub Actions 러너의 경우 각 작업이 전용 EC2 인스턴스로 라우팅됨.
- 50개의 병렬 작업을 처리하기 위해 50개의 EC2 인스턴스를 온라인 상태로 유지하는 것은 비현실적임.
더 빠른 부팅 시간
- 특정 작업에 대해 불필요한 작업을 하지 않는 것이 항상 더 빠름.
- EC2 인스턴스 생성, 부팅 및 애플리케이션 시작의 각 단계를 체계적으로 최적화함.
- 인스턴스를 한 번 부팅하고, 종료한 후 필요할 때 다시 부팅하는 방법을 사용함.
EBS 루트 볼륨 스트리밍
- EBS 루트 볼륨 준비는 EC2 인스턴스 부팅 시간과 애플리케이션 성능에 큰 영향을 미침.
- AMI에서 EBS 볼륨을 생성할 때 데이터 블록이 처음으로 액세스될 때 S3에서 가져와야 함.
- AWS는 모든 데이터 블록을 미리 로드하는 방법을 권장함.
인스턴스 한 번 부팅하기
- EBS 지원 인스턴스를 중지한 후 다시 시작할 수 있음.
- 중지된 인스턴스는 구성만 유지되며, 루트 EBS 볼륨에 대한 비용만 지불함.
- 인스턴스를 한 번 부팅하여 초기화 작업을 수행한 후 중지하면 "워밍된" EBS 루트 볼륨이 생성됨.
오토스케일링 워밍 풀
- AWS는 EC2 오토스케일링을 위한 워밍 풀을 제공함.
- 그러나 오토스케일링 그룹은 요청에 반응하는 데 시간이 걸림.
- 최상의 성능을 위해 LaunchInstances 및 StartInstances API 호출을 사용하여 직접 EC2 인스턴스를 시작함.
인스턴스 크기 조정
- 워밍된 인스턴스의 유형을 변경하여 부팅 시간을 최적화함.
- 초기화 작업에는 저렴한 인스턴스 유형을 사용하고, 실제 작업 시 더 높은 성능의 인스턴스 유형으로 변경함.
전체 흐름
- GitHub Actions 러너 인스턴스는 다음과 같은 흐름을 거침:
- t3.large 인스턴스로 생성
- 대상 VPC에 사설 IP 주소 할당
- 커널 및 사용자 공간 프로세스가 한 번 시작됨
- 인스턴스 중지
- 작업 요청이 도착하면 인스턴스 유형을 m7a로 업데이트하고 시작
- m7a 인스턴스 용량이 없으면 백업 유형으로 업데이트하고 다시 시작
- 이 흐름으로 작업을 위한 인스턴스 준비 시간이 40초에서 5초로 단축됨.