로드밸런서 l4 l7 차이 보고 고르는 방법

몇 년 전 접속자가 늘어난 쇼핑몰에 로드밸런서를 붙였는데, 장애 원인은 장비 성능이 아니었습니다. 점검용 요청이 정상으로 처리돼 죽은 서버로 계속 트래픽을 보낸 겁니다. 로드밸런서 l4 l7 차이를 볼 때도 기능 목록보다 먼저, 어떤 요청을 어디까지 확인하고 나눌지 정해야 합니다.

L4와 L7은 요청을 보는 깊이가 다릅니다

L4는 주로 접속을 맺는 주소와 포트, TCP·UDP 같은 전송 정보를 기준으로 트래픽을 분배합니다. 웹 요청의 경로나 쿠키를 읽어서 분기하는 용도는 아닙니다. 암호화된 통신을 서버까지 그대로 전달하는 구성이 비교적 단순하고, 웹 외의 서비스에도 폭넓게 쓸 수 있습니다.

L7은 웹 요청 내용을 보고 분배합니다. 예를 들어 상품 경로는 웹 서버 묶음으로, 이미지 경로는 별도 서버 묶음으로 보낼 수 있습니다. 호스트 이름, 요청 경로, 헤더, 쿠키 같은 조건을 조합할 수도 있습니다. 다만 암호화된 요청의 내용으로 분기하려면 로드밸런서가 그 내용을 볼 수 있도록 암호화를 해제하는 구성이 필요합니다. 이때 인증서 관리와 로드밸런서 뒤쪽 구간의 암호화 여부까지 운영 범위에 들어옵니다.

같은 L7이라도 제품마다 지원하는 조건과 방식은 다릅니다. L7이면 모든 웹 기능을 자동으로 처리한다고 생각하면 실제 설정에서 어긋납니다. 특히 긴 연결을 유지하는 기능, 업로드 크기 제한, 요청 시간 제한은 도입 전에 확인해야 합니다.

어느 쪽이 필요한지 요청 흐름으로 고릅니다

웹 서버가 여러 대이고 들어온 연결을 고르게 나누는 일만 필요하다면 L4부터 검토할 만합니다. 서버마다 같은 사이트가 올라가 있고, 경로별 분기가 없다면 L7 규칙을 추가해도 얻는 이득이 작습니다. 반대로 한 주소에서 여러 서비스를 운영하거나 특정 경로만 다른 서버로 보내야 한다면 L7이 편합니다. 웹 요청을 기준으로 차단이나 리디렉션 규칙을 적용해야 할 때도 마찬가지입니다.

예를 들어 웹 서버 2대가 각각 초당 200건의 요청을 무리 없이 처리한다고 해도, 앞단에 로드밸런서를 놓았다고 곧바로 초당 400건을 보장하는 것은 아닙니다. 데이터베이스 한 대가 초당 250건에서 밀리면 그 지점이 먼저 한계가 됩니다. 로그인 세션을 각 웹 서버의 메모리에만 저장했다면 요청이 다른 서버로 갈 때 로그인이 풀릴 수도 있습니다. 이 경우 세션 저장소를 공유하거나, 불가피하면 같은 사용자를 같은 서버로 보내는 설정을 검토해야 합니다.

트래픽 규모도 월 방문자 수만으로 판단하기 어렵습니다. 하루 2만 건의 요청이 고르게 들어오는 사이트와 행사 시작 1분에 1만 건이 몰리는 사이트는 필요한 여유가 다릅니다. 평소와 최대 시간대의 초당 요청 수, 동시 연결 수, 응답 시간, 서버 자원 사용량을 먼저 기록하는 편이 요금제 선택에 도움이 됩니다. 작은 사이트라면 서버 한 대와 복구 가능한 백업으로 충분한 경우도 많습니다.

장애 대응은 분배 방식보다 점검 설정에 달렸습니다

로드밸런서는 서버가 살아 있는지 주기적으로 확인합니다. 그런데 첫 화면이 정상 응답해도 데이터베이스 연결이 끊겨 주문만 실패할 수 있습니다. 반대로 점검 요청에 데이터베이스의 모든 상태를 묶어 두면 잠깐의 지연으로 정상 웹 서버까지 한꺼번에 제외될 수 있습니다. 서비스에 중요한 기능을 확인하되, 무엇이 실패했을 때 서버를 분배 대상에서 뺄지 범위를 분명히 잡아야 합니다.

점검 간격이 10초이고 연속 3회 실패해야 제외하도록 설정했다면, 실제 장애 후 제외까지 대략 30초 안팎이 걸릴 수 있습니다. 요청 처리 시간과 점검 시작 시점에 따라 더 달라집니다. 사용자에게 보이는 오류 시간을 줄이려면 이 값을 조정하고, 일시적인 지연 때문에 서버가 계속 빠졌다 돌아오는 현상도 함께 살펴야 합니다.

접속 기록도 확인할 부분입니다. 로드밸런서를 거치면 웹 서버 로그에 사용자 대신 앞단 장비 주소만 남는 구성이 있습니다. 실제 접속 주소를 전달하는 설정이 필요하지만, 전달된 값을 아무 요청에서나 믿으면 기록을 속일 여지가 생깁니다. 웹 서버가 신뢰할 앞단 장비를 지정하고, 그 장비를 통과한 값만 사용해야 합니다.

비용을 계산할 때 빠지기 쉬운 항목

로드밸런서 요금만 비교하면 예상보다 비용이 커질 수 있습니다. 처리한 데이터 양, 새 연결 수, 적용한 규칙, 인증서 운영, 서버 간 전송 비용은 상품마다 계산 방식이 다릅니다. 예를 들어 서버 2대를 서로 다른 구역에 두면 한쪽 장애에는 강해지지만, 구역 간 통신 비용과 데이터 동기화 절차가 추가될 수 있습니다. 월 비용은 평상시와 행사 기간의 사용량을 따로 넣어 계산하는 게 현실적입니다.

한편 로드밸런서가 있어도 원본 파일과 데이터베이스가 한곳에만 있으면 복구 문제는 그대로 남습니다. 서버 한 대를 분배 대상에서 빼 보는 연습, 백업 파일을 실제로 복원해 보는 연습이 필요합니다. 운영하면서 겪은 장애를 돌아보면 L4와 L7 중 어느 이름을 골랐는지보다, 죽은 서버를 제대로 감지하고 다른 서버가 요청을 이어받을 준비가 됐는지가 더 크게 작용했습니다.