NETWORKING, LOAD BALANCING, DEVOPS, L4, L7, SCALE IN, SCALE OUT

[Network] 네트워크 로드밸런싱: 이해와 실제 구현

Intro

안녕하세요 Noah입니다.

이번 포스트에서는 네트워크 로드밸런싱에 대해 알아보고, 실제 구현 방법에 대해서도 다루어 보겠습니다.
로드밸런싱은 서버의 트래픽을 균등하게 분산시켜 서비스의 가용성과 응답성을 높이는 기술입니다.

이 글을 통해 로드밸런싱의 기본적인 개념부터 실제 구현까지의 과정을 이해하실 수 있을 것입니다.

목차는 아래와 같습니다. ^^

본문

1. 네트워크 계층 소개

네트워크 통신에서 OSI 7계층 모델은 데이터의 흐름과 프로토콜을 이해하는 데 중요한 기준점을 제공합니다. L1부터 L7까지 각 계층은 고유의 기능을 수행하며, 이들의 상호작용을 통해 네트워크 통신이 이루어집니다.

[L1부터 L7계층까지 간단한 설명]

OSI(Open Systems Interconnection) 모델은 데이터 통신을 위한 7계층 프레임워크를 제공합니다. 각 계층은 특정 기능을 담당하며, 위 아래 계층과 상호작용합니다.

  1. L1, 물리 계층(Physical Layer): 데이터를 전기 신호로 변환하여 전송하는 역할을 합니다. 케이블, RJ45 커넥터, 허브 등이 이 계층에 속합니다.
  2. L2, 데이터 링크 계층(Data Link Layer): 물리적인 전송 오류를 감지하고 수정합니다. MAC 주소를 사용하여 통신하며, 스위치와 브리지가 이 계층에 속합니다.
  3. L3, 네트워크 계층(Network Layer): 다른 네트워크와의 통신을 담당하며, 라우팅을 통해 최적의 경로를 결정합니다. IP 주소를 사용하며, 라우터가 이 계층에 속합니다.
  4. L4, 전송 계층(Transport Layer): 종단 간의 신뢰성 있는 데이터 전송을 책임집니다. TCP와 UDP 프로토콜이 이 계층에 속합니다.
  5. L5, 세션 계층(Session Layer): 통신 세션을 관리하며, 데이터 교환을 위한 논리적 연결을 담당합니다.
  6. L6, 표현 계층(Presentation Layer): 데이터 형식을 변환하며, 암호화와 압축을 처리합니다.
  7. L7, 애플리케이션 계층(Application Layer): 최종 사용자와 직접적으로 상호작용하는 애플리케이션에 대한 인터페이스를 제공합니다. HTTP, FTP와 같은 프로토콜이 이 계층에 속합니다.



2. 로드밸런싱: L4 vs L7

로드밸런싱은 서버로 들어오는 트래픽을 여러 서버로 분산시키는 기술입니다. L4와 L7 로드밸런싱은 각각 전송 계층과 애플리케이션 계층에서 작동하며, 특성에 따라 다른 방식으로 트래픽을 처리합니다.

[Load Balancing: L4 vs L7]

  • 레이어 4(L4) 로드밸런싱: 전송 계층에서 작동합니다. IP 주소와 Port 번호를 기반으로 트래픽을 분산합니다. 연결 설정 및 종료, 패킷 전달 결정을 담당하며, 세션 계층 정보나 애플리케이션 계층 데이터를 볼 수 없습니다.
  • 레이어 7(L7) 로드밸런싱: 애플리케이션 계층에서 작동합니다. HTTP 헤더, 쿠키, 요청 URI 등 애플리케이션 데이터를 분석하여 트래픽을 분산합니다. L7 로드밸런싱은 트래픽을 더 세밀하게 제어할 수 있으며, 사용자의 요청을 특정 웹 애플리케이션 서비스에 분산시키는 등 복잡한 라우팅 결정을 할 수 있습니다.



3. Scale Out과 트래픽 분산

