미러링 사용
미러링을 사용하면 하나의 Event Streams 서비스 인스턴스의 메시지를 두 번째 인스턴스에 지속적으로 복사할 수 있습니다. 첫 번째 서비스 인스턴스가 사용 불가능하게 되는 것처럼 미러링을 사용하여 애플리케이션 복원성을 개선할 수 있습니다. 애플리케이션은 두 번째 인스턴스에 다시 연결하고 정상 조작을 계속할 수 있습니다.
이 기능은 완전히 관리되는 서비스의 일부이며 Event Streams 엔터프라이즈 플랜을 사용하는 서비스 인스턴스 간에만 사용할 수 있습니다.
미러링 기능:
- 서로 다른 IBM Cloud 계정에서 프로비저닝될 수 있는 두 개의 Event Streams 서비스 인스턴스 간에 토픽, 메시지 데이터 및 이용자 그룹 오프셋을 미러링합니다.
- Event Streams 서비스와 일치하는 99.99% 가용성의 SLA.
- IBM Cloud® Monitoring을 사용하여 모니터할 수 있습니다.
미러링 제한사항:
- 단방향: 서비스 인스턴스 쌍 사이에서 한 번에 한 방향으로만 데이터를 미러링할 수 있습니다. 이는 미러링이 "활성-활성" 이 아닌 "활성-수동" 스타일의 고가용성을 제공함을 의미합니다.
- 비동기: 메시지를 대상 인스턴스로 미러링하기 전에 소스 인스턴스에 메시지를 성공적으로 생성해야 합니다. 즉, 장애가 발생하면 복제 지연으로 인해 대상 클러스터에 장애가 발생한 정확한 지점까지의 모든 메시지가 없을 수 있으며 일부 메시지 데이터가 손실될 수 있습니다.
- 한 번 이상 메시지 이용: 이용자가 인스턴스 간에 이동할 때 이미 처리한 메시지를 다시 처리해야 할 수 있습니다.
미러링을 시작하기 전에 다음 사항을 고려하십시오.
- 미러링을 최대한 활용하기 위해 애플리케이션을 수정해야 할 수도 있습니다.
- 인스턴스 간에 데이터를 미러링하는 데 사용되는 네트워크 트래픽에 대해 사용 가능한 충분한 용량 이 있는지 확인하십시오.
미러링을 사용으로 설정하려면 미러링 설정 안내서를 참조하십시오.
미러링 개요
선택된 토픽의 미러링은 두 클러스터 간에 발생하며 단 방향입니다. 즉, 데이터는 단일 소스 클러스터에서 단일 대상 클러스터까지 한 방향으로 미러링됩니다. 각 클러스터에는 미러링 별명이 있습니다. 이 문서에서 A 는 소스 클러스터 별명으로 사용되고 B 는 대상 클러스터 별명으로 사용됩니다. 미러링이 사용으로 설정된 경우 별명을 구성할 수 있습니다. 예를 들어, 별명은 "us-south"
및 "us-east" 일 수 있습니다.
소스 클러스터(A)의 mytopic 라는 토픽은 대상 클러스터(B)에 mytopic.A 로 표시되어 A 에서 시작되었음을 나타냅니다. 이러한 유형의 토픽은 원격(소스) 클러스터에서 시작되므로 원격 토픽이라고 합니다. 이와 반대로 사용자가 대상 클러스터에서 직접 만든 토픽을 로컬 토픽이라고 합니다.
어떤 주제를 미러링할지 선택하려면 미러링 사용자 컨트롤을 사용하여 정규 표현식 패턴을 구성할 수 있습니다.
미러링은 소스 및 대상 인스턴스 간에 이용자 오프셋을 자동으로 변환합니다. Event Streams의 이전 버전에서 이용자는 A.checkpoints.internal 라는 특수 토픽을 사용해야 했습니다 (여기서 A 는 소스 클러스터의 별명임). 이는 더 이상 필요하지 않지만 체크포인트 주제는 기존 애플리케이션과의 역호환성을 위해 미러링 프로세스에 의해 계속 작성되고 업데이트됩니다.
체크포인트 주제를 사용하려는 애플리케이션은 Kafka MirrorClient 를 사용하여 이 주제에 보유된 데이터에 대한 액세스를 단순화할 수 있습니다.
마지막으로, 원격 토픽의 이름 지정으로 인해 다음과 같습니다.
- Kafka 리소스 이름의 일부로 클러스터 별명을 사용하지 마십시오.
- 원격 토픽 이름 (예: 소스 토픽 및 소스 클러스터 별명) 이 Kafka 토픽의 길이 한계 (249자) 를 초과하지 않는지 확인하십시오. 리모트 토픽 이름이 이 한계를 초과하면 토픽에 대한 메시지가 미러링되지 않습니다.
용량 계획
용량을 계획할 때는 소스 및 대상 서비스 인스턴스의 네트워크 사용량과 지리적 위치를 모두 고려해야 합니다.
네트워크 대역폭
선택한 토픽을 미러링하는 데 필요한 네트워크 대역폭은 소스 및 대상 서비스 인스턴스의 대역폭 허용량에서 고려해야 합니다. 예를 들어 소스 서비스 인스턴스의 애플리케이션이 미러링된 토픽에 대해 10MB/s의 메시지 트래픽을 생성하는 경우, 이러한 메시지를 대상 인스턴스로 미러링하려면 추가로 10MB/s의 발신 대역폭이 필요합니다. 이는 소비 애플리케이션에서 이미 사용하고 있는 기존 발신 대역폭과 함께 허용되어야 합니다. 모니터링 대시보드는 서비스 인스턴스에서 네트워크 사용량을 결정하는 데 사용될 수 있습니다. 자세한 정보는 Event Streams 메트릭 모니터링을 참조하십시오.
지리적 위치
다른 네트워킹과 마찬가지로, 달성할 수 있는 최대 처리량은 데이터가 전송되는 거리의 요인입니다(증가하는 대기 시간 및 패킷 유실로 인해). 이는 소스 인스턴스와 대상 인스턴스 간에 달성할 수 있는 최대 처리량에 영향을 줍니다. 대상 서비스 인스턴스를 소스와 가능한 한 지리적으로 가까운 위치에 배치하세요.
다음 표는 150MB/s 용량의 소스 인스턴스에서 미러링할 때 달성 가능한 처리량에 대한 지침을 제공합니다.
| 지역 | 최대 파티션당 처리량 | 최대 총 처리량 |
|---|---|---|
| us-south <-> us-east | 1.5MB/초 | 35MB/초 |
| eu-gb <-> eu-de | 2.5MB/초 | 35MB/초 |
| au-syd <-> jp-tok | 0.4MB/초 | 12MB/초 |
| 같은 지역 내 eu-gb <-> eu-gb | 2.5MB/초 | 35MB/초 |
다음 수가 표시됩니다.
- 최대 총 처리량: 선택된 모든 토픽에서 미러링될 수 있는 최대 총 MB/초입니다.
- 최대 파티션당 처리량: 단일 파티션 내에서 미러링될 수 있는 최대 MB/초입니다. 파티션당 로드가 이 한계 내에 남아 있도록 소스 주제에 대해 구성된 파티션 수를 선택하십시오.
제한을 초과하면 소스 인스턴스와 대상 인스턴스의 데이터 간에 지연이 증가합니다. 데이터 래그가 크면 소스 인스턴스가 실패하는 경우 더 많은 양의 메시지 데이터가 유실될 수 있습니다. 인스턴스 간의 지연이 0인 경우에도 미러링이 비동기이므로 소스 인스턴스가 실패하면 일부 데이터가 유실될 수 있습니다. 모니터링 대시보드는 각 토픽에 대한 대기 시간을 결정하는 데 사용될 수 있습니다. 자세한 정보는 미러링 모니터링을 참조하십시오.
달성 가능한 처리량에 대한 지침은 50개의 토픽 파티션에서 생성된 100K 메시지를 사용하여 생성되었습니다. 워크로드가 더 작은 메시지 크기 (예: 1K에서) 또는 더 적은 파티션을 사용하는 경우, 미러링은 이러한 처리량 레벨을 달성하지 못할 수 있습니다.
중복되는 대상 토픽 삭제
대상 인스턴스에서 실수로 데이터를 삭제하지 않도록 하기 위해 토픽이 소스에서 삭제되면 대상 인스턴스에서 자동으로 삭제되지 않습니다. 대상 인스턴스에서 토픽을 삭제하는 것은 사용자의 책임입니다. 미러링된 주제가 자주 삭제되고 작성되는 경우 대상 클러스터에서 더 많은 디스크 및 파티션 허용량을 사용할 수 있습니다. 대상 클러스터의 모니터링 대시보드를 사용하여 사용량을 모니터할 수 있습니다. Event Streams 메트릭 모니터링 을 참조하십시오. CLI, UI 또는 관리 인터페이스를 사용하여 더 이상 필요하지 않은 주제를 삭제할 수 있습니다.
미러링을 위한 IAM 액세스 정책
애플리케이션은 소스 및 대상 클러스터에 대한 액세스가 필요하므로 두 클러스터 모두에 IAM 액세스 정책을 설정해야 하며, 정책이 첨부된 서비스 ID의 API 키를 사용해야 합니다. IAM 와일드카드 지정 기능(와일드카드 정책을 사용하여 액세스 권한 지정)을 사용하여 미러링된 리소스에 대한 액세스를 제어하는 액세스 정책을 간소화할 수 있습니다.
IAM 액세스 정책을 처음 사용하는 경우 자세한 정보는 IBM Cloud IAM 작동 방법 및 Event Streams 인스턴스에 대한 인증 관리 를 참조하십시오.
두 클러스터에 다음 IAM 액세스 정책을 정의합니다. 여기서
A.checkpoints.internal 입니다.
| 리소스 유형 | 리소스 ID | 역할 |
|---|---|---|
| 클러스터 | 독자 | |
| 그룹 | <RESOURCE_NAME>.* | 애플리케이션에서 요청한 대로 |
| topic | <RESOURCE_NAME>.* | 애플리케이션에서 요청한 대로 |
| txnid | <RESOURCE_NAME>.* | 애플리케이션에서 요청한 대로 |
| 주제 (체크포인트 주제에 특정) |
|
독자 |
개별 애플리케이션에 세분화된 액세스 정책을 부여하십시오. 예를 들어, 단순히 이용하는 애플리케이션의 경우 독자 권한만 부여하십시오.
사용자 컨트롤을 미러링하려면 대상 클러스터에 대해 다음 권한이 있어야 합니다.
| 리소스 유형 | 리소스 ID | 역할 |
|---|---|---|
| 클러스터 | 관리자 |
미러링을 통한 컨텍스트 기반 제한 및 네트워크 보안 제어
미러링은 대상 클러스터가 연결을 시작하여 소스 클러스터에서 데이터를 가져오는 풀 기반 모델을 따릅니다. 미러링의 이 풀 기반 모델은 소스 클러스터에서 네트워크 제어를 적용하여 권한이 있는 대상 클러스터만 소스 클러스터의 데이터에 액세스할 수 있도록 합니다.
CBR(컨텍스트 기반 제한) 또는 CSE 허용 목록과 같은 네트워크 보안 제어가 활성화된 경우, 대상 클러스터의 미러링 포드 IP를 포함하는 서비스 엔드포인트 허용 목록을 소스 클러스터에 추가하여 네트워크 및 보안 ID 수준의 보안 경로를 정의합니다. 이 설정은 인프라 수준에서 세분화된 액세스 제어를 적용하여 권한이 부여된 미러링 엔드포인트(대상 클러스터)만 소스 클러스터에서 데이터를 가져올 수 있도록 합니다.
소스 클러스터와 대상 클러스터 간에 공유되는 자격 증명은 미러링 프로세스에만 사용되며 Event Streams 배포 간에 다른 리소스에 대한 액세스 권한을 부여하지 않습니다. 즉, 미러링 프로세스가 격리되고 안전하므로 다른 리소스에 대한 무단 액세스를 방지할 수 있습니다.
미러링 설정 전에 이러한 네트워크 보안 제어를 활성화해야 합니다. 미러링 설정 후 컨텍스트 기반 제한이 적용되면 클러스터가 업데이트될 때까지 미러링이 시작되지 않습니다.
미러링 후 CBR이 활성화된 경우:
- 지원 티켓을 올리세요.
- 변경 사항이 적용되려면 다음 클러스터 업데이트 주기(최소 24시간)까지 기다려야 합니다.
- 미러 노드 주소를 CBR 규칙에 포함하세요.
- 대상 클러스터에서 미러링을 비활성화했다가 다시 활성화합니다.
여러 엔터티 간에 클러스터를 공유할 때 고려할 사항
서로 다른 사업부 등 여러 개체가 인스턴스를 공유하여 서로 격리해야 하는 경우, 미러링된 클러스터의 관리 및 운영을 간소화하기 위해 이름 지정 지침을 따르세요.
다음 템플리트를 사용하여 Kafka 자원의 이름을 지정하십시오. <ENTITY_PREFIX>
여기서:
- < ENTITY_PREFIX>는 이 주제를 사용하는 엔티티의 접두부입니다.
-
는 엔티티와 리소스 이름을 쉽게 구분하는 데 사용되는 선택적 문자입니다. -
은 Kafka 리소스의 이름입니다.
예를 들어 회계 사업부에 송장이라는 주제가 필요한 경우 accounting.invoices 이라고 부를 수 있습니다.
필요한 액세스 정책은 조정되어야 합니다. 예를 들어, 회계 비즈니스 단위의 경우 다음 정책이 클러스터 B에 필요합니다.
| 리소스 유형 | 리소스 ID | 역할 |
|---|---|---|
| 클러스터 | 독자 | |
| 그룹 | accounting.* | 애플리케이션에서 요청한 대로 |
| topic | accounting.* | 애플리케이션에서 요청한 대로 |
| txnid | accounting.* | 애플리케이션에서 요청한 대로 |
| topic(참고: 체크포인트 토픽에 특정함) | A.checkpoints.internal | 독자 |
클러스터 A는 B.checkpoints.internal 에 있어야 하는 마지막 액세스 정책을 제외하고 동일한 액세스 정책을 가져야 합니다.
미러링 사용자 제어
CLI 또는 Administration REST API 를 사용하여 미러링을 구성할 수 있습니다. 모든 미러링 사용자 제어는 대상 클러스터에서 수행됩니다.
토픽 선택사항 설정
미러링 선택은 정규식(정규식) 패턴을 사용하여 소스 클러스터의 토픽 이름을 기반으로 이루어집니다. 여러 엔티티 간에 클러스터를 공유할 때의 고려사항 섹션의 조언을 고려하여 소스 클러스터의 토픽 이름을 신중하게 선택하십시오.
동일한 그룹 또는 애플리케이션의 일부인 토픽에 접두부를 추가하는 것과 같이 잘 구조화된 토픽 이름을 사용하면 미러링을 쉽게 제어할 수 있습니다. 이러한 명명 규칙을 적용하면 향후 이 패턴과 일치하는 모든 토픽이 추가 변경 없이 자동으로 반영됩니다.
주제 선택은 하나 이상의 정규식 패턴 목록의 형태로 제공됩니다. 목록의 패턴과 일치하는 경우 주제가 선택됩니다.
미러링을 위해 토픽을 선택하는 몇 가지 패턴 예는 다음과 같습니다.
| 패턴 예 | 설명 |
|---|---|
^topic1$ |
전체 토픽 이름입니다. 이는 topic1 라는 단일 토픽과만 일치합니다. |
^topic1$,^topic2$ |
전체 주제 이름과 일치하는 패턴 목록입니다. 이는 topic1 및 topic2 라는 두 개의 주제와 일치합니다. |
^aaa.* |
접두부와 일치합니다. 이는 aaa 로 시작하는 토픽 이름과 일치합니다. |
^aaa.*,^bbb.* |
접두부에서 일치하는 패턴의 목록입니다. 이는 aaa 또는 bbb 로 시작하는 토픽 이름과 일치합니다. |
^branch_[0-9]{3}_[a-z]*$ |
토픽 이름과 일치시키기 위해 더욱 복잡한 정규식 패턴입니다. 이는 branch_ 로 시작하고 그 뒤에 정확히 3자리숫자, _ 및 임의 수의 소문자가 오는 토픽 이름과 일치합니다. |
.* |
모든 소스 토픽을 미러링합니다. |
CLI를 사용할 때 패턴은 쉼표로 구분된 목록으로 제공됩니다. 예를 들어, 다음 명령은 이름에 접두부 accounting 또는 hr 가 있는 모든 주제를 선택합니다.
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
다음 명령은 관리 REST API를 사용하여 동일하게 선택하는 방법을 표시합니다. 패턴은 "includes" 라는 JSON 배열 양식입니다.
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^accounting.*", "^hr.*"]}'
주제 선택을 업데이트하면 현재 패턴 세트가 대체됩니다.
주제가 미러링되지 않도록 선택사항을 제거하려면 다음과 같이 CLI와 함께 --none 옵션을 사용하거나 관리 REST API와 함께 비어 있는 패턴을 사용하십시오.
ibmcloud es mirroring-topic-selection-set --none
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":[""]}'
미러링을 선택적으로 비활성화하려면 비활성화하려는 패턴을 제외하고 주제 선택을 다시 적용하세요. 예를 들어 topic1, topic2, topic3 가 현재 미러링 중인 경우 다음 명령은 topic2 에 대한 미러링을 비활성화하지만 나머지 두 개는 활성화된 상태로 유지합니다.
ibmcloud es mirroring-topic-selection-set --select '^topic1$,^topic3$'
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^topic1$","^topic3$"]}'
토픽 선택사항 검색
다음 인터페이스를 사용하여 미러링 선택 항목을 검색할 수 있습니다:
CLI:
ibmcloud es mirroring-topic-selection
REST API:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
활성 토픽 검색
다음 인터페이스를 사용하여 활발하게 미러링 중인 토픽을 검색할 수 있습니다:
CLI:
ibmcloud es mirroring-active-topics
REST API:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
미러링 인식 애플리케이션 빌드
생성자
생산자는 로컬 주제만 생성하는 것이 좋습니다. 인스턴스 간에 생성자를 전환하려면 일반적으로 생성자가 올바른 엔드포인트 및 신임 정보를 사용하여 연결할 수 있도록 구성을 변경해야 합니다.
이용자
이용자는 로컬 및 원격 토픽 모두 구독하고 이들로부터 이용해야 합니다. 이는 와일드카드가 지정된 구독을 사용하여 수행될 수 있습니다. 예를 들어, accounting.invoice 및 accounting.invoice.<ALIAS> 둘 다에서 이용하려면 accounting.invoice.*에 대한 구독을 사용하십시오.
로컬 및 원격 토픽을 모두 이용하는 경우 애플리케이션에 엄격한 순서 지정이 필요한지 확인하십시오. 이 경우 원격 토픽을 먼저 완전히 소비한 후 로컬 토픽에서 소비를 시작해야 합니다. 이러한 방법으로 메시지는 생성된 순서로 처리됩니다.
이용자 오프셋
두 인스턴스 간에 메시지 데이터가 미러링되는 경우 소스 인스턴스의 메시지에 지정된 오프셋이 대상 인스턴스에서 사용된 오프셋과 일치하지 않을 수 있는 여러 가지 이유가 있습니다. 예를 들어, 다음과 같습니다.
- 소스 인스턴스에서 동일한 이름의 토픽을 삭제하고 다시 작성합니다.
- 압축 정리 정책을 사용하여 주제를 미러링합니다.
- 트랜잭션을 사용하여 메시지 생성.
메시지 미러링 프로세스의 일부는 소스 인스턴스의 어떤 오프셋이 대상 인스턴스의 어떤 오프셋과 동등한지 추적합니다. 효율성을 위해 적은 수의 동등한 오프셋만 추적되며 토픽의 헤드 근처 위치가 선호됩니다. 소스 인스턴스의 이용자 그룹에 대해 오프셋이 커미트되면 대상 인스턴스의 가장 가까운 동등한 오프셋으로 변환되고 대상 인스턴스의 그룹에 대해 해당 오프셋이 커미트됩니다. 이 변환은 대상 클러스터로 전환하는 이용자가 미러링된 메시지를 건너뛰지 않도록 하기 위한 것입니다. 그러나 모든 동등한 오프셋이 미러링 프로세스에 의해 추적되는 것은 아니므로 이용자가 대상 인스턴스로 전환할 때 소스 인스턴스에서 이미 이용된 데이터를 재처리할 수 있습니다.
오프셋을 커미트하여 이용자 진행상태를 추적하는 애플리케이션을 작성할 때 다음을 고려하십시오.
- 이용자 오프셋은 해당 이용자 그룹이 대상 인스턴스에서 활성으로 사용되지 않는 경우에만 미러링됩니다.
- 이용자가 대상 인스턴스로 이동할 때 일부 메시지 데이터를 재처리할 것으로 예상됩니다.
- 대상 인스턴스로 이동할 때 이용자가 토픽의 헤드 뒤에 있을수록 잠재적으로 재이용해야 하는 데이터가 많아집니다.
- 재사용되는 데이터의 양을 최소화하고 인스턴스 간의 전환 애플리케이션을 주의깊게 관리할 수 있는 경우 이를 수행하기 위해 권장되는 단계 세트는 다음과 같습니다.
- 소스 인스턴스에 대한 메시지 생성을 중지합니다.
- 이용자가 토픽의 헤드를 따라잡을 때까지 기다리십시오.
- 이 위치에서 오프셋을 커미트합니다.
- 이용자를 대상 인스턴스로 전환하십시오.
미러링 모니터링
IBM Cloud Monitoring 을 사용하여 미러링을 모니터링할 수 있습니다. 모니터링을 사용으로 설정하려면 Event Streams 메트릭 모니터링을 참조하십시오. 모니터링 대시보드는 대상 클러스터에서 사용할 수 있습니다.
Event Streams 미러링 대시보드는 다음 메트릭을 표시합니다.
- 미러링 처리량: 소스 Event Streams 인스턴스에서 발생한 미러링 처리량의 초당 바이트입니다. 이는 미러링이 활성화되어 있는지 확인하고 용량 계획을 세우는 데 유용합니다.
- 미러링 대기 시간: 소스 Event Streams 인스턴스에서 발생한 토픽당 미러링 대기 시간(초)입니다. 대상 클러스터의 토픽이 얼마나 늦어지는지 판별하는 데 유용합니다.
지연 시간 내에 생성된 데이터는 대상 클러스터에 아직 존재하지 않을 수 있으며, 원본 클러스터에서 재해가 발생하면 손실될 수 있습니다. 그러나 미러링이 최신 상태이면 두 클러스터가 정상 상태로 유지되는 동안 데이터 유실 없이 장애 복구를 수행할 수 있습니다.
미러링으로 복구 목표 이해
미러링과 같은 데이터 보호 플랜에서 복구 지점 목표(RPO)와 복구 시간 목표(RTO)는 주요 매개변수입니다. 이러한 목표와 관련된 결정을 이해해야 합니다.
미러링 대시보드에서 제공되는 미러링 대기 시간 메트릭을 사용하여 복구 지점 목표를 모니터링할 수 있습니다. 이 지표는 두 클러스터 간의 지연을 표시하므로 재해가 발생하는 경우 데이터 손실의 양을 추정할 수 있습니다. 귀하는 해당 값을 모니터링하고 RPO에 맞는지 확인할 책임이 있습니다.
복구 시간 목표는 사용자가 완전히 제어하고 다음 시간 창으로 작성됩니다.
- 사용자가 장애 조치를 결정하기까지 걸리는 시간입니다.
- 사용자가 애플리케이션을 장애 조치하는 데 걸리는 시간입니다.
테스트
애플리케이션 미러링이 인식되도록 할 때 장애 복구 및 복구를 테스트하십시오. 재해 복구 예제 시나리오 에 설명된 단계를 완료하고 모니터링 대시보드를 사용하여 모든 단계가 예상대로 완료되었는지 확인하십시오.
소스 클러스터에서 같은 이름의 토픽 삭제 및 다시 만들기
소스 클러스터에서 토픽이 삭제되면 대상 클러스터의 해당 토픽은 자동으로 삭제되지 않습니다. 그 후에 소스 클러스터에서 토픽을 다시 작성하는 경우 소스 클러스터에 있는 새 토픽의 데이터가 대상 클러스터에 있는 기존 토픽의 끝에 추가됩니다.
Kafka Streams 및 Kafka Connect에 대한 고려사항
Kafka Streams 및 Kafka Connect는 상태 및 구성을 저장하기 위해 특정 이름이 사용된 내부 토픽에 의존합니다. 이러한 토픽이 미러링되면 대상 클러스터에서 이름이 바뀝니다. 따라서 Kafka Streams 및 Kafka Connect 애플리케이션은 클러스터 간에 장애 조치 및 장애 복구가 불가능합니다. 이러한 애플리케이션의 재해 복구를 계획할 때 이를 고려하십시오.