9.5 DDoS 방어 장비

• 기존 공격은 직접 공격해 관리자 권한을 탈취하는 데 초점이 맞추어져 있었다면 방화벽 대중화 이후의 공격은 정상적인 서비스가 불가능하도록 방해하는 데 초점이 맞추어져 있음
• 이 공격 방식을 DoS(Denial of Service) 공격이라고 함
• 하지만 해커 단독으로 하나의 서비스를 불가능하게 만드는 데는 제한이 많음
• 그래서 다수의 공격자를 만들어 동시에 DoS 공격을 하는 분산형 DoS인 DDoS 공격 방식으로 발전했고 이런 공격을 방어하기 위해 DDoS 전용 장비가 등장

9.5.1 DDoS 방어 장비의 정의

• 초기 DDoS 공격은 시스템이나 네트워크 장비의 취약점이 타깃인 경우가 많았음
• 단순한 DDoS 형태의 공격들도 다양한 기존 장비를 보완하는 기능이 나오고 취약점을 노린 DDoS 공격도 제조업체들이 보안 패치 대응으로 큰 효과를 발휘하지 못하자 다양한 DDoS 공격 형태가 등장
• DDoS 방어 장비는 볼류메트릭 공격을 방어하기 위해 트래픽 프로파일링 기법을 주로 사용하고 인터넷의 다양한 공격 정보를 수집한 데이터베이스를 활용하기도 함

9.5.2 DDoS 방어 장비 동작 방식

• DDoS 방어 서비스로는 클라우드 서비스, 회선 사업자의 방어 서비스, DDoS 방어 장비를 사내에 설치하는 방법이 있음
• 회선 사업자와 DDoS 방어 장비를 이원화해 협조하는 서비스도 많이 등장하고 있음
• DDoS 공격을 탐지해 공격을 수행하는 IP 리스트를 넘겨주면 방어 장비나 ISP 내부에서 이 IP를 버리는 것이 가장 흔한 DDoS 방어 기법
• DDoS 장비가 DDoS 여부를 판별하는 방식은 다양함
• 우선 DDoS 방어 장비의 주요 차단 방법인 프로파일링 기법
• 평소 데이터 흐름을 습득해 일반적인 대역폭, 세션량, 초기 접속량, 프로토콜별 사용량 등을 저장
• 이렇게 습득한 데이터와 일치하지 않는 과도한 트래픽이 인입되면 알려주고 차단
• 습득한 데이터는 다양한 날짜 범위와 다양한 요소를 모니터링함
• 또 하나의 방법은 일반적인 보안 장비처럼 보안 데이터베이스 기반으로 방어하는 것
• IP 평판 데이터베이스를 공유해 DDoS 공격으로 사용된 IP 기반으로 방어 여부

9.5.3 DDoS 공격 타입

• DDoS 공격은 다양한 기법이 있지만 일반적으로 회선 사용량을 가득 채우는 볼류메트릭 공격(Volumetric Attack)과 3, 4계층의 취약점과 리소스 고갈을 노리는 프로토콜 공격, 애플리케이션의 취약점을 주로 노리는 애플리케이션 공격 3가지가 있음

9.5.4 볼류메트릭 공격

• 볼류메트릭 공격은 회선 사용량이나 그 이상의 트래픽을 과도하게 발생시켜 회선을 사용하지 못하도록 방해하는 공격이므로 회선을 공급해 주는 ISP 내부나 사용자 네트워크 최상단에 위치시켜 이 공격을 완화해야 함
• DDoS 장비는 주로 볼류메트릭 공격이나 프로토콜 공격을 방어하는데 사용
• 혼자 방어할 수 없는 공격도 많으므로 회선을 공급하는 ISP와 공조해 방어할 필요가 있음

9.5.4.1 좀비 PC를 이용한 볼류메트릭 공격

• 볼류메트릭 공격은 특정 시간에 특정 타깃을 공격하는 형태로 발생
• 공격자가 상대적으로 적은 대역폭으로 중간 리플렉터에 패킷을 보내면 이 트래픽이 증폭되어 피해자 네트워크에 수십~수백 배의 공격 트래픽이 발생하는 공격법을 증폭 공격이라고 함
• ISP를 통한 방어나 Cloud DDoS 솔루션을 통해 서비스 네트워크로 트래픽이 직접 도달하지 못하도록 조치해야 함
• 클라우드 기반 서비스는 DDoS, WAF과 같은 별도의 보안 장비 없이도 다양한 DDoS 공격을 방어할 수 있다는 장점이 있음
• 클라우드 기반 서비스의 최대 장점은 실제 서비스 네트워크가 가려지므로 네트워크 차원이나 대규모 볼류메트릭 공격도 큰 투자 없이 방어할 수 있다는 것

9.6 VPN

9.6.1 VPN 동작 방식

• VPN은 가상 네트워크를 만들어주는 장비로 터널링 기법을 사용
• 패킷을 터널링 프로토콜로 감싸 통신하는 기법이 터널링 기법
• 패킷을 암호화하거나 인증하거나 무결성을 체크하는 보안 기능을 이용해 인터넷에 패킷이 노출되더라도 해커나 기관들이 감청하지 못하도록 보호할 수 있음
• 현재 가장 많이 사용되는 보안 VPN 프로토콜은 IPSEC과 SSL
• 일반적으로 VPN은 3가지 형태로 구현
  • Host to Host 통신 보호
    • 두 호스트 간에 직접 VPN 터널을 연동하는 기법
    • VPN 구성으로 잘 사용하지 않음
  • Network to Network 통신 보호
    • 본사-지사 같은 특정 네트워크를 가진 두 종단을 연결하는 경우
    • IPSEC 프로토콜 스택이 가장 많이 사용됨
  • Host가 Network로 접근할 때 보호
    • 모바일 사용자가 일반 인터넷망을 통해 사내망으로 연결하는 경우이며 IPSEC과 SSL 프로토콜이 범용적으로 사용
• 이런 서비스는 단순히 사이트를 우회하는 기법으로 많이 사용되지만 카페와 같은 공중 무선망을 사용할 때, 해커의 공격을 암호화 기법으로 원천 방어할 수 있어 공중 네트워크를 사용하는 경우, 이런 VPN을 보안에 활용하는 것이 좋음
• 클라우드 기반의 VPN은 언급했던 데이터가 암호화되고 보호되므로 외부에서 패킷을 확인할 수 없다는 점을 이용한 것

10. 서버의 방화벽 설정/동작

• 서버에 운영체제를 설치하면 리눅스나 윈도 서버 모두 운영체제의 자체 방화벽이 함께 설치됨

• 운영체제에서 동작하는 서버의 방화벽은 서버 보안을 강화하기 위해 최소한의 서비스 포트만 열어둔 채 대부분의 서비스는 차단함

• 방화벽은 일반적으로 필요한 IP 주소와 서비스 포트에 대해서만 열어주고 나머지는 모두 차단하는 화이트리스트 기반으로 정책을 관리함

  10.1 리눅스 서버의 방화벽 확인 및 관리

