Nomad 소개

Nomad 소개 (Introduction to Nomad)

Nomad 소개 가이드에 오신 것을 환영해요. 이 가이드는 Nomad를 시작하기에 가장 좋은 곳이에요. Nomad가 무엇인지, 어떤 문제를 해결할 수 있는지, 기존 소프트웨어와 어떻게 비교되는지, 어떻게 시작할 수 있는지 다뤄요. Nomad의 기본에 익숙하다면 문서와 튜토리얼이 사용 가능한 기능에 대한 더 자세한 참조를 제공해요.

출처: 문서

본문

Nomad란 무엇인가? (What is Nomad?)

Nomad는 유연한 워크로드 오케스트레이터(orchestrator)로, 조직이 단일하고 통합된 워크플로로 컨테이너화된 애플리케이션이나 레거시 애플리케이션을 쉽게 배포하고 관리할 수 있게 해줘요. Nomad는 Docker, 비컨테이너, 마이크로서비스, 일괄(batch) 애플리케이션의 다양한 워크로드를 실행할 수 있어요.

Nomad는 개발자가 애플리케이션 배포에 선언적 인프라스트럭처-애즈-코드(infrastructure-as-code)를 사용할 수 있게 해줘요. Nomad는 빈 패킹(bin packing)을 사용해 작업을 효율적으로 스케줄링하고 리소스 활용률을 최적화해요. Nomad는 macOS, Windows, Linux에서 지원돼요.

Nomad는 널리 채택되어 PagerDuty, Target, Citadel, Trivago, SAP, Pandora, Roblox, eBay, Deluxe Entertainment 등에서 프로덕션으로 사용되고 있어요.

핵심 기능 (Key features)

컨테이너와 레거시 애플리케이션 배포: 오케스트레이터로서의 Nomad의 유연성은 조직이 동일한 인프라에서 컨테이너, 레거시, 일괄 애플리케이션을 함께 실행할 수 있게 해줘요. Nomad는 플러그 가능한 작업 드라이버(task drivers)를 통해 컨테이너화 없이도 레거시 애플리케이션에 핵심 오케스트레이션 이점을 제공해요.
단순 & 신뢰성: Nomad는 단일 바이너리로 실행되며 완전히 자체 포함되어 있어요. 리소스 관리와 스케줄링을 단일 시스템으로 결합해요. Nomad는 스토리지나 조정(coordination)에 외부 서비스가 필요하지 않아요. Nomad는 애플리케이션, 노드, 드라이버 실패를 자동으로 처리해요. Nomad는 분산되어 있고 탄력적이며, 리더 선출과 상태 복제를 사용해 실패 시 고가용성을 제공해요.
디바이스 플러그인 & GPU 지원: Nomad는 머신 러닝(ML)과 인공 지능(AI) 같은 GPU 워크로드에 대한 내장 지원을 제공해요. Nomad는 디바이스 플러그인을 사용해 GPU, FPGA, TPU 같은 하드웨어 디바이스의 리소스를 자동으로 감지하고 활용해요.
다중 리전 페더레이션: Nomad는 다중 리전 페더레이션을 기본 지원해요. 이 내장 기능은 여러 클러스터를 연결할 수 있게 해주며, 개발자가 모든 리전의 모든 클러스터에 작업을 배포할 수 있게 해줘요. 페더레이션은 또한 ACL 정책, 네임스페이스, 리소스 쿼터, Sentinel 정책을 모든 클러스터에 자동 복제할 수 있게 해줘요.
입증된 확장성: Nomad는 낙관적 동시성(optimistically concurrent)을 가지며, 이는 처리량을 높이고 워크로드의 지연 시간을 줄여줘요. Nomad는 실제 프로덕션 환경에서 10K+ 노드의 클러스터로 확장되는 것이 입증됐어요.
HashiCorp 에코시스템: Nomad는 Terraform, Consul, Vault와 매끄럽게 통합되어 프로비저닝, 서비스 검색, 시크릿 관리를 제공해요.

Nomad가 다른 도구와 비교되는 방법 (How Nomad compares to other tools)

다음 특성은 일반적으로 관련 제품과 Nomad를 구별해줘요:

