# EC2 부팅 시간 단축하기

> Clean Markdown view of GeekNews topic #15046. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15046](https://news.hada.io/topic?id=15046)
- GeekNews Markdown: [https://news.hada.io/topic/15046.md](https://news.hada.io/topic/15046.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-05-28T09:17:06+09:00
- Updated: 2024-05-28T09:17:06+09:00
- Original source: [depot.dev](https://depot.dev/blog/faster-ec2-boot-time)
- Points: 14
- Comments: 1

## Topic Body

- 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초로 단축됨.

## Comments



### Comment 25644

- Author: neo
- Created: 2024-05-28T09:17:07+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=40455208) 
##### 요약

- **부팅 시간**: 자동 확장 성공의 핵심 요소로, 부팅 시간이 짧을수록 예측 창이 작아져 예측 정확도가 높아짐. 비용 절감을 위해 EBS 볼륨을 미리 준비하는 것이 합리적일 수 있음.
- **아마존의 최적화**: 아마존은 Firecracker와 같은 기술로 초고속 부팅을 구현했으며, EC2에서도 유사한 기능을 제공할 가능성이 있음.
- **불변 설정**: 불변/원자적 설정을 통해 EBS 볼륨을 공유하고, 최소 부팅 AMI를 사용해 최적화할 수 있음.
- **부팅 시간 측정**: EC2 인스턴스 부팅 시간이 이중 모드로 나타나며, 15-20초 또는 80초로 분포됨. 원인 파악 필요.
- **GitHub 액션**: GitHub 액션 러너의 부팅 최적화에도 불구하고, 작업 전달 시간이 길어져 최적화 필요.
- **AWS와 비교**: AWS와 다른 클라우드 제공업체의 부팅 시간 비교. Hetzner는 몇 초 만에 인스턴스를 생성함.
- **EC2 자동 확장기**: EC2 자동 확장기의 한계와 개선 필요성 언급. AWS 제공 자동 확장기는 느리고 제한적임.
- **EBS 사용 이유**: EBS는 내구성을 위해 비용과 성능을 희생함. 네트워크 연결된 볼륨으로 느림. 최소한의 Linux 설치와 빠른 로컬 스토리지 사용이 더 적합함.
- **EBS의 Copy-On-Write 지원 부족**: EBS는 Copy-On-Write를 지원하지 않으며, 스냅샷이 S3에 저장되어 IOPS 할당이 지연됨.
- **온프레미스 하드웨어로 이동**: Depot은 온프레미스 하드웨어로 이동해 성능을 최적화하고 비용을 절감할 수 있음. 고객 CI 작업을 직접 하이퍼바이저에서 부팅하는 것이 더 나은 접근법일 수 있음.