Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 또한 서비스는 각 워크로드의 특정 요구 사항에 따라 구성을 재정의할 수 있습니다. 이 기능을 사용하면 필요한 경우 유연성을 극대화하고 제어할 수 있습니다. 이 문서에서는 성능을 최적화하는 방법에 대한 팁을 제공합니다.
최적의 설정 및 구성
복제 인자, 디스크 수, 노드 수 및 SKU
Azure는 대부분의 지역에서 세 개의 가용성 영역을 지원합니다. Apache Cassandra용 Azure Managed Instance는 가용성 영역을 랙에 매핑합니다. 핫 파티션을 방지하려면 카디널리티가 높은 파티션 키를 선택하는 것이 좋습니다. 최상의 안정성과 내결함성을 위해서는 복제 인수를 3으로 구성하는 것이 좋습니다. 또한 복제 인자의 배수를 노드 수로 지정하는 것이 좋습니다(예: 3, 6, 9 등).
Azure는 프로비전하는 디스크 수보다 RAID 0을 사용합니다. 최적의 IOPS를 얻으려면 P30 디스크의 IOPS와 함께 선택한 SKU의 최대 IOPS를 확인합니다. 예를 들어, Standard_DS14_v2 SKU는 캐시되지 않은 51,200 IOPS를 지원하는 반면 단일 P30 디스크의 기본 성능은 5,000 IOPS입니다. 4개의 디스크가 20,000 IOPS로 이어지며 이는 컴퓨터의 한도보다 훨씬 낮습니다.
SKU 및 디스크 수에 대해 워크로드를 광범위하게 벤치마킹하는 것이 좋습니다. 벤치마킹은 코어가 8개뿐인 SKU에 특히 중요합니다. 우리의 연구에 따르면 8개의 핵심 CPU는 가장 까다로운 워크로드에 대해서만 작동합니다. 대부분의 워크로드를 수행하려면 최소 16개의 코어가 필요합니다.
분석 및 트랜잭션 워크로드
트랜잭션 워크로드는 일반적으로 짧은 대기 시간에 최적화된 데이터 센터가 필요하지만 분석 워크로드는 더 복잡한 쿼리를 사용하는 경우가 많으며, 실행하는 데 시간이 더 오래 걸립니다. 대부분의 경우 별도의 데이터 센터를 원합니다.
- 짧은 대기 시간에 최적화된 데이터 센터
- 분석 워크로드에 최적화된 데이터 센터
분석 워크로드에 최적화
고객은 분석 워크로드에 다음 cassandra.yaml 설정을 적용하는 것이 좋습니다. 이러한 설정을 적용하는 방법에 대한 자세한 내용은 Cassandra 구성 업데이트를 참조하세요.
시간 제한
| 가치 | Cassandra MI 기본값 | 분석 워크로드에 대한 권장 사항 |
|---|---|---|
| 읽기_요청_시간초과_밀리초 | 5,000 | 1만 |
| 범위_요청_시간_초과_밀리초_단위 | 1만 | 20,000 |
| 카운터_쓰기_요청_시간_제한_밀리초 | 5,000 | 1만 |
| cas_contention_timeout_in_ms (CAS 컨텐션 타임아웃 밀리초 단위) | 1,000 | 2천 |
| truncate_request_timeout_in_ms (요청 시간 초과를 잘라내는 시간(ms)) | 60,000 | 120,000 |
| 느린_쿼리_로그_타임아웃_밀리초 | 500 | 1,000 |
| 역할_유효성_밀리초 | 2천 | 120,000 |
| 권한_유효성_밀리초_단위로 | 2천 | 120,000 |
캐시
| 가치 | Cassandra MI 기본값 | 분석 워크로드에 대한 권장 사항 |
|---|---|---|
| 파일_캐시_크기_MB_단위 | 2,048 | 6,144 |
추가 권장 사항
| 가치 | Cassandra MI 기본값 | 분석 워크로드에 대한 권장 사항 |
|---|---|---|
| 커밋로그_총_공간_메가바이트 | 8,192 | 16,384 |
| 칼럼_인덱스_크기_kb | 64 | 16 |
| 압축 처리량(MB/초) | 128 | 256 |
클라이언트 설정
서버에 적용되는 시간 제한에 따라 Cassandra 클라이언트 드라이버 시간 제한을 늘리는 것이 좋습니다.
낮은 대기 시간을 위한 최적화
기본 설정은 이미 대기 시간이 짧은 워크로드에 적합합니다. 비상 대기 시간에 대한 최상의 성능을 보장하려면 투기적 실행을 지원하는 클라이언트 드라이버를 사용하고 그에 따라 클라이언트를 구성하는 것이 좋습니다. Java V4 드라이버의 경우 작동 방식과 이 샘플에서 정책을 사용하도록 설정하는 방법을 보여 주는 데모를 찾을 수 있습니다.
성능 병목 현상 모니터링
CPU 성능
모든 데이터베이스 시스템과 마찬가지로 Cassandra는 CPU 사용률이 약 50%이고 절대 80%를 초과하지 않는 경우 가장 잘 작동합니다. 포털의 모니터링 내 메트릭 탭에서 CPU 메트릭을 볼 수 있습니다.
팁
실제 CPU 보기의 경우 필터를 추가하고 속성을 Usage kind=usage_idle로 분할합니다. 이 값이 20%보다 낮은 경우 분할을 적용하여 모든 사용량 종류별로 사용량을 가져올 수 있습니다.
CPU가 대부분의 노드에서% 80을 영구적으로 초과하면 데이터베이스가 오버로드되어 여러 클라이언트 시간 제한으로 나타납니다. 이 시나리오에서는 다음 작업을 수행하는 것이 좋습니다.
- 특히 코어가 8 이하인 경우 CPU 코어가 더 많은 SKU로 수직으로 확장합니다.
- 노드를 더 추가하여 수평 크기 조정 앞에서 설명한 것처럼 노드 수는 복제 요소의 배수여야 합니다.
CPU가 일부 노드에 대해서만 높지만 다른 노드의 경우 낮은 경우 추가 조사가 필요한 핫 파티션을 나타냅니다.
참고 항목
SKU 변경은 Azure Portal, Azure CLI 및 ARM 템플릿 배포를 사용하여 지원됩니다. ARM 템플릿을 배포하거나 편집하고 SKU를 다음 값 중 하나로 바꿀 수 있습니다.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
현재는 SKU 제품군 간 전환을 지원하지 않습니다. 예를 들어 현재 소유하고 Standard_DS13_v2 있으며 더 큰 SKU(예: )로 Standard_DS14_v2업그레이드하려는 경우 이 옵션을 사용할 수 없습니다. 그러나 지원 티켓을 열어 더 높은 SKU로 업그레이드를 요청할 수 있습니다.
디스크 성능
서비스는 버스트 IOPS를 허용하는 Azure P30 관리 디스크에서 실행됩니다. 디스크 관련 성능 병목 현상에 대해서는 주의 깊은 모니터링이 필요합니다. 이 경우 IOPS 메트릭을 검토해야 합니다.
메트릭에 다음 특성 중 하나 또는 전부가 표시되는 경우 강화해야 할 수 있습니다.
- 기본 IOPS보다 일관되게 높거나 같음 5,000 IOPS에 노드당 디스크 수를 곱하여 숫자를 가져와야 합니다.
- 쓰기에 대해 SKU에 허용되는 최대 IOPS보다 지속적으로 높거나 같습니다.
- SKU는 캐싱 스토리지(쓰기 캐시)를 지원하며, 이 숫자는 관리 디스크의 IOPS보다 작습니다. 이 값은 읽기 IOPS의 상한입니다.
몇몇 노드에 대해서만 IOPS가 상승한 것으로 확인되면 핫 파티션이 있을 수 있으며 데이터에 잠재적인 기울이기가 있는지 검토해야 합니다.
IOPS가 SKU에서 지원하는 것보다 낮지만 디스크 IOPS보다 높거나 같은 경우 다음 작업을 수행할 수 있습니다.
- 성능을 높이려면 디스크를 더 추가합니다. 디스크를 늘리려면 지원 사례를 제기해야 합니다.
- 더 많은 노드를 추가하여 데이터 센터를 확장합니다.
IOPS가 SKU가 지원하는 최대치를 초과하는 경우 다음을 수행할 수 있습니다.
- 더 많은 IOPS를 지원하는 다른 SKU로 확장합니다.
- 더 많은 노드를 추가하여 데이터 센터를 확장합니다.
자세한 내용은 가상 머신 및 디스크 성능을 참조하세요.
네트워크 성능
대부분의 경우 네트워크 성능으로 충분합니다. 그러나 자주 수평 확장/축소와 같은 데이터를 자주 스트리밍하거나 수신/송신 데이터 이동이 많은 경우 이 성능이 문제가 될 수 있습니다. SKU의 네트워크 성능을 평가해야 할 수도 있습니다. 예를 들어 SKU는 Standard_DS14_v2 12,000Mb/s를 지원합니다. 이 값을 메트릭의 바이트 인/아웃과 비교합니다.
일부 노드에서만 네트워크가 상승된 것을 본다면 핫 파티션이 있을 수 있으며, 데이터 분배와 액세스 패턴을 검토하여 잠재적인 왜곡을 확인해야 할 수 있습니다.
- 더 많은 네트워크 I/O를 지원하는 다른 SKU로 수직으로 스케일 업합니다.
- 더 많은 노드를 추가하여 클러스터를 수평으로 스케일 업합니다.
연결된 클라이언트가 너무 많습니다.
애플리케이션의 원하는 대기 시간에 필요한 최대 병렬 요청 수를 지원하도록 배포를 계획하고 프로비전해야 합니다. 특정 배포의 경우 시스템에 최소 임계값 이상으로 더 많은 로드를 도입하면 전체 대기 시간이 늘어납니다. 연결된 클라이언트 수를 모니터링하여 이 상황이 허용되는 제한을 초과하지 않는지 확인합니다.
디스크 공간
대부분의 경우 디스크 공간이 충분합니다. 기본 배포는 IOPS에 최적화되어 디스크 사용률이 낮습니다. 그럼에도 불구하고 디스크 공간 메트릭을 검토하는 것이 좋습니다. Cassandra는 수많은 디스크를 누적한 다음 압축이 트리거될 때 이를 줄입니다. 공간을 회수할 수 없는 압축과 같은 추세를 설정하려면 더 오랜 기간 동안 디스크 사용량을 검토해야 합니다.
참고 항목
압축에 사용 가능한 공간을 확보하려면 디스크 사용률을 약 50%로 유지해야 합니다.
일부 노드에 대해서만 이 동작이 표시되는 경우 핫 파티션이 있을 수 있으며 데이터 배포 및 액세스 패턴을 검토하여 잠재적인 기울이기를 확인해야 할 수 있습니다.
- 디스크를 더 추가하지만 SKU에 의해 부과되는 IOPS 제한을 염두에 두어야 합니다.
- 클러스터 수평 확장
JVM 메모리
기본 수식은 상한이 31GB인 JVM(Jave Virtual Machine)에 가상 머신 메모리의 절반을 할당합니다. 대부분의 경우 이 방법은 성능과 메모리 간의 균형을 잘 조정합니다. 일부 워크로드, 특히 파티션 간 읽기 또는 범위 검사가 빈번한 워크로드에서는 메모리 문제가 발생할 수 있습니다.
대부분의 경우 메모리는 Java 가비지 수집기에 의해 효과적으로 회수되지만 특히 CPU가 80%를 초과하는 경우 남은 가비지 수집기에 대한 CPU 주기가 충분하지 않습니다. 따라서 모든 CPU 성능 문제는 메모리 문제보다 먼저 해결되어야 합니다.
CPU가 70% 미만이고 가비지 수집이 메모리를 회수할 수 없는 경우 JVM 메모리가 더 필요할 수 있습니다. 메모리가 제한된 SKU에 있는 경우 더 많은 JVM 메모리가 필요할 수 있습니다. 대부분의 경우 쿼리 및 클라이언트 설정을 검토하고 CQL 쿼리 내 fetch_size에서 선택한 항목과 함께 limit를 줄여야 합니다.
실제로 더 많은 메모리가 필요한 경우 다음을 수행할 수 있습니다.
- JVM 메모리 설정을 늘리려면 티켓을 제출합니다.
- 더 많은 메모리를 사용할 수 있는 SKU로 수직 크기 조정
삭제 표식
우리는 7일마다 '사신'을 사용하여 TTL이 만료된 행을 제거하는 유지 보수를 실행하며, 이러한 행들을 삭제된 행 표시(Tombstone)라고 부릅니다. 일부 워크로드는 삭제가 더 빈번하게 발생하며, Cassandra 로그에 Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold)와 같은 경고 메시지가 표시되거나, 과도한 삭제 초래물(tombstones)로 인해 쿼리를 처리할 수 없음을 나타내는 오류가 발생할 수 있습니다.
쿼리가 충족되지 않는 경우 단기적인 완화는 Cassandra 구성의 크기를 기본값 100,000에서 더 높은 값으로 늘리는 tombstone_failure_threshold 것입니다.
또한 키스페이스에서 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.
이 경우 쿼리를 검토하여 권장 일괄 처리 크기 이하로 유지해야 합니다. 드문 경우이며 단기적인 완화 방법으로 Cassandra 구성을 기본값인 50에서 더 높은 값으로 늘릴 batch_size_fail_threshold_in_kb 수 있습니다.
큰 파티션 경고
CassandraLogs에서 다음 경고가 나타날 수 있습니다.
Writing large partition <table> (105.426MiB) to sstable <file>
이 메시지는 데이터 모델의 문제를 나타냅니다. 자세한 내용은 이 스택 오버플로 문서를 참조하세요. 이 문제는 심각한 성능 문제를 일으킬 수 있으며 해결해야 합니다.
전문적인 최적화
압축
Cassandra를 사용하면 테이블을 만들 때 적절한 압축 알고리즘을 선택할 수 있습니다. 기본값은 처리량 및 CPU에 적합하지만 디스크에 더 많은 공간을 사용하는 LZ4입니다. Zstd(Cassandra 4.0 이상)를 사용하면 최소한의 CPU 오버헤드로 약 12%의 공간이 절약됩니다.
메모리 테이블 힙 공간 최적화
기본값은 cassandra.yaml에서 memtable_heap_space JVM 힙의 1/4를 사용하는 것입니다. 쓰기 지향 애플리케이션 및/또는 메모리가 작은 SKU의 경우 이 문제로 인해 자주 플러시되고 조각화 sstables되어 압축이 더 필요할 수 있습니다. 이러한 경우 4048 이상으로 늘리는 것이 좋을 수 있습니다. 이 방법을 사용하려면 다른 작업(예: 읽기)이 영향을 받지 않도록 신중하게 벤치마킹해야 합니다.