집에서 외부 페이지의 업데이트를 자동 모니터링하던 중, 어느 날 밤 「신규 4건 검출, 알림 없음」이라는 로그가 남았습니다. HTTP 상태 코드는 200이며, 예외(Exception)도 발생하지 않았습니다. 얼핏 보면 평온한 완료 상태입니다. 하지만 실제로 저장된 4건은 정상 페이지의 업데이트가 아니라 에러 페이지에서 유래한 내용이었습니다. 취득 처리 과정에서 응답 본문(Response Body)을 받았기 때문에 예외가 발생하지 않았고, 키워드 히트(Keyword hit)도 0이었기에 알림도 발생하지 않았던 것입니다. 이대로 비교용 baseline이 교체되었고, 다음에 정상 페이지로 돌아왔을 때의 차분(Difference)까지 신뢰할 수 없는 상태가 되었습니다.

회선도 서버도 정상적으로 작동하고 있는데, 모니터링의 「의미」가 깨집니다. 이 기사는 그 원인과 복구 방침을 짧게 정리한 것입니다.

무슨 일이 일어났는가

재검증 결과, 정상적인 전송 대상으로부터 HTTP 200을 확인하였고, 에러를 나타내는 표식이 없으며, 의미 있는 항목이 631건 있음을 확인할 수 있었습니다. 즉, 문제는 HTTP 200이라는 응답 그 자체가 아닙니다. 「200만을 완료 조건으로 삼았던 것」이 문제였습니다. 통신상으로는 성공했더라도 모니터링 대상 페이지를 제대로 취득했다는 보장은 없다는 당연한 사실을 판정 조건에 포함하지 않았던 것입니다.

HTTP 응답과 내용 취득을 분리하여 검증하기

자동화에서는 통신으로서의 성공과 목적하는 정보를 얻은 성공을 분리하여 다룰 필요가 있습니다.

첫 번째 단계는 요청에 대해 응답을 취득한 것입니다. HTTP 상태 코드나 본문의 수신은 여기에 포함됩니다. 두 번째 단계는 그 본문이 정말로 모니터링 대상 페이지이며, 비교나 알림에 사용해도 좋은 내용임을 확인하는 것입니다. state나 baseline을 업데이트해도 되는 시점은 두 번째 단계까지 통과한 후뿐입니다. HTTP 2xx는 통신의 성공이지, 목적하는 정보를 얻은 성공이 아닙니다.

의미 검증(Semantic Validation)은 복잡한 메커니즘일 필요는 없습니다. 최종적으로 허가된 도착지에 도달했는지, 에러 본문을 나타내는 표식이 없는지, 대상다운 최소한의 항목 수가 있는지를 확인하는 것만으로도 효과가 있습니다. 페이지 고유의 필수 단어나 날짜가 포함된 항목, 버전을 나타내는 헤더가 있다면 그것도 검수 재료가 됩니다. 중요한 것은 단일 판정에 의존하지 않는 것이며, 여러 조건을 조합함으로써 「본문은 받았지만 목적 페이지는 아닌」 응답을 일반적인 변화로부터 쉽게 분리할 수 있게 됩니다.

의미 검증에 실패하면 구(舊) baseline을 유지하기

이번 실패의 핵심은 에러 페이지를 일반적인 변화로 저장하여 baseline을 오염시킨 점에 있었습니다. 부정한 응답을 한 번 비교 정본(Ground Truth)으로 만들어 버리면, 그 이후의 정상적인 응답까지 이상한 차분으로 보이게 됩니다.

복구 후에는 취득 결과로서 요청 대상·최종 도착지·상태·본문을 유지하면서, 의미 검증에 실패한 것은 fetch_error로 취급하고 구(舊) state를 유지하도록 했습니다. 실패를 기록하면서도 비교 대상 자체는 진행시키지 않는 분리입니다. 이는 「아무 일도 없었던 것으로 치는」 처리가 아니라, 다음 비교 대상을 망가뜨리지 않기 위한 처리입니다.

오염된 baseline만 재작성하기

baseline이 오염되었다고 해서 모든 모니터링 이력을 다시 만들 필요는 없습니다. 이번에도 오염된 대상만 정상 페이지로부터 재 baseline 처리하였고, 다른 모니터링 대상의 이력에는 손을 대지 않았으며, 일반적인 변화 알림도 보내지 않았습니다. 이는 신중함을 위해서일 뿐만 아니라, 복구 작업으로 인한 차분을 「새로운 업데이트」로서 독자나 운영자에게 전달하지 않기 위함이기도 합니다. 복구가 완료되었다는 사실과 모니터링 대상에 일반적인 변화가 있었다는 것은 별개의 사건으로 취급해야 합니다.

교훈과 체크리스트

• HTTP 상태 코드는 유용한 관측값이지만, 그것만으로 완료를 선언하기에는 정보가 부족하다
• 「응답을 받았는가」와 「목적 페이지를 취득했는가」는 별개의 레이어(Layer)에서 검증한다
• 최종 도착지·에러 표식·항목 수·대상 고유 요소를 조합하여 판정한다
• 의미 검증에 실패하면 baseline을 업데이트하지 않고 구(舊) state를 유지한다
• baseline 오염으로부터의 복구는 대상을 한정하고, 일반적인 업데이트 알림과 혼동하지 않는다

차분 모니터링을 구축하고 계신 분들은 자신의 메커니즘이 「무엇을 근거로 목적 정보를 얻었다고 판정하고 있는가」를 한 번 재검토해 보시기를 권장합니다. HTTP status만 보고 있다면, 아직 완료되지 않았을 가능성이 있습니다.

상세 로그

이번 검증의 상세 내용과 실제로 사용한 판정 조건의 사고방식은 원문 기사에 정리되어 있습니다.

Discussion