Compute Engine의 유동 IP 주소 사용 패턴

Last reviewed 2024-01-29 UTC

이 문서에서는 온프레미스 네트워크 환경에서 Compute Engine으로 애플리케이션을 마이그레이션할 때 유동 IP 주소 구현 패턴을 사용하는 방법을 설명합니다. 이 문서는 Google Cloud로 애플리케이션을 마이그레이션하려는 네트워크 엔지니어, 시스템 관리자, 운영 엔지니어를 대상으로 작성되었습니다.

공유 또는 가상 IP 주소로도 불리는 유동 IP 주소는 온프레미스 네트워크 환경을 고가용성 환경을 만들기 위해 사용되는 경우가 많습니다. 유동 IP 주소를 사용하면 동일하게 구성된 다수의 실제 또는 가상 서버 간에 IP 주소를 전달할 수 있습니다. 이렇게 해서 프로덕션 소프트웨어의 장애 조치 또는 업그레이드를 지원할 수 있습니다. 하지만 Compute Engine 환경에서는 이 문서에 설명된 패턴 중 하나로 아키텍처를 변경하지 않는 한 유동 IP 주소를 직접 구현하는 것이 불가능합니다.

이 문서가 있는 GitHub 저장소에는 Terraform을 사용해서 자동으로 배포할 수 있는 각 패턴의 샘플 배포가 포함되어 있습니다.

온프레미스 환경의 유동 IP 주소

유동 IP 주소는 일반적으로 온프레미스 환경에서 사용됩니다. 사용 사례 예시는 다음과 같습니다.

  • 방화벽이나 부하 분산기와 같이 가용성이 높은 물리적 어플라이언스는 종종 장애 조치에 유동 IP 주소를 사용합니다.
  • 기본 서버 및 백업 서버를 사용하는 관계형 데이터베이스와 같이 고가용성이 필요한 서버에는 일반적으로 유동 IP 주소가 사용됩니다. 일반적인 예시인 Microsoft SQL Server에는 AlwaysOn 가용성 그룹이 사용됩니다. 이러한 패턴을 Google Cloud에서 구현하는 방법은 동기 커밋을 사용하여 SQL Server AlwaysOn 가용성 그룹 구성을 참조하세요.
  • 부하 분산기 또는 역방향 프록시를 구현하는 Linux 환경은 IP 가상 서버(IPVS), HAProxy 및 nginx와 같은 유동 IP 주소를 사용합니다. 이러한 환경은 노드 장애를 감지하고 인스턴스 간에 유동 IP 주소를 이동하기 위해 Heartbeat, Pacemaker 또는 Keepalived와 같은 데몬을 사용합니다.
  • Windows Server 장애 조치 클러스터링과 함께 가용성이 높은 Windows 서비스에는 고가용성 보장을 위해 유동 IP 주소가 사용됩니다. Google Cloud에서 장애 조치 클러스터링을 사용하여 Windows 서비스를 구현하려면 Windows Server 장애 조치 클러스터링 실행을 참조하세요.

온프레미스 환경에서 유동 IP 주소를 구현하는 방법은 여러 가지입니다. 유동 IP 주소를 공유하는 서버는 일반적으로 하트비트 메커니즘을 통해 상태 정보를 공유합니다. 이 메커니즘을 통해 서버는 서로의 상태를 통신하여 알 수 있습니다. 또한 기본 서버가 실패한 후에 보조 서버가 유동 IP 주소를 인계할 수 있습니다. 이러한 스킴은 가상 라우터 중복 프로토콜을 사용하여 구현되는 경우가 많지만 다른 유사한 메커니즘을 사용할 수도 있습니다.

IP 주소 장애 조치가 시작되면 유동 IP 주소를 인계하는 서버가 해당 네트워크 인터페이스에 주소를 추가합니다. 이 서버는 Gratuitous 주소 결정 프로토콜(ARP) 프레임을 전송하고 Layer 2를 사용하는 다른 기기로 이 인계를 알립니다. 또는 최단 경로 우선 개방(OSPF)과 같은 라우팅 프로토콜이 IP 주소를 업스트림 Layer 3 라우터에 알리기도 합니다.

다음 다이어그램은 온프레미스 환경의 일반적인 설정을 보여줍니다.

일반적인 온프레미스 환경.

위 다이어그램은 하트비트 메커니즘을 통해 동일한 스위치 교환 응답 정보에 연결된 기본 서버와 보조 서버를 보여줍니다. 기본 서버가 실패하면 보조 서버가 유동 IP 주소를 인수하기 위해 Gratuitous ARP 프레임을 스위치로 전송합니다.

Windows 네트워크 부하 분산 또는 IPVS와 같은 직접 서버 응답이 있는 Linux 부하 분산과 같은 온프레미스 부하 분산 솔루션과 함께 약간 다른 설정을 사용합니다. 이 경우 서비스가 Gratuitous ARP 프레임도 전송하지만 다른 서버의 MAC 주소를 Gratuitous ARP 소스로 사용합니다. 이 작업은 기본적으로 ARP 프레임 스푸핑을 일으키며, 다른 서버의 소스 IP 주소를 인수합니다.

이 작업은 하나의 IP 주소 로드를 여러 서버 간에 분산하기 위해 수행됩니다. 하지만 이러한 설정 유형은 이 문서의 범위를 벗어납니다. 유동 IP 주소가 온프레미스 부하 분산에 사용되는 거의 모든 경우에는 Cloud Load Balancing으로 마이그레이션하는 것이 선호됩니다.

유동 IP 주소를 Compute Engine으로 마이그레이션할 때의 문제

