18장 역방향 프록시와 로드 밸런서의 자리

사용자는 웹사이트 하나에 접속하지만 그 뒤에는 여러 프로그램이 있을 수 있다. 정적 파일을 보내는 서버, 로그인과 업무를 처리하는 서버, 이미지 변환 작업자 등이 나뉜다. 역방향 프록시는 사용자의 요청을 받아 내부의 적절한 서비스로 전달하는 입구 역할을 한다. 일반적인 사용자 측 프록시와 바라보는 방향이 다르다.

이 입구에서 TLS를 종료하거나 요청 크기를 제한하거나 정적 자료를 보내거나 경로에 따라 다른 서버로 보낼 수 있다. 로드 밸런싱은 여러 대상에 부하를 나누는 기능이다. 한 제품이 역방향 프록시와 로드 밸런서를 함께 제공할 수 있다. 역할을 분리해 이해하면 장애가 났을 때 어느 기능의 문제인지 설명하기 쉽다.

균등하게 나누는 것이 항상 공평하지는 않다

요청을 차례로 나누는 라운드 로빈은 단순하다. 그러나 요청의 비용과 서버 성능이 같지 않으면 요청 수가 같아도 부하는 다르다. 현재 연결 수나 가중치, 해시 등을 사용하는 방식도 있다. 어떤 알고리즘이 가장 좋은지 일반적으로 정할 수는 없다. 서비스의 요청 길이와 상태 보관 방식, 서버 간 차이를 고려해야 한다.

로그인 상태를 특정 서버의 메모리에만 두면 다음 요청이 다른 서버로 갈 때 사용자가 로그아웃된 것처럼 보일 수 있다. 세션 고정은 이를 완화할 수 있지만 서버 장애와 확장에 제약이 생긴다. 상태를 공유 저장소로 옮기거나 별도의 방식으로 관리하는 설계를 검토해야 한다. 로드 밸런서를 붙인다고 단일 서버용 프로그램이 자동으로 분산 시스템이 되지는 않는다.

건강 확인이 보는 깊이

포트에 연결되는지 확인하는 검사는 빠르고 단순하다. 하지만 프로그램이 실제로 요청을 처리할 수 있는지까지는 모른다. HTTP 건강 확인은 더 깊게 볼 수 있지만 검사 자체가 무거우면 부담이 된다. 데이터베이스와 외부 의존성을 매번 모두 확인하면 작은 장애가 전체 서버를 동시에 제외시키는 상황도 생길 수 있다. 건강 확인의 목적을 분명히 정해야 한다.

트래픽을 받을 준비가 되었는지와 프로세스를 다시 시작해야 하는지는 다른 질문이다. 시작 중인 서버는 살아 있지만 아직 요청을 받으면 안 될 수 있다. 일시적으로 의존성이 느리다고 모든 인스턴스를 재시작하면 회복을 더 어렵게 만들 수 있다. 검사 결과와 조치의 연결을 과도하게 단순화하지 말자. 실패 한 번이 곧바로 제거와 재시작으로 이어져야 하는 것은 아니다.

시간 제한을 한 줄로 맞추지 않는다

브라우저, 프록시, 응용 서버, 데이터베이스에는 각각 시간 제한이 있다. 프록시가 먼저 포기한 뒤 응용 서버가 계속 무거운 작업을 하면 사용자는 실패를 보고도 서버 부하는 남는다. 전체 요청 마감 시간과 내부 호출의 한도를 설계하고, 가능하면 취소를 아래쪽에 전달해야 한다. 긴 제한을 주는 것이 항상 친절한 것은 아니다. 오래 기다리는 요청이 다른 사용자의 자원을 붙잡을 수 있다.

큰 파일 업로드에는 본문 크기 제한과 버퍼링 정책이 영향을 준다. 응용 프로그램은 큰 파일을 허용했는데 앞의 프록시가 막을 수 있다. 반대로 모든 제한을 제거하면 메모리와 디스크를 쉽게 소진할 수 있다. 필요한 최대 크기와 동시 처리량, 저장 방식, 실패 시 정리 절차를 함께 정한다. 숫자 하나를 늘리는 작업도 여러 자원에 영향을 준다.

원래 사용자의 주소를 믿을 수 있는가

프록시 뒤의 응용 서버에는 프록시 주소가 출발지로 보일 수 있다. 원래 사용자 정보를 전달하는 헤더를 사용하기도 한다. 그러나 인터넷 사용자가 임의로 보낸 같은 이름의 헤더를 그대로 신뢰하면 기록과 접근 제어가 왜곡될 수 있다. 신뢰하는 프록시에서 온 정보만 해석하도록 경계를 정해야 한다. 헤더에 적혀 있다는 사실과 검증된 사실은 다르다.

배포할 서버를 로드 밸런서에서 빼는 순간에도 진행 중인 연결이 남을 수 있다. 새 요청을 멈추고 기존 요청이 끝나기를 기다리는 배출 절차가 필요하다. 무한히 기다릴 수는 없으므로 최대 시간과 긴 연결의 처리 정책을 정한다. 웹소켓처럼 오래 유지되는 연결은 짧은 HTTP 요청과 다른 고려가 필요하다.

로드 밸런서를 한 대만 두면 입구 자체가 단일 장애 지점이 될 수 있다. 관리형 서비스를 사용하더라도 설정 실수나 공통 의존성의 위험은 남는다. 서버 대수만 세어 이중화 여부를 판단하지 말자. 사용자의 요청이 지나가는 경로에서 공통으로 의존하는 곳을 그려 보면 어느 지점에 대비가 필요한지 보인다.

좋은 입구는 복잡함을 숨겨 주지만 운영자에게까지 모든 사실을 숨기면 안 된다. 어느 대상이 요청을 처리했는지, 입구에서 기다린 시간과 내부 처리 시간이 얼마인지, 어떤 이유로 실패했는지 구분해 기록한다. 사용자의 한 번의 클릭을 여러 구성 요소에서 이어 볼 수 있어야 분산된 서비스도 하나의 흐름으로 관리할 수 있다.