etcd가 충돌할 때, 먼저 디스크를 확인하세요

Source: Hacker News

번역을 진행하려면 번역하고자 하는 본문 내용을 제공해 주시겠어요?
본문을 알려주시면 원본 형식과 마크다운을 그대로 유지하면서 한국어로 번역해 드리겠습니다.

클라우드‑엣지 연속체 테스트베드에서 얻은 인사이트

컴퓨터 비전 데모를 위한 클라우드‑엣지 연속체 테스트베드를 구축하면서 분산 시스템에 대한 근본적인 사실을 배웠습니다: etcd는 느린 스토리지를 용서하지 않습니다.

The Demo Setup

우리는 MLSysOps 를 위한 데모를 구축하고 있습니다 – 이 프레임워크는 맞춤형 정책(단순하거나 ML 기반)을 통해 클라우드‑엣지‑IoT 연속체 전반에 걸쳐 애플리케이션의 배포 및 런타임 동작을 사용자 정의할 수 있게 합니다.

이 데모의 목적은 텔레메트리 기반 정책이 어디서 그리고 어떻게 애플리케이션이 실행되는지를 개발자나 운영자가 수동으로 개입하지 않아도 동적으로 조정할 수 있음을 보여주는 것입니다.

Architecture

• Continuum orchestrator: 개별 k3s 클러스터 위에 배치된 Karmada.
• Application: 실시간 객체 탐지를 수행하는 컴퓨터 비전 파이프라인.
• Hardware nodes:
  • Intel NUC
  • Raspberry Pi
  • Jetson AGX Orin

테스트베드 설정에 대한 자세한 내용은 MLSysOps GitHub repository 에서 확인할 수 있습니다.

Demo Flow

1. 객체 탐지 워크로드가 배포되어 Raspberry Pi에서 로컬로 실행됩니다.
2. Pi가 부하를 겪기 시작하면(프레임 레이트 감소, 추론 지연 증가) MLSysOps 에이전트가 텔레메트리를 통해 성능 저하를 감지합니다.
3. 정책이 투명하게 vAccel 백엔드를 Jetson AGX Orin으로 전환합니다.
4. 워크로드가 강력한 GPU로 오프로드되어 실시간 객체 탐지가 재개되며, 변경된 것은 정책 적용뿐—재배포도, 수동 개입도 없습니다.

우리가 배운 것

그 이야기를 전하기 전에, 먼저 클러스터를 가동시켜야 했으며 – 그 과정이 예상보다 더 흥미로웠다.

세 대의 물리 머신에 구성된 네‑노드 클러스터

Karmada는 자체 상태를 etcd에 저장하며, 이는 각 개별 Kubernetes 클러스터를 지원하는 etcd 인스턴스와 별개입니다. k3s에서는 이 etcd가 k3s 바이너리에 내장되어 있어 별도의 etcd 프로세스를 관리할 필요가 없습니다.

Karmada 호스트는 자체 etcd를 실행해야 하므로 전용 노드여야 하며, 이를 오케스트레이션하는 클러스터와는 구분됩니다. 사용 가능한 물리 머신이 세 대뿐이고 데모를 자체적으로 유지하고자 했기 때문에 다음과 같은 구성을 채택했습니다:

이 구성은 논리적이고 실용적이지만, 나중에 발견한 미묘한 문제를 야기하기도 했습니다.

증상: 계속 실행되지 않는 Pods

Karmada를 설치한 뒤, Karmada 자체의 pods가 5~10분마다 충돌하는 현상이 발견되었습니다—정기적이고, 예측 가능하며, 짜증나는 현상이었습니다.

충돌 자체는 즉시 원인을 알려주지는 않았습니다. pods는 다시 시작되고, 잠시 실행된 뒤 다시 충돌했습니다. 애플리케이션 레이어에서는 별다른 문제가 보이지 않았습니다.

k3s 클러스터 자체는 정상으로 보였습니다. 우리는 일반적인 원인—리소스 제한, 네트워킹, 재시작 시 발생하는 구성 드리프트—을 차례로 점검했지만 원인을 찾지 못했습니다.

조사는 점점 더 세세해졌습니다. 로그에서 찾을 수 있는 모든 실마리를 잡아당기고, 타임스탬프를 연관 지으며, 어떤 것이 언제 죽는지 패턴을 찾으려 노력했습니다.

Source: …

루트 원인: etcd와 I/O 지연

결국 로그가 예상치 못한 곳을 가리켰습니다: etcd가 타임아웃되고 있었습니다.
Karmada 설정 자체의 버그나 잘못된 구성 때문에 크래시가 발생한 것이 아니라, 기본 스토리지가 etcd의 기대에 충분히 빠르게 응답하지 못했기 때문이었습니다.

etcd는 강력한 일관성을 보장하는 분산 키‑값 저장소이며, 그 일관성을 유지하려면 I/O 지연에 매우 민감합니다. 쓰기‑앞 로그(write‑ahead log)를 사용하고 fsync 호출이 짧은 시간 안에 완료되어야 합니다. 스토리지가 느리면(간헐적이라도) etcd는 내부 하트비트와 선거(deadline)를 놓치게 되고, 리더 선출에 실패해 클러스터가 쿼럼을 잃으며, API 서버에 의존하는 파드들이 죽기 시작합니다.