• 리눅스에서는 호스트 방화벽 기능을 위해 보통 iptables을 많이 사용

10.1.1 iptables 이해하기

• 시스템 관리자는 iptables을 통해 서버에서 허용하거나 차단할 IP나 서비스 포트에 대한 정책을 수립함

• 이렇게 수립된 정책은 정책 그룹으로 관리함

• 정책 그룹은 서버 기준의 트래픽 구간별로 만드는데 여기서 말하는 트래픽 구간은 서버로 유입되는 구간(INPUT), 서버에서 나가는 구간(OUTPUT), 서버를 통과하는 구간(FORWARD) 등을 말함

• 그리고 이렇게 만들어진 방향성과 관련된 정책 그룹은 각 정책의 역할에 따라 다시 상위 역할 그룹에 속하게 됨

• 정리하면 정책은 방향성에 따라 방향성과 관련된 정책 그룹으로 분류하고 이렇게 분류된 그룹들은 역할과 관련된 정책 그룹으로 다시 묶이게 됨

• iptables에서 개별 정책의 방향성에 따라 구분한 그룹을 체인이라고 하며 체인을 역할별로 구분한 그룹을 테이블이라고 함

• 즉, 개별 정책의 그룹이 체인이 되고 체인 그룹이 테이블임

• iptables에는 필터 테이블, NAT 테이블, 맹글 테이블, 로 테이블, 시큐리티 테이블 이렇게 5가지 테이블이 있음

• 패킷을 허용하거나 차단하는 데 사용하는 테이블이 필터 테이블

• 여기서 다룰 리눅스의 호스트 방화벽은 이 필터 테이블을 통해 트래픽을 제어하는 것을 의미

• 테이블에는 방향성과 관련된 그룹이 있다고 했는데 이 그룹이 체인

• 필터 테이블에는 서버로 들어오는 트래픽, 나가는 트래픽, 통과하는 트래픽에 따라 INPUT 체인, OUTPUT 체인, FORWARD 체인이 있음

• 각 체인에는 해당 체인에 적용될 방화벽 정책을 정의

• 각 정책에는 정책을 적용하려는 패킷과 상태 또는 정보 값과의 일치 여부 조건인 매치와 조건과 일치하는 패킷의 허용(Accept)이나 폐기(Drop)에 대한 패킷 처리 방식을 결정하는 타깃으로 구성됨

  • Filter 테이블
    • iptables에서 패킷을 허용하거나 차단하는 역할을 선언하는 영역
  • INPUT, OUTPUT, FORWARD 체인
    • 호스트 기준으로 호스트로 들어오거나 호스트에서 나가거나 호스트를 통과할 때 사용되는 정책들의 그룹
    • 패킷의 방향성에 따라 각 체인에 정의된 정책이 적용됨
  • Match
    • 제어하려는 패킷의 상태 또는 정보 값의 정의
    • 정책에 대한 조건
  • Target
    • Match와 일치하는 패킷을 허용할지, 차단할지에 대한 패킷 처리 방식

  10.1.2 리눅스 방화벽 활성화/비활성화

• CentOS 7, IPv4 기준

// firewalld 비활성화

$ systemctl disable firewalld
$ systemctl stop firewalld

// iptables 설치

$ yum install iptables-service

// service 명령어나 systemctl 명령어로 iptables 서비스를 활성화

$ service iptables start // CentOs 6
$ systemctl start iptables.service // CentOs 7

10.1.3 리눅스 방화벽 정책 확인

// iptables의 설정값을 확인하는 명령은 -L (--list) 옵션을 사용

$ iptables -L

ACCEPT  all--  anywhere  anywhere  state RELATED, ESTABLISHED

• INPUT 체인 1번 정책
  • 첫 번째 허용 정책을 보면 RELATED, ESTABLISHED 상태인 모든 출발지에 대해 허용하도록 룰이 설정되어 있음
  • 이미 세션이 맺어져 있거나(ESTABLISHED) 연계된 세션이 있을 때, 어떤 출발지나 목적지인 패킷이더라도 허용하는 정책
  • FTP는 원시적인 프로토콜이어서 컨트롤 프로토콜과 데이터 프로토콜이 별도로 동작
  • 처음 연결된 이후 로그온, 항목 리스트 등의 실제 파일을 다운로드하기 전까지 컨트롤 프로토콜을 사용하고 실제로 데이터 다운로드 명령이 내려지면 별도로 세션을 만들어 다운로드를 시작
  • 두 개의 연결이 별도로 이루어지다 보니 방화벽 입장에서는 이 두 개의 연결을 연계시키지 못하면 제대로 통신을 할 수 없음
  • RELATE state를 이용해 이 두 가지의 연결을 하나로 간주하게 됨

ACCEPT  icmp--  anywhere  anywhere

• INPUT 체인 2번 정책
  • ICMP에 대한 허용 정책
  • 이 정책을 통해 ping과 같은 서비스를 사용할 수 있음

ACCEPT  tcp--  anywhere  anywhere  state NEW tcp dpt:ssh

• INPUT 체인 4번 정책
  • 신규 세션인 NEW state 중 목적지 서비스 포트가 SSH인 경우만 허용
  • 간단히 표현하면 외부에서 서버로 SSH(22) 접속을 허용하는 정책

REJECT  all--  anywhere  anywhere  reject-with icmp-host-prohibited

• INPUT 체인 5번 정책
  • 다섯 번째 정책은 위의 첫 번째부터 네 번째 정책에 매치되지 않은 패킷들을 차단하는 정책
  • INPUT 체인 자체는 기본 정책이 ACCEPT로 선언되어 있지만 이 정책 때문에 화이트리스트 기반 방화벽처럼 동작하게 됨
  • REJECT는 곧바로 폐기하는 DROP과 달리 ICMP 프로토콜을 이용해 패킷 차단 이유를 출발지에 전달
  • iptables의 기본 룰에서는 icmp-host-prohibited 메시지를 이용해 해당 패킷이 차단되었음을 알려줌

ACCEPT  all--  anywhere  anywhere

• INPUT 체인 3번 정책
  • iptables -L의 내용만으로 보면 모든 출발지의 모든 트래픽에 대해 허용하므로 마치 Any Open 정책처럼 보임
  • 하지만 실제로 외부에서 들어오는 패킷은 해당 정책을 거치지 않고 최하단의 DROP 정책에서 대부분 걸러짐
  • iptables 설정 확인

$ iptables -S

• 모든 정책에 대해 허용하는 것으로 되어 있지만 실제로 해당 정책이 적용되는 인터페이스가 루프백 인터페이스(lo)임을 알 수 있음
• 실제 정책이 어떻게 정의되어 있는지 확인하려면 -S이나 iptables 파일을 직접 확인해야 함

10.1.4 리눅스 방화벽 관리

• iptables에 웹 서비스가 가능하도록 http 서비스 포트를 열어주는 정책 추가

$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT

• 정책을 추가하려면 -A나 --append 옵션을 사용
• 옵션 뒤에는 어떤 체인에 적용할 것인지를 지정
• 체인명 뒤에는 넣을 정책을 정의
• 프로토콜을 지정하기 위해 -p(또는 --protocol) 옵션을 사용
• 목적지 포트를 제어하기 위해 --dport 옵션을 사용
• 출발지 포트는 --sport 옵션을 사용
• 출발지나 목적지의 IP 주소를 제어하기 위해 -s(또는 --source), -d(--destination) 옵션을 사용
• IP 주소 설정을 별도로 하지 않으면 anywhere로 적용
• 정책에 일치하는 패킷을 어떻게 처리할 것인지를 정하는 타깃 지정은 -j 옵션 사용
• iptables의 정책 삭제는 -A 대신 -D나 --delete 옵션을 사용

$ iptables -D INPUT -p tcp --dport 21 -j ACCEPT

• 정책이 너무 많을 때는 -L 옵션으로 일치하는 정책이 있는지 확인하기 어려우므로 -C나 --check 옵션을 사용해 해당 정책이 있는지 확인할 수 있음

$ iptables -C INPUT -p tcp --dport 21 -j ACCEPT

• 특정 위치에 정책을 추가하려면 정책의 줄 번호를 지정해야 함
• 기본 정책 확인 명령어로는 방화벽 정책의 줄 번호를 확인할 수 없으므로 -L 옵션 뒤에 --line-number 옵션을 추가해 현재 정책의 줄 번호를 확인

$ iptables -L --line-number

• 기존 tables에 추가할 때는 -A 옵션을 사용했지만 특정 위치에 정책을 추가하기 위해서는 -I나 --insert 옵션을 사용

$ iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT

• 특정 서비스 포트에 대해 특정 IP만 허용

$ iptables -A INPUT -i eth0 -p tcp -s 172.16.10.10/32 --dport 22 -j ACCEPT
$ iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROP

• IP 주소를 범위로 지정

$ iptables -A INPUT -p all -m iprange --src-range 192.168.0.0-192.168.255.255 -j DROP

• iptable에서 주소를 범위로 지정하는 방법

-m iprange --src-range 시작 IP 주소-끝 IP 주소
-m iprange --dst-range 시작 IP 주소-끝 IP 주소

• 서비스 포트를 범위로 지정

$ iptables -A INPUT -p tcp -m multiport --dport 3001:3010 -j DROP

• -F 옵션을 사용하면 iptables에 적용된 정책을 한꺼번에 삭제 가능

$ iptables -F
$ iptables --flush

• -p 옵션은 각 체인의 기본 정책을 변경

$ iptables -P INPUT DROP
$ iptables -P FOWARD DROP
$ iptables -P OUTPUT DROP

• iptables 정책 파일은 다음의 위치에 있음

/etc/sysconfig/iptables

10.1.5 리눅스 방화벽 로그 확인

• iptables도 일반 방화벽과 마찬가지로 로그를 통해 iptables 정책에 의해 차단되거나 허용된 내용을 확인할 수 있음
• iptables의 로그는 /var/log/messages에 남으므로 메시지 파일을 보려면 다음과 같이 로그 내용을 확인할 수 있음

$ tail -f /var/log/messages

• 하지만 메시지 파일에는 iptables 로그 외에 다른 로그들도 포함되어 있음
• iptables 로그만 확인하려면 다음과 같은 설정이 필요
• rsyslog.conf 파일에 다음과 같이 추가

kern.* /var/log/iptables.log

• rsyslog 서비스를 재시작

$ systemctl restart rsyslog.service

• warning 수준의 로그를 남기기 위해 log-level을 4로 하고 로그를 구분하는 식별자 추가

$ iptables -I INPUT LOG --log-level 4 --log-prefix '## ZIGI-Log ##

• --log-prefix 옵션을 사용하지 않아도 로그를 남길 수 있지만 prefix를 정해두면 로그를 구분할 수 있음
• iptables 정책을 확인하는 -L 옵션 뒤에 -v 옵션을 사용하면 통과하는 패킷과 바이트 수를 확인할 수 있음

$ iptables -L -v

11. 이중화 기술

• 끊김없는 안정적인 서비스를 제공하기 위해서는 네트워크, 서버, 스토리지와 같은 인프라뿐만 아니라 애플리케이션도 이중화(다중화) 기술을 적용해야 함
• 이중화를 위해 동일한 역할을 하는 인프라를 두 대 이상 구성하거나 하나의 장비 내에 네트워크 인터페이스 카드와 같은 내부 구성요소를 다중으로 구성하기도 하고 동일한 역할을 하는 애플리케이션을 동시에 여러 개 띄워 서비스를 제공하기도 함
• 이런 이중화 기술은 서비스 가용성을 높여주고 가용량을 확장해 주기 때문에 안정적인 서비스 제공을 위해 이중화는 필수 요소

11.1 이중화 기술 개요

• 서비스를 제공하기 위한 인프라의 주요 목표 중 하나는 적시에 서비스를 출시하기 위해 인프라를 신속히 제공하는 것
• 소위 타임 투 마켓을 위한 인프라의 민첩성
• 하지만 인프라의 더 본질적인 목표는 더 가용성 높은 서비스에 필요한 인프라를 안정적으로 제공하는 것
• 인프라를 설계할 때 가용성, 연속성, 안정성 등의 항목을 보는 것도 인프라를 안정적으로 제공하는 데 필요한 주요 지표
• 따라서 인프라를 설계할 때, 단일 접점의 장애가 전체 서비스에 영향을 미치지 않도록 SPoF(단일 장애점)를 만들지 않아야 함

11.1.2 이중화의 목적

• 인프라를 구성하는 각 요소가 복수 개 이상으로 인프라를 구성해 특정 인프라에 문제가 발생하더라도 이중화된 다른 인프라를 통해 서비스가 지속되도록 해줌
• 서비스에 필요한 출발 지점부터 끝 지점까지(End-to-End) 속하는 모든 인프라에 이중화 구성을 고려해야 함
• 서비스를 위한 물리적 또는 가상 머신 서버, 서버와 네트워크 장비를 구성해 주는 인터페이스, 서버에 연결된 스위치, 다수 서버의 부하 분산을 위한 L4/L7 스위치, 방화벽, 인터넷 게이트웨이, 인터넷 회선 등 모든 요소가 이중화 구성이 필요한 항목
• 심지어 이 모든 요소가 속한 데이터 센터 자체도 이중화가 필요해 DR 센터나 액티브-액티브 데이터 센터를 구축
• 인프라가 이중화되어 있다면 특정 지점에 문제가 발생하더라도 이중화된 인프라를 이용해 서비스할 수 있음
• 특정 인프라의 장애 상황에서도 서비스는 가능하므로 서비스의 연속성이 보장되고 이것을 폴트 톨로런스(장애 허용, 결함 감내)가 보장된다고 말하기도 함

11.2 LACP

