상태 유지 워크로드

상태 유지 워크로드 (Stateful Workloads)

기본적으로 Nomad의 할당 스토리지는 임시(ephemeral)예요. Nomad는 새 배포 중, 작업 재스케줄링 시, 또는 클라이언트를 잃을 때 이를 폐기할 수 있어요. 이는 데이터베이스 같은 영구 워크로드를 실행할 때 바람직하지 않아요.

출처: 문서

본문

이 문서는 Nomad에서 실행되는 워크로드의 영구 스토리지 옵션을 탐구해요. 제공되는 정보는 Nomad에 익숙하고 스토리지 기본에 대한 기초적인 이해가 있는 실무자를 위한 것이에요.

고려사항 (Considerations)

가장 적절한 스토리지 전략을 선택하려면 접근 패턴, 성능, 신뢰성·가용성 요구 사항, 유지보수를 고려해요.

로컬 스토리지는 성능이 좋고 가용해요. 충분한 용량이 있으면 유지보수가 많이 필요하지 않아요. 하지만 중복성이 없어서 단일 노드, 디스크, 또는 디스크 그룹이 실패하면 데이터 손실과 서비스 중단이 발생해요.

디스크, 컨트롤러, 네트워크 경로를 포함해 여러 중복성을 가진 지리적으로 분산된 네트워크 스토리지는 더 높은 가용성과 복원력을 제공하며, 데이터 손실 위험 전에 여러 하드웨어 장애를 견딜 수 있어요. 하지만 네트워크 스토리지의 성능과 신뢰성은 네트워크에 의존해요. 로컬 스토리지보다 대기 시간이 높고 처리량이 낮을 수 있으며, 더 많은 유지보수가 필요할 수 있어요.

Nomad가 공용 클라우드에서 실행되는지 온프레미스에서 실행되는지, 그리고 해당 환경에서 사용 가능한 스토리지 옵션이 무엇인지 고려해요. 그 지점에서 가장 최적의 선택은 조직과 애플리케이션의 요구에 따라 달라져요.

공용 클라우드 (Public cloud)

공용 클라우드 제공자들은 다양한 트레이드오프를 가진 여러 스토리지 서비스를 제공해요. 보통 로컬 디스크, 네트워크 연결 블록 장치, 네트워크 공유 스토리지로 구성돼요.

AWS
AWS 서비스 가용성 (Availability) 영속성 (Persistence) 성능 (Performance) 적합성 (Suitability)
Instance Storage 일부 인스턴스 유형에 로컬로 제한적, 인스턴스 중지/종료나 하드웨어 장애 시에도 유지되지 않음 높은 처리량과 낮은 대기 시간 버퍼, 캐시, 스크래치 데이터 등 자주 변경되는 정보의 임시 저장
Elastic Block Store 하나 이상의 인스턴스에 연결된 영역(zonal) 블록 장치 독립적인 수명주기로 영구적 구성 가능하지만 Instance Store보다 대기 시간이 높음 일반 목적 영구 스토리지
Elastic File System 여러 인스턴스에서 사용할 수 있는 리전/멀티리전 파일 스토리지 독립적인 수명주기로 영구적 구성 가능하지만 Instance Store나 EBS보다 처리량이 낮고 대기 시간이 높음 여러 존의 여러 인스턴스에서 사용 가능해야 하는 파일 스토리지 (페일오버로만이라도)
Azure
Azure 서비스 가용성 (Availability) 영속성 (Persistence) 성능 (Performance) 적합성 (Suitability)
Ephemeral OS disks 일부 인스턴스 유형에 로컬로 제한적, 인스턴스 중지/종료나 하드웨어 장애 시에도 유지되지 않음 높은 처리량과 낮은 대기 시간 버퍼, 캐시, 스크래치 데이터 등 자주 변경되는 정보의 임시 저장
Managed Disks 하나 이상의 VM에 연결된 영역 또는 리전 블록 장치 독립적인 수명주기로 영구적 구성 가능 일반 목적 영구 스토리지
Azure Files 여러 VM에서 사용할 수 있는 영역/리전/멀티리전 파일 스토리지 독립적인 수명주기로 영구적 구성 가능 여러 존의 여러 VM에서 사용 가능해야 하는 파일 스토리지 (페일오버로만이라도)
GCP
GCP 서비스 가용성 (Availability) 영속성 (Persistence) 성능 (Performance) 적합성 (Suitability)
Local SSD 일부 인스턴스 유형에 로컬로 제한적, 인스턴스 중지/종료나 하드웨어 장애 시에도 유지되지 않음 높은 처리량과 낮은 대기 시간 버퍼, 캐시, 스크래치 데이터 등 자주 변경되는 정보의 임시 저장
Persistent Disk 하나 이상의 인스턴스에 연결된 영역 또는 리전 블록 장치 독립적인 수명주기로 영구적 구성 가능 일반 목적 영구 스토리지
Filestore 여러 인스턴스에서 사용할 수 있는 영역/리전 파일 스토리지 독립적인 수명주기로 영구적 구성 가능 여러 존의 여러 VM에서 사용 가능해야 하는 파일 스토리지 (페일오버로만이라도)