단순성: Nomad는 외부 종속성이 없는 단일 프로세스로 실행돼요. 운영자는 쉽게 Nomad를 프로비저닝, 관리, 확장할 수 있어요. 개발자는 애플리케이션을 쉽게 정의하고 실행할 수 있어요.
유연성: Nomad는 컨테이너화된, 레거시, 마이크로서비스, 일괄 애플리케이션의 다양한 워크로드를 실행할 수 있어요. Nomad는 서비스, 일괄 처리, 시스템 작업을 스케줄링할 수 있고 Linux와 Windows에서 모두 실행될 수 있어요.
확장성과 고성능: Nomad는 초당 수천 개의 컨테이너를 스케줄링하고, 단일 클러스터에서 수천 개의 노드로 확장하며, 리전과 클라우드 공급자에 걸쳐 쉽게 페더레이션할 수 있어요.
HashiCorp 상호운용성: Nomad는 시크릿 관리를 위한 Vault와 서비스 검색 및 동적 구성을 위한 Consul과 우아하게 통합돼요. Nomad의 Consul 유사 아키텍처와 Terraform 유사 작업 명세서는 HashiCorp 스택의 기존 사용자에게 진입 장벽을 낮춰줘요.

비교에 관련된 카테고리가 많아요: 클러스터 매니저, 리소스 매니저, 워크로드 매니저, 스케줄러 등이 있어요. 각 카테고리에는 많은 기존 도구가 있으며 비교가 전체 공간을 모두 다루지는 않아요.

Nomad 대 Kubernetes (Nomad versus Kubernetes)

Kubernetes와 Nomad는 애플리케이션 배포와 관리에서 유사한 핵심 사용 사례를 지원하지만 몇 가지 핵심 방식에서 다르게요. Kubernetes는 클러스터 관리, 스케줄링, 서비스 검색, 모니터링, 시크릿 관리를 포함해 Linux 컨테이너 기반 애플리케이션을 실행하는 데 필요한 모든 기능을 제공하는 것을 목표로 해요. Nomad는 클러스터 관리와 스케줄링에만 초점을 맞추려 하며, 서비스 검색/서비스 메시용 Consul과 시크릿 관리용 Vault 같은 도구와 구성되는 작은 범위를 가지는 Unix 철학으로 설계됐어요.

단순성 (Simplicity)

Kubernetes는 함께 완전한 기능을 제공하는 6개 이상의 상호작용 서비스의 모음으로 설계됐어요. 조정과 스토리지는 핵심에서 etcd가 제공해요. 상태는 API 컨트롤러로 감싸져 있으며, 스케줄링 같은 기능을 위한 상위 수준 API를 제공하는 다른 서비스가 소비해요. Kubernetes는 고가용성 구성으로 실행을 지원하지만 설정이 운영상 복잡해요.

Nomad는 아키텍처상 훨씬 단순해요. Nomad는 클라이언트와 서버 모두 단일 바이너리이며 조정이나 스토리지에 외부 서비스가 필요하지 않아요. Nomad는 경량 리소스 매니저와 정교한 스케줄러를 단일 시스템으로 결합해요. 기본적으로 Nomad는 분산되어 있고 고가용성이며 운영상 단순해요.

유연한 워크로드 지원 (Flexible Workload Support)

Kubernetes는 특히 Linux 컨테이너에 초점을 맞춘 반면, Nomad는 더 범용적이에요. Nomad는 Docker, Java, Windows의 IIS, Qemu 등을 포함한 가상화된, 컨테이너화된, 독립형 애플리케이션을 지원해요. Nomad는 확장 가능한 드라이버로 설계됐으며 모든 공통 드라이버로 지원이 확장될 거예요.

일관된 배포 (Consistent Deployment)

프로덕션 환경을 위한 전체 Kubernetes 설치 기간은 시간이 오래 걸리고 운영상 복잡하며 리소스 집약적이에요. minikube, kubeadm, k3s 등과 같은 이러한 어려움을 완화하기 위해 Kubernetes 커뮤니티가 만든 구현이 점점 늘어나고 있어요. 이렇게 축소된 Kubernetes 버전은 개발과 테스트에 더 쉽게 도입할 수 있지만, 프로덕션으로 이동할 때 기능, 구성, 관리의 불일치를 초래해요.

Kubernetes의 파편화된 배포와 대조적으로, Nomad는 단일 경량 바이너리로 로컬 개발, 프로덕션, 온프레미스, 엣지, 클라우드에 일관된 방식으로 배포할 수 있으며 모든 환경에서 동일한 운영 편의성을 제공해요.

