장애 회고 [2021.06.04]

 

장애가 나는 횟수가 좀 잦아지긴 했다 싶었는데, 에브리타임 할인이 끝나는 마지막날 큰 장애가 났다. 오전 10시 30분 정도부터 서비스가 느리다는 쏠을 비롯한 운영팀의 메세지가 있었고, 10시 46분부터 본격적으로 UFO 가 날아다니기 시작했다. 이전에도 장애는 여러번 있었고 금방 회복을 해왔기 때문에 크게 대수롭지 않게 생각하고 잠깐 개발파트 자리에 가서 서성였다가 내자리에서 돌아와서 할일 했다.
 
근데 분위기가 좀 이상했다. 조슈아 한테서 카트와 회원가입에서 비정상적인 요청이 날아온다는 이야기가 들렸고, 트래픽도 잠깐의 증가가 아니고 이벤트 마지막날 잘된 바이럴에 의한 지속적인 트래픽 이라는걸 알았다. 플랫폼의 생명력은 가입 유저를 어케 잘 활성화 시키냐에 달려있는데 수천명의 가입유저를 놓치고 있다는 생각을 하니 속이 탔다. 게다가 서비스 코드를 가장 넓은 범위를 알고 있는 후리가 마침 휴가였다.ㅠㅠ
 
향로 들어오고 좀 더 섬세하게 장애 모니터링을 하는 작업을 진행해 주시고 있었지만 아쉽게도 아직 시간이 모자라서 일정수준 아래였다. 의심할 수 있는 문제들을 하나씩 짚어보다가 슬로우쿼리에서 포착되는 것들중 실마리를 찾기 시작했다. 많은 가입이 이뤄지면서 이메일 인증 키를 지울때 부하가 걸려 이 부분과 carts API 기능을 막고, 동시에 DB 사이즈를 8x 로 올렸다.
 
이 부분에서 향로가 미리 세팅해둔 슬로워쿼리 모니터링에서 의심점을 하나씩 찾아가는 과정이 꽤 괜찮았다. 근본적으로는 한 row 에 요청이 몰리면서 락 이 걸리는 문제였다. (나중에 보니 이 동일한 문제가 중첩적으로 발생했다.) 난 해당 로직이 보여주는것 외에는 서비스에 영향을 주지 않는다고 알고 있어서 이 코드는 수정해도 괜찮다고 안심시키고 비스타에게 해당코드 수정을 부탁했다.
 
사실 이때쯤 급한건 해결되는거 같았다.(착각이었음) 1시간 넘는 장애는 오랜만 이었어서 긴장이 된 상태였는데 코드 수정으로 해결될거라고 생각하니 긴장이 풀렸고 다들 걱정이 많은거 같아서 밥부터 먹어야 겠다고 생각했다.
  
그래도 장애가 완전 끝난건 아니니 사무실로 중국음식을 시켰다. 심적으로 고생들 했으니까 탕슉이나 그런거 넉넉하게 시켰다. 근데 장애가 해결이 되지 않아 다들 절반도 못먹고 다들 일어나서 모니터링을 하기 시작했다. 수강생, 쿠폰 사용자 등 count 관련 로직이 주 문제여서 이것들을 수정하고 배포해 나갔는데, 문제가 해결되지 않고 나중에는 서버가 살자마자 계속 죽어버리는 일이 발생했다.
 
솔찍히 이때는 온갖 생각, 걱정이 다 들었다. 근데 다른 동료들 얼굴을 보니 다들 상황을 심각하게 받아들이고 있었다. 이런 모습을 보니 내가 느끼는 불안을 전염시킬 필요는 없다고 느꼈다. 긴장을 풀어줘야 겠다고 생각했다. 계속 괜찮으니 천천히 생각하자고 예전에는 이틀씩 안됐었다고 이야기도 했다. 만약 이 상황을 심각하지 않게 받아들이는 사람이 하나라도 있었다면 다르게 반응했을텐데, 우리 팀원들에게는 그럴 필요가 없었다. 감사할 따름이다.
 
