로드밸런싱
로드밸런싱
다음은 로드밸런싱이다. 로드밸런싱에 대해 알아보기 전에 기초 기념들 및 정의에 대해 알아보자. 로드밸런서의 개념부터 알아보자면 아래와 같다.
로드밸런서는 서버나 장비의 부하를 분산하기 위해 사용하는 장비로, 트래픽을 분배해주는 기능을 하며 4계층 이상에서 동작한다.
이러한 로드밸런서는 로드밸런싱을 구현해서 한 서버에 가중될 수 있는 부하를 여러 개의 서버로 나누어 트래픽을 분배해준다고 할 수 있다. 예를 들어보면, 하나의 웹서비스가 있다고 해보자. 그 웹 서비스에 클라이언트 단에서 서버단에 요청을 한다면. 먼저 그 요청은 웹서버에 닿는다고 할 수 있다. 그런데, 그 웹서버로 들어오는 요청이 많다면? 그래서, 그 요청이 너무 많은 나머지 웹서버에 마비가 온다면? 혹은, api 서버단에 요청을 하는 과정에서 그 api 서버로 가는 트래픽이 많아서 api 서버가 포화된다면? 이러한 상황에서 시스템 엔지니어는 선택을 해야 한다.
서버의 리소스 사양을 높일 것인가? 아니면 적은 서버 여러 대를 로드밸런싱할 것인가?
서버의 리소스 사양을 높일 수 있지만, 트래픽 양은 웹서비스가 성장하고 좋아질수록, 높아질 수 밖에 없는 구조이므로 기하급수적으로 높일 수 밖에 없을 것이다. 그렇다면 그에 따라 리소스 사양을 높이는 데에 대한 비용이 비대하게 증가할 수 밖에 없다. 반면, 적은 리소스의 서버 여러대에 로드밸런서를 통해 트래픽 양을 분배한다면? 비용 효율 면에서 상당히 좋을 것이다. 트래픽 양이 증가한다고 하더라도, 여러 대의 장비들에 분배한다는 점에서 훨씬 안전하고. 그렇기에 로드밸런서라는 방식을 우리는 알아야 하는 것이다.
이러한 로드밸런스는 리버스 프록시를 통해 클라이언트와 웹서버 사이에 로드밸런싱 방식으로 클라이언트의 요청에 대해 웹서버에서 로드밸런싱 방식으로 부하를 처리하는 방식 등으로 쓰이기도 하지만. 실은 k8s에서의 서비스에서 핵심적인 역할을 하게 된다. 이렇게 보면 이를 위해 로드밸런싱을 알아야 하기도 한다.
위 플로우에서 볼 수 있듯이, 레플리카를 통해 여러 개의 파드들로 클러스터상에 띄어져 있고. 이 파드들이 하나의 서비스로 노출되어 서비스를 통해 로드밸런싱으로 구현되어있는 모습을 나타낸 것이다. k8s에서 이는 핵심적인 특징이라 할 수 있다. 한 파드가 죽더라도, 다른 파드들에서 살아있음으로써 하나의 웹 서비스가 죽지 않고 계속 배포되어있는 상황으로 유지할 수 있는 것. 이러한 점은 롤링 업데이트나 무중단 배포에서 상당한 영향을 준다고 할 수 있겠다. 그래서 이러한 원리의 근간인 로드밸런싱에 대해 배운다고 할 수 있겠다.
이러한 로드밸런싱은 4계층 이상에서 동작하는데, 이는 4계층에서 데이터 전송이나 수신이 이루어지기 때문이다. 트래픽을 적절히 분배해서 한 서버에 과도하게 들어오는 트래픽이 없도록 해서 궁극적으로 원활한 데이터 전송 및 수신을 이룬다는 점에서 4계층에서 동작한다고 할 수 있는 것이다. 그런데, 이러한 로드밸런싱은 4계층 뿐만 아니라 7계층에서도 동작할 수 있는데, http나 https 요청에 관해서 트래픽을 처리할 수 있다는 점에서 7계층에서도 적용된다고 할 수 있다. 그래서 4계층 이상에서 동작한다는 표현이 쓰였다고 할 수 있다.
이러한 내용은 아래 시퀀스 다이어그램으로도 나타낼 수 있다.
먼저, 4계층에서 동작하는 로드밸런스를 살펴보자.
다음은 7계층에서의 로드밸런스이다.
이렇게 기초 내용을 살펴보았으니 본격적으로 로드밸런스에 대해 알아보자.
우린 앞에서 여러 서버들로 나누어서 한 서비스에 들어오는 트래픽에 대해 분배를 한다고 들었다. 그런데, 한 서비스에 들어오는 트래픽을 여러 대의 서버에 보내는 과정에서 그냥 그대로 보낼까? 병렬식으로? 클라이언트단에서 요청을 하면, 하나의 서버에서 이를 받아서 여러 대의 서버로 트래픽을 분배할 것이다. 그 하나의 서버가 바로 로드밸런서이고. 그러면 그 하나의 서버인 로드밸런서는 어떤 형태를 띨까? 주로 로드밸런서는 가상 ip 주소로써 서비스에 접근한다. 이러한 로드밸런서를 SIB VIP (Server Load Balancer Virtual IP)라고 하는 것이다. 이러한 SIB VIP는 로드밸런서로써 클라이언트의 요청을 받아서 여러 대의 서버에 적절히 나누어서 트래픽을 보내는데 아래는 그 예시를 나타낸 것이다.
203.0.113.10이란 가상 ip를 가진 로드밸런서가 서버 1, 2, 3에 로드밸런싱으로 트래픽을 분배함을 볼 수 있다. 이때, 로드밸런서와 서버 1, 2, 3은 로드밸런서의 가상 ip에 실제 서버들인 서버 1, 2, 3이 바인딩되는 형태로 로드밸런싱이 이루어지게 된다고 할 수 있겠다. 그리고 로드밸런서의 VIP에 설정된 포트와 실제 서버의 서비스 포트가 다르게 설정되어 있어서 사용자가 VIP의 특정 포트에 접근하고 로드밸런서에서 해당 서비스의 요청을 실제 서버의 다른 서비스 포트로 포트 변경을 함께 수행하는 등 포트에 차이를 두어서도 설정할 수 있다고 하는데. 여기까지는 다루지 않는 걸로.
그러면 여기서 질문! 그러면 만약에 로드밸런서의 VIP에 바인딩된 여러 서버들 중 한 서버에 장애가 발생했다면? 어떻게 할 것인가? 그 서버에 트래픽을 보낼까? 아니다. 이러한 상황 때문에 헬스 체크라는 개념이 등장하게 된다.
헬스 체크(Health Check)는 네트워크나 시스템 구성 요소의 상태를 주기적으로 모니터링하고 확인하는 프로세스를 나타낸다.
헬스 체크를 통해 정상적인 서비스 쪽으로만 부하를 분산하고 비정상적인 서버는 서비스 그룹에서 제외해 트래픽을 보내지 않게 한다는 목적 아래에 이루어지는 건데, 서비스 그룹에서 제외된 후 헬스 체크를 지속적으로 계속 수행해서 다시 정상으로 확인되면 서비스 그룹에 해당 장비를 다시 넣어 트래픽이 서버 쪽으로 보내지도록 한다. 이러한 헬스 체크를 하는 방식은 ping을 이용하거나, 포트, HTTP 상태 코드를 요청해 체크하는 방식 등이 존재한다.
또한, 이러한 헬스 체크를 진행하기 위해 고려해야 할 사항들이 있는데. 주기, 응답 시간, 시도 횟수, 타임아웃=, 서비스 다운시의 주기가 존재한다. 응답 시간을 설정해서 그 응답 시간 내에 서버가 응답을 하지 않으면 다운된 것으로 보고, 헬스 체크 주기를 또 설정해서 주기별로 헬스 체크를 진행. 여러 번의 주기 끝에도 불구하고 서버가 응답하지 않으면 다운된 것으로 간주. 그리고 이 과정에서 타임아웃을 설정하여 정해진 타임아웃까지 헬스 체크가 실패하면 다운된 것으로 간주하는 내용인데 자세히 다루지 않기로 한다.
그리고 부하 분산 알고리즘 등의 내용이 존재하지만, 알고리즘 내용은 아래의 표를 통해 간단히 정리만 하고 넘어가기로 한다.
| 라운드 로빈(Round Robin) | 현재 구성된 장비에 부하를 순차적으로 분산. 총 누적 세션 수는 동일하지만 활성화된 세션 수는 달라질 수 있음. |
| 최소 접속 방식(Least Connection) | 현재 구성된 장비 중 가장 활성화된 세션 수가 적은 장비로 부하를 분산. |
| 가중치 기반 라운드 로빈(Weighted Round Robin) | 라운드 로빈 방식과 동일하지만 각 장비에 가중치를 두어 가중치가 높은 장비에 부하를 더 많이 분산. 처리 용량이 다른 서버에 부하를 분산하기 위한 분산 알고리즘. |
| 가중치 기반 최소 접속 방식(Weighted Least Connection) | 최소 접속 방식과 동일하지만 각 장비에 가중치를 부여해 가중치가 높은 장비에 부하를 더 많이 분산. 처리 용량이 다른 서버에 부하를 분산하기 위한 분산 알고리즘. |
| 해시(Hash) | 해시 알고리즘을 이용한 부하 분산 |
그러면 이제는 구성 방식에 대해 알아볼까? 구성 방식으로는 로드 밸런서의 구성 위치에 따라 2가지로 나눌 수 있다.
원암(One-Arm) 구성 인라인(Inline) 구성
이 구성 방식은 mermaid 코드로 각각의 구성에 대해 보여줌과 동시에 간단히 설명하고 넘어가는 것으로 하겠다.
먼저, 원암(One-Arm) 구성이다.
다수 플로우가 조잡하긴 하지만.. 원암 구성을 그래도 최대한 나타낸 구성도라 할 수 있겠다. 원암 구성은 로드 밸런서가 중간 스위치 옆에 연결되는 구성으로 즉, 로드밸런서를 경유하지 않아도 되는 트래픽의 경우, 다이렉트로 서버에 가도록. 로드밸런서르 경유해야 하는 트래픽의 경우, 로드밸런서를 통해서 로드밸런싱 되도록 하는 구성이라 할 수 있다. 이러한 원암 구성은 로드밸런서 부하 감소와 장애 영향도를 줄이기 위해 사용된다. 로드밸런서 장비에 장애가 발생하더라도, 로드밸런서를 거치지 않는 일반 서비스의 경우에는 지장이 없기 때문이다.
반면, 인라인 구성은 아래와 같은데 우리가 앞에서 늘상 말해온 그 모습을 띤다고 할 수 있겠다.
모든 트래픽으 로드밸런서를 통해 이루어지는 구조로, 구성이 직관적이고 이해하기 쉽다. 대신 로드밸런서 부하가 높아진다는 특징이 존재한다.
로드밸런스는 여기까지 정리하기로 한다. 동작 모드 등의 내용이 있고, 로드밸런싱이 이루어지는 과정에서 Destination ip와 source ip가 바뀌는 등의 내용이 나오는데 여기까지만 다루는 걸로..
이 포스팅은 우리가 알아야할 로드밸런서의 1퍼센트도 다루지 않았을 정도로 미약하기 때문에, 로드밸런서에 대해서는 다시 공부하여 추후에 다시 보강하여 정리하기로 한다.