우아한형제들이 장애를 놓치지 않고 탐지하는 방법

배달의민족을 사용하는 고객들은 늘 오늘의 식사를 기대합니다. 점심시간에 맞춰 미리 떡볶이를 주문하고, 저녁에는 치킨과 함께 축구 경기를 즐길 계획을 세우며 퇴근합니다.

하지만 주문을 하려는 순간 시스템 장애가 발생한다면 어떨까요? 단순히 메뉴를 바꾸는 번거로움에서 끝나는 게 아니라 기대했던 행복한 시간이 한순간에 무너져버릴 수 있습니다. 특히 월드컵 결승전을 치킨 없이 보는 것은 상상만으로도 괴로운 일이죠.

그래서 우리는 그 누구보다 빠르게 장애를 탐지해야 하는 숙명을 갖습니다. 빠르게 장애를 인지하고 피해가 커지기 전에 상황을 해결함으로써 고객의 계획된 일상을 지켜야 합니다. 오늘은 우리가 어떻게 장애를 놓치지 않고 신속하게 탐지해낼 수 있었는지 그 과정을 공유드리고자 합니다.

장애는 왜 발생할까요?

서비스는 끊임없이 변화합니다. 기능 개선, 신규 기능 출시, 비즈니스 확장 등 고객의 필요에 따라 반응하며 이러한 변화는 멈출 수 없습니다. 그리고 이런 변화를 주도하는 것은 사람이기 때문에 실수 없이 완벽하게 운영하는 것은 불가능합니다.

따라서 장애 발생은 피할 수 없는 현실입니다. 그래서 우아한형제들 내부에서도 “장애는 내는 게 아니라 나는 것이다.”라는 표현을 사용하기도 합니다. 중요한 것은 장애가 발생했을 때 얼마나 빠르게 이를 발견하고 대응하는가입니다.

일명 ‘화불’이라고 불리는 대표적인 장애

장애는 어떻게 탐지하나요?

전통적으로 장애 탐지는 CPU 사용률, Memory 사용량과 같은 시스템 지표를 모니터링하며, 사전 정의한 임계 조건에 도달하면 경보를 발생시키는 방식으로 이루어집니다.

이미지 출처: ChatGPT 5

다만 장애 발생 가능성이 있는 모든 시스템 지표를 빠짐없이 모니터링하는 것은 현실적으로 불가능합니다. 어딘가에는 늘 모니터링이 닿지 않는 구간이 존재할 수밖에 없습니다. 그렇다고 놓치는 장애가 있어서는 안 됩니다. 놓친 장애는 곧바로 고객 피해로 이어지기 때문입니다.

그렇다면 장애를 놓치지 않고 탐지할 수 있는 방법이 있을까요?

서비스 이상 탐지

장애에 빠르게 대응할 수 있도록 우아한형제들 SRE(Site Reliability Engineering)팀은 장애 탐지와 관제를 담당하는 여러 시스템을 직접 설계하고 운영하고 있는데요, 전통적인 모니터링 방법으로는 탐지할 수 없었던 장애를 놓치지 않기 위해 서비스 이상 탐지(Service Anomaly Detection) 시스템을 도입하기로 결정했습니다.

장애가 발생하면 그 즉시 장애 발생 사실을 알기는 어렵지만 분명 어디선가 사용자는 장애로 인한 영향을 받게 됩니다. 이런 사용자 영향은 결국 서비스 지표의 변화로 이어지게 되고, 관련 서비스 지표를 모니터링하고 있다면 장애 발생 사실을 빠르게 탐지할 수 있습니다.

서비스 지표는 실시간 로그인 수, 주문 수, 결제 성공률과 같은 항목으로 구성되며, 사용자 경험을 직접적으로 반영하는 밀접한 관계를 갖습니다. 셀 수 없이 많은 시스템 지표와 달리 서비스 지표는 한정적이기 때문에 최소한의 지표로도 효과적인 모니터링이 가능합니다.

요구사항

그래서 서비스 지표를 모니터링할 수 있는 서비스 이상 탐지 시스템 구현을 결정했고, 설계에 앞서 세 가지 요구사항을 정의했습니다.

1. 실시간 탐지가 가능해야 합니다.

아무리 정확히 장애를 탐지한다고 하더라도 장애가 발생하고 한참 이후에 경보가 울린다면 아무런 효용이 없습니다. 장애가 발생한 즉시 실시간(아무리 늦어도 Near-Realtime)으로 경보가 울려야 의미 있는 대응을 할 수 있습니다.

2. 경보가 울린 이유를 알 수 있어야 합니다.

