L4 로드밸런서 뒤에서 HTTP/2 요청이 특정 서버에 몰립니다. L7 분산으로 바꾸면 무엇이 달라지나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
L4는 주로 연결·전송 계층 정보를 기준으로 분산하고 L7은 HTTP 요청 같은 애플리케이션 의미를 이해해 분산할 수 있습니다. 연결 하나에 많은 요청이 실리면 연결 단위 균등이 요청 부하 균등은 아닙니다.
동작 원리와 전제
HTTP/2의 긴 연결이 한 backend로 고정되면 새 서버가 생겨도 기존 요청이 이동하지 않을 수 있습니다. L7 프록시는 스트림·요청별 정책을 적용할 수 있지만 프로토콜·배치에 따라 실제 분산 단위를 확인해야 합니다.
선택과 실패 처리
L7은 경로·헤더 라우팅과 인증·관측 기능을 제공할 수 있는 대신 TLS 종료·파싱·메모리·지연 비용이 있습니다. 원본 IP와 전달 헤더의 신뢰, streaming·WebSocket 지원도 설계합니다. 연결 수만 맞춘 뒤 CPU 편중이 사라졌다고 보지 않습니다.
구체적인 사례와 검증
같은 연결 수 100개라도 하나가 초당 만 요청을 보내고 나머지가 거의 유휴라면 연결 개수 분포는 부하를 설명하지 못합니다. 요청 처리 비용·응답 바이트·stream 수를 함께 봐야 합니다. L7 프록시가 요청 단위로 분산할 수 있어도 session affinity나 upstream 연결 정책 때문에 편중이 남을 수 있습니다. 기능별 backend 분리와 상태 외부화도 검토합니다. TLS 종료 위치가 바뀌면 인증서·원본 신원·client IP 전달과 로그의 신뢰 경계를 다시 설계해야 합니다. 분산 방식 교체를 단순 성능 옵션으로만 보고 보안·종료 계약을 놓치지 않겠습니다.
큰 요청·작은 요청·장기 스트림·새 backend 추가·drain을 시험합니다. 연결·요청·CPU·응답 바이트 분포를 각각 봅니다. sticky session이 필요하면 상태 외부화와 일관성 비용까지 비교하겠습니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 핵심 구분: L4는 주로 연결·전송 계층 정보를 기준으로 분산하고 L7은 HTTP 요청 같은 애플리케이션 의미를 이해해 분산할 수 있습니다.
- 선택 조건: L7은 경로·헤더 라우팅과 인증·관측 기능을 제공할 수 있는 대신 TLS 종료·파싱·메모리·지연 비용이 있습니다.
- 검증 기준: 큰 요청·작은 요청·장기 스트림·새 backend 추가·drain을 시험합니다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 연결 수가 균등하면 요청 비용과 CPU도 균등하다고 한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- 새 backend가 생겨도 긴 TCP·HTTP/2 연결이 옮겨가지 않는 이유를 어떻게 확인하나요?
- 프록시가 전달한 사용자 주소·host를 어떤 hop과 재작성 규칙 아래 신뢰하나요?
- health 변경 뒤에도 남은 연결과 요청을 어떤 순서와 기한으로 정리하나요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.