Event Streams 에 대한 FAQ
이 문서에는 IBM® Event Streams for IBM Cloud® 서비스 이용자들이 흔히 겪는 질문이나 문제에 대한 정보가 포함되어 있습니다. 지원 티켓을 생성하지 않고도 문제를 해결하는 방법에 대한 지시사항을 제공하거나 질문에 답하는 것이 이 문서의 목표입니다.
토픽 작성 및 삭제를 위해 Kafka API를 사용하는 방법
0.11 이상에서 Kafka 클라이언트를 사용 중이거나 0.10.2.0 이상에서 Kafka Streams를 사용 중인 경우, API를 사용하여 토픽을 작성하고 삭제할 수 있습니다. 토픽 작성 시 허용되는 설정에 대한 제한사항이 있습니다. 현재는 다음 설정만 수정할 수 있습니다.
- cleanup.policy
-
delete(기본값),compact또는delete,compact(으)로 설정 - retention.ms
-
기본 보존 기간은 24시간입니다. 최소 1시간이며 최대 30일입니다. 이 값을 시간 배수로 지정하십시오.
참고: 엔터프라이즈 플랜에서는 임의 값으로 설정할 수 있습니다.
- retention.bytes
-
이전 로그 세그먼트를 삭제하여 여유 공간을 확보하기 전에 최대 파티션의 크기(로그 세그먼트로 구성됨)는 늘어날 수 있습니다.
참고: 엔터프라이즈: 100KiB - 2TiB의 값으로 설정하십시오. 표준: 100KiB - 1GiB의 값으로 설정하십시오.
- segment.bytes
-
로그를 위한 세그먼트 파일 크기입니다.
참고: 엔터프라이즈: 100KiB - 2TiB의 값으로 설정하십시오. 표준: 100KiB - 512MiB의 값으로 설정하십시오.
- segment.index.bytes
-
오프셋을 파일 위치로 맵핑하는 인덱스의 크기입니다.
참고: 엔터프라이즈: 100KiB - 1TiB의 값으로 설정하십시오. 표준: 100KiB - 100MiB의 값으로 설정하십시오.
- segment.ms
-
이 기간이 지나면 세그먼트 파일이 가득 차지 않아도 Kafka에서 로그가 롤링하도록 강제 실행하게 되는 기간입니다.
참고: 5분 - 30일의 값으로 설정하십시오.
기본값 설정의 다음 예제를 참조하십시오.
Details for topic testit
Topic name Internal? Partition count Replication factor
testit false 1 3
Partition details for topic testit
Partition ID Leader Replicas In-sync
0 1 [1 5 0] [1 5 0]
Configuration parameters for topic testit
Name Value
cleanup.policy delete
min.insync.replicas 2
segment.bytes 536870912
retention.ms 86400000
segment.ms 604800000
retention.bytes 1073741824
segment.index.bytes 10485760
Event Streams에서 이용자 오프셋 토픽의 로그 보존 기간으로 설정하는 기간
Event Streams에서는 이용자 오프셋을 7일 동안 보존합니다. 이는 Kafka 구성 offsets.retention.minutes에 해당됩니다.
오프셋 보존은 시스템 전체에 해당하므로 개별 토픽 레벨에서 설정할 수 없습니다. 모든 이용자 그룹은 토픽의 로그 보존이 최대 30일로 늘어났더라도 저장된 오프셋의 기간은 7일 동안만 가능합니다.
엔터프라이즈 플랜에서 내부 Kafka __consumer_offsets 토픽은 읽기 전용으로 사용자에게 표시됩니다. 어떠한 방식으로도 토픽 관리를 시도하지 않는 것이 좋습니다. 표준 플랜에서는 어떤 방법으로도 __consumer_offsets 토픽에 액세스할 수 없습니다.
이용자가 없는 이용자 그룹을 정리하는 방법은 무엇입니까?
이용자가 떠나면 오프셋이 있는 경우에만 그룹이 계속 존재합니다. 7일 동안 비활성 상태이면 이용자 오프셋이 삭제됩니다. 따라서 이 그룹에서 마지막으로 커미트된 오프셋이 만료되면 이용자 그룹이 삭제됩니다.
선택한 그룹을 한 번에 명시적으로 삭제하려면, deleteConsumerGroups()API 또는 ibmcloud es group-delete 명령을 사용할 수 있습니다
메시지가 얼마 동안 보존됩니까?
기본적으로 메시지는 Kafka에서 각 파티션당 최대 1GB까지 최대 24시간 동안 보존됩니다. 1GB 한계에 도달하면 한계를 넘지 않도록 가장 오래된 메시지가 삭제됩니다.
사용자 인터페이스 또는 관리 API 중 하나를 사용하여 토픽을 작성할 때 메시지 보유에 대한 시간 한계를 변경할 수 있습니다. 시간 한계는 최소 1시간이며 최대 30일입니다.
Kafka 클라이언트 또는 Kafka Streams를 사용하여 토픽을 작성할 때 허용되는 설정의 제한사항에 대한 정보는 토픽 작성 및 삭제를 위해 Kafka API를 사용하는 방법을 참조하십시오.
Event Streams의 가용성 작동은 무엇입니까?
Event Streams 앱을 작성하는 경우, 이 정보를 사용하여 보통 Event Streams 가용성 작동이 무엇이며 사용자의 앱에서 무엇을 처리해야 하는지 이해하십시오.
API
Event Streams의 일반 오퍼레이션의 일부로서 Kafka 클러스터의 노드가 가끔씩 다시 시작됩니다. 어떤 경우에는 클러스터가 리소스를 재지정하면 사용자의 앱이 인식하게 됩니다. 이러한 변경사항에 복원력이 있으며 다시 연결해서 오퍼레이션을 재시도할 수 있도록 앱을 작성하십시오.
Event Streams의 최대 메시지 크기는 얼마입니까?
Event Streams의 최대 메시지 크기는 1MB이며 이는 Kafka의 기본값입니다.
Event Streams의 복제 설정은 무엇입니까?
Event Streams는 높은 가용성과 지속성을 제공하도록 구성되어 있습니다. 다음 구성 설정은 모든 토픽에 적용되며 변경될 수 없습니다.
- replication.factor = 3
- min.insync.replicas = 2
토픽 및 파티션에 대한 제한사항과 기본값은 무엇입니까?
- 토픽 이름은 최대 200자로 제한됩니다.
- 토픽의 기본 파티션 수는 하나입니다.
- 각 IBM Cloud 영역에는 파티션의 수가 100개로 제한됩니다. 더 많은 파티션을 작성하려면, 새 IBM Cloud 영역을 사용해야 합니다.
프로비저닝한 Event Streams 플랜을 확인하는 방법은 무엇입니까?
프로비저닝한 Event Streams 플랜 유형(Lite, 표준 또는 엔터프라이즈)을 확인하려면 다음 단계를 완료하십시오.
- IBM Cloud 콘솔에서 확인할 Event Streams의 인스턴스로 이동하십시오.
- 왼쪽의 탐색 분할창에서 플랜 탭을 클릭하십시오. 현재 플랜 섹션에는 플랜 유형이 표시됩니다.
Event Streams 콘솔을 사용하여 내 IBM Cloud 플랜을 변경할 수 있습니까?
예, 하지만 Lite 플랜에서 표준 플랜으로 변경하는 경우에만 해당됩니다.
-
IBM Cloud 콘솔에서 변경할 Event Streams Lite 플랜의 인스턴스로 이동하십시오.
-
왼쪽의 탐색 분할창에서 플랜 탭을 클릭하십시오.
-
가격 플랜 변경 섹션에서 표준 상자를 선택하십시오. 업그레이드를 클릭하십시오.
표준 플랜의 100개 파티션 한계를 활용할 수 있도록 Lite 파티션의 캐시된 1개 파티션 한계가 지워질 때까지 몇 분 정도 기다리십시오.
하지만 이 옵션은 현재 다른 플랜 조합에 대해 IBM Cloud 콘솔에서 작동하지 않습니다. 예를 들어, 다른 플랜 조합을 시도하면 다음과 같은 오류 메시지가 표시됩니다
Could not find VCAP::CloudController::ServicePlan with guid: ibm.eventstreams.standard
Event Streams 표준 플랜과 Event Streams 엔터프라이즈 플랜의 차이점은 무엇입니까?
여러 Event Streams 플랜에 대한 자세한 정보를 알아보려면 플랜 선택을 참조하십시오.
재해 복구는 어떻게 수행해야 합니까?
현재 Event Streams 재해 복구 관리는 사용자 본인의 책임입니다. Event Streams 데이터는 한 위치(지역)의 Event Streams 인스턴스와 다른 위치의 다른 인스턴스 간에 복제될 수 있습니다. 그러나 원격 Event Streams 인스턴스를 제공하고 복제를 관리하는 것은 사용자의 책임입니다.
클러스터 간에 데이터를 복제하려면 Kafka MirrorMaker와 같은 도구를 사용하는 것이 좋습니다. MirrorMaker를 실행하는 방법에 대한 정보는 다음을 참조하십시오. Event Streams kafka-mirrormaker 저장소. 복구 프로세스의 예는 재해 복구 시나리오에서 미러링 사용 을 참조하십시오.
사용자는 메시지 페이로드 데이터의 백업 또한 책임져야 합니다. 이 데이터는 클러스터 내의 여러 Kafka 브로커에 복제(따라서 대부분의 장애 발생 상황에 대한 보호를 제공함)되지만, 이러한 복제 방법이 위치 단위 장애에 대한 보호까지 제공하지는 않습니다. 사용자가 주제 이름과 해당 주제에 대한 구성 데이터를 백업하는 것이 좋습니다.
다중 구역 지역에서 Event Streams 인스턴스를 구성한 경우에는 지역적 장애가 발생할 가능성이 거의 없습니다. 하지만 사용자는 이러한 상황에 대비하는 것이 좋습니다. 장애(및 원격 DR 인스턴스가 아직 설정되지 않음)로 인해 사용자의 인스턴스를 더 이상 사용할 수 없는 경우, 사용자는 새 지역에 새 인스턴스를 구성하고 사용 가능한 경우 토픽과 데이터를 백업으로부터 복원하는 것을 고려해야 합니다. 그러면 애플리케이션을 새 인스턴스에 지정할 수 있습니다.