검수요청.png검수요청.png

"기본노드"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
(합의 알고리즘)
(합의 알고리즘)
58번째 줄: 58번째 줄:
  
 
====합의 알고리즘====
 
====합의 알고리즘====
[[합의 알고리즘]](Consensus Algorithm)은 크게 Paxos와 Raft 합의 알고리즘이 있다. Raft 합의 알고리즘의 가장 큰 특징은 리더 기반의 복제와 각 멤버 노드가 상태를 가진다는 것이다. 하나의 레플리카 셋에는 반드시 하나의 리더만 존재할 수 있고, 리더는 사용자의 모든 데이터 변경 요청을 처리한다. 그리고 리더는 사용자의 요청 내용(데이터 변경)을 로그에 기록하고, 모든 팔로워는 리더의 로그를 가져와서 동기화를 수행한다. Raft 합의 알고리즘의 리더를 몽고디비에서는 프라이머리 노드라고 하고 팔로워는 세컨드리 노드라고 한다. 그리고 로그를 몽고디비에서는 오피로그(Operation Log; OpLog)라고 한다.<ref>코딩초보 여성게, 〈[https://coding-start.tistory.com/m/274?category=815805 DB - MongoDB 복제(Replica-set,프라이머리,세컨드리,아비터노드)]〉, 《티스토리》, 2019-09-12</ref>
+
[[합의 알고리즘]](Consensus Algorithm)은 크게 Paxos와 Raft 합의 알고리즘이 있다. Raft 합의 알고리즘의 가장 큰 특징은 리더 기반의 복제와 각 멤버 노드가 상태를 가진다는 것이다. 하나의 레플리카 셋에는 반드시 하나의 리더만 존재할 수 있고, 리더는 사용자의 모든 데이터 변경 요청을 처리한다. 그리고 리더는 사용자의 요청 내용(데이터 변경)을 로그에 기록하고, 모든 팔로워는 리더의 로그를 가져와서 동기화를 수행한다. Raft 합의 알고리즘의 리더를 몽고디비에서는 프라이머리 노드라고 하고 팔로워는 보조 노드라고 한다.<ref>코딩초보 여성게, 〈[https://coding-start.tistory.com/m/274?category=815805 DB - MongoDB 복제(Replica-set,프라이머리,세컨드리,아비터노드)]〉, 《티스토리》, 2019-09-12</ref>
  
 
===심버스===
 
===심버스===

2019년 10월 17일 (목) 16:56 판

프라이머리 노드(Primary Node)는 응용 프로그램이 실행되는 노드이며, 여기서 보조 노드로 데이터가 복제된다. 기본 노드, 주 노드로 불리기도 한다.

개요

프라이머리 노드는 기본 서버의 구성 중 하나이다. 시스템 장애로 인해 다른 서버로 전환해야 할 때까지 이 서버에서 처리가 수행된다. 로컬 노드라고도 불린다. 프라이머리 상태는 일시적이고 동적이므로, 특정 머신에 고정되어 있지 않다.[1]

활용

몽고디비

몽고디비(MongoDB) 로고

몽고디비(MongoDB)에서는 마스터-슬레이브 복제와 레플리카 셋 복제라고 하는 두 가지 방식의 복제를 지원한다. 마스터-슬레이브 복제는 몽고디비가 만들어졌던 초기에 사용하던 복제 방식으로, 몽고디비3.2 버전에서는 권장하지 않는 방식이다. 또한, 마스터-슬레이브 복제 방식은 마스터의 장애에 대한 페일 오버를 관리자가 수동으로 처리해야 하며, 최근 버전의 몽고디비에서는 거의 기능이 개선되거나 보완되지 않고 있다. 그에 반해서 레플리카 셋 복제는 안정되고 많은 부분 자동화되어 처리될 수 있게 개발됐다.

복제

복제(Replication)는 여러 서버가 서로의 데이터를 동기화하는 것을 의미하는데, 서로 주고받는 데이터에 따라서 논리 복제와 물리 복제로 나눌 수 있다. 분산 복제 블록 장치(Distributed Replicated Block Device; DRBD)와 같이 리눅스 서버가 데이터의 내부를 전혀 모르는 상태에서 디스크의 블록만 복제하는 형태를 물리적 복제라고 한다. 그리고 MySQL 서버나 몽고디비 서버와 같이 데이터베이스 서버가 직접 서버 간의 데이터를 동기화하는 방식을 논리적 복제라고 한다. 물리적 복제는 데이터베이스가 전혀 관여하지 않음으로 운영체제 차원에서 응용 프로그램에 투명하게 복제를 처리할 수 있지만, 응용 프로그램의 캐시나 내부 처리 로직에서 변경된 데이터를 사용하지 못하는 문제점도 있다. 몽고디비는 MySQL 서버의 복제와 아주 비슷하게 논리적 복제 수단을 가지고 있으며, 더불어 프라이머리 노드의 선출과 네트워크 단절로 인한 스플릿 브레인(Split-Brain) 현상을 막을 수 있는 기능까지 내장하고 있다.

복제의 가장 큰 목적은 동일한 데이터를 이중 삼중으로 유지함으로써 레플리카 셋의 특정 멤버에서 데이터 손실이 발생하더라도 다른 멤버의 데이터로 대체할 수 있도록 하기 위함이다. 즉 고가용성(High-Availability)을 위해서 중복된 데이터 셋을 준비하는 것이다. 고가용성을 위해서 몽고디비 레플리카 셋의 각 멤버는 서로 다른 멤버가 살아있는지 계속 확인하는 하트 비트 메시지를 주고받는다. 만약 프라이머리 노드와 통신 되지 않으면 새로운 프라이머리 노드를 선출해 서비스가 계속 지속되도록 한다. 복제의 또 다른 목적으로는 데이터 조회 쿼리의 로드 분산을 생각할 수 있다. 몽고디비에서 데이터의 변경은 프라이머리 노드에서 시작되지만, 각 세컨드리 노드는 데이터 변경은 하지 못하지만 조회쿼리의 요청은 받을 수 있다. 즉, 읽기 성능을 높이기 위해 세컨드리 노드를 확장해서 사용하기도 한다.

  • 복제 셋(replica set)의 구성
  • 1대의 프라이머리(primary) 서버
  1. 클라이언트 요청을 처리한다.
  2. 데이터에 대해 쓰기, 읽기가 가능하다.
  3. 복제 셋에서 쓰기 동작을 하는 유일한 맴버다.
  • 여러 대의 보조(secondary) 서버
  1. 프라이머리 데이터의 복제 데이터를 가지고 있다.
  2. 프라이머리의 오피로그(oplog)에서 하던 동작을 보조의 데이터 셋에 비동기적으로 적용한다.
  3. 프라이머리 서버에 장애가 발생 시 보조 서버는 자신들 중 새로운 프라이머리 서버를 선출할 수 있다.
  4. 데이터의 읽기만 가능하다.
  • 복제의 작동 방식
데이터 복제를 가능하게 한다.
  • 캡드(capped) 컬렉션으로 모든 복제 노드에서 local이라는 데이터베이스 내에 존재한다.
  • 데이터에 대한 모든 수정사항을 기록한다.
  1. 클라이언트가 프라이머리 노드에 관해 쓰기를 할 때마다 보조에서 재생하기 위한 충분한 정보가 프라이머리 노드의 오피로그에 자동으로 추가된다.
  2. 쓰기가 보조 노드에 복제되고 나면 쓰기 정보가 보조 노드의 오피로그에도 기록된다.
  • 오피로그 항목은 BSON 타임 스탬프로 인식되고, 모든 보조는 타임 스탬프를 이용해서 적용할 최신 항목을 추적한다.
  • 로컬(local) 데이터베이스의 oplog.rs라는 컬렉션에 오피로그가 저장된다.
  1. 로컬 데이터베이스에 저장된 기타 컬렉션
  2. replset.minvalid : 복제 셋 멤버의 초기 동기화를 위한 정보
  3. system.replset : 복제 셋 설정 도큐먼트를 저장
  4. me, slaves : 쓰기 concern을 구현하는 데 사용
  5. system.indexes : 인덱스 규격에 대한 정보를 가지고 있는 표준 컬렉션
  • 보조가 복제 데이터를 유지하는 프로세스
  1. 프라이머리 노드에 쓰기 기록
  2. 프라이머리 노드의 오피로그에 추가
  3. 보조 노드가 자신의 오피로그에 프라이머리 노드의 오피로그를 복제
  • 보조에서의 상세 프로세스
  1. 보조 노드가 업데이트 준비가 됨
  2. 자신의 오프로그에서 가장 최근 항목의 타임 스탬프를 검사
  3. 프라이머리 노드의 오피로그에서 최근 항목의 타임 스탬프 이후의 모든 오피로그 항목을 질의
  4. 질의 된 오피로그 항목을 자신의 오프로그에 추가
  5. 추가된 오프로그의 항목을 자신의 데이터에 적용
  • 보조는 롱 폴링(long polling) 방식을 사용하여 프라이머리의 변경 데이터를 즉각적으로 적용하게 된다.[2]

합의 알고리즘

합의 알고리즘(Consensus Algorithm)은 크게 Paxos와 Raft 합의 알고리즘이 있다. Raft 합의 알고리즘의 가장 큰 특징은 리더 기반의 복제와 각 멤버 노드가 상태를 가진다는 것이다. 하나의 레플리카 셋에는 반드시 하나의 리더만 존재할 수 있고, 리더는 사용자의 모든 데이터 변경 요청을 처리한다. 그리고 리더는 사용자의 요청 내용(데이터 변경)을 로그에 기록하고, 모든 팔로워는 리더의 로그를 가져와서 동기화를 수행한다. Raft 합의 알고리즘의 리더를 몽고디비에서는 프라이머리 노드라고 하고 팔로워는 보조 노드라고 한다.[3]

심버스

심버스(SymVerse) 로고

심버스는 20,000TPS를 목표로, 블록 생성의 안전성을 높이고, 거버넌스 문제를 해결하기 위해 심센서스(SymSensus)라는 합의 알고리즘을 적용했다. 심센서스는 거부권(veto)을 포함한 투표 방식의 비잔틴 장애 허용(BFT; Byzantine Fault Tolerant) 알고리즘을 사용하는데, 이는 가장 빠른 BFT 알고리즘이다. 심버스는 기존 블록체인의 합의 방식과 달리 단순히 블록 생성의 대가로 코인이 발행되지 않으며 네트워크 증명(PoN)의 기여도를 측정하여 1일 1회 코인이 분배된다. 심버스는 네트워크 증명을 통해 참여자가 4일마다 증인이 될 수 있도록 설계했다. 심버스는 네트워크 참여자 모두에게 블록을 생성할 수 있는 권리를 부여하여 생태계가 자발적으로 성장할 수 있게 했다. 심센서스는 거부권 기능을 도입함으로써 악의적인 노드의 블록 조작 가능성을 원천적으로 방지할 수 있다.[4]

  • A 그룹 보증노드 : 심센서스는 게임이론과 구조설계 기법이 적용됐으며 총 25개 보증노드가 돌아간다. 이 중 9개는 A 그룹이라 부르고 심버스재단이 선발한다. 이 그룹 노드들은 블록생성권이 없고, 투표권만 행사한다. 게다가 동일한 투표 결과를 보여주는 집단적인 거부권(veto)을 행사할 수 있다. 전체 보증노드 중 2/3 이상 찬성할 경우 합의 과정은 종결된다. 따라서 거부권이 존재하는 심버스에서는 어떠한 보증노드들이라도 담합하여 이득을 취할 수 없다.
  • B 그룹 보증노드 : B 그룹의 보증노드는 후보 신청한 작업노드 중에서 탈중앙화되고 선발 과정이 공평한 4단계의 자동 벤치마킹 테스트(autonomous bench marking test)를 통하여 선발한다. 블록 생성의 합의 과정을 주관하는 프라이머리 노드 1개, 프라이머리 노드에 대한 우선순위가 확정된 프런트 벤치 노드(front bench node) 3개, 미들 벤치 노드(middle bench node) 8개, 백 벤치 노드(back bench node) 4개를 포함하여 총 16개로 구성된다. 충분한 거래내역을 처리할 수 있도록 프라이머리 노드가 생성하는 블록의 수는 정해져 있지 않다. 블록의 크기는 블록의 종류에 따라 다를 수 있다. 프라이머리 노드는 거래기록을 모으고 이를 블록으로 생성한 후 생성한 블록에 대한 검증을 요청한다. 이때 프라이머리 노드가 서명 기반 비잔틴 장애 허용(BFT) 방식으로 보증노드 수의 2/3 이상으로부터 확인을 받으면 블록생성이 확정되고, 다른 노드들에게 전파한다.[5]

각주

  1. Primary Node〉, 《StorNext 5》
  2. kwsstudy, 〈복제(REPLICATION)〉, 《Github 블로그》, 2016-12-04
  3. 코딩초보 여성게, 〈DB - MongoDB 복제(Replica-set,프라이머리,세컨드리,아비터노드)〉, 《티스토리》, 2019-09-12
  4. 방은주 기자, 〈차세대 메인넷 표방 ‘심버스’공개...“이오스 잡겠다”〉, 《지디넷코리아》, 2018-08-18
  5. 심버스, 〈SymVerse : Better World〉, 《심버스 백서》, 2018-10

참고자료

같이 보기


  검수요청.png검수요청.png 이 기본노드 문서는 블록체인 기술에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.