2018년 11월 22일 AWS 장애.. 간단 정리.
그냥 정리해봤음.
서울 리전(AP-NORTHEAST-2)에서 2018년 11월 22일에 발생된 서비스 중단 상황에 대한 기본적인 끄적거림.
AWS의 공식적인 발언을 요약하면 다음과 같다.
1. 한국시간 8시 19분에서 9시 43분까지의 장애 상황으로 이야기됨.
2. 서울 리전의 EC2 인스턴스의 내부 DNS 이슈가 있었음.
요약하자면... '내부 DNS확인 서비스의 이슈'이며, DNS 확인 서버군(resolver fleet)의 정상 호스트 숫자가 감소함에 따라 발생한 문제라고 정리한다. 외부 DNS확인 서비스는 문제없었다고 나름 자세하게 소개하고 있다. ( 이 내용이 뭔지는 다음의 박스 내용을 참조하기를 바랍니다. )
내부 DNS 기반 HA 구성의 간단한 설명... 끄적끄적...
AWS는 ELS, AuroraDB 등의 가용성을 높이기 위해서 HA(High Availability)를 위해서 DNS를 활용하며, 서버( 인스턴스 )의 숫자를 늘리기 위해서 내부 DNS를 세팅하고, 여러 개의 서버 ip를 동록 하고 이를 DNS를 통해서 배분 관리하는 방식으로 서비스의 가용성을 향상함.
이번 문제는 이러한 내부의 DNS확인 서비스에서 최소 정상 호스트를 지정하는 설정을 잘못 제거함. ( 누군지 모르겠지만.. AWS내부 서비스 관리자 ). 이로 인해서 기본 설정값이 매우 낮다고 해석됨에 따라서, 고객 EC2 인스턴스 내의 DNS 쿼리가 실패하면서 무수한 커넥션 에러를 뿜어냄...
하여간, 누군지 모를 내부의 설정 미스 때문에... 전체 서비스에 영향을 받았고, 이것에 대한 의미적 구성 검증(semactic configuration validation)을 구현했다는 말로 해결했다고 한다.
간단한 설명... 끄적끄적...
최소한의 정상 호스트를 검증할 수 있는 validation code를 삽입해서, 향후 동일 이슈가 발생되지 않도록 코드 처리했음.
DevOps관계자들이나 서버 개발자들이 가장 크게 인지한 부분은 AWS의 SLA 계약관계에 없던, AWS내부의 DNS 서비스에 장애가 발생해서 문제가 날 수 있다는 것을 인지하지 못했다는 점이다.
보통 서비스를 안정적으로 가동하기 위해서 EC2를 사용하고, 이중화 및 로드밸런서, RDS장애 대비를 위한 Read Relica 인스턴스 추가 등을 주로 사용하고, 일라스틱도 ElastiCache 멀티 인스턴스 클러스터링 정도로만 해도 충분하게 방어될 것이라고 생각했다. ( 하지만, 역시.. AWS내부도 동일하다. )
하지만, 전혀 예상하지 않았던... AWS내부의 DNS확인 서비스로 인해서 장애가 발생한 것은 매우 드문케이스라고 정의할 수 있다.
문제는 위의 요약본을 읽게 되면 마치... EC2 인스턴스의 장애에는 문제가 없지만. 외부 DNS 서비스인 Routh53의 오류가 아니므로, EC2의 서비는 문제가 없는 것처럼 이야기하는 상황으로 설명을 하고 있다. 물론, 이 이야기는 틀린 이야기는 아니다.
EC2의 전체적인 서비스에는 문제가 없었으나, 실제 RDS, Lambsa, S3 등의 거의 모든 서비스는 DNS장애로 'Connection Error'를 마구 뱉어냈다.
분명, EC2관련 서비스는 문제가 없었다는 문장은 성립한다. 하지만, 전체적인 서비스의 진행은 그러하지 않았다. 미국적인 발상이라고 해야 하는지... SLA 계약에 없다는 식으로 해석을 해야 하는지는 정말 법전을 뒤져봐야 할 문제이다.
안타깝지만... 클라우드의 전체적인 의존관계에 대한 SLA는 보장하지 않고 있다.
서비스의 전체적인 안정성과 DevOps 관련된 이슈에 대한 진일보한 서비스 형태나 계약형태가 등장할 것으로 보인다. 그리고, 내부적인 서비스 진행을 위해서 외부 고객들에게 인지되지 못한 내부의 internal DNS의 이슈는 주변의 전문가들은 언제나 이야기가 되던 것들이었다.
(술자리에서 가끔 이야기하던 것들이다. 그들은 내부에 어떤 식으로 구성하는가? 에 대해서 수다를 떤 적이 있는데.. 그 이슈가 터진 셈이다.)
분명한 것은 AWS 서비스의 SLA가 한 가지 더 진일보한 형태가 나올 가능성이 있으며, 동일한 이슈로 문제를 일으키지 않기 위해서 그들 내부적으로 이중화는 좀 더 정밀하게 가지고 갈 것이다.
AWS의 장애 시간이 84분이라고 한다.
그리고, 15분 동안 문제를 파악하고, 장애 해결을 했다고 한다. 분명한 것은 내부에서 정말 자동화된 복구가 진행된 것 같지 않다는 것이 주변 서버 개발자들의 의견이다. 그들 역시 내부의 서비스를 믿고 맡길만한 인프라 서비스가 없기 때문에 과거 IDC에서 설정하거나, 문제가 있었던 그 형태 그대로 벌어지고 있다는 것은... 그들 역시 사람이라는 것을 인지하게 한다.
다만...
KT의 화재로 장애가 발생하고, 디지털 난민이 된 어떤 사람의 이야기보다... 화재로 2층의 IDC센터에 있던 서버 장비들이 훼손되면서 서비스의 유지가 불완전해진 어떤 상황들을 보면...
클라우드의 인프라에서 발생한 장애는 큰 이슈가 아닌 것이라고 생각이 든다.
실제, 저 역시도.. AWS의 서비스를 주로 사용하고 있고, 서울 리전을 일부 사용하고 있었지만... 매우 다행하게도 서울 리전을 그렇게 믿지 않아서 일부 서비스만 서울 리전을 사용하고 있었다는 것이 전체적인 서비스를 안정적으로 동작하게 하는 결정이었다는 생각도 해봅니다.
당장에 할 수 있는 좋은 방법은 AWS 멀티 리전이 가장 효과적이라고 주변에 조언을 해봅니다.
ps...
다만, 개인정보를 국외의 리전에 만드는 것은 한국형(?)이어서 안된다는 것을 다시 한번 이야기 드립니다. 그래서, 한국에서는 '개인정보'를 중심으로 움직이는 커머스와 같은 서비스들은 멀티 클라우드가 정답이고, 순수 솔루션 위주의 SaaS인 경우에만 멀티리전이 합당하겠죠.
한국의 거대한 개발자 조직을 가지고 있는 쿠팡도 이번 AWS장애에는 속수무책이었던 이유이기도 합니다. 아마도, 멀티 클라우드를 선택하지 않을까 합니다. 배민도 마찬가지이구요.
