[Hyperledger Fabric v1.1] 4. Operations Guides: Bringing up a Kafka-based Ordering Service

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release-1.1/kafka.html

Bringing up a Kafka-based Ordering Service

Caveat emptor

이 문서는 독자가 일반적으로 Kafka 클러스터와 ZooKeeper 앙상블을 설정하는 방법을 알고 있다고 가정합니다. 이 가이드의 목적은 Hyperledger Fabric ordering 서비스 노드 세트(OSNs)가 Kafka 클러스터를 사용하고 블록 체인 네트워크에 ordering 서비스를 제공하기 위해 취해야 할 단계를 식별하는 것입니다.

Big picture

각 채널은 Kafka의 별도의 단일 파티션 주제에 매핑됩니다. OSN이 Broadcast RPC 를 통해 트랜잭션을 수신 하면 브로드캐스트 클라이언트가 채널에 쓸 수 있는 권한이 있는지 확인한 다음 해당 트랜잭션을 카프카의 적절한 파티션으로 중계합니다. 이 파티션은 수신된 트랜잭션을 로컬 블록으로 그룹화하고 로컬 원장에서 이를 유지하며 Deliver RPC를 통해 클라이언트를 수신하는 OSN에 의해 ​​소비됩니다. 저수준에 대한 자세한 내용은 describes how we came to this design 문서를 참조하십시오. 그림 8은 위에 설명 된 프로세스의 개략적인 표현입니다.

Steps

K와 Z 를 Kafka 클러스터와 ZooKeeper 앙상블의 노드 수로 각각 설정합니다. :

1. K는 최소한 4로 설정해야합니다 (아래 4 단계에서 설명 하겠지만, 이것은 고장 내결함성을 나타내기 위해 필요한 노드의 최소 수입니다. 즉, 4 개의 브로커를 사용하면 1 개의 브로커가 다운 될 수 있습니다. 채널은 계속해서 쓰기 및 읽기가 가능하며 새로운 채널을 만들 수 있습니다.)
2. Z는 3, 5 또는 7 중 하나입니다. 스플릿 브레이브 시나리오를 피하기 위해서는 홀수이어야하며 단일 실패 지점을 피하려면 1보다 커야합니다. 7 개의 ZooKeeper 서버를 초과하는 것은 과잉으로 간주됩니다.

그런 다음 다음과 같이 진행하십시오.

1. 주문자 : 네트워크의 기원 블록(genesis block)에 카프카 관련 정보를 암호화하십시오. configtxgen을 사용중인 경우 configtx.yaml을 편집하거나 시스템 채널의 기원 블록(genesis block)에 대한 사전 설정된 프로필을 선택하여 다음과 같이하십시오.
   1. Orderer.OrdererType은 kafka로 설정됩니다.
   2. Orderer.Kafka.Brokers에는 클러스터에 있는 두 개 이상의 Kafka 중개인의 주소가 IP:port으로 들어있습니다. 이 목록은 완전 할 필요는 없습니다. (이들은 부트 스트랩 브로커입니다.)