Compute Engine은 Virtual Private Cloud(VPC) 네트워크에서 가상화된 네트워크 스택을 사용하므로 Google Cloud를 변경하지 않으면 일반적인 구현 메커니즘이 작동하지 않습니다. 예를 들어 VPC 네트워크는 소프트웨어 정의 네트워크에서 ARP 요청을 처리하고 Gratuitous ARP 프레임을 무시합니다. 또한 OSPF 또는 경계 게이트웨이 프로토콜(BGP)과 같은 표준 라우팅 프로토콜을 사용하여 VPC 네트워크 라우팅 테이블을 직접 수정하는 것은 불가능합니다. 유동 IP 주소의 일반적인 메커니즘에서는 ARP 요청이 인프라 전환을 통해 처리되거나, OSPF 또는 BGP에서 프로그래밍 가능한 네트워크가 사용됩니다. 따라서 Google Cloud에서 이러한 메커니즘을 사용해서 IP 주소가 장애 조치되지 않습니다. 온프레미스 유동 IP 주소를 사용해서 가상 머신(VM) 이미지를 마이그레이션하려는 경우 애플리케이션을 변경하지 않으면 유동 IP 주소가 장애 조치될 수 없습니다.

오버레이 네트워크를 사용하면 ARP 요청을 사용해서 전체 Layer 2 통신 및 IP 인계를 가능하게 하는 구성을 만들 수 있습니다. 그러나 오버레이 네트워크를 설정하는 것은 복잡하고 Compute Engine 네트워크 리소스를 관리하기 어렵게 만듭니다. 이러한 접근 방식도 이 문서의 범위를 벗어납니다. 대신 이 문서에서는 오버레이 네트워크를 만들지 않고 Compute Engine 네트워킹 환경에서 장애 조치 시나리오를 구현하기 위한 패턴에 대해 설명합니다.

Compute Engine에서 가용성이 높고 안정적인 애플리케이션을 구현하기 위해서는 수평 확장 아키텍처를 사용합니다. 이 유형의 아키텍처는 단일 노드 장애로 인한 결과를 최소화합니다.

이 문서에서는 다음과 같이 유동 IP 주소를 사용해서 온프레미스에서 Compute Engine으로 기존 애플리케이션을 마이그레이션하기 위한 여러 패턴에 대해 설명합니다.

VM 인스턴스 간에 이동되는 별칭 IP 주소는 고가용성 요구사항을 충족하지 않으므로 장애 조치 메커니즘으로 권장되지 않습니다. 영역 장애 이벤트와 같은 특정 장애 시나리오에서는 인스턴스에서 별칭 IP 주소를 삭제하지 못할 수 있습니다. 따라서 이를 다른 인스턴스로 추가할 수도 없어서 장애 조치가 불가능할 수 있습니다.

사용 사례별 패턴 선택

요구사항에 따라 이 솔루션에서 설명하는 패턴 중 하나 이상이 온프레미스 환경에서 유동 IP 주소를 구현하는 데 유용하게 사용될 수 있습니다.

애플리케이션에서 사용하기에 가장 적합한 패턴을 결정할 때는 다음 요소를 고려하세요.

  • 유동 내부 또는 유동 외부 IP 주소: 유동 IP 주소가 필요한 대부분의 애플리케이션에서는 유동 내부 IP 주소가 사용됩니다. 일반적으로 외부 애플리케이션에 대한 트래픽이 부하 분산되기 때문에 유동 외부 IP 주소가 사용되는 애플리케이션은 거의 없습니다.

    이 섹션의 뒷 부분에 있는 표에서는 유동 내부 IP 주소 및 유동 외부 IP 주소에 사용할 수 있는 패턴을 추천합니다. 유동 내부 IP 주소를 사용하는 사용 사례의 경우 필요에 따라 이러한 패턴 중 하나가 실행 가능할 수 있습니다. 하지만 유동 외부 IP 주소를 사용하는 사용 사례는 부하 분산을 사용하는 패턴 중 하나로 마이그레이션하는 것이 좋습니다.

  • 애플리케이션 프로토콜: VM에 TCP 및 UDP만 사용되는 경우 이 표에 있는 모든 패턴을 사용할 수 있습니다. IPv4를 기반으로 다른 연결 프로토콜이 사용될 경우에는 일부 패턴만 적합합니다.

  • 활성-활성 배포 호환성: 온프레미스에서 유동 IP를 사용하는 일부 애플리케이션은 활성-활성 배포 모드로 작동할 수 있습니다. 즉, 기본 서버에서 보조 서버로 장애 조치가 반드시 필요하지는 않습니다. 이러한 종류의 애플리케이션을 Compute Engine으로 이동할 때는 더 많은 패턴을 선택할 수 있습니다. 언제든지 트래픽 수신을 위해 단일 애플리케이션 서버만 필요한 애플리케이션은 활성-활성 배포와 호환되지 않습니다. 이러한 애플리케이션은 다음 표의 일부 패턴만 사용해서 구현할 수 있습니다.

  • 기본 VM 복구 후 장애 복구 동작: 장애 조치 후 원래 기본 VM이 복구될 때는 사용된 패턴에 따라 트래픽이 둘 중 하나의 동작을 수행합니다. 한 가지 동작은 원래 기본 VM으로 즉시 돌아가는 것이고 다른 동작은 수동 장애 복구 시작 또는 새 기본 VM 실패가 이뤄질 때까지 새 기본 VM에 유지되는 것입니다. 모든 경우 새로 시작된 연결만 장애 복구됩니다. 기존 연결은 연결이 닫힐 때까지 새 기본 VM에서 유지됩니다.

  • 상태 점검 호환성: Compute Engine 상태 점검을 사용하여 애플리케이션이 응답하는지 쉽게 확인할 수 없는 경우 다음 표에 설명된 일부 패턴을 사용할 수 없습니다.

  • 인스턴스 그룹: 상태 점검과 호환되는 패턴은 인스턴스 그룹과도 호환됩니다. 실패한 인스턴스를 자동으로 다시 만들려면 자동 복구 기능이 있는 관리형 인스턴스 그룹을 사용하면 됩니다. VM에 상태가 유지되면 스테이트풀(Stateful) 관리형 인스턴스 그룹을 사용할 수 있습니다. VM을 자동으로 다시 만들 수 없거나 수동 장애 조치가 필요한 경우 비관리형 인스턴스 그룹을 사용하고 장애 조치 중에 VM을 수동으로 다시 만듭니다.

  • 기존 하트비트 메커니즘: 애플리케이션의 고가용성 설정이 이미 Heartbeat, Pacemaker 또는 Keepalived와 같은 하트비트 메커니즘을 사용하여 장애 조치를 트리거하는 경우 다음 표에 설명된 일부 패턴을 사용할 수 있습니다.

