Cloud Native Operations

한국어

English

한국어

English

Appearance

EKS에서 블록체인 노드 운영 퀴즈 ​

이 퀴즈는 StatefulSet 구성, 스토리지, 헬스체크, 하드포크 관리에 대한 이해도를 테스트합니다.

객관식 문제 ​

  1. 블록체인 노드를 EKS에서 운영할지 판단하는 기준으로 제시된 것은?
    • A) 노드 개수가 10개 이상인지
    • B) 블록체인 노드 주변에 다른 워크로드(인덱서, API, 모니터링)가 있는지 — 노드만 덩그러니 있으면 EC2가 단순
    • C) 퍼블릭 체인인지 프라이빗 체인인지
    • D) 검증자를 운영하는지
정답 보기

정답: B) 블록체인 노드 주변에 다른 워크로드(인덱서, API, 모니터링)가 있는지 — 노드만 덩그러니 있으면 EC2가 단순

설명: 블록체인 노드는 Kubernetes의 강점(빠른 재배치, 수평 확장, 롤링 업데이트)과 잘 맞지 않는 부분이 있습니다. 그럼에도 EKS를 쓰는 근거는 운영 표준화, 여러 체인·환경 관리, 주변 구성요소와의 통합입니다. 인덱서·API·모니터링이 이미 클러스터에 있으면 노드도 함께 두는 것이 합리적이고, 검증자 하나만 운영하는 데 EKS의 추상화는 이점 없이 복잡도만 더합니다.

  1. 블록체인 노드 StatefulSet에서 terminationGracePeriodSeconds를 길게 주어야 하는 이유는?
    • A) 이미지 풀에 시간이 걸리기 때문
    • B) 클라이언트가 종료 시 메모리의 상태를 디스크에 flush해야 하고, 강제 종료되면 데이터베이스가 손상되어 재동기화가 필요할 수 있기 때문
    • C) P2P 피어에게 종료를 알려야 하기 때문
    • D) 볼륨 detach에 시간이 걸리기 때문
정답 보기

정답: B) 클라이언트가 종료 시 메모리의 상태를 디스크에 flush해야 하고, 강제 종료되면 데이터베이스가 손상되어 재동기화가 필요할 수 있기 때문

설명: 기본값 30초는 대개 부족합니다. 블록체인 클라이언트는 상태 데이터베이스를 메모리에 캐시하고 있으며 종료 시 이를 디스크에 flush해야 합니다. 강제 종료(SIGKILL)되면 DB가 중간 상태로 남아 손상될 수 있고, 그러면 재동기화가 필요해 수 시간에서 며칠이 걸립니다. 같은 이유로 메모리 limit도 넉넉히 주어야 합니다 — OOM kill도 강제 종료이기 때문입니다.

  1. 블록체인 노드 스토리지에서 용량보다 IOPS가 먼저 병목이 되는 이유는?
    • A) 체인 데이터가 압축되어 저장되기 때문
    • B) 상태 트리(Merkle Patricia Trie 등)를 탐색·갱신하는 작업이 흩어진 키를 건드리는 랜덤 접근 패턴이기 때문
    • C) 블록이 순차적으로만 기록되기 때문
    • D) 스냅샷을 자주 생성하기 때문
정답 보기

정답: B) 상태 트리(Merkle Patricia Trie 등)를 탐색·갱신하는 작업이 흩어진 키를 건드리는 랜덤 접근 패턴이기 때문

설명: 블록체인 노드의 디스크 사용은 랜덤 읽기·쓰기가 많습니다. 용량이 남아도 IOPS가 부족하면 동기화가 따라가지 못하고, 뒤처진 노드는 서비스할 수 없습니다. 그래서 gp3의 IOPS와 throughput을 용량과 독립적으로 설정할 수 있는 특성이 핵심 이점입니다. gp2는 용량당 IOPS가 정해져 있어 IOPS를 늘리려면 필요 없는 용량을 사야 했습니다.

  1. liveness probe에 동기화 상태를 넣으면 안 되는 이유는?
    • A) 동기화 확인이 RPC 부하를 늘리기 때문
    • B) 뒤처진 노드가 재시작되고, 재시작으로 더 뒤처지고, 다시 재시작되는 무한 루프에 빠지기 때문
    • C) liveness probe는 exec 방식을 지원하지 않기 때문
    • D) 동기화 상태는 readiness에서만 조회 가능하기 때문
정답 보기

정답: B) 뒤처진 노드가 재시작되고, 재시작으로 더 뒤처지고, 다시 재시작되는 무한 루프에 빠지기 때문

