[Hyperledger Fabric v1.0] 5. ARCHITECTURE(아키텍트): Bringing up a Kafka-based Ordering Service(Kafka 기반 주문 서비스 시작)

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

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

 Bringing up a Kafka-based Ordering Service(Kafka 기반 주문 서비스 시작)

Caveat emptor(경고 emptor)

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

Big picture(청사진)

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

Steps(순서)

K 와 Z를 각각 Kafka 클러스터와 ZooKeeper 앙상블의 노드 수로 봅시다.

i. 최소한 K는 4로 설정해야합니다 (아래 4 단계에서 설명 하겠지만, 이것은 고장 내결함성을 나타 내기 위해 필요한 최소 노드 수입니다. 즉, 4 개의 브로커가있는 경우 1 개의 브로커가 작동하지 않을 수 있습니다. 모든 채널은 계속해서 쓰기 및 읽기가 가능하며 새로운 채널을 만들 수 있습니다.)

ii. Z는 3, 5 또는 7 중 하나입니다. 스플릿 브레이브 시나리오를 피하기 위해 홀수 여야하며 단일 실패 지점을 피하기 위해 1보다 커야합니다. 7 개의 ZooKeeper 서버를 초과하는 것은 과잉으로 간주됩니다.

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

1. 주문자 : 네트워크의 기원 블록에 카프카 관련 정보를 암호화하십시오. configtxgen을 사용하는 경우 configtx.yaml을 편집하거나 시스템 채널의 genesis 블록에 대한 사전 설정된 프로필을 선택하십시오.

• Orderer.OrdererType이 kafka로 설정됩니다.
• Orderer.Kafka.Brokers 에는 클러스터에있는 두 개 이상의 Kafka 중개자의 주소가 IP:port  notation에 들어 있습니다. 이 목록은 완전 할 필요는 없습니다. (이들은 귀하의 seed brokers입니다.)

2. 주문자 : 최대 블록 크기를 설정하십시오. 각 블록은 configtx.yaml에서 설정할 수있는 최대 바이트 수 (헤더 제외)입니다. 여기에서 선택한 값을 A로 지정하고 4 단계에서 Kafka 중개인을 구성하는 방법에 영향을줍니다.

3. 주문자 : 제네시스 블록을 만듭니다. configtxgen을 사용하십시오. 위의 1 단계와 2 단계에서 선택한 설정은 시스템 전체의 설정입니다. 즉, 모든 OSN에 대해 네트워크 전체에 적용됩니다. 제네시스 블록의 위치를 ​​기록하십시오.

4. Kafka cluster: 카프카 브로커를 적절하게 구성하십시오. 모든 카프카 중개인은 다음과 같은 키들을 구성해야합니다.

• unclean.leader.election.enable = false – 데이터 일관성은 블록 체인 환경에서 핵심입니다. 동기화 된 복제 세트 외부에서 채널 리더를 선택할 수 없거나 이전 리더가 생성 한 오프셋을 덮어 쓸 위험이 있습니다. 결과적으로 주문자가 생산하는 블록 체인을 다시 작성합니다.

• min.insync.replicas = M – 여기서 1 <M <N과 같은 값 M을 선택합니다 (아래 default.replication.factor 참조). 데이터는 최소한 M 개의 복제본에 기록 될 때 커밋 된 것으로 간주됩니다 (동기화 후 동기화로 간주되어 동기화 된 복제 세트 또는 ISR에 속함). 다른 경우, 쓰기 조작은 오류를 리턴합니다. 그때:
  • 채널 데이터가 기록되는 N 개 중 최대 N-M 개의 복제본을 사용할 수 없게되면 작업이 정상적으로 진행됩니다.
  • 더 많은 복제본을 사용할 수 없게되면 Kafka는 M의 ISR 집합을 유지할 수 없으므로 쓰기 허용을 중지합니다. 문제없이 작업을 읽습니다. 채널은 M개의 복제본이 동기화 될 때 다시 쓰기 가능하게됩니다.