다음 표에서는 패턴 기능을 보여줍니다. 각 패턴에 대한 설명은 다음 섹션을 참조하세요.

패턴 이름 IP 주소 지원 프로토콜 배포 모드 장애 복구 애플리케이션 상태 확인 호환성 필요 하트비트 메커니즘 통합 가능
부하 분산 사용 패턴
active-active 부하 분산 내부 또는 외부 TCP/UDP 전용 active-active 해당 사항 없음 예 아니요
장애 조치 및 애플리케이션 노출 상태 확인을 사용하는 부하 분산 내부 또는 외부 TCP/UDP 전용 active-passive 즉시(기존 연결 제외) 예 아니요
장애 조치 및 하트비트 노출 상태 확인을 사용하는 부하 분산 내부 또는 외부 TCP/UDP 전용 active-passive 구성 가능 아니요 예
Google Cloud 경로 사용 패턴
ECMP 경로 사용 내부 모든 IP 프로토콜 active-active 해당 사항 없음 예 아니요
다른 우선순위 경로 사용 내부 모든 IP 프로토콜 active-passive 즉시(기존 연결 제외) 예 아니요
하트비트 메커니즘을 사용하여 경로 다음 홉 전환 내부 모든 IP 프로토콜 active-passive 구성 가능 아니요 예
자동 복구를 사용하는 패턴
자동 복구 단일 인스턴스 사용 내부 모든 IP 프로토콜 해당 사항 없음 해당 사항 없음 예 아니요

사용 사례에 사용할 패턴은 다음 요소에 따라 결정될 수 있습니다. 다음 결정 트리에 따라 적합한 옵션을 선택할 수 있습니다.

부하 분산기 선택을 도와주는 결정 트리입니다.

위의 다이어그램은 다음 단계를 간략하게 설명하고 있습니다.

  1. 단일 자동 복구 인스턴스가 요구 사항에 맞는 충분한 가용성을 제공하나요?
    1. 그렇다면 이 문서의 뒷 부분에 있는 자동 복구 단일 인스턴스 사용을 참조하세요. 자동 복구는 VM 인스턴스 그룹의 메커니즘을 사용해서 장애가 있는 VM 인스턴스를 자동으로 대체합니다.
    2. 그렇지 않으면 다음 결정 트리로 이동합니다.
  2. 애플리케이션에 TCP 및 UDP가 아닌 IPv4 기반의 프로토콜이 필요한가요?
    1. 그렇다면 다음 결정 지점으로 이동합니다.
    2. 그렇지 않으면 다음 결정 지점으로 이동합니다.
  3. 애플리케이션이 active-active 모드에서 작동할 수 있나요?
    1. 답변이 예이고 TCP 및 UDP 이외의 IPv4 기반 프로토콜이 필요하면 이 문서 뒷 부분에 있는 등가 멀티 경로 (ECMP) 경로 사용을 참고하세요. ECMP 경로는 모든 경로 후부의 다음 홉 간에 트래픽을 분산합니다.
    2. 예이며 TCP와 UDP 이외의 IPv4 외에 프로토콜이 필요하지 않으면 이 문서 뒷부분의 active-active 부하 분산을 참조하세요. active-active 부하 분산은 VM을 내부 TCP/UDP 부하 분산기의 백엔드로 사용합니다.
    3. 그렇지 않으면, 어느 경우든 다음 결정 지점으로 이동합니다.
  4. 애플리케이션이 Google Cloud 상태 확인을 노출할 수 있나요?
    1. 답변이 예이고 TCP 및 UDP 외에 IPv4 기반 프로토콜이 필요하면 이 문서 뒷 부분에 있는 장애 조치 및 애플리케이션 노출 상태 확인을 사용하는 부하 분산을 참고하세요. 장애 조치 및 애플리케이션 노출 상태 확인을 사용하는 부하 분산에서는 VM이 내부 TCP/UDP 부하 분산기의 백엔드로 사용됩니다. 또한 내부 TCP/UDP 부하 분산 IP 주소가 가상 IP 주소로 사용됩니다.
    2. 답변이 예이고 TCP 및 UDP 이외의 IPv4 기반 프로토콜이 필요하지 않으면 이 문서 뒷 부분에 있는 다른 우선순위 경로 사용을 참조하세요. 다른 우선순위 경로를 사용하면 기본 인스턴스 작동이 실패하지 않는 한 해당 인스턴스로 트래픽이 계속 전달되도록 보장합니다.
    3. 답변이 아니요이고 TCP 및 UDP 이외의 IPv4 기반 프로토콜이 필요하면 이 문서 뒷 부분에 있는 장애 조치 및 하트비트 노출 상태 확인을 사용하는 부하 분산을 참조하세요. 장애 조치 및 하트비트 노출 상태 확인을 사용하는 부하 분산 패턴에서는 상태 확인이 애플리케이션 자체가 아닌 두 VM 간에 실행되는 하트비트 메커니즘에 의해 노출됩니다.
    4. 답변이 아니요이고 TCP 및 UDP 외의 IPv4 기반 프로토콜이 필요하지 않으면 이 문서 뒷 부분에 있는 하트비트 메커니즘을 사용하여 경로 다음 홉 전환을 참조하세요. 하트비트 메커니즘을 사용하여 경로 다음 홉을 전환할 때는 기본 VM 인스턴스를 가리키는 다음 홉에 단일 정적 경로가 사용됩니다.