사설 클라우드 또는 온프레미스 (Private cloud or on-premises)

셀프 매니지드 사설 클라우드에서 온프레미스로 워크로드를 실행할 때는 SAN/NAS 시스템이나 Ceph 같은 소프트웨어 정의 스토리지가 보통 비로컬 스토리지를 제공해요. 컴퓨팅 인스턴스는 iSCSI, FC, NVMe-oF 같은 블록 프로토콜이나 NFS, CIFS 같은 파일 프로토콜(또는 둘 다)로 스토리지에 접근할 수 있어요. 대부분의 조직에서 전담 스토리지 팀이 이러한 시스템을 관리해요.

Nomad에서 영구 스토리지 소비하기 (Consuming persistent storage from Nomad)

환경은 애플리케이션 요구 사항에 따라 다르므로, 가장 적절한 스토리지 드라이버를 선택할 때 성능, 신뢰성, 가용성, 유지보수를 고려해요.

CSI

Container Storage Interface는 스토리지 제공자가 Nomad 같은 오케스트레이터가 사용할 수 있는 플러그인을 개발할 수 있도록 하는 벤더 중립적 스펙이에요. 일부 CSI 플러그인은 스냅샷, 삭제, 동적 크기 조정을 포함한 볼륨 수명주기를 동적으로 프로비저닝하고 관리할 수 있어요. 각 플러그인이 지원하는 정확한 기능 집합은 플러그인과 기본 스토리지 플랫폼에 따라 달라져요.

플러그인과 기능 집합 목록은 Kubernetes CSI Developer Documentation에서 찾을 수 있어요.

Nomad가 CSI 스펙을 따르기는 하지만, 일부 플러그인은 오케스트레이터 특정 로직을 구현해 Nomad와 호환되지 않게 할 수 있어요. 사용 전에 선택한 플러그인이 Nomad에서 작동하는지 검증해야 해요. 자세한 내용은 스토리지 제공자의 플러그인 문서를 참고해요.

CSI 플러그인에는 세 가지 하위 유형이 있어요.

  • 컨트롤러 (Controller) : 스토리지 제공자와 통신해 볼륨 수명주기를 관리해요.
  • 노드 (Node) : 모든 Nomad 클라이언트에서 실행되고 모든 로컬 작업(예: 할당에서 볼륨 마운트/언마운트)을 처리해요. 이러한 작업을 수행하려면 노드가 권한(privileged)이 있어야 해요.
  • 모놀리식 (Monolithic) : 위 두 역할을 결합해요.

모든 유형은 Nomad 작업으로 실행할 수 있고 실행해야 해요 — Node와 Monolithic은 system 작업, Controller는 service 작업이에요. 자세한 내용은 [Container Storage Interface (CSI) plugins page][csi-concepts]를 참고해요.

CSI 플러그인은 스토리지 요구 사항이 빠르고 지속적으로 진화할 때 유용해요. 예를 들어 영구 스토리지가 있는 새 워크로드가 자주 추가·제거되는 환경은 CSI에 잘 맞아요. 하지만 유지보수 측면에서 몇 가지 어려움이 있어요. 가장 눈에 띄는 것은 지속적으로 실행되어야 하고, 구성되어야 하며(스토리지 플랫폼에 대한 인증·연결 포함), 새 기능과 버그 수정을 따라잡고 기본 스토리지 플랫폼과의 호환성을 유지하기 위해 업데이트되어야 한다는 점이에요. 또한 움직이는 부분이 몇 개 있고, 문제 해결이 어려울 수 있으며, (볼륨을 마운트하려면 권한 있는 컨테이너로 실행해야 하므로) 복잡한 보안 프로파일을 가져요.

Stateful Workloads with CSI 가이드와 Nomad CSI demo 저장소는 CSI 플러그인을 Nomad와 함께 사용하는 방법에 대한 지침과 예시를 제공하며, 플러그인 실행용 작업 파일과 볼륨 생성·소비용 구성 파일을 포함해요.

호스트 볼륨 (Host volumes)

호스트 볼륨은 Nomad 클라이언트의 경로를 할당에 마운트해요. Nomad는 호스트 볼륨 가용성을 인지하고 작업 스케줄링에 활용해요. 하지만 Nomad는 볼륨의 기반 특성(로컬 ext4 파일시스템의 표준 폴더인지, GlusterFS 같은 분산 네트워크 스토리지 기반인지, NAS나 AWS EFS 같은 공용 클라우드 서비스의 NFS/CIFS 마운트 볼륨인지)은 알지 못해요. 따라서 호스트 볼륨은 로컬 반영구 스토리지와 고가용성 네트워크 스토리지 모두에 사용할 수 있어요. 호스트 볼륨은 동적 또는 정적일 수 있어요.

