본문 바로가기
서버구축 (WEB,DB)

Zookeeper, Storm, Kafka, Elasticsearch 클러스터 고가용성 구성

by 날으는물고기 2024. 10. 23.

Zookeeper, Storm, Kafka, Elasticsearch 클러스터 고가용성 구성

High Availability Architectures and Best Practices - Evidian

Zookeeper, Storm, Kafka, Elasticsearch 클러스터를 고가용성으로 구성하는 것은 데이터의 안정적인 수집, 처리, 저장을 보장하는 데 중요합니다. 각 구성 요소는 다음과 같은 역할을 합니다.

  • Zookeeper: 분산 애플리케이션을 위한 중앙 집중형 서비스로, Kafka 및 Storm의 클러스터 관리에 사용됩니다.
  • Kafka: 고성능 메시징 시스템으로, 데이터를 수집하여 Storm으로 전달합니다.
  • Storm: 실시간 데이터 처리 시스템으로, 데이터를 처리한 후 Elasticsearch에 저장합니다.
  • Elasticsearch: 분산 검색 및 분석 엔진으로, 최종 데이터를 저장하고 검색합니다.

1. Zookeeper 클러스터 구성

  1. 서버 준비: 최소 3대의 서버를 준비합니다.
  2. Zookeeper 설치 및 설정
    • 각 서버에 Zookeeper를 설치합니다.
    • zoo.cfg 파일을 설정합니다.
      tickTime=2000
      dataDir=/var/lib/zookeeper
      clientPort=2181
      initLimit=5
      syncLimit=2
      server.1=zookeeper1:2888:3888
      server.2=zookeeper2:2888:3888
      server.3=zookeeper3:2888:3888
  3. Zookeeper 시작: 각 서버에서 Zookeeper를 시작합니다.
    zkServer.sh start

2. Kafka 클러스터 구성

  1. 서버 준비: 최소 3대의 서버를 준비합니다.
  2. Kafka 설치 및 설정
    • 각 서버에 Kafka를 설치합니다.
    • server.properties 파일을 설정합니다.
      broker.id=0
      log.dirs=/var/lib/kafka
      zookeeper.connect=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181
    • 각 서버에서 broker.id 값을 다르게 설정합니다.
  3. Kafka 시작: 각 서버에서 Kafka를 시작합니다.
    kafka-server-start.sh /path/to/server.properties

3. Storm 클러스터 구성

  1. 서버 준비: 최소 3대의 서버를 준비합니다.
  2. Storm 설치 및 설정
    • 각 서버에 Storm을 설치합니다.
    • storm.yaml 파일을 설정합니다.
      storm.zookeeper.servers:
          - "zookeeper1"
          - "zookeeper2"
          - "zookeeper3"
      nimbus.seeds: ["storm-nimbus"]
      supervisor.slots.ports:
          - 6700
          - 6701
          - 6702
  3. Storm 시작
    • Nimbus 노드에서 Nimbus를 시작합니다.
      storm nimbus
    • Supervisor 노드에서 Supervisor를 시작합니다.
      storm supervisor
    • 각 노드에서 UI를 시작합니다.
      storm ui

4. Elasticsearch 클러스터 구성

  1. 서버 준비: 최소 3대의 서버를 준비합니다.
  2. Elasticsearch 설치 및 설정
    • 각 서버에 Elasticsearch를 설치합니다.
    • elasticsearch.yml 파일을 설정합니다.
      cluster.name: my-cluster
      node.name: node-1
      network.host: 0.0.0.0
      discovery.seed_hosts:
          - "es-node1"
          - "es-node2"
          - "es-node3"
      cluster.initial_master_nodes:
          - "node-1"
          - "node-2"
          - "node-3"
    • 각 서버에서 node.name 값을 다르게 설정합니다.
  3. Elasticsearch 시작: 각 서버에서 Elasticsearch를 시작합니다.
    systemctl start elasticsearch

데이터 흐름 구성

  1. 데이터 수집 (Kafka)
    • 데이터는 Kafka로 수집됩니다. 프로듀서를 통해 Kafka 토픽에 데이터를 전송합니다.
      kafka-console-producer.sh --broker-list kafka1:9092 --topic my-topic
  2. 데이터 처리 (Storm)
    • Kafka 스파웃을 사용하여 Kafka에서 데이터를 읽고, 이를 Storm 톱롤로지로 전달합니다.
    • Storm 볼트를 사용하여 데이터를 처리한 후 Elasticsearch로 전송합니다.
  3. 데이터 저장 (Elasticsearch)
    • Storm에서 처리된 데이터를 Elasticsearch에 저장합니다.
    • elasticsearch-hadoop와 같은 커넥터를 사용하여 Storm과 Elasticsearch를 연동합니다.
      // 예시: Storm Bolt에서 Elasticsearch로 데이터 전송
      public class ElasticsearchBolt extends BaseRichBolt {
          private TransportClient client;
      
          @Override
          public void prepare(Map stormConf, TopologyContext context, OutputCollector collector) {
              Settings settings = Settings.builder().put("cluster.name", "my-cluster").build();
              client = new PreBuiltTransportClient(settings)
                  .addTransportAddress(new TransportAddress(InetAddress.getByName("es-node1"), 9300));
          }
      
          @Override
          public void execute(Tuple tuple) {
              String data = tuple.getStringByField("data");
              IndexResponse response = client.prepareIndex("my-index", "_doc")
                  .setSource(jsonBuilder().startObject().field("data", data).endObject())
                  .get();
          }
      
          @Override
          public void cleanup() {
              client.close();
          }
      }

