서버 리소스 요구 사항 참조
서버 리소스 요구 사항 참조 (Server Resource Requirements Reference)
이 페이지는 Consul이 운영에 필요한 서버 리소스에 대한 참조를 제공해요. 하드웨어 요구 사항, Raft 성능 튜닝 기본값, 메모리 및 읽기/쓰기 튜닝 지침을 다뤄요.
출처: 문서
본문
이 페이지는 Consul이 운영에 필요한 서버 리소스에 대한 참조를 제공해요.
소개 (Introduction)
Consul 서버는 모든 쓰기 작업을 처리하기 위해 합의 프로토콜을 실행하고 거의 모든 읽기 작업에서 접근되므로 서버 성능이 Consul 클러스터의 전체 처리량과 상태에 중요해요. 서버는 일반적으로 쓰기에서 I/O 바운드입니다. 기반 Raft 로그 저장소가 항목이 추가될 때마다 디스크에 동기화를 수행하기 때문이에요. 서버는 읽기에서 일반적으로 CPU 바운드입니다. 읽기는 동시 접근에 최적화된 완전 인메모리 데이터 저장소에서 동작하기 때문이에요.
하드웨어 요구 사항 (Hardware requirements)
프로덕션 클러스터의 Consul 서버에 대한 최소 하드웨어 요구 사항은 다음과 같아요:
| CPU | 메모리 | 디스크 용량 | 디스크 IO | 디스크 처리량 | 평균 왕복 시간 | 99% 왕복 시간 |
|---|---|---|---|---|---|---|
| 8-16 코어 | 32-64 GB RAM | 200+ GB | 7500+ IOPS | 250+ MB/s | 50ms 미만 | 100ms 미만 |
하드웨어 요구 사항은 Consul 클러스터의 크기, 클라이언트 에이전트 수, 읽기 중심 및 쓰기 중심 사용 같은 워크로드 특성에 따라 증가해요. Consul은 테스트 및 개발 목적의 더 작은 하드웨어 구성에서 실행될 수 있지만, 프로덕션 환경에서 최적의 성능과 신뢰성을 보장하고 용량 장애 중에 하드웨어를 업그레이드하지 않도록 하기 위해 이러한 최소 사양을 권장해요.
다음 표는 각 주요 클라우드 인프라 제공자의 하드웨어 인스턴스에 대한 권장 시작점을 제공해요.
| 제공자 | 인스턴스/VM 유형 | 디스크 볼륨 사양 |
|---|---|---|
| AWS | m5.2xlarge, m5.4xlarge |
200+GB gp3, 10000 IOPS, 250MB/s |
| Azure | Standard_D8s_v3, Standard_D16s_v3 |
2048GB* Premium SSD, 7500 IOPS, 200MB/s |
| GCP | n2-standard-8, n2-standard-16 |
1000GB* pd-ssd, 30000 IOPS, 480MB/s |
Raft 성능 튜닝 기본값 (Raft performance tuning defaults)
Consul 서버 성능 매개변수의 기본값은 Consul이 세 대의 AWS t2.micro 인스턴스 서버 클러스터에서 실행된다고 가정해요. 이 임계값은 충분한 읽기, 쓰기, 네트워크 부하 하에서 CPU 크레딧이 영구적으로 0이 되어 해당 인스턴스 유형의 기준 성능 모드로 강제된 리더 인스턴스를 사용해 경험적으로 결정되었어요. 실제 워크로드는 일반적으로 활동 버스트가 더 많으므로 이는 보수적인 튜닝 전략이에요.
이 기본값을 선택한 이유는 더 낮은 비용의 컴퓨팅 리소스로 소규모 프로덕션 또는 개발 클러스터를 실행할 수 있게 하기 위해서이며, 리더 장애 감지와 리더 선출 시간의 일부 성능을 희생한 결과예요.
기본 설정은 다음 Consul 서버 에이전트 구성과 동일해요:
JSON:
{
"performance": {
"raft_multiplier": 5
}
}
HCL:
performance {
raft_multiplier = 5
}
프로덕션에서는 Consul 서버 성능 매개변수를 가능한 가장 낮은 Raft 배율 설정인 1로 구성할 것을 권장해요. 이 설정은 더 높은 리소스 소비를 대가로 Consul 서버가 기본 구성보다 더 빨리 실패한 리더를 감지하고 리더 선거를 완료할 수 있게 해요. 특별한 이유로 더 느린 기본 구성을 사용하지 않는 한 프로덕션의 Consul 클러스터에서 이 더 높은 성능 구성을 권장해요. 예를 들어 저가형 하드웨어, 높은 지연 시간 네트워크, 또는 워크로드를 공유하는 인스턴스에서 실행되는 워크로드는 추가 리소스에 접근하지 못하거나 최고 성능 수준에서 운영하기 위해 이를 필요로 하지 않을 수 있어요.
Consul 서버 에이전트의 고성능 설정은 다음 구성으로 표시돼요:
JSON:
{
"performance": {
"raft_multiplier": 1
}
}
HCL:
performance {
raft_multiplier = 1
}
이 값은 서버 간 네트워크 지연과 서버의 읽기/쓰기 부하를 고려해야 해요.
raft_multiplier 값은 배율 요소이며 다음 매개변수에 직접 영향을 미쳐요:
| 매개변수 | 값 | |
|---|---|---|
| HeartbeatTimeout | 1000ms | 기본값 |
| ElectionTimeout | 1000ms | 기본값 |
| LeaderLeaseTimeout | 500ms | 기본값 |
기본적으로 Consul은 5(즉 raft_multiplier: 5)의 배율 요소를 사용하며, 그 결과는 다음과 같아요:
| 매개변수 | 값 | 계산 |
|---|---|---|
| HeartbeatTimeout | 5000ms | 5 x 1000ms |
| ElectionTimeout | 5000ms | 5 x 1000ms |
| LeaderLeaseTimeout | 2500ms | 5 x 500ms |
참고 (NOTE) 지연이 더 큰 광범위한 네트워크는 더 큰 raft_multiplier 값에서 더 잘 동작해요.
절충점은 리더 안정성과 실제 리더 장애로부터의 복구 시간 사이에 있어요. 짧은 배율은 장애 감지 및 선출 시간을 최소화하지만 지연이 높은 상황에서는 자주 트리거될 수 있어요. 이는 지속적인 리더십 변동(churn)과 관련 비가용성을 초래할 수 있어요. 높은 배율은 가짜 장애가 리더십 변동을 일으킬 확률을 줄이지만, 실제 장애를 감지하는 데 더 오래 걸리고 따라서 클러스터 가용성을 복원하는 데 더 오래 걸리는 대가를 치러요.
리더십 불안정은 CPU 리소스가 부족하게 프로비저닝된 경우에도 발생할 수 있으며, CPU 사이클을 다른 워크로드와 공유하는 환경에서 더 자주 발생해요. 서버가 리더로 유지되려면 몇 백 밀리초마다 다른 모든 서버에 빈번한 하트비트 메시지를 보내야 해요. 리더가 충분한 CPU를 확보하지 못해 이 중 일부가 누락되거나 지연되면 다른 서버는 이를 실패로 감지하고 새 선거를 실시해요.
Consul용 프로덕션 서버를 선택할 때는 현실적인 워크로드로 벤치마킹하는 것이 가장 좋아요. 일반적인 권장 사항은 다음과 같아요:
- Consul은 여러 코어를 활용하며 최소 2코어를 권장해요.
- 가짜 리더 선거는 서버 간 네트워킹 문제나 불충분한 CPU 리소스로 발생할 수 있어요. 클라우드 환경의 사용자는 리더 선거가 안정될 때까지 서버를 네트워킹과 CPU가 개선된 다음 인스턴스 클래스로 올리는 경우가 많아요. Consul 0.7 이상에서는 이제 성능 매개변수 구성을 통해 서버를 키우는 대신 성능을 절충할 수 있는 도구를 제공해요.
consul.raft.leader.lastContact텔레메트리를 사용해 Raft 타이밍이 어떻게 동작하는지 관찰하고 Raft 성능을 낮추거나 더 강력한 서버를 추가할지 결정하는 데 참고할 수 있어요. - DNS 중심 워크로드의 경우 클러스터의 모든 Consul 에이전트를
allow_stale구성 옵션으로 구성하면 리더뿐 아니라 모든 Consul 서버에서 읽기가 확장될 수 있어요. Consul 0.7 이상은 DNS에 대한 stale 읽기를 기본적으로 활성화해요. 자세한 내용은 DNS 캐싱 가이드의 Stale Reads를 참고해요. 클라이언트가 따를 것이라면 합리적인 0이 아닌 DNS TTL 값을 설정하는 것도 좋아요. - Consul에 대해 대량 읽기를 수행하는 다른 애플리케이션에서는 읽기가 리더로만 전달되지 않고 모든 서버에서 확장되도록 stale 일관성 모드 사용을 고려해요.
- Consul 0.9.3 이상에서는 Consul 클라이언트가 Consul 서버에 대해 수행할 수 있는 RPC 요청 속도를 제한하는 새로운
limits구성이 제공돼요. 제한에 도달하면 시간이 지나 더 많은 요청이 허용될 때까지 요청이 속도 제한 오류를 반환하기 시작해요. 클러스터 전반에 이 구성을 적용하면 서버에서 최대 원하는 애플리케이션 로드 수준을 강제할 수 있고 악성 애플리케이션을 완화하는 데 도움이 될 수 있어요.
메모리 요구 사항 (Memory Requirements)
Consul 서버 에이전트는 키/값 항목, 서비스 카탈로그, 준비된 쿼리, 액세스 제어 목록, 세션으로 구성된 작업 집합(working set) 데이터를 메모리에 보관하며 동작해요. 이 데이터는 내구성을 위해 스냅샷과 이전 스냅샷 이후의 변경 로그 형태로 Raft를 통해 디스크에 저장돼요.
메모리 요구 사항을 계획할 때 일반적으로 서버 에이전트가 작업 집합 크기의 2배에서 4배를 담을 수 있는 충분한 RAM을 할당해야 해요. 텔레메트리 데이터에서 consul.runtime.alloc_bytes 값을 확인해 작업 집합 크기를 결정할 수 있어요.
참고 (NOTE): Consul은 일반적인 목적의 데이터베이스 역할을 하도록 설계되지 않았으므로 키/값 저장소에 어떤 데이터를 채울지 선택할 때 이를 염두에 두어야 해요.
읽기/쓰기 튜닝 (Read/Write Tuning)
Consul은 디스크 I/O에 의해 쓰기가 제한되고 CPU에 의해 읽기가 제한돼요. 메모리 요구는 저장된 KV 쌍의 총 크기에 따라 달라지며 (하드 드라이브 스토리지도 마찬가지로) 그 데이터에 맞게 크기를 조정해야 해요. 키의 값 크기 제한은 512KB예요.
Consul은 디스크 I/O에 의해 쓰기가 제한되고 CPU에 의해 읽기가 제한돼요.
쓰기 중심(write-heavy) 워크로드의 경우 오버헤드에 사용 가능한 총 RAM은 대략 다음과 같아야 해요:
RAM NEEDED = number of keys * average key size * 2-3x
쓰기는 커밋되기 전에 서버 쿼럼(quorum)에서 디스크(영구 스토리지)에 동기화되어야 하므로 높은 쓰기 처리량(또는 SSD)의 디스크를 배포하면 쓰기 측 성능이 향상돼요. (문서)
읽기 중심(read-heavy) 워크로드의 경우 모든 Consul 서버 에이전트를 allow_stale DNS 옵션으로 구성하거나 stale 일관성 모드로 API를 쿼리해요. 기본적으로 서버에 대한 모든 쿼리는 리더로 RPC 전달되어 서비스됩니다. stale 읽기를 활성화하면 어떤 서버든 어떤 쿼리에도 응답하므로 리더의 오버헤드가 줄어들어요. 일반적으로 stale 응답은 일관성 모드보다 100ms 이하로 느리지만 고부하에서 성능을 크게 개선하고 지연 시간을 줄여요.
리더 서버에서 메모리가 부족하거나 디스크가 가득 차면 서버는 결국 응답을 멈추고 선거를 잃게 되며 마지막 커밋 시간을 넘어서지 못해요. 그러나 max_stale을 구성하고 큰 값으로 설정하면 Consul은 이러한 장애 시나리오 중에도 쿼리에 계속 응답해요. (max_stale 문서)
stale은 강한 일관성이 중요한 조정(coordination, 즉 잠금이나 애플리케이션 리더 선거)에는 적합하지 않다는 점에 유의해야 해요. 중요한 경우 진정한 선형화 가능성(linearizability)을 위해 선택적인 consistent API 쿼리 모드가 필요해요. 트레이드오프는 이로 인해 읽기가 완전한 쿼럼 쓰기로 바뀌므로 더 많은 리소스가 필요하고 더 오래 걸린다는 점이에요.
읽기 중심 클러스터는 더 나은 확장성을 위해 향상된 읽기 기능(Enterprise)을 활용할 수 있어요. 이 기능은 추가 서버를 비투표자(non-voters)로 도입할 수 있게 해요. 비투표자로서 서버는 데이터 복제에는 계속 참여하지만 리더가 로그 항목을 커밋하는 것을 막지는 않아요.
Consul의 에이전트는 다른 노드(가십) 및 서버 에이전트와 통신하기 위해 네트워크 소켓을 사용해요. 또한 파일 디스크립터는 watch 핸들러, 헬스 체크, 로그 파일에 대해 열려요. 쓰기 중심 클러스터의 경우 리더가 파일 디스크립터를 소진하지 않도록 ulimit 크기를 기본값(1024)에서 늘려야 해요.
잘못 구성된 클라이언트의 CPU 스파이크를 방지하기 위해 서버에 대한 RPC 요청은 속도 제한되어야 해요.
참고 (NOTE) 속도 제한은 클라이언트 에이전트에서만 구성돼요.
또한 consul.runtime.alloc_bytes와 consul.runtime.heap_objects라는 두 가지 성능 지표가 현재 크기가 부하를 적절히 충족하지 못하는지 진단하는 데 도움이 될 수 있어요.
서비스 메시 인증서 서명 CPU 제한 (Service Mesh Certificate Signing CPU Limits)
서비스 메시를 활성화하면 리더 서버가 클러스터의 모든 서비스 인스턴스에 대해 공개 키 서명 작업을 수행해야 해요. 일반적으로 이러한 작업은 최신 하드웨어에서 빠르지만, CA가 변경되거나 키가 교체되면 리더는 실행 중인 모든 서비스 인스턴스에 대한 새 인증서 요청이 쏟아지게 돼요.
클라이언트 에이전트는 즉각적인 스레딩 허드(thundering herd)를 피하기 위해 이를 30초에 걸쳐 무작위로 분산하지만, 클러스터에서 사용되는 인증서 수에 따라 해당 기간을 조정할 정보가 충분하지 않아 더 긴 스미어링(smearing)을 선택하면 소규모 클러스터에서 인위적으로 느린 교체가 발생해요.
요청을 30초에 걸쳐 스미어링하면 가장 큰 클러스터를 제외한 모든 클러스터에서 RPC 부하를 합리적인 수준으로 낮추기에 충분하지만, 암호화 작업의 추가 CPU 부하가 서버의 정상 작업에 영향을 줄 수 있어요. 이를 제한하기 위해 Consul은 1.4.1부터 인증서 서명이 리더에 미치는 영향을 제한하는 두 가지 방법인 csr_max_per_second와 csr_max_concurrent를 제공해요.
기본적으로 초당 50개 제한을 설정하는데, 이는 보급형 하드웨어에서 합리적이지만 클러스터에서 1500개 이상의 서비스 인스턴스가 서비스 메시를 사용한다면 너무 낮아 회전 시간에 영향을 줄 수 있어요. 사용 가능한 코어가 4개 미만이라면 서명에 전체 코어가 사용되는 것이 서버 안정성에 영향을 줄 수 있으므로 csr_max_per_second가 가장 적합해요. 단점은 용량 계획이 필요하다는 것이에요. 몇 개의 서비스 인스턴스가 서비스 메시 인증서를 필요로 할까? 서버가 안정성에 영향을 주지 않고 견딜 수 있는 CSR 속도는 얼마일까? CA 교체를 얼마나 빨리 처리하고 싶을까?
더 큰 프로덕션 배포의 경우 일반적으로 서버가 정상 워크로드를 처리하려면 여러 CPU 코어를 권장해요. 코어가 4개 이상이면 속도 제한을 조정하는 것보다 csr_max_concurrent로 서명 CPU 영향을 제한하는 것이 더 간단해요. 이는 인증서 서명 작업이 독점할 수 있는 CPU 코어 수를 효과적으로 설정해요(특정 코어에 고정하지는 않지만). 이 경우 csr_max_per_second는 비활성화(0으로 설정)해야 해요.
예를 들어 8코어 서버가 있다면 csr_max_concurrent를 1로 설정하면 사용 가능한 모든 CPU 코어를 소비하거나 정상 서버 작업과 안정성에 영향을 주지 않으면서 단일 코어가 처리할 수 있는 만큼의 CSR을 처리할 수 있어요(매우 큰 클러스터에는 충분할 가능성이 높아요).