부하 분산 사용 패턴

일반적으로는 Google Cloud에서 유동 IP 주소를 사용해서 Cloud Load Balancing을 사용하는 아키텍처로 애플리케이션을 마이그레이션할 수 있습니다. 이 옵션은 마이그레이션된 온프레미스 서비스만 내부적으로 노출되는 대부분의 사용 사례에 가장 적합하기 때문에 내부 패스 스루 네트워크 부하 분산기를 사용할 수 있습니다. 이 부하 분산 옵션은 이 섹션의 모든 예시 및 GitHub의 샘플 배포에 사용됩니다. 클라이언트가 다른 리전에서 유동 IP 주소에 액세스하는 경우 전역 액세스 옵션을 선택합니다.

애플리케이션이 TCP 또는 UDP 외의 IPv4 기반 프로토콜을 사용해서 통신하는 경우 부하 분산을 사용하지 않는 패턴을 선택해야 합니다. 이러한 패턴에 대해서는 이 문서의 뒷 부분에서 설명합니다.

애플리케이션이 HTTP(S)를 사용하는 경우 내부 애플리케이션 부하 분산기를 사용하여 활성-활성 패턴을 구현할 수 있습니다.

마이그레이션하려는 서비스가 외부에서 사용 가능한 경우 외부 패스 스루 네트워크 부하 분산기를 사용하여 이 섹션에서 설명하는 모든 패턴을 구현할 수 있습니다. 활성-활성 배포의 경우 해당 부하 분산 옵션으로 지원되는 프로토콜 및 포트가 애플리케이션에 사용되면 외부 애플리케이션 부하 분산기, TCP 프록시 또는 SSL 프록시를 사용할 수도 있습니다.

다음과 같이 온프레미스 유동 IP 주소 기반 구현과 모든 부하 분산 기반 패턴 간의 차이를 고려하세요.

  • 장애 조치 시간: 온프레미스 환경에서 Gratuitous ARP를 사용해서 연결 유지되는 페어링을 수행하면 IP 주소를 장애 조치하는 데 몇 초 정도 소요될 수 있습니다. Compute Engine 환경에서 장애 조치의 평균 복구 시간은 설정한 매개변수에 따라 달라집니다. 가상 머신(VM) 인스턴스 또는 VM 인스턴스 서비스에 장애가 발생할 경우 장애 조치 평균 시간 트래픽은 Check Interval 및 Unhealthy Threshold와 같은 상태 확인 매개변수에 따라 달라집니다. 이 매개변수를 기본값으로 설정하면 장애 조치는 일반적으로 15~20초가 걸립니다. 이러한 매개변수 값을 줄이면 시간을 더 줄일 수 있습니다.

    Compute Engine에서 영역 내 또는 여러 영역 간 장애 조치는 동일한 시간이 걸립니다.

  • 프로토콜 및 포트: 온프레미스 설정에서 유동 IP 주소는 모든 트래픽을 허용합니다. 내부 패스 스루 네트워크 부하 분산기의 경우 내부 전달 규칙의 다음 포트 사양 중 하나를 선택합니다.

    • 숫자로 1~5개의 포트를 지정합니다.
    • TCP 또는 UDP에 대해 모든 포트에서 트래픽을 전달하려면 ALL을 지정합니다.
    • TCP 및 UDP 트래픽 혼합을 전달하거나 단일 IP 주소로 5개를 초과하는 포트를 사용하려면 동일한 IP 주소를 사용하는 여러 전달 규칙을 사용합니다.
      • TCP 또는 UDP 및 1~5 포트: 전달 규칙 하나를 사용합니다.
      • TCP와 UDP 및 1~5 포트: 여러 전달 규칙을 사용합니다.
      • 6개 이상 포트와 TCP 또는 UDP: 여러 전달 규칙을 사용합니다.

  • 상태 확인: 온프레미스에서는 다음 방법으로 머신에서 애플리케이션 응답을 확인할 수 있습니다.

active-active 부하 분산

활성-활성 부하 분산 패턴에서 VM은 내부 패스 스루 네트워크 부하 분산기의 백엔드입니다. 내부 패스 스루 네트워크 부하 분산기 IP 주소를 가상 IP 주소로 사용합니다. 트래픽은 2개의 백엔드 인스턴스 사이에 고르게 분산됩니다. 동일 세션에 속하는 트래픽은 세션 어피니티 설정에 정의된 대로 동일한 백엔드 인스턴스로 이동합니다.

애플리케이션에 TCP 및 UDP 기반 프로토콜만 사용되고 머신 간 장애 조치가 필요하지 않으면 활성-활성 부하 분산 패턴을 사용합니다. 애플리케이션이 요청 내용 자체에 따라 요청에 응답할 수 있는 시나리오에서 이 패턴을 사용합니다. 기본 또는 보조 데이터베이스에서와 같이 지속적으로 동기화되지 않는 머신 상태가 있으면 이 패턴을 사용하지 않습니다.