고가용성을 위한 팁

  • Zookeeper: 홀수 개의 서버로 구성하여 마스터 선출에 안정성을 높입니다.
  • Kafka: 파티션을 여러 브로커에 분산하고, 복제팩터를 설정하여 브로커 장애 시에도 데이터 손실을 방지합니다.
  • Storm: 여러 노드에 Supervisor를 설치하여 노드 장애 시에도 작업을 지속할 수 있도록 합니다.
  • Elasticsearch: 샤드를 여러 노드에 분산하고, 복제 샤드를 설정하여 데이터 손실을 방지합니다.

 

이러한 구성 요소와 설정을 통해 고가용성 클러스터를 구축하고 안정적으로 데이터를 처리할 수 있습니다. 추가적으로 Master/Slave 구조의 개념과 각 구성 요소에서의 적용 방법입니다.

1. Zookeeper

  • Master/Slave 개념: Zookeeper에서는 Master/Slave 개념이 아니라 Leader/Follower 개념이 사용됩니다.
  • Master 지정 방법: Zookeeper 클러스터는 Leader 선출을 위해 Zab(또는 Zookeeper Atomic Broadcast) 프로토콜을 사용합니다. 설정 파일 (zoo.cfg)에서 클러스터 서버를 지정하면, Zookeeper는 자동으로 Leader를 선출합니다.
  • Master 장애 대응 방법: Leader 노드가 장애가 발생하면, 나머지 Follower 노드들이 새로운 Leader를 선출합니다. 자동으로 이루어지며 추가적인 설정이 필요하지 않습니다.
# zoo.cfg 예시
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=zookeeper1:2888:3888
server.2=zookeeper2:2888:3888
server.3=zookeeper3:2888:3888

2. Kafka

  • Master/Slave 개념: Kafka에서는 Master/Slave 개념이 아니라 Leader/Replica 개념이 사용됩니다.
  • Master 지정 방법: 각 파티션은 여러 브로커에 분산되어 저장되며, 각 파티션에는 Leader 브로커와 Replica 브로커가 있습니다. Leader는 파티션의 데이터를 읽고 쓸 수 있으며, Replica는 Leader의 데이터를 복제합니다.
  • Master 장애 대응 방법: Leader 브로커가 장애가 발생하면, Zookeeper를 통해 새로운 Leader가 자동으로 선출됩니다.
# server.properties 예시
broker.id=0
log.dirs=/var/lib/kafka
zookeeper.connect=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181

3. Storm

  • Master/Slave 개념: Storm에서는 Master/Slave 개념이 Nimbus와 Supervisor로 나뉩니다.
  • Master 지정 방법: Nimbus는 클러스터의 Master 노드로, 작업을 할당하고 클러스터를 관리합니다. Supervisor는 Slave 노드로, Nimbus가 할당한 작업을 실행합니다.
  • Master 장애 대응 방법: Nimbus가 장애가 발생하면, 다른 Nimbus 노드를 통해 클러스터를 복구해야 합니다. Storm은 고가용성을 위해 다중 Nimbus 구성을 지원하지 않습니다. 따라서, Nimbus 노드의 고가용성을 위해 Zookeeper를 사용한 페일오버 솔루션을 구성하는 것이 일반적입니다.
# storm.yaml 예시
storm.zookeeper.servers:
    - "zookeeper1"
    - "zookeeper2"
    - "zookeeper3"
nimbus.seeds: ["storm-nimbus"]
supervisor.slots.ports:
    - 6700
    - 6701
    - 6702

4. Elasticsearch

  • Master/Slave 개념: Elasticsearch에서는 Master/Slave 개념이 Master/Data 노드로 나뉩니다.
  • Master 지정 방법: Master 노드는 클러스터 상태를 관리하고, Data 노드는 데이터를 저장하고 검색합니다. elasticsearch.yml 설정 파일에서 노드 역할을 지정할 수 있습니다.
  • Master 장애 대응 방법: Master 노드가 장애가 발생하면, 나머지 Master 노드 후보들이 새로운 Master를 선출합니다. 이를 위해 클러스터 초기 설정 시 최소 마스터 노드를 지정합니다.