• 1990년대 중반까지는 각 벤더별로 장비 간 대역폭을 늘리기 위해 독자적인 방법으로 구현했지만 벤더 독자적인 방법으로는 다른 장비끼리 연결할 때 호환성 문제가 발생해 이 문제를 해결하기 위해 상호호환 가능한 연결 계층(Link Layer) 표준화를 시작
• 이 표준화가 LACP (Link Aggregation Control Protocol)
• 링크 애그리게이션의 목적은 대역폭 확장을 통한 두 가지를 제공하는 것
  • 링크 사용률 향상(Improved Utilization of Available Link)
  • 향상된 장애 회복(Improved Resilience)
• LACP를 사용하면 두 개 이상의 물리 인터페이스로 구성된 논리 인터페이스를 이용해 모든 물리 인터페이스를 액티브 상태로 사용
• 이것을 통해 스위치와 스위치 또는 스위치와 서버 간 네트워크 대역폭이 물리 인터페이스 수량만큼 확장
• 또한, 논리 인터페이스를 구성하는 물리 인터페이스 중 일부에서 문제가 발생하더라도 나머지 물리 인터페이스로 서비스를 유지
• 액티브-스탠바이가 아니라 액티브-액티브 상태이므로 인터페이스 절체로 인한 지연 없이 서비스를 제공

11.3 서버의 네트워크 이중화 설정

• 인터페이스 이중화에 사용되는 기술 명칭은 윈도우와 리눅스에 따라 다음과 같이 다르게 부름
  • 윈도우: 팀/team/티밍/teaming
  • 리눅스: 본드/bond/본딩/bonding

11.3.1 리눅스 본딩 모드

• 리눅스 본딩 모드는 모드 0~4까지 있음
• 실무에서는 이중화를 구성할 때, 액티브-스탠바이로는 모드 1을 사용하고 액티브-액티브로는 모드 4를 사용하며 나머지 모드는 보통 잘 사용하지 않음

11.3.1.1 모드1: 액티브- 스탠바이

• 인터페이스를 액티브-스탠바이로 구성할 때는 모드 1을 사용
• 평소 액티브 인터페이스로만 패킷이 전달되지만 액티브가 죽으면 스탠바이 인터페이스가 자동으로 활성화되어 패킷을 전송함
• 원래의 액티브 인터페이스가 다시 살아나면 설정에 따라 액티브 인터페이스가 자동으로 다시 활성화(Auto Fail Back)되거나 수동으로 넘기기 전까지 스탠바이 인터페이스가 활성화 상태를 유지

11.3.1.2 모드4: LACP

• 표준 프로토콜인 LACP를 이용해서 인터페이스를 액티브-액티브 방식으로 사용하고 싶을 때는 모드 4로 설정

11.3.3 리눅스 본드 설정 및 확인

11.3.3.1 CentOS에서 본드 설정 및 확인

• 네트워크 설정 파일이 있는 디렉토리에 bond 인터페이스 파일을 생성하고 bond로 묶일 인터페이스에 추가 속성을 설정하는 방식

$ cd /etc/sysconfig/network-scripts

• bond 인터페이스 파일 ifcfg-bond0을 생성해 다음과 같이 설정

ifcfg-bond0

DEVICE=bond0
BOOTPROTO=none
onBOOT=yes
BOOTPROTO=static
IPADDR=10.10.10.11
NETMASK=255.255.255.0
GATEWAY=10.10.10.1

• bond 인터페이스 파일을 설정했으면 물리 인터페이스 파일, ifcfg-eth0, ifcfg-eth1에도 bond 인터페이스 사용을 위한 추가 속성을 설정

ifcfg-eth0, ifcfg-eth1

DEVICE=bond0
BOOTPROTO=none
onBOOT=yes
MASTER=bond0
SLAVE=yes

• 본드 인터페이스 설정을 마친 후에는 bonding 설정 파일 위치로 이동해 속성을 변경

$ cd /etc/modprobe.d/

• bonding 설정 파일

bonding.conf

alias bond0 bonding
options bond0 mode=4 miimon=100

• mode는 본드 구성에 대한 모드 번호
• miimon은 해당 밀리초마다 bond로 묶인 링크를 확인하는 옵션
• bond 모드의 기본값이 0(라운드 로빈)이며 miimon 값은 0(또는 1[0.01초])
• miimon이 0이면 인터페이스 상태를 체크하지 않아 페일오버가 동작하지 않으므로 반드시 확인해 0이 아닌 값으로 변경
• 모드 1을 사용해 액티브-스탠바이 구성으로 본드를 구성할 때는 위의 옵션 값 외에 어떤 인터페이스를 액티브(Primary 속성)로 사용할지에 대한 옵션을 추가로 설정해야 함
• 리눅스 커널에 본드 모듈 적재

$ modprobe bonding

• 본드 인터페이스를 게이트웨이로 설정하고 싶다면 다음 설정을 추가

/etc/sysconfig/network

GATEDEV=bond0

• bond 인터페이스를 설정하거나 수정한 후에는 네트워크를 다시 시작

$ service network restart    //CentOs 6
$ systemctl restart network  //CentOs 7

• 본드 설정 및 네트워크 재시작 후에는 본드가 정상적으로 잘 구성되었는지 확인

$ cat /proc/net/bonding/bond0

본드 설정 후 인터페이스가 정상적으로 활성화되지 않을 때

• 본드 설정 후 네트워크를 다시 시작하는 과정에서 본드 인터페이스가 정상적으로 활성화되지 못하는 경우가 있음
• 이때는 NetworkManager를 중지하고 실행

$ service networkmanger stop
$ chkconfig networkmanger off

11.3.3.2 우분투에서 본드 설정 및 확인

• 우분투에서 본드를 설정하려면 먼저 ifenslave 패키지를 설치

$ apt-get install ifenslave

• 커널 모듈에 bonding 값이 있어야 함
• 만약 없다면 /etc/modules 파일에 bonding이라는 값을 추가하고 재부팅 해야 함

/etc/modules

bonding

• 본딩 설정을 위해 인터페이스 파일인 /etc/network/interfaces에 인터페이스 eth0과 eth1을 bond0 인터페이스로 만들기 위한 설정을 다음과 같이 함

/etc/network/interfaces

auto eth0
iface eth0 inet manual
    bond-master bond0

auto eth1
iface eth1 inet manual
    bond-master bond0

auto eth0
iface eth0 inet static
    address 192.168.1.10
    gateway 192.168.1.1
    netmask 255.255.255.0

11.4 MC-LAG

• 서로 다른 스위치 간의 실제 MAC 주소 대신 가상 MAC 주소를 만들어 논리 인터페이스로 LACP 구성
• MC-LAG 기술을 이용하면 단일 스위치로 LACP를 구성해 대역폭을 확장할 것인지, 서로 다른 스위치로 구성해 장비 이중화로 가용성을 확보할 것인지를 선택할 수 있음

11.4.1 MC-LAG 동작 방식