애플리케이션 계층에서의 Scale Out은 서버의 수를 증가시켜 처리 능력을 확장하는 것을 의미합니다.
로드밸런서는 들어오는 요청을 여러 서버에 분산하여 각 서버가 고르게 트래픽을 처리할 수 있도록 합니다.
애플리케이션 계층의 로드밸런싱을 사용하면, 사용자의 세션 정보나 특정 요청을 처리하는 데 최적화된 서버에 요청을 보낼 수 있습니다.
loadbalancing.webp

[트래픽을 분산하는 대표적인 기준]

1. 라운드 로빈(Round Robin): 서버 목록을 순서대로 돌아가며 트래픽을 분산합니다.

즉, 첫 번째 들어온 요청은 첫 번째 서버로, 두 번째 요청은 두 번째 서버로, 그리고 이런 식으로 모든 서버에 동일한 순서로 요청을 할당한 후, 마지막 서버에 요청을 할당한 다음에는 다시 첫 번째 서버로 돌아가 요청을 분산시킵니다.

특징
  • 단순성과 공정성: 모든 서버가 요청을 공평하게 처리할 기회를 얻습니다. 설정이 간단하며, 서버 간에 균등한 부하 분산을 목표로 합니다.
  • 자동 확장성: 새로운 서버가 풀(pool)에 추가되면, 라운드 로빈 알고리즘은 자동으로 새 서버를 요청 분산 로직에 포함시킵니다.
  • 상태 비저장(Stateless): 이 방식은 각 요청이 독립적으로 처리되며, 특정 사용자의 세션 상태를 기억하지 않습니다. 따라서 세션 정보나 사용자 특성에 따른 분산은 고려되지 않습니다.
  • 사용 사례: 모든 서버가 유사한 스펙을 가지고 있고, 세션 유지가 중요하지 않은 경우에 효과적입니다. 예를 들어, 상태를 저장하지 않는 RESTful API 서버 그룹에서 유용하게 사용됩니다.
  • 한계: 서버 간의 처리 능력이나 현재 부하가 고르지 않은 경우, 라운드 로빈 방식은 비효율적일 수 있습니다. 예를 들어, 하나의 서버가 다른 서버보다 처리 능력이 떨어지는 경우에도 동일한 수의 요청을 받게 되어 전체적인 응답 시간이 늘어날 수 있습니다. 또한, 세션 지속성이 필요한 어플리케이션에는 적합하지 않습니다. 하지만 라운드 로빈은 다른 로드밸런싱 알고리즘(예: 가중 라운드 로빈, 최소 연결, 최소 응답 시간 등)과 결합하거나, 특정 요구 사항에 따라 조정되어 사용될 수 있습니다. 이렇게 하여 서버의 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.
2. 가중 라운드 로빈(Weighted Round Robin): 서버에 가중치를 부여하여 트래픽을 분산합니다.

서버에 가중치를 부여하여, 서버의 처리 능력에 따라 트래픽을 분산합니다. 가중치가 높은 서버에는 더 많은 요청을 할당하고, 가중치가 낮은 서버에는 적은 요청을 할당합니다.

특징
  • 가중치 부여: 서버의 처리 능력이나 성능 차이를 고려하여, 각 서버에 가중치를 부여합니다. 가중치가 높은 서버에는 더 많은 요청을 할당하고, 가중치가 낮은 서버에는 적은 요청을 할당합니다.
  • 효율성: 서버 간의 처리 능력이나 현재 부하를 고려하여, 트래픽을 더 효율적으로 분산할 수 있습니다. 가중치가 높은 서버에는 더 많은 요청을 할당하여, 전체적인 응답 시간을 최적화할 수 있습니다.
  • 사용 사례: 서버 간의 처리 능력이나 성능 차이가 큰 경우, 가중 라운드 로빈 방식은 효과적입니다. 예를 들어, 서버의 스펙이 다르거나, 현재 부하가 고르지 않은 경우에 사용됩니다. 또한, 세션 지속성이 필요한 어플리케이션에도 적합합니다.
  • 한계: 가중 라운드 로빈은 서버의 가중치를 미리 설정해야 하므로, 서버의 처리 능력이나 성능 차이를 정확하게 파악해야 합니다. 가중치 설정이 잘못되면, 트래픽이 고르게 분산되지 않거나, 특정 서버에 부하가 집중될 수 있습니다. 따라서, 가중 라운드 로빈을 사용할 때는 서버의 가중치를 정확하게 설정하고, 주기적으로 모니터링하여 조정해야 합니다. 이렇게 하여 서버의 처리 능력이나 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.
