다음을 통해 공유

Azure VM에서 Apache Cassandra 실행

  • 아티클

주의

이 문서에서는 EOL(수명 종료)된 Linux 배포판인 CentOS를 참조합니다. 이에 따라 사용 및 플랜을 고려하세요. 자세한 내용은 CentOS 수명 종료 지침을 참조하세요.

이 문서에서는 Azure Virtual Machines에서 Apache Cassandra를 실행하기 위한 성능 고려 사항을 설명합니다.

이러한 권장 사항은 GitHub에서 찾을 수 있는 성능 테스트 결과를 기반으로 합니다. 이러한 권장 사항을 기준으로 사용한 다음, 자체 워크로드에 대해 테스트해야 합니다.

Apache Cassandra용 Azure Managed Instance

Azure Virtual Machines에서 Apache Cassandra를 실행하기 위한 보다 자동화된 서비스를 찾고 있는 경우 Apache Cassandra용 Azure Managed Instance를 사용하는 것이 좋습니다. 이 서비스는 Apache Cassandra 클러스터 내의 노드 배포, 관리(패치 및 노드 상태) 및 크기 조정을 자동화합니다. 또한 하이브리드 클러스터에 대한 기능을 제공하므로 Azure에 배포된 Apache Cassandra 데이터 센터는 기존 온-프레미스 또는 타사 호스팅 Cassandra 링에 조인할 수 있습니다. 이 서비스는 Azure Virtual Machine Scale Sets를 사용하여 배포됩니다. 이 서비스를 개발하는 동안 채택된 권장 사항은 다음과 같습니다.

Azure VM 크기 및 디스크 유형

Azure의 Cassandra 워크로드는 일반적으로 Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 또는 Standard_E16s_v5 가상 머신을 사용합니다. Cassandra 워크로드는 VM에 더 많은 메모리를 보유할 수 있으므로 메모리 최적화 가상 머신 크기(예: Standard_DS14_v2 또는 Standard_E16s_v5) 또는 로컬 스토리지 최적화 크기(예: Standard_L16s_v3)를 고려해 보세요.

내구성을 위해 데이터 및 커밋 로그는 일반적으로 2~4개의 1TB 프리미엄 관리 디스크(P30)로 구성된 스트라이프 집합에 저장됩니다.

Cassandra 노드는 데이터 밀도가 너무 높아서는 안 됩니다. VM당 최대 1~2TB의 데이터와 압축을 위한 충분한 여유 공간이 있는 것이 좋습니다. 프리미엄 관리 디스크를 사용하여 가능한 가장 높은 처리량 및 IOPS를 달성하려면 단일 2TB 또는 4TB 디스크를 사용하는 대신 여러 개의 1TB 디스크에서 스트라이프 집합을 만드는 것이 좋습니다. 예를 들어 DS14_v2 VM에서 1TB 디스크 4개의 최대 IOPS는 4× 5000 = 20K이고 단일 4TB 디스크의 경우 7.5K입니다.

더 작은 디스크 용량이 필요한 Cassandra 워크로드에 대한 Azure Ultra Disks를 평가하세요. 이는 Standard_E16s_v5 및 Standard_D16s_v5와 같은 VM 크기에서 더 높은 IOPS/처리량과 짧은 대기 시간을 제공할 수 있습니다.

지속성 스토리지가 필요하지 않은 Cassandra 워크로드, 즉 다른 스토리지 매체에서 데이터를 쉽게 재구성할 수 있는 워크로드의 경우 Standard_L16s_v3 또는 Standard_L16s_v2 VM을 사용하는 것이 좋습니다. 이러한 VM 크기에는 크고 빠른 로컬 NVM Express(NVMe) 디스크가 있습니다.

자세한 내용은 Azure 로컬/임시 디스크와 연결된/영구 디스크의 성능 비교(GitHub)를 참조하세요.

가속 네트워킹

Cassandra 노드는 클라이언트 VM에서 데이터를 주고받고, 복제를 위해 노드 간에 통신하기 위해 네트워크를 많이 사용합니다. 최적의 성능을 위해 Cassandra VM은 처리량이 높고 대기 시간이 짧은 네트워크를 활용하는 것이 좋습니다.