로컬 스토리지 기반의 호스트 볼륨은 중요하지도 않고 쉽게 복원되지도 않는 데이터를 유지하는 데 도움을 줘요. 예를 들어 다시 만들 수 있는 온디스크 캐시, 또는 단일 노드가 클러스터의 나머지에서 자신의 상태를 다시 구축할 수 있는 클러스터형 애플리케이션이 있어요. NFS/CIFS 마운트 볼륨이나 GlusterFS·Ceph 같은 분산 스토리지 기반의 네트워크 스토리지에서 호스트 볼륨은 고가용성·고신뢰성 스토리지를 소비하는 빠른 옵션을 제공해요.

동적 호스트 볼륨 (Dynamic host volumes)

동적 호스트 볼륨은 volume create 명령어나 API로 프로비저닝해요. ACL 정책은 네임스페이스 내 스토리지에 대한 제어를 Nomad 운영자에게 위임할 수 있게 해줘요. 동적 호스트 볼륨 플러그인 스펙을 사용하면 로컬 스토리지 환경에 특화된 플러그인을 개발할 수 있어요. 예를 들어 온프레미스 클러스터에서 LVM thin-provisioning을 수행하는 플러그인을 작성할 수 있어요.

정적 호스트 볼륨 (Static host volumes)

정적 호스트 볼륨은 Nomad 에이전트의 구성 파일에 선언해요. 재구성하려면 Nomad 클라이언트를 재시작해야 해요. 이러한 재시작 때문에 스토리지 구성을 자주 변경한다면 정적 호스트 볼륨은 비현실적이에요. 또한 서로 다른 역할 간의 조정이 필요할 수 있어요. 예를 들어 Nomad 관리자는 Nomad 구성 파일을 수정해 호스트 볼륨을 추가·업데이트·삭제해서 Nomad 운영자가 소비할 수 있게 만들어야 해요. 또는 네트워크 호스트 볼륨의 경우 스토리지 관리자가 볼륨을 프로비저닝해 Nomad 클라이언트에 제공하고, 시스템 관리자가 이를 Nomad 클라이언트에 마운트해요.

NFS 주의사항 (NFS caveats)

NFS 기반 호스트 볼륨에는 ACL, 신뢰성, 성능 관련 주의사항이 몇 가지 있어요. NFS 마운트 옵션은 마운트하는 모든 Nomad 클라이언트에서 동일해야 해요.

NFS 버전에 따라 UID/GID(사용자/그룹 ID)가 서로 다른 Nomad 클라이언트 간에 달라질 수 있어, 다른 호스트의 할당이 볼륨에 접근하려 할 때 문제가 생길 수 있어요. 이를 확실히 방지하는 유일한 방법은 Kerberos 기반 ID 매핑을 사용하는 NFS v4를 사용하거나, 호스트 간 UID/GID를 동기화하는 신뢰할 수 있는 구성 관리/이미지 빌드 프로세스를 갖는 것이에요. 데이터 손실을 방지하려면 하드 마운트(hard mount)를 사용해야 해요. 선택적으로 intr을 사용해 NFS 요청을 중단할 수 있게 하면, NFS 서버를 사용할 수 없을 때 시스템 전체가 멈추는 것을 방지할 수 있어요.

NFS 기반 스토리지 성능의 중요한 요소는 블록의 최대 읽기/쓰기 크기를 결정하는 wsize와 rsize 마운트 옵션이에요. 크기가 작을수록 더 큰 작업이 더 작은 청크로 분할되어 성능에 상당한 영향을 줘요. 기본 스토리지 시스템의 벤더가 최적 크기를 제공해요. 예를 들어 AWS EFS는 wsize와 rsize 모두 1048576 바이트 값을 권장해요.

NFS 마운트 옵션에 대해 더 알아보려면 Red Hat의 NFS 문서를 방문해요.

임시 디스크 (Ephemeral disks)

Nomad 임시 디스크는 Nomad 할당 폴더의 최선 노력(best-effort) 영속성을 설명해요. 호스트 간 데이터 마이그레이션을 지원하며(Nomad 클라이언트 노드 간 네트워크 연결 필요) 스케줄링에 크기를 인지해요. 하지만 영속성은 최선 노력이므로 클라이언트나 기본 스토리지가 실패하면 데이터를 잃게 돼요. 임시 디스크는 필요 시 다시 만들 수 있는 데이터(예: 진행 중인 캐시나 데이터의 로컬 사본)에 완벽해요.