다음 다이어그램은 active-active 부하 분산 패턴의 구현을 보여줍니다.

내부 클라이언트가 active-active 부하 분산 패턴을 탐색하는 방법

이전 다이어그램은 내부 패스 스루 네트워크 부하 분산기를 통해 2개 VM에서 실행되는 서비스에 내부 클라이언트가 액세스하는 방법을 보여줍니다. 두 VM 모두 인스턴스 그룹의 일부입니다.

active-active 부하 분산 패턴을 사용하려면 서비스가 지원되는 상태 점검 프로토콜 중 하나를 사용하여 상태 점검을 노출하여 응답하는 VM만 트래픽을 수신하도록 해야 합니다.

이 패턴의 전체 샘플 구현은 GitHub에서 Terraform을 사용한 배포 예시를 참조하세요.

장애 조치 및 애플리케이션 노출 상태 확인을 사용하는 부하 분산

활성-활성 패턴과 비슷하게, 장애 조치 및 애플리케이션 노출 상태 확인을 통한 부하 분산에서는 해당 VM이 내부 패스 스루 네트워크 부하 분산기의 백엔드로 사용됩니다. 또한 내부 패스 스루 네트워크 부하 분산기 IP 주소를 가상 IP 주소로 사용합니다. 한 번에 하나의 VM에서만 트래픽이 수신되도록 이 패턴은 내부 패스 스루 네트워크 부하 분산기에 대한 장애 조치를 적용합니다.

이 패턴은 애플리케이션에 TCP 또는 UDP 트래픽만 있고 활성-활성 배포가 지원되지 않을 경우에 권장됩니다. 이 패턴을 적용하면 모든 트래픽이 기본 VM 또는 장애 조치 VM으로 전달됩니다.

다음 다이어그램은 장애 조치 및 애플리케이션 노출 상태 확인 패턴을 사용한 부하 분산 구현을 보여줍니다.

내부 클라이언트가 내부 패스 스루 네트워크 부하 분산기 뒤에서 서비스를 탐색하는 방법

이전 다이어그램은 내부 클라이언트가 내부 패스 스루 네트워크 부하 분산기 뒤에서 서비스에 액세스하는 방법을 보여줍니다. 2개의 VM은 개별 인스턴스 그룹에 있습니다. 한 인스턴스 그룹은 기본 백엔드로 설정됩니다. 다른 인스턴스 그룹은 내부 패스 스루 네트워크 부하 분산기의 장애 조치 백엔드로 설정됩니다.

기본 VM의 서비스가 응답하지 않으면 트래픽이 장애 조치 인스턴스 그룹으로 전환됩니다. 기본 VM이 다시 응답하면 트래픽이 자동으로 기본 백엔드 서비스로 다시 전환됩니다.

이 패턴의 전체 샘플 구현은 GitHub에서 Terraform을 사용한 배포 예시를 참조하세요.

장애 조치 및 하트비트 노출 상태 확인을 사용하는 부하 분산

장애 조치 및 하트비트 노출 상태 확인을 사용하는 부하 분산 패턴은 이전 패턴과 동일합니다. 상태 확인이 애플리케이션 자체로 노출되지 않지만 두 VM 상에 실행되는 하트비트 메커니즘에 의해 노출된다는 것만 다릅니다.

다음 다이어그램은 장애 조치 및 하트비트 노출 상태 확인 패턴을 사용한 부하 분산 구현을 보여줍니다.

2개의 VM이 개별 인스턴스 그룹에 있는 상태로 내부 클라이언트가 내부 부하 분산기 뒤에서 서비스에 액세스하는 방법

이 다이어그램은 내부 클라이언트가 내부 부하 분산기 뒤에서 서비스에 액세스하는 방법을 보여줍니다. 2개의 VM은 개별 인스턴스 그룹에 있습니다. 한 인스턴스 그룹은 기본 백엔드로 설정됩니다. 다른 인스턴스 그룹은 내부 패스 스루 네트워크 부하 분산기의 장애 조치 백엔드로 설정됩니다. 연결 유지는 VM 노드 사이에 하트비트 메커니즘으로 사용됩니다.

VM 노드는 선택한 하트비트 메커니즘을 사용하여 서비스 상태에 대한 정보를 교환합니다. 각 VM 노드는 자체 상태를 확인하고 상태를 원격 노드에 알립니다. 로컬 노드 상태 및 원격 노드에서 수신된 상태에 따라 한 노드가 기본 노드로 선택되고 다른 노드는 백업 노드로 선택됩니다. 이 상태 정보를 사용해서 하트비트 메커니즘에서 기본으로 고려된 노드가 내부 패스 스루 네트워크 부하 분산기의 트래픽도 수신하게 해주는 상태 점검 결과를 노출할 수 있습니다.

예를 들어 연결 유지의 경우 상태 점검 상태를 변경하는 notify_master, notify_backup, notify_fault 구성 변수를 사용하여 스크립트를 호출할 수 있습니다. 기본 상태(연결 유지에서는 이 상태를 master라고 부름)로 전환할 때 커스텀 TCP 포트로 리슨하는 애플리케이션을 시작할 수 있습니다. 백업 또는 오류 상태로 전환할 때는 이 애플리케이션을 중지할 수 있습니다. 상태 확인은 이 커스텀 TCP 포트가 열린 경우 성공하는 TCP 상태 확인일 수 있습니다.

이 패턴은 애플리케이션 노출 상태 확인으로 장애 조치를 사용하는 패턴보다 복잡합니다. 하지만 더 세부적인 제어가 가능합니다. 예를 들어 즉시 또는 하트비트 메커니즘을 구현하는 동안 수동으로 장애 복구하도록 구성할 수 있습니다.

