ㅍㅍㅅㅅ

출처: 아시아-태평양 서울 리전(AP-NorthEast-2)의 Amazon EC2 DNS 확인(Resolution) 이슈 요약

22일 AWS 서울 리전 장애 관련하여 AWS 측의 공지를 읽고, 내가 가장 놀란 부분은, 내가 지금까지 AWS를 사용하면서 한 번도 AWS의 내부 DNS에 장애가 발생할 수도 있다는 걸 생각해본 적이 없다는 거다. AWS 리전 내 DNS는 AWS의 정식 상품이나 서비스가 아니므로, 당연히 이에 대해서는 SLA에 명시되어 있지도 않다.

나는 EC2 장애 대비하여 EC2 인스턴스를 이중화하고 로드밸런서를 쓴다, RDS 장애 대비를 위해 Read Replica 인스턴스를 둔다, ElastiCache도 멀티 인스턴스로 클러스터링한다, 정도만 생각했다.

이번처럼 리전 DNS 장애가 발생하면 AWS 도메인으로 endpoint 가 지정되는 리전 내 AWS 서비스 간 네트워크에 장애가 발생하므로, 거의 모든 서비스가 장애를 일으킬 수 있다는 건 상상조차 해본 적이 없었다.

AWS 측의 공지를 읽고 놀란 점은 또 있다.

EC2 인스턴스는 거의 IP로 접속을 하므로 내부 DNS 장애에 영향을 받지 않는 게 사실이고, 외부 DNS 인 Route53 장애가 아니니 당연히 EC2 외부 DNS 확인 과정은 영향이 없다.

장애로 인해 내 사이트는 Connection Error를 빵빵 내버렸는데, AWS는 EC2 측의 공지문 어디에도 EC2 DNS 장애로 인해 영향을 받은 서비스 범위가 어디까지인지 전혀 명시되어 있지 않다.

실제로는 RDS, ElastiCache, Lambda, S3, DynamoDb 등 거의 모든 서비스가 네트워크가 안 되는 상황이었는데 말이다. AWS 공지문은 "술은 마셨으나 음주 운전은 아니다, 앞으로 술을 줄이도록 하겠다"라는 말과 크게 다르지 않아 보인다.

AWS는 서비스 장애로 인한 피해 보상을 규정하고 있다. Service Level Agreement가 바로 그것이다. 그런데, 공지문에서 장애로 인한 서비스 범위를 밝히지 않음으로써 고객들은 스스로 피해 범위를 파악해야 하는 어려움이 있고, 반대로 AWS는 피해 보상 규모를 축소할 수 있는 영민함을 발휘한 것이다.

AWS에서는 장애 시간이 84분이었고, 장애 원인 파악에 초기 15분, 나머지는 장애 해결에 걸린 시간이었다고 한다. 장애 해결 방법이 삭제된 EC2 인스턴스를 다시 늘린 거라고 하는데, 이에 70분 가까이 소요되었다고 하는 건, Auto Scaling을 클라우드 서비스의 장점으로 내세우는 것 치고는 시간이 오래 걸린 거 아닌가 생각이 든다.

AWS 서비스의 SLA가 개별 서비스에 관해서 규정되어 있는 상황이다. EC2는 어떻고, RDS는 어떻고, S3는 어떻고 하는 식이다. 그런데, 서비스를 개발 운영할 때 필수적으로 클라우드 서비스 사이에는 의존성이 생길 수밖에 없다.

예를 들어, EC2, RDS를 이용하고 있다고 하면, RDS가 장애가 나도 서비스 장애, EC2 장애가 나도 서비스 장애를 겪게 된다. 즉, 개별 서비스의 SLA가 실제 서비스를 운영하는 처지에서는 별로 도움이 안 되는 상황이다.

그래서, 클라우드 서비스 업체들은 서비스 개별 SLA 제시를 할 게 아니라, 고객 관점에서 포괄적인 Total SLA를 제시할 필요가 있다. 업체들이 빅데이터, 인공지능, 블록체인, DevOps 등 신기술을 도입한 서비스 출시 경쟁을 벌이고 있는데, 서비스 안정성 측면에서 Total SLA에 조금이라도 관심을 두면 고맙겠다.