3. 최소 연결(Least Connections): 현재 연결 수가 가장 적은 서버에 트래픽을 분산합니다.

현재 연결 수가 가장 적은 서버에 트래픽을 할당하여, 부하가 가장 적은 서버에 요청을 보냅니다. 이 방식은 서버의 현재 부하를 고려하여, 트래픽을 가장 효율적으로 분산할 수 있습니다.

특징
  • 현재 연결 수: 서버의 현재 연결 수를 기준으로, 가장 부하가 적은 서버에 트래픽을 분산합니다. 이 방식은 서버의 현재 부하를 고려하여, 트래픽을 가장 효율적으로 분산할 수 있습니다.
  • 효율성: 서버의 현재 부하를 고려하여, 트래픽을 가장 효율적으로 분산할 수 있습니다. 현재 연결 수가 가장 적은 서버에 트래픽을 할당하여, 전체적인 응답 시간을 최적화할 수 있습니다.
  • 사용 사례: 서버의 현재 부하를 고려하여, 트래픽을 가장 효율적으로 분산하고 싶은 경우에 사용됩니다. 예를 들어, 서버의 현재 연결 수가 다른 서버보다 적은 경우, 최소 연결 방식은 효과적입니다. 또한, 세션 지속성이 필요한 어플리케이션에도 적합합니다.
  • 한계: 최소 연결 방식은 서버의 현재 연결 수를 기준으로 트래픽을 분산하므로, 서버의 처리 능력이나 성능 차이를 고려하지 않습니다. 따라서, 서버의 현재 연결 수가 다른 서버보다 적더라도, 처리 능력이나 성능 차이가 큰 경우에는 효과적이지 않을 수 있습니다. 또한, 세션 지속성이 필요한 어플리케이션에는 적합하지 않습니다. 하지만 최소 연결은 다른 로드밸런싱 알고리즘(예: 라운드 로빈, 가중 라운드 로빈, 최소 응답 시간 등)과 결합하거나, 특정 요구 사항에 따라 조정되어 사용될 수 있습니다. 이렇게 하여 서버의 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.
4. 최소 응답 시간(Least Response Time): 가장 빠른 응답 시간을 가진 서버에 트래픽을 분산합니다.

가장 빠른 응답 시간을 가진 서버에 트래픽을 할당하여, 가장 빠른 서버에 요청을 보냅니다. 이 방식은 서버의 응답 시간을 기준으로, 트래픽을 가장 효율적으로 분산할 수 있습니다.