2. Orderers : 최대 블록 크기를 설정하십시오. 각 블록에는 대부분 Orderer.AbsoluteMaxBytes 바이트(헤더 제외)가 있으며 configtx.yaml에 설정할 수 있습니다. 여기에서 선택한 값을 A로 지정하고 기록해 두십시오 - 6 단계에서 Kafka 중개인을 구성하는 방법에 영향을 줍니다.
3. Orderers : 기원 블록(genesis block)을 만듭니다. configtxgen을 사용합니다. 위의 3 단계와 4 단계에서 선택한 설정은 시스템 전체의 설정입니다. 즉, 모든 OSN에 대해 네트워크 전체에 적용됩니다. 기원 블록(genesis block)의 위치를 ​​기록하십시오.
4. Kafka 클러스터 : Kafka brokers를 적절하게 구성하십시오. 모든 카프카 중개인은 다음과 같은 키를 구성해야합니다.
   1. unclean.leader.election.enable = false - 데이터 일관성은 블록 체인 환경에서 핵심입니다. 동기화된 복제 세트 외부에서 채널 리더를 선택할 수 없거나 이전 리더가 생성한 오프셋을 덮어 쓸 위험이 있습니다. 결과적으로 orderer가 생산하는 블록 체인을 다시 작성합니다.
   2. min.insync.replicas = M -  1 < M < N와 같은 M 값을 선택하십시오(아래 default.replication.factor 참조). 데이터는 최소한 M개의 복제본에 기록 될 때 커밋된 것으로 간주됩니다 (동기화 후 동기화 된 것으로 간주되고 동기화 된 복제 집합 또는 ISR에 속함). 다른 경우, 쓰기 조작은 오류를 리턴합니다. 그때:
      1. 채널 데이터가 기록되는 N개까지의 N-M 복제본을 사용할 수 없게 되면 작업이 정상적으로 진행됩니다.
      2. 더 많은 복제본을 사용할 수 없게 되면 Kafka는 M의 ISR 집합을 유지할 수 없으므로 쓰기 허용을 중지합니다. 문제없이 작업을 읽습니다. 채널은 M개의 복제본이 동기화 될 때 채널에 다시 쓸 수 있게 됩니다.
   3. default.replication.factor = N - 여기서 N < K인 값 N을 선택합니다. N의 복제 인수는 각 채널이 N개의 브로커에 복제된 데이터를 갖게됨을 의미합니다. 이들은 채널의 ISR 세트 후보입니다. 위의 min.insync.replicas section에서 언급했듯이 모든 브로커가 항상 사용 가능해야하는 것은 아닙니다.  N 브로커보다 적으면 채널 생성을 진행할 수 없으므로 N을 K보다 반드시 작게 설정해야합니다. 따라서 N = K로 설정하는 경우 단일 브로커가 중단된다는 것은 블록 체인 네트워크에 새로운 채널을 만들 수 없다는 것을 의미합니다. ordering 서비스의 오류 방지 기능은 존재하지 않습니다. 위에서 설명한 것을 바탕으로, M과 N의 최소 허용 값은 각각 2, 3입니다. 이 구성은 앞으로 나아갈 새로운 채널을 생성하고 모든 채널이 계속 쓰기 가능하도록 합니다.
   4. message.max.bytes 및 replica.fetch.max.bytes는 위의 4단계의 Orderer.AbsoluteMaxBytes에서 선택한 A 값보다 큰 값으로 설정되어야합니다. 헤더를 설명할 버퍼를 추가하십시오. 1 MiB가 충분합니다. 다음 조건이 적용됩니다. : Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes  (완전성을 위해 message.max.bytes는 기본적으로 100 MiB로 설정되는 socket.request.max.bytes 값보다 작아야 하며, 100 MiB보다 큰 블록을 사용하려면 fabric/orderer/kafka/config.go에 있는 brokerConfig.Producer.MaxMessageBytes의 하드 코딩된 값을 수정하고 소스에서 이진 파일을 다시 작성해야 합니다. 이것은 권장되지 않습니다.)
   5. log.retention.ms = -1. ordering 서비스가 Kafka 로그의 가지 치기에 대한 지원을 추가 할 때까지는 시간 기반 보존을 비활성화하고 세그먼트가 만료되지 않도록해야합니다. (크기 기반 보존 - log.retention.bytes -는 본문 작성 시점에 Kafka에서는 기본적으로 비활성화되어 있으므로 명시적으로 설정할 필요가 없습니다.)