Cassandra 노드의 NIC 및 Cassandra에 액세스하는 클라이언트 애플리케이션을 실행하는 VM에서 가속화된 네트워킹을 사용하도록 설정하는 것이 좋습니다.

가속화된 네트워킹에는 Cent OS 7.5 이상 또는 Ubuntu 16.x/18.x와 같은 최신 드라이버가 포함된 최신 Linux 배포가 필요합니다. 자세한 내용은 가속화된 네트워킹을 사용하여 Linux 가상 머신 만들기를 참조하세요.

Azure VM 데이터 디스크 캐싱

Cassandra 읽기 워크로드는 임의 액세스 디스크 대기 시간이 짧을 때 가장 성능이 좋습니다. ReadOnly 캐싱이 사용하도록 설정된 Azure 관리 디스크를 사용하는 것이 좋습니다. ReadOnly 캐싱은 백 엔드 스토리지로 가는 대신 호스트의 캐시에서 데이터를 읽기 때문에 평균 대기 시간이 짧습니다.

캐시된 모드가 캐시되지 않은 모드보다 처리량 제한이 낮더라도 Cassandra와 같이 읽기가 많은 임의 읽기 워크로드는 읽기 대기 시간이 짧으면 좋습니다. (예: DS14_v2 가상 머신의 최대 캐시 처리량은 512MBps이고 캐시되지 않은 처리량은 768MBps입니다.)

ReadOnly 캐싱은 작업 데이터 세트가 호스트 캐시에 적합하고 데이터가 지속적으로 덮어써지지 않는 Cassandra 시계열 및 기타 워크로드에 특히 유용합니다. 예를 들어 DS14_v2는 1-2TB 데이터 밀도를 가진 Cassandra 노드에서 데이터의 최대 50%를 저장할 수 있는 512GB의 캐시 크기를 제공합니다.

ReadOnly 캐싱을 사용하는 경우 캐시 누락으로 인한 상당한 성능 저하가 없으므로 가장 쓰기가 많은 워크로드를 제외한 모든 워크로드에 캐시 모드를 사용하는 것이 좋습니다.

자세한 내용은 Azure VM 데이터 디스크 캐싱 구성 비교(GitHub)를 참조하세요.

Linux 미리 읽기

Azure Marketplace의 대부분의 Linux 배포에서 기본 블록 디바이스 미리 읽기 설정은 4096KB입니다. Cassandra의 읽기 I/OS는 일반적으로 임의이며 상대적으로 작습니다. 따라서 미리 읽기가 큰 경우 필요하지 않은 파일의 일부를 읽어 처리량이 낭비됩니다.

불필요한 lookahead를 최소화하려면 Linux 블록 디바이스 미리 읽기 설정을 8KB로 지정합니다. (DataStax 설명서의 권장 프로덕션 설정을 참조하세요.)

스트라이프 집합 및 배열 디바이스 자체(예: /dev/md0)의 모든 블록 디바이스에 대해 8KB 미리 읽기를 구성합니다.

자세한 내용은 디스크 미리 읽기 설정의 영향 비교(GitHub)를 참조하세요.

디스크 배열 mdadm 청크 크기

Azure에서 Cassandra를 실행하는 경우 여러 데이터 디스크의 mdadm 스트라이프 집합(즉, RAID 0)을 만들어 전체 디스크 처리량 및 IOPS를 VM 제한에 더 가깝게 늘리는 것이 일반적입니다. 최적의 디스크 스트라이프 크기는 애플리케이션별 설정입니다. 예를 들어 SQL Server OLTP 워크로드에 권장되는 크기는 64KB입니다. 데이터 웨어하우징 워크로드에 권장되는 크기는 256KB입니다.

테스트 결과, Cassandra 읽기 워크로드의 64k, 128k 및 256k 청크 크기 간에 큰 차이가 없다는 사실이 밝혀졌습니다. 128k 청크 크기에 약간 눈에 띄는 이점이 있는 것 같습니다. 따라서 다음을 권장합니다.

  • 64K 또는 256K의 청크 크기를 이미 사용 중인 경우 128K 크기를 사용하기 위해 디스크 배열을 다시 빌드하는 것은 의미가 없습니다.

  • 새 구성의 경우 처음부터 128K를 사용하는 것이 좋습니다.

