블록체인 노드를 컨테이너로 돌릴 때: CA 자동화와 OS 메모리 관리가 같이 가야 하는 이유

Hyperledger Fabric의 peer/orderer, Geth, Besu, Tendermint 같은 블록체인 클라이언트를 Docker나 Kubernetes 위에서 돌리는 조합이 늘고 있다. 문제는 이 두 축 — 노드 간 통신을 지키는 인증서 관리와, 컨테이너가 죽지 않게 하는 메모리 관리 — 를 따로 다루면 둘 다 어설퍼진다는 점이다. 인증서가 롤링되지 않으면 mTLS 통신이 끊기고, 메모리 상한이 커널·컨테이너·애플리케이션 사이에서 어긋나면 OOM으로 블록 높이가 역행한다.

컨테이너로 노드를 표준화한다는 것

불변 이미지, 읽기 전용 루트파일시스템, 최소 권한 실행으로 구성하면 합의 노드 간 바이너리가 재현 가능한 형태로 일관되게 유지된다. cgroups v2의 memory.max, memory.high, swap 전략을 노드마다 명시적으로 설정해야 런타임 거동을 예측할 수 있다.

인증서 쪽은 ACME, Fabric CA, Vault PKI 등으로 발급→배포→회전→폐기의 표준 절차를 자동화하고, 중간/루트 CA 체인과 CRL/OCSP를 반영하는 게 기본이다. 키 자체는 Kubernetes Secret이나 Docker secret에 두기보다 HSM/PKCS#11과 연계해 추출 위험을 줄이는 편이 안전하다.

메모리를 계층 전반에서 동시에 맞춰야 한다

메모리 최적화는 계층을 나눠 생각하는 게 맞다.

커널: vm.overcommit_memory, vm.swappiness, THP(Transparent Huge Pages), PSI(Pressure Stall Information) 기반 경보·오토스케일링 연계
컨테이너: memory.high/max, swap 제한, NUMA 정책
애플리케이션: Go 런타임의 GOMEMLIMIT, Java의 -Xmx/MaxRAMPercentage 같은 런타임 상한

이 세 층의 숫자가 어긋나면 문제가 생긴다. 컨테이너 limit은 8GiB인데 애플리케이션이 상한 없이 힙을 늘리면 커널 OOM Killer가 프로세스를 죽이고, 반대로 애플리케이션 상한을 지나치게 낮게 잡으면 GC 빈도만 늘어난다. THP 비활성화나 NUMA 고정은 지연 편차를 줄이는 데는 유리하지만 일부 워크로드에서는 메모리 효율을 깎아먹을 수 있어, seccomp/AppArmor·readOnlyRootFilesystem 같은 격리 강화와 함께 트레이드오프로 다뤄야 한다.

관측은 eBPF/PSI로 메모리 정체를 감지하고 P95/P99 GC 지연, 페이지 폴트율을 지켜보는 식으로 이뤄진다. memory.high 초과나 reclaim 실패 같은 신호는 OOM이 실제로 터지기 전에 동기/비동기 RPC 큐를 조절하는 트리거로 쓴다.

체인마다 다른 CA·메모리 조합

Hyperledger Fabric + Fabric CA, CouchDB: peer/orderer 컨테이너에 CouchDB, Fabric CA가 붙는 구성이다. 인증서·키는 HSM 또는 Vault로 보호하고 노드 간에는 TLS mutual auth를 쓴다. peer에 2~~4GB, CouchDB file cache에 1~~2GB를 배정하고 memory.high를 peer의 80%로 설정해 단계적 reclaim을 유도한다. 채널 재구성이나 업그레이드 때는 인증서 로테이션을 롤링으로 적용해 OOM으로 인한 블록 높이 역행을 막는다.

Ethereum(Geth) 풀노드 + 프록시 TLS 종단: Geth 컨테이너 앞에 Nginx나 Envoy로 RPC TLS를 종단시키고 CA가 서버/클라이언트 인증서를 관리하는 구조다. --cache를 2048~~4096 사이로 조정하고 Go의 GOMEMLIMIT을 컨테이너 memory.max의 80~~85%로 맞춘다. 이렇게 하면 스냅 동기화 중 P99 GC 스톨이 줄고 블록 전파 지연이 안정된다.

Tendermint/Cosmos, Validator-Sentry 패턴: Validator는 HSM 기반으로 서명하고, Sentry가 외부 피어와의 통신을 대신 받는다. CA는 노드 간 TLS 발급·회전을 담당한다. validator에는 memory.high를 더 낮게 잡고 sentry에는 네트워크 버퍼 여유를 더 준다. 이 구성에서는 합의 라운드 타임아웃과 피어 드랍 빈도가 줄어드는 게 관찰된다.

메모리 압력이 실제로 커질 때

입력(이미지, CA 인증서/키, OS 커널 파라미터, 컨테이너 메모리 한계)이 커널 튜닝 → 컨테이너 제한 → 런타임 상한 동기화 → CA 자동화 → 관측/경보를 거쳐 안정된 동기화와 낮은 합의 지연으로 이어지는 흐름을 도식화하면 다음과 같다.

⤢✕