확장성 (Scalability)

Kubernetes 문서는 최대 5,000개 노드와 300,000개 총 컨테이너의 클러스터를 지원한다고 밝혀요. 환경이 커지면서 서로 다른 제약을 가진 상호작용 구성 요소들이 운영 복잡성을 더해요. Google의 운영자조차 대규모로 시스템을 관리하는 상당한 어려움을 밝혔어요. Federation 프로젝트의 미성숙함과 중앙 집중식 관리 평면을 관리하는 추가 오버헤드도 여러 클러스터에 걸친 분산 시스템 배포를 어렵게 해요.

Nomad는 실제 프로덕션 환경에서 10,000개 노드를 초과하는 클러스터 크기로 확장되는 것이 입증됐어요. 단일 클러스터 또는 여러 클러스터로 여러 가용성 영역, 리전, 데이터 센터에 걸쳐 배포할 수 있어요. Nomad는 클러스터 위에 클러스터를 실행하는 오버헤드 없이 다중 클러스터 배포를 기본적으로 처리하도록 설계됐어요. 이는 추가 복잡성 없이 여러 데이터 센터, 리전, 클라우드에 걸쳐 애플리케이션 배포를 더 쉽게 확장하게 해줘요.

Nomad는 2016년 1백만 컨테이너 챌린지와 2020년 2백만 컨테이너 챌린지로 확장성에 대한 힘든 벤치마크를 수행했어요. 이 테스트는 Nomad의 아키텍처 설계를 검증하고 Nomad가 가장 극단적인 요구 사항에서도 작동하는지 확인하는 것을 목표로 해요.

Kubernetes의 보완 (Supplement to Kubernetes)

기업은 프로젝트, 인프라 환경, 기술 역량, 팀 규모, 예산, SLA가 다른 여러 그룹(사업 단위)으로 구성돼 있어요. 각 그룹은 서로 다른 요구 사항을 가지며 특정 요구와 제약에 따라 기술을 활용해요.

중대형 기업은 수백에서 수천 명의 소프트웨어 개발자와 관리자를 단일 오케스트레이터(Kubernetes, Nomad, Mesos)로 표준화하려고 할 때 어려움을 겪어요. 오늘날 어떤 스케줄러도 모든 애플리케이션, 환경, 프로젝트, 팀에 맞지 않기 때문이에요.

오늘날 Intel, Autodesk, GitHub 같은 글로벌 2000대 기업은 여러 제품과 사업 단위를 가지고 있으며 Nomad와 Kubernetes를 자연스럽게 실행해 서로를 보완해요. 각 스케줄러의 강점을 활용해 Kubernetes는 최첨단 에코시스템을, Nomad는 핵심 스케줄링에서의 단순한 유지 관리와 유연성을 활용해요.

이것은 일반적으로 자체 호스팅 Kubernetes를 채택하는 팀에서 보이는 특성이에요:

Kubernetes 에코시스템과 Helm 차트가 필요한 그린필드 사용 사례: 머신 러닝(ML), 서버리스, 빅데이터
Kubernetes를 유지 관리하기 위한 높은 예산과 전담 직원
상당한 투자와 장기 일정(수년)을 가진 고도로 가시적인 프로젝트
새롭고 클라우드 네이티브한 애플리케이션 배포 및 관리
AWS, GCP, Azure 같은 공용 클라우드 환경

일반적으로 Nomad를 채택하는 팀의 특성:

컨테이너화된 것과 비컨테이너화된 워크로드의 혼합 실행 (Windows, Java)
오케스트레이터를 유지할 역량이 제한적인 중소 규모 팀
핵심적이고 기존의 애플리케이션 배포 및 관리
온프레미스 환경 또는 하이브리드 환경
빠르게 움직이고 마감 기한이 빡빡한 비즈니스 요구를 충족하기 위한 단순성 요구

자연스러운 인력 및 조직적 제약 때문에 소규모 기업이 단일 오케스트레이터를 계속 표준화하는 것을 보고 있어요. 하나 이상의 오케스트레이터를 유지할 DevOps 구성원이 충분하지 않고, 워크플로를 분기시킬 개발자도 충분하지 않으며, 둘 이상의 오케스트레이터를 요구할 만큼 워크로드 다양성이 충분하지 않아요.

