|
| 1 | +# LoadBalancing |
| 2 | + |
| 3 | +## 로드밸런싱이란 무엇일까? |
| 4 | + |
| 5 | +<img src="https://user-images.githubusercontent.com/85864699/208324606-5fce605e-0741-4fb5-b882-5900b65a987c.png" alt="Untitled" style="zoom:50%;" /> |
| 6 | + |
| 7 | +- 네트워크 또는 서버에 가해지는 부하(로드)를 분산(밸런싱) 해주는 기술이다. |
| 8 | +- 로드 밸런싱 기술을 제공하는 서비스 또는 장치를 **로드밸런서**라고 하며 클라이언트와 네트워크 트래픽이 집중되는 서버들 또는 네트워크 허브 사이에 위치한다. |
| 9 | +- 특정 서버 또는 네트워크 허브에 부하가 집중되지 않도록 하여 트래픽을 다양한 방법으로 분산하여 서버나 네트워크 허브들의 성능을 최적인 상태로 유지한다. |
| 10 | +- Scale up: 서버 자체의 성능을 높인다. |
| 11 | +- Scale out: 여러대의 서버를 두는 것이다. |
| 12 | + |
| 13 | +## 로드밸런서의 동작방식 |
| 14 | + |
| 15 | +1. 클라이언트가 브라우저에 www.naver.com이라고 입력한다. |
| 16 | +2. 클라이언트에 설정된 메인 DNS서버로 www.naver.com의 IP주소 문의한다. |
| 17 | +3. 메인 DNS 서버는 로드 밸런서의 IP(Virtual IP)주소를 별도의 DNS 서버에 문의한다. |
| 18 | +4. 별도 DNS 서버는 로드 밸런서의 IP주소를 메인 DNS 서버에게 알려준다. |
| 19 | +5. 메인 DNS 서버는 획득한 VIP(가상 IP주소)를 클라이언트에 전송한다. |
| 20 | +6. 클라이언트에서 로드밸런서의 VIP주소로 HTTP요청한다. |
| 21 | +7. 로드밸런서는 별도의 로드밸런싱 방법(ex.라운드로빈)을 통하여 서버에게 요청을 전송한다. |
| 22 | +8. 서버의 작업 결과를 받은 로드 밸런서는 전달받은 HTTP 결과를 클라이언트에게 전송한다. |
| 23 | + |
| 24 | +## 로드 밸런싱의 기본 기능 |
| 25 | + |
| 26 | +- **Health Check** |
| 27 | + - 서버들에 대한 주기적인 Health Check를 통해 서버들의 장애 여부를 판단하여, 정상 동작중인 서버로만 트래픽을 보낸다. |
| 28 | + - L3 체크 : ICMP를 이용하여 서버의 IP주소가 통신 가능한 상태인지 확인한다. |
| 29 | + |
| 30 | +  |
| 31 | + |
| 32 | + **🍇 ICMP** |
| 33 | + |
| 34 | + TCP/IP에서 IP 패킷을 처리할 때 발생되는 문제를 알려주는 프로토콜이다. |
| 35 | + |
| 36 | + **호스트가 없거나, 포트가 닫혀 있는** 등의 에러 상황이 발생할 경우 IP헤더에 기록되어 있는 출발지 호스트로 **에러에 대한 정보를 보내주는 역할**을 한다. |
| 37 | + |
| 38 | + - L4 체크 : TCP는 3Way-Handshaking기반으로 통신하는데, 이러한 TCP 특성을 바탕으로 각 포트 상태를 체크하는 방식이다. |
| 39 | + - L7체크: 애플리케이션 계층에서 체크를 수행. 실제 웹페이지에 통신을 시도하여 이상 유무 파악한다. |
| 40 | +- Tunneling(터널링) |
| 41 | + - 데이터 스트림을 인터넷 상에서 가상의 파이프를 통해 전달하는 기술이다. |
| 42 | + - 패킷 내에 터널링할 대상을 캡슐화시켜 목적지까지 전송한다. |
| 43 | + - 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화 해제하게 한다. |
| 44 | +- Network Address Translataion(NAT) |
| 45 | + - 내부 네트워크에서 사용하는 사설 IP주소와 로드 밸런서 외부의 공인 IP주소간의 변환 역할을 한다. |
| 46 | + - 로드 밸런싱 관점에서는 여러개의 호스트가 하나의 공인 IP주소(VLAN or VIP)를 통해 접속하는 것이 주 목적이다. |
| 47 | + - SNAT(Source Network Address Translation) : 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP주소 → 외부 공인 IP주소로 변환한다. |
| 48 | + - DNAT(Destination Network Address Translation) : 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP주소 → 내부 사설 IP주소로 변환한다. |
| 49 | +- DSR (Destination Network Address Translation) |
| 50 | + - 서버에서 클라이언트로 트래픽이 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음, 네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트를 찾아가는 방식이다. |
| 51 | + - 이 기능을 통해 로드 밸런서의 부하를 줄여줄 수 있다. |
| 52 | + |
| 53 | +로드 밸런싱 알고리즘 |
| 54 | + |
| 55 | +- 라운드 로빈 방식 |
| 56 | + - 서버로 들어온 요청을 순서대로 돌아가며 배정한다. |
| 57 | + - **클라이언트의 요청을 순서대로 분배하기 때문에 서버들이 동일한 스펙을 가지고 있고, 서버와의 연결이 오래 지속되지 않는 경우 적합**하다. |
| 58 | +- 가중 라운드 로빈 방식 |
| 59 | + - 각각의 서버마다 가중치를 매기고, 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분한다. |
| 60 | + - **주로 서버의 트래픽 처리 능력이 상이한 경우 사용**된다. |
| 61 | +- IP 해시 방식 |
| 62 | + - 클라이언트의 IP주소를 특정 서버로 매핑하여 요청 처리한다. |
| 63 | + - 사용자의 IP 주소를 해싱하여 부하 분산하기에 사용자가 **항상 동일한 서버로 연결되는 것을 보장**한다. |
| 64 | + - **경로가 보장되며, 접속자 수가 많을 수록 분산 및 효율이 뛰어나다.** |
| 65 | +- 최소 연결 방식 |
| 66 | + - Request가 들어온 시점에 가장 적은 연결(세션) 상태를 보이는 서버에 우선적으로 트래픽 할당한다. |
| 67 | + - **자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합하다.** |
| 68 | +- 최소 응답시간 방식 |
| 69 | + - 서버의 현재 연결상태와 응답시간을 모두 고려하여 가장 짧은 응답시간을 보내는 서버로 트래픽을 할당하는 방식이다. |
| 70 | + - **각 서버들의 가용한 리소스와 성능, 처리중인 데이터 양등이 상이할 경우 적합**하다. |
| 71 | +- 대역폭 방식 |
| 72 | + - 서버들과의 **대역폭을 고려하여 서버에 트래픽 할당**한다. |
| 73 | + |
| 74 | +## L4로드 밸런싱과 L7로드 밸런싱 |
| 75 | + |
| 76 | +- L4로드 밸런싱 |
| 77 | + |
| 78 | +  |
| 79 | + |
| 80 | + - 4계층 : 네트워크 계층, 3계층 : 전송계층의 정보를 바탕으로 로드를 분산한다. |
| 81 | + - IP주소,포트번호,MAC주소(하드웨어 주소),전송 프로토콜 등에 따라 트래픽 분산 가능하다. |
| 82 | + - [장점] |
| 83 | + - 패킷의 내용을 확인하지 않고 로드를 분산하므로 속도가 빠르고 효율이 높다. |
| 84 | + - 데이터의 내용을 복호화할 필요가 없기에 안전하다. |
| 85 | + - L7로드 밸런서보다 가격이 저렴하다. |
| 86 | + - [단점] |
| 87 | + - 패킷의 내용을 살펴볼 수 없기에 섬세한 라우팅 불가하다. |
| 88 | + - 사용자 IP가 수시로 바뀌는 경우, 연속적인 서비스 제공하기 어렵다. |
| 89 | +- L7 로드밸런싱 |
| 90 | + |
| 91 | +  |
| 92 | + |
| 93 | + - 애플리케이션 계층에서 로드를 분산하기 때문에 HTTP헤더, 쿠키 등과 같은 사용자 요청을 기준으로 특정서버에 트래픽 분산 가능하다. |
| 94 | + - L4 로드 밸런서의 기능에 더하여 **패킷 내용 확인**하고 그 내용에 따라 로드를 특정서버에 분배하는 것이 가능하다. |
| 95 | + - 특정한 패턴 지닌 바이러스 감지해 네트워크 보호 가능하다. |
| 96 | + - Dos/DDos와 같은 비정상적인 트래픽 필터링 가능하다. |
| 97 | + - URL 스위칭: 특정 하위 URL들을 특정 서버로 처리하는 방식이다. |
| 98 | + - Contect Switching : 클라이언트가 요청한 특정 리소스에 대해 특정 서버로 연결 가능 하다. |
| 99 | + - 쿠키 지속성 : 쿠키 정보 카탕으로 클라이언트가 연결했었던 동일 서버에 계속 할당해주는 방식, 특히 사설 네트워크에 있던 클라이언트의 IP주소가 공인 IP주소로 치환되어 전송하는 방식을 지원한다. |
| 100 | + - [장점] |
| 101 | + - 상위 계층에서 로드 분산하기 때문에 훨씬 더 섬세한 라우팅이 가능하다. |
| 102 | + - 캐싱 기능을 제공한다. |
| 103 | + - 비정상적인 트래픽 사전에 필터링 할 수 있어서 서비스 안정성이 높다. |
| 104 | + - [단점] |
| 105 | + - L4 로드 밸런서에 비해 비싸다. |
| 106 | + - 패킷의 내용을 복호화 하여야 하므로 더 높은 비용 지불해야 한다. |
| 107 | + - 클라이언트가 로드밸런서와 인증서 공유해야하기 때문에, 공격자가 로드 밸런서 통해 클라이언트의 데이터에 접근할 수 있는 보안상의 위험성이 존재한다. |
| 108 | + |
| 109 | +## GSLB? CDN? DNS? |
| 110 | + |
| 111 | +- DNS |
| 112 | + - 도메인 네임을 IP주소로 매핑해주는 서비스이다. |
| 113 | + - DDNS는 Dynamic DNS로 실시간으로 DNS 갱신하며, 동적 DNS라고도 불린다 |
| 114 | + - DDNS를 사용한다면 IP주소가 변경되더라도 DNS에 IP를 바뀐 IP주소로 갱신해주어 IP가 변경되더라도 문제없이 사용가능하다. |
| 115 | + - DNS는 health check를 할 수 없어 오버로드 상태가 되어도 사용자들은 과부하 서버로 연결을 요청할 것 이다. |
| 116 | +- GSLB |
| 117 | + |
| 118 | +  |
| 119 | + |
| 120 | + - 로드밸런싱에서 업그레이드 된 형태 같지만 실제로는 DNS 서비스의 발전된 형태이다. (지능적 DNS 서비스라고 불리기도 한다) |
| 121 | + - DNS를 동적으로 만들고, IP주소와 관련된 프로그램 및 컨텐츠의 상태와 특성을 이해하도록 설계됐다. |
| 122 | + - SLB가 실제 서버의 상태 점검과 모니터링을 수행하는 것과 마찬가지로 GSLB 시스템은 IP 주소 뒤에 있는 응용 프로그램과 콘텐츠의 가용성 모니터링 가능하다. |
| 123 | + - GSLB가 Health Check에 실패한 경우 해당 IP주소가 DNS 응답 풀에서 제외된다. |
| 124 | + - GSLB의 목표 |
| 125 | + - 재난 복구 : 실패에 대해 대체할 수 있는 서버를 제공한다. |
| 126 | + - 부하 분산: 많은 트래픽을 여러 서버로 분산시킨다. |
| 127 | + - 성능: client 위치나 네트워크 기반으로 최적의 성능을 낼 서버 선택해준다. |
| 128 | + - DNS와의 차이점 |
| 129 | + |
| 130 | + |
| 131 | + | | GSLB | DNS | |
| 132 | + | --- | --- | --- | |
| 133 | + | 재해 복구 | 서버의 상태를 모니터링 (Health Check) 실패한 서버의 IP는 응답에서 제외 | 서버의 상태를 알 수 없다. 서비스를 실패하는 유저 발생 | |
| 134 | + | 로드밸런싱 | 서버의 로드 모니터링하여 로드가 적은 서버의 IP를 반환하는 방식 가능 | Round Robin 방식사용. 정교한 로드 밸런싱이 되지 못함 | |
| 135 | + | 레이턴스 기반 | 지역별 latency 정보를 가져 유저에게 더 적은 latency를 가지는 서버로 연결 | Round Robin. 네트워크상 멀리 떨어진 위치의 서버로 연결할 수 있다. | |
| 136 | + | 위치기반 서비스 | 유저의 지역 정보를 기반, 해당 지역을 서비스하는 서버로 연결 | Round Robin | |
| 137 | +- CDN |
| 138 | + - 지리적, 물리적으로 떨어져 있는 사용자에게 컨텐츠를 더 빠르게 제공할 수 있는 기술 |
| 139 | + - 느린 응답속도를 극복하기 위한 기술이다. |
| 140 | + - 만약 유럽에 있는 국가가 한국 서버를 이용할 경우 물리적인 거래로 인해 요청/응답 속도가 늦어질 수 밖에 없다. 이런 경우 유럽 요청자 근처의 위치의 CDN 서버에 복사하여 유럽 사용자에게 더 빠른 연결, 속도를 보장할 수 있다. |
| 141 | + - HTML, CSS, JS, Video 등의 리소스들을 빠른 속도로 다운 받을 수 있게 하며 DDOS 같은 서버 다운 시킬 수도 있는 악의적인 공격을 방어하는데도 매우 효울적이다. |
| 142 | + - 미리 정적인 자원들을 캐싱하여 사용자의 위치와 가까운 곳에 복사본을 저장하고, 바로 자원을 쓸 수 있게 제공하는 기술이다. |
| 143 | + - CDN을 가능하게 하는 기술을 GSLB라고 한다. |
| 144 | + - CDN을 사용하지 않는 경우 |
| 145 | + |
| 146 | +  |
| 147 | + |
| 148 | + - 콘텐츠를 담고있는 Origin Server들은 모든 사용자의 요청에 일일이 응답해야하므로 막대한 트래픽 유발, 부하 끊임없이 들어온다. |
| 149 | + - CDN을 사용하는 경우 (Cache Server이용) |
| 150 | + |
| 151 | +  |
| 152 | + |
| 153 | + - 서버의 트래픽 부하 및 비용을 줄이고 사용자에게 빠른 서비스 제공 가능하다. |
| 154 | + |
| 155 | + - CDN 필요기술 |
| 156 | + - Load Balance |
| 157 | + - 사용자에게 콘텐츠 전송요청을 받았을 때 최적의 네트워크 환경을 찾아 연결하는 기술 , GSLB라고 한다. |
| 158 | + - 콘텐츠 배포하는 기술이다. |
| 159 | + - CDN의 트래픽을 감지하는 기술이다. |
| 160 | + - CDN 캐싱 방법 |
| 161 | + - Static Caching |
| 162 | + - Origin Server에 있는 콘텐츠를 미리 Cache Server에 복사한다. |
| 163 | + - 대부분 국내 CDN이 이 방식을 사용한다. |
| 164 | + - Dynamic Caching |
| 165 | + - Origin Server에 있는 콘텐츠를 미리 Cache Server에 복사하지 않는다. (최초 Cache Server에는 콘텐츠가 없다) |
| 166 | + - 사용자가 Content 요청시 해당 콘텐츠가 없는 경우 Origin Server로 부터 다운로드 받아 전달. 있는 경우 캐싱된 콘텐츠가 사용자에 전달한다. |
| 167 | + - 각 Content는 일정 시간(TTL)이 지나면 Cache Server에서 삭제될 수 있고, 혹은 Origin Server를 통해 Content Freshness 확인 후에 계속 가지고 있을 수 있다. |
| 168 | + - Akamai, Amazon 같은 글로벌 CDN 업체가 이 방식을 지원한다. |
| 169 | + |
| 170 | +## 참고자료 |
| 171 | + |
| 172 | +- [https://www.stevenjlee.net/2020/06/30/이해하기-네트워크의-부하분산-로드밸런싱-load-balancing-그/](https://www.stevenjlee.net/2020/06/30/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%9D%98-%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-load-balancing-%EA%B7%B8/) |
| 173 | + |
| 174 | +- [https://velog.io/@jhoryong/Network-CDN-DNS](https://velog.io/@jhoryong/Network-CDN-DNS) |
| 175 | + |
| 176 | +- [https://velog.io/@chun_gil/CDN-Content-Delivery-Networks-개념-정리](https://velog.io/@chun_gil/CDN-Content-Delivery-Networks-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC) |
| 177 | + |
| 178 | +- [https://co-no.tistory.com/22](https://co-no.tistory.com/22) |
| 179 | + |
| 180 | +- [https://manvscloud.com/?p=447](https://manvscloud.com/?p=447) |
| 181 | + |
| 182 | +- [https://skstp35.tistory.com/294](https://skstp35.tistory.com/294) |
0 commit comments