최적의 성능에 대한 모범 사례

아티클
08/15/2024

Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 또한 이 서비스를 사용하면 각 워크로드의 특정 요구 사항에 따라 구성을 재정의할 수 있으므로 필요한 경우 최대한의 유연성과 제어가 가능합니다. 이 문서에서는 성능을 최적화하는 방법에 대한 팁을 제공합니다.

최적의 설정 및 구성

복제 인자, 디스크 수, 노드 수 및 SKU

Azure는 대부분의 지역에서 3개 가용성 영역을 지원하고 Cassandra Managed Instance는 가용성 영역을 랙에 매핑하므로 핫 파티션을 방지하려면 카디널리티가 높은 파티션 키를 선택하는 것이 좋습니다. 최상의 안정성과 내결함성을 위해서는 복제 인수를 3으로 구성하는 것이 좋습니다. 또한 복제 인자의 배수를 노드 수로 지정하는 것이 좋습니다(예: 3, 6, 9 등).

프로비전한 디스크 수에 대해 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 MI 기본값	분석 워크로드에 대한 권장 사항
read_request_timeout_in_ms	5,000	10000
range_request_timeout_in_ms	10000	20,000
counter_write_request_timeout_in_ms	5,000	10,000
cas_contention_timeout_in_ms	1,000	2,000
truncate_request_timeout_in_ms	60,000	120,000
slow_query_log_timeout_in_ms	500	1,000
roles_validity_in_ms	2,000	120,000
permissions_validity_in_ms	2,000	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 메트릭을 볼 수 있습니다.

팁

실제 CPU 보기의 경우 필터를 추가하고 속성을 Usage kind=usage_idle로 분할합니다. 이 값이 20%보다 낮은 경우 분할을 적용하여 모든 사용량 종류별로 사용량을 가져올 수 있습니다.

대부분의 노드에서 CPU가 영구적으로 80%를 초과하면 데이터베이스가 오버로드되어 여러 클라이언트 시간 제한이 발생합니다. 이 시나리오에서는 다음 조치를 취하는 것이 좋습니다.

CPU 코어가 더 많은 SKU로 수직 스케일 업합니다(특히 코어가 8개 이하인 경우).
더 많은 노드를 추가하여 수평으로 크기 조정합니다(앞서 언급한 것처럼 노드 수는 복제 요소의 배수여야 함).

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를 보유하고 있으며 Standard_DS14_v2 같은 더 큰 SKU로 업그레이드하려는 경우 이 옵션을 사용할 수 없습니다. 그러나 지원 티켓을 열어 더 높은 SKU로 업그레이드를 요청할 수 있습니다.

디스크 성능

이 서비스는 "버스트 IOPS"를 허용하는 Azure P30 관리 디스크에서 실행됩니다. 디스크 관련 성능 병목 현상에 대해서는 주의 깊은 모니터링이 필요합니다. 이 경우 IOPS 메트릭을 검토해야 합니다.

메트릭에 다음 특성 중 하나 또는 모두가 표시되면 스케일 업이 필요함을 나타낼 수 있습니다.

지속적으로 기본 IOPS보다 높거나 같습니다. 숫자를 가져오려면 5,000 IOPS에 노드당 디스크 수를 곱해야 합니다.
쓰기에 대해 SKU에 허용되는 최대 IOPS보다 지속적으로 높거나 같습니다.
SKU는 캐시된 스토리지(캐시 연속 쓰기)를 지원하며 이 숫자는 관리 디스크의 IOPS보다 작습니다(읽기 IOPS의 상한임).

몇몇 노드에 대해서만 IOPS가 상승한 것으로 확인되면 핫 파티션이 있을 수 있으며 데이터에 잠재적인 기울이기가 있는지 검토해야 합니다.

IOPS가 선택한 SKU에서 지원하는 것보다 낮지만 디스크 IOPS보다 높거나 같은 경우 다음 조치를 취할 수 있습니다.

성능을 높이려면 디스크를 더 추가합니다. 디스크를 늘리려면 지원 사례를 제기해야 합니다.
더 많은 노드를 추가하여 데이터 센터를 스케일 업합니다.

IOPS가 SKU가 지원하는 최대치를 초과하는 경우 다음을 수행할 수 있습니다.

더 많은 IOPS를 지원하는 다른 SKU로 스케일 업합니다.
더 많은 노드를 추가하여 데이터 센터를 스케일 업합니다.

자세한 내용은 가상 머신 및 디스크 성능을 참조하세요.

네트워크 성능

대부분의 경우 네트워크 성능은 충분합니다. 그러나 데이터를 자주 스트리밍하거나(예: 빈번한 수평 스케일 업/스케일 업) 수신/송신 데이터 이동이 큰 경우 문제가 될 수 있습니다. SKU의 네트워크 성능을 평가해야 할 수도 있습니다. 예를 들어, Standard_DS14_v2 SKU는 12,000Mb/s를 지원합니다. 이를 메트릭의 바이트 입력/출력과 비교합니다.