연결 유지를 사용하는 이 패턴의 전체 샘플 구현은 GitHub에서 Terraform을 사용한 배포 예시를 참조하세요.

Google Cloud 경로 사용 패턴

애플리케이션이 IPv4 기반으로 TCP 또는 UDP 이외의 프로토콜을 사용하는 경우 유동 IP 주소를 경로 기반 패턴으로 마이그레이션할 수 있습니다.

이 섹션에서는 경로는 항상 VPC 네트워크의 일부인 Google Cloud 경로를 나타냅니다. 정적 경로는 항상 Google Cloud의 정적 경로를 나타냅니다.

이러한 패턴 중 하나를 사용하여 다른 인스턴스를 다음 홉으로 사용하는 특정 IP 주소에 대해 여러 정적 경로를 설정할 수 있습니다. 이 IP 주소는 모든 클라이언트에 사용되는 유동 IP 주소가 됩니다. 정적 경로가 기존 서브넷 경로를 재정의할 수 없기 때문에 모든 VPC 서브넷 IP 주소 범위 외부에 있어야 합니다. 대상 인스턴스에서 IP 주소 전달을 설정해야 합니다. IP 주소 전달을 사용 설정하면 인스턴스에 할당되지 않은 IP 주소로 트래픽을 수락할 수 있으며, 이 경우에는 유동 IP 주소입니다.

유동 IP 주소 경로를 피어링된 VPC 네트워크에서 사용할 수 있도록 하려면 커스텀 경로를 내보내어 유동 IP 주소 경로를 모든 피어 VPC 네트워크에 전파합니다.

Cloud Interconnect 또는 Cloud VPN을 통해 온프레미스 네트워크에서 연결하려면 커스텀 IP 주소 경로 공지를 사용하거나 온프레미스에 유동 IP 주소를 공지해야 합니다.

경로 기반 패턴은 부하 분산 기반 패턴에 비해 다음과 같은 이점이 있습니다.

  • 프로토콜 및 포트: 경로 기반 패턴은 특정 대상에 전송되는 모든 트래픽에 적용됩니다. 부하 분산 기반 패턴은 TCP 및 UDP 트래픽에만 허용됩니다.

경로 기반 패턴은 부하 분산 기반 패턴에 비해 다음과 같은 단점이 있습니다.

  • 상태 확인: 상태 확인을 Google Cloud 경로에 연결할 수 없습니다. 경로는 기본 VM 서비스의 상태와 관계없이 사용됩니다. VM이 실행되는 경우 서비스가 비정상인 경우에도 인스턴스로 직접 트래픽을 라우팅합니다. 이러한 인스턴스에 자동 복구 정책을 연결하면 지정된 비정상 기간이 지난 후 인스턴스를 대체합니다. 하지만 해당 인스턴스가 재시작된 후 서비스가 작동되기 전이라도 트래픽이 즉시 재개됩니다. 이러한 서비스 격차로 인해 비정상 인스턴스가 아직 트래픽을 제공하거나 다시 시작되는 동안 서비스 오류가 발생할 수 있습니다.
  • 장애 조치 시간: VM 인스턴스를 삭제하거나 중지한 후에는 Compute Engine이이 인스턴스를 가리키는 모든 정적 경로를 무시합니다. 하지만 경로에 대한 상태 확인이 없기 때문에 인스턴스를 아직 사용할 수 있는 한 Compute Engine에서 계속 정적 경로가 사용됩니다. 또한 인스턴스 중지에 시간이 걸리므로 부하 분산 기반 패턴보다 장애 조치 시간이 상당히 높습니다.
  • 내부 유동 IP 주소만: 외부 패스 스루 네트워크 부하 분산과 함께 부하 분산을 사용하여 패턴을 구현하여 외부 유동 IP 주소를 만들 수 있지만 경로 기반 패턴은 내부 유동 IP 주소에서만 작동합니다.
  • 유동 IP 주소 선택: 서브넷에 포함되지 않는 내부 유동 IP 주소로만 경로를 설정할 수 있습니다. 서브넷 경로를 Google Cloud에서 덮어쓸 수 없습니다. 다른 네트워크에 실수로 할당할 수 없도록 이러한 유동 IP 주소를 관리해야 합니다.
  • 경로 연결 가능성: 내부 유동 IP 주소를 온프레미스 네트워크 또는 피어링된 네트워크에서 연결 가능하도록 만들려면 이전에 설명된 것처럼 이러한 정적 경로를 분산해야 합니다.

등가 멀티 경로(ECMP) 경로 사용

등가 멀티 경로(ECMP) 경로 패턴은 활성-활성 부하 분산 패턴과 비슷합니다. 트래픽이 두 백엔드 인스턴스 사이에 동일하게 분산됩니다. 정적 경로를 사용할 때는 ECMP가 어피니티에 5-튜플 해시를 사용하여 모든 경로 후보의 다음 홉 사이에 트래픽을 분산합니다.

Compute Engine 인스턴스를 다음 홉으로 사용해서 우선순위가 동일한 2개의 정적 경로를 만드는 방식으로 이 패턴을 구현합니다.

다음 다이어그램 ECMP 경로 패턴의 구현을 보여줍니다.

내부 클라이언트가 2개의 ECMP 경로 중 하나를 사용하여 서비스에 액세스하는 방법

이전 다이어그램은 내부 클라이언트가 서비스를 구현하는 VM 인스턴스를 가리키는 다음 홉과 함께 2개 경로 중 하나를 사용해서 서비스에 액세스하는 방법을 보여줍니다.

