로드밸런싱 - 안정성을 위한 기술

개요

가용성이란 안정성을 수치화한 것
안정성을 높이기 위한 방법에는?

• 이중화 & 다중화 : 물리적 장비나 프로그램을 여러 개 두는 것
• 로드 밸런싱 : 트래픽을 고르게 분산하는 기술 (로드=부하)

---

가용성 availability

“컴퓨터 시스템이 특정 기능을 실제로 수행할 수 있는 시간의 비율”

• 가용성 = 업타입 / 업타임 + 다운타임 (전체 사용 시간 중 정상적인 사용 시간)
• 업타임 : 정상적인 사용 시간
• 다운타임 : 정상적인 사용이 불가능한 시간

1) 고가용성 HA High Availability

• 일반적으로 안정적인 시스템은 가용성 99.999% 이상을 목표로 함
• 9의 개수로 파이브 나인스라 부르기도 함
• 90% 원 나인, 99% 투 나인스, 99.9% 쓰리 나인스, …

 늘 가동되고 있는 시스템이라 가정할 때, 1년간 다운타임은 세븐 나인스 기준 3.16초, 식스 나인스 31.56초, 파이브 나인스 5.26분, 포 나인스 52.56분으로 각각의 격차가 크고, 특히 절대 다운돼선 안되는 시스템인 경우 그 피해 차이가 심화됨!! 따라서 일반적으로 파이브 나인스 이상이라는 거지, 최대한 높여야 하는 것

---

 2) 가용성을 높이는 방법

“다운타임을 최소화하기”

• 서비스가 다운되는 이유는 과도한 트래픽, 예기치 못한 소프트웨어상의 오류, 하드웨어 장애, 보안 공격이나 자연재해 등등 굉장히 다양하다!!
• 인간의 힘으로 막기엔 한계가 있기 때문에, 문제를 원천 차단하는 예방적 방식 보다, 문제가 발생해도 계속 시스템이 기능할 수 있도록 설계하는 것이 중요!!

결함 감내 fault tolerance
시스템에 문제가 발생하더라도 계속 기능할 수 있도록 하는 능력

---

3) 결함 감내 방식 - 이중화 & 다중화

• 가장 기본적인 고가용성 설계 원칙, 예비(=backup)을 마련하기
• 다중화는 예비를 세개 이상 여러 개 마련하는 것
• 보통 문제가 발생할 경우 시스템 전체가 중단될 위험이 있는 대상이나 지점의 백업을 둔다!!

SPoF (Single Point of Failure)
단일 장애점
서버 컴퓨터, NIC, 스위치 등의 물리적 장비나 데이터베이스, 웹 서버 프로그램 등등
SPoF는 최소화시켜야함!! 그 넘의 예비를 둔다면 더 이상 단일이 아니니 SpoF가 아니게 되죠?!

이중화 구성 방법

액티브/스탠바이 Active / StandBy

• 한 시스템은 가동하고, 다른 시스템은 백업 용도로 대기
• 페일오버 failover : 액티브에 문제가 생길 시 곧바로 스탠바이가 액티브로 전환됨
• 평소에도 액티브에만 부하가 몰리기 때문에, 성능적인 개선은 기대하기 어려움

액티브/액티브 Active / Active

• 두 시스템 모두를 가동
• 평상 시 부하가 분산되기 때문에 성능적으로 우위에 있지만, 
• 한 쪽에 문제가 발생했을 시 나머지 한 쪽에 로드가 급격히 몰릴 수 있단 위험이 있음

티밍 teaming과 본딩 bonding
여러 NIC를 이중화 또는 다중화해서 하나의 인터페이스처럼 사용하는 기법들
티밍은 주로 Windows에서, 본딩은 주로 Linux에서 활용

---

로드 밸런싱 Load Balancing

• 고가용성을 요구하는 호스트는 일반적으로 서버!
• 서버를 다중화했다고 안정성이 보장된다는 말이 아님!!
• 서버가 백만 개 있다고 한들, 트래픽이 어느 하나로 몰리면 다중화의 의미가 없겠죠?!

1) 로드 밸런싱이란?

• 트래픽의 고른 분배를 위한 기술
• 로드 밸런서에 의해 수행됨
• 로드 밸런서는 특정 하드웨어를 지칭하기도 하고, 밸런싱을 수행하는  특정 소프트웨어를 지칭하기도 함

하드웨어

• 로드 밸런싱 전용 네트워크 장비
• L4 스위치 : Layer 4, 즉 전송계층까지의 정보(IP주소나 포트 번호 등)를 바탕으로 밸런싱하는 장치
• L7 스위치 : Layer 7, 응용계층의 정보(URI, HTTP 메세지, 쿠키 등)까지 활용해 밸런생하는 장치

소프트웨어 

• HAProxy, Envoy 등
• Nginx에도 로드 밸런싱 기능이 내포돼 있음
• HAProxy와 Nginx를 주로 쓰는 것 같다고 하심…?!

---

2) 로드 밸런서의 위치

• 서버와 클라이언트 사이에 위치!! 만약 소프트웨어 밸런서라면 그 소프트웨어가 설치된 호스트 기기가 위치하겄죠??
• 클라는 로드 밸런서에 요청을 보내고, 로드 밸런서는 요청들을 다중화된 각 서버에 적절히 분배

헬스 체크 Health Check

• 로드밸런서는 서버들의 건강 상태를 주기적으로 모니터링하고 체크
• HTTP, ICMP 등의 다양한 프로토콜을 활용해 체크 메세지를 주고 받음

하트비트 Heartbeat
서버끼리도 주기적으로  체크 메세지를 서로 주고받으며 상태를 상호 확인

---

3) 로드 밸런싱 알고리즘

부하를 적절히 배분하는 방법에는 굉장히 다양한 알고리즘이 존재하며,

로드 밸런서 장치나 시스템마다 알고리즘을 이해하는 방법도 다 다름, 그래도 대표적인 몇몇을 보자면!!

라운드 로빈 방식 Round Robin Method

단순히 차례대로 서버들을 번갈아가며 부하를 전달하는 방식

최소 연결 방식 Least Connection Method

현재 연결 수가 적은 서버에 우선적으로 전달하는 방식

IP 해시 방식 IP Hash Method

클라이언트 IP 주소 : 특정 서버 주소 형태로 해싱된 사용자의 IP를 기준으로 서버를 매핑해 부하를 전달

담당 직원을 배정하는 느낌!! 클라 A님은 서버 A가 요청을 받음

최소 응답시간 방식 Least Response Time Method

응답 시간이 가장 짧은 서버에게 부하를 전달

가중치가 부여된 알고리즘
서버 간 성능 차이에 따라 서버별 가중치를 배정해, 이를 바탕으로 부하를 전달
예를들어 서버 A의 성능이 5고, 서버 B의 성능이 1이면, 서버 A에 부하가 다섯 배 더 전달됨!!