2024-03-06

docs/sk-lim19f/2024-03-06.md

@@ -0,0 +1,86 @@
+# 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)
+        -   서비스의 기본적인 헬스 체크 주기가 아닌, 서비스 다운 시의 헬스 체크 주기
+        -   서비스가 죽은 상태에서 헬스 체크 주기를 별도로 더 늘릴때 사용