LACP로 2Gbps 만들기 (구성, 로드밸런싱, 단일플로우)

트래픽 병목 현상 LACP(Link Aggregation)로 대역폭

예산도 없는데 1Gbps 링크가 업무 시간마다 꽉 막히는 상황, 저도 겪어봤습니다. 10G 업그레이드를 요청했다가 "예산 없음"으로 바로 반려당한 뒤, LACP라는 선택지를 들여다보기 시작했습니다. 결과는 예상보다 훨씬 괜찮았지만, 처음에 오해했던 부분도 분명히 있었습니다. 그 경험을 그대로 풀어보겠습니다.

LACP 구성: 스위치와 서버를 한 번에 묶는 법

가장 먼저 한 일은 스위치에서 포트채널(Port-Channel) 인터페이스를 생성하는 것이었습니다. 포트채널이란 물리적으로 분리된 여러 이더넷 포트를 하나의 논리적 인터페이스로 묶어 운영 체계와 상위 프로토콜이 단일 링크처럼 인식하게 만드는 구조입니다. Cisco 장비 기준으로 포트채널 인터페이스를 생성하고, 여기에 물리 포트 2개를 LACP active 모드로 연결했습니다.

여기서 active 모드란 LACP 협상을 능동적으로 시작하는 모드입니다. 상대방이 passive 모드여도 협상이 성립되므로, 서버와 스위치 양쪽이 모두 active일 때 가장 안정적으로 동작합니다. 반대로 강제로 묶는 방식은 한쪽 장비가 LACP를 지원하지 않을 때 쓰는 편법에 가깝습니다. 제 경험상 가능하면 쓰지 않는 게 낫습니다. 협상 없이 강제로 묶다가 한쪽이 재시작되면 예상치 못한 동작이 나오는 경우를 겪은 적이 있기 때문입니다.

서버 측은 Linux bonding 드라이버를 802.3ad 모드로 설정했습니다. 802.3ad란 IEEE가 정의한 링크 어그리게이션(Link Aggregation) 표준으로, 여러 물리 링크를 하나의 논리 채널로 묶는 방법과 협상 절차를 규정한 문서입니다. 현재는 IEEE 802.1AX-2014로 통합·개정되어 있습니다. 설정 시 lacp-rate fast와 xmit-hash-policy layer3+4를 지정하는 것이 분산 효율에 가장 유리합니다.

구성 시 확인해야 할 핵심 항목이 있습니다. 스위치와 서버의 포트 속도 및 듀플렉스가 반드시 동일해야 하고, 묶이는 물리 포트들은 같은 VLAN 설정을 공유해야 합니다. LACP PDU(Protocol Data Unit) 교환이 정상적으로 이루어지는지 스위치 로그로 반드시 확인해야 하며, 서버 측 해시 정책은 layer3+4 설정이 분산 효율에 가장 유리합니다. 제가 처음 구성할 때 VLAN 설정이 포트마다 달라서 한 포트만 active 상태로 올라오는 문제를 겪었습니다. 사소한 설정 불일치 하나가 전체 구성을 망가뜨릴 수 있다는 점을 직접 배웠습니다.

로드밸런싱: "2배 빠르다"는 말의 진짜 의미

"LACP를 쓰면 2배 빠르다"라고 생각하는 분들도 있는데, 저는 이 표현이 절반은 맞고 절반은 틀렸다고 봅니다. 기술적으로 정확히 설명하면, LACP가 늘려주는 것은 단일 전송 속도가 아니라 집계 대역폭(Aggregate Bandwidth)입니다. 집계 대역폭이란 링크 여러 개의 용량을 합산한 전체 수용 가능 트래픽 총량을 의미하며, 이것이 실제로 활용되려면 여러 개의 플로우(Flow)가 동시에 흘러야 합니다.

플로우란 동일한 출발지 IP, 목적지 IP, 포트 번호 조합으로 구성된 하나의 연속 트래픽 단위입니다. LACP의 로드밸런싱 알고리즘은 이 플로우 단위로 링크를 배정하는 방식이라, 단일 플로우는 어떤 경우에도 하나의 물리 링크에만 고정됩니다. 즉, 직원 한 명이 혼자 대용량 파일을 내려받는다면 그 전송 속도는 1Gbps를 넘지 않습니다.

제 동료들 중에도 "이제 2Gbps 나오는 거 아니냐"고 기대했다가 실망한 케이스가 실제로 있었습니다. 솔직히 이건 저도 처음엔 헷갈렸습니다. 그러나 파일 서버 특성상 동시에 수십 명이 접근하는 환경이라면 이야기가 달라집니다. 각 클라이언트 세션이 별도의 플로우로 인식되어 L3+L4 해시 알고리즘에 따라 두 링크에 분산되므로, 전체 처리량은 실질적으로 늘어납니다.