자세한 내용은 mdadm 청크 크기가 Cassandra 성능에 미치는 영향 측정(GitHub)을 참조하세요.

로그 파일 시스템 커밋

커밋 로그가 처리량이 높고 대기 시간이 짧은 디스크에 있는 경우 Cassandra 쓰기가 가장 잘 수행됩니다. 기본 구성에서 Cassandra 3.x는 최대 10초마다 메모리에서 커밋 로그 파일로 데이터를 플러시하고 모든 쓰기에 대한 디스크를 건드리지 않습니다. 이 구성에서는 커밋 로그가 프리미엄 연결 디스크에 있든, 로컬/임시 디스크에 있든 관계없이 쓰기 성능은 거의 동일합니다.

다시 시작된 노드가 플러시된 커밋 로그의 데이터 파일에 아직 없는 데이터를 다시 구성할 수 있도록 커밋 로그에 내구성이 있어야 합니다. 내구성을 높이려면 로컬 스토리지가 아닌 프리미엄 관리 디스크에 커밋 로그를 저장합니다. 로컬 스토리지의 경우 VM이 다른 호스트로 마이그레이션되면 데이터가 손실될 수 있습니다.

테스트 결과에 따르면, 커밋 로그가 xfs 및 ext4 파일 시스템에 있을 때 CentOS 7.x의 Cassandra는 쓰기 성능이 더 낮을 수 있습니다. 커밋 로그 압축을 켜면 ext4와 일치하는 xfs 성능이 제공됩니다. 테스트 결과에 따르면, 압축된 xfs는 압축된 ext4 및 압축되지 않은 ext4와 비슷한 성능을 제공합니다.

자세한 내용은 ext4 및 xfs 파일 시스템 및 압축된 커밋 로그에 대한 관찰(GitHub)을 참조하세요.

기준 VM 성능 측정

Cassandra 링용 VM을 배포한 후 몇 가지 가상 테스트를 실행하여 기준 네트워크 및 디스크 성능을 설정합니다. 이러한 테스트를 사용하여 성능이 VM 크기에 따른 예상과 일치하는지 확인합니다.

나중에 실제 워크로드를 실행할 때 성능 기준을 알고 있으면 잠재적인 병목 상태를 더 쉽게 조사할 수 있습니다. 예를 들어 VM에서 네트워크 송신에 대한 기준 성능을 알면 병목 상태인 네트워크를 배제하는 데 도움이 될 수 있습니다.

성능 테스트 실행에 대한 자세한 내용은 기준 Azure VM 성능 유효성 검사(GitHub)를 참조하세요.

문서 크기

Cassandra 읽기 및 쓰기 성능은 문서 크기에 따라 달라집니다. 더 큰 문서를 사용하여 읽거나 쓸 때 더 높은 대기 시간 및 더 낮은 작업/초를 기대할 수 있습니다.

자세한 내용은 다양한 Cassandra 문서 크기의 상대적 성능 비교(GitHub)를 참조하세요.

복제 계수

대부분의 Cassandra 워크로드는 연결된 프리미엄 디스크를 사용하는 경우 RF(복제 계수) 3을 사용하고 임시 로컬 디스크를 사용할 때는 5까지 사용합니다. Cassandra 링의 노드 수는 복제 요소의 배수여야 합니다. 예를 들어 RF 3은 3, 6, 9 또는 12개 노드의 링을 의미하지만 RF 5에는 5, 10, 15 또는 20개의 노드가 있습니다. RF가 1보다 크고 일관성 수준 LOCAL_QUORUM을 사용하는 경우 읽기 및 쓰기 성능이 RF 1에서 실행되는 동일한 워크로드보다 낮은 것이 정상입니다.

자세한 내용은 다양한 복제 요소의 상대적 성능 비교(GitHub)를 참조하세요.

Linux 페이지 캐싱