NUC의 VM들은 호스트 스토리지를 공유하고 있었고, 기본 설정에서는 I/O 성능이 etcd를 만족시키기에 충분히 일관되지 않았습니다. etcd 타임아웃 임계값을 높이면 약간은 도움이 되었지만 근본적인 문제는 해결되지 않았습니다; 단지 실패 지점을 늦춘 것에 불과했습니다. 실제 문제는 스토리지 자체였습니다.

해결 방법: NUC에서 ZFS 튜닝

ZFS 스토리지 백엔드를 최적화한 뒤—쓰기 커밋 방식과 I/O 스케줄링에 영향을 주는 설정을 조정한 뒤—지연 프로파일이 개선되어 etcd 타임아웃이 사라지고 파드 충돌도 멈추었으며 클러스터가 안정되었습니다.

다음 ZFS 속성들을 VM을 지원하는 데이터셋에 적용했습니다:

zfs set sync=disabled      default   # 동기식 쓰기 비활성화
zfs set compression=lz4    default   # 빠른 LZ4 압축 사용
zfs set atime=off          default   # 접근 시간 업데이트 비활성화
zfs set recordsize=8k      default   # etcd 쓰기에 맞춘 작은 레코드 크기

각 설정이 하는 일

이 설정들을 적용하면 ZFS가 과도하게 조심하는 것을 멈추고 빠르게 동작하게 됩니다. sync=disabled가 etcd 충돌을 멈춘 주요 요인이고, 나머지 세 설정은 추가적인 I/O 완화를 제공하며 성능‑조정 워크로드에 일반적으로 좋은 관리 방안입니다.

Note: 운영 환경에서는 sync=disabled(전원 장애 시 데이터 손실 가능)와 성능 향상 사이의 위험을 충분히 고려해야 합니다. 공유 스토리지 위의 데모 VM에서는 이 트레이드‑오프가 허용될 수 있지만, 실제 etcd 클러스터에서는 보다 내구성 있는 구성을 사용하는 것이 바람직합니다.

교훈: etcd가 충돌하면 디스크를 확인하세요

이 패턴을 머릿속에 새겨두세요. Karmada(또는 etcd를 내장한 Kubernetes‑계열 시스템)를 운영 중이고, 명확한 애플리케이션 수준 원인이 보이지 않는 주기적인 파드 충돌을 겪고 있다면, 먼저 물어봐야 할 질문은:

etcd 워크로드 하에서 스토리지는 어떻게 동작하고 있나요?

etcd 문서에서도 이를 강조하고 있습니다. SSD 사용을 권장하고, 다른 I/O‑무거운 워크로드와 공유되는 스토리지에서 etcd를 실행하지 말라고 경고합니다.

• 실제 운영 클러스터에서는 일반적으로 etcd 노드 전용 전용 스토리지를 사용합니다.
• 공유 하드웨어 위에 VM을 띄워 놓은 데모 환경에서는 이 점을 간과하기 쉽습니다.

실행할 진단

1. Prometheus 메트릭 – etcd는 풍부한 메트릭을 노출합니다. 주시해야 할 메트릭은 다음과 같습니다:

   • etcd_disk_wal_fsync_duration_seconds
   • etcd_disk_backend_commit_duration_seconds

   두 메트릭 중 99번째 백분위수가 지속적으로 > 100 ms라면, 이는 구성 문제가 아니라 스토리지 문제입니다.

2. 스토리지 벤치마크 – 머신에 etcd를 설치하기 전에, 사용할 스토리지 경로에 대해 간단한 벤치마크를 실행합니다. fio 같은 도구를 사용하면 기본 읽기/쓰기 지연 프로파일을 얻을 수 있습니다.

# Example fio command (adjust path, size, and runtime as needed)
fio --name=etcd-bench --filename=/var/lib/etcd/data \
    --rw=randwrite --bs=4k --iodepth=32 --numjobs=4 \
    --time_based --runtime=60 --group_reporting

벤치마크 결과가 높은 지연 시간이나 낮은 IOPS를 보여준다면, etcd를 더 빠르고 전용 SSD 스토리지로 옮기는 것을 고려하세요. 이 간단한 점검만으로도 파드가 명확한 이유 없이 계속 충돌할 때 수시간에 달하는 트러블슈팅을 절약할 수 있습니다.

Source:

데모로 돌아가기

클러스터가 안정화되자 실제 데모는 빠르게 완성되었습니다. MLSysOps 정책 레이어는 제 역할을 수행하고, 텔레메트리는 라즈베리 Pi가 프레임 레이트에서 뒤처지고 있음을 보여줍니다. 정책이 발동하고, vAccel 백엔드는 Jetson AGX Orin으로 전환되며, 객체 감지가 실시간으로 전환됩니다. 네트워크 홉은 여전히 존재하지만, GPU 덕분에 무시할 수 있게 됩니다.

이것은 이기종 엣지 환경에서 적응형, 정책‑기반 오케스트레이션이 달성할 수 있는 것을 설득력 있게 보여주는 데모입니다. 우리는 그곳에 도달하기 위해 디스크‑I/O 문제와 싸워야 했습니다.

때때로 가장 유용한 디버깅 세션은 답이 전혀 다른 방향에 있을 때입니다. etcd는 분산 시스템이 인프라에 대해 강한 의견을 가지고 있음을 알려주었으며—​그 의견에 귀 기울일 가치가 있습니다.

Check out our demo