한 VM의 서비스가 응답하지 않으면 자동 복구가 응답하지 않는 인스턴스를 다시 만들려고 시도합니다. 자동 복구로 인스턴스가 삭제된 후에는 새 인스턴스가 생성되기 전까지 인스턴스를 가리키는 경로가 비활성화됩니다. 새 인스턴스가 존재하면 이 인스턴스를 가리키는 경로가 즉시 자동으로 사용되고 트래픽이 인스턴스 간에 동일하게 분산됩니다.

ECMP 경로 패턴의 경우 자동 복구가 응답하지 않는 VM을 자동으로 대체할 수 있도록 서비스가 지원되는 프로토콜을 사용해서 상태 확인을 노출해야 합니다.

이 문서와 관련된 GitHub 저장소에서 Terraform을 사용하는 이 패턴의 샘플 구현을 찾을 수 있습니다.

다른 우선순위 경로 사용

다른 우선순위 경로 패턴도 이전 패턴과 비슷하지만, 인스턴스가 실패하지 않는 한 트래픽이 항상 기본 인스턴스로 전달되도록 다른 우선순위 정적 경로가 사용된다는 것이 다릅니다.

이 패턴을 구현하기 위해서는 ECMP 경로 패턴의 동일 단계를 수행합니다. 정적 경로를 만들 때는 다음 홉이 기본 인스턴스를 가리키는 경로에 더 낮은 우선순위 값(기본 경로)을 부여합니다. 다음 홉이 보조 인스턴스를 가리키는 인스턴스에는 더 높은 우선순위 값(보조 경로)을 부여합니다.

다음 다이어그램은 다른 우선순위 경로 패턴의 구현을 보여줍니다. 서비스에 액세스하는 내부 클라이언트가 네트워크 상황에 따라 기본 또는 보조 경로를 사용하는 방법

이전 다이어그램은 서비스에 액세스하는 내부 클라이언트가 정상 상황에서 다음 홉으로 VM 1을 가리키는 우선순위 값 500의 기본 경로를 사용하는 방법을 보여줍니다. 우선순위 값이 1,000인 보조 경로는 VM 2인 보조 VM에 다음 홉으로 연결될 수 있습니다.

기본 VM의 서비스가 응답하지 않으면 자동 복구가 인스턴스를 다시 만들려고 시도합니다. 자동 복구로 인스턴스가 삭제된 다음 생성된 새 인스턴스가 설정되기 전 기본 인스턴스를 다음 홉으로 사용해서 기본 경로가 비활성화됩니다. 그런 후 패턴에서 보조 인스턴스가 잇는 경로가 다음 홉으로 사용됩니다. 새 기본 인스턴스가 설정된 후에는 기본 경로가 다시 활성화되고 모든 트래픽이 기본 인스턴스로 전달됩니다.

이전 패턴과 마찬가지로 다른 우선순위 경로 패턴에서는 자동 복구가 응답하지 않는 VM을 자동으로 대체할 수 있도록 서비스가 지원되는 프로토콜을 사용해서 상태 확인을 노출해야 합니다.

이 문서가 포함된 GitHub 저장소에서 Terraform을 사용하는 이 패턴의 샘플 구현을 찾을 수 있습니다.

하트비트 메커니즘을 사용하여 경로의 다음 홉 전환

애플리케이션이 애플리케이션 응답을 모니터링하기 위해 연결 유지와 같은 하트비트 메커니즘을 구현하는 경우 하트비트 메커니즘 패턴을 적용해서 정적 경로의 다음 홉을 변경할 수 있습니다. 이 경우 기본 VM 인스턴스를 가리키는 다음 홉에 단일 정적 경로만 사용할 수 있습니다. 장애 조치 시 하트비트 메커니즘은 경로의 다음 홉을 보조 VM으로 연결합니다.

다음 다이어그램은 경로의 다음 홉 패턴을 전환하기 위한 하트비트 메커니즘 구현을 보여줍니다.

내부 클라이언트가 기본 및 보조 VM이 하트비트 정보를 교환하는 서비스에 액세스하는 방법

이전 다이어그램은 내부 클라이언트가 다음 홉이 기본 VM을 가리키는 경로를 사용해서 서비스에 액세스하는 방법을 보여줍니다. 기본 VM은 연결 유지를 통해 하트비트 정보를 보조 VM과 교환합니다. 장애 조치 시 연결 유지는 API 호출을 사용해서 보조 VM에서 다음 홉을 가리키는 Cloud Run 함수를 호출합니다.

노드는 선택한 하트비트 메커니즘을 사용해서 서비스 상태 관련 정보를 서로 교환합니다. 각 VM 노드는 자체 상태를 확인하고 이를 원격 VM 노드에 알립니다. 로컬 VM 노드 상태 및 원격 노드에서 수신된 상태에 따라 한 VM 노드가 기본 노드로 선택되고 다른 VM 노드는 백업 노드로 선택됩니다. 노드가 기본으로 설정된 다음에는 유동 IP 주소에 대해 경로의 다음 홉을 자신으로 연결합니다. 연결 유지를 사용하는 경우 API 호출 또는 Google Cloud CLI를 사용해서 정적 경로를 대체하는 notify_master 구성 변수를 사용해서 스크립트를 호출할 수 있습니다.

경로의 다음 홉 패턴을 전환하기 위한 하트비트 메커니즘은 VM이 인스턴스 그룹의 일부일 필요가 없습니다. 실패 시 VM이 자동으로 대체되도록 하려면 이를 자동 복구 인스턴스 그룹에 배치할 수 있습니다. 또한 응답하지 않는 VM을 수동으로 복구하고 다시 만들 수도 있습니다.