• default.replication.factor = N – 여기서 N <K 인 값 N을 선택합니다. N의 복제 인수는 각 채널의 데이터가 N개의 브로커에 복제됨을 의미합니다. 이들은 채널의 ISR 세트 후보입니다. 위의 min.insync.replicas section 에서 언급했듯이 모든 브로커가 항상 사용 가능해야하는 것은 아닙니다. N- 브로커가 N보다 적 으면 채널 제작을 진행할 수 없기 때문에 N을 K보다 작게 설정해야합니다. 따라서 N = K로 설정하면 단일 브로커가 중단된다는 것은 블록 체인 네트워크에 새로운 채널을 만들 수 없다는 것을 의미합니다. 주문 서비스의 오류 방지 기능은 존재하지 않습니다.
• message.max.bytes 및 replica.fetch.max.bytes는 위의 2 단계에서 Orderer.AbsoluteMaxBytes에서 선택한 값보다 큰 값으로 설정해야합니다. 머리말을 설명 할 버퍼를 추가하십시오. 1 MiB가 충분합니다. 다음 조건이 적용됩니다. Orderer.AbsoluteMaxBytes < replica.fetch.max.bytes <= message.max.bytes
• (완성을 위해 message.max.bytes는 기본적으로 100 MiB로 설정된 socket.request.max.bytes보다 작아야합니다. 100 MiB보다 큰 블록을 원한다면 하드를 편집해야합니다 abric/orderer/kafka/config.go에있는 brokerConfig.Producer.MaxMessageBytes의 값을 인코딩하고 소스에서 이진 파일을 다시 작성하십시오.
• log.retention.ms = -1. Fabric의 주문 서비스에서 Kafka 로그의 가지 치기에 대한 지원이 추가 될 때까지는 시간 기반 보존을 비활성화하고 세그먼트가 만료되지 않도록해야합니다. (크기 기반 보존 - log.retention.bytes 참조 -이 글을 쓰고있는 시점의 Kafka에서는 기본적으로 사용 중지되어 있으므로 명시 적으로 설정할 필요가 없습니다.) 앞서 설명한 내용을 토대로 M과 N의 최소 허용 값은 각각 2와 3입니다. 이 구성은 앞으로 나아갈 새로운 채널을 생성하고 모든 채널이 계속 쓰기 가능하도록합니다.

5. 지시자 : 각 OSN을 제네시스 블록으로 향하게하십시오. orderer.yaml에서 General.GenesisFile을 편집하여 위의 3 단계에서 생성 된 기원 블록을 가리 키도록합니다. (그 동안 YAML 파일의 다른 모든 키가 적절하게 설정되었는지 확인하십시오.)

6. 주문자 : 폴링 간격 및 타임 아웃을 조정합니다. (선택 단계.)

• orderer.yaml 파일의 Kafka.Retry 섹션을 사용하여 메타 데이터 / 제작자 / 고객 요청의 빈도와 소켓 시간 초과를 조정할 수 있습니다. (이들은 카프카 제작자 또는 소비자에게 기대되는 모든 설정입니다.)
• 또한 새 채널을 만들거나 기존 채널을 다시로드하면 (순서가 다시 시작된 경우) 주문자는 다음과 같은 방법으로 Kafka 클러스터와 상호 작용합니다.
  • 채널에 해당하는 Kafka 파티션을위한 Kafka 제작자 (작성자)를 만듭니다.
  • 이 생성자는 해당 파티션에 no-op CONNECT 메시지를 게시합니다.
  • 해당 파티션에 대한 Kafka 소비자 (독자)를 만듭니다.

7. SSL을 통해 통신 할 수 있도록 OSN과 Kafka 클러스터를 설정하십시오. (옵션 단계이지만 권장 됨) 방정식의 Kafka 클러스터 측면에 대한 Confluent 가이드를 참조하고 그에 따라 모든 OSN의 orderer.yaml 에있는 Kafka.TLS 에서 키를 설정하십시오.

8. ZooKeeper 앙상블, Kafka 클러스터, 주문 서비스 노드 순서로 노드를 가져옵니다.

Additional considerations(추가 고려 사항)

1. 기본 메시지 크기. 위의 2 단계 (단계 섹션 참조)에서 Orderer.Batchsize.PreferredMaxBytes 키를 설정하여 원하는 블록 크기를 설정할 수도 있습니다. 상대적으로 작은 메시지를 처리 할 때 Kafka는 높은 처리량을 제공합니다. 1 MiB보다 크지 않은 값을 목표로 삼는다.

2. 환경 변수를 사용하여 설정을 무시합니다. 환경 변수를 사용하여 Kafka 브로커 또는 ZooKeeper 서버 설정을 무시할 수 있습니다. 구성 키의 점을 밑줄로 바꿉니다 (예 : KAFKA_UNCLEAN_LEADER_ELECTION_ENABLE=false 를 지정하면 unclean.leader.election.enable의 기본값을 무시할 수 있습니다. 로컬 구성에 대한 OSN에도 동일하게 적용됩니다 (즉, orderer.yaml에서 설정할 수있는 항목). 예를 들어 ORDERER_KAFKA_RETRY_SHORTINTERVAL=1s을 사용하면 Orderer.Kafka.Retry.ShortInterval의 기본값을 무시할 수 있습니다.

Supported Kafka versions and upgrading(지원되는 Kafka 버전 및 업그레이드)

Supported Kafka versions for v1 are 0.9 and 0.10. (Fabric uses the sarama client library and vendors a version of it that supports Kafka 0.9 and 0.10.)

v1에 대해 지원되는 카프카 버전은 0.9와 0.10입니다. Fabric은 sarama 클라이언트 라이브러리를 사용하고 공급 업체는 Kafka 0.9 및 0.10을 지원하는 버전을 사용합니다.

상자에서 Kafka 버전의 기본값은 0.9.0.1입니다. 지원되는 다른 버전을 사용하려면 소스 코드를 편집 (orderer / orderer/localconfig/config.go에서 defaults 구조체의 Version 필드 수정)하고 orderer 바이너리를 다시 빌드해야합니다. 예를 들어, 0.10.0.1을 실행하는 Kafka 클러스터에서 주문 서비스를 실행하려면 다음과 같이 파일을 편집하십시오.

...
Verbose: false,
Version: sarama.V0_10_0_1,
TLS: TLS{
...

그리고 바이너리를 다시 빌드하십시오. (이 과정은 FAB-4619로 개선 될 것입니다.)

Debugging(디버깅)

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

Example(예시)

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