애플리케이션 로드밸런서 풀로 작업하기

IBM Cloud® Application Load Balancer for VPC (ALB) 풀은 로드 밸런서로부터 들어오는 트래픽을 수신하고 나가는 트래픽 응답을 제공하는 백엔드 대상들의 그룹입니다. 이 풀에는 프로토콜, 부하 분산 알고리즘, 백엔드 대상(VPC 인스턴스), 백엔드 대상에 대한 상태 점검, 세션 고정 기능이 포함되어 있습니다.

로드 밸런서 구성에서 리스너는 상위 리소스로 간주됩니다. 풀을 직접 또는 간접적으로 참조하는 두 가지 방법으로 해당 리스너와 연결할 수 있습니다. 직접 연결하려면 풀을 리스너의 default_pool 로 구성합니다. 간접 연결의 경우 failsafe_policy.target 관계를 통해 다른 풀에서 풀을 참조하여 다른 풀이 이미 리스너에 연결되어 있는지 확인합니다.

다음 조건은 모든 애플리케이션 부하 분산 장치 풀에 적용됩니다:

• 보조 풀이 ‘ failsafe_policy.target ’로 구성된 경우, 하나의 리스너에 여러 풀을 연결할 수 있습니다.
• 중복 풀 할당은 허용되지 않으며, 각 풀은 리스너별로 고유해야 합니다.
• 이 기능은 Application 제품군 로드밸런서에서만 사용할 수 있습니다.
• failsafe_policy.target 를 사용할 때는, protocol 가 기본 풀 프로토콜과 일치하거나 허용된 호환 프로토콜을 사용해야 합니다. 현재 http 및 https 만이 호환되는 것으로 간주됩니다.

애플리케이션 부하 분산 장치를 만들 때 또는 나중에 다음 절차에 따라 풀을 구성할 수 있습니다:

1. 브라우저에서 IBM Cloud 콘솔을 열고 계정에 로그인하세요.

2. 탐색 메뉴 선택한 다음 인프라 > 네트워크 > 로드 밸런서를 클릭합니다.

3. 수정하려는 애플리케이션 로드 밸런서를 클릭하십시오.

4. 애플리케이션 로드 밸런서의 세부 정보 페이지에서 [ 백엔드 풀 ] 탭을 클릭한 다음, 편집할 풀을 선택합니다.

5. 풀에 대해 다음 옵션을 구성하십시오:

   • 풀 이름: 풀의 이름입니다. 이상적으로는 이 풀에서 수행하는 기능에 대해 설명하는 이름입니다.
   • 프로토콜: 이 풀에서 인스턴스의 프로토콜을 선택하십시오. 풀의 프로토콜은 연관된 리스너의 프로토콜과 일치해야 합니다. 예를 들어, 리스너가 HTTP 을 사용하는 경우, 풀도 HTTP 을 사용해야 합니다. 마찬가지로, 리스너가 TCP 를 사용하는 경우, 풀 역시 TCP 를 사용해야 합니다.

   HTTP 는 가로챌 수 있고 안전하지 않은 것으로 간주되는 일반 텍스트로 데이터를 전송합니다. 프로토콜을 http 대신 https 으로 선택하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요: https://www.cloudflare.com/learning/ssl/why-is-http-not-secure/

   • 방법: 로드 밸런서가 풀에 속한 인스턴스들 간에 트래픽을 분산하는 방식을 선택합니다:
     • 라운드 로빈: 요청을 차례대로 각 인스턴스에 전달합니다. 모든 인스턴스가 대략 동일한 수의 클라이언트 연결을 수신합니다.
     • 가중치 라운드 로빈: 요청을 해당 가중치에 비례하여 각각의 인스턴스로 전달합니다. 예를 들면, 인스턴스 A, B, C가 있고 이들의 가중치는 60, 60 및 30(으)로 설정됩니다. 인스턴스 A 및 B는 동일한 수의 연결을 수신하고 인스턴스 C는 그 절반의 연결을 수신합니다.
     • 최소 연결: 현재 연결 수가 가장 적은 인스턴스에 요청을 전달합니다.
   • 세션 일관성: 특정 사용자의 세션 중에 모든 요청이 동일한 인스턴스에 전송되는지 선택하십시오.
   • 상태 검사: 로드 밸런서가 인스턴스 상태를 확인하는 방식을 구성합니다. 상태 확인 구성에 대한 자세한 내용은 상태 확인 작업을 참조하세요.