특징
  • 응답 시간: 서버의 응답 시간을 기준으로, 가장 빠른 서버에 트래픽을 분산합니다. 이 방식은 서버의 응답 시간을 기준으로, 트래픽을 가장 효율적으로 분산할 수 있습니다.
  • 효율성: 서버의 응답 시간을 기준으로, 트래픽을 가장 효율적으로 분산할 수 있습니다. 가장 빠른 응답 시간을 가진 서버에 트래픽을 할당하여, 전체적인 응답 시간을 최적화할 수 있습니다.
  • 사용 사례: 서버의 응답 시간을 기준으로, 트래픽을 가장 효율적으로 분산하고 싶은 경우에 사용됩니다. 예를 들어, 서버의 응답 시간이 다른 서버보다 빠른 경우, 최소 응답 시간 방식은 효과적입니다. 또한, 세션 지속성이 필요한 어플리케이션에도 적합합니다.
  • 한계: 최소 응답 시간 방식은 서버의 응답 시간을 기준으로 트래픽을 분산하므로, 서버의 처리 능력이나 성능 차이를 고려하지 않습니다. 따라서, 서버의 응답 시간이 다른 서버보다 빠르더라도, 처리 능력이나 성능 차이가 큰 경우에는 효과적이지 않을 수 있습니다. 또한, 세션 지속성이 필요한 어플리케이션에는 적합하지 않습니다. 하지만 최소 응답 시간은 다른 로드밸런싱 알고리즘(예: 라운드 로빈, 가중 라운드 로빈, 최소 연결 등)과 결합하거나, 특정 요구 사항에 따라 조정되어 사용될 수 있습니다. 이렇게 하여 서버의 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.
5. IP 해시(IP Hash): 클라이언트의 IP 주소를 해시하여 트래픽을 분산합니다.

클라이언트의 IP 주소를 해시하여, 동일한 클라이언트는 항상 동일한 서버로 요청을 보냅니다. 이 방식은 클라이언트의 IP 주소를 기준으로, 트래픽을 분산할 수 있습니다.

특징
  • IP 주소 해시: 클라이언트의 IP 주소를 해시하여, 동일한 클라이언트는 항상 동일한 서버로 요청을 보냅니다. 이 방식은 클라이언트의 IP 주소를 기준으로, 트래픽을 분산할 수 있습니다.
  • 세션 지속성: 동일한 클라이언트가 항상 동일한 서버로 요청을 보내므로, 세션 정보를 유지할 수 있습니다. 이 방식은 세션 지속성이 필요한 어플리케이션에 적합합니다.
  • 사용 사례: 동일한 클라이언트가 항상 동일한 서버로 요청을 보내야 하는 경우에 사용됩니다. 예를 들어, 세션 정보를 유지해야 하는 웹 애플리케이션에서 유용하게 사용됩니다.
  • 한계: IP 해시 방식은 클라이언트의 IP 주소를 기준으로 트래픽을 분산하므로, 서버의 처리 능력이나 성능 차이를 고려하지 않습니다. 따라서, 서버의 처리 능력이나 성능 차이가 큰 경우에는 효과적이지 않을 수 있습니다. 또한, 세션 지속성이 필요하지 않은 어플리케이션에는 적합하지 않습니다. 하지만 IP 해시는 다른 로드밸런싱 알고리즘(예: 라운드 로빈, 가중 라운드 로빈, 최소 연결, 최소 응답 시간 등)과 결합하거나, 특정 요구 사항에 따라 조정되어 사용될 수 있습니다. 이렇게 하여 서버의 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.
6. URL 해시(URL Hash): 클라이언트의 URL을 해시하여 트래픽을 분산합니다.

클라이언트의 URL을 해시하여, 동일한 URL 요청은 항상 동일한 서버로 요청을 보냅니다. 이 방식은 클라이언트의 URL을 기준으로, 트래픽을 분산할 수 있습니다.

특징
  • URL 해시: 클라이언트의 URL을 해시하여, 동일한 URL 요청은 항상 동일한 서버로 요청을 보냅니다. 이 방식은 클라이언트의 URL을 기준으로, 트래픽을 분산할 수 있습니다.
  • 세션 지속성: 동일한 URL 요청은 항상 동일한 서버로 요청을 보내므로, 세션 정보를 유지할 수 있습니다. 이 방식은 세션 지속성이 필요한 어플리케이션에 적합합니다.
  • 사용 사례: 동일한 URL 요청은 항상 동일한 서버로 요청을 보내야 하는 경우에 사용됩니다. 예를 들어, 세션 정보를 유지해야 하는 웹 애플리케이션에서 유용하게 사용됩니다.
  • 한계: URL 해시 방식은 클라이언트의 URL을 기준으로 트래픽을 분산하므로, 서버의 처리 능력이나 성능 차이를 고려하지 않습니다. 따라서, 서버의 처리 능력이나 성능 차이가 큰 경우에는 효과적이지 않을 수 있습니다. 또한, 세션 지속성이 필요하지 않은 어플리케이션에는 적합하지 않습니다. 하지만 URL 해시는 다른 로드밸런싱 알고리즘(예: 라운드 로빈, 가중 라운드 로빈, 최소 연결, 최소 응답 시간 등)과 결합하거나, 특정 요구 사항에 따라 조정되어 사용될 수 있습니다. 이렇게 하여 서버의 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.