Cassandra의 Java 코드는 데이터 파일을 읽을 때 일반 파일 I/O를 사용하고 Linux 페이지 캐싱의 이점을 활용합니다. 파일의 일부를 한 번 읽으면 읽기 콘텐츠가 OS 페이지 캐시에 저장됩니다. 동일한 데이터에 대한 후속 읽기 액세스가 훨씬 빠릅니다.

이러한 이유로 동일한 데이터에 대해 읽기 성능 테스트를 실행할 때 두 번째 및 후속 읽기는 원래 읽기보다 훨씬 빠른 것으로 나타나며, ReadOnly가 사용하도록 설정된 경우 원격 데이터 디스크 또는 호스트 캐시의 데이터에 액세스해야 했습니다. 후속 실행에서 유사한 성능 측정값을 얻으려면 Linux 페이지 캐시를 지우고 Cassandra 서비스를 다시 시작하여 내부 메모리를 지웁니다. ReadOnly 캐싱이 사용하도록 설정된 경우 데이터가 호스트 캐시에 있을 수 있으며 OS 페이지 캐시를 지우고 Cassandra 서비스를 다시 시작한 후에도 후속 읽기가 더 빨라집니다.

자세한 내용은 Linux 페이지 캐싱의 Cassandra 사용에 대한 관찰(GitHub)을 참조하세요.

다중 데이터 센터 복제

Cassandra는 기본적으로 여러 데이터 센터의 개념을 지원하므로 여러 Azure 지역 또는 한 지역 내의 가용성 영역에서 하나의 Cassandra 링을 쉽게 구성할 수 있습니다.

다중 지역 배포의 경우 Azure Global VNet 피어링을 사용하여 다른 지역의 가상 네트워크를 연결합니다. VM이 동일한 지역의 서로 다른 가용성 영역에 배포되는 경우 VM은 동일한 가상 네트워크에 있을 수 있습니다.

지역 간의 기준 왕복 대기 시간을 측정하는 것이 중요합니다. 지역 간의 네트워크 대기 시간은 지역 내 대기 시간보다 10~100배 더 높을 수 있습니다. LOCAL_QUORUM 쓰기 일관성을 사용할 때는 두 번째 지역에 표시되는 데이터 간에 지연이 발생하고 EACH_QUORUM을 사용하는 경우 쓰기 성능이 크게 저하될 것으로 예상해야 합니다.

특히 다중 DC 환경에서 Apache Cassandra를 대규모로 실행하는 경우 노드 복구가 어려워집니다. 사신과 같은 도구는 대규모 복구를 조정하는 데 도움이 될 수 있습니다(예: 데이터 센터의 모든 노드에서 한 번에 하나의 데이터 센터에서 전체 클러스터의 부하를 제한). 그러나 대규모 클러스터에 대한 노드 복구는 아직 완전히 해결된 문제가 아니며 온-프레미스 또는 클라우드에 관계없이 모든 환경에 적용됩니다.

노드가 보조 지역에 추가되면 일부 대역폭 및 CPU/디스크 리소스가 지역 간에 복제 트래픽을 주고받는 데 사용되므로 성능이 선형으로 확장되지 않습니다.

자세한 내용은 다중 dc 지역 간 복제의 영향 측정(GitHub)을 참조하세요.

힌트 핸드오프 구성

다중 지역 Cassandra 링에서 일관성 수준이 LOCAL_QUORUM인 쓰기 워크로드가 있으면 보조 지역의 데이터가 손실될 수 있습니다. 기본적으로 Cassandra 힌트 핸드오프는 상대적으로 낮은 최대 처리량 및 3시간 힌트 수명으로 제한됩니다. 쓰기가 많은 워크로드의 경우 힌트가 복제되기 전에 삭제되지 않도록 힌트 핸드오프 제한 및 힌트 기간을 늘리는 것이 좋습니다.

자세한 내용은 지역 간 복제의 힌트 핸드오프에 대한 관찰(GitHub)을 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

이러한 성능 결과에 대한 자세한 내용은 Azure VM의 Cassandra 성능 실험을 참조하세요.

Azure와 관련이 없는 일반 Cassandra 설정에 대한 자세한 내용은 다음을 참조하세요.