정방향·역방향 프록시와 캐시

01포워드 프록시와 리버스 프록시가 대리하는 쪽

• 포워드 프록시포워드 프록시는 클라이언트가 외부 서비스에 접근할 때 선택하는 중계 지점이다.

  • 접근 정책·출발지 통합·캐시 등을 제공할 수 있다.
• 서비스 진입점리버스 프록시는 서버 측 진입점으로 동작하며 클라이언트는 그 주소를 서비스의 주소로 사용한다.
• 백엔드 선택내부 서버 위치를 숨기고 요청 경로에 따라 적절한 백엔드로 전달할 수 있다. 두 역할 모두 중계지만 구성 주체와 요청 대상의 선택 방식이 다르다.
• 앞뒤 연결의 분리리버스 프록시는 보통 클라이언트 연결과 백엔드 연결을 별도로 관리한다.
• TCP 중계와 HTTP 처리클라이언트 TCP 연결의 바이트를 한 네트워크 선처럼 그대로 이어 놓는 것과 HTTP를 해석해 새 요청을 만드는 것은 다르다.
• TLS·프록시TLS 종료 지점이 프록시라면 클라이언트 구간 암호화는 그곳에서 끝나고, 백엔드 구간을 다시 HTTPS로 보호할지는 별도 연결 설정이다.
• 프록시클라이언트용 프록시를 인증 없이 외부에 개방하면 의도하지 않은 중계 경로가 될 수 있다. 역방향 프록시도 허용할 호스트와 경로, 대상 서버를 명확히 제한해야 한다.

02proxy_pass가 URI와 헤더를 바꾸는 방법

• URI가 있는 proxy_passNginx의 location /api/에서 proxy_pass http://127.0.0.1:8000/처럼 URI /를 포함하면 정규화된 요청 URI 중 location에 대응하는 부분을 지정 URI로 대체하는 형태가 된다.

  • /api/items는 백엔드의 /items가 될 수 있다.
• URI 없는 proxy_pass반면 proxy_pass http://127.0.0.1:8000처럼 URI 부분을 생략하면 일반적인 경우 요청 URI를 그대로 전달하므로 /api/items가 유지된다.
• URI 치환의 예외정규식 location·rewrite·변수 사용에는 별도 규칙이 있어 단순 예를 무조건 확장하지 않는다.
• HostHost는 백엔드가 가상 호스트를 고르거나 절대 URL을 만들 때 의미가 있고 X-Forwarded-Proto는 원래 접속 스킴을 전달하는 관례다.
• X-Forwarded-ForX-Forwarded-For에는 여러 프록시 경유 정보가 쌓일 수 있다.
• 헤더애플리케이션이 임의 클라이언트가 보낸 헤더를 그대로 신뢰하면 주소·스킴 위조가 가능하므로 프록시가 덮어쓰거나 검증하고 앱은 신뢰한 중계 지점에서 온 정보만 해석해야 한다.