7. 가중 응답 시간(Weighted Response Time): 서버의 응답 시간에 가중치를 부여하여 트래픽을 분산합니다.

서버의 응답 시간에 가중치를 부여하여, 응답 시간이 빠른 서버에 더 많은 트래픽을 할당합니다. 이 방식은 서버의 응답 시간을 기준으로, 트래픽을 분산할 수 있습니다.

특징
  • 가중치 부여: 서버의 응답 시간에 가중치를 부여하여, 응답 시간이 빠른 서버에 더 많은 트래픽을 할당합니다. 이 방식은 서버의 응답 시간을 기준으로, 트래픽을 분산할 수 있습니다.
  • 효율성: 서버의 응답 시간을 기준으로, 트래픽을 가장 효율적으로 분산할 수 있습니다. 응답 시간이 빠른 서버에 더 많은 트래픽을 할당하여, 전체적인 응답 시간을 최적화할 수 있습니다.
  • 사용 사례: 서버의 응답 시간을 기준으로, 트래픽을 가장 효율적으로 분산하고 싶은 경우에 사용됩니다. 예를 들어, 서버의 응답 시간이 다른 서버보다 빠른 경우, 가중 응답 시간 방식은 효과적입니다. 또한, 세션 지속성이 필요한 어플리케이션에도 적합합니다.
  • 한계: 가중 응답 시간 방식은 서버의 응답 시간을 기준으로 트래픽을 분산하므로, 서버의 처리 능력이나 성능 차이를 고려하지 않습니다. 따라서, 서버의 응답 시간이 다른 서버보다 빠르더라도, 처리 능력이나 성능 차이가 큰 경우에는 효과적이지 않을 수 있습니다. 또한, 세션 지속성이 필요하지 않은 어플리케이션에는 적합하지 않습니다. 하지만 가중 응답 시간은 다른 로드밸런싱 알고리즘(예: 라운드 로빈, 가중 라운드 로빈, 최소 연결, 최소 응답 시간 등)과 결합하거나, 특정 요구 사항에 따라 조정되어 사용될 수 있습니다. 이렇게 하여 서버의 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.
8. 자원 기반(Resource Based): 서버의 자원 사용량을 기준으로 트래픽을 분산합니다.

서버의 CPU, 메모리, 디스크 사용량 등 자원 사용량을 기준으로, 트래픽을 가장 효율적으로 분산할 수 있습니다. 이 방식은 서버의 자원 사용량을 기준으로, 트래픽을 분산할 수 있습니다.

