13. 긴급대응
18 Jul 2023 | Site Reliability Engineering
13. 긴급 대응
시스템에 문제가 생기면 어떻게 해야 할까?
- 가장 먼저 당황하지 말아야 한다.
- 마닝 ㄹ자신에게 너무 부담스럽다고 느껴진다면 다른 사람들에게 도움을 요청하자
- 만일 회사에 마련된 장애 대응 절차가 있다면 그 절차에 익숙해져야 한다.
테스트로 인한 장애
- 구글은 재난과 긴급 상황에 대한 사전적 테스트 접근법을 취하고 있다
- SRE들은 시스템에 장애를 일으킨 후 이로 인해 시스템이 어떻게 실패하는지를 지켜본 다음, 그 현상이 반복해서 발생하지 않도록 신뢰성을 향상시킬 수 있느 변경 사항을 적용
- 이 과정에서 어떤 취약점이나 숨겨진 의존성을 발견하면 조치 문서에 기록해 둔다.
- 그러나 간혹 우리의 예상과 실제 결과가 어긋날 때가 있다.
세부 내용
- 보유 중인 분산 MySQL 데이터베이스 중 하나에 포함된 테스트 데이터베이스를 통해 숨겨진 의존성 확인 하고자 함
- 계획 : 수백 대의 데이터베이스 중 한 데이터베이스에 대한 접근 차단
대응
- 테스트를 시작한지 몇 분이 지나지 않아 데이터베이스에 의존하는 여러 시스템으로부터 내부 및 외부 사용자가 핵심 시트엠에 접근하지 못한다는 오류를 보고받기 시작
- SRE들은 즉각 테스트의 실행을 중단.
- 그 다음 권한 변경을 되돌리려 했지만 작업에 실패
- 당황하지 않고 즉시 모여 변경된 권한을 어떻게 복구 할 수 있을 지 의논
- 이미 테스트가 완료된 방법을 이용해 복제(replicas) 및 장애 대비(failovers) 데이터베이스의 권한을 복구할 수 있었음
- 동시에 주요 개발자들에게 데이터베이스 애플리케이션 계층 라이르러리의 결함을 수정하도록 요청
- 한 시간 이내에 권한 복구 완료
- 이 테스트로 인해 영향을 받는 부분이 너무 광범위했으므로 라이브러리에 대한 신속한 수정이 이루어짐, 이 현상이 재발하지 않도록 하는 테스트 수행 계획도 수립
우리가 발견한 것들
테스트를 진행하면서 잘한 부분
- 이 장애에 영향을 받은 서비스들이 즉각적으로 문제를 보고 -> 테스트 즉시 종료
- 첫 장애 보고 이후 한 시간 안에 모든 권한을 완벽히 목구
- 후속 조치 항목 역시 신속하게 처리되어 동일한 장애에 대응할 수 있게 됨
- 동일한 장애가 재발하지 않는지 확인하기 위한 정기적인 테스트 계획 수립
깨달은 사실
- 숨겨진 의존관계에 대해 완전히 이해하고 있지 못함
- 테스트 환경에서의 롤백 절차를 테스트한 적이 없었으므로 이 절차 역시 결함이 있었음
- 대량의 테스트를 시행하기에 앞서 롤백 절차를 완벽하게 테스트해야 함
변경으로 인한 장애
- 구글은 어마어마한 수의 설정을 관리하고 있으며 지속적으로 변경이 발생 함
- 이로인한 장애를 차단하기 위해, 변경된 설정으로 인해 뭔가 예상하지 못한 결과나 동작이 발생하지 않음을 확인하기 위한 많은 테스트를 수행함
- 하지만 모든 테스트를 하는 것을 불가능
세부 내용
- 어느 금요일, 서비스의 악의적인 사용을 방지하기 위한 목적으로 인프라스트럭처의 설정을 변경/적용함
- 이 인프라스트럭처는 기복적으로 외부로 노출되는 모든 서비스들과 함께 동작하는 것이었고, 변경된 설정을 이런 시스템을에게서 crash-loop를 유발함
- 구글의 내부 인프라스트럭처 역시 이 서비스들에 의존하고 있었으므로 많은 수의 내부 애플리케이션들도 갑자기 사용할 수 없게 됨
대응
- 불과 수초 만에 특정 사이트가 다운되엉ㅆ다는 모니터링 알림이 쏟아져 나옴
- 비상 대기 엔지니어들 몇 명이 근무 중이었지만 이들은 경험상 사내 네트워크 장애에 대한 알림이라고 믿을 수밖에 없는 알림을 계속해서 받았으므로 프로덕션 환경에 대한 백업용 접근이 가능한 (panic room이라고 불리는) 별도의 공간으로 모여듬, 그 후 사내용 네트워크 접근이 차단되어 발을 동동 구르던 엔지니어들도 이 공간에 합류
- 첫 설정이 적용된 이후 5분쯤 지나, 해당 설정을 적용한 엔지니어도 사내 장애를 인지했지만 더 큰 장애는 인지하지 못하고 첫 설정을 롤백하기 위해 다시 설정을 변경 적용 -> 서비스들이 되살아나기 시작
- 첫 설정 적용이후 10분쯤 지났을 무렵 비상 대기 엔지니어가 장애를 선언하고 내부 장애 조치 절차를 따르기 시작
- 사내에 장애 상황을 전파
- 설정을 적용했던 엔지니어는 비상 대기 엔지니어에게 장애의 원인이 자신이 적용한 설정 변경 때문인 것 같으며, 현재 해당 설정은 롤백된 상태라고 알림
- 그와는 별개로 일부 서비스들은 그와 무관한 버그 또는 처음 변경된 설정에 영향을 받아 생성된 잘못된 설정 때문에 한 시간이 지나도 여전히 복구가 되지 않음
우리가 발견한 것들
장애를 처리하면서 잘한 부분
- 모니터링 시스템은 거의 즉시 문제를 인지하고 알림을 발송
- 하지만 알림이 지속적으로 반복 발송되어 비상 대기 엔지니어들이 그 때문에 고군분투 함
- 일단 문제를 인지한 후의 장애 관리는 대체적으로 잘 진행 됨
- 구글이 보유한 대역 외 통신 시스템 적분에, 일부 더 복잡한 소프트웨어 스택이 사용 불가능했던 상황에서도 모든 사람들이 소통할 수 있었음 -> SRE가 고가용적이며 오버헤드가 낮은 백업 시스템을 보유해야 하는 이유
- 구글은 다르 ㄴ도구들에 대한 접근이 불가능한 상황에서도 업데이트를 수행하거나 설정 변경을 롤백할 수 있는 cli와 대체 접근 방식을 보유함
- 구글의 인프라스트럭처는 해당 시스템이 새로운 클라이언트에 전체 업데이트를 얼마나 빨리 제공했는지를 측정하는 또 다른 보호 계층을 제공 -> 이 동작 덕분에 크래시 루프의 무한 발생을 어느 정도 막아서 완전한 장애를 차단
- 행운도 작용함, 장애를 유발한 설정을 적용한 엔지니어가 롤백을 빠르게 함
깨달은 사실
- 카나리 테스트에서 이 장애를 잡아내지 못함
- 다음 분기에서 카나리 테스트와 자동화의 개선에 더 높은 우선순위를 두게 됨
- 이 장애가 발생하 ㄴ기간 동안, 단 몇 분만에 모든 지역이 오프라인 상태가 되었으므로 엄청난 양의 알림이 발송됨 -> 이는 비상 대기 엔지니어들이 실제로 필요한 작업을 하는데 큰 방해가 되었고, 의사소통도 어렵게 함
- 구글은 직접 개발한 도구에 대한 의존도가 높음, 장애 조치 및 의사소통을 위해 사용하는 소프트웨어 스택의 상당 부분은 장애 당시 크래시 루프가 발생한 작업들에 의존하고 있었음
절차에 의한 장애
- 구글은 자동화를 엄청 해놓음
- 이 자동화가 장애를 유발한 사례
세부 내용
- 곧 사용이 종료될 동일한 서버에 두 개의 시스템 종료 요청이 연속적으로 전달됨
- 그런데 두 번째 시스템 종료 요청에 자동화 시스템의 사소한 버그로 인해 전체 인프라스트럭처에서 동일한 설정으로 설치된 모든 서버에 대한 디스크삭제 요청이 큐에 기록됨
대응
- 두 번째 시스템 종료 요청이 발송되자마자, 비상 대기 엔지니어에게 첫 번째 작은 서버가 오프라인 모드로 전환되었다는 호출이 전달
- 조사 결과 해당 머신은 디스크삭제 큐의 요청 때문에 종료되는 것으로 파악 -> 통상적인 절차에 따라 비상 대기 엔지니어는 해당 지역의 트래픽을 다른 지역으로 우회 (해당 지역의 모든 머신이 제거되었기 때문)
- 얼마 지나지 않아 전 세계의 동일한 종류의 모든 서버들로부터 알림이 발송되기 시작… 모든 팀의 자동화 시스템 비활성화
- 한 시간 정도 지나자 모든 트래픽이 다른 지역으로 전송
- 복구를 시작함
- 3일 쯤 지나자 대부분의 서버들이 복구되고, 나머지는 한두 달 후에 복구 됨
우리가 발견한 것들
장애를 처리하면서 잘한 부분
- 대량의 서버 앞에 놓인 리버스 프록시는 소량의 서버를 처리하는 리버스 프록시와는 관리 방법이 매우 다르므로 대량의 서버가 영향을 받지는 않았다.
- 비상 대기 엔지니어는 트래픽을 소량의 서버군으로부터 대량의 서버군으로 빠르게 옮길 수 있었음
- 그러나 일부 네트워크링크에 부하가 몰리면서 네트워크 엔지니어들이 우회방법을 찾을 수밖에 없었음
- 소량의 서버군에 대한 시스템 종료 과정은 효율적으로 잘 동작함
깨달은 부분
- 근본적인 문제는 시스템 종료 자동화 서버가 전달된 명령의 유효성을 적절하게 판단하지 못한 것에 있었음
- 최초의 시스템 종료 문제가 발생한 서버에 대한 조치 이후, 해당 서버가 다시 가동되기 시작했을 때 시스템 종료 서버는 머신 랙으로부터 빈 응답을 받았다.
- 문제는 이 빈 응답을 걸러내지 못하고 머신 데이터베이스에 빈 필터를 그대로 전달해서 머신 데이터베이스가 디스크삭제 요청 서버에게 모든 머신의 디스크를 삭제할 것을 요청 한 것
- 머신의 재설치는 느리고 신뢰성이 떨어지는 작업이었음
- 머신 재설치 인프라스트럭처는 수천 대의 머신에 대한 동시 작업을 제대로 처리하지 못함
모든 문제가 해결 되었다
- 일단 긴급 상황이 종료되고 나면 뒷정리를 위한 시간을 마련하고 장애에 대해 문서를 작성하는 것
지난 일로부터 배우기. 그리고 반복하지 않기
장애에 대한 기록을 남기자
- 포스트모텀 (15장)
커다란, 어쩌면 불가능할지도 모를 것에 대한 질문을 던지자: 만일 … 라면?
- 건물에 전력이 끊어진다면?
- 네트워크 장비 랙이 물에 잠긴다면?
- 주 데이터센터에 갑자기 정전이 발생한다면?…
- 카오스 엔지니어링
사전 테스트 장려하기
- 회사의 전 직원이 블랙 포레스트로 워크숍을 간 토요일 새벽 2시에 장애가 발생 vs 공들여 리뷰한 테스트를 모니터링하고 있는 도중에 장애발생
결론
- 장애를 조치하는 사람을 우선 침착해야함 그리고 필요하다면 다른 사람들에게 도움을 요청할 수 있어야 함
- 이전에 발생한 장애를 연구하고 이로부터 새로운 것을 학습해야 함
- 시스템이 이런 종류의 장애에 더욱 잘 대처할 수 있도록 개선해야 함
- 장애가 발생할 때마다 문서화 해야함
- 사전테스트에 더욱 주의를 기울여야 함
13. 긴급 대응
시스템에 문제가 생기면 어떻게 해야 할까?
- 가장 먼저 당황하지 말아야 한다.
- 마닝 ㄹ자신에게 너무 부담스럽다고 느껴진다면 다른 사람들에게 도움을 요청하자
- 만일 회사에 마련된 장애 대응 절차가 있다면 그 절차에 익숙해져야 한다.
테스트로 인한 장애
- 구글은 재난과 긴급 상황에 대한 사전적 테스트 접근법을 취하고 있다
- SRE들은 시스템에 장애를 일으킨 후 이로 인해 시스템이 어떻게 실패하는지를 지켜본 다음, 그 현상이 반복해서 발생하지 않도록 신뢰성을 향상시킬 수 있느 변경 사항을 적용
- 이 과정에서 어떤 취약점이나 숨겨진 의존성을 발견하면 조치 문서에 기록해 둔다.
- 그러나 간혹 우리의 예상과 실제 결과가 어긋날 때가 있다.
세부 내용
- 보유 중인 분산 MySQL 데이터베이스 중 하나에 포함된 테스트 데이터베이스를 통해 숨겨진 의존성 확인 하고자 함
- 계획 : 수백 대의 데이터베이스 중 한 데이터베이스에 대한 접근 차단
대응
- 테스트를 시작한지 몇 분이 지나지 않아 데이터베이스에 의존하는 여러 시스템으로부터 내부 및 외부 사용자가 핵심 시트엠에 접근하지 못한다는 오류를 보고받기 시작
- SRE들은 즉각 테스트의 실행을 중단.
- 그 다음 권한 변경을 되돌리려 했지만 작업에 실패
- 당황하지 않고 즉시 모여 변경된 권한을 어떻게 복구 할 수 있을 지 의논
- 이미 테스트가 완료된 방법을 이용해 복제(replicas) 및 장애 대비(failovers) 데이터베이스의 권한을 복구할 수 있었음
- 동시에 주요 개발자들에게 데이터베이스 애플리케이션 계층 라이르러리의 결함을 수정하도록 요청
- 한 시간 이내에 권한 복구 완료
- 이 테스트로 인해 영향을 받는 부분이 너무 광범위했으므로 라이브러리에 대한 신속한 수정이 이루어짐, 이 현상이 재발하지 않도록 하는 테스트 수행 계획도 수립
우리가 발견한 것들
테스트를 진행하면서 잘한 부분
- 이 장애에 영향을 받은 서비스들이 즉각적으로 문제를 보고 -> 테스트 즉시 종료
- 첫 장애 보고 이후 한 시간 안에 모든 권한을 완벽히 목구
- 후속 조치 항목 역시 신속하게 처리되어 동일한 장애에 대응할 수 있게 됨
- 동일한 장애가 재발하지 않는지 확인하기 위한 정기적인 테스트 계획 수립
깨달은 사실
- 숨겨진 의존관계에 대해 완전히 이해하고 있지 못함
- 테스트 환경에서의 롤백 절차를 테스트한 적이 없었으므로 이 절차 역시 결함이 있었음
- 대량의 테스트를 시행하기에 앞서 롤백 절차를 완벽하게 테스트해야 함
변경으로 인한 장애
- 구글은 어마어마한 수의 설정을 관리하고 있으며 지속적으로 변경이 발생 함
- 이로인한 장애를 차단하기 위해, 변경된 설정으로 인해 뭔가 예상하지 못한 결과나 동작이 발생하지 않음을 확인하기 위한 많은 테스트를 수행함
- 하지만 모든 테스트를 하는 것을 불가능
세부 내용
- 어느 금요일, 서비스의 악의적인 사용을 방지하기 위한 목적으로 인프라스트럭처의 설정을 변경/적용함
- 이 인프라스트럭처는 기복적으로 외부로 노출되는 모든 서비스들과 함께 동작하는 것이었고, 변경된 설정을 이런 시스템을에게서 crash-loop를 유발함
- 구글의 내부 인프라스트럭처 역시 이 서비스들에 의존하고 있었으므로 많은 수의 내부 애플리케이션들도 갑자기 사용할 수 없게 됨
대응
- 불과 수초 만에 특정 사이트가 다운되엉ㅆ다는 모니터링 알림이 쏟아져 나옴
- 비상 대기 엔지니어들 몇 명이 근무 중이었지만 이들은 경험상 사내 네트워크 장애에 대한 알림이라고 믿을 수밖에 없는 알림을 계속해서 받았으므로 프로덕션 환경에 대한 백업용 접근이 가능한 (panic room이라고 불리는) 별도의 공간으로 모여듬, 그 후 사내용 네트워크 접근이 차단되어 발을 동동 구르던 엔지니어들도 이 공간에 합류
- 첫 설정이 적용된 이후 5분쯤 지나, 해당 설정을 적용한 엔지니어도 사내 장애를 인지했지만 더 큰 장애는 인지하지 못하고 첫 설정을 롤백하기 위해 다시 설정을 변경 적용 -> 서비스들이 되살아나기 시작
- 첫 설정 적용이후 10분쯤 지났을 무렵 비상 대기 엔지니어가 장애를 선언하고 내부 장애 조치 절차를 따르기 시작
- 사내에 장애 상황을 전파
- 설정을 적용했던 엔지니어는 비상 대기 엔지니어에게 장애의 원인이 자신이 적용한 설정 변경 때문인 것 같으며, 현재 해당 설정은 롤백된 상태라고 알림
- 그와는 별개로 일부 서비스들은 그와 무관한 버그 또는 처음 변경된 설정에 영향을 받아 생성된 잘못된 설정 때문에 한 시간이 지나도 여전히 복구가 되지 않음
우리가 발견한 것들
장애를 처리하면서 잘한 부분
- 모니터링 시스템은 거의 즉시 문제를 인지하고 알림을 발송
- 하지만 알림이 지속적으로 반복 발송되어 비상 대기 엔지니어들이 그 때문에 고군분투 함
- 일단 문제를 인지한 후의 장애 관리는 대체적으로 잘 진행 됨
- 구글이 보유한 대역 외 통신 시스템 적분에, 일부 더 복잡한 소프트웨어 스택이 사용 불가능했던 상황에서도 모든 사람들이 소통할 수 있었음 -> SRE가 고가용적이며 오버헤드가 낮은 백업 시스템을 보유해야 하는 이유
- 구글은 다르 ㄴ도구들에 대한 접근이 불가능한 상황에서도 업데이트를 수행하거나 설정 변경을 롤백할 수 있는 cli와 대체 접근 방식을 보유함
- 구글의 인프라스트럭처는 해당 시스템이 새로운 클라이언트에 전체 업데이트를 얼마나 빨리 제공했는지를 측정하는 또 다른 보호 계층을 제공 -> 이 동작 덕분에 크래시 루프의 무한 발생을 어느 정도 막아서 완전한 장애를 차단
- 행운도 작용함, 장애를 유발한 설정을 적용한 엔지니어가 롤백을 빠르게 함
깨달은 사실
- 카나리 테스트에서 이 장애를 잡아내지 못함
- 다음 분기에서 카나리 테스트와 자동화의 개선에 더 높은 우선순위를 두게 됨
- 이 장애가 발생하 ㄴ기간 동안, 단 몇 분만에 모든 지역이 오프라인 상태가 되었으므로 엄청난 양의 알림이 발송됨 -> 이는 비상 대기 엔지니어들이 실제로 필요한 작업을 하는데 큰 방해가 되었고, 의사소통도 어렵게 함
- 구글은 직접 개발한 도구에 대한 의존도가 높음, 장애 조치 및 의사소통을 위해 사용하는 소프트웨어 스택의 상당 부분은 장애 당시 크래시 루프가 발생한 작업들에 의존하고 있었음
절차에 의한 장애
- 구글은 자동화를 엄청 해놓음
- 이 자동화가 장애를 유발한 사례
세부 내용
- 곧 사용이 종료될 동일한 서버에 두 개의 시스템 종료 요청이 연속적으로 전달됨
- 그런데 두 번째 시스템 종료 요청에 자동화 시스템의 사소한 버그로 인해 전체 인프라스트럭처에서 동일한 설정으로 설치된 모든 서버에 대한 디스크삭제 요청이 큐에 기록됨
대응
- 두 번째 시스템 종료 요청이 발송되자마자, 비상 대기 엔지니어에게 첫 번째 작은 서버가 오프라인 모드로 전환되었다는 호출이 전달
- 조사 결과 해당 머신은 디스크삭제 큐의 요청 때문에 종료되는 것으로 파악 -> 통상적인 절차에 따라 비상 대기 엔지니어는 해당 지역의 트래픽을 다른 지역으로 우회 (해당 지역의 모든 머신이 제거되었기 때문)
- 얼마 지나지 않아 전 세계의 동일한 종류의 모든 서버들로부터 알림이 발송되기 시작… 모든 팀의 자동화 시스템 비활성화
- 한 시간 정도 지나자 모든 트래픽이 다른 지역으로 전송
- 복구를 시작함
- 3일 쯤 지나자 대부분의 서버들이 복구되고, 나머지는 한두 달 후에 복구 됨
우리가 발견한 것들
장애를 처리하면서 잘한 부분
- 대량의 서버 앞에 놓인 리버스 프록시는 소량의 서버를 처리하는 리버스 프록시와는 관리 방법이 매우 다르므로 대량의 서버가 영향을 받지는 않았다.
- 비상 대기 엔지니어는 트래픽을 소량의 서버군으로부터 대량의 서버군으로 빠르게 옮길 수 있었음
- 그러나 일부 네트워크링크에 부하가 몰리면서 네트워크 엔지니어들이 우회방법을 찾을 수밖에 없었음
- 소량의 서버군에 대한 시스템 종료 과정은 효율적으로 잘 동작함
깨달은 부분
- 근본적인 문제는 시스템 종료 자동화 서버가 전달된 명령의 유효성을 적절하게 판단하지 못한 것에 있었음
- 최초의 시스템 종료 문제가 발생한 서버에 대한 조치 이후, 해당 서버가 다시 가동되기 시작했을 때 시스템 종료 서버는 머신 랙으로부터 빈 응답을 받았다.
- 문제는 이 빈 응답을 걸러내지 못하고 머신 데이터베이스에 빈 필터를 그대로 전달해서 머신 데이터베이스가 디스크삭제 요청 서버에게 모든 머신의 디스크를 삭제할 것을 요청 한 것
- 머신의 재설치는 느리고 신뢰성이 떨어지는 작업이었음
- 머신 재설치 인프라스트럭처는 수천 대의 머신에 대한 동시 작업을 제대로 처리하지 못함
모든 문제가 해결 되었다
- 일단 긴급 상황이 종료되고 나면 뒷정리를 위한 시간을 마련하고 장애에 대해 문서를 작성하는 것
지난 일로부터 배우기. 그리고 반복하지 않기
장애에 대한 기록을 남기자
- 포스트모텀 (15장)
커다란, 어쩌면 불가능할지도 모를 것에 대한 질문을 던지자: 만일 … 라면?
- 건물에 전력이 끊어진다면?
- 네트워크 장비 랙이 물에 잠긴다면?
- 주 데이터센터에 갑자기 정전이 발생한다면?…
- 카오스 엔지니어링
사전 테스트 장려하기
- 회사의 전 직원이 블랙 포레스트로 워크숍을 간 토요일 새벽 2시에 장애가 발생 vs 공들여 리뷰한 테스트를 모니터링하고 있는 도중에 장애발생
결론
- 장애를 조치하는 사람을 우선 침착해야함 그리고 필요하다면 다른 사람들에게 도움을 요청할 수 있어야 함
- 이전에 발생한 장애를 연구하고 이로부터 새로운 것을 학습해야 함
- 시스템이 이런 종류의 장애에 더욱 잘 대처할 수 있도록 개선해야 함
- 장애가 발생할 때마다 문서화 해야함
- 사전테스트에 더욱 주의를 기울여야 함
Comments