2020년 12월 19일, AWS의 서울 리전에서 ELB 관련 이슈로 일부 서비스가 일시적으로 장애를 겪었습니다. 장애에 대한 영향을 확인해보려면 계정별로 Personal Health Dashboard 에서 확인할 수 있습니다.

AWS에서 공지한 장애 내용

저희는 19일 당일에는 특별힌 이슈가 없었는데, 이후에 장애 관련 영향을 파악하는 도중에 재미있는 사실을 발견하여 공유할까 합니다.

알려지지 않은 장애

AWS에 따르면 장애는 19일에 일시적으로 NLB에 대해서 발생하였고, 얼마 지나지 않아서 해결되었다고 합니다. OpsNow에서는 NLB를 많이 사용하지 않기 때문에 큰 영향은 없을 것으로 생각했는데, 의외로 CLB에서 문제가 발견되었습니다. 문제를 발견하게 된 계기는 바로 CloudWatch의 로그 수집 비용이었습니다.

이상한 스파이크가 보입니다.

OpsNow는 B2B 솔루션이라서 트래픽이 급증하는 경우는 거의 발생하지 않습니다. 그럼에도 불구하고 안정적이던 CloudWatch의 VendedLog-Bytes에 대한 비용이 갑자기 늘어난 것을 확인할 수 있습니다. 그리고 이처럼 이상 트래픽이 발생한 시점은 12월 19일이 아니라 18일에 집중되어 있으며, 17일에도 일부 발생한 것으로 추측됩니다. 이틀에 걸쳐서 약 80달러 정도의 비용이 증가했습니다.

비용 증가의 주범은 바로 VPC 플로우 로그였습니다. 플로우 로그는 CloudWatch의 로그 그룹으로 저장되는데, 해당 로그 그룹의 IncomingBytes가 다음과 같이 급격하게 늘어난 것을 확인할 수 있었습니다.

17일과 18일에 걸쳐서 이상 트래픽이 보입니다.

CloudWatch 로그를 좀 더 상세하게 분석해서 VPC 플로우 로그에 쌓인 데이터가 어디서 발생한 것인지 찾아보았습니다. 그리고 그 원인은 앞서 언급한 바와 같이, NLB가 아니라 CLB였습니다.

중앙에서 좌측이 17일의 스파이크, 정 중앙은 18일의 지속적인 트래픽입니다.

CLB의 EstimatedProcessedBytes 메트릭을 자세히 보면 17일에는 스파이크가 발생했고, 18일에는 6시간 가량의 알 수 없는 이상 트래픽이 발생한 것을 확인할 수 있었습니다. 그리고 이런 현상은 다수의 CLB에서 발견되었습니다.

이게 정말 이상 트래픽인지 어떻게 판단할 수 있을까요? CLB의 EstimatedProcessedBytes 메트릭을 6시간 단위로 합치고 2020년 전체에 대한 메트릭을 살펴보면 손쉽게 알 수 있습니다.

12월 18일에 스파이크가 나타납니다.

1년 전체를 살펴봤음에도 전례없는 엄청난 수치를 기록하고 있습니다. 통상적인 서비스 트래픽이 절대 아니라는 것입니다. 문득 이러한 사실을 깨닫고 나니, 19일의 장애는 사실 17일과 18일에 이미 다른 곳에서 발생했고 그 여파가 19일에 나타난 것이 아닌가 하는 추측을 해볼 수 있습니다.


OpsNow에서 사용하는 서비스는 그 양이 엄청나게 많지는 않아서 로그 비용만 80달러의 이상 비용이 발생하였습니다. AWS에서는 위와 같은 CLB 문제에 대해서는 별도로 공지를 하지 않았기 때문에, 결국 이러한 부분은 저희 스스로 찾아서 환불을 요구할 수밖에 없습니다.

이 글을 보시는 분들도 장애가 발생하면 AWS의 공지만 보고 지나치지 마시고 실제로 그 장애가 서비스에 얼마나 영향을 미쳤는지를 반드시 확인해보시기 바랍니다.