location /api/ {
    proxy_pass http://127.0.0.1:8000/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

03연결 재사용·버퍼·timeout의 서로 다른 시간

• 백엔드 연결 재사용프록시는 백엔드 연결을 유지해 다음 요청에 재사용할 수 있다.

  • 이는 클라이언트 keep-alive와 별도 연결 풀이다.
• 응답·버퍼응답 버퍼링을 사용하면 백엔드의 응답을 프록시가 받아 저장하면서 느린 클라이언트에 전달할 수 있어 백엔드 연결 점유와 클라이언트 전송을 분리한다.

  • 반대로 스트리밍 이벤트에서는 즉시 전달과 버퍼 설정의 관계가 중요하다.
• timeoutconnect timeout은 백엔드 연결 수립 대기, read timeout은 백엔드 응답 읽기의 대기 조건과 관련되며 많은 구현에서 전체 요청의 절대 총시간이 아니라 연속 읽기 사이의 시간이다.
• 응답오류 502는 유효한 백엔드 응답을 받지 못한 경우, 504는 중계 중 시간 초과를 나타낼 수 있다.
• timeout·요청원인 없이 timeout을 늘리면 느린 요청을 더 오래 점유하게 할 뿐 처리 능력을 늘리지 못한다.
• 요청·응답요청 본문 크기, 연결 제한, 응답 시간 제한, 스트리밍과 WebSocket 같은 기능은 서비스 요구에 맞게 맞춰야 한다.
• 계층별 제한 불일치프록시와 애플리케이션의 제한이 다르면 일부 요청만 실패하는 현상이 나타난다.

07캐시 hit·miss·재검증을 하나의 요청으로 추적하기

• 캐시·Host캐시 키가 Host·Path·Query 등 요청의 구분 요소를 포함한다고 하자.
• Cache miss 처리첫 요청이 miss이면 원본 서버에서 응답을 받아 저장 가능한지 정책을 평가한다.
• 요청·응답다음 요청의 키가 같고 저장 응답이 fresh이면 원본에 가지 않고 응답할 수 있다.
• ETagfreshness가 끝나도 ETag나 Last-Modified 같은 validator가 있으면 조건부 요청으로 변경 여부를 확인한다.

  • 원본이 304를 반환하면 기존 본문을 재사용할 수 있다.
• Cache-ControlCache-Control: no-store는 저장하지 않도록 요구한다.
• no-cacheno-cache는 항상 저장 금지라는 뜻이 아니라 재사용 전에 검증을 요구하는 의미다.
• Vary·요청Vary는 특정 요청 헤더 값에 따라 표현이 달라짐을 알려 주며 캐시는 해당 변형을 구분해야 한다.
• 개인화 응답의 공유 위험사용자별 비공개 응답을 공용 키 하나로 저장하면 성능은 좋아 보여도 다른 사용자에게 정보가 노출될 수 있다.
• 캐시purge·만료·bypass는 서로 다른 캐시 생애 동작이다.
• 오래된 응답 허용 정책장애 시 오래된 응답을 사용할지와 그 허용 기간도 정책으로 정한다.
• 캐시·응답캐시 적중률뿐 아니라 응답 최신성, 원본 오류와 캐시 자체의 오류를 구분할 관찰 정보가 필요하다.

08로드 밸런싱·캐시·엣지의 조합과 상태 위치

• 부하 분산부하 분산은 여러 백엔드 중 하나를 선택하는 역할이다.
• 리버스 프록시리버스 프록시는 부하 분산 없이 단일 서버로만 전달할 수 있고, 캐시 없이 TLS와 라우팅만 처리할 수도 있다.
• CDNCDN 같은 엣지 네트워크는 사용자와 가까운 위치에 응답·계산·보안 기능을 배치하며 캐시는 그 기능 중 하나다.

  • 같은 장비에 여러 역할이 있어도 용어의 목적은 분리해야 한다.
• 애플리케이션 상태 위치요청을 여러 앱에 나누면 로그인 세션·업로드 파일·DB 트랜잭션의 상태가 어디 있는지가 중요해진다.
• 요청·세션한 서버 메모리에만 로그인 상태가 있으면 다음 요청이 다른 서버로 갈 때 세션이 사라진 것처럼 보일 수 있다.
• sticky sessionsticky session은 선택을 묶는 수단이지만 해당 서버 고장 때 상태를 복제해 주지는 않는다.
• 요청·저장 경로 설계정상 요청 경로와 상태 저장 경로를 함께 설명해야 프록시 확대가 서비스 확장으로 이어진다.

09프록시 앞뒤에서 달라지는 연결 정보

• 프록시·TLS역방향 프록시 앞에서 TLS가 종료되는 구성을 생각한다.
• 두 구간의 연결클라이언트는 프록시와 연결하고 프록시는 별도의 연결로 애플리케이션 서버에 요청을 보낸다.

  • 내부 연결이 HTTP인지 HTTPS인지는 별도 설정이다.
• 전달 헤더의 신뢰 경계애플리케이션 소켓이 직접 보는 연결 상대는 보통 프록시이므로 원래 사용자 주소·호스트·프로토콜이 필요한 경우 정의된 전달 정보를 이용한다. 단, 그 정보는 외부 사용자가 임의로 보낸 값과 신뢰된 프록시가 생성한 값을 구분해야 한다.
• X-Forwarded-For클라이언트가 X-Forwarded-For에 임의의 주소를 넣은 채 요청할 수 있다고 가정한다.
• 위조된 주소 헤더프록시가 이를 검증 없이 넘기고 애플리케이션이 첫 값을 무조건 사용자 주소로 믿으면 로그와 접근 판단을 왜곡할 수 있다.
• 프록시·헤더각 프록시가 기존 헤더를 제거·교체·추가하는 규칙과 애플리케이션이 신뢰하는 홉의 범위를 함께 정해야 한다.
• 헤더어떤 단일 헤더 이름을 쓰느냐보다 실제 배치와 신뢰 경계를 일치시키는 것이 중요하다.

1. HTTPS 요청프록시와 TLS를 맺고 HTTP 요청을 전달한다.
2. 헤더·경로 정책허용된 사이트와 경로를 선택하고 전달 헤더를 신뢰 정책에 맞게 정리한다.
3. 별도 upstream 요청설정된 내부 주소와 프로토콜로 새 요청을 보낸다.
4. 응답 반환업무 결과 또는 오류를 프록시에 반환한다.
5. 응답 전달정책에 따라 헤더·캐시 처리를 하고 클라이언트에 돌려준다.

10캐시와 오류가 응답을 바꾸는 지점

• 프록시프록시 접근 로그와 애플리케이션 로그의 요청 수가 다른 것은 캐시·차단·연결 실패 때문일 수 있다.
• upstreamupstream 연결 실패, 연결은 됐지만 응답이 늦은 경우, 본문 전송 중 끊긴 경우를 분리한다.
• 응답·요청시간 제한은 연결·응답·전체 요청 중 어떤 범위에 적용되는지 확인해야 한다.
• Timeout과 자원 점유504가 보인다는 이유로 값을 크게 늘리면 느린 요청이 자원을 더 오래 점유할 수 있다. 요청 식별자와 각 계층의 소요 시간을 연결해 실제 병목을 찾는다.