에러 알람과 예외처리의 난관

2024년 6월 7일 금요일

Today I Learned

날짜

2024년 6월 8일 금요일

내용

에러 알람

휴일에 쉬는데, 실서버에서 에러가 난다고 온갖 알람이 오두방정을 떤다. 다행히(?) 서버 트래픽의 문제라던가, 기능상의 문제는 아니였고 크론이 실행되는 도중 발생하는 문제였다. 자동적으로 업데이트 되야할 데이터가 원할하게 돌아가지 못했다는 뜻이다. 쉬는데 참 마음이 찝찝해서 금요일이 되자마자 실서버에서 처리해주었다. 원인은 크게 두가지였다.

  1. Orphan Data

    직역하면 고아 객체긴 한데.. 관계된 데이터가 없다는 뜻이다. 예를 들어, 우리 서비스에선 Shop 데이터가 존재하면 이 하위 개념으로 shop_detail 데이터가 존재하게 된다. 영속성 전이(CASCADE)를 설정해놓으면 shop이 삭제될때 연관된 shop_detail도 따라없어져야 한다. 그럼에도 불구하고 아주 낮은 확률로 혼자 남아있는 shop_detail이 발견된다면 연관된 shop이 없는 이 shop_detail 데이터를 고아 객체라고 부르는데, 이것 떄문에 발생하는 오류들이 꽤 있었다. 버그나 로직의 구멍이 있다기 보단, 초기 개발때 로직이 불완전한 상황에서 만들어진 데이터들로 인해 생긴듯 하여 커맨드를 작성해서 지워줬다.

  2. 예외처리

    늘 하는 고민인데, 예외처리는 어느정도 수준까지 이루어져야 할까? 쇼피파이에서 테마를 조회하여 앱블록을 가져오는 기능이 있다. 거의 대부분은 원하는 형태로 잘 가져오지만 진짜 뜬금없는 애들 아주 종종 있다. JSON이 아니라 뜬금없이 String이 담겨있는 경우라던가.. 이럴 때 오류가 난다.

    그렇다면 응답에서 string이 아닐때만 로직이 진행되도록 코드를 추가하는게 무조건 옳은가? 만약 1만번 중 1번 꼴로 이러한 문제가 발생한다면 나머지 정상적인 9999번의 실행에서는 굳이 0.01%의 확률로 발생하는 문제로 인해 불필요한 로직이 추가되야 한다. 비록 타입을 검증하는 간단한 if 문이라 하더라도, 이게 좋은 코드인지는 잘 모르겠다.

    그럼 9999번을 위해 1번의 오류를 무시해야 할까? 매일 10000개의 데이터를 검증해야 한다면 매일 1번의 오류가 나게 된다. 그냥 아주 작은 사소한 오류라 아무런 영향을 끼치지 않겠으나 이러한 것들이 쌓인다면, 실서버에서 발생하는 에러를 알려주는 기능이 무의미해지진 않을까?

    어렵다ㅏㅏㅏㅏㅏㅏㅏㅏㅏㅏㅏㅏ

회고

사랑니 쪽 잇몸에 염증이 났다. 너무 아프다.