리버스 프록시, 원래 주소를 잃지 않게 넘기기

원래 요청 정보를 잃지 않게 넘깁니다

앞단이 요청을 받아 뒤쪽 애플리케이션으로 넘기면, 애플리케이션이 보는 정보는 앞단의 것으로 바뀝니다. 접속한 사용자 주소가 앞단 주소로 보이고, 암호화 연결로 들어왔는데 일반 연결로 보일 수 있습니다. 그러면 접속 기록이 전부 같은 주소로 남고, 애플리케이션이 만드는 링크가 잘못된 접두사로 생성됩니다. 그래서 넘길 때 네 가지를 함께 전달합니다. 원래 호스트 이름, 접속자 주소, 연결 방식, 그리고 원래 포트입니다. 전달한 뒤에는 애플리케이션 쪽에서 그 값을 신뢰하도록 설정해야 하고, 신뢰 범위를 앞단 주소로 제한해야 위조를 막을 수 있습니다.

제한 시간을 뒤쪽 응답 분포에 맞춥니다

제한 시간을 기본값 그대로 두면 장애 때 문제가 커집니다. 뒤쪽이 응답하지 않는데 앞단이 길게 기다리면 연결이 쌓이고, 쌓인 연결이 앞단의 처리 여력을 먹습니다. 그래서 제한 시간은 뒤쪽 응답 시간 분포를 보고 정합니다. 평균이 아니라 상위 백분위수를 기준으로 삼고, 그 값의 몇 배 수준에서 끊습니다. 함께 설정할 것은 연결 시도 제한 시간과 읽기 제한 시간입니다. 두 값을 구분하지 않으면 연결 자체가 안 되는 상황과 응답이 느린 상황을 같은 시간으로 다루게 됩니다. 또 업로드가 있는 경로는 예외로 길게 두어야 합니다.

쌓이는 연결 수를 계산해 봅니다

학습용 가정으로 계산합니다. 가정값은 초당 요청이 50건이고 뒤쪽이 응답하지 않는 장애가 발생했다고 두겠습니다. 제한 시간이 60초이면 그 시간 동안 쌓이는 연결은 50 곱하기 60으로 3,000건입니다. 제한 시간을 10초로 줄이면 50 곱하기 10으로 500건입니다. 중간 계산값인 차이는 2,500건입니다. 최종 판단은 앞단의 동시 연결 한도와 비교해서 합니다. 한도가 1,000건이라면 60초 설정에서는 한도를 넘겨 정상 경로의 요청까지 막히고, 10초 설정에서는 여유가 남아 다른 경로는 계속 동작합니다. 제한 시간이 장애 격리 장치로 작동하는 셈입니다.

짧은 제한 시간이 정상 요청을 끊을 수 있습니다

결론을 뒤집는 조건은 정상적으로 오래 걸리는 요청입니다. 보고서 생성이나 대용량 업로드처럼 수십 초가 정상인 경로를 짧은 제한 시간으로 묶으면 정상 요청이 끊어집니다. 그래서 제한 시간을 경로별로 다르게 둡니다. 일반 경로는 짧게, 오래 걸리는 경로는 별도 설정으로 길게 둡니다. 두 번째 조건은 재시도 설정입니다. 제한 시간이 지나면 다른 서버로 다시 보내는 설정이 켜져 있으면, 느린 요청이 모든 서버를 차례로 누르게 됩니다. 그래서 재시도 조건을 연결 실패에만 한정하고 응답 지연에는 적용하지 않도록 설정합니다.

웹호스팅 실행 전 점검표

• 호스트·접속자 주소·연결 방식·포트를 함께 전달했다
• 전달값 신뢰 범위를 앞단 주소로 제한했다
• 연결 제한 시간과 읽기 제한 시간을 구분해 설정했다
• 오래 걸리는 경로를 별도 설정으로 분리했다