용량 계획
용량 계획 (Capacity Planning)
프로덕션 환경에서 Consul 클러스터를 배포하고 유지할 때의 용량 계획 권장 사항을 설명하는 문서예요. 리소스 요구 사항, 워크로드 특성, 모니터링, Raft 튜닝을 다뤄요.
출처: 문서
본문
이 페이지는 프로덕션 환경에서 Consul 클러스터를 배포하고 유지할 때의 용량 계획 권장 사항을 설명해요. 조직이 프로덕션 환경을 설계할 때 사용 가능한 리소스와 그것이 네트워크 용량에 미치는 영향을 고려해야 해요.
소개 (Introduction)
서버 인스턴스의 올바른 크기를 선택하는 것이 중요해요. Consul 서버 환경에는 표준적인 최소 요구 사항 집합이 있어요. 그러나 이러한 요구 사항은 Consul을 무엇에 사용하는지에 따라 달라질 수 있어요.
리소스 할당이 부족하면 네트워크 문제나 전반적인 성능 저하가 발생할 수 있어요. 성능 저하로 Consul 리더 노드가 충분한 시간 내에 요청에 응답하지 못하면 Consul 클러스터가 새 리더 선거를 트리거해요. Consul은 선거가 끝날 때까지 모든 네트워크 요청과 Raft 업데이트를 일시 중지해요.
워크로드 입력 및 출력 요구 사항 (Workload input and output requirements)
워크로드는 Consul 클러스터와 상호 작용하는 모든 작업이에요. 이러한 작업은 키/값 읽기 및 쓰기, 서비스 등록 및 등록 해제, Consul 클라이언트 에이전트 추가 또는 제거 등으로 구성돼요.
초당 입출력 작업(IOPS)은 인접하지 않은 저장 위치에 대한 읽기 및 쓰기 양을 측정하는 단위예요. 높은 워크로드의 경우 Consul 서버 디스크가 빠른 Raft 로그 업데이트 속도를 따라갈 수 있도록 높은 IOPS 수를 지원하는지 확인해요. 베어메탈 환경과 달리 클라우드 환경의 가상 인스턴스에서는 IOPS가 저장 크기에 묶여 있는 경우가 많아요. 저장 GB가 많을수록 일반적으로 더 많은 IOPS를 얻을 수 있어요. 따라서 IOPS 최적화 인스턴스에 배포할 것을 권장해요.
Consul 서버 에이전트는 일반적으로 쓰기에는 I/O 바운드이고 읽기에는 CPU 바운드예요. 추가 튜닝 권장 사항은 Raft 튜닝을 참고하세요.
메모리 요구 사항 (Memory requirements)
서버 에이전트가 작업 집합(working set) 크기의 2~4배를 포함하도록 서버 에이전트에 RAM을 할당해야 해요. 실행 중인 클러스터의 작업 집합 크기는 리더 노드의 텔레메트리 데이터에서 consul.runtime.alloc_bytes 값을 확인해 결정할 수 있어요. 모니터링 솔루션에서 텔레메트리 값을 검사하거나, Consul 리더 인스턴스에 설치된 jq 도구로 다음 명령을 실행해요.
참고 팁
Kubernetes의 경우 리더 파드에서 명령을 실행하세요.
jq는 Consul 서버 컨테이너에서 사용할 수 있어요.
$CONSUL_HTTP_TOKEN을 유효한 권한이 있는 ACL 토큰으로 설정한 다음 작업 집합 크기를 가져와요.
$ curl --silent --header "X-Consul-Token: $CONSUL_HTTP_TOKEN" http://127.0.0.1:8500/v1/agent/metrics | jq '.Gauges[] | select(.Name=="consul.runtime.alloc_bytes") | .Value'
616017920
Kubernetes 저장 요구 사항 (Kubernetes storage requirements)
영구 볼륨(PV) 리소스를 설정할 때 올바른 서버 저장 클래스 매개변수를 정의해야 해요. 기본값은 성능이 부족할 가능성이 높기 때문이에요. storageClass Helm 차트 매개변수를 설정하려면, 특정 클라우드 제공자에 대한 자세한 내용은 Kubernetes의 storageClasses 문서를 참고하세요.
읽기 및 쓰기 중심 워크로드 권장 사항 (Read and write heavy workload recommendations)
프로덕션에서 사용 사례에 따라 Consul이 읽기 중심 워크로드, 쓰기 중심 워크로드, 또는 둘 모두를 수행할 수 있어요. 이러한 유형의 워크로드에 대한 구체적인 리소스 권장 사항은 다음 표를 참고하세요.
| 워크로드 유형 | 인스턴스 권장 사항 | 워크로드 요소 예시 | 엔터프라이즈 기능 권장 사항 |
|---|---|---|---|
| 읽기 중심 (Read-heavy) | m5.4xlarge (AWS), Standard_D16s_v3 (Azure), n2-standard-16 (GCP) 유형 인스턴스 |
Raft RPC 호출, DNS 쿼리, 키/값 검색 | 읽기 복제본 (Read replicas) |
| 쓰기 중심 (Write-heavy) | 10 000+의 IOPS 성능 |
Consul 에이전트 조인 및 이탈, 서비스 등록 및 등록 해제, 키/값 쓰기 | 네트워크 세그먼트 (Network segments) |
읽기 중심 또는 쓰기 중심 워크로드의 문제 해결 권장 사항은 Consul at Scale을 참고하세요.
성능 모니터링 (Monitor performance)
모니터링은 Consul 데이터센터에 운영을 계속하기 위한 충분한 리소스가 있는지 확인하는 데 중요해요. 사전 예방적 모니터링 전략은 문제가 배포에 영향을 주기 전에 네트워크에서 문제를 찾는 데 도움이 돼요.
Consul 메트릭과 텔레메트리의 출발점으로 메트릭과 로그로 Consul 서버 헬스 및 성능 모니터링 튜토리얼을 완료할 것을 권장해요. 다음 튜토리얼은 Consul 클러스터에 대한 특정 모니터링 솔루션을 안내해요.
중요한 메트릭 (Important metrics)
프로덕션 환경에서는 Consul 클러스터의 메트릭에 대한 기준선(baseline)을 만들어요. 기준선을 발견한 후에는 예기치 않은 값이 있을 때 알림을 받고 경보를 정의할 수 있게 돼요. 메트릭과 그 값에 대한 자세한 설명은 Consul 에이전트 텔레메트리를 참고하세요.
트랜잭션 메트릭 (Transaction metrics)
이 메트릭은 Consul 클러스터의 다양한 부분에서 쓰기 작업을 완료하는 데 걸리는 시간을 나타내요.
consul.kvs.apply는 KV 저장소 업데이트를 완료하는 데 걸리는 시간을 측정해요.consul.txn.apply는 트랜잭션 작업을 적용하는 데 소요된 시간을 측정해요.consul.raft.apply는 측정 간격 동안 적용된 Raft 트랜잭션 수를 세어요. 이 메트릭은 리더에서만 보고돼요.consul.raft.commitTime는 리더에서 새 항목을 디스크의 Raft 로그에 커밋하는 데 걸리는 시간을 측정해요.
메모리 메트릭 (Memory metrics)
이 성능 지표는 현재 인스턴스 크기가 워크로드를 처리할 수 없는지 진단하는 데 도움이 될 수 있어요.
consul.runtime.alloc_bytes는 Consul 프로세스가 할당한 바이트 수를 측정해요.consul.runtime.sys_bytes는 OS에서 얻은 총 메모리 바이트 수를 측정해요.consul.runtime.heap_objects는 힙에 할당된 객체 수를 측정하며 일반적인 메모리 압력 지표예요.
리더십 메트릭 (Leadership metrics)
리더십 변경 자체는 우려할 이유가 아니지만, 빈번한 변경은 더 깊은 문제의 증상일 수 있어요. 빈번한 선거나 리더십 변경은 Consul 서버 간의 네트워크 문제나 Consul 서버가 부하를 따라가지 못하는 것을 나타낼 수 있어요.
consul.raft.leader.lastContact는 리더가 리더 임대(lease)를 확인할 때 팔로워 노드에 마지막으로 연락한 이후 경과 시간을 측정해요.consul.raft.state.candidate는 Consul 서버가 선거를 시작할 때마다 증가해요.consul.raft.state.leader는 Consul 서버가 리더가 될 때마다 증가해요.consul.server.isLeader는 서버가 리더인지 추적해요.
네트워크 메트릭 (Network metrics)
네트워크 활동과 RPC 수 측정은 Consul 에이전트에서 만들어진 현재 부하를 나타내며, 부하가 rate limit될 만큼 높아질 때를 포함해요. 비정상적으로 높은 RPC 수가 발생하면 클러스터에 과부하가 걸리기 전에 조사해야 해요.
consul.client.rpc는 클라이언트 모드의 Consul 에이전트가 Consul 서버에 RPC 요청을 할 때마다 증가해요.consul.client.rpc.exceeded는 클라이언트 모드의 Consul 에이전트가 Consul 서버에 RPC 요청을 하다가 해당 에이전트의 한도 구성으로 rate limit될 때마다 증가해요.consul.client.rpc.failed는 클라이언트 모드의 Consul 에이전트가 Consul 서버에 RPC 요청을 하고 실패할 때마다 증가해요.
네트워크 제약과 대체 접근 방식 (Network constraints and alternate approaches)
필요한 리소스를 할당할 수 없다면 Consul의 성능을 낮은 속도나 복원력으로 동작하도록 변경할 수 있어요. 이러한 변경은 클러스터가 리소스 용량 내에 유지되도록 보장해요.
- 소프트 한도(soft limits)는 과부하로 인한 클러스터 저하를 방지해요.
- Raft 튜닝은 불리한 환경을 보완할 수 있게 해줘요.
소프트 한도 (Soft limits)
단일 데이터센터의 권장 최대 크기는 Consul 클라이언트 에이전트 5,000개예요. 이 권장 사항은 표준적이고 튜닝되지 않은 환경을 기반으로 하며, 장애 영향 범위(blast radius)의 위험 관리 요소를 고려해요. 최대 에이전트 수는 Consul을 어떻게 사용하는지에 따라 더 낮을 수 있어요.
5,000개를 초과하는 클라이언트 에이전트가 필요하다면 단일 Consul 데이터센터를 여러 개의 작은 데이터센터로 분할해야 해요.
- 노드가 다른 리전과 같은 별도의 물리적 위치에 분산되어 있다면 물리적 위치를 기반으로 여러 데이터센터 구조를 모델링할 수 있어요.
- 단일 가용 존이나 리전에서 네트워크 세그먼트를 사용하면 단일 데이터센터의 전체 리소스 사용량을 줄일 수 있어요.
Kubernetes에 Consul 배포 시 Helm 차트에서 requests와 limits를 모두 설정할 것을 권장해요. 자세한 내용은 Helm 차트 문서를 참고하세요.
- requests는 Consul 워크로드에 필요한 리소스를 할당해요.
- limits는 파드가 요청된 것보다 더 많은 리소스를 소비하고 Kubernetes가 이 리소스를 회수해야 할 때 파드가 종료되고 재시작되는 것을 방지해요. limits는 리소스 제약으로 인해 Consul 리더의 컨테이너가 종료되고 재배포되는 중단 상황을 방지할 수 있어요.
다음은 16 CPU 코어와 64GB 메모리를 할당하는 예시 Helm 구성이에요:
global:
image: "hashicorp/consul"
## ...
resources:
requests:
memory: '64G'
cpu: '16000m'
limits:
memory: '64G'
cpu: '16000m'
Raft 튜닝 (Raft tuning)
Consul은 일관성을 제공하기 위해 Raft 합의 알고리즘을 사용해요. 특정 환경에 맞게 Raft를 조정해야 할 수 있어요. raft_multiplier 구성을 조정해 리더 안정성과 리더 장애에서 복구하는 시간 사이의 균형을 정의해요.
- 낮은 배수는 장애 감지와 선거 시간을 최소화하지만, 고지연 상황에서는 자주 트리거될 수 있어요.
- 높은 배수는 장애가 리더십 변동을 일으킬 확률을 줄이지만, 클러스터가 실제 장애를 감지하고 가용성을 복원하는 데 더 오래 걸려요.
raft_multiplier 값의 기본값은 5예요. 이는 다음 매개변수에 직접 영향을 주는 스케일링 요소 설정이에요:
| 매개변수 이름 | 기본값 | 유래 |
|---|---|---|
| HeartbeatTimeout | 5000ms | 5 x 1000ms |
| ElectionTimeout | 5000ms | 5 x 1000ms |
| LeaderLeaseTimeout | 2500ms | 5 x 500ms |
consul.raft.leader.lastContact의 텔레메트리를 사용해 Raft 타이밍 성능을 관찰할 수 있어요.
지연이 더 큰 광역 네트워크는 raft_multiplier 값이 클수록 더 좋은 성능을 보이지만, 클러스터 장애 감지는 더 오래 걸려요. 네트워크가 낮은 지연으로 동작한다면 Raft 배수를 5보다 높게 설정하지 않을 것을 권장해요. 대신 서버를 더 강력한 것으로 교체하거나 노드 간 네트워크 지연을 최소화해야 해요.
기준선에서 시작해 Raft 배수의 다양한 값으로 카오스 엔지니어링 테스트를 수행해 클러스터의 문제 감지 및 복구에 허용 가능한 시간을 찾을 것을 권장해요. 그런 다음 처리되는 워크로드 수에 맞춰 클러스터와 전용 리소스를 확장해요. 이 접근 방식은 리소스를 확장할 수 없을 때 Raft 튜닝을 백업 계획으로 사용할 수 있게 해주기 때문에, 순수한 리소스 성장과 순수한 Raft 튜닝 전략 사이에서 최상의 균형을 제공해요.
Consul 클러스터가 처리하는 워크로드 유형도 Raft 튜닝에서 중요한 역할을 해요. 예를 들어 Consul 클러스터가 대부분 정적이고 이벤트를 많이 처리하지 않는다면, 클러스터가 수렴하거나 리더를 재선거하는 동안 중요한 이벤트가 발생할 위험이 낮기 때문에 리소스를 확장하는 대신 Raft 배수를 높여야 해요.