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