#SRE #장애대응
박주희 2021.06.30
SRE팀에서 가장 중요한 업무 중 하나는 장애 대응입니다. 많은 서비스 회사가 장애에 민감하게 반응합니다. 장애로 인해 금전적 손해가 발생하기 때문이기도 하지만 그보다 더 큰 이유는 장애로 인한 고객 불편이 장기적으로 서비스의 신뢰를 하락시킬 수 있기 때문입니다. 장애는 서비스의 성장, 서비스의 변화 등 다양한 과정 중에서 발생하는 성장통이기 때문에 장애가 발생하는 것을 원천적으로 차단할 방법은 없습니다. 그렇기에 빠르고 적절히 장애에 대응해 신뢰도 하락을 최소화하는 일이 중요합니다. 장애가 발생하더라도 영향 범위를 최소화하고, 빠르게 복구하며, 고객에게 적절한 정보를 제공하고, 같은 불편을 겪지 않도록 조처를 하는 모든 과정이 고객의 신뢰를 지키는 방법입니다.
장애 탐지
장애는 시스템 알람으로 탐지할 수도 있고, 고객 센터로 인입되는 문의를 통해서도 인지할 수 있습니다.
시스템 알람을 통한 탐지
모든 시스템에는 이상 현상을 감지할 수 있는 모니터링 시스템이 구축되어 있습니다. 이상 현상을 탐지하면 즉각 슬랙(Slack)으로 알람을 발송하죠. 그중에서도 특히 주의를 기울여야 하는 알람은 담당자에게 즉시 연락이 갈 수 있도록 온콜(On Call)도 운영합니다.
우아한형제들은 성격에 맞는 알람 채널을 다양하게 구성해서 운영합니다. 각 시스템 단위의 알람뿐 아니라, 비즈니스 지표를 기준으로 한 알람과 외부 연동 시스템의 이상을 확인할 수 있는 알람 등 다양한 지표를 참고해 서비스 이상 징후를 탐지합니다.
- 시스템 지표 : CPU, Memory, latency, 5xx error count 등
- 비즈니스 지표 : 가게 상세 진입률, 주문 추이 등
- 외부 연동 시스템 지표 : 연동 시스템 주문 전달 실패, 프랜차이즈 시스템 오류 등
고객 센터로 인입되는 문의
대부분 이슈를 시스템 알람을 통해서 인지하고 있지만, 사용 빈도가 극도로 낮은 메뉴에 오류가 발생하거나 사용자 기기 기종 혹은 OS 버전에 따른 제한적인 오류가 발생하는 특수한 때에는 시스템으로 탐지하기 어렵습니다. 이런 오류들은 주로 고객 센터를 통해서 인지합니다. 고객 센터로 인입되는 이슈 중, 시스템 이상으로 판단되거나 고객 센터에서 자체적으로 처리하지 못하는 문제는 서비스 담당자들이 함께 커뮤니케이션하는 채널로 전달됩니다. 각 팀에서는 고객센터에서 전달된 이슈를 확인하고, 장애로 확인되는 경우 장애 대응을 시작합니다.
몇 년 전까지는 모노리틱 구조*로 인해서 모든 엔지니어가 이 채널의 알람에도 민감하게 반응했지만, 현재는 마이크로서비스 아키텍처에 맞게 문제가 있는 도메인(예를 들어 주문, 리뷰, 결제 등)을 호출하면 각 담당자에게 온콜이 가도록 분리 운영합니다.
장애 공지
개발조직에서는 장애를 감지한 순간, 즉각적으로 장애를 공지합니다.
장애 공지는 장애 발생 시간, 영향 범위, 장애 조치 채널, 내부적으로 정의한 장애 등급 등 여러 정보를 포함합니다. 하지만 최초로 장애 공지를 할 때는 확인된 최소의 정보만 가지고 빠르게 공지하도록 권고합니다. 초기에 모든 항목을 확인하고 기입할 수 없고, 파악하는 데 최소 몇 분은 걸리기 때문입니다. 완벽한 정보가 아니더라도 일단 빠르게 장애 상황이 발생했다는 경보를 울리면 담당자들이 빠르게 대응을 준비할 수 있으므로 장애 공지는 화재경보기와 같은 역할을 한다고 볼 수 있습니다. 건물에서 화재경보기가 울리면 어디에서 불이 났는지 눈에 보이지 않아도 누군가는 119에 신고를 하고, 누군가는 소화기를 찾고, 누군가는 대피를 준비합니다. 이와 비슷하게 장애 공지가 올라오면 사내에서 누군가는 서버 증설을 준비하고, 누군가는 고객 전파를 준비하고, 누군가는 담당 시스템에 영향이 있는지 확인합니다. 이렇게 울린 경보를 통해서 각 담당자가 각자의 역할을 확인하고 그 내용을 공유하려 장애 조치 채널 (논의 채널)로 몰려 들어옵니다. 개발자, 기획자, 인프라 엔지니어, SRE 조직은 물론이고, 대외 커뮤니케이션 담당자 및 주요 의사결정권자들까지 모두 빠르게 채널에 합류합니다. 장애를 빠르게 해결하는 수단과 방법을 모두 동원할 목적으로 장애 공지를 활용합니다.
장애 전파
장애를 해결하는 것만큼이나 장애 상황과 해결 방안을 잘 전파하는 것도 중요합니다. 배달의민족과 같은 플랫폼 서비스에 장애가 발생하면 다양한 이해관계자가 영향을 받습니다. 이해관계자는 크게 외부 이해관계자와 내부 이해관계자로 나눌 수 있습니다. 외부 이해관계자는 가게를 운영하는 사장님, 배달을 수행하는 라이더, 음식을 주문하는 사용자와 같은 고객뿐만 아니라, POS, 배달대행사, 프랜차이즈, 결제대행사 등 다양한 연동 시스템을 담당하는 업체도 모두 포함합니다. 내부 이해관계자는 장애에 대응하는 개발조직은 물론이고, 고객과의 접점에서 직접 응대하는 CS 조직, 대외 커뮤니케이션 조직, 사업 조직까지 많은 부서를 포괄합니다. 장애가 발생하면 앞서 나열한 모든 이해관계자에게 작든 크든 어떠한 영향을 주게 됩니다.
그렇기 때문에 (모든 장애에 해당하지는 않지만) 일부 대규모 장애의 경우 여러 채널로 문의가 들어오기도 합니다. 사용에 불편함을 느낀 사용자와 장사에 영향을 받는 사장님은 고객센터와 영업부서에 문의하게 되고, 연동된 여러 시스템에서는 각 담당자에게 문의합니다. 이때 정확한 정보가 전달되지 않는다면 여러 담당자가 혼란을 겪게 되고 때로는 외부로 잘못된 정보가 전달될 수도 있습니다. 장애를 대응하는 조직에서는 이러한 혼란을 방지하고 정확한 정보를 전달하고자 많은 노력을 기울이고 있습니다.
장애 전파 방법에서도 많은 고민과 시행착오를 거쳐 프로세스를 수립했는데, 핵심적인 두 가지를 살펴보겠습니다.
첫째, 장애 복구와 장애 전파를 분리 운영합니다. 앞서 이야기했듯이 장애 전파는 장애 복구만큼이나 중요하기 때문에 둘 다 놓칠 수 없지만, 양쪽 모두를 신경 쓰다 보면 하나도 제대로 되지 않을 때가 있습니다. 그래서 장애 대응 시에 반드시 장애 복구와 장애 전파를 같은 사람이 하지 않도록 가이드합니다. 될 수 있으면 담당 팀의 기획자 혹은 조직장이 전파하도록 지정하고, 상황이 여의치 않으면 SRE*팀이 이를 지원하기도 합니다.
이러한 조치는 두 가지 이점이 있는데 첫 번째는 엔지니어들이 장애 복구에 집중할 수 있다는 점이고, 두 번째는 유관부서에서는 조금 더 서비스에 초점을 맞춘 내용을 전달받을 수 있다는 점입니다.
장애 복구를 진행하는 엔지니어가 장애 전파도 같이 하면 서비스의 영향도보다는 시스템의 상태를 공유하는 경우가 많습니다. 이 정보는 집중되어 있어서 장애 현상을 전달하기는 쉽지만, 장애 현상으로 인해서 서비스에 어느 정도의 영향이 있는지 고려하기는 힘듭니다. 이 경우 정보 전달은 되었지만, 사용자 친화적인 정보가 아니므로 별도의 해석을 하거나, 거꾸로 다시 질문을 해야 하는 상황이 야기됩니다. 질문이 이어지게 되면 혼란은 가중되고 집중력은 떨어지게 되어 결과적으로 장애 복구 시간이 늘어나기도 합니다.
특정 서버의 스펙을 초과하는 트래픽이 들어와서 스케일 아웃을 해야 하는 경우로 예를 들겠습니다.
- 엔지니어 버전 : A 서버에 트래픽이 몰려 레이턴시가 높습니다. 스케일 아웃 진행 중이며 10분 정도 소요될 것으로 예상합니다.
- 기획자 버전 : 사용자가 급증해 A 서비스 이용이 원활하지 않습니다. 전체적인 접속 속도가 늦으며 간헐적으로 페이지 접근이 되지 않을 수 있습니다. 서버 증설을 진행 중이며 10분 후에 정상화될 예정입니다.
다소 극단적인 예라고 생각될 수 있지만, 실제 장애 상황에서 나타나는 패턴입니다. 엔지니어는 빠른 현상 전달에 집중하고, 기획자나 조직장은 서비스 상태 전달에 집중합니다. 이런 정보를 전달받는 입장에서도 둘의 차이는 극명하게 나타납니다. 엔지니어 버전의 경우(물론 엔지니어들은 한 번에 이해하지만), 외부로 커뮤니케이션 해야 하는 유관 부서에서는 어떻게 전달할지 고민하는 시간이 늘어나거나 복구 작업 중인 담당자에게 다시 질문해야 하는 난감한 상황에 처하기도 합니다. 장애 담당 부서에서 전달하는 정보는 여러 내외부 관계자들에게 전달되기 때문에 정보를 전달받는 사람이 이해하기 쉽도록 전달해야 혼란을 줄일 수 있습니다.
이런 이유로 인해서 장애 대응과 장애 전파를 분리하게 되었습니다. 이렇게 조치해서 엔지니어들은 장애 복구에 집중할 수 있는 시간을 확보해 더 정확하고 빠르게 서비스를 복구할 수 있게 되었고, 유관부서에서는 반복되는 질문 없이 각 부서의 역할에 집중해서 빠르게 대외 커뮤니케이션을 비롯한 여러 조치를 진행할 수 있게 되었습니다.
둘째, 고객이 알고 싶어 하는 내용을 전파합니다. 사용자들은 장애 현상이 나에게만 발생하는 것인지 아닌지, 언제 해소되는지, 잘못 결제된 내역이 있다면 그 내역이 언제 취소되는지와 같은 정보를 궁금해 합니다. 사장님들과 라이더님들은 배달하지 못한 음식은 어떻게 하면 되는지, 언제쯤 서비스가 복구되는지, 폐기해야 하는 음식에 대한 보상은 어떻게 받을 수 있는지를 궁금해 합니다.
즉, 현재 상태, 조치 예정 시간, 후속 대응 세 가지가 주요 이슈가 됩니다. 이를 위해서 담당 부서에서 전달해준 내용을 바탕으로 여러 커뮤니케이션 담당자들이 상황과 전달 대상에게 알맞는 공지를 여러 수단을 통해서 제공합니다. 왜 서비스에 문제가 있으며, 언제까지 복구할 예정이고, 후속조치는 어떻게 진행될지 이 3가지 핵심적인 정보를 전달해서 고객의 혼란을 줄이고, 고객센터나 영업부서에 쏟아지는 문의도 줄일 수 있습니다. 앞서 이야기했듯이 장애 발생을 원천적으로 막을 수는 없지만, 고객에게 적절한 정보를 제공함으로써 서비스의 신뢰는 지킬 수 있습니다.
* Site Reliability Engineering. IT 운영에 대한 소프트웨어 엔지니어링 접근 방식으로 소프트웨어를 툴로 활용하여 시스템관리, 문제해결, 자동화하는 팀
장애 복구
장애 공지 후에 장애 전파와 장애 복구가 동시에 진행됩니다. 장애 복구에서 중요한 것은 서비스 정상화이며, 대부분의 경우 서비스 정상화는 원인 파악보다 우선됩니다. 사용자의 불편을 최소화하는 것이 우선인 겁니다. 일반적으로 많이 사용하는 장애 복구 방법을 살펴보겠습니다.
장비 증설
트래픽이 과도하게 몰리거나 변경된 코드가 시스템에 부하를 주는 경우 가장 먼저 장비를 증설합니다. 클라우드 환경의 가장 큰 장점이 손쉽고 빠르게 장비 증설이 가능하다는 점이기 때문에 이를 십분 활용해 서비스를 안정화합니다. 배달의민족 서비스는 피크 시간의 트래픽이 다른 시간과 비교해 극단적으로 높은 편입니다. 사전에 이를 충분히 고려해서 장비를 운영하고 있지만, 피크 시간에 예상하지 못한 트래픽이 급격하게 증가하면 시스템이 매우 취약해질 수 있습니다. 이때 장비를 증설하면 빠르게 서비스를 안정화할 수 있고, 병목을 일으키는 지점을 찾아서 근본적인 조치를 할 수 있는 시간을 벌 수 있습니다.
롤백
급증한 트래픽이 문제가 아니라면 장애 발생 직전 시점에 변경된 내용이 있는지 확인합니다. 만약 시스템 변경으로 문제가 발생했다면, 즉시 변경 사항을 롤백합니다. 이때 롤백은 코드 롤백뿐만 아니라 인프라 단의 설정과 같은 다른 변경도 모두 포함합니다. 일반적으로 장애 시점 이전 24시간 내의 변경 내역을 전부 확인하는데, 변경 직후에 장애가 발생하는 경우보다는 이슈가 누적되어서 몇 시간 뒤에 장애로 확산되거나 특정 작업(가령 배치 작업)과 충돌이 나는 경우가 많기 때문입니다. 원인이 명확하지 않으면 코드나 설정을 변경하는 것보다 정상 동작하던 상태로 롤백하는 것이 훨씬 안전하므로 롤백을 가장 우선해 고려합니다.
핫픽스
앞서 언급했던 롤백이 가장 빠른 복구 방법이긴 하지만 코드 롤백이 불가능할 경우(예를 들어 DB 스키마 변경)나 문제의 원인이 명확해 롤백보다 핫픽스가 더 빠르다고 판단되는 때에는 문제 부분을 빠르게 수정해서 핫픽스를 진행합니다. 핫픽스를 진행할 때는 원인을 명확하게 알고 100% 확률로 해소되는 핫픽스라고 하더라도 반드시 페어로 확인하고, 베타에서 검증한 후에 진행합니다. 물론, 검증하는 데 시간이 더 걸리지만, 장애 확산이나 부작용을 줄이기 위해서 안전하게 해결하는 것을 최우선으로 합니다.
장비 교체
간혹 특정 장비에 문제가 생기거나 위의 조치들로 해결되지 않을 때는 장비를 교체합니다. 클라우드 환경에서도 장비에 문제가 생기는 경우가 종종 있습니다. 특정 장비에서만 문제가 발생하면 해당 장비만 교체하고, 전체적으로 문제가 발생하면 운영 중인 장비 구성과 같은 세트를 준비한 후에 전체를 교체하기도 합니다. 서비스 중단 시간을 최소화할 목적으로 재기동을 하기보다는 장비를 교체하는 방향으로 진행하고 있으며 DB도 페일오버*를 통해서 장비를 교체합니다. 물론 불가피한 때에는 재기동을 하기도 합니다.
급박한 순간에도 항상 가장 빠르게 복구할 수 있는 방법을 찾기 때문에, 서비스가 정상화된 후 원인 파악을 진행하면 처음 시도한 복구 방법이 잘못되었던 경우도 있습니다. 하지만 그 방법이 틀렸다고 생각하지는 않습니다. 엔지니어들은 항상 서비스 정상화를 위해 할 수 있는 가장 빠른 방법을 선택하고 시행착오를 거쳐 가면서 더 나은 방향으로 나아가고 있다고 믿기 때문입니다.
장애 후 조치
장애 복구가 완료되고, 서비스가 정상화되면 원인 파악과 재발 방지 대책 수립을 위해서 장애 리뷰를 진행합니다. 장애 대응 조직에서는 장애 보고서를 작성하게 되는데, 장애 보고서에는 장애 발생 시각, 탐지 시각, 종료 시각, 장애 탐지 방법, 장애 발생 지점, 장애 복구 방법, 대응 과정 중의 시간별 액션, 장애 원인, 재발 방지 대책 등이 포함됩니다. 이 중에서도 가장 중요한 항목은 장애 원인 분석과 재발 방지 대책 수립입니다.
장애 원인 분석
우리는 장애 원인을 찾는 데 5 whys 기법을 사용합니다. 5 whys는 토요타에서 체계적인 문제 해결에 사용하는 개발한 도구로, 어떠한 문제 상황에 대해 그러한 상황이 발생하게 된 원인을 ‘왜 그러한 상황이 발생했는가?’라는 질문을 여러 번 반복해나가며 문제의 근본 원인에 도달할 수 있다는 방법론입니다.
우리는 장애 리뷰에 이 방법론을 적용해서 조금 더 근본적인 원인을 찾고자 합니다. 근본 원인에 도달하는 정답이 있는 것은 아니지만 이 방법을 이용해서 많은 인사이트를 얻고 있습니다. 장애 리뷰에 적용하면서 아래 세 가지 포인트를 항상 고려합니다.
- 첫 번째 질문은 항상 장애에 영향을 받은 고객의 관점에서 시작해야 합니다.
- 검증이 가능한, 혹은 검증된 사실에 기반해서 답변을 해야 합니다.
- 5번의 횟수는 상징적인 숫자로 꼭 질문이 5개일 필요는 없고, 더 적거나 더 많아도 됩니다.
재발 방지 대책 수립
근본 원인을 찾았다면 그 문제가 다시 발생하지 않도록 재발 방지 대책을 수립합니다. 이때 재발 방지 대책은 근본 원인을 제거하는 데서 그치지 않고 더 빠른 탐지와 더 빠른 복구에 도움이 되는 모든 조치를 포함합니다. 모니터링 지표 추가, 설정값 변경, 코드 리뷰 절차 개선, 배포 프로세스 수정 등 여러모로 고민하고 조치하며 단기, 중기, 장기적으로 개선할 방안들을 도출합니다. 단기적으로는 부하가 발생하는 로직 개선, 이슈 발생 시 빠른 탐지를 위한 알람 강화와 같은 항목들이 도출되며, 이 작업들은 대부분 하루 이틀 내에 마무리됩니다. 중, 장기적 대책은 아키텍처를 개선하거나 레거시를 제거하는 것과 같은 대규모 작업으로, 필요에 따라 TF를 구성하기도 하고 전사 프로세스 변경이 진행되는 때도 있습니다. 빠르게 개선할 수 없는 경우는 임시방편을 도입하기도 하지만 그 후에 반드시 근본 원인을 해결해야만 잠재적인 위험을 막아낼 수 있습니다.
장애 대응을 하면서 가장 뼈아픈 장애는 재발한 장애라고 생각합니다. 알면서도 막지 못했거나, 조치가 미흡해서 같은 장애가 재발하면, 원인을 모르는 장애보다 더 속상합니다. 그렇기 때문에 가능한 한 많은 사람이 고민해서 재발방지 대책을 마련하고, 적절히 조치하기 위한 액션을 합니다.
장애 리뷰
장애 보고서 작성이 완료되면 장애 보고서 내용을 바탕으로 장애 리뷰를 진행합니다. 내부에서 정해진 장애 등급에 따라, 일부 장애는 팀/실 단위의 리뷰를 진행하고 대규모 장애의 경우 담당 팀, SRE팀뿐만 아니라 각 조직의 조직장과 CTO까지 모두 리뷰에 참여합니다. 바쁘게 일정이 돌아가는 와중에도 이렇게 많은 인원이 모여서 리뷰를 하는 이유는 조금 더 넓은 범위를 살펴보기 위함입니다. 팀/실 단위로 리뷰한 내용 중 추가로 고려해봐야 할 이슈가 있을 수도 있고, 전사로 전파해 주의를 기울여야 하는 경우도 있기 때문입니다.
한 가지 예를 들어보면, 특정 장비에 이슈가 있어서 해당 장비를 종료하고 신규 장비를 투입한 적이 있습니다. 하지만 장비를 종료해버렸기 때문에 해당 장비에 어떤 문제가 있는지 원인 분석을 할 충분한 자료를 확보하지 못했습니다. 장애 리뷰를 진행하면서 이러한 내용을 알게 되었고, 장비 교체 시에 장비를 종료하기보다는 비정상적인 장비만 일시적으로 서비스에서 분리하도록 전사에 공유했습니다.
일련의 리뷰 절차가 완료되면 장애 보고서를 전사 개발조직에도 공유합니다. 장애란 비단 한 조직 혹은 개인의 문제가 아니며 누구든 비슷한 장애를 겪을 수 있습니다. 직접적인 경험을 해보지 못하더라도 동료들이 충분히 경험하고 고민한 내용을 간접적으로 경험할 수 있고, 이를 통해 인사이트를 얻는다면 시스템을 한 단계 더 탄탄하게 만들 수 있습니다.
장애 지표 활용
앞서 언급했듯이 장애 보고서를 통해서 생각보다 많은 항목이 수집되고 있습니다. 장애 보고서에서 장애 발생 시각, 탐지 시각, 종료 시각, 장애 탐지 방법, 장애 발생 지점, 장애 복구 방법, 대응 과정 중의 시간별 액션, 장애 원인, 재발 방지 대책, 장애 등급, 장애 후속 조치 방안과 같은 항목이 수집되고 있으며, 이 데이터를 모아서 업타임(Uptime)*을 높이거나 전체적인 장애 대응 프로세스를 개선하는 데 참고합니다. 장애가 자주 발생하는 지점을 확인해서 우리 시스템의 취약점을 알 수 있게 되고, 장애 유형에 따라 전파 범위를 조절할 수 있으며, 외부 시스템의 장애 빈도나 유형을 파악해서 연동 전략을 고민할 수 있습니다. 장애 발생 시각과 탐지 시각 사이의 간격이 크면 장애 탐지가 빠르게 되고 있지 않다는 뜻이기 때문에 모니터링과 알람을 강화해 더 빠르게 탐지할 방안을 고민할 수도 있습니다. 개별 장애 보고서의 내용도 모두 중요하고 도움이 되지만 모은 데이터를 기반으로 인사이트를 얻어서 개선 방안을 찾아 나가는 것도 중요합니다.
* 가동 시간. 동작 중이면서 사용 가능한 컴퓨터의 시간을 백분율로 나타낸 시스템의 신뢰성의 측정도
◆◆◆
장애는 항상 다루기 어렵고 까다로운 주제입니다. 사실 장애에 대해서 터놓고 이야기하는 것이 쉽지는 않습니다. 장애가 발생한 도메인 담당자의 입장에서는 미안한 마음이 들어, 리뷰를 진행하면서 물어보는 입장에서는 혹시 불편해하지 않을까 고민이 되기 때문입니다.
하지만 우리가 이렇게 터놓고 이야기할 수 있는 것은 장애에 대해 특정 개인이나 팀을 탓하지 않는다는 것을 모두가 알고 있기 때문입니다. 오늘 내가 한 실수는 내일 내 옆자리 동료도 할 수 있는 실수이고, 수백 명의 개발자가 잠재적인 위험을 안고 있다는 뜻일 수 있습니다. 작은 불씨일 때는 몇 명의 입김으로 불을 끌 수 있지만, 덮거나 숨기면 그 불씨는 더 커져서 산 하나를 홀랑 태워먹을 수도 있습니다. 감추고 숨기기보다는 함께 해결하고 함께 고민하는 것이 장애 대응의 가장 중요한 핵심이며, 그렇게 할 수 있는 조직이 건강한 조직이라고 생각합니다.
사람은 누구나 실수할 수 있기 때문에 같은 실수를 반복하지 않는 것이 중요하고, 실수를 통해서 배우는 것이 중요하며, 내가 한 실수는 다른 사람도 할 수 있기 때문에 실수를 방지하도록 시스템이 막아줄 수 있어야 합니다. 장애는 결코 어느 한 사람, 한 조직의 잘못이 아닙니다.
저자 우아한 형제들
우아한형제들은 배달이 일상을 조금 더 행복하게 하도록 오늘도 달리고 있습니다. 평범한 사람들이 모여 비범한 성과를 만들어 내는 곳이될 수 있도록 건강한 조직문화를 만드는 일에 진심을 다합니다. 2016년부터 ‘우아한형제들 기술블로그’를 운영하며 개발 조직의 성장 과정을 기록하고 있습니다.