서비스 이상 탐지 시스템은 100% 정확할 수 없으며, 변화하는 서비스 환경 속에서 오탐은 언제든 발생할 수 있습니다. 따라서 원인 분석이 어려운 AI 기반 설계보다는 빠르게 원인을 분석하고, 개선할 수 있는 구조로 구현해야 합니다.

3. 경보 이후의 프로세스도 제공해야 합니다.

경보가 울려도 장애 대응이 신속하고 체계적으로 진행되지 않으면 목표 시간 내 장애를 해소할 수 없습니다. 장애 숙련도와 무관하게 누구나 빠르게 대응할 수 있도록 경보 이후의 대응 프로세스까지 제공하는 것을 핵심 요구사항으로 정의했습니다.

탐지 기법 설계

그러면 위의 요구사항을 충족하면서도 장애를 정확하게 탐지하기 위한 시스템은 어떻게 설계해야 할까요?

한 가지 다행인 점은 배달의민족 서비스는 대부분 점심과 저녁에 주문이 집중되는 구조로 패턴이 매우 선명하고 일정한 흐름을 갖습니다. 덕분에 과거 내역을 토대로 정상적인 상황에서의 서비스 지표를 쉽게 예측할 수 있고, 예측과 실적의 차이로 해당 서비스 지표의 장애 여부를 쉽게 판단할 수 있습니다.

구체적인 예측을 위해 우리는 IQR, 2-sigma 등 다양한 이상 감지 기법들을 검토했지만, 직관적이고 분석이 용이하며 이상치에도 강한 중앙값(Median) 방식을 선택했습니다. 복잡한 기법을 활용하기보다는 빠르게 구현하고, 빠르게 검증하고, 빠르게 개선하고자 했습니다.

서비스 이상 탐지 릴리즈

앞에서 정의한 요구사항을 준수하는 시스템을 설계, 구현하여 성공적으로 릴리즈를 완료했습니다. 다음 이미지는 서비스 이상 탐지 시스템에서 실제로 모니터링 중인 지표 그래프의 일부분입니다.

‘주문 생성’ 서비스 지표에 대한 서비스 이상 탐지 그래프

과거 데이터의 중앙값을 토대로 예측 값(Prediction)을 생성하고, 현재 값(Actual)과 비교합니다. 만약 현재 값이 임계 값(Warning, Critical)에 도달하면 장애로 판단해 경보가 울리게 됩니다.

하지만 지표라는 게 언제든지 갑작스럽게 솟구치거나 꺼지는 이상 값이 발생할 수 있기 때문에 이로 인한 오탐을 방지하기 위해 임계 도달 횟수를 추가로 관리합니다. 임계 값에 몇 회 이상 연속으로 도달했는지로 경보의 정확도를 관리합니다.

임계 도달 횟수를 높게 설정하면 경보의 정확도는 높아지지만 장애 탐지 속도는 느려지고, 횟수를 낮게 설정하면 장애 탐지 속도는 빨라지지만 오탐 발생 가능성이 높아집니다.

임계 값과 임계 도달 횟수는 각 지표마다 성격이 모두 다르기 때문에 과거 트렌드를 토대로 적정한 값을 찾는 충분한 안정화 기간이 필요합니다.

장애 대응 프로세스

임계 도달 횟수만큼 임계 값에 도달하게 되면 Slack 채널에 경보가 발송(좌측 이미지)됩니다. 경보 메시지에는 지표 현황이나 긴급도 등의 정보가 포함되어 있어 현재 상황을 빠르게 파악할 수 있습니다.

장애 경보와 경보 이후의 프로세스

회의 중이거나 새벽 시간에는 Slack 메시지를 확인하기 어려울 수 있습니다. 각 서비스 지표별로 미리 정의된 Opsgenie On-Call 담당자를 즉시 호출(가운데 이미지)합니다. 더 이상 최초 발견자가 담당자를 찾을 필요도 없고, 전화로 잠을 깨우는 수고로움도 필요 없습니다.

평소에는 잘 알고 있던 프로세스도 갑작스러운 상황에서는 머리가 하얘질 수 있습니다. 특히 장애가 막 발생한 순간이라면 더욱 그렇습니다. ‘내가 지금 당장 뭐부터 해야 하지?’ 기억을 떠올리는 사이에도 고객 피해는 계속해서 커지고 있습니다. 이런 부담을 없애고 즉시 장애에 대응할 수 있도록 장애 전파와 장애 채널 생성을 서비스 이상 탐지에서 자동으로 수행(우측 이미지)합니다. 담당자는 복잡한 프로세스를 생각할 필요 없이 바로 불을 끄러 가면 됩니다.