1단계에서 단일 API 호출이 완료된 후 트래픽이 장애 조치되기 때문에 장애 조치 시 다음 절차를 호출하면 장애 조치 시간이 최소화됩니다.

  1. 유동 IP 주소를 대상으로 사용하고 새 기본 인스턴스를 다음 홉으로 지정해서 새 정적 경로를 만듭니다. 새 경로는 경로 이름이 달라야 하고 경로 우선순위가 원래 경로보다 낮아야 합니다(예: 400).
  2. 이전 기본 VM에 대한 원래 경로를 삭제합니다.
  3. 바로 전에 삭제한 경로와 동일한 이름 및 우선순위를 사용해서 경로를 만듭니다. 새 기본 VM에서 다음 홉으로 연결합니다.
  4. 만든 새 정적 경로를 삭제합니다. 트래픽이 새 기본 VM으로 전달되도록 보장하기 위해서는 이것이 필요하지 않습니다.

원래 경로가 대체되었으므로 분할 네트워크의 경우에도 경로가 한 번에 하나만 활성화됩니다.

다른 경로 기반 패턴 대신 하트비트 메커니즘을 사용해서 경로 우선순위 패턴을 전환하면 장애 조치 시간이 줄어들 수 있습니다. 장애 조치를 위한 자동 복구를 통해 VM을 삭제하거나 대체할 필요가 없습니다. 또한 다시 응답이 돌아온 후 원래 기본 서버로 장애 복구할 때 이를 더 자세히 제어할 수 있습니다.

이 패턴의 한 가지 단점은 하트비트 메커니즘을 직접 관리해야 한다는 것입니다. 메커니즘 관리는 더 복잡한 결과로 이어질 수 있습니다. 또 다른 단점은 하트비트 프로세스를 실행하는 VM으로 또는 하트비트 프로세스에서 호출되는 서버리스 함수로 전역 라우팅 테이블을 변경하기 위해 권한을 부여해야 하는 것입니다. 전역 라우팅 테이블을 서버리스 함수로 변경하는 것이 VM에 부여되는 권한 범위를 줄일 수 있으므로 더 안전합니다. 하지만 이 방법은 구현하기에 더 복잡합니다.

Keepalived를 사용한 이 패턴의 전체 샘플 구현은 GitHub에서 Terraform을 사용한 배포 예시를 참조하세요.

자동 복구를 사용하는 패턴

복구 시간 요구사항에 따라 Compute Engine을 사용할 때는 단일 VM 인스턴스로 마이그레이션하는 것이 적절한 옵션일 수 있습니다. 이 옵션은 유동 IP 주소를 사용하는 여러 서버가 온프레미스에 사용된 경우에도 그렇습니다. 축소하는 VM 수에 관계없이 이 패턴을 여러 번 사용할 수 있는 이유는 몇 초 또는 몇 분 내에 새 Compute Engine 인스턴스를 만들 수 있기 때문입니다. 반면에 온프레미스 장애의 경우 일반적으로 해결하는 데 몇 시간 또는 며칠까지 걸릴 수 있습니다.

자동 복구 단일 인스턴스 사용

이 패턴을 사용할 때는 VM 인스턴스 그룹에서 장애 VM 인스턴스를 자동으로 대체할 수 있는 자동 복구 메커니즘이 필요합니다. 애플리케이션이 상태 확인을 노출하고 애플리케이션이 비정상일 때 자동 복구가 VM을 자동으로 대체합니다.

다음 다이어그램은 단일 인스턴스 패턴을 자동 복구하는 구현을 보여줍니다.

내부 클라이언트가 Compute Engine 인스턴스에 직접 연결되는 방법

이전 다이어그램은 내부 클라이언트가 크기가 1이고 자동 복구가 설정된 관리형 인스턴스 그룹에 배치된 Compute Engine 인스턴스에 직접 연결되는 방법을 보여줍니다.

부하 분산을 사용하는 패턴과 달리 자동 복구 단일 인스턴스 패턴은 다음과 같은 이점이 있습니다.

  • 트래픽 분산: 인스턴스가 하나만 있으므로 인스턴스에 항상 모든 트래픽이 수신됩니다.
  • 사용 편의성: 인스턴스가 하나만 있으므로 구현하기에 가장 간단한 패턴입니다.
  • 비용 절약: 2개 대신 단일 VM 인스턴스만 사용하므로 구현 비용을 절반으로 줄일 수 있습니다.

하지만 이 패턴에는 다음과 같은 단점이 있습니다.

  • 장애 조치 시간: 부하 분산 기반 패턴보다 프로세스가 상당히 느립니다. 상태 확인으로 머신 오류가 감지된 후 장애 인스턴스를 삭제하고 다시 만들려면 최소 1분 이상, 일반적으로 더 많은 시간이 필요합니다. 이 패턴은 프로덕션 환경에서 일반적이지 않습니다. 하지만 내부 또는 실험용 서비스의 경우 장애 조치 시간이 충분히 적절할 수 있습니다.
  • 영역 장애 대응: 크기가 1인 관리형 인스턴스 그룹은 영역 장애의 영향을 받습니다. 영역 장애에 대응하려면 서비스가 실패할 때 Cloud Monitoring 알림을 추가하고 영역 장애가 발생하면 다른 영역에 인스턴스 그룹을 만듭니다. 이 경우 동일한 IP 주소를 사용할 수 없기 때문에 Cloud DNS 비공개 영역을 사용해서 VM 주소를 지정하고 DNS 이름을 새 IP 주소로 전환합니다.

GitHub 저장소에서 Terraform을 사용하는 이 패턴의 샘플 구현을 찾을 수 있습니다.

다음 단계