특징
  • 자원 사용량: 서버의 CPU, 메모리, 디스크 사용량 등 자원 사용량을 기준으로, 트래픽을 분산합니다. 이 방식은 서버의 자원 사용량을 기준으로, 트래픽을 가장 효율적으로 분산할 수 있습니다.
  • 효율성: 서버의 자원 사용량을 기준으로, 트래픽을 가장 효율적으로 분산할 수 있습니다. 자원 사용량이 낮은 서버에 트래픽을 할당하여, 전체적인 응답 시간을 최적화할 수 있습니다.
  • 사용 사례: 서버의 자원 사용량을 기준으로, 트래픽을 가장 효율적으로 분산하고 싶은 경우에 사용됩니다. 예를 들어, 서버의 자원 사용량이 다른 서버보다 낮은 경우, 자원 기반 방식은 효과적입니다. 또한, 세션 지속성이 필요한 어플리케이션에도 적합합니다.
  • 한계: 자원 기반 방식은 서버의 자원 사용량을 기준으로 트래픽을 분산하므로, 서버의 처리 능력이나 성능 차이를 고려하지 않습니다. 따라서, 서버의 자원 사용량이 다른 서버보다 낮더라도, 처리 능력이나 성능 차이가 큰 경우에는 효과적이지 않을 수 있습니다. 또한, 세션 지속성이 필요하지 않은 어플리케이션에는 적합하지 않습니다. 하지만 자원 기반은 다른 로드밸런싱 알고리즘(예: 라운드 로빈, 가중 라운드 로빈, 최소 연결, 최소 응답 시간 등)과 결합하거나, 특정 요구 사항에 따라 조정되어 사용될 수 있습니다. 이렇게 하여 서버의 성능 차이를 고려하거나, 트래픽의 특성에 맞는 더 정교한 로드밸런싱 전략을 구현할 수 있습니다.



4. Scale In 시 발생할 수 있는 문제점

가동 중인 서버를 축소(Scale In)할 때 발생할 수 있는 문제점에는 서비스 중단, 부하 증가, 데이터 일관성 문제 등이 있습니다.





5. 문제 해결 방법

이러한 문제점을 해결하기 위한 방법으로는 점진적 축소, 세션 지속성 보장, 로드밸런싱 조정 등이 있습니다. 각 방법은 서비스의 중단 없이 서버를 안전하게 축소할 수 있게 도와줍니다.

[Scale In 방법]

1. 점진적 축소(Gradual Scale In): 서버를 점진적으로 축소하여 서비스 중단을 최소화합니다.

서버를 점진적으로 축소하여, 서비스 중단을 최소화합니다. 서버를 하나씩 제거하거나, 서버의 가중치를 낮추어 점진적으로 트래픽을 줄입니다. 이 방식은 서비스 중단을 최소화하고, 안정적으로 서버를 축소할 수 있습니다.

2. 세션 지속성 보장(Session Persistence): 세션 정보를 유지하여 서버를 안전하게 축소합니다.

세션 정보를 유지하여, 서버를 안전하게 축소합니다. 세션 정보를 다른 서버로 이전하거나, 세션 정보를 저장하는 별도의 서버를 사용하여, 서버를 안전하게 축소할 수 있습니다. 이 방식은 서버의 세션 정보를 보존하고, 안정적으로 서버를 축소할 수 있습니다.

3. 로드밸런싱 조정(Load Balancer Adjustment): 로드밸런서 설정을 조정하여 서버를 안전하게 축소합니다.

로드밸런서 설정을 조정하여, 서버를 안전하게 축소합니다. 로드밸런서의 가중치를 조정하거나, 서버 그룹에서 제외하여, 서버를 안전하게 축소할 수 있습니다. 이 방식은 로드밸런서를 통해 서버를 안전하게 축소할 수 있습니다.



글을 마치며

네트워크 로드밸런싱은 서버의 가용성과 안정성을 유지하는 데 있어 필수적인 기술입니다. 이번 포스트를 통해 로드밸런싱의 기본 개념과 구현 방법에 대해 알아보았습니다.

로드밸런싱은 단순히 트래픽을 분산시키는 것뿐만 아니라, 서비스의 품질을 결정짓는 중요한 요소입니다. 따라서 효과적인 로드밸런싱 전략은 모든 개발자와 시스템 관리자가 갖추어야 할 중요한 역량 중 하나입니다.

앞으로도 개발과 관련된 대한 다양한 주제로 여러분과 지식을 공유할 예정이니, 관심 있으신 분들은 자주 방문해 주세요. 궁금한 점이나 추가적으로 알고 싶은 내용이 있으면 언제든지 댓글로 질문해주세요.

이 글이 여러분의 프로젝트에 도움이 되길 바라며, 글을 마치겠습니다. 건승하세요! ^^