오래된 정상 화면은 어떻게 장애를 숨기는가
마지막 정상 응답이 지금의 정상 상태를 뜻하지는 않는다. nigo-protocol 운영 콘솔에서 표본의 시각, 관측 실패, 명령 수락과 실제 완료를 구분한 이유를 살펴본다.
약 6분
분산 시스템
글 15편합의, 확정성, 장애 허용과 상태 복제
최신순1 / 2 페이지
RocksDB를 붙이기 전에 저장소의 약속부터 테스트했다
저장소를 바꾸기 위해 같은 테스트를 돌렸더니 기존 Memory 구현의 결함이 드러났다. snapshot의 부분 반영과 상태 이력 분류를 통해 공통 계약과 저장소별 내구성 검증의 경계를 살펴본다.
네 노드 중 하나만 멈췄다: 타임아웃 이후의 합의
먼저 다음 라운드로 넘어간 검증자가 뒤늦은 확정 증거를 버리면 어떻게 될까. nigo-protocol의 실제 재현과 수정에서, 새 투표를 만드는 일과 이미 성립한 합의를 배우는 일을 구분한다.
저장 함수가 돌아오면 서명을 보내도 될까
합의에 참여한 노드가 재시작 뒤에도 자신의 투표를 기억하려면 무엇이 먼저 저장돼야 할까. nigo-protocol의 로컬 안전 기록에서 commit, 내구성 확인, 서명 전파의 경계를 살펴본다.
HTTP는 응답하는데 합의는 멈춰 있다면
응답하는 서버, 실행 중인 합의 엔진, 실제 거래 확정은 서로 다른 근거를 필요로 한다. nigo-protocol이 정상 대기와 진행 지연, 관측 불가를 나눈 과정을 살펴본다.
- nigo-protocol 병렬 실행 시리즈 · 3편
병렬화의 효과는 어디에서 사라졌을까
실행 시간은 18% 줄었는데 전체 로컬 처리 시간은 2.4%만 줄었다. nigo-protocol의 병렬 실행 측정 기록을 통해 검증 비용, 거래 의존성, 측정 순서가 성능 판단을 어떻게 바꾸는지 살펴본다.
- nigo-protocol 병렬 실행 시리즈 · 2편
같은 거래 의존성, 세 가지 병렬 실행 방식
거래 사이의 기다림을 DAG로 표현하고, 같은 의존 관계를 WAVE·READY_QUEUE·WORK_FIRST_CONTINUATION으로 실행하는 차이와 nigo-protocol의 Direct Cell·Native Program 적용 구조를 설명한다.
- nigo-protocol 병렬 실행 시리즈 · 1편
동시에 실행해도 같은 원장이 되려면
자산 100을 두 갈래로 나누고 다시 합치는 예제로, 거래의 독립성 판단과 실행 격리, 정해진 순서의 결과 반영이 순차 실행과 같은 원장을 만드는 과정을 설명한다.
안전하게 멈춘 GC는 일을 끝낸 것일까
여러 상태가 공유하는 검증 자료의 삭제 조건에서 출발해, nigo-protocol의 실제 부하 실험에서 안전한 중단과 자동 정리의 완료가 왜 다른 결과였는지 살펴본다.
과거에 없던 상태와, 지금 꺼낼 수 없는 상태
자산 100의 이전 예제로 과거 상태의 부재와 자료 미확보·보존 제한을 구분하고, 단일 Cell 증명이 확인하는 사실과 계속된 자료 제공의 책임을 설명한다.