• 피어 장비
  • MC-LAG을 구성하는 장비를 피어 장비라고 함
• MC-LAG 도메인(Domain)
  • 두 Peer 장비를 하나의 돈리 장비로 구성하기 위한 영역 ID
  • Peer 장비는 이 영역 ID를 통해 상대방 장비가 Peer를 맺으려는 장비인지 판단
• 피어 링크(Peer-Link)
  • MC-LAG을 구성하는 두 Peer 장비 간의 데이터 트래픽을 전송하는 인터링크

11.5 게이트웨이 이중화

11.5.1 게이트웨이 이중화란?

• L2 통신
  • 특정 호스트가 동일한 서브넷에 있는 내부 네트워크와 통신할 때는 ARP를 직접 브로드캐스트해 출발지와 목적지가 직접 통신
• L3 통신
  • 외부 네트워크인 경우, 목적지와 통신하기 위해 게이트웨이를 통해서 하는 통신
• 게이트웨이 역할을 하는 두 대의 장비가 하나의 IP 주소를 가지는 것
• LACP와 유사하게 하나의 IP 주소와 하나의 MAC 주소를 갖고 하단 호스트들이 그 가상 IP와 MAC 주소를 알게 되어 장애가 발생해도 통신이 가능
• 이런 경우 사용하는 프로토콜이 FHRP(First Hop Redundancy Protocol)라는 게이트웨이 이중화 프로토콜
• 게이트웨이 이중화 프로토콜을 사용하면 두 라우터는 실제 IP 외에 추가로 가상 IP 주소와 가상 IP에 대한 MAC 주소를 동일하게 갖음
• 게이트웨이 이중화 프로토콜의 가상 IP는 그룹 내에서 우선순위가 높은 장비가 Active 상태로 유지하고 ARP 요청에 응답
• 하단 호스트들이 사용할 게이트웨이 IP 주소가 이 가상 IP 주소
• 게이트웨이 이중화 프로토콜 그룹 장비 중 가상 IP에 대한 Active 상태를 가진 장비에 문제가 발생하면 Standby 상태인 장비가 Standbt에서 Active 상태로 변경
• 호스트 입장에서는 게이트웨이 IP 주소를 가진 장비가 한 대 이상으로 구성되어 있어 Active 상태의 게이트웨이 장비에 장애가 발생하더라도 게이트웨이와의 통신이 끊기지 않으므로 외부 네트워크와 지속적인 통신을 함

11.5.2 FHRP

• FHRP는 외부 네트워크와 통신하기 위해 사용되는 게이트웨이 장비를 두 대 이상의 장비로 구성할 수 있는 프로토콜
• FHRP를 이용해 FHRP 그룹 내의 장비가 동일한 가상 IP를 갖도록 설정하고 FHRP를 설정할 때는 우선순위 값을 이용해 어떤 장비가 가상 IP 주소에 대한 액티브 역할을 할 것인지 결정
• FHRP 그룹의 장비는 물리적으로 다른 장비이지만 가상 IP와 가상 IP MAC 주소도 동일
• FHRP 기술에 대한 표준 프로토콜은 VRRP(Virtual Router Redundancy Protocol)

11.5.3. 올 액티브 게이트웨이 이중화

• 피어 장비 모두 게이트웨이 역할을 할 수 있음에도 불구하고 트래픽이 불필요하게 우회하므로 비효율적
• MC-LG 기술을 사용할 때는 게이트웨이 이중화 가상 IP의 MAC 주소를 액티브 장비와 스탠 바이 장비에서 모두 사용할 수 있도록 해 게이트웨이를 액티브-액티브 형태로 구성하는 기능을 제공
• 게이트웨이를 액티브-액티브로 구성하면 액티브 장비로 들어오는 트래픽은 물론 스탠바이 장비로 들어오는 트래픽도 스탠바이 장비에서 직접 처리해 트래픽 흐름을 최적화

11.5.4 애니캐스트 게이트웨이

• 게이트웨이가 한 곳에 위치하게 되면 모든 트래픽이 하나의 게이트웨이를 거쳐 통신하게 되므로 통신이 비효율적으로 이루어지게 됨
• 이런 경우, 애니 캐스트 게이트웨이 기술을 적용하면 각 위치에 같은 주소를 가지는 게이트웨이가 여러 개 동작
• 게이트웨이가 여러 곳에 위치하므로 하나의 게이트웨이에 문제가 발생해도 랙 하나에서만 장애가 발생하고 다른 위치에서는 외부로 통신하는 데는 문제가 없음

12. 로드 밸런서

• 서비스의 안정성이나 가용량을 높이기 위해 서비스를 이중화할 때는 서비스 자체적으로 HA 클러스터(High Availability Cluster)를 구성하기도 하지만 복잡한 고려 없이 이중화를 손쉽게 구현하도록 로드 밸런서가 많이 사용
• 로드 밸런서는 다양한 구성 방식과 동작 모드가 있으며 각 방식과 모드에 따라 서비스 흐름이나 패킷 내용이 달라짐

12.1 부하 분산이란?

• 서비스 규모가 커지면 물리나 가상 서버 한 대로는 모든 서비스를 수용할 수 없게 됨
• 서비스 가용성을 높이기 위해 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데 각 서버 IP 주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 함
• 로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 서비스 요청을 분산시켜 부하를 분산함
• 로드 밸런서에는 서비스를 위한 가상 IP(VIP)를 하나 제공하고 사용자는 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근
• 로드 밸런서는 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 사용자의 요청을 분산하므로 서버에서 장애가 발생하더라도 기존 요청을 분산하여 다른 서버에서 서비스를 제공할 수 있음

FWLB

• 서버에 대한 부하 분산뿐만 아니라 방화벽을 액티브-액티브로 구성하기 위해 로드밸런서를 사용하기도 함
• 서버 부하 분산을 SLB(Server Load Balancing), 방화벽 부하 분산을 FWLB(FireWall Load Balancing)라고 함
• 방화벽은 자신을 통과한 패킷에 대해 세션을 관리하는 테이블을 갖고 있음
• 즉, 방화벽을 통과하는 패킷에 대해서는 방화벽 정책을 확인해 허용되는 정책이면 방화벽을 통과시키면서 그 정보를 세션 테이블에 기록
• 응답 패킷은 방화벽 정책을 확인하는 것이 아니라 세션 테이블에서 해당 패킷을 먼저 조회
• 세션 테이블에 있는 응답 패킷이라면 이미 정책에서 허용된 패킷이므로 방화벽을 바로 통과할 수 있음
• 하지만 세션 테이블에 응답 패킷이 없다면 요청한 적이 없는 패킷에 대한 응답으로 간주하고 공격성으로 판단해 해당 패킷은 폐기됨
• 이런 경우는 출발지와 목적지 간 경로가 두 개 이상 있어 비대칭 경로가 만들어질 때도 있음
• 방화벽 장비를 이중화할 경우, 이런 비대칭 동작으로 인해 방화벽이 정상적으로 동작하지 않을 수 있음
• 이런 문제를 해결하고 동시에 이중화된 방화벽을 모두 사용하기 위해 FWLB가 사용
• FWLB가 세션을 인식하고 일정한 규칙을 이용하여 방화벽 세션을 분산하는데 한 번 방화벽을 지나갔던 세션이 다시 같은 방화벽을 거치도록 트래픽을 분산

