프로덕션 참조 아키텍처

프로덕션 참조 아키텍처 (Production reference architecture)

이 문서는 노마드 프로덕션 배포를 위한 권장 사례와 참조 아키텍처를 제공해요. 이 참조 아키텍처는 각 구현의 특정 요구사항에 맞게 조정해야 하는 일반적인 아키텍처를 제시해요.

다음 주제를 다루어요:

• 참조 아키텍처(Reference Architecture)
• 단일 리전 내 배포 토폴로지
• 멀티 리전 배포 토폴로지
• 네트워크 연결 세부사항
• 배포 시스템 요구사항
• 고가용성(High Availability)
• 장애 시나리오

이 문서는 Consul 클러스터와 함께, 또는 접근 가능한 Consul 클러스터와 함께 노마드 클러스터를 배포하는 것을 설명해요. 자동 클러스터링, 서비스 디스커버리, 헬스 체크, 동적 구성을 제공하려면 노마드와 함께 Consul을 사용하는 것을 권장해요.

출처: 문서

본문

참조 아키텍처

노마드 클러스터는 일반적으로 3개 또는 5개(그 이상은 7개가 최대)의 서버와 다수의 클라이언트 에이전트로 구성돼요. 노마드는 인프라를 하나의 노마드 서버 클러스터가 서비스하는 리전으로 나눈다는 점에서 Consul과 약간 달라요. 하지만 하나의 리전은 여러 데이터센터나 가용 영역(AZ)을 관리할 수 있어요. 예를 들어 US 리전은 us-east-1과 us-west-2 데이터센터를 포함할 수 있어요.

노마드 멀티 리전 아키텍처에서 통신은 WAN gossip을 통해 이뤄져요. 또한 노마드는 자동 클러스터링, 서비스 디스커버리, 동적 구성 같은 기능을 제공하기 위해 Consul과 쉽게 통합할 수 있어요. 따라서 배포를 단순화하려면 노마드 배포에 Consul을 사용할 것을 권장해요.

클라우드 환경에서는 단일 클러스터를 여러 가용 영역에 걸쳐 배포할 수 있어요. 예를 들어 AWS에서 각 노마드 서버는 연결된 EC2 인스턴스에 배포될 수 있고, 그 EC2 인스턴스들은 여러 AZ에 분산될 수 있어요. 마찬가지로 노마드 서버 클러스터를 여러 클라우드 리전에 배포해 리전 수준의 HA 시나리오를 지원할 수 있어요.

노마드 서버 클러스터 설계에 대한 자세한 내용은 클러스터 요구사항 문서를 참고해 주세요.

이 문서에서 공유하는 설계는 유연성과 복원력을 제공하므로 프로덕션 환경에 권장되는 아키텍처예요. 노마드는 기존 Consul 서버 클러스터를 활용하지만, Consul 서버 클러스터의 배포 설계는 이 문서의 범위 밖이에요.

노마드에서 Consul로의 연결은 HTTP를 통하며, 모든 트래픽의 암호화를 위해 TLS와 Consul 토큰으로 보호해야 해요. 이는 노마드의 Automatic Clustering with Consul로 수행돼요.

단일 리전 내 배포 토폴로지

같은 리전에 배포되는 애플리케이션에는 단일 노마드 클러스터를 권장해요.

각 클러스터는 3개 또는 5개의 서버를 갖는 것이 좋아요. 이는 장애 시 가용성과 성능 사이의 균형을 이뤄요. Raft 합의는 서버가 늘어날수록 점점 느려지기 때문이에요.

새 서버가 기존의 대규모 클러스터에 조인하는 데 걸리는 시간은 클러스터의 크기가 커질수록 늘어날 수 있어요.

참조 다이어그램

([참조 다이어그램 이미지])

멀티 리전 배포 토폴로지

여러 리전에 노마드 서버 클러스터를 배포하면, 사용자는 서버가 별도의 리전에 있더라도 어떤 노마드 서버에서든 어떤 리전을 대상으로 해서 노마드 서버와 상호작용할 수 있어요. 하지만 대부분의 데이터는 완전히 독립적인 클러스터이므로 리전 간 복제되지 않아요. 리전 간에 복제되는 예외는 다음과 같아요:

• ACL 정책과 글로벌 토큰
• 노마드 엔터프라이즈의 Sentinel 정책

서로 다른 데이터센터의 노마드 서버 클러스터는 WAN 링크로 연합(federate)될 수 있어요. 서버 클러스터는 포트 4648의 WAN에서 통신하도록 조인될 수 있어요. 이와 동일한 포트가 단일 데이터센터 배포에서 LAN을 통해서도 사용돼요.

노마드 클러스터 연합에 대해 자세히 알아보는 추가 문서가 제공돼요.

네트워크 연결 세부사항

([노마드 네트워크 다이어그램 이미지])

노마드 서버는 고대역폭, 저지연 네트워크 환경에서 통신할 수 있어야 하며 클러스터 멤버 간 10밀리초 미만의 지연 시간을 가져야 해요. 이 지연 시간 요구사항을 충족한다면 노마드 서버는 클라우드 리전이나 데이터센터에 분산될 수 있어요.

노마드 클라이언트 클러스터는 Network Connectivity Details에 명시된 대로 트래픽을 받을 수 있어야 해요. 하지만 클라이언트는 노마드 서버에서 도달 가능하고 작업 요청을 받을 수만 있다면 어떤 유형의 인프라(멀티 클라우드, 온프레미스, 가상, 베어메탈 등)에도 분리될 수 있어요.