일반적으로 해싱 알고리즘이 균등 분산을 보장한다고 알려져 있지만, 실제로 써보니 스위치 벤더마다 결과가 꽤 다릅니다. 해싱 알고리즘이란 플로우의 IP 주소와 포트 번호를 수학적으로 계산해 어느 물리 링크로 보낼지 결정하는 방식으로, 알고리즘 설계에 따라 한쪽 링크에 트래픽이 쏠리는 불균형이 생길 수 있습니다. Cisco의 EtherChannel 구성 가이드에서도 해싱 방식 선택이 분산 효율에 직접적인 영향을 미친다고 명시하고 있습니다. 상황에 따라 layer2, layer3, layer3+4 중 트래픽 패턴에 맞는 옵션을 골라야 한다는 뜻입니다. 이 부분을 간과하면 링크 한쪽이 포화 상태인데 다른 쪽은 거의 놀고 있는 상황이 발생합니다. 저도 초기에 이 불균형을 확인하고 해시 정책을 바꿔서 개선한 경험이 있습니다.

단일 플로우 한계: LACP가 답이 아닌 경우

LACP 도입 후 가장 많이 받은 질문이 "그런데 나 혼자 큰 파일 받을 때는 왜 그대로야?"였습니다. 이 질문에 제대로 답하려면 단일 플로우 한계를 정확히 짚고 넘어가야 합니다.

IEEE 802.1AX 표준의 설계 철학은 패킷 순서 보장입니다. 하나의 플로우를 여러 링크에 동시에 쪼개서 보내면 패킷이 뒤섞이고 TCP 재조립 과정에서 성능이 오히려 떨어집니다. 그래서 표준 자체가 플로우 단위 링크 고정을 원칙으로 삼고 있습니다. 이 점은 단점이 아니라 설계상 의도된 트레이드오프입니다. 이 트레이드오프를 이해하지 못하면 LACP를 도입하고도 "왜 빠르지 않냐"는 불만이 나올 수밖에 없습니다. 기대치 관리가 기술 구현만큼 중요한 이유입니다.

LACP가 실질적인 이득을 주는 환경과 그렇지 않은 환경을 구분해서 판단하는 것이 중요합니다. 동시 접속 클라이언트가 많고 각각 독립적인 세션을 생성하는 파일 서버나 NAS 환경에서는 LACP 효과가 큽니다. 반면 특정 서버 간 단일 대용량 백업 스트림이 주류인 환경에서는 LACP로 얻는 속도 이득은 거의 없습니다. 고가용성(페일오버)이 주목적이고 대역폭 증가는 부수적인 경우라면 LACP는 합리적인 선택입니다.

마케팅 자료에서 "2배 속도"라고 표현하는 것은 기술적으로 부정확하다는 시각도 있는데, 개인적으로는 이 표현이 오히려 기대치를 잘못 설정하게 만든다고 생각합니다. 진정한 단일 링크 성능이 필요하다면 LACP가 아니라 10G 인터페이스로의 업그레이드가 맞는 방향입니다. LACP는 어디까지나 예산 제약 안에서 다중 플로우 처리량과 가용성을 동시에 개선하는 도구입니다. 이 포지셔닝을 명확히 해두지 않으면 도입 후 실망하거나, 반대로 필요한 상황에서 도입하지 않는 두 가지 실수가 모두 발생할 수 있습니다.

마치며

LACP는 저처럼 예산 없이 성능 개선을 요구받는 상황에서 꽤 현실적인 선택지입니다. 다만 적용 전에 "우리 환경의 트래픽이 다중 플로우인가, 단일 플로우인가"를 먼저 확인하는 것이 순서입니다. 그 판단만 정확하게 하면 LACP는 비용 대비 효과가 좋은 솔루션입니다. 구성을 검토 중이라면 Linux bonding 드라이버 문서와 스위치 벤더의 EtherChannel 가이드를 함께 읽어보시길 권합니다. 이론보다 실제 설정 예제를 보면 훨씬 빠르게 이해됩니다.

---

출처 및 참고 경로

• IEEE 802.3ad LACP 표준: https://standards.ieee.org/ieee/802.3ad/1090/
• 시스코 EtherChannel 구성 가이드: Cisco EtherChannel Configuration Guide
• 리눅스 커널 본딩 문서: https://www.kernel.org/doc/Documentation/networking/bonding.txt
• Ubuntu netplan 공식 문서: https://netplan.io/reference/
• Red Hat 네트워크 팀 설정 가이드: Red Hat Docs - Network Teaming
• RFC 7424 - LACP: https://datatracker.ietf.org/doc/html/rfc7424