서버를 구축해보자 1 - 로드밸런서

이번에 첫 실무 프로젝트를 하게 되었는데,

서비스 구성을 위한 서버 기술/장비를 조사해야 될 필요가 생겼다.

그런데 본인은 네트워크고 서버고 아----무것도 모른단 말임?? 저는 게임 개발자인데요?

근데 뭐 해야되면 해야지. 그래서 급하게 공부 시작.

 

대략적으로 공부해야될 키워드는

1. 로드밸런서
2. 프록시(포워드/리버스)
3. NginX
4. OpenVidu
5. SFU(Selective forwarding Unit)
6. MCU(Multipoint Control Unit)
7. HTTPS 종결
8. Signaling

하나씩 차근차근 공부해 보자.

---

로드밸런서 (Load Balancer)

백엔드 지식이 전무해서, 간단하게 그냥 클라이언트 <-> 단일 서버로 직접 연결시켜 버리면 되지 않나 싶었는데 그렇지 않은 듯하다.

 

위와 같이 무식하게 서버를 구축한다면 문제점은 크게 세 가지다.

첫 번째는 서버의 자원을 늘릴 때의 문제,

두 번째는 각 서버의 역할이 달라 적절하게 로드를 분산시켜야 할 때의 문제

세 번째는 단일 서버 사용으로 인한 단일 장애점 문제

이렇게 세 가지 문제점이 존재한다.

 

서버 자원을 늘릴때의 문제를 먼저 생각해 보자.

처음부터 서버가 가진 자원이 많다면 위와 같은 방식으로도 충분히 문제없지 않느냐~ 싶지만, 얼마나 규모가 늘어날지 예측도 안될뿐더러 시작부터 큰 규모의 자원을 가진 서버를 구축하는 것도 현실적으로 어렵다. 그래서 지금 개발하는 서비스의 시작 단계에서는 우선 최소한의 자원을 가진 서버를 이용해서 서비스를 제공하고, 추후 서비스가 활성화돼서 이용자가 늘어나게 된다면 그때 가서 서버를 증설하는 방향으로 프로젝트를 진행한다.

 

아무튼 핵심은 서버를 증설하던, 성능을 확장하던 서비스 규모가 커짐에 따라 더 많은 트래픽을 처리할 수 있게 해줘야 한다는 점이다. 이때, 서버 성능을 확장하는 방법을 Scale up, 서버를 증설하는 하는 방법을 Scale out이라 한다. 쉽게 설명하자면 1TB 서버를 가지고 있는 상태에서 해당 서버를 2TB로 만든다면 Scale up, 1TB 서버를 추가한다면 Scale out이다.

 

Scale up의 경우 관리나 운영 측면에서 변하는 것이 없기 때문에 내 입장에서는 편하긴 하나, 성능이 증가할수록 비용의 증가 폭이 너무 크고 비용 부담도 크고, 계속해서 확장하다 보면 결국엔 한계에 도달하게 된다. 거기다 단일 서버의 경우 하나의 서버에 모든 부하가 집중되기 때문에 SPoF(단일장애지점)이 될 수도 있다.

 

그래서 우리는 Scale out 방식으로 접근한다.

늘어난 트래픽만큼 추가적으로 서버를 증설하기만 되니, 구매 및 유지에 대한 비용은 선형적으로 증가한다. 다만 서버가 늘어날수록 관리하기 어렵고(관리 편의성 하락), 서버의 운영에 들어가는 비용(이는 금전적 비용이 아닌 인적 자원 소모를 이야기하는 듯하다)도 증가한다. 토스에서 서버를 구축하는 것을 살펴보니 서버를 업데이트한다거나 장애가 발생하면 2개의 데이터 센터 중 하나로 트래픽을 몰아버리는 것 같았다. 이런 식으로 다중 서버를 사용하는 방법은 하나의 서버나 데이터 센터가 마비되더라도 서비스 제공 자체에는 문제가 없도록 할 수 있다.

 

