프록시 인프라 구축을 마치고 점검을 요청했는데 후속으로 미뤄 둔 검증이 실은 실 트래픽 전환 전에 끝내야 하는 필수 게이트 아니냐는 지적을 받았다. 미뤄 둔 것은 고정 주소가 제대로 붙었는지 확인하는 일이었다.
Table of contents
Open Table of contents
조용히 실패하는 경로
지적을 받고 그 검증이 왜 필수인지를 다시 따져 봤다. 고정 주소 연결이 조용히 실패하면 프록시는 정상으로 리슨하고 헬스체크도 포트가 열려 있으니 정상으로 보고한다.
그 상태에서 실 트래픽이 그 노드로 가면 기본 주소로 나가게 되고 상대 허용 목록에 없으므로 거부당한다. 헬스체크가 정상이라고 하는데 실제로는 못 나가는 상태가 되는 것이다.
전송 계층 체크의 한계
앞서 포워드 프록시 포트에 일반 헬스체크를 못 보낸다는 이유로 전송 계층 체크를 쓰고 있었다. 그것은 포트가 열려 있는지만 보고 제대로 동작하는지나 올바른 주소로 나가는지는 보지 않는다.
프로세스가 떠 있기만 하면 무조건 정상으로 나온다. 앞서 두 대안 중에 전용 헬스체크 포트를 함께 검토해 둔 것이 여기서 살았다.
두 가지를 보는 엔드포인트
별도 포트에 작은 서버를 띄우고 거기서 두 가지를 확인하게 했다. 인스턴스 메타데이터로 자기 공인 주소를 조회해 기대값과 비교하고 자기 프록시를 통해 외부로 실제 요청을 보내 응답이 오는지를 본다.
둘 다 통과해야 정상 응답을 준다. 이 엔드포인트 하나가 고정 주소가 안 붙으면 즉시 트래픽을 막고 프록시 설정이 깨져 못 나가는 경우도 잡으며 프록시 포트를 안 찌르게 되면서 빈 연결 로그까지 없앴다.
소스에서 못 거른 노이즈
세 번째가 부수 효과로 나온 이유는 소스에서 거르려던 시도가 실패했기 때문이다. 프록시 설정에서 응답 코드와 메서드와 출발지 접근 제어로 그 요청들을 로그에서 빼려 했다.
셋 다 안 됐는데 터널 방식 트랜잭션과 조기 종료 연결은 그 필드들이 채워지는 경로를 안 타서 값이 비어 있기 때문이다. 그래서 로그를 보내는 에이전트의 전송 필터에서 제외 규칙으로 걸렀고 소스에서 못 거르면 다음 단계에서 거르면 되므로 소스에서 안 되면 못 한다는 결론으로 끝내지 않았다.
후속과 선행의 기준
이 건의 시작이 후속으로 미뤄 뒀다는 것이었다. 미룰 때는 구축이 급했고 주소 확인은 나중에 해도 될 것으로 보였다.
지적을 받고 다시 보니 순서가 틀렸는데 다음 단계인 실 트래픽 전환이 그 검증에 의존하기 때문이다. 후속과 선행 조건을 가르는 기준은 다음 단계가 그것에 의존하는지이고 의존하면 후속이 아니다.
정리
- 전송 계층 헬스체크는 포트만 보고 동작은 보지 않는다
- 고정 주소 연결이 조용히 실패해도 정상으로 보고된다
- 전용 엔드포인트에서 의도한 상태를 직접 검증한다
- 하나를 잘 만들면 게이트와 동작 검증과 노이즈 제거를 함께 해결한다
- 소스에서 못 거르는 로그는 전송 계층에서 거른다
- 소스에서 안 되면 못 한다는 결론으로 끝내지 않는다
- 후속과 선행의 기준은 다음 단계가 그것에 의존하는지다
- 의존하면 후속이 아니다