좋은 모니터링을 해보자

이 글을 쓰게 된 배경

이번에 회사에서 소소하지는 않았던 사실상 전면 장애가 났었는데요

이 과정에서 모두가 확인할 수 있는 모니터링 대시보드를 만들고, 여기만 보자는 의견을 내게 되었고, 미팅을 주최해 결국 모니터링 대시보르를 만들었던 경험을 한 번쯤 정리해 두면 앞으로도 도움이 많이 될 것 같아서 이번에 정리를 해두려고 합니다

 

전면 장애가 나면 보통 이렇게 대응을 하고, 후속 처리를 하게 됩니다

가장 먼저 장애가 난 원인을 파악합니다

1. 현재 서버의 에러 로그를 확인합니다

대부분의 경우에 여기서 모든 것이 드러나는 경우가 많습니다

만약 여기서 잡히지 않는다면 그때부터는 이제 장애의 원인을 확인해봅니다

특정 api의 응답이 없는지, 혹은 엄청 느려졌는지, 아니면 전체적으로 다 문제인지를 확인합니다

특정 api 만 문제라면 그 api 가 왜 느려졌는지 확인해 봅니다

전체적으로 문제라면 jvm thread, gc, spring active thread 등등 기반 메트릭을 확인해 봅니다

 

그 원인을 파악하고 나면 그에 따른 적절한 조치를 합니다.

 

후속 대응으로는 이런 것들을 합니다

장애의 원인 파악 후 재발방지 대책을 세웁니다

혹은 원인 파악을 하는 과정에서 힘들었던 것들을 보완합니다

 

이번에 제가 진행했던 것들은 영향범위를 조금 더 편하게 확인하기 위해서 했던 작업입니다

 

아이디어 제시

아래의 내용은 제가 실제로 슬랙에서 아이디어를 제시했던 내용인데요

 

오늘 보아하니 홈택스가 한번 장애가 나면 그 이후에 회복하는 것이 되게 늦는 것 같더라고요
결제 성공률과 같은 비즈니스단에서 인지 가능한 형태의 지표가 있으면 좋을 것 같아요

이 작업의 goal 은 #silo-tax-inflow-dev 나 #silo-conversion-boost-dev 채널 or 진짜 크리티컬 한 알림만 모아두는 채널로 알림을 줘서 누구든 바로 점검이나 인텔리를 off 해야 하는 상황이라는 것을 알 수 있는 것입니다

아래는 숨은 환급액 찾기를 예시로 합니다

 숨은 환급 찾기 서비스 스크래핑 성공률 (가드레일 지표 예시 : 고객이 인지하는 스크래핑 성공률이 70% 이하가 되면 안 된다)
 숨은 환급액 찾기 결제 후 신고 성공률 (가드레일 지표 예시 : 고객이 마지막 신고를 하는 성공률이 70% 이하가 되면 안 된다)
 숨은 환급액 찾기 결제 성공률이 N% 미만이다 (가드레일 지표 예시 : 결제 성공률이 75% 이하가 되면 안 된다)
 숨은 환급액 찾기 시작 화면부터 마지막 신고까지 전체 퍼널 통과율 (가드레일 지표 : 신고 횟수 N회 / 인트로를 본 횟수 M회 * 100 가 20% 이하가 되면 안 된다)
 숨은 환급액 찾기 시작 화면부터 결제까지 전체 퍼널 통과율 (가드레일 지표 : 결제 횟수 N회 / 인트로를 본 횟수 M회 * 100 가 20% 이하가 되면 안 된다)
 홈택스 평균 응답 시간이 N초 이상이다 (가드레일 지표 : 홈택스의 세금 신고 화면 or 중요한 화면의 응답 시간이 평균 10초가 넘으면 안 된다) <- 이런 부분은 node or 다른 팀에서 인풋을 줘도 좋을 것 같아요

alert 은 달면 안 되지만  필요할 것 같은 지표 예시
 마지막 N분동 안 숨은 환급액 찾기 인트로 진입자 unique count
 마지막 N분동안 숨은 환급액 찾기 결제자 unique count
 마지막 N분동안 숨은 환급액 찾기 신고자 unique count
alert을 달지 못하는 이유는 시간대별 편차가 훨씬 커서 알럿이 제대로 안될 것 같아요

현재 있는 grafana 만을 보고 보고 바로 판단이 가능하도록 필요 없는 것들은 없애고, 더 직관적으로 바꾸는 작업이 필요합니다
이 지표 설정 과정에서 인삼, pm, po 분들의 의견을 모아보려고 하요

필요한 input 은
 어떤 조건에서는 확인용 alert를 주면 좋겠다
 어떤 정도에서는 즉각 점검이 필요하다는 alert 를 주면 좋겠다
라는 비즈니스적인 지표가 필요합니다 :인사:

이 부분을 진행하는 미팅을 한번 진행해 보면 좋을 것 같은데요 참여하실 분들은 알려주시면 초대드릴게요 :인사:

예시가 되는 송금팀 스레드
진짜 크리티컬에서 즉각 대응이 필요한 알림 채널 #team-finance-platform-critical 예시
사진은 모두가 보는 송금팀 grafana 스크린샷입니다

이런 형태로 아이디어를 내게 되었습니다

 