도입 성과는 어떤가요?

올해 6월 서비스 이상 탐지를 도입하고, 남은 하반기 동안 안정화와 함께 계속해서 장애를 탐지해 내고 있습니다. 그동안의 성과는 어땠을까요? 처음 서비스 이상 탐지 도입을 결정했을 때 우리가 기대하는 것은 다음의 세 가지였습니다.

• 경보 정밀도: 오탐 경보(False Positive)를 최소화해야 합니다.

• 장애 탐지율: 발생한 장애 대부분을 탐지해야 합니다.

• 장애 전파 시간: 빠르게 장애가 전파돼야 합니다.

실제 결과는 기대 이상이었습니다.

아이콘 출처: flaticon.com

경보 정밀도는 약 11배 향상됐습니다. 기존에는 경보가 발생해도 실제 장애인지 오탐인지 반신반의의 분위기가 있었습니다. 제발 오탐이길 기도했죠. 실제로 오탐인 경우도 자주 발생했습니다. 장애가 아니라서 다행이었지만, 주말이나 새벽에 갑작스러운 대응이 요구되며 구성원들의 피로는 커져갔습니다.

향상된 정밀도로 이제는 경보 대부분이 실제 장애에 해당합니다. 오탐이 줄어 갑작스러운 대응 상황이 많이 줄었고, 대신 경보가 발생했을 때 사실상 장애 상황으로 간주하여 빠른 대응이 가능해졌습니다.

장애 탐지율은 약 70% 향상됐습니다. 사실상 대부분의 장애를 서비스 이상 탐지가 탐지하는 데 성공하면서 이제는 우리가 인지하지 못하는 사이에 장애로 인해 고객 피해가 급격히 증가하는 상황에 대한 걱정을 상당 부분 해소할 수 있었습니다.

대부분의 장애가 서비스 이상 탐지에 의해 탐지되고, 서비스 이상 탐지는 자동화된 전파 기능을 제공해 장애 전파 시간 역시 상당한 개선이 있었습니다. 이전 대비 약 74%의 전파 시간이 단축되면서 장애 해결을 위해 더욱 빠르게 리소스를 투입할 수 있었고, 단축된 시간만큼 장애 해소 역시 빠르게 이룰 수 있었습니다.

서비스 지표 모니터링 통합

정량적인 성과뿐 아니라 정성적인 측면에서도 큰 변화가 있었습니다. 서비스 이상 탐지 도입 이전에도 각 서비스팀에서 모니터링 중인 서비스 지표는 있었습니다. 다만 서비스팀 내부에서만 관리되는 경보들로 전사 장애를 관제하는 SRE팀에서는 어떤 지표가 모니터링되는지, 어느 채널에 경보가 울리는지 등 현황 파악이 어려웠고, 정책이나 프로세스를 전파하려고 해도 각 서비스팀마다 지표에 대한 정의나 구조가 달랐기 때문에 적용이 쉽지 않았습니다.

이번 서비스 이상 탐지를 도입하면서 이런 각 서비스팀의 서비스 지표 모니터링 대부분을 서비스 이상 탐지로 통합했습니다. 앞으로는 대부분의 서비스 지표 현황을 저희 팀에서 파악할 수 있게 됐고, 이는 앞으로 새로운 정책이나 프로세스 도입이 보다 효율적으로 적용됨으로써 유의미한 성과를 창출하는 데 큰 기반이 될 것입니다.

앞으로의 계획

서비스 이상 탐지 도입으로 이제는 장애를 신속하게 탐지하고 대응을 시작하는 영역에서 많은 갈증이 해소되었습니다. 다음으로 집중할 부분은 발생한 장애의 원인을 신속하게 탐지해 내는 것입니다.

이미지 출처 : ChatGPT 5

전사의 다양한 지표를 관리하고 운영하는 SRE팀의 수많은 데이터 더미 속에서 현재는 사람이 파악하고 있는 장애 원인 추적 과정을 빠르게 개선해 보고자 합니다. 워낙 광범위한 영역을 빠르게 분석해야 하기 때문에 서비스 이상 탐지 도입 때와는 다르게 AI를 활용하는 방안으로 해결책을 구상하고 있습니다.

기술이 발전하며 이제는 보다 적은 비용으로 많은 시도를 해볼 수 있게 되었습니다. 앞으로도 장애 대응을 더욱 발전시키기 위해 끊임없이 도전하고, 그 과정에서의 배움과 경험을 계속 공유드리겠습니다.