# elasticsearch.yml 예시
cluster.name: my-cluster
node.name: node-1
node.master: true
node.data: false
network.host: 0.0.0.0
discovery.seed_hosts:
    - "es-node1"
    - "es-node2"
    - "es-node3"
cluster.initial_master_nodes:
    - "node-1"
    - "node-2"
    - "node-3"

마스터 장애 대응

Zookeeper

  1. Leader 장애 발생 시: Follower 중 하나가 자동으로 Leader가 됩니다.
  2. 새로운 Leader 선출 과정: Zab 프로토콜에 따라 선출됩니다.

Kafka

  1. Leader 장애 발생 시: Zookeeper가 새로운 Leader를 선출합니다.
  2. 새로운 Leader 선출 과정: 해당 파티션의 Replica 중 하나가 Leader로 전환됩니다.

Storm

  1. Nimbus 장애 발생 시: 새로운 Nimbus를 수동으로 시작해야 합니다.
  2. Nimbus 페일오버 구성: 페일오버 솔루션을 통해 두 개 이상의 Nimbus 노드를 준비하고 Zookeeper를 사용하여 장애 시 페일오버를 구성할 수 있습니다.

Elasticsearch

  1. Master 노드 장애 발생 시: 나머지 Master 후보 노드들이 새로운 Master를 선출합니다.
  2. 새로운 Master 선출 과정: discovery.zen.minimum_master_nodes 설정에 따라 선출됩니다.
    # elasticsearch.yml 추가 설정
    discovery.zen.minimum_master_nodes: 2
  • Zookeeper: 자동 Leader 선출
  • Kafka: 자동 Leader 선출
  • Storm: 수동 Nimbus 페일오버 필요
  • Elasticsearch: 자동 Master 노드 선출

 

이렇게 각 구성 요소의 Master/Slave 구조와 장애 대응 방법을 이해하고 설정하면 고가용성 클러스터를 효과적으로 운영할 수 있습니다. 자동으로 Master 노드가 선정되는 구성 요소와 그렇지 않은 경우 대부분의 분산 시스템에서는 고가용성을 위해 Master 노드의 자동 선출 메커니즘을 제공합니다. 그러나 설정과 운영에 따라 수동 개입이 필요한 경우도 있습니다. 각 구성 요소에서의 Master 노드 선정 방법입니다.

1. Zookeeper

  • 자동 선정: Zookeeper는 Leader/Follower 구조를 사용하며, Leader는 자동으로 선출됩니다. Zookeeper는 Zab(Zookeeper Atomic Broadcast) 프로토콜을 통해 Leader를 선출하며, 설정 파일에서 지정된 서버 목록 중에서 하나를 Leader로 선택합니다.

2. Kafka

  • 자동 선정: Kafka에서는 각 파티션에 대해 Leader 브로커가 있으며, 이는 자동으로 선출됩니다. 만약 현재 Leader 브로커에 장애가 발생하면, Zookeeper를 통해 파티션의 Replica 중 하나가 새로운 Leader로 자동 전환됩니다.

3. Storm

  • 수동 선정: Storm의 Nimbus는 Master 역할을 하지만, Storm 자체는 고가용성을 위해 다중 Nimbus 구성을 자동으로 지원하지 않습니다. 따라서, Nimbus의 장애 시 수동으로 새로운 Nimbus를 시작하고 설정해야 합니다. Zookeeper와 같은 외부 도구를 사용하여 페일오버를 설정할 수 있습니다.

4. Elasticsearch

  • 자동 선정: Elasticsearch는 Master/Data 노드 구조를 사용하며, Master 노드는 클러스터의 관리 작업을 수행합니다. elasticsearch.yml 파일에서 Master 후보 노드를 지정하면, Master 노드가 장애가 발생했을 때 나머지 후보 노드들 중에서 새로운 Master를 자동으로 선출합니다.
    # elasticsearch.yml 예시
    cluster.name: my-cluster
    node.name: node-1
    node.master: true
    node.data: false
    network.host: 0.0.0.0
    discovery.seed_hosts:
        - "es-node1"
        - "es-node2"
        - "es-node3"
    cluster.initial_master_nodes:
        - "node-1"
        - "node-2"
        - "node-3"
    discovery.zen.minimum_master_nodes: 2
  • 자동으로 Master 노드가 선정되는 구성 요소
    • Zookeeper: Leader 자동 선출
    • Kafka: 파티션 Leader 자동 선출
    • Elasticsearch: Master 노드 자동 선출
  • 수동으로 관리가 필요한 구성 요소
    • Storm: Nimbus 노드는 자동 선출되지 않으며, 장애 발생 시 수동으로 페일오버 구성 필요

 

