[네트워크 network] 로드 밸런서(load balancer) 란?

제가 현재 일하고 있는 Canverse의 도메인은 canverse.org 입니다.

모바일 브라우저(사파리 기준)에서 앞에 http를 붙이면 안 되고, https를 붙여야만 접속이 가능한 이슈가 계속 있어왔고, 최근 수정을 요청받았습니다.

그래서 단순하게 토이 프로젝트에 적용했던 방식을 적용하려고 했었는데요, 그 방식은 다음과 같습니다.

 

사용 스택 : EC2 + NGINX

 

1. Nginx에서 https를 설정한 후, 개인키 csr키를 생성합니다.
2. Letsencrypt를 사용해서 ssl 인증서를 발급합니다.
3. ssl 인증서와 키를 추가해서 Nginx 서버 블록을 구성합니다
4. Nginx 설정 파일 (/etc/nginx/sites-available 폴더에서 default 파일)에서 서버 블록을 아래와 같이 수정해줍니다.
   

   server {
   	listen 80 default_server;
       listen [::]:80 default_server;
       server_name test.com www.test.com
       return 301 https://$server_name$request_uri;
   }

위 코드를 살펴보면

server : 코드가 작성되는 블록의 이름입니다.

listen 80 default_server : 포트번호 80은 http 포트이고, default_server는 서버 호스트 이름입니다.

listen [::]:80 default_server : 위와 동일하지만, 모든 IPv6 HTTP 트래픽에 대해 작동합니다.

return 301 https://$server_name$request_uri : 301 code는 트래픽을 리다이렉션 하는 데 사용됩니다.

 

위와 같은 과정을 통해서 하면 test.com 이나 www.test.com  으로 접속해도 https를 앞에 붙여서 리다이렉션 해주기 때문에 해결이 될 것이라고 생각했습니다.

 

하지만!!!

여태껏 위와 같은 방식을 사용하지 않았던 이유가 당연히 존재했었습니다. 제 질문에 대한 사수님(JH님)의 답변은 다음과 같았습니다.

nginx를 사용해서 그렇게도 할 수 있어요.
다만 그렇게 nginx를 사용해서 80 -> 443 redirect를 하는 방식은 서버가 하나 있다는 걸 가정한 거라서 서버가 여러 개 있을 때 (트래픽 감당이라던가, 하나가 다운됐을 때 다른 서버들이 있어서 사이트는 다운되지 않는다던가) 에는 적용하기 힘들죠. 
지금 서버 구조는 로드밸런서가 요청을 받고 클라우드에 다른 서버로 나눠주는 방식인데 (아직은 편의상 서버 하나만 사용 중), 이렇게 하는 경우 로드밸런서에서는 https 요청을 받고 로드밸런서 <->서버는 http로 통신을 해요. (https로 해도 상관없는데 어차피 이 구간은 VPC라서 http도 상관없음)
좀 더 구체적으로는 로드밸런서의 443 포트 (https)로 오는 요청을 서버의 3000 (frontend)이나 3001 (backend) 포트로 전달하는 방식이죠

 

 

아!! 답변을 듣고 80프로 정도 이해가 갔습니다.

그럼 20프로는 왜 이해가 안 갔냐? 그 이유는 로드밸런서에 대해 정확히 알고 있지 못하다.라는 결론이 나왔습니다.

이번 게시물에서 로드밸런서가 뭔지 정리하면서 짚고 넘어가려고 합니다.

 

그래서, 로드밸런서란?

 

Server는 클라이언트가 원하는 결과를 응답해 주는 역할을 합니다.

하지만 클라이언트가 수천만 명이면? 결과를 응답해 주다가 지쳐버리게 되고, 동작을 멈추게 됩니다.

 

문제를 해결하는 방법은 아래 두 가지가 있습니다.

scale-up : Server가 더 빠르게 동작하기 위해 하드웨어 성능을 올리는 방법
scale-out : 하나의 Server가 아닌 여러 대의 Server가 나눠서 일을 하는 방법

 

로드밸런싱은 scale-out을 적용해서 하나의 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 서버의 로드율 증가, 부하량, 속도 저하 등을 고려해서 적절히 분산 처리하여 해결하는 서비스입니다.

 

주요 기능으로는 

• NAT
  • 사설 IP 주소를 공인 IP 주소로 바꾸는 데 사용하는 통신망의 주소 변환기입니다.
• Tunneling
  • 인터넷상에 보이지 않는 통로를 만들어서 통신할 수 있게 하는 개념입니다.
  • 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별한 후, 캡슐화를 해제할 수 있게 합니다.
• DSR(Direct Server Return) 
  • 로드 밸런서 사용 시 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념입니다.
    DSR의 구성 예는 아래와 같습니다.
    

    

 

그럼 로드밸런서 종류에는 어떤 것들이 있을까요?

(이번에 정리하면서 알았습니다. AWS EC2를 사용할 때 L2, L3, L4 가 뭔지를.. 뭔지도 모르고 쓰지는 않아야겠네요..)

 

• L2
  
  • Mac 주소를 바탕으로 Load Balancing 합니다.
• L3
  
  • IP 주소를 바탕으로 Load Balancing 합니다.
• L4
  • Transport Layer(IP와 Port) 레벨에서 Load Balancing 합니다.
  • TCP, UDP
• L7
  • Application Layer(사용자 request) 레벨에서 Load Balancing 합니다.
  • HTTP, HTTPS, FTP

가장 많이 활용되는 로드밸런서로는 L4, L7이 있습니다.

한 대의 서버에 각기 다른 포트번호를 부여해서 다수의 서버 프로그램을 운영하는 경우에는 최소 L4 이상을 사용해야만 합니다.

L4와 L7을 한눈에 비교해보면 아래와 같습니다.

 

그럼, 로드밸런서는 어떤 기준으로 Server를 선택할까요?

 

• Round Robin
  • 단순히 Round Robin으로 분산하는 방식입니다. Round Robin은 간단하게 살펴보면, 컴퓨터 자원을 사용할 수 있는 기회를 프로그램 프로세스들에게 공정하게 부여하는 방법으로, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간 단위로 CPU를 할당하는 방식의 알고리즘입니다.
• Least Connections
  • 연결 개수가 가장 적은 서버를 선택하는 방식입니다.
  • 트래픽으로 인해 세션이 길어지는 경우, 이 방식이 효과적입니다.
• Source
  • 사용자의 IP를 Hashing 하여 분배하는 방식입니다.
  • 사용자는 항상 같은 서버로 연결되도록 보장받을 수 있습니다.

 

 

Reference

• https://nesoy.github.io/articles/2018-06/Load-Balancer   
• https://post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903