파이오링크 L4스위치 로드밸런싱 개념
파이오링크 PAS-K는 국내 데이터센터에서 가장 널리 쓰이는 국산 L4/L7 로드밸런서(ADC)입니다. 이 글에서는 PAS-K의 동작 구조, SLB·FWLB·GWLB 같은 부하분산 종류, 헬스체크와 세션 유지, 그리고 실제 CLI 설정 예제까지 한 번에 정리합니다.
1. 파이오링크 PAS-K가 뭔가요
파이오링크(PIOLINK)는 2000년에 설립된 국내 네트워크 보안·ADC 전문 기업이고, PAS-K는 이 회사의 대표 제품인 애플리케이션 딜리버리 컨트롤러(ADC)입니다. 흔히 "L4 스위치" 또는 "L4 로드밸런서"라고 부르는 그 장비가 맞습니다.
쉽게 비유하자면 PAS-K는 대형 음식점의 안내데스크 직원과 같습니다. 손님이 입장하면 어느 테이블로 모실지 판단해서 적절히 분산해주고, 만석인 테이블이나 영업 중단된 자리는 빼버리는 역할입니다. 손님(클라이언트)은 안내데스크 직원(PAS-K) 한 명만 보면 되고, 뒤쪽 테이블(서버)이 몇 개인지는 신경 쓸 필요가 없습니다.
PAS-K 시리즈 라인업
PAS-K는 처리 성능에 따라 여러 모델로 나뉩니다. 대표적으로 PAS-K1500 / 2400 / 2800 / 4200 / 4400 / 4800 등이 있고, 가상 어플라이언스인 PAS-KV와 SDN 통합형인 PAS-KS도 운영됩니다. 모든 모델은 파이오링크 전용 운영체제인 PLOS(Piolink Application-aware O/S) 위에서 동작합니다.
예전엔 "L4 스위치"라고 불렀지만, 요즘은 단순 부하분산을 넘어 SSL 가속, 캐싱, 압축, DDoS 방어, WAF 연동까지 다 합쳐진 ADC(Application Delivery Controller)가 정식 명칭입니다. PAS-K는 ADC지만 현장에서는 여전히 "L4" 또는 "L4 스위치"로 더 많이 불립니다.
2. L4 로드밸런서의 기본 개념과 용어
L4 로드밸런서는 OSI 4계층(전송 계층)인 TCP/UDP 포트 기준으로 트래픽을 나누는 장비입니다. HTTP 헤더나 URL 같은 7계층 정보는 들여다보지 않고, "어느 IP의 어느 포트로 들어왔느냐"만으로 어느 서버에 보낼지 결정합니다.
| 용어 | 의미 (쉬운 비유) |
|---|---|
| VIP (Virtual IP) | 클라이언트가 접속하는 대표 IP. 음식점 대표 전화번호처럼, 외부에서는 이 번호 하나만 알면 됩니다. |
| Real Server | 실제로 서비스를 처리하는 뒤쪽 서버들. 음식점의 실제 테이블입니다. |
| Vserver (Virtual Server) | VIP + 포트 + 부하분산 규칙을 묶은 가상 서비스 단위. PAS-K가 외부에 노출하는 서비스의 정체입니다. |
| Filter | 어떤 트래픽을 Vserver로 보낼지 매칭하는 규칙. 안내데스크 직원이 손에 든 매뉴얼이라고 보면 됩니다. |
| Health Check | Real Server가 살아있는지 주기적으로 확인하는 기능. 영업 중인 테이블만 손님에게 안내하는 셈입니다. |
| Persistence | 같은 클라이언트는 같은 서버로 계속 보내주는 기능. 단골손님을 늘 같은 직원이 응대하는 것과 같습니다. |
| SNAT / DNAT | 출발지/목적지 IP 변환. PAS-K가 패킷을 서버에 전달할 때 사용하는 주소 변환 방식입니다. |
3. PAS-K의 핵심 구성요소 — Real Server, Vserver, Filter
PAS-K 설정은 4단계 레이어 구조로 진행됩니다. 한 번 익히면 모든 설정이 이 패턴을 따르기 때문에 머릿속에 그림으로 잡아두는 게 중요합니다.
설정 흐름
- Real Server 정의 — 실제 서버들의 IP/포트를 등록합니다.
- Real Server Group 묶기 — 같은 역할의 서버들을 그룹으로 묶고, 부하분산 알고리즘을 지정합니다.
- Vserver 생성 — VIP와 서비스 포트를 정의하고, 위에서 만든 그룹을 연결합니다.
- Filter 적용 — 어떤 조건의 패킷을 Vserver로 보낼지 매칭 규칙을 만듭니다.
Real → Group → Vserver → Filter 순서로 만들고, 지울 때는 반대로
Filter → Vserver → Group → Real 순서로 지웁니다.
참조 관계 때문에 순서를 어기면 에러가 납니다.
4. 부하분산 알고리즘 6가지
여러 서버에 트래픽을 어떻게 나눠줄지 결정하는 규칙입니다. PAS-K는 아래 6가지를 기본 제공합니다.
| 알고리즘 | 동작 방식 | 언제 쓰나 |
|---|---|---|
| Round Robin | 서버 1→2→3→1... 순서대로 돌아가며 배정 | 서버 사양이 동일할 때, 가장 무난한 기본값 |
| Weighted Round Robin | 서버별 가중치 비율대로 배정 (예: 2:1:1) | 서버 사양이 다를 때 (좋은 서버에 더 많이) |
| Least Connection | 현재 연결 수가 가장 적은 서버에 배정 | 세션이 오래 유지되는 서비스 (DB, FTP) |
| Weighted Least Connection | 가중치 + 연결 수를 함께 고려 | 사양 다른 서버 + 장기 세션 |
| Hash | 클라이언트 IP 등을 해시해서 항상 같은 서버로 보냄 | 세션 고정이 꼭 필요한 환경 |
| Fastest Response | 응답 시간이 가장 빠른 서버에 우선 배정 | 실시간 응답이 중요한 서비스 |
웹 서비스는 Round Robin + Source IP Persistence, DB·세션 중요 서비스는 Least Connection + Cookie Persistence 조합이 가장 흔합니다. 시작은 Round Robin으로 잡고 부하 추이를 본 뒤 조정하는 것이 안전합니다.
5. 헬스체크(Health Check) 동작 방식
죽은 서버에 트래픽을 보내면 사용자에게 에러 페이지가 노출됩니다. 이를 막기 위해 PAS-K는 주기적으로 Real Server에게 "살아있느냐?" 신호를 보내고, 응답이 없으면 자동으로 분산 대상에서 제외합니다.
PAS-K가 지원하는 헬스체크 종류
| 방식 | 설명 |
|---|---|
| ICMP (Ping) | 가장 가벼움. 서버 자체가 살아있는지만 확인. 웹 서비스가 죽어도 OS만 켜져있으면 OK로 판단하는 단점. |
| TCP Port | 지정 포트로 TCP 3-way handshake 시도. 서비스 포트(80, 443 등)가 열려있는지 확인. 실무 기본값. |
| HTTP/HTTPS | 특정 URL로 GET 요청을 보내고 HTTP 200 응답이나 특정 문자열을 확인. 가장 정확하지만 부하 약간 있음. |
| DNS | DNS 서버 부하분산 시 사용. 특정 도메인의 응답을 검증. |
| Script / Custom | 사용자 정의 스크립트로 복합 검증. 예: 특정 API의 JSON 응답 내용 확인. |
주요 파라미터
- Interval(주기): 검사 간격. 기본 5초. 짧을수록 빠른 감지 / 부하 증가.
- Timeout(타임아웃): 응답 대기 시간. 기본 3초. Interval보다 짧아야 합니다.
- Retry(재시도): 몇 번 실패해야 DOWN으로 판단할지. 일시적 네트워크 흔들림 대비.
- Recovery(복구): DOWN 상태에서 몇 번 성공해야 UP으로 복귀할지. 너무 빠르면 플랩(flap) 발생.
헬스체크를 ICMP만 걸어두면 OS는 살아있지만 웹서버 프로세스가 죽은 상황에서도 정상으로 판단해 사용자에게 에러를 노출시킵니다. 웹 서비스라면 반드시 HTTP/HTTPS 헬스체크 또는 최소한 TCP 80/443 체크를 거시기 바랍니다.
6. 세션 유지(Persistence) 정책
쇼핑몰에서 장바구니에 물건을 담아놓고 결제 페이지로 갔는데 다른 서버로 분산되면 장바구니가 비어버립니다. 이를 막기 위해 같은 사용자는 같은 서버로 계속 보내는 규칙이 세션 유지입니다.
| 방식 | 기준 | 특징 |
|---|---|---|
| Source IP | 클라이언트 IP | 가장 흔함. 단, NAT 뒤 여러 사용자가 같은 IP로 보이는 환경에선 부하가 한 서버에 쏠릴 수 있음 |
| Cookie | HTTP 쿠키 | L7 기능. 웹 서비스에 최적. 사용자별로 더 정확히 분리 가능 |
| SSL Session ID | SSL 세션 | HTTPS 환경에서 사용. SSL 핸드셰이크 오버헤드 감소 |
| Hash | IP+Port 해시 | 테이블 저장 없이 항상 같은 서버로 계산. 메모리 효율적 |
7. PAS-K 부하분산 종류 — SLB / FWLB / GWLB / CSLB
PAS-K는 단순히 웹 서버 분산만 하는 게 아닙니다. 무엇을 분산할 것이냐에 따라 여러 종류가 있고, 각각 동작 방식이 조금씩 다릅니다.
① SLB (Server Load Balancing) — 가장 일반적
웹 서버, DB 서버, API 서버 같은 일반 서버들을 묶어 분산하는 가장 기본적인 기능입니다. 보통 "L4 부하분산"이라고 하면 SLB를 의미합니다.
② FWLB (Firewall Load Balancing)
방화벽 여러 대를 묶어 부하를 분산합니다. 방화벽은 양방향 트래픽이 같은 장비를 지나가야 정상 동작하기 때문에, 일반 SLB보다 더 까다로운 대칭 경로(symmetric path) 보장이 필요합니다. PAS-K를 방화벽 앞뒤에 한 대씩 두고 샌드위치 구조로 구성합니다.
③ GWLB (Gateway Load Balancing)
여러 회선(ISP 라우터)을 묶어 인터넷 출구 트래픽을 분산합니다. 회선 하나가 죽어도 다른 회선으로 자동 전환되고, 평소에는 두 회선을 모두 사용해 대역폭을 늘립니다.
④ CSLB (Cache Server Load Balancing)
캐시 서버(프록시)들을 분산합니다. 같은 URL은 같은 캐시 서버로 보내야 캐시 히트율이 높아지므로 보통 Hash 알고리즘과 조합합니다.
⑤ ILB / GSLB
- ILB (Inbound Load Balancing): 외부에서 들어오는 트래픽을 여러 회선으로 분산.
- GSLB (Global Server Load Balancing): 지리적으로 떨어진 데이터센터 간 분산. DNS 기반으로 사용자에게 가까운 사이트로 유도.
8. 실전 CLI 설정 예제
웹 서버 3대를 묶어 HTTP(80) 서비스를 부하분산하는 가장 일반적인 시나리오로 설정해 보겠습니다.
시나리오
- VIP:
10.10.10.100:80 - Real Server:
10.10.10.11, 10.10.10.12, 10.10.10.13(모두 80 포트) - 알고리즘: Round Robin
- 헬스체크: HTTP GET
/health - 세션 유지: Source IP 30분
Step 1. Health Check 정의
PAS-K(config)# slb healthcheck HC_WEB
PAS-K(slb-hc)# type http
PAS-K(slb-hc)# request "GET /health HTTP/1.0"
PAS-K(slb-hc)# response-code 200
PAS-K(slb-hc)# interval 5
PAS-K(slb-hc)# timeout 3
PAS-K(slb-hc)# retry 3
PAS-K(slb-hc)# exit
Step 2. Real Server 등록
PAS-K(slb-real)# ip 10.10.10.11
PAS-K(slb-real)# port 80
PAS-K(slb-real)# healthcheck HC_WEB
PAS-K(slb-real)# exit
PAS-K(config)# slb real WEB2
PAS-K(slb-real)# ip 10.10.10.12
PAS-K(slb-real)# port 80
PAS-K(slb-real)# healthcheck HC_WEB
PAS-K(slb-real)# exit
PAS-K(config)# slb real WEB3
PAS-K(slb-real)# ip 10.10.10.13
PAS-K(slb-real)# port 80
PAS-K(slb-real)# healthcheck HC_WEB
PAS-K(slb-real)# exit
Step 3. Real Server Group 생성
PAS-K(slb-grp)# load-balancing round-robin
PAS-K(slb-grp)# real WEB1
PAS-K(slb-grp)# real WEB2
PAS-K(slb-grp)# real WEB3
PAS-K(slb-grp)# persistence source-ip timeout 1800
PAS-K(slb-grp)# exit
Step 4. Vserver 정의
PAS-K(slb-vs)# ip 10.10.10.100
PAS-K(slb-vs)# port 80
PAS-K(slb-vs)# service-type http
PAS-K(slb-vs)# group WEB_FARM
PAS-K(slb-vs)# exit
Step 5. Filter 적용 및 저장
PAS-K(slb-flt)# src any
PAS-K(slb-flt)# dst 10.10.10.100/32
PAS-K(slb-flt)# protocol tcp port 80
PAS-K(slb-flt)# action vserver VIP_WEB
PAS-K(slb-flt)# exit
PAS-K(config)# end
PAS-K# write memory
상태 확인 명령어
| 명령어 | 용도 |
|---|---|
| show slb real | Real Server 상태 (UP/DOWN) 확인 |
| show slb vserver | Vserver 설정 및 동작 상태 |
| show slb session | 현재 활성 세션 목록 |
| show slb statistics | 트래픽 통계 (cps, bps 등) |
| show slb healthcheck | 헬스체크 동작 결과 |
위 예제는 PLOS의 일반적인 구문 구조를 따른 것이며, 실제 운영 장비의 모델/펌웨어 버전에 따라 세부 옵션이 다를 수 있습니다. 운영 적용 전 반드시 해당 모델의 공식 매뉴얼이나 GUI 화면과 교차 확인하시기 바랍니다.
9. 고가용성(HA) 이중화 구성
PAS-K가 단일 장애점(SPOF)이 되면 안 됩니다. 그래서 보통 두 대를 페어로 묶어 이중화(HA) 구성하는 것이 표준입니다. PAS-K는 Active-Standby와 Active-Active 두 가지 모드를 모두 지원합니다.
| 모드 | 동작 | 장단점 |
|---|---|---|
| Active-Standby | 한 대만 일하고 한 대는 대기. 장애 시 자동 전환 | 구성 단순, 트러블슈팅 쉬움 / 대기 장비가 놀고 있음 |
| Active-Active | 두 대가 VIP를 나눠 동시에 처리 | 자원 활용 극대화 / 설정 복잡, 세션 동기화 이슈 주의 |
핵심 구성 요소
- VRRP 기반 페일오버: 두 장비가 가상 IP를 공유. Active가 죽으면 Standby가 즉시 가상 IP를 인계.
- Session Sync(세션 동기화): 진행 중인 세션 정보를 양 장비가 공유. 장애 시 사용자 세션이 끊기지 않음.
- Config Sync(설정 동기화): 한쪽에서 변경한 설정이 자동으로 다른 장비에 반영.
- Heartbeat: 두 장비가 서로 살아있는지 주기적으로 확인하는 신호. 보통 별도 케이블로 직결.
Heartbeat 케이블이 끊어지면 두 장비가 서로 "상대가 죽었다"고 판단해 둘 다 Active가 되는 스플릿 브레인(Split-Brain)이 발생할 수 있습니다. VIP 충돌로 서비스가 마비되므로, Heartbeat는 반드시 2개 이상의 경로로 이중화해야 합니다.
10. 자주 묻는 질문 (Q&A)
Q1. L4 스위치와 L7 스위치의 차이는 뭔가요?
L4는 IP+포트까지만 보고 분산, L7은 HTTP URL·헤더·쿠키까지 보고 분산합니다. 예를 들어 /api/* 요청은 API 서버로, /img/* 요청은 이미지 서버로 보내는 건 L7 기능입니다. PAS-K는 두 가지를 모두 지원합니다.
Q2. SNAT는 왜 필요한가요?
Real Server가 응답할 때 패킷이 PAS-K를 거치지 않고 클라이언트에게 직접 가버리면 비대칭 라우팅이 되어 세션이 깨집니다. SNAT를 켜면 PAS-K가 출발지 IP를 자신의 IP로 바꿔서 서버에 전달하기 때문에, 서버는 응답을 무조건 PAS-K로 보내게 됩니다. 단, 서버 로그에 클라이언트 IP가 안 남는 단점이 있어 보통 X-Forwarded-For 헤더를 함께 사용합니다.
Q3. PAS-K로 SSL 인증서를 처리할 수 있나요?
네, SSL Offload 기능을 지원합니다. PAS-K에서 SSL을 종단처리(복호화)한 후 뒤쪽 서버로는 평문 HTTP로 보내는 방식이 일반적입니다. 서버의 SSL 처리 부담이 줄고 인증서 관리도 PAS-K 한 곳에서 일괄 처리할 수 있습니다.
Q4. 헬스체크 주기를 짧게 잡으면 서버 부하가 커질까요?
ICMP·TCP 체크는 거의 부하가 없지만, HTTP 체크는 매번 웹 서버 프로세스가 응답을 만들어야 해서 부하가 생깁니다. 보통 5~10초 주기가 적절하며, 1초 같은 짧은 주기는 VoIP나 결제처럼 빠른 감지가 필수인 경우에만 권장합니다.
Q5. PAS-K의 GUI(웹 UI)와 CLI 중 뭘 써야 하나요?
초기 설정·모니터링은 GUI가 빠르고 직관적입니다. 하지만 대량 설정·자동화·정확한 백업 비교 작업은 CLI가 압도적으로 효율적입니다. 운영자는 GUI를 익혀두되, 핵심 명령어 구조(Real→Group→Vserver→Filter)는 반드시 CLI 기준으로 머릿속에 잡아두는 것이 좋습니다.
📌 정리
PAS-K는 Real → Group → Vserver → Filter의 4단 구조만 익히면 대부분의 부하분산 설정이 비슷한 패턴으로 풀립니다. 시작은 SLB + Round Robin + TCP 헬스체크로 잡고, 서비스 특성에 따라 알고리즘과 세션 유지 정책을 조정해 가는 것이 가장 안전합니다. 그리고 운영망에서는 반드시 HA 이중화 + Heartbeat 이중경로를 함께 구성해 스플릿 브레인을 막아야 합니다.
#파이오링크 #PASK #PIOLINK #L4스위치 #로드밸런서 #부하분산 #ADC #SLB #ApplicationDeliveryController #네트워크엔지니어 #PLOS #국산ADC #도담인사이트
댓글
댓글 쓰기