크롤러의 함정: 42Noti 서비스에서 발생한 401 에러와 그 해결 과정

4.10. 갑자기 나타난 Noti 에러

상용 서비스에 크롤러가 포함되어있다면 늘 주목하자

내가 서비스하고 있는 프로그램 중에서 42Noti가 오늘 갑자기 에러를 뿜어내기 시작했다. 나는 내 프로그램들에 문제가 발생하면 즉각적으로 알 수 있도록 Slack WebHook을 걸어두는데, 이 웹 훅에 401에러가 지속적으로 발생하기 시작한 것이다. 401 코드를 보아하니 권한에서 문제가 생긴 것 같은데.. 도대체 무엇이 문제일까 직접 한번 확인을 해봐야만 했다. 그러면서 머리를 스치고 지나가는 것이 최근에 내가 크롤링하는 부분이 문제가 되었나 싶었다. 최근에 크롤링 하는 사이트의 UI가 변경되면서 문제가 되었을 것이라는 추측을 했다.

 

401에러의 원인

결과적으로 예상은 적중했다. 내 42Noti는 3주마다 갱신해야되는 Secret를 셀레니움으로 제작한 42API_RENEW 패키지를 이용해서 진행하는데, 이 코드가 문제가 된 것이었다. 시크릿을 정상적으로 갱신해주지 못하니, Noti가 API Request를 하기 전에 인증하는 과정에서 에러가 발생한 것이다. 그래서 왜 이 셀레니움 코드가 정상적으로 작동하지 않았는지 확인해보니, 예상했던대로 UI변경으로 인하여 기존 로직이 정상적으로 작동하고 있지 않았다.

 

42Intra에 로그인하는 과정에서 UI 컴포넌트의 Depth가 하나 더 생겼으며 로그인 버튼의 이름이 변경되었다. 42는 언제나 갑작스럽게 UI를 변경하는데 최근에는 변경하지 않아서 안심하고 있던 내 실수였다. 다행히도 내가 작성한 코드라서 바로 문제를 해결할 수 있었고, 몇가지 수정사항을 덧붙여 시스템을 복구시켰다.

얻을 수 있었던 교훈

일단 크롤러를 사용하는 서비스는 안심할 수 없다는 것을 확인했다. 명세가 정해진 API와 같은 경우에는 명세가 변경되기 전에 충분히 인지할 수 있는 시간이 있는 반면, 크롤러는 내가 그냥 긁어오는 것이기 때문에 서비스 제공자에게 알려달라고 하기 어렵다. 이런 경우 그냥 내가 잘 주목하고 있다가 문제가 되자마자 빠르게 변경해야되는데, 크롤링 코드의 수명주기가 정말 짧다는 것을 다시한번 인지했다.

 

또한, 인프라의 바닥에서 사용하는 도구를 만들 경우 하나의 도구가 여러 서비스를 마비시킬 수 있다는 것을 인지했다. 내가 만든 42API_RENEW는 이 NOTI에서만 작동하는 것이 아니라 여러 42 서비스에서 작동하고 있다. 인프라의 밑바탕에 있는 서비스가 마비되니까 다른 모든 서비스가 마비되는 것을 확인헀고, 그렇기에 바탕이 되는 서비스의 중요성을 다시 한번 느꼈다.

 

마지막으로, 에러를 감지할 수 있는 방법을 늘 곁에 두어야된다는 것을 절실히 확인했다. 이번에 만약 Slack 알람으로 에러 로그를 찍고있지 않았다면 우리 팀원들 그 누구도 해당 문제가 발생했는지 알 수 없었을 것이다. 아마 여러 알림이 안 올라오고 나서 즉, 문제가 발생한 후에야 해당 문제를 인지하고 수정할 시도를 했을 것이다. 하지만, 이번에는 에러를 감지할 수 있는 수단에 접근성이 높았고 덕분에 실제로 문제가 발생하기 전에 문제를 해결해 낼 수 있었다. 

 

이번에 얻은 교훈을 바탕으로 앞으로는 개발을 진행할 때 모니터링을 할 수 있는 비용을 최소로 하고 늘 내가 알람을 받을 수 있도록 환경을 구성해야겠다.