12.2 부하 분산 방법

• LACP는 두 개 이상의 인터페이스를 하나의 논리 인터페이스로 묶어 회선의 부하를 분산시킴
• LACP는 다수의 물리 인터페이스를 하나의 논리 인터페이스로 구성하기 위해 LACP를 위한 가상의 MAC 주소를 만들게 됨
• 로드 밸런서도 이와 유사하게 부하를 다수의 장비에 분산시키기 위해 가상 IP 주소를 갖게 됨
• 로드 밸런서에는 서비스를 제공하는 서버의 IP인 리얼 IP와 로드 밸런서에서 서비스를 대표하는 VIP가 있음
• VIP에는 리얼 IP가 바인딩되어 있고 사용자가 VIP로 서비스를 요청하면 해당 VIP에 연결된 리얼 IP로 해당 요청을 전달

12.3 헬스 체크

• 로드 밸런서에서는 부하 분산을 하는 각 서버의 서비스를 주기적으로 헬스 체크해 정상적인 서비스 쪽으로만 부하를 분산하고 비정상적인 서버는 서비스 그룹에서 제외해 트래픽을 보내지 않음

12.3.1 헬스 체크 방식

12.3.1.1 ICMP

• VIP에 연결된 리얼 서버에 대해 ICMP(ping)로 헬스 체크를 수행하는 방법
• 단순히 서버가 살아 있는지 여부만 체크하는 방법이므로 잘 사용하지 않음

12.3.1.2 TCP 서비스 포트

• 가장 기본적인 헬스 체크 방식은 로드 밸런서에 설정된 서버의 서비스 포트를 확인하는 것
• 즉, 로드 밸런서에서 서버의 서비스 포트 2000번을 등록했다면 로드 밸런서에서는 리얼 IP의 2000번 포트로 SYN을 보내고 리얼 IP를 가진 서버로부터 SYN, ACK를 받으면 서버에 다시 ACK로 응답하고 FIN을 보내 헬스 체크를 종료함

12.3.1.3 TCP 서비스 포트: Half Open

• 일반 TCP 서비스 포트를 확인할 때는 SYN/SYN, ACK/ACK까지 정상적인 3방향 핸드셰이크를 거치게 됨
• 헬스 체크로 인한 부하를 줄이거나 정상적인 종료 방식보다 빨리 헬스 체크 세션을 끊기 위해 정상적인 3방향 핸드셰이크와 4방향 핸드셰이크가 아닌 TCP Half Open 방식을 사용하기도 함
• TCP Half Open 방식은 초기의 3방향 핸드셰이크와 동일하게 SYN을 보내고 SYN,ACK를 받지만 ACK 대신 RST를 보내 세션을 끊음

12.3.1.4 HTTP 상태 코드

• 로드 밸런서의 헬스 체크 방식 중 HTTP 상태 코드를 확인하는 방식으로 로드 밸런서가 서버로 3방향 핸드셰이크를 거치고나서 HTTP를 요청해 정상적인 상태코드(200 OK)를 응답하는지 여부를 체크해 헬스 체크를 수행

12.3.1.5 콘텐츠 확인(문자열 확인)

• 로드 밸런서에서 서버로 콘텐츠를 요청하고 응답받은 내용을 확인하여 지정된 콘텐츠가 정상적으로 응답했는지 확인하는 헬스 체크 방법
• 특정 웹페이즈를 호출해 사전에 지정한 문자열이 해당 웹페이지 내에 포함되어 있는지를 체크하는 기능
• 이 헬스 체크 방식을 사용하면 로드 밸런서에서 직접 관리하는 서버의 상태뿐만 아니라 해당 서버의 백엔드의 상태를 해당 웹페이지로 체크할 수 있음
• 앞단의 서버가 백엔드로 요청을 하고 백엔드에서 정상적인 결괏값으로 웹 페이지에 특정 문자열을 출력하게 해 백엔드 상태까지 확인하면서 헬스 체크를 수행하는 것
• 한 가지 유의 사항은 단순히 서버에서 응답받은 문자열만 체크하면 정상적인 요청 결괏값이 아닌 문자열만 체크하므로 비정상적인 에러 코드에 대한 응답인 경우라도 해당 응답 내용이 헬스 체크를 하려고 했던 문자열이 포함되어 있으면 헬스 체크를 정상으로 판단할 수 있음 -따라서 문자열을 이용한 헬스 체크를 수행할 때는 정상 코드 값도 중복으로 확인하거나 문자열 자체를 일반적이 아닌 특정 문자열로 지정해 결과가 정상일 때만 헬스 체크가 성공할 수 있도록 해야 함

12.3.2 헬스 체크 주기와 타이머

• 헬스 체크 주기를 볼 때는 응답 시간, 시도 횟수, 타임아웃 등 다양한 타이머를 함께 고려해야 함
  • 주기(Interval)
    • 로드 밸런서에서 서버로 헬스 체크 패킷을 보내는 주기
  • 응답 시간(Response)
    • 로드 밸런서에서 서버로 헬스 체크 패킷을 보내고 응답을 기다리는 시간
    • 해당 시간까지 응답이 오지 않으면 실패로 간주
  • 시도 횟수(Retries)
    • 로드 밸런서에서 헬스 체크 실패 시 최대 시도 횟수
    • 최대 시도 횟수 이전에 성공 시 시도 횟수는 초기화됨
  • 타임아웃(Timeout)
    • 로드 밸런서에서 헬스 체크 실패 시 최대 대기 시간
    • 헬스 체크 패킷을 서버로 전송한 후 이 시간 내에 성공하지 못하면 해당 서버는 다운
  • 서비스다운 시의 주기(Dead Interval)
    • 서비스의 기본적인 헬스 체크 주기가 아닌, 서비스다운 시의 헬스 체크 주기
    • 서비스가 죽은 상태에서 헬스 체크 주기를 별도로 더 늘릴 때 사용

12.4 부하 분산 알고리즘

• 로드 밸런서가 리얼 서버로 부하를 분산할 때, 로드 밸런서에서는 사전에 설정한 분산 알고리즘을 통해 부하 분산이 이루어짐

12.4.1 라운드 로빈

• 라운드 로빈 방식은 특별한 규칙 없이 현재 구성된 장비에 순차적으로 돌아가면서 트래픽을 분산

12.4.2 최초 접속 방식 (Least Connection)