리소스 (Resources)

Nomad와 Kubernetes 간의 심층 비교는 다음 리소스를 검토해 주세요:

Nomad 대 AWS ECS (Nomad versus AWS ECS)

Amazon Web Services는 클러스터 매니저인 Elastic Container Service (ECS)를 제공해요. ECS 서비스는 AWS 안에서만 사용할 수 있고 Docker 워크로드에만 사용할 수 있어요. Amazon은 고객에게 EC2 인스턴스에 설치된 에이전트를 제공하지만, AWS의 호스팅 서비스인 서버는 제공하지 않아요.

Nomad와 ECS 사이에는 근본적인 차이가 여러 가지 있어요. Nomad는 클라이언트와 서버 구성 요소를 모두 포함해 완전히 오픈 소스예요. 대조적으로 ECS의 에이전트 코드만 공개되어 있고 서버는 비공개 소스이며 Amazon이 관리해요.

ECS 서버가 AWS에 의해 관리되는 부작용으로 AWS 밖에서는 ECS를 사용할 수 없어요. Nomad는 실행되는 환경에 구애받지 않으며(agnostic) 공용·프라이빗 클라우드와 bare metal 데이터 센터를 모두 지원해요. Nomad의 클러스터는 여러 데이터 센터와 리전에 걸쳐 있을 수 있으며, 단일 클러스터가 AWS, Azure, GCE의 머신을 동시에 관리할 수 있다는 의미예요.

ECS 서비스는 특히 컨테이너와 Docker 엔진에 초점을 맞추는 반면, Nomad는 더 범용적이에요. Nomad는 Docker를 포함한 가상화된, 컨테이너화된, 독립형 애플리케이션을 지원해요. Nomad는 확장 가능한 드라이버로 설계됐으며 모든 공통 드라이버로 지원이 확장될 거예요.

Nomad 대 Terraform (Nomad versus Terraform)

Terraform은 인프라를 안전하고 효율적으로 구축, 변경, 버전 관리하는 도구예요. 구성 파일은 단일 애플리케이션이나 전체 데이터 센터를 실행하는 데 필요한 구성 요소를 Terraform에 설명해요. Terraform은 원하는 상태에 도달하기 위해 무엇을 할지 설명하는 실행 계획을 생성한 다음 이를 실행해 설명된 인프라를 구축해요. 구성이 변경되면 Terraform은 무엇이 변경됐는지 판단하고 적용할 수 있는 증분 실행 계획을 만들 수 있어요.

Nomad는 여러 핵심 방식에서 Terraform과 달라요. Terraform은 컴퓨트 인스턴스, 스토리지, 네트워킹 같은 저수준 구성 요소와 DNS 항목, SaaS 기능 같은 고수준 구성 요소를 포함한 모든 유형의 리소스를 지원하도록 설계됐어요. Terraform은 이러한 리소스의 수명 주기를 만들고, 프로비저닝하고, 관리하는 방법을 알고 있어요. Nomad는 기존 인프라에서 실행되며 그 인프라에서 실행되는 애플리케이션의 수명 주기를 관리해요.

또 다른 주요 차이점은 Terraform이 완료될 때까지 실행되는 오프라인 도구인 반면, Nomad는 장기 실행 서버가 있는 온라인 시스템이라는 점이에요. Nomad는 새 작업 제출, 기존 작업 업데이트/삭제를 허용하며 노드 실패를 처리할 수 있어요. 이는 Terraform처럼 단발성으로가 아니라 지속적으로 운영해야 함을 의미해요.

서버나 애플리케이션이 소수인 소규모 인프라의 경우 Nomad의 복잡성이 단순히 Terraform으로 애플리케이션을 머신에 정적으로 할당하는 것보다 나을 것이 없을 수 있어요. 더 큰 규모에서는 Terraform으로 Nomad의 용량을 프로비저닝하고, Nomad로 애플리케이션을 머신에 동적으로 스케줄링하는 것을 관리해야 해요.

다음 단계 (Next steps)

오늘날 많은 산업에서 Nomad가 실제 비즈니스 목표를 해결하기 위해 프로덕션에서 어떻게 사용되는지 다양한 방식을 이해하려면 사용 사례를 검토해 주세요.