가용영역을 늘려도 무너진다: GCP VMware Engine 장애로 본 스트레치 클러스터와 BGP 플래핑
🤖 AI Summary
7월 14일(현지 시각), Google Cloud VMware Engine(GCVE)의 스트레치 클러스터 고객들이 여러 리전에서 존 단위 네트워크 장애를 겪었습니다. 특이한 점은 존 자체가 죽지 않았다는 것입니다. 공식 로그 기준으로 VM은 정상 동작 중이었고 스토리지·컴퓨트도 영향이 없어 보인다고 기록됐습니다. 끊긴 것은 존 사이의 연결이었습니다. 공식 로그는 존 간 통신 실패와 BGP 세션 플래핑, 그리고 witness 어플라이언스 도달 불가로 상태 동기화가 멈춘 상황을 확인했습니다. 복원력을 위해 두 존에 걸쳐 만든 구조가 그 복원력을 잃었고, 시간이 지나자 공식 로그는 VM 격리와 쓰기 데이터 유실 가능성까지 경고했습니다. 원인은 네트워크 설정 변경 하나였고, 해결은 마지막 정상값으로의 롤백이었습니다. 이 글은 공식 인시던트 로그를 기준으로 사건의 전개를 따라가며, 이중화 구조를 운영하는 팀이 점검할 지점을 정리합니다.
블로그 목차
7월 14일, 존은 살아 있는데 연결이 끊겼습니다
Google 공식 인시던트 로그의 첫 공지는 이렇게 시작합니다. GCVE 스트레치 클러스터 고객들이 여러 리전에 걸쳐 존 단위 네트워크 연결 장애를 겪고 있다는 것. 시작 시각은 현지 시각(US/Pacific) 7월 14일 10시였고, 최종 영향 지역은 시드니(australia-southeast1)·멜버른(australia-southeast2)·프랑크푸르트(europe-west3) 세 곳으로 기록됐습니다. 조사 도중 후보에 올랐던 토론토(northamerica-northeast2)는 이후 영향받지 않은 것으로 정정됐습니다.
흥미로운 건 장애의 모양새입니다. 데이터센터가 불탄 것도, 존 하나가 통째로 내려간 것도 아닙니다. 공식 로그도 스토리지·컴퓨트는 영향이 없어 보이며 VM은 정상 동작 중이라고 밝혔습니다(연결은 저하될 수 있다는 단서와 함께). 지난 5월 AWS use1-az4 사례처럼 가용영역 내부의 물리 인프라가 무너진 사건과는 정반대 방향입니다. 이번에 끊긴 것은 존이 아니라 존과 존 사이였습니다.
스트레치 클러스터의 급소: 존 간 연결과 witness
스트레치 클러스터는 하나의 클러스터를 두 존에 걸쳐 늘여 놓은 구성입니다. 한쪽 존에 문제가 생기면 다른 쪽이 즉시 이어받는 것, 즉 빠른 페일오버가 존재 이유입니다. 그러려면 두 존은 서로의 상태를 끊임없이 동기화해야 하고, 두 존이 갈라졌을 때 어느 쪽을 살릴지 판정해 줄 제3의 심판, witness가 필요합니다.
이번 장애는 정확히 그 급소에서 발생했습니다. 공식 로그의 조사 결과를 그대로 옮기면, 먼저 "클러스터 존 간의 근본적인 통신 실패와 BGP 세션 플래핑"이 확인됐습니다. BGP 세션이 오르내리기를 반복하며(플래핑) 존 사이의 경로가 불안정해진 것입니다. 이어서 로그는 이렇게 설명합니다. "영향받은 존들과 witness 어플라이언스 사이의 네트워크 연결이 상실됐다." 그리고 "witness에 도달할 수 없기 때문에, 클러스터 존들은 상태를 안전하게 동기화할 수 없다"고요.
심판이 사라진 클러스터는 안전을 위해 동기화를 멈춥니다. 데이터가 갈라지는(스플릿 브레인) 최악을 피하기 위한 올바른 행동입니다. 다만 초기 공지의 "VM 정상 동작"이 끝이 아니었습니다. 시간이 지나며 공식 로그는 "영향받은 사이트의 VM들이 격리되고 있으며, 쓰기 가능한 데이터를 잃을 수 있다"고 심각도를 높였고, 이에 건강한 반대편 존으로의 VM 마이그레이션을 1차 완화책으로 권고했습니다. 복원력만 사라진 게 아니라, 그 상태가 길어지면 데이터 접근 자체가 위태로워지는 사건이었던 셈입니다.
원인은 설정 변경 하나, 해법은 롤백: 11시간 46분
원인 조사도 공식 로그에 기록돼 있습니다. 예비 분석 결과는 "네트워크 설정 변경이 존 간 네트워크 중단의 원인이었다"는 것. 해법도 그만큼 담백했습니다. 엔지니어링 팀은 "문제가 된 설정을 마지막 정상값(last-known good)으로 롤백"해 상황을 완화했습니다. 로그 기준 인시던트는 10:00에 시작해 21:46에 종료됐습니다(모두 US/Pacific). 약 11시간 46분입니다.
여기서 두 가지가 눈에 들어옵니다. 첫째, 하이퍼스케일러의 다중 존 구조조차 설정 변경 하나가 장애 벡터가 된다는 것. 둘째, 결국 복구를 만든 것은 화려한 기술이 아니라 "마지막 정상값으로 되돌릴 수 있는 상태"를 유지해 온 운영 원칙이라는 것. 이전 상태를 보존하고 되돌릴 길을 확보한다는 원칙은 무중단 배포 글에서 다룬 롤백 설계와 정확히 같은 문법입니다.
이중화 구조를 운영한다면 점검할 세 가지
이번 사건이 남긴 질문은 명확합니다. 우리의 복원력 계층은, 그 자체가 실패할 때 어떻게 되는가.
연결도 실패 도메인입니다.이중화를 이야기할 때 우리는 구성 요소(서버·존·리전)의 생사만 세는 경향이 있습니다. 그러나 이번 사건의 급소는 존이 아니라 존 간 링크와 witness 경로였습니다. 이중화 구조라면그 사이의 연결과 quorum 경로를 별도의 실패 도메인으로목록에 올리고 모니터링해야 합니다.설정 변경은 장애 벡터입니다.하이퍼스케일러조차 설정 변경 하나로 다중 리전이 흔들렸습니다. 변경 전 검증 절차와, 문제 시마지막 정상값으로 즉시 되돌릴 롤백 경로가 준비돼 있는지가 복구 시간을 결정합니다.복원력의 상실을 감지할 신호가 필요합니다.이번 장애의 무서움은 초기엔 VM이 정상 동작해 평소 지표상 아무 문제 없어 보였다는 데 있습니다. 안전망(복원력)은 이미 사라졌고, 시간이 지나자 VM 격리·쓰기 데이터 위험으로 번졌습니다.동기화 상태·quorum 도달성처럼 복원력 계층 자체의 건강을 말해 주는 지표를 경보로 두어야, 안전망 없이 운행 중이라는 사실을 즉시 알 수 있습니다.
이것만 기억하세요
7월 14일 GCVE 스트레치 클러스터 장애의 급소는 존이 아니라 존 간 연결(BGP 플래핑)과 witness 도달 불가였습니다. VM은 초기엔 정상 동작했지만 동기화가 멈추며 복원력이 사라지고 이후 VM 격리·쓰기 데이터 유실까지 경고된 약 12시간이었고, 원인은 네트워크 설정 변경, 해법은 마지막 정상값 롤백이었습니다. 교훈은 하나입니다. 이중화의 "사이"와 quorum 경로도 실패 도메인으로 관리할 것.
자주 묻는 질문 (FAQ)
Q. 스트레치 클러스터가 무엇인가요?
하나의 클러스터를 두 가용영역(존)에 걸쳐 늘여 놓은 구성입니다. 한쪽 존에 문제가 생겨도 다른 쪽이 이어받아 빠르게 복구하는 복원력이 존재 이유예요. 이를 위해 두 존은 상태를 계속 동기화하고, 갈라졌을 때 판정을 도와줄 witness 같은 제3의 구성 요소가 함께 동작합니다.
Q. witness 어플라이언스는 무슨 역할을 하나요?
두 존이 갈라졌을 때 어느 쪽을 살릴지 판정을 돕는 제3의 심판입니다. 이번 장애에서 공식 로그는 존들과 witness 사이의 연결이 상실됐고, witness에 도달할 수 없어 존들이 상태를 안전하게 동기화할 수 없다고 설명했어요. 심판이 사라지면 클러스터는 안전을 위해 동기화를 멈출 수밖에 없습니다.
Q. VM이 계속 돌았다는데 무엇이 문제였나요?
초기 공식 로그는 VM이 정상 동작 중이라고 밝혔지만, 이후 업데이트에서 영향받은 사이트의 VM이 격리되고 쓰기 가능한 데이터를 잃을 수 있다고 심각도를 높였고, 건강한 반대편 존으로의 VM 마이그레이션을 1차 완화책으로 권고했어요. 복원력 상실에서 시작해 데이터 접근까지 위태로워진 약 12시간입니다.
Q. 원인이 정말 설정 변경 하나였나요?
공식 로그 기준으로 예비 분석은 네트워크 설정 변경이 존 간 중단의 원인이었다고 밝혔고, 팀은 그 설정을 마지막 정상값으로 롤백해 완화했습니다. 조사 과정에서 존 간 통신 실패와 BGP 세션 플래핑이 확인됐어요. 인시던트는 현지 시각 10:00에 시작해 21:46에 종료됐습니다.
Q. 우리 인프라에서는 무엇을 점검해야 하나요?
세 가지입니다. 이중화 구성 요소만이 아니라 그 사이의 연결(존 간 링크·quorum 경로)을 실패 도메인으로 모니터링할 것, 설정 변경을 장애 벡터로 보고 검증·롤백 절차를 갖출 것, 그리고 동기화 상태·quorum 도달성처럼 복원력 계층 자체의 건강 지표를 경보로 둘 것입니다.
