Hermes를 통한 고급 고가용성 전송

  • 릴리스 버전: Australia
  • 업데이트 날짜 2026년 03월 12일
  • 소요 시간: 3분
  • 정상 작동, AHA(Advanced High Availability) 전송 및 페일오버 시나리오 중에 Hermes에서 메시지가 생성되고 소비되는 방법을 알아봅니다.

    ServiceNow 프로덕션 인스턴스는 지리적으로 분리된 데이터 센터에서 운영됩니다. 각 데이터 센터는 다른 데이터 센터와 쌍을 이루어 페일오버 지원과 함께 중복성을 제공합니다. 한 데이터 센터는 활성 측으로 지정되고 다른 데이터 센터는 대기 측으로 지정됩니다. 예를 들어 인스턴스가 DC1 및 DC2 데이터 센터에 구성되어 있고 DC1을 활성 쪽으로 할 수 있습니다.

    StreamConnect, LES 또는 IDR이 활성화되면 새로운 Hermes Kafka 클러스터가 두 데이터 센터 모두에서 프로비저닝됩니다. 고가용성을 보장하고 페일오버 지원을 제공하기 위해 Hermes는 각 데이터 센터에 하나씩 한 쌍의 활성/활성 Kafka 클러스터를 사용합니다.

    근접 클러스터
    인스턴스와 동일한 데이터 센터에 있는 Hermes Kafka 클러스터는 니어 클러스터입니다.
    원거리 클러스터
    다른 데이터 센터에서 실행되는 클러스터는 멀리 클러스터입니다. 다른 경우에는 그 반대입니다. 가까운 클러스터는 데이터 센터에 있고 먼 클러스터는 다른 데이터 센터에서 실행되고 있습니다.
    그림 1. 근거리 및 원거리 Hermes Kafka 클러스터
    가까운 곳과 먼 거리의 Hermes Kafka 클러스터는 인스턴스를 기준으로 합니다.

    정상 작동

    정상 작동 조건에서 메시지는 인스턴스 또는 외부 클라이언트에 의해 가까운 Hermes 클러스터로 생성됩니다. 예를 들어 인스턴스가 DC1 데이터 센터에서 실행 중인 경우 DC1의 가까운 Hermes 클러스터로 메시지가 생성됩니다. 외부 클라이언트에서 보낸 메시지는 생성자 부트스트랩 URL에 정의된 400x 범위의 포트를 사용하여 클러스터로 생성됩니다.

    Hermes에서 주제가 생성되면 두 클러스터 모두에 생성됩니다. 두 클러스터의 메시지를 소비하는 데 두 개의 소비자 프로세스가 사용되지만 정상적인 상황에서는 단일 소비자만 적극적으로 소비합니다. 각 소비자는 410x 범위와 420x 범위의 고유한 부트스트랩 URL을 사용해야 합니다.

    페일오버 프로세스

    다음과 같은 상황에서는 메시지가 생성되는 클러스터가 변경될 수 있습니다.

    인스턴스 고급 고가용성(AHA) 이전
    인스턴스가 AHA 전송을 수행하면 대기 인스턴스는 활성 상태가 되고 이전 활성 인스턴스는 대기 인스턴스가 됩니다. 이 시나리오에서 인스턴스는 새로 활성화된 쪽에서 Hermes 클러스터를 사용하도록 전환됩니다.

    예를 들어 인스턴스가 DC1을 현재 활성 측으로 하여 DC1 및 DC2 데이터 센터에서 실행 중이고 AHA 전송이 발생하는 경우 인스턴스는 DC2의 Hermes 클러스터를 사용하도록 전환됩니다.

    Hermes 장애 조치
    인스턴스는 Hermes 클러스터의 상태를 적극적으로 모니터링합니다. 클러스터에서 문제를 발견하면 페일오버 모드로 전환됩니다. 이 경우 인스턴스는 근접 Hermes 클러스터가 복구되었음을 감지할 때까지 대기 인스턴스 근처의 Hermes 클러스터를 사용합니다.

    예를 들어 인스턴스가 DC1을 활성 쪽으로 사용하여 DC1 및 DC2 데이터 센터에서 실행되는 경우 DC1의 Hermes 클러스터를 사용합니다. DC1의 Hermes 클러스터에서 문제가 감지되면 Hermes 장애 조치(failover) 모드로 전환되고 DC1 클러스터가 다시 정상이 될 때까지 DC2 클러스터에 메시지를 생성하기 시작합니다. 복구 후 DC1의 Hermes 클러스터를 사용하여 다시 시작됩니다.

    장애 조치(failover)가 발생할 때 소비자가 지연되는 경우 소비자 중 한 명이 처리를 완료할 때까지 두 소비자 모두 잠재적으로 메시지를 사용할 수 있습니다. 예를 들어 현재 활성 쪽이 DC1인 경우 DC1에서 사용하는 소비자는 메시지를 적극적으로 처리하고 있습니다. DC1 클러스터에서 문제가 발생하여 DC2 클러스터로 장애 조치(failover)가 발생하는 경우 DC2 클러스터에서 사용하는 소비자가 메시지 처리를 시작합니다. DC1 클러스터에서 사용하는 소비자가 지연된 경우 두 소비자 모두 DC1 소비자가 따라잡을 때까지 메시지를 계속 사용합니다.

    질서 유지

    메시지 순서를 유지 관리해야 하는 경우 이를 관리하는 것은 소비자 응용 프로그램의 책임입니다. 메시지의 전역 순서는 Kafka의 주제가 정의되는 방식에 따라 달라집니다.