Hardware Choices — 하드웨어 선택

Hardware Choices — 하드웨어 선택

대부분의 데이터베이스와 마찬가지로 Cassandra는 CPU 코어가 많고, RAM이 크고, 디스크가 빠를수록 처리량이 좋아져요. 테스트·개발 환경(Raspberry Pi 포함)에서는 작은 서버에서도 돌릴 수 있지만, 최소 프로덕션 서버는 2코어 이상과 최소 8GB RAM이 필요해요. 일반적인 프로덕션 서버는 8코어 이상과 최소 32GB RAM을 써요.

출처: Hardware Choices

본문

CPU

Cassandra는 고도로 동시적이에요. 가능한 많은 CPU 코어에서 실행되는 다중 스레드로 수많은 동시 요청(읽기·쓰기 모두)을 처리해요. Cassandra의 쓰기 경로는 보통 크게 최적화되어 있어서(commitlog에 쓰고 데이터를 멤테이블에 삽입), 특히 쓰기가 CPU 바운드가 되는 경향이 있어요. 따라서 CPU 코어를 추가하면 읽기와 쓰기 처리량이 모두 늘어나는 경우가 많아요.

Memory (메모리)

Cassandra는 Java VM 안에서 실행되며, 이 VM은 고정 크기 힙(java의 Xmx 시스템 파라미터)을 사전 할당해요. 힙 외에도 Cassandra는 압축 메타데이터, 블룸 필터, 행·키·카운터 캐시, 프로세스 내 페이지 캐시 등에 상당량의 RAM을 off-heap으로 사용해요. 마지막으로 Cassandra는 운영체제의 페이지 캐시를 활용해 최근 접근된 파일 부분을 RAM에 저장해 빠르게 재사용해요.

최적의 성능을 위해 운영자는 자신의 워크로드에 맞춰 클러스터를 벤치마킹·튜닝해야 해요. 다만 기본 지침은 다음과 같아요.

  • ECC RAM을 항상 사용하세요. Cassandra는 비트 수준 손상을 막는 내부 보호 장치가 거의 없어요.
  • Cassandra 힙은 2GB 이상, 시스템 RAM의 50% 이하여야 해요.
  • 12GB보다 작은 힙은 ParNew/ConcurrentMarkSweep 가비지 컬렉션을 고려하세요.
  • 12GB보다 큰 힙은 다음 중 하나를 고려하세요:
    • 16GB 힙 + 8-10GB new gen, survivor ratio 4-6, 최대 tenuring threshold 6
    • G1GC

Disks (디스크)

Cassandra는 서로 매우 다른 두 가지 목적을 위해 데이터를 디스크에 영속해요. 첫 번째는 새 쓰기가 있을 때 commitlog에 쓰는 것으로, 크래시나 시스템 종료 후 재생(replay)할 수 있게 하는 거예요. 두 번째는 임계값을 초과해 멤테이블이 SSTable로 디스크에 플러시될 때 데이터 디렉터리에 쓰는 거예요.

Commitlog는 Cassandra 노드에 이루어진 모든 쓰기를 받으며 클라이언트 작업을 막을 가능성이 있지만, 노드 시작 시에만 읽혀요. 반면 SSTable(데이터 파일) 쓰기는 비동기로 발생하지만, 클라이언트 검색을 충족시키기 위해 읽혀요. SSTable은 컴팩션이라는 과정으로 주기적으로 병합·재작성되기도 해요. commitlog 디렉터리에 있는 데이터는 아직 SSTable 데이터 디렉터리에 영구 저장되지 않은 데이터로, SSTable 데이터 파일로 플러시되면 주기적으로 제거돼요.

Cassandra는 스피닝 하드 드라이브(HDD)와 SSD 모두에서 아주 잘 동작해요. 두 경우 모두 Cassandra의 정렬된 불변 SSTable 덕분에 선형 읽기, 적은 시크(seek), 적은 덮어쓰기가 가능해져, HDD의 처리량을 극대화하고 쓰기 증폭을 피해 SSD 수명을 늘려 줘요. 다만 스피닝 디스크를 사용할 때는 commitlog(commitlog_directory)가 하나의 물리 디스크(파티션이 아니라 물리 디스크)에 있어야 하고, 데이터 파일(data_file_directories)은 별도의 물리 디스크로 설정하는 것이 중요해요. commitlog를 데이터 디렉터리와 분리하면, 읽기가 디스크의 다양한 SSTable에서 데이터를 요청하며 플래터를 시크할 필요 없이 commitlog에 순차 추가함으로써 쓰기가 이점을 얻을 수 있어요.

대부분의 경우 Cassandra는 여러 대의 독립적이고 저렴한 서버로 중복성을 제공하도록 설계됐어요. 그래서 데이터 디렉터리에 NFS나 SAN을 쓰는 것은 안티패턴이며 피해야 해요. 마찬가지로 디스크가 여러 개인 서버는 RAID1이나 RAID5보다 RAID0이나 JBOD를 쓰는 게 더 나은 경우가 많아요. Cassandra가 제공하는 복제가 디스크 계층의 복제 필요성을 없애므로, RAID1·RAID5로 장애를 대비하기보다 RAID0의 추가 처리량을 활용하는 것이 보통 권장돼요.

Common Cloud Choices (일반적인 클라우드 선택)

Cassandra의 많은 대규모 사용자는 AWS, Azure, GCE 등 다양한 클라우드에서 실행하며, 어느 환경에서든 잘 동작해요. 사용자는 물리 공간에서 필요한 것과 비슷한 하드웨어를 선택해야 해요. EC2에서 인기 있는 옵션은 다음과 같아요.

  • i2 인스턴스 — 높은 RAM:CPU 비율과 로컬 임시 SSD 제공
  • i3 인스턴스 — NVMe 디스크
  • EBS — 쉬운 백업·교체를 원하면 잘 동작해요.
  • m4.2xlarge / c4.4xlarge 인스턴스 — 최신 CPU·강화 네트워킹 제공, EBS GP2(SSD) 저장소와 잘 맞음

일반적으로 디스크·네트워크 성능은 인스턴스 크기와 세대가 커질수록 좋아지므로, 각 패밀리 내에서 더 새롭고 더 큰 인스턴스 유형이 더 나은 성능을 내는 경우가 많아요.

더 알아보기 (Learn more)