각 시스템에서 Master 노드가 자동으로 선정되는지 여부를 알고, 이를 설정하는 방법을 이해하는 것은 클러스터의 고가용성을 유지하는 데 중요합니다. 수동으로 노드를 구분하고 관리하는 방법과 Master 개념의 노드가 장애 발생 시 처리하는 각 시스템별 방법입니다.

1. Zookeeper

Zookeeper는 Leader와 Follower 노드를 자동으로 선출합니다. 수동으로 특정 노드를 Leader로 지정할 수는 없지만, 설정 파일을 통해 노드 구성을 지정할 수 있습니다.

# zoo.cfg 예시
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=zookeeper1:2888:3888
server.2=zookeeper2:2888:3888
server.3=zookeeper3:2888:3888

Master 노드 장애 처리

  1. 장애 발생 시: Leader 노드가 장애가 발생하면, Follower 노드들 중 하나가 자동으로 새로운 Leader로 선출됩니다.
  2. 새로운 Leader 확인: zkCli.sh 클라이언트를 사용하여 현재 Leader를 확인할 수 있습니다.
    echo stat | nc zookeeper1 2181

2. Kafka

Kafka에서는 server.properties 파일을 통해 각 브로커를 설정합니다. 특정 파티션의 Leader를 수동으로 지정할 수는 없습니다.

# server.properties 예시
broker.id=0
log.dirs=/var/lib/kafka
zookeeper.connect=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181

Master 노드 장애 처리

  1. 장애 발생 시: Leader 브로커가 장애가 발생하면, Zookeeper가 새로운 Leader를 자동으로 선출합니다.
  2. 새로운 Leader 확인: kafka-topics.sh 스크립트를 사용하여 각 파티션의 Leader를 확인할 수 있습니다.
    kafka-topics.sh --describe --topic <topic_name> --zookeeper zookeeper1:2181

3. Storm

Storm에서는 Nimbus와 Supervisor 노드를 설정 파일을 통해 수동으로 구분합니다.

# storm.yaml 예시
storm.zookeeper.servers:
    - "zookeeper1"
    - "zookeeper2"
    - "zookeeper3"
nimbus.seeds: ["storm-nimbus"]
supervisor.slots.ports:
    - 6700
    - 6701
    - 6702

Master 노드 장애 처리

  1. 장애 발생 시: Nimbus가 장애가 발생하면, 새로운 Nimbus를 수동으로 시작해야 합니다.
  2. 새로운 Nimbus 시작: 다른 서버에서 Nimbus를 시작하고 storm.yaml 파일을 업데이트합니다.
    storm nimbus

4. Elasticsearch

Elasticsearch는 elasticsearch.yml 파일을 통해 노드를 Master 또는 Data 노드로 구분합니다.

# elasticsearch.yml 예시
node.master: true
node.data: false
network.host: 0.0.0.0
discovery.seed_hosts:
    - "es-node1"
    - "es-node2"
    - "es-node3"
cluster.initial_master_nodes:
    - "node-1"
    - "node-2"
    - "node-3"

Master 노드 장애 처리

  1. 장애 발생 시: Master 노드가 장애가 발생하면, 나머지 Master 후보 노드들이 새로운 Master를 자동으로 선출합니다.
  2. 새로운 Master 확인: curl 명령어를 사용하여 클러스터 상태를 확인할 수 있습니다.
    curl -X GET "es-node1:9200/_cluster/health?pretty"

예시

Zookeeper

# zoo.cfg
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=zookeeper1:2888:3888
server.2=zookeeper2:2888:3888
server.3=zookeeper3:2888:3888
  • 장애 처리: Follower 중 하나가 자동으로 Leader로 선출됩니다.

Kafka

# server.properties
broker.id=0
log.dirs=/var/lib/kafka
zookeeper.connect=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181
  • 장애 처리: 새로운 Leader가 자동으로 선출됩니다.

Storm

# storm.yaml
storm.zookeeper.servers:
    - "zookeeper1"
    - "zookeeper2"
    - "zookeeper3"
nimbus.seeds: ["storm-nimbus"]
supervisor.slots.ports:
    - 6700
    - 6701
    - 6702
  • 장애 처리: 수동으로 새로운 Nimbus를 시작합니다.

Elasticsearch

# elasticsearch.yml
node.master: true
node.data: false
network.host: 0.0.0.0
discovery.seed_hosts:
    - "es-node1"
    - "es-node2"
    - "es-node3"
cluster.initial_master_nodes:
    - "node-1"
    - "node-2"
    - "node-3"
  • 장애 처리: 새로운 Master가 자동으로 선출됩니다.

 

이러한 구성을 통해 각 시스템의 고가용성을 유지하고, Master 노드 장애 시 적절한 대응을 할 수 있습니다.

728x90

댓글