스토리지 비교 (Storage comparison)

이 문서에 정리된 정보를 바탕으로 다음 표를 사용해 Nomad 스토리지 요구 사항을 가장 잘 해결하는 스토리지 옵션을 선택해요.

스토리지 옵션 장점 (Advantages) 단점 (Disadvantages) 이상적인 환경 (Ideal for)
CSI 볼륨 많은 제공자를 가진 넓은 생태계, 스냅샷·복제·크기 조정 같은 고급 기능, 동적·유연·셀프서비스(올바른 ACL 정책이 있는 사람은 누구나 온디맨드로 볼륨 생성 가능) 약간의 복잡성과 지속적 유지보수, 플러그인 업그레이드가 기본 스토리지 제공자의 API 변경/업그레이드를 따라야 함, 모든 CSI 플러그인이 모든 기능을 구현하지는 않음, 모든 CSI 플러그인이 CSI 스펙을 존중하고 Nomad와 호환되지는 않음, 할당에서 볼륨을 마운트하려면 노드 플러그인이 권한 모드로 실행되어야 함 Nomad 클러스터 운영자와 소비자가 스토리지를 쉽게 추가/변경해야 하고, 선택한 스토리지 제공자가 CSI 스펙을 존중하는 CSI 플러그인을 가진 환경
로컬 스토리지 기반 동적 호스트 볼륨 즉시 사용 가능, 로컬이라 빠름, 지속적 유지보수 불필요 결함 허용이 없음. 단일 인스턴스의 하드웨어 장애 시 애플리케이션이 데이터를 복원할 수 없으면 데이터 손실 노드 장애를 견디도록 설계된 애플리케이션의 고성능·저대기 시간 영구 스토리지 요구가 있는 환경
네트워크 또는 클러스터 스토리지 기반 동적 호스트 볼륨 즉시 사용 가능, Nomad 측 지속 유지보수 불필요(스토리지 제공자에는 있을 수 있음) 기본 네트워크 스토리지와 그 한계가 소비자와 분리되어 있지만 이해해야 함. 예: 동시 접근이 가능한가 NFS/CIFS로 소비할 수 있는 스토리지 제공자가 이미 있는 환경
로컬 스토리지 기반 정적 호스트 볼륨 즉시 사용 가능, 로컬이라 빠름, 지속적 유지보수 불필요 구성·소비에 여러 역할 간 조정 필요(Nomad 클라이언트를 실행하는 운영자가 Nomad 클라이언트 구성 파일에 정적으로 구성해야 함), 결함 허용 없음. 단일 인스턴스의 하드웨어 장애 시 데이터 손실 일부 실패를 견딜 수 있지만 그렇게 하지 않거나 고성능·저대기 시간이 필요한 환경의 낮은 영구 스토리지 요구
네트워크 또는 클러스터 스토리지 기반 정적 호스트 볼륨 즉시 사용 가능, Nomad 측 지속 유지보수 불필요(스토리지 제공자에는 있을 수 있음) 구성·소비에 여러 역할 간 조정 필요(스토리지 관리자가 볼륨을 프로비저닝하고, Nomad 클라이언트를 실행하는 운영자가 Nomad 클라이언트 구성 파일에 정적으로 구성해야 함), 기본 네트워크 스토리지와 그 한계가 소비자와 분리되어 있지만 이해해야 함 NFS/CIFS로 소비할 수 있는 스토리지 제공자가 이미 있는, 낮은 용량 또는 낮은 변경 빈도의 스토리지 환경
임시 디스크 로컬이라 빠름, 선택적 마이그레이션을 포함한 기본 최선 노력 영속성 결함 허용 없음. 단일 인스턴스의 하드웨어 장애 시 데이터 손실 임시 캐시, 처리 중인 파일을 저장할 곳 등이 필요한 환경. 쉽게 다시 만들 수 있는 모든 임시 데이터

추가 리소스 (Additional resources)

Nomad와 이 문서에서 다루는 주제에 대해 더 알아보려면 다음 리소스를 방문해요.

할당 (Allocations)

  • Nomad의 이벤트 스트림으로 할당과 그 스토리지 모니터링하기
  • 클러스터 설정 모범 사례

CSI

  • Nomad CSI 플러그인 개념
  • Nomad CSI 튜토리얼
  • Nomad CSI 예시
  • Nomad와 함께 Ceph RBD CSI
  • Nomad와 함께 Democratic CSI
  • Nomad와 함께 JuiceFS CSI
  • Hetzner CSI
  • NFS CSI 플러그인

동적 호스트 볼륨 (Dynamic Host Volumes)

  • 동적 호스트 볼륨
  • 동적 호스트 볼륨 가이드
  • 커스텀 호스트 볼륨 플러그인

더 알아보기 (Learn more)