노마드 네트워킹에 대해 자세히 알아보는 추가 문서가 제공돼요.

배포 시스템 요구사항

노마드 서버 에이전트는 클러스터 상태 유지, RPC 쿼리(읽기 작업) 응답, 모든 쓰기 작업 처리의 책임을 져요. 노마드 서버 에이전트가 대부분의 무거운 작업을 수행하므로, 서버 크기 결정은 노마드 클러스터의 전반적인 성능 효율성과 건강에 매우 중요해요.

노마드 서버

	Type	CPU	Memory	Disk	Typical Cloud Instance Types
	Small	2-4 core	8-16 GB RAM	50 GB	AWS: m5.large, m5.xlarge
					Azure: Standard_D2_v3, Standard_D4_v3
					GCP: n2-standard-2, n2-standard-4
	Large	8-16 core	32-64 GB RAM	100 GB	AWS: m5.2xlarge, m5.4xlarge
					Azure: Standard_D8_v3, Standard_D16_v3
					GCP: n2-standard-8, n2-standard-16

하드웨어 크기 결정 고려사항

• Small 크기는 대부분의 초기 프로덕션 배포나 개발/테스트 환경에 적합해요.
• Large 크기는 지속적으로 높은 워크로드가 있는 프로덕션 환경용이에요.

참고: 대규모 워크로드의 경우 빠른 Raft 로그 업데이트 속도를 따라잡을 수 있도록 디스크가 높은 IOPS를 지원하는지 확인해 주세요.

노마드 클라이언트도 특수 워크로드로 설정할 수 있어요. 예를 들어 워크로드가 GPU 처리를 요구한다면, 그 GPU 특정 작업을 서비스하기 위한 노마드 데이터센터를 만들고 노마드 서버 클러스터에 조인시킬 수 있어요. 특수 워크로드에 대한 자세한 내용은 특정 클라이언트 노드를 대상으로 하는 작업 제약(constraints) 문서를 참고해 주세요.

고가용성

노마드 서버 클러스터는 단일 데이터센터 내 고가용성 배포의 단위예요. 권장되는 방식은 3개 또는 5개 노드의 노마드 서버 클러스터를 배포하는 거예요. 이 구성에서는 노마드 서버 중단 시 사람의 개입 없이 즉시 장애 조치가 처리돼요.

리전 전반의 고가용성을 설정할 때는 여러 노마드 서버 클러스터를 배포하고 WAN gossip으로 연결해요. 리전의 노마드 클러스터는 서로 완전히 독립적이며 작업, 클라이언트, 상태를 공유하지 않아요. 단일 리전별 클러스터에 있는 데이터는 다른 리전의 클러스터로 복제되지 않아요.

장애 시나리오

클라우드 환경의 일반적인 분산은 AWS 리전 같은 고대역폭, 저지연 네트워크 내에서 노마드 서버 노드를 별도의 가용 영역(AZ)으로 나누는 거예요. 아래 다이어그램은 여러 AZ에 배포된 노마드 서버가 각 AZ당 하나의 투표 멤버를 선출하고 AZ 수준과 노드 수준의 장애 보호를 모두 제공하는 모습을 보여줘요.

([노마드 내결함성 다이어그램 이미지])

클러스터 크기 결정과 장애 허용, 그리고 중단 복구에 대해 자세히 알아보는 추가 문서가 제공돼요.

가용 영역 장애

단일 AZ 장애가 발생하면 오직 하나의 노마드 서버만 영향을 받으며, Raft 쿼럼이 여전히 존재하는 한(즉 3 서버 클러스터에서 2개, 5 서버 클러스터에서 3개의 서버가 사용 가능한 경우, 일반적으로는 다음과 같음) 작업 스케줄링에 영향을 주지 않아요:

quorum = floor( count(members) / 2) + 1

멀티 AZ 구성에서 AZ가 장애 나면 두 가지 시나리오가 발생할 수 있어요: 리더 손실 또는 팔로워 손실.

리더 서버 손실

노마드 리더 서버가 포함된 AZ가 실패하면, 남은 쿼럼 멤버들이 새 리더를 선출해요. 그러면 새 리더가 새 로그 항목을 받아들이기 시작하고 이 항목들을 남은 팔로워에게 복제해요.

팔로워 서버 손실

노마드 팔로워 서버가 포함된 AZ가 실패하면, 노마드 리더 서버나 클러스터 운영에 즉각적인 영향은 없어요. 하지만 미래의 노마드 리더 서버 장애를 제대로 관리하려면 여전히 Raft 쿼럼이 있어야 해요.

리전 장애

리전 수준 장애(전체 노마드 서버 클러스터를 포함하는)가 발생하면, 클라이언트는 제대로 연합된 다른 리전에 작업을 제출할 수 있어요. 하지만 노마드 서버 클러스터는 데이터를 다른 리전 클러스터에 복제하지 않으므로 데이터 손실이 발생할 가능성이 높아요. 설정 방법은 Multi-region Federation을 참고해 주세요.

다음 단계

Deployment Guide를 읽어 Consul을 사용하는 단일 HashiCorp Nomad 클러스터를 설치하고 구성하는 데 필요한 단계를 배워요.

더 알아보기 (Learn more)

• 노마드 배포 가이드
• 멀티 리전 연합
• 하드웨어 요구사항