EC2 부팅 시간 단축하기

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

[GN⁺]

Hacker News 의견

요약

• 부팅 시간: 자동 확장 성공의 핵심 요소로, 부팅 시간이 짧을수록 예측 창이 작아져 예측 정확도가 높아짐. 비용 절감을 위해 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 작업을 직접 하이퍼바이저에서 부팅하는 것이 더 나은 접근법일 수 있음.