약간 핵심에서 벗어나 빙빙 도는 것 같지만, 여기까지 백그라운드였고 이제부터 본론이다.

우리는 Scale out 방식으로 서버 자원을 늘릴 계획이라 이야기했었다. Scale out 문제가 아니더라도, 미디어 서버나 시그널링 서버 등의 여러 서버를 이용할 필요가 존재하기도 하고. 어쨌든 간에 우리 서비스의 아키텍처에는 단일 서버가 아닌 다중 서버가 필요하다는 게 핵심이다. 이때, 여러 서버를 사용해서 트래픽을 나눠주기 위해서는 로드밸런서(Load balancer)라는 게 필요하다.

 

로드밸런서라는 것 자체가 어떤 특정 기술이나 하드웨어를 말하는 줄 알았는데, 그런 것이 아니라 서버에 가해지는 부하(로드)를 분산(밸런싱)해주는 장치 또는 기술의 총칭이 바로 로드밸런서였다.

 

로드밸런서는 클라이언트와 서버 그룹 사이에 위치하면서 각 트래픽을 적절하게 각 서버에 분배해 주는 역할을 수행한다. 이때, 클라이언트의 요청을 특정 서버로 분배하는 기법을 로드밸런싱 알고리즘이라 하는데, 이에 대해서는 본 포스팅에서는 다루지 않을 생각이다(지금 단계에서는 필요하지 않다고 여겨짐).^[각주:1]

 

로드밸런서는 OSI 7 계층 중 어떤 단계에서 로드밸런싱 기법을 적용하느냐에 따라 L4 로드밸런서와 L7 로드밸런서로 나누어진다.^[각주:2] 각각에 대해서 쉽게 설명하면 L4 로드밸런서는 Transport Layer에서 동작하고, L7 로드밸런서는 Application Layer에서 동작한다. L4 로드밸런서는 IP, IPX나 TCP, UDP 정보를 바탕으로 로드밸런싱을 수행한다. L7 로드밸런서는 HTTP 헤더, 쿠키 등의 사용자 요청을 기준으로 로드밸런싱을 수행할 수 있다.^[각주:3]

 

지금 설계하는 서비스의 경우 각 기관별로, 유형별로, 용도별로 서로 다른 서버와 연결시켜주어야 하기 때문에 복잡한 로직을 수행할 수 있는 L7 로드밸런서를 사용하는 것이 알맞다고 생각된다. 그런데 로드밸런서로 그런 게 가능한가? 잘 모르겠다. 선배의 말로는 충분히 가능하긴 하다는 것 같은데, 선배도 잘 모르신단다! 흠... 리버스 프록시에 대해 알아야 좀 더 확실한 결론을 얻을 수 있을 듯하다.

 

이 글을 작성하며 참고한 포스팅

로드밸런서(Load Balancer)의 개념과 특징

 

로드밸런서(Load Balancer)란? : AWS와 로드 밸런싱(Load Balancing) 개념 정리

 

로드 밸런서(Load Balancer)란?

---

 

 

1. 로드밸런싱 알고리즘은 정적 로드밸런싱 알고리즘인 라운드로빈, 가중 라운드로빈, IP 해시와 동적 로드밸런싱 알고리즘인 최소 연결, 최소 리스폰이 존재한다. [본문으로]
2. 일반적으로 L4, L7 로드밸런서를 사용하는 것이지, 다른 계층에서의 로드밸런서를 사용하는 것도 가능은 한 것 같다. 하지만 정확히 모름. [본문으로]
3. 조금 더 파고들자면, 더 높은 계층의 로드밸런서를 쓸수록 더 정교한 로드밸런싱이 가능하고, 더 낮은 계층의 로드밸런서를 사용할수록 더 빠르고 효율 높은 로드밸런싱이 가능하다는 듯 하다. [본문으로]