오늘은 EC2의 용량을 늘리는 것에 대한 내용을 적어보려 합니다. 사실상 장애리뷰 겸...
서비스에서 EB 환경이 아닌 EC2 인스턴스를 운용하는 부분이 있는데, 이번에는 거기서 말썽을 부렸습니다.
EC2 에서 어떤 문제를 일으켰을까?
사실 처음 장애 상황을 인지한 경로는 아쉽게도 EC2에 대한 모니터링을 통한 것이 아니었습니다.
해당 인스턴스에 젠킨스를 설치하여 배치 작업들을 수행하고 있었는데 배치 작업의 최근 수행 시간이 하루 전인 것을 이상하게 여겨 이슈화되었습니다. 해당 문제 제기를 보고 해당일 오전에 있던 배포가 떠올라 Code Deploy에 가보니 배포 역시 실패해 있었고 에러를 확인하니 여유 공간이 없다고 합니다. ssh으로 접속하여 확인하였을 때도 100% 사용 중인 것을 확인할 수 있었습니다. 흠...
그럼 이제 용량을 늘려보자
해당 인스턴스의 정상화를 위해서는 용량 증가가 필수였습니다. 당시 사용하고 있는 용량은 32G, 2배인 64G로 늘렸습니다.
하지만 이 수정을 통해서 바로 추가 용량을 사용할 수 있는 것은 아닙니다. 공식문서에 따르면 볼륨에 파티션이 있는 경우 파티션을 확장해주어야한다고 합니다. 파티션 확장은 growpart를 통해서 할 수 있는데 여유 공간이 없는 경우 마찬가지로 용량이 부족하다는 에러가 뜨게 됩니다. 하지만 AWS는 모든 것을 알고 있습니다. 공식문서를 보면 임시 파일 영역(/tmp) 를 생성하라고 합니다. 이제부터는 큰 문제없이 용량 확장이 진행되었습니다. 과정은 아래와 같습니다.
$ lsblk
$ df -h
$ sudo mount -o size=10M,rw,nodev,nosuid -t tmpfs tmpfs /tmp
$ sudo growpart /dev/nvme0n1 1
$ sudo resize2fs /dev/nvme0n1p1
$ sudo umount /tmp
아쉬운 점
장애 인지 후 대응까지는 동료들과 모여서 빠르게 처리되었지만 인지하는 과정이 아쉬웠습니다. 모니터링 페이지가 있음에도 불구하고 간접적인 방식으로 장애를 인지했기 때문에 그렇습니다. ec2의 용량과 메모리 지표를 추가하려면 해당 인스턴스에 에이전트를 설치하는 등의 별도의 과정이 필요하여 이제껏 추가하지 않았던 것 같은데, ec2를 상용 환경에서도 사용하는 입장에서 이러한 지표들에 대한 추가를 진지하게 고민해봐야 하는 순간이라고 생각이 들었습니다.
혹은 AWS Batch로의 이전도 있겠지만 자세한 내용은 알지 못해 조사가 필요합니다.
참고
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
https://aws.amazon.com/ko/premiumsupport/knowledge-center/ebs-volume-size-increase/
'AWS' 카테고리의 다른 글
보안 그룹 중첩 시 유의 사항 (0) | 2024.03.14 |
---|---|
[AWS] EBS 용량 변경시 주의 사항 및 파티션 방식 (MBR/GPT) (0) | 2023.03.12 |
[RDS] RDS MySql 버전 업그레이드 시도와 장애 (0) | 2023.01.19 |
CodeDeploy에 알림을 추가해보자! (0) | 2023.01.10 |
CodeDeploy가 왜 배포 실패했을까? (0) | 2023.01.07 |
댓글