Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 또한 서비스는 각 워크로드의 특정 요구 사항에 따라 구성을 재정의할 수 있습니다. 이 기능을 사용하면 필요한 경우 유연성을 극대화하고 제어할 수 있습니다. 이 문서에서는 성능을 최적화하는 방법에 대한 팁을 제공합니다.
최적의 설정 및 구성
복제 요소, 디스크 수, 노드 수 및 제품 계층
Azure는 대부분의 지역에서 세 개의 가용성 영역을 지원합니다. Apache Cassandra용 Azure Managed Instance는 가용성 영역을 랙에 매핑합니다. 핫 파티션을 방지하려면 카디널리티가 높은 파티션 키를 선택하는 것이 좋습니다. 최고 수준의 안정성 및 내결함성을 위해 복제 인자 3을 구성하는 것이 좋습니다. 또한 복제 요소의 배수를 노드 수로 지정하는 것이 좋습니다. 예를 들어 3, 6, 9 등을 사용합니다.
Azure는 프로비전하는 디스크 수에 대해 RAID 0을 사용합니다. 최적의 초당 입력/출력 작업(IOPS)을 얻으려면 선택한 제품 계층의 최대 IOPS와 P30 디스크의 IOPS를 확인하십시오. 예를 들어 제품 계층은 Standard_DS14_v2 51,200개의 캐시되지 않은 IOPS를 지원합니다. 단일 P30 디스크의 기본 성능은 5,000 IOPS입니다. 4개의 디스크는 20,000 IOPS로 이어지며 이는 컴퓨터의 한도보다 훨씬 낮습니다.
제품 계층 및 디스크 수에 대해 워크로드를 광범위하게 벤치마킹하는 것이 좋습니다. 벤치마킹은 코어가 8개뿐인 제품 계층에서 특히 중요합니다. 우리의 연구에 따르면 8코어 CPU는 가장 까다로운 워크로드에서만 작동합니다. 대부분의 워크로드는 제대로 수행하려면 최소 16개의 코어가 필요합니다.
분석 및 트랜잭션 워크로드
트랜잭션 워크로드에는 일반적으로 짧은 대기 시간에 최적화된 데이터 센터가 필요합니다. 분석 워크로드는 더 복잡한 쿼리를 사용하는 경우가 많으며, 실행하는 데 시간이 더 오래 걸립니다. 대부분의 경우 다음을 사용하여 별도의 데이터 센터를 원합니다.
- 짧은 대기 시간에 최적화된 기능입니다.
- 하나는 분석 워크로드에 최적화되어 있습니다.
분석 워크로드 최적화
분석 워크로드에 대해 다음 cassandra.yaml 설정을 적용하는 것이 좋습니다. 이러한 설정을 적용하는 방법에 대한 자세한 내용은 Cassandra 구성 업데이트를 참조하세요.
시간 제한
| 가치 | Cassandra MI 기본값 | 분석 워크로드에 대한 권장 사항 |
|---|---|---|
read_request_timeout_in_ms |
5,000 | 1만 |
range_request_timeout_in_ms |
1만 | 20,000 |
counter_write_request_timeout_in_ms |
5,000 | 1만 |
cas_contention_timeout_in_ms |
1,000 | 2천 |
truncate_request_timeout_in_ms |
60,000 | 120,000 |
slow_query_log_timeout_in_ms |
500 | 1,000 |
roles_validity_in_ms |
2천 | 120,000 |
permissions_validity_in_ms |
2천 | 120,000 |
캐시
| 가치 | Cassandra MI 기본값 | 분석 워크로드에 대한 권장 사항 |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6,144 |
추가 권장 사항
| 가치 | Cassandra MI 기본값 | 분석 워크로드에 대한 권장 사항 |
|---|---|---|
commitlog_total_space_in_mb |
8,192 | 16,384 |
column_index_size_in_kb |
64 | 16 |
compaction_throughput_mb_per_sec |
128 | 256 |
클라이언트 설정
서버에 적용된 시간 제한에 따라 Cassandra 클라이언트 드라이버 시간 제한을 늘리는 것이 좋습니다.
짧은 대기 시간에 최적화
기본 설정은 대기 시간이 짧은 워크로드에 이미 적합합니다. 비상 대기 시간에 대한 최상의 성능을 보장하려면 추측 실행을 지원하고 그에 따라 클라이언트를 구성하는 클라이언트 드라이버를 사용하는 것이 좋습니다. Java V4 드라이버의 경우 데모에서는 이 프로세스의 작동 방식과 이 샘플에서 정책을 사용하도록 설정하는 방법을 보여 줍니다.
성능 병목 상태 모니터링
CPU 성능
모든 데이터베이스 시스템과 마찬가지로 Cassandra는 CPU 사용률이 약 50%이고 절대 80%를 초과하지 않는 경우 가장 잘 작동합니다. CPU 메트릭을 보려면 Azure Portal의 모니터링 섹션에서 메트릭 탭을 엽니다.
실제 CPU 보기의 경우 필터를 추가하고 속성을 분할하는 데 사용합니다 Usage kind=usage_idle . 이 값이%20보다 낮으면 분할을 적용하여 모든 사용량 종류별로 사용량을 가져옵니다.
CPU가 대부분의 노드에서% 80을 영구적으로 초과하면 데이터베이스가 오버로드되어 여러 클라이언트 시간 제한으로 나타납니다. 이 시나리오에서는 다음 작업을 수행하는 것이 좋습니다.
- 특히 코어가 8개 이하인 경우 CPU 코어가 더 많은 제품 계층으로 수직으로 확장합니다.
- 노드를 더 추가하여 수평 크기 조정 앞에서 설명한 것처럼 노드 수는 복제 요소의 배수여야 합니다.
CPU가 소수의 노드에 대해서만 높지만 다른 노드의 경우 낮으면 핫 파티션을 나타냅니다. 이 시나리오에는 추가 조사가 필요합니다.
제품 계층 변경은 Azure Portal, Azure CLI 및 ARM 템플릿(Azure Resource Manager 템플릿) 배포를 사용하여 지원됩니다. ARM 템플릿을 배포하거나 편집하고 제품 계층을 다음 값 중 하나로 바꿀 수 있습니다.
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
현재는 제품 제품군 간 전환을 지원하지 않습니다. 예를 들어, 현재 Standard_DS13_v2을/를 소유하고 있고 Standard_DS14_v2과 같은 더 큰 제품으로 업그레이드하려는 경우, 이 옵션은 제공되지 않습니다. 지원 티켓을 열어 상위 제품으로의 업그레이드를 요청합니다.
디스크 성능
서비스는 버스트 IOPS를 허용하는 Azure P30 관리 디스크에서 실행됩니다. 디스크 관련 성능 병목 상태와 관련하여 신중한 모니터링이 필요합니다. 이 경우 IOPS 메트릭을 검토해야 합니다.
메트릭에 다음 특성 중 하나 또는 전부가 표시되는 경우 강화해야 할 수 있습니다.
- 메트릭은 기본 IOPS보다 일관되게 높거나 같습니다. 5,000 IOPS에 노드당 디스크 수를 곱하여 숫자를 가져와야 합니다.
- 메트릭은 쓰기에 대해 제품 계층에 허용되는 최대 IOPS보다 일관되게 높거나 같습니다.
- 제품 계층은 캐시된 스토리지(쓰기-통과 캐시)를 지원하며, 이 숫자는 관리 디스크의 IOPS보다 작습니다. 이 값은 읽기 IOPS의 상한입니다.
몇 개의 노드에 대해서만 IOPS가 상승된 경우, 과열된 파티션이 있을 수 있으며, 편향 가능성을 점검하기 위해 데이터를 검토해야 할 수 있습니다.
IOPS가 제품 계층에서 지원하는 것보다 낮지만 디스크 IOPS보다 높거나 같은 경우 다음 작업을 수행합니다.
- 데이터 센터를 확장하기 위해 노드를 더 추가합니다.
IOPS가 제품 계층에서 지원하는 상한에 도달하면 다음을 수행할 수 있습니다.
- 더 많은 IOPS를 지원하는 다른 제품 계층으로 확장합니다.
- 데이터 센터를 확장하기 위해 노드를 더 추가합니다.
자세한 내용은 가상 머신 및 디스크 성능을 참조하세요.
네트워크 성능
일반적으로 네트워크 성능은 충분합니다. 빈번한 수평 확장/스케일 다운과 같은 데이터를 자주 스트리밍하거나 수신/송신 데이터 이동이 많은 경우 이 성능이 문제가 될 수 있습니다. 제품 계층의 네트워크 성능을 평가해야 할 수도 있습니다. 예를 들어 제품 계층은 Standard_DS14_v2 12,000Mb/s를 지원합니다. 이 값을 메트릭의 바이트인/출력과 비교합니다.
몇 개의 노드에서만 네트워크 부하가 증가한 것이 보인다면, 핫 파티션이 발생할 수 있습니다. 데이터 배포 및 액세스 패턴의 잠재적 편향을 검토하세요.
- 더 많은 네트워크 I/O를 지원하여 다른 제품 계층으로 수직으로 확장합니다.
- 더 많은 노드를 추가하여 클러스터를 수평으로 스케일 업합니다.
연결된 클라이언트가 너무 많습니다.
애플리케이션의 원하는 대기 시간에 필요한 최대 병렬 요청 수를 지원하도록 배포를 계획하고 프로비전합니다. 특정 배포의 경우 최소 임계값을 초과하는 시스템에 더 많은 부하를 도입하면 전체 대기 시간이 증가합니다. 연결된 클라이언트 수를 모니터링하여 이 상황이 허용되는 제한을 초과하지 않는지 확인합니다.
디스크 공간
대부분의 경우 디스크 공간이 충분합니다. 기본 배포는 IOPS에 최적화되어 디스크 사용률이 낮습니다. 그럼에도 불구하고 디스크 공간 메트릭을 가끔 검토하는 것이 좋습니다. Cassandra는 수많은 디스크를 누적한 다음 압축이 트리거될 때 디스크를 줄입니다. 압축이 공간을 회수할 수 없는 경우와 같이 추세를 설정하려면 더 오랜 기간 동안 디스크 사용량을 검토해야 합니다.
참고
압축에 사용할 수 있는 공간을 보장하려면 디스크 사용률을 약 50%로 유지합니다.
일부 노드에 대해서만 이 동작이 표시되면 핫 파티션이 있을 수 있습니다. 데이터 배포 및 액세스 패턴의 잠재적 편향을 검토하세요.
- 디스크를 더 추가하지만 제품 계층에서 적용되는 IOPS 제한을 염두에 두어야 합니다.
- 클러스터를 가로로 확장합니다.
JVM 메모리
기본 수식은 상한이 31GB인 JVM(Java Virtual Machine)에 가상 머신 메모리의 절반을 할당합니다. 대부분의 경우 이 방법은 성능과 메모리 간의 균형을 잘 조정합니다. 일부 워크로드, 특히 파티션 간 읽기 또는 범위 검색이 자주 발생하는 워크로드는 메모리에 문제가 있을 수 있습니다.
대부분의 경우 메모리는 Java 가비지 수집기에서 효과적으로 회수됩니다. CPU가 80%를 초과하는 경우가 많으면 가비지 수집기에 충분한 CPU 주기가 남아 있지 않게 됩니다. 메모리 문제를 확인하기 전에 CPU 성능 문제를 해결합니다.
CPU가 70% 미만이고 가비지 수집이 메모리를 회수할 수 없는 경우 더 많은 JVM 메모리가 필요할 수 있습니다. 메모리가 제한된 제품 계층에 있는 경우 더 많은 JVM 메모리가 필요할 수 있습니다. 대부분의 경우 쿼리 및 클라이언트 설정을 검토하고 CQL(Cassandra 쿼리 언어) 쿼리 내에서 선택된 항목 fetch_size과 함께 limit를 줄여야 합니다.
더 많은 메모리가 필요한 경우 다음을 수행할 수 있습니다.
- 사용 가능한 메모리가 더 많은 제품 계층으로 수직으로 확장합니다.
삭제 표식
Reaper를 사용하여 7일마다 수정 작업을 수행해 TTL(Time to Live)이 만료된 행을 제거합니다. 이러한 행을 삭제 표시라고 합니다. 일부 워크로드는 더 자주 삭제되고 Cassandra 로그와 같은 Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) 경고를 표시합니다. 일부 오류는 과도한 무덤 표시로 인해 쿼리를 수행할 수 없음을 나타냅니다.
쿼리가 충족되지 않는 경우 단기 완화는 tombstone_failure_threshold의 값을 기본값 100,000에서 더 높은 값으로 늘리는 것입니다.
또한 키스페이스에서 TTL을 검토하고 잠재적으로 매일 복구를 실행하여 더 많은 삭제 표시를 지우는 것이 좋습니다. TTL이 짧고(예: 2일 미만) 데이터가 빠르게 들어오고 삭제되는 경우 압축 전략을 검토하고 선호하는 Leveled Compaction Strategy것이 좋습니다. 경우에 따라 이러한 작업은 데이터 모델을 검토해야 함을 나타낼 수 있습니다.
Batch 경고
CassandraLogs에서 다음과 같은 경고와 잠재적으로 관련된 오류가 발생할 수 있습니다.
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
쿼리를 검토하여 권장 일괄 처리 크기 이하로 유지합니다. 드문 경우에 단기적인 완화 방법으로 batch_size_fail_threshold_in_kb에서 기본값인 50을 로 더 높은 값으로 증가시킵니다.
큰 파티션 경고
CassandraLogs에서 다음 경고가 발생할 수 있습니다.
Writing large partition <table> (105.426MiB) to sstable <file>
이 메시지는 데이터 모델의 문제를 나타냅니다. 자세한 내용은 이 Stack Overflow 문서를 참조하세요. 이 문제는 심각한 성능 문제를 일으킬 수 있으며 해결해야 합니다.
전문적인 최적화
압축
Cassandra를 사용하면 테이블을 만들 때 적절한 압축 알고리즘을 선택할 수 있습니다. 기본값은 처리량 및 CPU에 적합하지만 디스크에 더 많은 공간을 사용하는 LZ4입니다. Zstandard(Cassandra 4.0 이상)를 사용하면 CPU 오버헤드를 최소화하면서 약 12개의% 공간을 절약할 수 있습니다.
memtable 힙 공간 최적화
기본값은 파일의 memtable_heap_space JVM 힙의 1/4을 사용하는 것입니다 cassandra.yaml . 쓰기 지향 애플리케이션 또는 메모리가 적은 제품 계층의 경우 이 문제로 인해 플러시 및 조각화 sstables가 자주 발생할 수 있으므로 압축이 더 필요할 수 있습니다. 적어도 4,048로 증가하는 것이 좋을 수 있습니다. 이 방법을 사용하려면 다른 작업(예: 읽기)이 영향을 받지 않도록 신중하게 벤치마킹해야 합니다.