5. Orderers : 각 OSN을 기원 블록(genesis block)으로 향하게 하십시오. General.GenesisFile을 orderer.yaml에서 편집하여 위의 5 단계에서 생성된 기원 블록(genesis block)을 가리키도록 합니다. (그 동안 YAML 파일의 다른 모든 키가 적절하게 설정되었는지 확인하십시오.)
6. Orderers : 폴링 간격 및 타임 아웃을 조정합니다. (선택 단계.)
   1. orderer.yaml 파일의 Kafka.Retry 섹션을 사용하여 메타 데이터/제작자/고객 요청의 빈도와 소켓 시간 초과를 조정할 수 있습니다. (이들은 Kafka 제작자 또는 소비자에게 기대되는 모든 설정입니다.)
   2. 또한 새 채널이 생성되거나 기존 채널이 다시 로드 될 때 (orderer가 방금 다시 시작된 경우) orderer는 다음과 같은 방법으로 Kafka 클러스터와 상호 작용합니다.
      1. 채널에 해당하는 Kafka 파티션을위한 Kafka 제작자 (작성자)를 만듭니다.
      2. 해당 생성자를 사용하여 해당 파티션에 no-op CONNECT 메시지를 게시 합니다.
      3. 해당 파티션에 대한 Kafka 소비자 (판독기)를 만듭니다. 이러한 단계 중 하나라도 실패하면 반복되는 빈도를 조정할 수 있습니다. 구체적으로 그들은 Kafka.Retry.ShortInterval의 총합을 위해 Kafka.Retry.ShortInterval마다 다시 시도될 것이며, Kafka.Retry.LongInterval을 성공할 때까지 Kafka.Retry.LongTotal의 총합을 구하기 재시도합니다. 위의 모든 단계가 성공적으로 완료 될 때까지 orderer는 채널에 쓰거나 채널에서 읽을 수 없습니다.
7. SSL을 통해 통신할 수 있도록 OSN 및 Kafka 클러스터를 설정합니다. (옵션 단계이지만 적극 추천합니다.) 방정식의 Kafka 클러스터 측면에 대해서는 Confluent 가이드 문서를 참조하고 그에 따라 모든 OSN에서 Kafka.TLS의 키를 orderer.yaml로 설정하십시오.
8. ZooKeeper 앙상블, Kafka 클러스터, ordering 서비스 노드 순서로 노드를 가져옵니다.

Additional considerations

1. 기본 메시지 크기. 위의 4 단계 (Steps 섹션 참조)에서 Orderer.Batchsize.PreferredMaxBytes 키를 설정하여 원하는 블록 크기를 설정할 수도 있습니다. 상대적으로 작은 메시지를 처리 ​​할 때 Kafka는 높은 처리량을 제공합니다. 1 MiB보다 크지 않은 값을 목표로 삼는다.
2. 환경 변수를 사용하여 설정을 무시합니다. Fabric과 함께 제공되는 샘플 Kafka 및 Zookeeper Docker 이미지 (images/kafka 및 images/zookeeper 참조)를 사용하는 경우, 환경 변수를 사용하여 Kafka 브로커 또는 ZooKeeper 서버의 설정을 무시할 수 있습니다. 구성 키의 점을 밑줄로 바꾸십시오 - 예를 들어 KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false를 지정하면 unclean.leader.election.enable의 기본값을 무시할 수 있습니다. 로컬 구성에 대한 OSN에도 동일하게 적용됩니다 ( 즉, orderer.yaml에서 설정할 수 있는 항목). 예를 들어 ORDERER_KAFKA_RETRY_SHORTINTERVAL=1s이면 Orderer.Kafka.Retry.ShortInterval의 기본값을 재정의할 수 있습니다.

Kafka Protocol Version Compatibility

패브릭은 sarama 클라이언트 라이브러리와 공급 업체를 사용하여 Kafka 0.10에서 1.0까지 지원하지만 아직 이전 버전에서 작동하는 것으로 알려져 있습니다.

orderer.yaml의 Kafka.Version 키를 사용하여 Kafka 클러스터의 브로커와 통신하는 데 사용되는 Kafka 프로토콜 버전을 구성할 수 있습니다. Kafka 브로커는 이전 버전의 프로토콜과 역 호환됩니다. Kafka 브로커의 이전 프로토콜 버전과의 이전 호환성으로 인해 Kafka 브로커를 새 버전으로 업그레이드하는 경우 Kafka.Version 키 값을 업데이트할 필요는 없지만 Kafka 클러스터는 이전 프로토콜 버전을 사용하는 동안 성능이 저하 될 수 있습니다.

Debugging

General.LogLevel을 DEBUG로 설정하고 orderer.yaml의 Kafka.Verbose를 true로 설정합니다.

Example

Sample Docker 위의 권장 설정으로 인라인 구성 파일을 작성하려면 fabric/bddtests 디렉토리 아래에 있습니다. dc-orderer-kafka-base.yml 및 dc-orderer-kafka.yml를 찾으십시오.