[NETWORK] L4,L7 스위치, 로드밸런싱

## 서비스를 운영하는 중 트래픽이 많아진다면 어떻게 해야 할까?

- 갑작스러운 이용자의 증가나 사업 확장일 때는 스케일 아웃, 스케일 업 기법으로 해결 가능
- **스케일 아웃**
    - 더 많은 서버 용량과 성능이 필요할 때 서버를 추가하여 시스템을 확장하는 방법
    - 서버 한대에 장애가 발생해도 다른 서버를 활용하여 운영가능
- **스케일 업**
    - 서버의 cpu나 ram을 추가하여 부품만 고성능으로 교환하는 방법
- **스케일 인**
    - 작업이 완료되어 더 이상 필요 없는 Scale Out으로 늘렸던 컴퓨팅 수를 줄이는 방법

! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/be637ced-476c-43ec-b0a8-5b05950a29bc/Untitled.png)

- **AWS Auto Scaling**
    - Scale In / Out 기능을 정책에 따라서 조정해 주는 AWS 서비스를 말한다.

- **비용, 안정성 측면에서 스케일 아웃이 효율적!**

## 로드밸런싱이란?

- 트래픽을 받아서 여러 대의 서버에 부하를 분산시기는 방법
- **목표**
    - 자원사용 최적화
    - 처리량 증가
    - 응답속도 감소
    - 특정 서버의 과부하 방지
    - 안정성, 가용성 제고

## 로드밸런서란?

- 서버나 장비의 트래픽을 **분산**하기 위해 사용하는 장비
- 실제로는 여러 대의 서버가 있더라도 클라이언트 입장에서는 하나로 보이게 할 수 있음
    - 로드밸런서가 대표 ip주소를 가지고 요청을 받아 실제 서버 ip로 분배

- **로드밸런싱 적용 전, 후**

! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/43d1967a-2439-4c35-9009-018ce9bc4333/Untitled.png)

! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/7f99b4f7-7a90-4b58-b190-0b0e9b06ad63/Untitled.png)

- 서버 추상화
    - 클라이언트가 백엔드 서버를 알지 못해도 로드밸런서가 대신 수행해 줌
- 결함 관용적
    - 서버에 장애가 발생해도 나머지 서버로 부하를 나누면 됨
- 성능 개선
    - 여러 대의 서버가 분산해서 일하니깐 응답속도가 감소된다.
    

## L4/L7 로드밸런서

- **L4 로드밸런싱**
    - ip, macm port 등 opi - 4 계층(전송계층) 이하 프로토콜의 헤더를 기반으로 부하 분산
        
        ! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/438e633f-dc89-4264-ad0c-0c1d41bee533/Untitled.png)
        
    - L4는 데이터를 확인할 수 없어 ip와 port만으로 로드밸런싱 수행
        - header 유무 확인 불가
        - path 기반 라우팅 불가
    - **장점**
        - 패킷의 내용 확인 안 하고 분산하니깐 속도 빠르고 효율 좋음(로드밸런서 자체 처리량은 높음 )
        - 데이터 내용 복호화할 필요 없으니 안전
        - 비용 낮음
    - **단점**
        - 패킷 내용을 못 보니깐 섬세한 라우팅 불가 ( 부하가 몰릴 수도)
        - 사용자 ip가 수시로 바뀌면 연속적 서비스를 제공하기 어려움
- **L7 로드 밸런싱**
    - L4의 기능
    - http, ftp, smtp 등 osi - 7 계층(애플리케이션계층) 이하 프로토콜 헤더를 기반으로 부하 분산
        
        ! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/dfb3f540-b64e-42b5-b5d7-6276adb90497/Untitled.png)
        
    - L7는 ip와 port 외에도 uri, payload, 헤더, 쿠키 내용을 확인하여 로드밸런싱 수행
    - **장점**
        - 데이터 보고 로드 분산하니깐 섬세한 라우팅 가능(요청에 따라 특정 서버에 트래픽 분산 가능)
        - 캐싱 기능 제공
        - 비정상 트래픽은 필터링 가능해서 서비스 안정성 높음
            - 헤더 확인 후 에러 리턴
        - keep-alive, pipelining, multiplexing 지원
    - **단점**
        - 비용 높음
        - 패킷 내용을 복호화해야 해서 더 높은 비용 지불
        - 크라리언트가 로드밸런서와 인증서 공유 → 공격자가 로드밸런서를 통해 클라이언트 데이터에 접근 가능하여 보안상 위험성
        
        ! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/63070fc6-24dc-40b6-bd98-96f6271feeb1/Untitled.png)
        

<aside>
💡 특정 기능이 필요한 것이 아니라면, **초당 연결수(Connections Per Sec)**, **동시 연결수(Concurrent Connections)**, **처리용량(Throughput)**을 성능 지표로 하여 L4 로드밸런서와 L7 로드밸런서 중 적절히 선택하는 것이 바람직

</aside>

## Load Balancing 알고리즘

### **정적 부하분산 Static Load Balancing**

- **Round Robin**
    - 입력받은 요청을 각각의 서버에 순차적으로 할당하는 방식.
    - 클라이언트의 요청을 순서대로 분배하기 때문에 알고리즘이 단순하고 각 서버가 트래픽을 골고루 나눠서 처리한다.
    - 각 서버의 처리량이 비슷할 경우 운용.
    
    ! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/24351ded-6271-4b14-a4d2-4cce1b751c86/Untitled.png)
    

- **IP Hash**
    - 클라이언트의 IP주소를 특정 서버에 매핑해 특정 IP에서 전달받은 요청을 항상 매핑된 서버로 보내는 방식.
    - 클라이언트는 항상 동일한 서버로 접속하게 된다.
        
        ! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/73e70314-c1b0-40f4-ad29-a0d05e98dbf0/Untitled.png)
        

### **동적 부하분산 Dynamic Load Balancing**

- **Weighted Round Robin**
    - 각 서버별로 가중치를 설정하고 가중치가 가장 높은 서버에 트래픽을 우선 배정한다.
    - 클라이언트 입력이 100이고 서버 A, B, C의 가중치가 2, 3, 5라고 가정했을 때 각 서버에는 20, 30, 50의 입력이 Round Robin 방식으로 전달된다.
    - 각 서버의 처리량이 상이할 경우 운용.
        
        ! [Untitled](https://prod-files-secure.s3.us-west-2.amazonaws.com/b94b9bfc-91e2-4c3a-850e-03c644dd099f/2c7a6464-0af1-45cf-b10d-a3d4ae7dd3a5/Untitled.png)
        
- **Least Connection**
    - 해당 시점에서 연결된 요청이 가장 적은 서버로 요청을 보낸다.
    - 세션 유지시간이 길거나 서버에 분산된 트래픽이 일정하지 않은 경우 운용.
- Least Response Time
    - 클라이언트 요청을 전달하기 전 각 서버에 응답을 요청하고 응답시간이 가장 짧은 서버에 클라이언트 요청을 전달한다
    - 각 서버의 성능이 상이할 경우 운용.