제가 생각했을 때 현재 서비스에서 가장 큰 문제는 서비스 점검을 걸지 말지에 대한 판단을 오로지 개발자의 말에만 의존해서 하고 있다는 점이었습니다

지금 서비스 안 돼요 점검 걸어주세요 -> 점검 걸림

어 지금 에러 올라와요 -> 점검 안 걸림

 

이 부분을 pm의 의견에 따라서 

지금 당장 결제에 도달하는 사람이 5명 이하니까 평상시보다 결제까지 도달하는 사람이 절반밖에 안 되네요 점검 겁시다

지금 사전신청을 하는 사람이 몇 명밖에 안되네요 이거는 잠깐 멈춰두고 다시 여는 게 좋을 것 같아요

라는 것을 진행하는 것을 목표로 했습니다

 

미팅을 시작하기 전까지 준비

문제에 대응이 필요한 상황을 2가지로 나누었습니다

1. 서비스 전면 장애 상황으로 점검을 걸어야 한다

2. 문제가 발생할 수 있는 상황이니 유저를 모으는 마케팅을 잠시 중단해야 한다

이렇게 2가지를 각각 어떤 기준으로 할지는 이번 미팅에서 정하는 것으로 했었죠

 

미팅의 목표 설정

1. 점검을 걸지 말지에 대한 판단이 가능한 지표를 정하고, 대략적인 수치를 정해 본다 (대략적인 수치는 운영하면서 바뀔 수 있으니 지표를 정하는 것에 더 집중한다)
2. 유저를 모으는 마케팅 팀이 마케팅을 중지할지 말지에 대해서 간단한 지표를 정해보고, 대략적인 수치를 정해본다

3. 마케팅팀에서 어떤 지표가 있으면 문제가 되는 특정 마케팅을 탐지할 수 있을지 그 방식을 정해본다

이렇게 총 3가지의 목표를 가지고 미팅을 진행하게 되었습니다

 

당연히 장애 상황에서의 결제 숫자, 결제 성공률, 응답시간 등 문제가 되는 지표들은 미리 준비를 했고요

 

합리적인 지표 선택하기

아래 부분은 추가적으로 챙겼으면 좋았을 부분인데, 회의 때 필요하다는 것을 알게 되었던 부분입니다

서비스 전체 점검이라는 것은 정말 크리티컬 한 경험이기에, 점검을 걸만큼 크리티컬한 핵심 제품을 선택한다

그 핵심 제품을 구성하는 필수적인 스텝을 쪼개본다

이 스텝들을 어떻게 모니터링할지 결정해 본다

 

세금 환급이라는 서비스의 경우에는 

1. 국세청 인증을 한다 (인증)

2. 국세청의 세금 신고 내역을 스크래핑을 한다 (스크래핑)

3. 수수료를 결제한다 (결제)

4. 세금 환급을 신고한다 (신고)

라는 모든 유저가 무조건 지나가게 되는 과정이 있습니다

 

이 과정 중에서 어떤 것을 모니터링할지 중요도를 파악해야 합니다

개발자는 당연히 1,2,3,4를 모두 봐야 하지만, 마케팅 팀 입장에서는 1,2만을 봐도 충분한 것이죠

 

그렇다면 이후에 모니터링 지표는 어떻게 만들 수 있을까요?

저희가 사용한 지표들은 다음과 같습니다

1. 단순 수량

1,2,3,4번의 단순 시도 횟수가 특정 숫자보다 작게 N분간 지속되면 알럿

 

2. 1,2,3,4 기능의 성공률이 N% 미만으로 지속되면 알럿

 

3. 1,2,3,4 기능의 응답 시간이 N초 이상이 되면 알럿

 

이렇게 3가지 케이스에 대해서 알럿을 걸어두고, 이 알럿을 모니터링할 수 있도록 하고 있습니다

 

1번에 대해서 알럿을 걸면 당연하지만 하루동안 시간대에 따라 분포가 달라지니 false alert 이 자주 발생할 수 있는데요

다행히도 저희 서비스의 대부분의 기능은 국세청 점검시간인 00:00~06:00까지 점검이 되다 보니 그 시간대별 분포 차이가 그렇게 크지 않았습니다

그래서 합리적인 선에서 alert을 걸 수 있었고요

 

추가적으로 그 대시보드에 포함시킨 것

마케팅에서 사용하는 referrer count 별 접속량을 추가해 두었습니다

이 대시보드만을 통해서 어떤 곳에서 많이 유입이 있어서 트래픽 때문에 문제가 된다면 어떤 referrer에 해당하는 것을 꺼야 하는지 바로 알 수 있도록 하는 것이죠

 

결과

마케팅 팀 자체적으로 현재 상황을 바로 파악할 수 있게 되었고, 마케팅을 중단할지 말지에 대해서 선택을 할 수 있게 되었습니다

중단을 한다면 어떤 referrer 에 해당하는 마케팅을 꺼야 가장 효과적으로 트래픽을 조절할 수 있는지 파악을 할 수 있게 되었죠

여러분들도 모니터링을 하실 때는 이러한 것들을 고려해서 좋은 모니터링 지표를 설정하고, 모니터링을 하실 수 있으면 좋겠네요