설명: liveness는 "프로세스가 살아있고 응답하는가"만 봐야 합니다. 여기에 동기화 조건을 넣으면 뒤처진 노드를 죽이게 되고, 재시작은 동기화를 더 지연시켜 영원히 따라잡지 못합니다. 반대로 readiness에는 반드시 동기화를 넣어야 합니다 — 넣지 않으면 뒤처진 노드가 트래픽을 받아 오래된 체인 기준으로 틀린 데이터를 반환합니다. 이 구분이 블록체인 노드 헬스체크의 핵심입니다.

  1. P2P 인바운드를 열었는데 피어가 오지 않는 전형적 원인은?
    • A) Security Group 설정 누락
    • B) 광고 주소 미설정 — 컨테이너 안에서 본 Pod IP와 외부에서 접근 가능한 주소가 달라 다른 피어가 접속할 수 없음
    • C) UDP 포트만 열고 TCP를 열지 않음
    • D) 피어 수 상한이 0으로 설정됨
정답 보기

정답: B) 광고 주소 미설정 — 컨테이너 안에서 본 Pod IP와 외부에서 접근 가능한 주소가 달라 다른 피어가 접속할 수 없음

설명: P2P 프로토콜은 자기 주소를 다른 피어에게 광고합니다. 컨테이너 안에서 본 주소(Pod IP)와 외부에서 접근 가능한 주소(노드 공인 IP, LB 주소)가 다르면 다른 피어가 광고된 주소로 접속하지 못합니다. 대부분의 클라이언트가 --nat extip:<addr> 형태의 옵션을 제공하며, 이것을 설정하지 않으면 인바운드를 열어도 피어가 오지 않습니다. Pod별로 다른 주소를 광고해야 하므로 StatefulSet ordinal이나 downward API로 자기 주소를 알아내는 초기화 로직이 필요합니다.

  1. 블록체인 노드에서 CPU limit을 신중히 다뤄야 하면서 동시에 노드 전용화를 권하는 이유는?
    • A) CPU limit이 메모리 사용에 영향을 주기 때문
    • B) 전용 node는 tenant 경합을 줄이지만 시스템 daemon의 reservation·여유는 필요하다
    • C) 전용 노드에서는 CPU limit이 무시되기 때문
    • D) Guaranteed QoS를 받으려면 노드를 전용화해야 하기 때문
정답 보기

정답: B) 전용 node는 tenant 경합을 줄이지만 시스템 daemon의 reservation·여유는 필요하다

설명: Kubelet·CNI/CSI·monitoring·OS 서비스는 남습니다. 앱 CPU limit을 생략해도 지속 부하와 node health를 시험합니다.

  1. Pectra 업그레이드의 EIP-7251이 운영에 준 영향은?
    • A) 노드 디스크 요구량이 절반으로 줄었다
    • B) EIP-7251은 해당 validator의 consolidation을 허용하지만 validator key와 process/VM은 일대일이 아니다
    • C) 실행 클라이언트와 컨센서스 클라이언트가 하나로 통합되었다
    • D) 하드포크 일정이 연 1회로 줄었다
정답 보기

정답: B) EIP-7251은 해당 validator의 consolidation을 허용하지만 validator key와 process/VM은 일대일이 아니다

설명: Validator client는 여러 키를 관리할 수 있습니다. Validator record/키 관리 감소가 비례하는 인프라·비용 감소를 증명하지는 않습니다.

  1. 어떤 유지보수 조치가 Fabric MSP/TLS 인증서 만료에 대응합니까?
    • A) orderer의 Raft 합의 실패
    • B) MSP/TLS 인증서 만료를 감시하고 channel·policy·consensus 운영과 함께 갱신을 연습한다
    • C) 체인코드 실행 오류
    • D) 채널 정책 충돌
정답 보기

정답: B) MSP/TLS 인증서 만료를 감시하고 channel·policy·consensus 운영과 함께 갱신을 연습한다

설명: 인증서 만료는 구체적 위험이지만 이 자료의 실측 최다 장애 순위는 아닙니다. Operator 호환성과 peer transaction 검증도 확인합니다.

  1. 하드포크 후 반드시 해야 하는 확인 작업은?
    • A) Pod 재시작
    • B) 다른 노드와 공개 익스플로러와 블록 해시를 대조해 같은 체인에 있는지 확인
    • C) 스토리지 용량 재계산
    • D) 피어 목록 초기화
정답 보기

정답: B) 다른 노드와 공개 익스플로러와 블록 해시를 대조해 같은 체인에 있는지 확인

설명: 호환되지 않는 client는 활성화 후 canonical chain 추적을 중단하거나 갈라질 수 있으므로 process liveness만으로 정확성을 확인할 수 없습니다. 정상적인 전파·sync 지연을 고려하며 독립적인 신뢰 node 또는 explorer에서 같은 block height와 finality 상태의 hash를 비교합니다. 서로 다른 최신 head나 explorer 하나를 결정적 근거로 삼지 말고 client 버전·fork 인식·동기화 확인을 함께 사용합니다.