Summary
AWS EC2 인스턴스 타입(유형) 변경은 기존 인스턴스를 중지한 후 새로운 인스턴스 타입으로 변경하여 재시작하는 과정입니다. EBS 기반 인스턴스에서만 가능하며, 인스턴스 스토어 볼륨을 루트 볼륨으로 사용하는 인스턴스의 경우 데이터 손실이 발생할 수 있습니다. 적절한 사전 준비와 호환성 확인이 필요합니다.
Details
1. AWS 콘솔을 통한 인스턴스 타입 변경
타입 변경 프로세스
1. EC2 콘솔 접속: AWS Management Console → EC2 서비스
2. 인스턴스 선택: 변경할 인스턴스 선택
3. 인스턴스 중지: 작업 → 인스턴스 상태 → 중지 (Stop)
4. 인스턴스 타입 변경:
- 작업 → 인스턴스 설정 → 인스턴스 유형 변경
- 새로운 인스턴스 타입 선택
- 변경 적용
5. 인스턴스 시작: 작업 → 인스턴스 상태 → 시작
추가 고려사항
- 인스턴스 상태 확인: "stopped" 상태에서만 타입 변경 가능
- 호환성 확인: 현재 세대와 다음 세대 인스턴스 간 호환성
- 네트워크 설정: ENI(Elastic Network Interface) 호환성 확인(해당 인스턴스 타입이 지원하는 ENI 최대 개수 확인)
- EBS 최적화: 새 인스턴스 타입의 EBS 최적화 지원 여부
2. AWS CLI를 통한 인스턴스 타입 변경
# 인스턴스 중지
aws ec2 stop-instances --instance-ids i-1234567890abcdef0
# 인스턴스 상태 확인 (중지 될 때까지 대기)
aws ec2 describe-instances \
--instance-ids i-1234567890abcdef0 \
--query 'Reservations[].Instances[].State.Name'
# 인스턴스 타입 변경
aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--instance-type Value=m5.large
# 인스턴스 시작
aws ec2 start-instances --instance-ids i-1234567890abcdef0
3. 인스턴스 타입별 특징
범용 인스턴스 (General Purpose)
- T3/T4g 버스터블: 기본 CPU 성능 + 버스트 크레딧
- M5/M6i: 균형잡힌 컴퓨팅, 메모리, 네트워크 리소스
- 사용 사례: 웹 서버, 중소형 데이터베이스, 백엔드 서버
컴퓨팅 최적화 (Compute Optimized)
- C5/C6i: 고성능 프로세서 중심
- 사용 사례: 웹 서버, 과학적 모델링, 배치 처리
메모리 최적화 (Memory Optimized)
- R5/R6i: 메모리 집약적 애플리케이션
- X1/X2: 대용량 인메모리 데이터베이스
- 사용 사례: 인메모리 데이터베이스, 실시간 빅데이터 분석
스토리지 최적화 (Storage Optimized)
- I3/I4i: NVMe SSD 지원, 높은 랜덤 I/O
- D2/D3: HDD 기반 대용량 스토리지
- 사용 사례: NoSQL 데이터베이스, 분산 파일 시스템
4. 다운타임 없는 변경 방법 (고급)
Auto Scaling 기반 교체 전략
- 새 Launch Template 생성: 원하는 인스턴스 타입으로 설정
- Auto Scaling 그룹 업데이트: 새 Launch Template 적용
- 인스턴스 교체: 점진적으로 새 인스턴스로 교체
- 로드 밸런서: 트래픽을 새 인스턴스로 점진적 이동
Blue-Green 배포
- 새 환경 구성: 새 인스턴스 타입으로 parallel 환경 구축
- 데이터 동기화: 필요시 데이터 복제
- DNS 전환: Route 53 가중치 라우팅으로 점진적 전환
- 기존 환경 정리: 검증 완료 후 기존 환경 종료
Guidance
사전 준비 사항
1. 호환성 확인
- 아키텍처: x86_64 ↔ ARM64 (Graviton) 확인
- 가상화 타입: HVM만 지원하는 인스턴스 타입 확인
- 네트워크 성능: 향상된 네트워킹 지원 여부
- EBS 최적화: 새 인스턴스 타입의 EBS 성능
2. 애플리케이션 고려사항
- 라이센스: 코어/vCPU 기반 라이센스 비용 변화
- 메모리 요구사항: 현재 메모리 사용량 vs 새 타입 메모리
- 네트워크 대역폭: 네트워크 집약적 애플리케이션 영향
- 스토리지 성능: IOPS 요구사항 충족 여부
3. 백업 및 스냅샷
- EBS 스냅샷: 변경 전 필수 백업
- 인스턴스 스토어: 임시 데이터는 손실됨 (백업 필요)
- 애플리케이션 백업: 데이터베이스 등 애플리케이션 레벨 백업
성능 및 비용 고려사항
1. 성능 영향
CPU 성능: 성능 검증을 위한 벤치마크 수행 권장
메모리 대역폭: 메모리 집약적 워크로드 검증
네트워크 성능: 네트워크 처리량 테스트
스토리지 I/O: EBS 성능 변화 확인
2. 비용 최적화
온디맨드 vs 예약 인스턴스: 장기 사용 시 예약 인스턴스 고려
스팟 인스턴스: 중단 가능한 워크로드는 스팟 활용
Right Sizing: 실제 리소스 사용량 기반 타입 선택
비용 계산기: AWS 요금 계산기로 비용 비교
3. 모니터링 및 검증
CloudWatch 메트릭: CPU, 메모리, 네트워크, 디스크 사용률
애플리케이션 성능: 응답 시간, 처리량 모니터링
로그 분석: 오류 로그 및 성능 로그 확인
부하 테스트: 변경 후 성능 벤치마킹
잠재적 위험 및 제한사항
1. 데이터 손실 위험
- 인스턴스 스토어: 중지/시작 시 데이터 완전 손실
- 스왑 파일: RAM 디스크의 임시 데이터 손실
- 캐시 데이터: 메모리 기반 캐시 재구축 필요
2. 서비스 중단
- 다운타임: 중지→변경→시작 과정에서 서비스 중단
- 부팅 시간: 인스턴스 크기 및 타입에 따라 달라질 수 있음
- 초기화: 일부 서비스의 재초기화 시간 추가 소요 가능성
3. 네트워크 및 보안
- IP 주소: 퍼블릭 IP 변경 가능성 (Elastic IP 사용 권장)
- 보안 그룹: 새 인스턴스 타입의 네트워크 인터페이스 수
- DNS 캐시: 클라이언트의 DNS 캐시 TTL로 인한 전환 지연 발생 고려
댓글
댓글 0개
댓글을 남기려면 로그인하세요.