• 최초 접속 방식은 서버가 가진 세션 부하를 확인해 그것에 맞게 부하를 분산하는 방식
• 로드 밸런서에서는 서비스 요청을 각 장비로 보내줄 때마다 세션 테이블이 생성되므로 각 장비에 연결된 현재 세션 수를 알 수 있음
• 최초 접속 방식은 각각 장비의 세션 수를 확인해 현재 세션이 가장 적게 연결된 장비로 서비스 요청을 보내는 방식
• 서비스별로 세션 수를 관리하면서 분산해 주므로 각 장비에서 처리되는 활성화 세션 수가 비슷하게 분산되면서 부하를 분산

12.4.3 해시

• 해시 방식은 서버의 부하를 고려하지 않고 클라이언트가 같은 서버에 지속적으로 접속하도록 하기 위해 사용하는 부하 분산 방식
• 서버 상태를 고려하는 것이 아니라 해시 알고리즘을 이용해 얻은 결괏값으로 어떤 장비로 부하를 분산할지를 결정
• 알고리즘에 의한 계산값에 의해 부하를 분산하므로 같은 알고리즘을 사용하면 항상 동일한 결괏값을 가지고 서비스를 분산할 수 있음
• 라운드 로빈이나 최소 접속 방식은 부하를 비교적 비슷한 비율로 분산시킬 수 있다는 장점이 있지만 동일한 출발지에서 로드 밸런서를 거친 서비스 요청이 처음에 분산된 서버와 그다음 요청이 분산된 서버가 달라질 수 있어 각 서버에서 세션을 유지해야 하는 서비스는 정상적으로 서비스되지 않음
• 그와 반대로 해시 방식은 알고리즘으로 계산한 값으로 서비스를 분산하므로 항상 동일한 장비로 서비스가 분산
• 즉, 세션을 유지해야 하는 서비스에 적합한 분산 방식
• 하지만 알고리즘의 결괏값이 특정한 값으로 치우치면 부하 분산 비율이 한쪽으로 치우칠 수도 있음
• 해시를 사용해야 하는 이유와 최소 접속 방식의 장점을 묶어 부하 분산하는 방법도 존재
• 라운드 로빈 방식이나 최소 접속 방식을 사용하면서 스티키 옵션을 주어 한 번 접속한 커넥션을 지속적으로 유지하는 기법
• 처음 들어온 서비스 요청을 세션 테이블에 두고 같은 요청이 들어오면 같은 장비로 분산해 세션을 유지하는 방법
• 하지만 이렇게 하더라도 해당 세션 테이블에는 타임아웃이 있어 타임아웃 이후에는 분산되는 장비가 달라질 수 있다는 것을 고려해야 함

12.5 로드 밸런서 구성 방식

• 로드 밸런서의 구성 방식은 로드 밸런서의 구성 위치에 따라 2가지로 나눌 수 있음
  • 원암 구성
  • 인라인 구성
• 원암 구성은 로드 밸런서가 중간 스위치 옆에 연결되는 구성이고 인라인 구성은 서버로 가는 경로상에 로드 밸런서가 연결되는 구성
• 실질적으로 원암과 인라인의 구분은 서버로 가는 트래픽이 모두 로드밸런서를 경유하는지, 경유하지 않아도 되는지에 대한 트래픽 흐름으로 구분

12.5.1 원암 구성

• 로드 밸런서의 원암 구성은 로드 밸런서가 스위치 옆에 있는 형태를 말함
• LACP와 같은 다수의 인터페이스로 스위치와 연결된 경우에도 스위치 옆에 있는 구성이라면 동일하게 원암 구성이라고 함
• 부하 분산을 이용하는 트래픽의 경우 부하 분산에 사용되는 서비스 IP 정보를 로드 밸런서가 가지고 있어 서버로 유입되는 트래픽은 먼저 로드 밸런서를 거침
• 로드 밸런서에서는 각 실제 서버로 트래픽을 분산하고 서버의 응답 트래픽은 다시 로드 밸런서를 거쳐 사용자에게 응답하게 됨
• 원암 구조에서 서버의 응답 트래픽이 로드 밸런서를 다시 거치려면 로드 밸런서를 거칠 때, 서비스 IP에 대해 실제 서버로 Destination NAT뿐만 아니라 서비스를 호출한 사용자 IP가 아니라 로드 밸런서가 가진 IP로 Source NAT도 함께 이루어져야 함
• 로드 밸런서의 부하 분산을 이용하지 않는 트래픽은 원암 구성에서 굳이 로드 밸런서를 거치지 않아도 서버와 통신할 수 있음
• 따라서 원암 구성에서는 로드 밸런서를 이용하는 서비스에 대해서만 로드 밸런서를 경유하므로 불필요한 트래픽이 로드 밸런서에 유입되지 않아 로드 밸런서 부하를 줄일 수 있음
• 스위치와 로드 밸런서 간의 대역폭을 최소화할 수 있고 대역폭이 부족할 때는 이 구간만 대역폭을 증설하면 되므로 인라인 방식보다 상대적으로 확장에 유리
• 원암 구성은 로드 밸런서 부하 감소는 물론 장애 영향도를 줄이기 위해서도 사용
• 로드 밸런서 장비에 장애가 발생하더라도 로드 밸런서를 거치지 않는 일반적인 서비스의 트래픽 흐름에는 문제가 없으므로 원암 구성은 로드 밸런서를 통과해야 하는 트래픽과 통과하지 않아도 되는 트래픽이 섞인 경우에 많이 사용

12.5.2 인라인 구성

• 로드 밸런서의 인라인 구성은 용어 그대로 로드 밸런서가 스위치에서 서버까지 가는 일직선상 경로에 있는 형태를 말함
• 인라인 구성은 트래픽이 흐르는 경로에 로드 밸런서가 있어서 서버로 향하는 트래픽이 로드 밸런서의 서비스를 받는지 여부와 상관없이 로드 밸런서를 모두 통과
• 인라인 구성에서는 부하 분산 여부와 상관없이 모든 트래픽이 동일한 경로로 흐르므로 구성이 직관적이고 이해하기 쉬움
• 그 대신 모든 트래픽이 로드 밸런서를 경유하므로 로드 밸런서의 부하가 높아짐
• 특히 일반 L3 역할을 하는 스위치에 비해 로드 밸런서는 4계층 이상의 데이터를 처리하므로 처리 가능한 용량이 L3 장비보다 적으며 처리 용량이 커지면서 가격도 많이 상승하므로 로드 밸런서 부하에 따른 성능을 반드시 고려해야 함
• 로드 밸런서에서 처리하지 않는 트래픽이 로드 밸런서를 거치더라도 그 부하는 크지 않음
• 인라인으로 로드 밸런서를 선정할 때 로드 밸런싱 성능과 패킷 스루풋 성능을 구별해 디자인해야 함

12.6 로드 밸런서 동작 모드

• 로드 밸런서의 동작 방식은 다음 3가지
  • 트랜스패런트(Transparent: TP), 또는 브릿지
  • 라우티드
  • DSR(Direct Server Return)

12.6.1 트랜스패런트 모드

