프록시 전환 작업을 마치고 며칠간 돌리던 수동 감시를 끄기 전에 남는 안전망이 무엇인지 확인했다. 상시 감시로 걸려 있는 것은 로드밸런서의 비정상 호스트 수 계열 하나뿐이었다.
Table of contents
Open Table of contents
헬스체크가 재는 것의 범위
그 지표가 보는 것은 우리 프록시 노드가 헬스체크에 응답하는지 여부다. 노드가 죽거나 프로세스가 멈추면 잡히므로 살아 있는지는 확실히 알려 준다.
그런데 새 출발지 주소로 옮기면서 실제로 두려운 것은 그 방향이 아니었다. 상대 마켓이 우리 새 주소를 허용 목록에 넣어 주지 않은 경우가 진짜 위험이었다.
정상 프록시가 전달하는 거부
허용되지 않은 주소로 나가면 요청은 상대에게 도달하고 거부 응답이 돌아온다. 프록시는 그 응답을 성실히 전달하므로 자기 일을 다 한 상태다.
프로세스도 포트도 응답 시간도 정상이며 거부는 오히려 빨라서 지표가 더 좋아 보인다. 헬스체크는 통과하고 알람은 울리지 않는데 아무것도 나가지 않는 상태가 된다.
가용성과 수용성이라는 두 축
여기서 개념이 갈렸는데 하나는 내가 살아 있느냐는 가용성이고 다른 하나는 상대가 나를 받아 주느냐는 수용성이다. 두 축은 독립이라 한쪽이 정상이어도 다른 쪽이 막혀 있을 수 있다.
가용성이 무너지면 알람이 울리지만 수용성만 무너지면 어떤 알람도 울리지 않는다. 프록시나 게이트웨이처럼 남을 대신 부르는 구성에서는 이 조합이 가장 위험하다.
뜸한 사용자가 늦게 발견하는 실패
거래가 활발한 이용자는 곧바로 알아채고 문의하지만 활동이 뜸한 이용자는 다르다. 새벽에 몇 건 시도했다가 실패하고 그 사실을 인지하지 못한 채 지나간다.
그런 실패는 몇 주가 지난 뒤에야 문의로 들어온다. 계측이 없으면 그 기간 동안 아무도 모르는 상태가 유지된다.
응답 내용을 지표로 뽑기
수용성을 재려면 응답 내용을 봐야 하므로 액세스 로그의 거부 패턴을 필터로 뽑아 지표로 만들자고 제안했다. 5분 합계가 0을 넘으면 알리는 형태이고 0건이 정상인 지표다.
마켓 전환은 채널마다 순차로 반복되므로 한 번 만들면 이후 모든 전환에 그대로 재사용된다. 다만 알림 경로의 부하와 오탐 피로는 혼자 판단할 사안이 아니라 잔여 과제로 명시해 두었고 옆 세션에서 받은 수치는 재확인하지 않았음을 함께 적었는데 헬스체크가 수용성을 재지 못한다는 결론 자체는 그 수치 없이도 성립하기 때문이다.
정리
- 가용성과 수용성은 서로 다른 축이다
- 헬스체크는 상대가 받아 주는지를 재지 않는다
- 상대가 거부해도 모든 지표가 정상으로 보인다
- 거부는 빨라서 응답 시간이 오히려 좋아진다
- 활동이 뜸한 사용자의 실패는 한참 뒤에 드러난다
- 수용성은 액세스 로그의 거부 패턴으로 잰다
- 0건이 정상인 지표를 둔다
- 받은 수치와 그것 없이도 서는 결론을 구분해 적는다