우아한형제들에게 장애란? 많은 서비스회사가 장애에 민감하게 반응하고 있습니다. 우아한형제들이 장애 상황에서 고객의 신뢰를 지키기 위해서 어떤 활동을 하는지 지금부터 자세히 살펴보겠습니다. 장애 탐지
모든 시스템에는 이상 현상을 감지할 수 있는 모니터링 시스템이 구축되어 있으며, 이 모니터링 시스템에서 탐지한 이상 현상을 즉각적으로 인지하기 위해서 Slack(슬랙)으로 알람을 발송하고 있습니다. 그 중에서도 특히 주의를 기울여야 하는 알람의 경우 담당자에게 즉시 연락이 갈 수 있도록 온콜도 운영하고 있습니다.
대부분 이슈를 시스템 알람을 통해서 인지하고 있지만, 사용 빈도가 극도로 낮은 메뉴에 오류가 발생하거나 사용자 기기 기종 혹은 OS 버전에 따른 제한적인 오류가 발생하는 케이스와 같이 특수한 경우에는 시스템으로 탐지하기 어렵습니다. 이런 오류들은 주로 고객 센터를 통해서 인지하게 됩니다. 고객 센터로 인입되는 이슈 중, 시스템 이상으로 판단되거나 고객 센터에서 자체적으로 처리하지 못하는 문제는 서비스 담당자들이 함께 커뮤니케이션하고 있는 채널로 전달됩니다. 각 팀에서는 고객센터에서 전달된 이슈를 확인하고, 장애로 확인되는 경우 장애 대응을 시작하게 됩니다. (장애가 아닌 경우도
종종 있습니다.) 장애 공지
장애 공지는 장애 발생 시간, 영향 범위, 장애 조치 채널, 내부적으로 정의한 장애 등급, 등 여러 정보를 포함하고 있습니다. 최근 발생한 장애 조치 채널에 합류한 멤버들의 리스트를 확인해보면 정말 다양한 팀에서 합류했다는 사실을 알 수 있습니다. 장애 전파
배달의민족과
같은 플랫폼 서비스에 장애가 발생하면 다양한 이해관계자들이 영향을 받습니다. 이해관계자는 크게 외부 이해관계자와 내부 이해관계자로 나눌 수 있습니다. 외부 이해관계자는 가게를 운영하시는 사장님, 배달을 수행하는 라이더, 음식을 주문하는 사용자와 같은 고객뿐만 아니라, POS, 배달대행사, 프랜차이즈, PG사 등 다양한 연동 시스템을 담당하는 업체들도 모두 포함합니다. 내부 이해관계자는 장애에 대응하는 개발조직은 물론이고, 고객과의 접점에서 직접 응대하는 CS 조직, 대외 커뮤니케이션 조직, 사업 조직까지 많은 부서를 포괄하고 있습니다. 장애가 발생하면 앞서 나열한 모든 이해관계자에게 작든 크든 어떠한 영향을 주게 됩니다. 장애 전파 방법에 대해서도 많은 고민과 시행착오를 거쳐 프로세스를 수립했는데, 핵심적인 두 가지를 살펴보겠습니다.
앞서 이야기했듯이 장애 전파는 장애 복구만큼이나 중요하기 때문에 둘 다 놓칠 수 없지만, 양쪽 모두를 신경 쓰다 보면 하나도 제대로 되지 않을 때가 있습니다. (극한의 스트레스는 덤….) 장애 복구를 진행하고 있는 엔지니어가 장애 전파도 같이하게 되면 서비스의 영향도 보다는 시스템의 상태를 공유하는 경우가 많이 있습니다. 복구에 집중되어 있어서 장애 현상을 전달하기는 쉽지만, 장애 현상으로 인해서 서비스에 어느 정도의 영향이 있는지를 고려하기는 힘들기 때문입니다. 이 경우 정보 전달은 되었지만, 사용자 친화적인 정보가 아니므로 별도의 해석을 하거나, 거꾸로 다시 질문을 해야 하는 상황이 야기됩니다. 질문이 이어지게 되면 혼란은 가중되고 집중력은 떨어지게 되어 결과적으로 장애 복구 시간이 늘어나기도 합니다. 특정 서버의 스펙을 초과하는 트래픽이 들어와서 scale out을 해야 하는 경우로 예를 들어보겠습니다.
다소 극단적인 예라고 생각될 수 있지만, 실제 장애 상황에서 나타나는 패턴입니다. 엔지니어는 빠르게 현상에 대해 전달하는데 집중하고, 기획자나 조직장은 서비스 상태를 전달하는 데 집중하고 있습니다. 이런 정보를 전달받는 입장에서도 둘의 차이는 극명하게 나타납니다. 엔지니어 버전의 경우, (물론 엔지니어들은 한 번에 이해하지만) 외부로 커뮤니케이션을 해야 하는 유관부서에서는 어떻게 전달해야 할지
고민하는 시간이 늘어나거나 복구 작업 중인 담당자에게 다시 질문을 해야 하는 난감한 상황에 처하기도 합니다. 장애 담당 부서에서 전달하는 정보는 여러 내외부 관계자들에게 전달되기 때문에 정보를 전달받는 사람이 이해하기 쉽도록 전달해야 혼란을 줄일 수 있습니다.
사용자들이 알고 싶은 건 장애 현상이 나에게만 발생하는 것인지 아닌지, 언제 해소되는지, 잘못 결제된 내역이 있다면 그 내역이 언제 취소되는지와 같은 정보이며, 사장님들과 라이더들이 알고 싶은 것도 배달하지 못한 음식은
어떻게 하면 되는지, 언제쯤 서비스가 복구 되는지, 폐기해야 하는 음식에 대한 보상은 어떻게 받을 수 있는지 등과 같은 정보입니다. 장애 복구
장애 복구에서 중요한 것은 서비스 정상화이며, 대부분의 케이스에서 서비스 정상화는 원인 파악보다 우선됩니다. 원인을 찾는 것도 물론 중요하지만, 장애를 빠르게 복구하고 사용자의 불편을 최소화하기 위해서 원인 파악보다는 장애 해소에 더욱 집중합니다. 일반적으로 많이 사용하는 장애 복구 방법을 살펴보겠습니다.
트래픽이 과도하게 몰리거나 변경된 코드가 시스템에 부하를 주는 경우 가장 먼저 장비를 증설합니다. 클라우드 환경의 가장 큰 장점이 손쉽고 빠르게 장비 증설이 가능하다는 점이기 때문에 이를 십분 활용하여 장비 증설을 통해 서비스를 안정화합니다.배달의민족 서비스의 경우 피크 시간의 트래픽이 다른 시간과 비교해서 극단적으로 높은 편입니다. 사전에 이를 충분히 고려해서 장비를 운영하고 있지만, 피크 시간에 예상하지 못한 트래픽이 급격하게 증가하게 되면 시스템이 매우 취약해질 수 있습니다. 이때 장비를 증설하면 빠르게 서비스를 안정화할 수 있고, 실제 병목을 일으키는 지점을 찾아서 근본적인 조처를 할 수 있는 시간을 벌 수 있습니다. [배달의민족 트래픽 추이]
급증한 트래픽이 문제가 아닌 경우 가장 먼저 장애 발생 직전 시점에 변경된 내용이 있는지 확인합니다. 트래픽이 증가하지 않았다면 시스템의 어떤 변경으로 인해서 장애가 발생할 수 있기 때문입니다. 만약 시스템 변경으로 인해서 문제가 발생했다면, 즉시 변경사항을 롤백합니다. 이때 롤백은 코드 롤백뿐만 아니라 인프라 단의 설정과 같은 다른 변경도 모두 포함합니다. 일반적으로 장애 시점 이전 24시간 내의 변경 내역을 전부 확인하는데, 변경 직후에 장애가 발생하는 경우보다는 이슈가 누적되어서 몇 시간 뒤에 장애로 확산되거나 특정 작업 (ex, 배치)와 충돌이 나는 경우가 많기 때문입니다. 원인이 명확하지 않으면 코드나 설정을 변경하는 것보다 정상 동작하던 상태로 롤백하는 것이 훨씬 안전하므로 롤백을 가장 우선하여 고려합니다.
앞서 언급했던 롤백이 가장 빠른 복구 방법이긴 하지만, 코드 롤백이 불가능할 경우 (ex, DB 스키마 변경)나 문제의 원인이 명확하여 롤백보다 핫픽스가 더 빠르다고 판단되는 경우에는 문제 되는 부분을 빠르게 수정해서 핫픽스를 진행합니다. 핫픽스를 진행할 때는 원인을 명확하게 알고 100% 확률로 해소 될 수 있는 핫픽스라고 하더라도 반드시 페어로 확인하고, 베타에서 검증한 후에 진행하고 있습니다. 물론, 검증에 시간이 더 걸리지만, 장애 확산이나 side effect를 줄이기 위해서 안전하게 해결하는 것을 최우선으로 하고 있습니다.
간혹 특정 장비에 문제가 생기거나 위의 조치들로 해결되지 않을 때는 장비를 교체합니다. (클라우드 환경에서도 장비에 문제가 생기는 경우가 종종 있습니다.) 특정 장비에서만 문제가 발생하면 해당 장비만 교체하고, 전체적으로 문제가 발생하면 운영 중인 장비 구성과 동일한 세트를 준비한 후에 전체를 교체하기도 합니다. 서비스 중단 시간을 최소화하기 위해서 재기동을 하기보다는 장비를 교체하는 방향으로 진행하고 있으며 DB도 failover를 통해서 장비를 교체합니다. 물론, 불가피한 경우에는 재기동을 하기도 합니다. (말 안 들을 때 껐다 켜는 건 국룰 아닌가요?)
장애 후속 조치
가장 먼저 장애 대응 조직에서는 장애보고서를 작성하게 되는데, 이 장애보고서에는
장애 발생 시각, 탐지 시각, 종료 시각, 장애 탐지 방법, 장애 발생 지점, 장애 복구 방법, 대응 과정 중의 시간별 action, 장애 원인, 재발 방지 대책 등이 포함됩니다. (내용이 꽤 많습니다)
우리는 장애 원인을 정확하게 찾기 위해서 5whys라는 기법을 사용합니다. 5whys는 도요타의 Taiichi Ohno가 체계적인 문제 해결을 위해 개발한 도구로, 어떠한 문제 상황에 대해 그러한 상황이 발생하게 된 원인을 ‘왜 그러한 상황이 발생하였는가?’ 라는 질문을 여러 번 반복해나가면 문제의 근본 원인에 도달할 수 있다는 방법론입니다. 미국 제퍼슨 독립 기념관의 기둥 대리석이 지속적으로 부식되어 해마다 많은 보수비용이 발생하고 기념관의 이미지가 훼손되는 문제가 있었는데, 5whys를 통해서 해결한 이 사례를 예로 들어보겠습니다. .
우리는 장애 리뷰에 이 방법론을 적용해서 조금 더 근본적인 원인을 찾고자 합니다. 근본 원인에 도달하는 과정은 어렵고 정답이 정해져있는 것도 아니지만 이 방법을 이용해서 많은 인사이트를 얻고 있습니다. 장애 리뷰에 이 방법을 적용하면서 아래 세 가지 포인트를 항상 고려하고 있습니다.
앞선 과정을 통해서 근본 원인을 찾았다면, 그 문제가 다시 발생하지 않도록 재발 방지 대책을 수립합니다. 이때 재발 방지 대책은 근본 원인을 제거하는 데서 그치지 않고 더 빠른 탐지와 더 빠른 복구에 도움이 되는 모든 조치를 포함합니다. 모니터링 지표 추가, 설정값 변경, 코드 리뷰 절차 개선, 배포 프로세스 수정 등 여러모로 고민하고 조치하며 단기, 중기, 장기적으로 개선할 방안들을 도출합니다. 단기적으로는 부하가 발생하는 로직 개선, 이슈 발생 시 빠른 탐지를 위한 알람 강화와 같은 항목들이 도출되며, 이 작업들은 대부분 하루 이틀 내에 마무리됩니다. 중, 장기적 대책은 아키텍처를 개선하거나 레거시를 제거하는 것과 같은 대규모 작업으로, 필요에 따라 TF를 구성하기도 하고 전사 프로세스 변경이 진행되는 때도 있습니다. 빠르게 개선할 수 없는 경우는 임시방편을 도입하기도 하지만 그 후에 반드시 근본 원인을 해결해야만 잠재적인 위험을 막아낼 수 있습니다. 장애 대응을 하면서 가장 뼈아픈 장애는 재발한 장애라고 생각합니다. 알면서도 막지 못했거나, 조치가 미흡해서 같은 장애가 재발하면, 원인을 모르는 장애보다 더 속상합니다. 그렇기 때문에 가능한 많은 사람이 여러모로 고민해서 재발방지 대책을 마련하고, 적절히 조치하기 위한 액션을 하고 있습니다.
장애보고서 작성이 완료되면 장애보고서 내용을 바탕으로 장애 리뷰를 진행하게 됩니다. 내부에서 정해진 장애 등급에 따라, 일부 장애는 팀/실 단위의 리뷰를 진행하고 대규모 장애의 경우 담당팀, SRE팀뿐만 아니라 각 조직의 조직장과 CTO까지 모두 리뷰에 참여하게 됩니다. 바쁘게 일정이 돌아가는 와중에도 이렇게 많은 인원이 모여서 리뷰를 하는 이유는 조금 더 넓은 범위를 살펴보기 위함입니다. 팀/실 단위로 리뷰한 내용 중 추가로 고려해봐야 할 이슈가 있을 수도 있고, 전사로 전파하여 주의를 기울여야 하는 케이스도 있기 때문입니다. 한가지 예를 들어보면, 특정 장비에 이슈가 있어서 해당 장비를 terminate하고 신규 장비를 투입한 적이 있습니다. 하지만 장비를 terminate 시켜버렸기 때문에 해당 장비에 어떤 문제가 있었는지 원인분석을 하기 위한 충분한 자료를 확보하지 못하였습니다. 장애 리뷰를 통해서 이러한 내용을 알게 되었고, 이 문제를 해결하기 위해서 장비 교체 시에 장비를 terminate 하기보다는 비정상적인 장비만 일시적으로 서비스에서 분리할 수 있도록 전사에 공유하여 장애 원인분석에 도움이 될 수 있도록 개선하였습니다. 이런 일련의 리뷰 절차가 완료되면 장애보고서를 전사 개발조직에도 공유하고 있습니다. 장애란 비단 한 조직 혹은 개인의 문제가 아니며 누구든 비슷한 장애를 겪을 수 있습니다. 직접적인 경험을 해보지 못하더라도 동료들이 충분히 경험하고 고민한 내용을 통해서 간접적으로 경험할 수 있고, 이 간접적인 경험을 통해 인사이트를 얻는다면 시스템을 한 단계 더 탄탄하게 만들 수 있습니다. 장애 지표 활용
장애보고서에서 장애 발생 시각, 탐지 시각, 종료 시각, 장애 탐지 방법, 장애 발생 지점, 장애 복구 방법, 대응 과정 중의 시간별 action, 장애 원인, 재발 방지 대책, 장애 등급, 장애 후속 조치 방안과 같은 항목들이 수집되고 있으며, 이 데이터들을 모아서 uptime을 높이거나 전체적인 장애 대응 프로세스를 개선하는 데 참고하고 있습니다. 장애가 자주 발생하는 지점을 확인해서 우리 시스템의 취약점을 알 수 있게 되고, 장애 유형에 따라 전파 범위를 조절할 수 있으며, 외부시스템의 장애 빈도나 유형을 파악해서 연동 전략을 고민할 수 있습니다. 장애 발생 시각과 탐지 시각 사이의 간격이 크면 장애 탐지가 빠르게 되고 있지 않다는 뜻이기 때문에 모니터링과 알람을 강화하여 더 빠르게 탐지할 방안을 고민할 수도 있습니다. 개별 장애보고서의 내용도 모두 중요하고 도움이 되지만 모여진 데이터를 기반으로 인사이트를 얻어서 개선 방안을 찾아 나가는 것도 중요합니다. 마무리
사실, 장애에 대해서 터놓고 이야기하는 것이 쉽지는 않습니다. 장애가 발생한 도메인 담당자의 입장에서는 미안한 마음이 들어서, 리뷰를 진행하면서 물어보는 입장에서는 혹시 불편해하지 않을까 고민이 되기 때문입니다. 하지만 우리가 이렇게 터놓고 이야기할 수 있는 것은 장애에 대해 특정 개인이나 팀을 탓하지 않는다는 것을 모두가 알고 있기 때문입니다. 오늘 내가 한 실수는 내일 내 옆자리 동료도 할 수 있는 실수이고, 수백명의 개발자가 잠재적인 위험을 안고 있다는 뜻일 수 있습니다. 작은 불씨 일때는 몇 명의 입김으로 불을 끌 수 있지만, 덮거나 숨기면 그 불씨는 더 커져서 산 하나를 홀랑 태워먹을 수도 있습니다. 감추고 숨기기보다는 함께 해결하고 함께 고민하는 것이 장애 대응의 가장 중요한 핵심이며, 그렇게 할 수 있는 조직이 건강한 조직이라고 생각합니다. 지난번에 썼던 내용이지만, 다시 한 번 더 강조해봅니다.
장애는 결코 어느 한 사람, 한 조직의 잘못이 아닙니다. 감사합니다. |