에러 경로는 원인별로 갈린다. 메모리 압력이 오를 때는 PSI memory가 0.6초/60초 임계를 넘으면 RPC 동시성을 낮추고 memory.high를 상향하거나 캐시를 줄이며, 그래도 지속되면 롤링 재시작으로 넘어간다. OOM이 임박했을 때는 컨테이너 RSS가 memory.max의 90%를 넘는 시점에 GOMEMLIMIT/Xmx를 일시적으로 낮추고 블록/트랜잭션 큐를 배출한다. 인증서 만료·폐지 쪽은 OCSP/CRL 조회가 실패해도 기존 세션은 유지한 채 재시도 백오프를 걸고, 만료 14/7/1일 전 단계적으로 롤링한다.

설정 예시

전제: Linux 커널 5.10+, cgroups v2 활성, Docker 24+, Go 1.20+/Java 17+, 시간 동기화(chrony/ntpd). 아래 값들은 예시이며 실제 배포 전 최신 정보 확인이 필요하다.

커널 파라미터와 THP 비활성화:

# /etc/sysctl.d/99-blockchain.conf
vm.overcommit_memory = 1
vm.overcommit_ratio = 80
vm.swappiness = 10
vm.max_map_count = 1048576

sysctl --system

# THP 비활성(지연 편차 감소용)
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

THP를 끄면 메모리 단편화가 늘어날 수 있고, max_map_count를 올리면 메모리 매핑이 많은 DB·노드에는 필요하지만 과도하면 OOM 발생 시 디버깅이 어려워진다.

Docker Compose로 메모리 제한과 Secret을 함께 관리하는 예:

# docker-compose.yaml
version: "3.9"
services:
  geth:
    image: ethereum/client-go:v1.14.9
    command: ["--http", "--http.addr", "0.0.0.0", "--cache", "4096"]
    environment:
      - GOMEMLIMIT=6GiB # 컨테이너 memory.max의 80~85%
      - MALLOC_ARENA_MAX=2
    deploy:
      resources:
        limits:
          memory: 8g
        reservations:
          memory: 6g
    volumes:
      - ./data:/root/.ethereum
      - type: bind
        source: ./certs
        target: /etc/pki
        read_only: true
    read_only: true
    cap_drop: ["ALL"]
    networks: ["chain"]
  proxy:
    image: envoyproxy/envoy:v1.30-lts
    volumes:
      - ./envoy.yaml:/etc/envoy/envoy.yaml:ro
      - ./certs:/etc/pki:ro
    deploy:
      resources:
        limits:
          memory: 512m
networks:
  chain: {}

Docker Swarm 모드가 아니라면 deploy.resources는 적용되지 않으니 docker run의 --memory/--memory-reservation을 대신 써야 한다.

Java 기반 노드(Besu 등)는 컨테이너 인지형 상한을 명시한다.

# 컨테이너 메모리 8GiB 가정
JAVA_TOOL_OPTIONS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=75 -Xms2g -XshowSettings:vm" \
docker run --memory=8g --memory-swap=8g \
  -e JAVA_TOOL_OPTIONS \
  hyperledger/besu:24.9 \
  --rpc-http-enabled

MaxRAMPercentage를 너무 낮게 잡으면 GC 빈도가 늘고, 너무 높게 잡으면 OOM 위험이 커진다.

Fabric CA 연계와 PKCS#11(HSM) 활성화:

# Fabric CA 클라이언트로 mTLS cert 발급
fabric-ca-client enroll -u https://user:pass@ca.example.com \
  --tls.certfiles /etc/pki/ca.crt

# Peer에서 PKCS#11 활성화 환경변수
export CORE_PEER_BCCSP_DEFAULT=PKCS11
export CORE_PEER_BCCSP_PKCS11_LIBRARY=/usr/lib/softhsm/libsofthsm2.so
export CORE_PEER_BCCSP_PKCS11_PIN=1234
export CORE_PEER_BCCSP_PKCS11_LABEL=FabricToken

HSM 라이브러리·버전 호환성은 공급사마다 다르므로 문서 기준으로 최신 정보를 확인해야 한다.

접근 방식의 체감 차이

전략	성능(P99 지연)	확장성(동시 피어)	일관성(블록 전파)	안정성(OOM/일)	운영 편의
기본값(무제한/기본 커널)	중간, 스파이크 빈번	증가 시 급격 악화	변동 큼	높음(>0.1)	쉬움(초기)
OS 튜닝만(THP off, vm 조정)	개선, 편차 감소	보통	개선	중간(≈0.02)	중간
컨테이너+런타임 동기화(cgroups+GOMEMLIMIT/Xmx)	우수, 안정	우수	일정	낮음(<0.005)	초기 비용↑, 장기 쉬움

수치는 운영 사례 평균값 가정으로, 워크로드에 따라 편차가 있다. 이 조합을 제대로 적용했을 때 보고되는 정량 효과는 OOM 이벤트/노드-일 기준 70~~95% 감소, P99 합의 지연 20~~40% 개선(블록 전파 편차 감소 포함), 인증서 로테이션 실패율 0.5% 미만 달성과 갱신 시간 50% 단축이다. 정성적으로는 장애 예측 가능성 향상, 롤링 업그레이드 안정성 제고, HSM/Secret 최소 노출과 mTLS 전면화를 통한 보안 태세 강화, 운영 표준화로 인한 온보딩·감사 대응 용이성이 따라온다.