• 트랜프패런트 구성은 로드 밸런서가 OSI 2계층 스위치처럼 동작하는 구성
• 즉, 로드 밸런서에서 서비스하기 위해 사용하는 VIP 주소와 실제 서버가 동일한 네트워크를 사용하는 구성
• 트랜스패런트 구성은 기존에 사용하던 네트워크 대역을 그대로 사용하므로 로드 밸런서 도입으로 인한 IP 네트워크 재설계를 고려하지 않아도 되고 네트워크에 L2 스위치를 추가하는 것과 동일하게 기존 망의 트래픽 흐름에 미치는 영향 없이 로드 밸런서를 손쉽게 구성할 수 있음
• 트랜스패런트 구성에서는 트래픽이 로드 밸런서를 지나더라도 부하 분산 서비스를 받는 트래픽인 경우에만 4계층 이상의 기능을 수행하며 부하 분산 서비스가 아닌 경우에는 기존 L2 스위치와 동일한 스위칭 기능만 수행

12.6.2 라우티드 모드

• 라우티드 구성은 이름에서도 알 수 있듯이 로드 밸런서가 라우팅 역할을 수행하는 모드
• 즉, 로드 밸런서를 기준으로 사용자 방향과 서버 방향이 서로 다른 네트워크로 분리된 구성
• 로드 밸런서는 사용자 방향과 서버 방향의 네트워크를 라우팅으로 연결
• 라우티드 모드는 보안 강화 목적으로 서버 쪽 네트워크를 사설로 구성해 서버에 직접 접속하는 것을 막는 용도로 사용되기도 함

인라인 모드의 라우티드 구성에서 라우티드 모드의 로드 밸런서가 서버의 게이트웨이 역할을 하거나 로드 밸런서와 서버 사이에 또 다른 L3 장비를 통하는 경우, 해당 L3 장비에서 게이트웨이 역할을 할 수도 있음

12.6.3 DSR 모드

• DSR(Direct Server Returm)은 명칭 그대로 사용자의 요청이 로드 밸런서를 통해 서버로 유입된 후에 다시 로드 밸런서를 통하지 않고 서버가 사용자에게 직접 응답하는 모드
• 로드 밸런서에는 응답 트래픽이 유입되지 않으므로 사용자가 요청하는 패킷에 대해서만 관여
• DSR 모드는 응답할 때, 로드 밸런서를 경유하지 않으므로 원암으로 구성
• DSR 모드는 L2 DSR과 L3 DSR 구분되는데 L2 DSR은 실제 서버의 네트워크를 로드 밸런서가 가진 경우이며 L3 DSR은 실제 서버의 네트워크 대역을 로드 밸런서가 가지지 않은 경우
• 즉, 로드 밸런서에서 실제 서버까지의 통신이 L2 통신인지, L3 통신인지에 따라 L2 DSR과 L3 DSR로 나눌 수 있음
• DSR 모드에서는 요청 트래픽만 로드 밸런서를 통해 흐르므로 로드 밸런서 전체 트래픽이 감소해 로드 밸런서 부하가 감소
• 특히 일반적인 서비스 트래픽인 경우, 서비스 요청 패킷보다 서비스 응답 패킷의 크기가 더 크기 때문에 로드 밸런서의 트래픽 부하 감소에 효과적
• 반면, 이러한 효과가 있는 반면에 DSR 모드의 서비스 응답이 로드 밸런서를 경유하지 않으므로 문제가 발생했을 때, 문제 확인이 어려움
• 다른 동작 모드는 로드 밸런서 설정만 필요하지만 L2 DSR과 L3 DSR은 로드 밸런서 설정 외에 서버에서도 추가 설정이 필요
• DSR 모드를 사용하려면 서버에서도 추가 설정이 필요
  • 루프백 인터페이스 설정
  • 리눅스 커널 파라미터 수정(리눅스) / 네트워크 설정 변경(윈도우)

12.7 로드 밸런서 유의 사항

12.7.1 원암 구성의 동일 네트워크 사용 시

• 로드 밸런서를 거치면서 변경된 IP가 재 응답할 때, 로드 밸런서를 경유하면서 원래의 IP로 바꾸어 응답해야 하지만 원암 구조에서는 응답 트래픽이 로드 밸런서를 경유하지 않아서 발생

12.7.1.1 게이트웨이를 로드 밸런서로 설정

• 서버에서 동일 네트워크가 아닌 목적지로 가려면 게이트웨이를 통과해야 함
• 따라서 로드 밸런서를 통해 부하 분산이 이루어지는 실제 서버에 대해서는 게이트웨이를 로드 밸랜서로 설정하면 로컬 네트워크가 아닌 외부 사용자의 호출에 대한 응답이 항상 로드 밸런서를 통하므로 정상적으로 응답할 수 있게 됨
• 다만 이 경우, 물리적으로는 원암 구조이지만 실제 트래픽 플로가 로드 밸런서를 게이트웨이로 사용하므로 원암 구조에서 가질 수 있는 로드 밸런서의 부하 감소 효과가 줄어듦
• 물론 부하 분산을 사용하지 않는 서버는 기존과 동일하게 게이트웨이를 L3 스위치로 설정하면 로드 밸런서를 경유하지 않으므로 여전히 로드 밸런서의 부하 감소 효과를 가져올 수 있음

12.7.1.2 Source NAT 사용

• 원암 구성의 동일 네트워크 문제를 해결하는 두 번째 방법은 Source NAT를 적용하는 것
• 사용자의 서비스 요청에 대해 로드 밸런서가 실제 서버로 가기 위해 수행하는 Destination NAT뿐만 아니라 출발지 IP 주소를 로드 밸런서가 가진 IP로 함께 변경
• 그럼 서버에서는 사용자의 요청이 아니라 로드 밸런서가 서비스 요청을 한 것으로 보이기 때문에 응답을 로드 밸런서를 보내게 됨
• 로드 밸런서는 응답 패킷의 출발지를 실제 서버에서 로드 밸런서에 있는 서비스 IP(VIP)로 바꾸고 목적지 IP 주소를 로드 밸런서의 IP에서 원래의 사용자 IP로 변경해 사용자에게 응답하게 함
• 다만 이 경우, 서버 애플리케이션 입장에서 보면 서비스를 호출한 IP가 하나의 동일한 IP로 보이기 때문에 사용자 구분이 어렵다는 문제가 있음
• 웹 서비스는 이런 문제를 해결하기 위해 HTTP 헤더의 X-Forwarded-For(XFF)를 사용해 실제 사용자 IP를 확인하는 방법을 사용

12.7.1.3 DSR 모드

• 원암 구조의 동일 네트워크에서 DSR 모드를 사용할 수 있음
• DSR 모드는 사용자의 서비스 요청 트래픽에 대해 별도의 Destination NAT를 수행하지 않고 실제 서버로 서비스 요청 패킷을 전송
• 각 서버에는 서비스 IP 정보가 루프백 인터페이스에 설정되어 있으며 서비스에 응답할 때, 루프백에 설정된 서비스 IP 주소를 출발지로 응답