프로덕션 권장 사항

프로덕션 권장 사항 (Production recommendations)

cassandra.yaml과 jvm.options 파일에는 프로덕션 사용에 대한 많은 참고 사항과 권장 사항이 있어요. 이 페이지는 파일의 정보 중 일부를 확장해 설명해요.

출처: Production recommendations

본문

토큰 (Tokens)

노드당 둘 이상의 토큰 범위를 사용하는 것을 가상 노드(virtual nodes) 또는 vnode라고 해요. vnodes는 새 노드가 클러스터에 부트스트랩할 때 더 많은 스트리밍 피어로 유연한 확장을 용이하게 해요. 스트리밍의 부정적 영향(I/O와 CPU 오버헤드)을 제한하면 점진적 클러스터 확장이 가능해져요. 그러나 토큰이 많을수록 더 많은 피어와 데이터를 공유하게 되고, 결과적으로 가용성이 감소해요. 이 두 요소는 클러스터의 특성(읽기와 쓰기)에 따라 균형을 맞춰야 해요. 더 자세히 알아보려면 Cassandra Availability in Virtual Nodes, Joseph Lynch and Josh Snyder를 읽어 보길 권장해요.

cassandra.yaml 파일의 설정을 사용해 토큰 수를 변경해요:

num_tokens: 16

다음은 가장 일반적인 토큰 수와 각각을 언제, 왜 사용하는지에 대한 간단한 설명이에요.

토큰 수 설명
1 최대 가용성, 최대 클러스터 크기, 최소 피어, 하지만 확장이 유연하지 않아요. 확장하고 균형을 유지하려면 항상 클러스터 크기를 두 배로 늘려야 해요.
4 탄력성과 가용성의 건강한 혼합. 결국 30노드 이상에 도달할 클러스터에 권장. 균형을 유지하려면 약 20% 더 많은 노드를 추가해야 해요. 클러스터 축소는 클러스터 불균형을 초래할 수 있어요.
8 8개 vnode를 사용하면 ~10% 분산으로 시스템 간에 워크로드가 분배되고 성능에 미치는 영향이 최소화돼요.
16 정기적으로 확장과 축소를 반복하는 탄력성이 높은 클러스터에 가장 적합하지만, 더 큰 클러스터에서는 가용성 문제가 있을 수 있어요. 50노드 이상의 클러스터에는 권장되지 않아요.

토큰 수를 설정하는 것 외에도 cassandra.yaml의 allocate_tokens_for_local_replication_factor를 적절한 복제 수로 설정하는 것이 매우 중요해요. 균등한 토큰 할당을 보장하기 위해서예요.

미리 읽기 (Read ahead)

미리 읽기는 페이지 캐시에 가능한 한 많은 데이터를 로드된 상태로 유지하려는 운영 체제 기능이에요. 스피닝 디스크는 긴 탐색 시간으로 높은 지연 시간을 유발할 수 있으므로, 페이지 캐시를 사용한 읽기의 추가 처리량이 성능을 향상시킬 수 있어요. 미리 읽기를 활용하면 OS가 추가 탐색 비용 없이 추가 데이터를 메모리로 가져올 수 있어요. 이 방법은 사용 가능한 RAM이 핫 데이터셋 크기보다 클 때 잘 동작하지만, 반대의 경우(데이터셋 > RAM)에는 문제가 될 수 있어요. 핫 데이터셋이 클수록 미리 읽기가 덜 유용해요.

미리 읽기는 다음 경우에 확실히 유용하지 않아요.

  • 단일 파티션 키가 있는 테이블 같은 작은 파티션
  • 솔리드 스테이트 드라이브(SSD)

미리 읽기는 실제로 디스크 사용량을 증가시킬 수 있으며, 일부 경우에는 최대 5배의 지연 시간과 처리량 성능 저하를 초래할 수 있어요. 읽기 중심의 키/값 테이블에서 작은(1KB 미만) 행을 가진 경우 특히 이 문제에 취약해요.

권장 미리 읽기 설정은:

하드웨어 초기 권장 사항
스피닝 디스크 64KB
SSD 4KB

미리 읽기는 Linux 시스템에서 blockdev 도구를 사용해 조정할 수 있어요.

예를 들어 디스크 /dev/sda1의 미리 읽기를 4KB로 설정해요:

$ blockdev --setra 8 /dev/sda1

참고: blockdev 설정은 미리 읽을 512바이트 섹터 수를 설정해요. 위의 인자 8은 4KB 또는 8 × 512바이트와 같아요.

모든 시스템은 다르므로 이 권장 사항을 출발점으로 사용하고 SLA와 처리량 요구 사항에 따라 튜닝하세요. 미리 읽기가 디스크 리소스 사용에 어떻게 영향을 주는지 이해하려면 Diving Deep, using external tools 섹션을 주의 깊게 읽어 보길 권장해요.

압축 (Compression)

압축된 데이터는 고정 크기 바이트 버퍼를 압축하고 데이터를 디스크에 쓰는 방식으로 저장돼요. 버퍼 크기는 테이블 스키마 설정의 WITH COMPRESSION 압축 맵에서 chunk_length_in_kb 요소로 결정돼요. 기본 설정은 Cassandra 4.0부터 16KB예요.

압축된 전체 버퍼를 디스크에서 읽어야 하므로, 너무 큰 압축 청크 길이를 사용하면 작은 레코드를 읽을 때 상당한 오버헤드가 발생할 수 있어요. 기본 미리 읽기 설정과 결합하면 특정 워크로드에서 막대한 읽기 증폭이 발생할 수 있어요. 따라서 이 설정에 적절한 값을 선택하는 것이 중요해요.

LZ4Compressor가 기본이고 권장되는 압축 알고리즘이에요. 압축에 대한 추가 정보가 필요하면 The Last Pickle 블로그의 압축 성능 포스트를 읽어 보세요.

컴팩션 (Compaction)

서로 다른 워크로드에 대해 서로 다른 compaction 전략이 있어요. 다양한 전략을 읽어 환경에 가장 적합한 것이 무엇인지 이해하길 권장해요. 서로 다른 테이블이 같은 클러스터에서 서로 다른 컴팩션 전략을 사용할 수 있고, 실제로 자주 사용해요.

암호화 (Encryption)

프로덕션 클러스터를 설정할 때 피어 간(peer-to-peer) 암호화와 클라이언트-서버 암호화를 설정하는 것이 훨씬 좋아요. 클러스터가 프로덕션 트래픽을 서비스한 후에 설정하는 것은 올바르게 하기 어려워요. 어떤 유형의 네트워크 암호화를 계획한다면, 클러스터를 초기 구성할 때 설정하길 권장해요. 나중에 이러한 구성을 변경하는 것이 불가능한 것은 아니지만, 실수는 다운타임이나 데이터 손실을 초래할 수 있어요.

키스페이스가 NetworkTopologyStrategy로 생성되도록 보장

프로덕션 클러스터는 절대 SimpleStrategy를 사용해서는 안 돼요. 프로덕션 키스페이스는 NetworkTopologyStrategy(NTS)를 사용해야 해요. 예를 들어:

CREATE KEYSPACE mykeyspace WITH replication =     {
   'class': 'NetworkTopologyStrategy',
   'datacenter1': 3
};

NetworkTopologyStrategy로 초기화된 Cassandra 클러스터는 여러 랙과 데이터센터를 구성하는 기능을 활용할 수 있어요.

랙과 스니치 구성

클러스터가 프로비저닝된 후에 랙을 올바르게 구성하거나 변경하는 것은 지원되지 않는 과정이에요. 단일 랙에서 여러 랙으로 마이그레이션하는 것도 지원되지 않으며 데이터 손실을 초래할 수 있어요. GossipingPropertyFileSnitch를 사용하는 것이 온프레미스 또는 하이브리드 클라우드 환경에서 가장 유연한 해결책이에요. Ec2Snitch는 AWS EC2 전용 환경에 적합해요.

더 알아보기 (Learn more)