EBS 지연 현상

최근 서비스를 배포하는 도중 이상한 현상을 발견했다.

어떤 경우는 CodeDeploy가 10분만에 끝나고 어떤건 30분이 넘어도 끝나지 않았다. 배포 프로세스를 보면 미리 생성된 골든이미지를 배포 단계에서 S3에서 데이터를 EBS로 가져온 뒤 서비스를 실행하는 순서다.

 

지연 발생한 경우

지연된 배포

정상인 경우

정상 배포

처음에는 EBS의 IOPS를 의심했다.

같음 배포임에도 Writes Throughput의 지표가 상이한점, Read/Write Size는 SSD Type의 EBS특성상 256mb로 제한되어 있기에 정상적인 상태이긴 했다.

 

그래서 GP3의 기본 throughput 125에서 500으로 올렸다.

EBS 자체 성능 제한으로 Read/Write Size의 지표는 같으나 Write Bandwidth와 Write Throughput의 성능이 눈에띄게 달라졌다. EBS문제는 확실하긴 하다.

참고로 GP3의 Throughput은 (iops * 0.25m/s) 공식을 따르기에 사용하고있는 500Gb기준으로 최대 750까지 가능했따. 물론, 그만큼 비용이 높아진다.

 

그러다가 지표를 다시 한번 살펴보던중 Latency가 눈에 보였다. EBS는 스냅샷에서 파생되서 여러 스토리지가 생기고 EC2에 붙었을때 IOPS 지연이 발생한다.

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html

Amazon EBS 빠른 스냅샷 복원 - Amazon Elastic Compute Cloud

생각해보니 지연이 발생하고 초기 init하는 부분에서 문제가 생겨 이걸 활성화 시켜주면 어떨까? 하는 생각에 Support를 통해 최대 갯수를 늘렸고 바로 배포전 활성화 시켰다.

결과를 보니 기존에 150~500까지 치던 Latency 지표가 정상으로 돌아왔다. 역시 이게 문제였다.

 

그래서 이제 배포전 EBS fast snapshot restore 기능을 활성화 시키고 배포후 비활성화 시켰다.(이게 은근 돈이 많이 들어서 배포 완료후 트리거를 하나 더 두었다)

 

-해 결-