소수의 노드에 대해 관리자 권한의 네트워크만 표시되는 경우 핫 파티션이 있을 수 있으며 잠재적인 기울이기에 대한 데이터 배포 및/또는 액세스 패턴을 검토해야 합니다.

더 많은 네트워크 I/O를 지원하는 다른 SKU로 수직으로 스케일 업합니다.
더 많은 노드를 추가하여 클러스터를 수평으로 스케일 업합니다.

연결된 클라이언트가 너무 많습니다.

애플리케이션의 원하는 대기 시간에 필요한 최대 병렬 요청 수를 지원하도록 배포를 계획하고 프로비전해야 합니다. 특정 배포의 경우 시스템에 최소 임계값 이상으로 더 많은 로드를 도입하면 전체 대기 시간이 늘어납니다. 연결된 클라이언트 수를 모니터링하여 허용 가능한 한도를 초과하지 않는지 확인합니다.

디스크 공간

대부분의 경우 기본 배포는 IOPS에 최적화되어 있으므로 디스크 공간이 충분하므로 디스크 사용률이 낮아집니다. 그럼에도 불구하고 경우에 따라 디스크 공간 메트릭을 검토하는 것이 좋습니다. Cassandra는 많은 디스크를 누적한 다음 압축이 트리거되면 디스크를 줄입니다. 따라서 공간을 회수할 수 없는 압축과 같은 추세를 파악하기 위해 장기간에 걸쳐 디스크 사용량을 검토해야 합니다.

참고 항목

압축에 사용 가능한 공간을 확보하려면 디스크 사용률을 약 50%로 유지해야 합니다.

소수의 노드에서만 이 동작이 나타나는 경우 핫 파티션이 있을 수 있으며 잠재적인 기울이기에 대한 데이터 배포 및/또는 액세스 패턴을 검토해야 합니다.

디스크를 더 추가하되 SKU에서 부과하는 IOPS 제한에 유의해야 합니다.
클러스터를 수평으로 스케일 업

JVM 메모리

기본 수식은 VM 메모리의 절반을 JVM에 할당하며 상한은 31GB입니다. 이는 대부분의 경우 성능과 메모리 간의 균형이 잘 맞습니다. 일부 워크로드, 특히 파티션 간 읽기 또는 범위 검사가 빈번한 워크로드에서는 메모리 문제가 발생할 수 있습니다.

대부분의 경우 메모리는 Java 가비지 수집기에 의해 효과적으로 회수되지만 특히 CPU가 80%를 초과하는 경우 남은 가비지 수집기에 대한 CPU 주기가 충분하지 않습니다. 따라서 모든 CPU 성능 문제는 메모리 문제보다 먼저 해결되어야 합니다.

CPU가 70% 미만이고 가비지 수집이 메모리를 회수할 수 없는 경우 JVM 메모리가 더 필요할 수 있습니다. 메모리가 제한된 SKU를 사용하는 경우 특히 그렇습니다. 대부분의 경우 쿼리 및 클라이언트 설정을 검토하고 CQL 쿼리 내 limit에서 선택한 항목과 함께 fetch_size를 줄여야 합니다.

실제로 더 많은 메모리가 필요한 경우 다음을 수행할 수 있습니다.

JVM 메모리 설정을 늘리려면 티켓을 제출합니다.
더 많은 메모리를 사용할 수 있는 SKU로 수직 크기 조정

삭제 표식

TTL이 만료된 행("삭제 표식"이라고 함)을 제거하는 reaper를 사용하여 7일마다 복구를 실행합니다. 일부 워크로드는 삭제 빈도가 더 높으며 Cassandra 로그에 Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold)와 같은 경고가 표시되거나 과도한 삭제 표식으로 인해 쿼리를 수행할 수 없음을 나타내는 오류도 표시됩니다.

쿼리가 충족되지 않는 경우 단기적인 완화 방법은 Cassandra 구성의 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.

이 경우 쿼리를 검토하여 권장 일괄 처리 크기 미만으로 유지해야 합니다. 드문 경우지만 단기적인 완화 방법으로 Cassandra 구성의 batch_size_fail_threshold_in_kb를 기본값인 50에서 더 높은 값으로 늘릴 수 있습니다.

큰 파티션 경고

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의 경우 이로 인해 플러시가 자주 발생하고 SSD가 조각화되어 더 많은 압축이 필요할 수 있습니다. 이러한 경우 최소 4048로 늘리는 것이 도움이 될 수 있지만 다른 작업(예: 읽기)이 영향을 받지 않도록 주의 깊은 벤치마킹이 필요합니다.

다음 단계

이 문서에서는 최적의 성능을 위한 몇 가지 모범 사례를 제시했습니다. 이제 클러스터 사용을 시작할 수 있습니다.

Azure Portal을 사용하여 클러스터 만들기

다음을 통해 공유