6. 건강 상태 점검에 대한 ‘요청 설정’(선택 사항) 을 선택하세요. 값을 지정하지 않으면 기본 상태 확인 설정이 적용됩니다. 사용할 수 있는 옵션은 다음과 같습니다.

   • 요청 메서드: GET 또는 POST 중 하나를 선택하십시오. 두 메서드 모두에 대해 요청 헤더를 사용자 정의할 수 있습니다. POST 메서드를 사용할 때, 선택적으로 요청 본문을 사용자 정의할 수 있습니다.
   • 요청 본문: 상태 확인에 사용할 ‘ HTTP ’ 요청 본문을 지정합니다. 값이 지정되지 않은 경우, 상태 확인 요청에는 요청 본문이 포함되지 않습니다.
   • 호스트 헤더: 요청이 HTTP/1.1 프로토콜을 사용하도록 보장하기 위해 호스트 헤더를 포함합니다. 그렇지 않은 경우, 시스템은 기본적으로 HTTP/1.0 을 사용합니다.
   • 다른 요청 헤더 추가: 하나 이상의 요청 헤더를 추가합니다.
     • 헤더 이름 : GET 요청 메서드의 경우, content-type, ` `accept, authorization, ` `cookie, origin, ` `referrer 또는 user-agent`` 중 하나를 선택하십시오. POST 요청 메서드의 경우, content-type, content-length, application-json 또는 accept-encoding 중 하나를 선택하십시오.
     • 값: 지정된 헤더 이름에 해당하는 값을 입력하십시오.

7. 건강 상태 점검에 대한 응답 설정(선택 사항)을 선택하십시오. 상태 검사 시 성공 응답 값을 사용자 정의합니다. 값을 지정하지 않으면 기본 상태 확인 설정이 적용됩니다. 사용할 수 있는 옵션은 다음과 같습니다.

   • 응답 본문: 응답 본문 내용을 입력하세요.
   • 응답 코드: 100 에서 599 사이의 값을 쉼표로 구분하여 여러 개 지정할 수 있습니다. 범위를 지정하려면 XX 을 사용하십시오. 예를 들어, 2XX 은 200-299 범위에 속하는 response와 일치합니다.

8. 기존 풀에 백업 풀을 추가하려면 백업 풀 구성( failsafe policy)을 설정하십시오. 로드 밸런서에 이미 다른 풀이 적어도 하나 이상 존재하는지 확인하십시오.

   • 조치: 기본 풀의 상태가 비정상적으로 변했을 때 수행할 조치. 로드 밸런서에서 백엔드 풀을 편집할 때, 다음의 ‘ failsafe policy ’ 작업 중 하나를 지정할 수 있습니다:
     • 전달: - 로드 밸런서는 요청을 지정된 백업 풀로 라우팅합니다. 이 작업은 다른 애플리케이션 서버 그룹으로의 원활한 장애 조치 경로를 제공합니다. 트래픽을 수신할 수 있도록 미리 구성되어 있고 준비된 백업 풀이 있어야 합니다.
     • 드롭: - 로드 밸런서가 모든 수신 요청을 드롭하면 클라이언트는 응답을 받지 못합니다.
     • 실패: - 로드 밸런서는 HTTP 503("서비스 이용 불가") 상태 코드가 포함된 요청을 거부하며, 클라이언트에게 서비스가 일시적으로 중단되었음을 알립니다.
   • Target: 백업 풀의 선택은 여기에서 이루어집니다. 대상 풀을 지정하는 경우, action 값은 반드시 forward

풀에 있는 인스턴스의 상태가 비정상적이지만 애플리케이션은 정상적으로 실행되고 있다면, 상태 확인 프로토콜과 상태 확인 경로 값을 확인해 보십시오. 또한 인스턴스에 연결된 모든 보안 그룹이 로드 밸런서와 인스턴스 간의 트래픽을 허용하는지 확인하십시오.