이번 글에서는 L3 계층에서의 부하분산(이하 로드 밸런싱)을 가능하게 하는 ECMP와 UCMP 에 대해 알아보고자 합니다.
보통 로드밸런싱이라 하면 L4와 L7단의 프로토콜을 활용한 방법이 대표적이지만, L3 계층에서도 부하분산이 가능합니다.
로드밸런싱(Load Balancing)이란?
로드 밸런싱이란 처리해야 할 일을 나누어 처리하는 것입니다.
비행기를 타기 전에 여행 짐을 위탁 수화물로 부칠 때, 여러 개의 창구에서 수속하는것과 같은 이치이지요.
만약 창구가 1개라면 승객들은 한참 기다려야 짐을 부칠 수 있을 겁니다.
하지만 대다수의 항공사의 경우 창구를 여러 개 두어 일을 처리합니다.
이와 마찬가지로 컴퓨터 공학에서도 어떤 일을 처리할 때 일을 분산시킵니다.
이를 부하 분산(Load balancing) 이라 하며, 의미는 다음과 같습니다.
부하분산 또는 로드 밸런싱(load balancing) 은 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치
와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다. 이로써 가용성 및 응답시간을 최적화 시킬 수 있다.
- 출처 : 위키백과 -
흔히 로드밸런싱이라 함은, L4/L7 단에서의 로드밸런싱을 의미합니다.
하지만 L3 계층에서도 라우팅 프로토콜을 사용한 부하 분산이 가능합니다.
이에 앞서 L3 Switch의 동작 과정을 알아보겠습니다.
L3 Switch 의 동작
L3 Switch 는 OSI 7 Layer 중 3계층인 네트워크 계층에서 동작하는 장비입니다.이 장비는 패킷을 원격지로 송신할 때, 올바른 위치로 가도록 보내주는 역할을 합니다.
이 장비는 특이하게도, 정확한 목적지로 패킷을 전달하지 않습니다. 다만 목적지와 가까운 쪽으로 패킷을 전달합니다.
이 동작은 마치 도로의 이정표와 같습니다.
도로에 보이는 이정표는 운전자를 정확히 목적지로 안내하지는 않습니다.
다만 목적지로 가는 길라잡이의 역할을 하지요.
위 사진의 이정표에 한림이나 하귀로 가려면 앞으로, 노형동으로 가려면 왼쪽으로, 이호테우 해변을 가려면 오른쪽으로 가야 합니다.
운이 좋다면 우회전 하자마자 이호테우 해변이 나올것이고, 아니면 좀 더 가야할 수도 있습니다.
Routing Table
L3 Switch 에서는 라우팅 테이블이 이 이정표의 역할을 합니다.
라우터로 들어오는 패킷을 확인해서 목적지를 확인하고, 라우팅 테이블 상에서 이 패킷이 어느 방향으로 가면 될지를 알려주고, 또 보내주죠.
라우팅 테이블에 작성할 정보를 얻는것을 라우팅, 그리고 이 정보를 바탕으로 패킷을 보내주는 것을 스위칭 이라고 합니다.
라우팅과 스위칭을 하는데에도 여러 방법이 있습니다.
라우팅은 다이렉트 커넥티드, 스태틱 라우팅, 다이나믹 라우팅 등 여러 방법이 있지만 이번 글은 L3 단의 부하분산을 알아보는게 목적이므로 스위칭에 중점을 두겠습니다.
Longest Prefix Match
운전을 하시는 분들은 지도 어플리케이션을 사용해보신 경험이 있을겁니다.
그중 저는 길찾기 기능을 애용하는데요, 출발지와 목적지를 입력하면 아래와 같이 나옵니다.
출발지부터 목적지까지 여러개의 경로가 있네요. 그 중에 제일 최적의 경로를 초록색으로 표시해주기까지 합니다.
그 결과로 광주원주 고속도로를 타고 가는 경로가 선정되었네요.
아마 네이버 지도는 연료비, 이동 거리, 통행료, 소요 시간 등 여러가지를 고려해서 경로를 알려준 듯 합니다.
하지만 이 최적의 경로라 함은 상황마다 다를 수 있습니다.
화물차나 고급유를 사용하는 차는 연료를 아끼는 경로로 가고싶을 수 있고, km 당 주행요금이 붙는 쏘카는 제일 빠른 경로로 가고싶을 수도 있죠. 하지만 일반적으로는 시간도 덜 걸리고, 거리도 짧고, 연료비와 통행료도 덜 나오는 경로를 원할겁니다.
라우터도 마찬가지로 패킷이 어떤 경로로 갈지 지정해야 합니다.
그 중 제일 먼저 고려되는 것이 Longest Prefix Match 입니다.
Longest Prefix Match 를 쉽게 이해하기 위해 예시를 들어보겠습니다.
저는 세종의 저희 집에서 서울의 잠실 한강공원에 가고 싶습니다.
갈 수 있는 방법은 여러개지만, 제일 최우선인 목표는 잠실 한강공원에 제일 가깝게 도착하는겁니다.
그래서 일단 목적지에 도달할 수 있는 방법을 추려보았습니다.
1. 기차를 타고 간다.
2. 버스를 타고 간다.
3. 차를 렌트해서 운전해서 간다.
일단 제일 큰 목표는 정확히 목적지에 도달하는 겁니다. 비용과 시간은 나중에 생각하겠습니다.
기차를 타면 서울역에 내립니다. 4호선과 2호선을 환승해 잠실 한강공원에 도달할 수 있습니다. 정거장을 11개나 거쳐야 하네요.
버스를 타면 고속버스 터미널에 내립니다. 3호선과 2호선을 환승하면 잠실 한강공원에 도달할 수 있습니다. 기차보다는 낫네요.
차로 운전해서 가면 정확히 잠실 한강공원으로 바로 갈 수 있습니다.
이런 상황이라면, 저는 차를 운전해서 가겠습니다.
목표는 잠실 한강공원에 제일 가깝게 도착하는 것인데 잠실 한강공원에 정확히 도착할 수 있다니, 제일 좋은 선택지네요.
전 차가 없으니 차도 렌트해야하고 키로 당 주행비용도 내야하지만, 그건 뒷전입니다.
그 다음으로는 버스를 탈 것 같네요.
고속버스 터미널에서 잠실에 가는게 서울역에서 잠실 가는것보단 낫거든요.
물론 가는길에 좌석도 불편하고 멀미도 나고 시간도 오래걸리겠지만요.
Longest Prefix Match 도 이와 같습니다.
패킷이 스위칭 될 때 목적지와 가장 많은 정보가 일치되는 곳으로 패킷을 보내는게 Longest Prefix Match 입니다.
여기서 말하는 Prefix 는, 네트워크 주소와 호스트 주소 부분을 구분하는 서브넷 마스크 입니다.
직역 하면 "가장 긴 접두사 일치", 즉 서브넷 마스크가 가장 긴(큰) 경로가 우선순위를 가지는거죠.
여기서 중요한 건, 패킷의 목적지 IP 가 라우팅 테이블의 경로 정보의 네트워크에 속해야 한다는 겁니다.
잠실 한강공원에 가고싶은데, 아무리 비용이 덜들고 빨리 가도 세종 호수공원으로 가면 안되잖아요?
위에서 언급했던 세 방법(버스, 기차, 운전)은 그래도 서울로 가긴 합니다.
서브넷 마스크로 따지면 대강 아래처럼 정리할 수 있겠네요.
- 운전, xxx.xxx.xxx.xxx/32
- 버스, xxx.xxx.xxx.xxx/24
- 기차, xxx.xxx.xxx.xxx/16
AD
그래서 저는 운전을 해서 가기로 했습니다.
그런데, 저한테는 또 옵션이 있습니다. 어떤 차를 타고 갈지 정해야합니다.
저는 현대 오토에버에 가고싶으니 현대차를 타고 가는 방법이 우선순위가 높다고 가정하겠습니다.
이처럼 라우터가 경로를 학습한 프로토콜에 따라 우선순위가 달라집니다.
이를 AD(Administrative Distance) 라 부르며, 이는 라우터 장비를 생산하는 회사에 따라 다릅니다.
아래는 Cisco 사의 AD 기본값입니다.
Metric
도로는 고속도로를 타고 갈지, 국도를 타고 갈지도 결정해야 합니다.
도로가 몇 차선인지도 중요합니다. 만약 1차선이면 차가 많이 없어도 답답할겁니다.
또 교통량이 많은 도로인지도 중요하죠. 차가 많으면 길이 막힐테니까요.
이처럼 라우터도 경로의 길이, 대역폭, 지연시간 등 여러 요소를 고려해 비용(Metric) 을 계산합니다.
Longest Prefix Match와 AD를 고려했는데도 동일한 경로가 있다면, 이 Metric이 낮은 경로가 우선적으로 선택됩니다.
여기까지 읽어주셨다면 라우터의 동작과정, 라우팅 우선순위에 대해 이해하셨을 겁니다.
그런데 만약 Longest Prefix Match, AD, Metric 까지 모두 고려했는데도 동일한 경로가 있다면 어떻게 할까요?
ECMP
그때 ECMP 기능을 사용하게 됩니다.
ECMP는 Equal-Cost Multi-Path Routing 의 약자로, 여러 경로가 동일한 비용으로 계산될 때 이 경로 중 하나를 선택해 패킷을 전달하는 방법입니다.
즉 이번글의 제목인 L3단의 부하분산 이라는 말은, 이 ECMP 를 가리키는 말이죠.
하지만 여기서 예상되는 문제가 있습니다.
TCP
ECMP 기능으로 분산 한 패킷의 상위 프로토콜 지시자가 TCP 일 경우 문제가 발생합니다.
TCP 프로토콜은 연결 지향의 프로토콜로, 수신측이 받는 패킷의 순서를 보장하는 프로토콜입니다.
이더넷 프레임에서 보낼 수 있는 패킷의 최대 크기(MTU) 는 1,500 Byte 입니다.
이 크기를 넘어서면 L3 에서 패킷을 나누어 보내는데, 이를 단편화 라고 합니다.
이렇게 단편화 된 패킷은 수신 측의 L3에서 재조립 됩니다.
IPv4 헤더의 32비트부터 47비트까지인 Identification(식별자), 48비트부터 50비트까지인 Flags(플래그), 51비트부터 63비트 까지인 Fragment Offset(단편 오프셋), 이렇게 3가지의 정보를 가지고 재조립 합니다.
그런데, 만약 ECMP 가 단편화 된 패킷을 서로 다른 라우터로 보내면 어떻게 될까요?
최종 목적지에 도달했을 때 패킷의 순서가 바뀌어있을 수 있습니다.
순서가 바뀌면 TCP 동작과정에 의해 재전송 요청을 보내겠지만, 또 ECMP 기능에 의해 패킷의 순서가 꼬일 수 있습니다.
그래서 ECMP는 Per-Flow 방식으로 동작합니다.
Per-Flow 방식은 패킷의 흐름에 따라 모든 패킷이 동일한 경로를 사용하도록 보장합니다.
여기서 말하는 Flow 란, 네트워크 패킷의 속성을 기반으로 정의 됩니다. 대표적으로 아래의 요소들이 같다면, 그 패킷들은 같은 Flow 라고 가정할 수 있습니다.
- 소스 IP 주소
- 목적지 IP 주소
- 소스 포트
- 목적지 포트
- 사용 프로토콜
물론 이렇게 하면 균등한 부하 분산이 되지 않을 수 있습니다.
예를들어 R1으로 보낸 패킷은 작업이 오래 걸리는데, R2로 보낸 패킷은 금방 끝날수도 있죠.
ECMP는 경로의 대역폭이나 지연시간을 고려하지 않고 부하를 분산합니다.
이런 단점을 보완하기 위해 등장한 기술이 UCMP 입니다.
UCMP
UCMP는 UnEqual-Cost Multi-Path 의 약자로, 비용이 다른 경로에 부하를 분산하는 기능입니다.
UCMP 는 경로의 성능이나 대역폭에 따라 트래픽을 비균등하게 분배합니다.
경로 A의 대역폭이 1Gbps 이고, 경로 B의 대역폭이 100Mbps 이면 경로 A로 더 많은 트래픽을 보내는 방식이죠.
하지만 이 또한 단점이 있습니다.
트래픽을 보내려면 해당 경로에 가중치를 설정해야 합니다. 이 가중치는 네트워크 관리자가 수동으로 가중치를 설정하며, 관리자가 경로의 성능을 파악하고 주기적으로 가중치를 조정해야 합니다.
그래야 올바르게 부하가 분산되고, UCMP를 사용하는 이점을 얻는것이겠지요.
하지만 그 전에 관리자가 일일이 가중치를 설정해서 얻는 이점이 클지는 생각해봐야 할 부분인 것 같습니다.
지금까지 L3 단의 부하 분산에 대해 알아보았습니다.
쉽게 설명하려고 하다보니 비유하는 부분이 있는데, 적절한 비유일지는 잘 모르겠습니다.(특히 AD 부분에서 현대차 예시)
다음 글에서는 L4/L7 단의 부하 분산에 대해 알아보겠습니다.
글에 틀린 내용이 있거나 지적할 부분이 있으면 댓글 부탁드립니다.
읽어주셔서 감사합니다.
'Network > L3' 카테고리의 다른 글
| 서브넷 마스크 쉽게 이해하기 (0) | 2024.08.22 |
|---|---|
| MTU, 진짜 1500 Byte 일까? (0) | 2024.08.14 |