다행이 4시 정도부터 DB Connection 수를 늘려야되는 해결책을 찾았다. 디비 사이즈만 늘렸지 서버와 연결된 커넥션 수가 적었기 때문에 rock 이 걸리면서 디비가 계속 죽거나 응답을 못받은 서버가 죽은거였다. 그 이후부턴 인지 가능한 문제라 하나씩 풀려나가기 시작했다. 문제되는 로직들을 수정하고, DB 사이즈를 더 크게 늘리고 등등 급한 불은 껐다. 한국에서 젤 큰 DB 를 언제 써보나 싶었는데 기대하던것보다 훨씬 일찍 써봤다. AWS 강철 매니저도 자기도 첨 봤다고 신기해했다.ㅋㅋ
 
6시부터 회고를 했다.
장애가 발생했던 시간부터 타임라인 별로 어떤 문제가 있었는지, 어떻게 해결했는지 짚어갔다.
이번엔 예전 장애 일어났을 때와 문제 해결 양식이 차이가 컸다. 이번엔 긴 시간 동안 순차적으로 문제가 터지고 해결해 나갔기 때문에 타임라인 별로 정리하고 보는게 좋겠다는 생각이 들어 그렇게 해보자고 이야기 했다. 그래서 이런 타임라인 시트가 나오고 앞으로 해야 할 일이 명확해 졌다.
 
장애가 발생한 것은 슬픈 일이지만, 개발 파트원들이 이런 큰 문제가 왔을 때 어떻게 해결하는지 모습을 지켜본 것은 좋았던 일이라 생각한다. 그리고 문제가 발생했던 구간도 첨 생각보다는 해결하기 쉬운 부분이어서 안심이 됐다.
 
다만 이번 장애가 해결되고 운영파트와의 상황 공유 및 할 수 있는 일에 대한 프로토콜, 대응 등이 명확하지 않았던 것은 아쉽고 미안하다. 덕분에 장애시 프로토콜을 정의했고, 앞으로 더 촘촘히 발전시켜 나가야겠다.
 
나(@hjoo) 스스로에 대해서는 이 글을 쓰다보니 느낀게 있는데, 내가 엄청 안이해 졌다는 거다. 과거의 나였으면 이런 상황에선 좀 더 틈없이 움직였을 거다. 엄청 예전 옛날에 추석때 트래픽이 몰려 서비스가 안됐을 때, 구글폼으로 가입을 받고 서비스가 정상화 되고 나서 가입을 시켜주고 비번 변경하라는 메일을 보냈었다. 같은 방법은 아니더라도 그런 식으로 액션을 취했어야 했다. 뭔 이미 성공한 서비스인 것처럼 행동했다. 아직 한참 멀었는데.
  

Summary

노력한것

  • 분위기가 부정적인 방향으로 심각해지지 않게 되도록 편한 분위기를 유도했다. (O)
  • 문제가 길어지면서 절차적으로 해결이 되는 모습을 팀원들이 경험하도록 유도했다. (O)
  • 기술적인 문제가 있더라도 서비스 자체에는 문제가 없는 방향에 대해서 생각했다. (X)
  • 개발 파트에서 되도록 많은 사람이 문제 해결에 참여할 수 있도록 일을 나눴다. (세모)

잘한것

  • 비스타, 꾸기 등이 문제 해결에 직접 참여할 수 있었다.
  • 개발 파트 분위기가 경직되지 않고 적절한 긴장감이 유지됐다.
  • 장애 후기 정리가 좋았다.

잘못한것 (개선할것)

  • 문제 당장 해결하는 것에만, 기술적인 부분에만 집중해 운영적으로 더 할 수 있는 것들을 많이 놓쳤다.
  • (장애시 프로토콜 마련 및 개선)
  • 운영팀에 공유가 좋지 않았다.
  • (장애시 프로토콜 마련 및 개선)
  • 개발파트 안에서도 문제 해결 과정에서 소외되는 사람들이 생겼다.
  • (장애시 프로토콜 마련 및 개선)
  • 개인적으로 나태했다.
  • (반성 및 장애시 프로토콜 마련 및 개선)

 

 

작성자 : 쭈 
작성일 : 2021.06.04