CentOS 8에 Apache Cassandra 설치 및 구성
소개
Apache Cassandra는 단일 장애점이 없는 오픈소스 고성능 NoSQL 분산 데이터베이스입니다. 한 줄 설명: Cassandra는 고가용성·수평 확장이 필요하고 데이터 손실을 허용할 수 없는 애플리케이션에 적합합니다.
중요: 이 튜토리얼은 CentOS 8 환경에서 로컬 또는 단일 노드 테스트/개발용 설치를 대상으로 합니다. 프로덕션 클러스터는 시드 노드 설계, 네트워크 플래닝, 모니터링, 백업 계획 등 추가 작업이 필요합니다.
요구사항
- CentOS 8 서버(최소 2GB RAM 권장). 더 큰 워크로드는 더 많은 메모리와 CPU 필요.
- 루트 권한 또는 sudo 사용 권한이 있는 계정.
- 인터넷 연결(패키지 저장소 접근용).
시작 전에 서버 업데이트
먼저 시스템을 최신 상태로 업데이트하고 재부팅합니다.
dnf update업데이트 후 변경사항을 적용하려면 시스템을 재부팅하세요.
Java 및 Python 설치
Apache Cassandra는 OpenJDK 8과 Python 2(일부 관리 스크립트용)를 필요로 합니다. 다음 명령으로 설치합니다:
dnf install java-1.8.0-openjdk-devel python2설치 후 Java 버전을 확인합니다:
java -version예상 출력 예시(버전 문자열은 환경에 따라 다릅니다):
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)Apache Cassandra 저장소 추가 및 설치
CentOS 8 기본 저장소에는 Cassandra 패키지가 없으므로 DataStax 커뮤니티 저장소를 추가합니다. 다음 파일을 생성합니다:
nano /etc/yum.repos.d/cassandra.repo파일에 다음 내용을 추가하세요:
[cassandra]
name = DataStax Repo for Apache Cassandra
baseurl = http://rpm.datastax.com/community
enabled = 1
gpgcheck = 0저장 후 다음으로 Cassandra 패키지를 설치합니다:
dnf install dsc20설치가 완료되면 다음 단계로 진행합니다.
systemd 서비스 단위 파일 생성 및 수정
일부 Cassandra 패키지는 자동으로 systemd 서비스 파일을 생성하지 않습니다. 시스템 서비스로 관리하려면 직접 유닛 파일을 만듭니다:
nano /etc/systemd/system/cassandra.service권장 내용:
[Unit]
Description=Apache Cassandra
After=network.target
[Service]
PIDFile=/var/run/cassandra/cassandra.pid
User=cassandra
Group=cassandra
ExecStart=/usr/sbin/cassandra -f -p /var/run/cassandra/cassandra.pid
Restart=always
[Install]
WantedBy=multi-user.target파일을 저장하고 systemd 데몬을 다시 로드합니다:
systemctl daemon-reload서비스를 시작하고 부팅 시 자동 시작하도록 활성화합니다:
systemctl start cassandra
systemctl enable cassandra서비스 상태를 확인합니다:
systemctl status cassandra정상적으로 실행 중이면 로그에 CQL(포트 9042) 또는 Thrift(포트 9160) 바인딩 메시지가 보입니다.
설치 확인
노드 상태를 확인하려면 nodetool을 사용합니다:
nodetool status예상되는 출력 형식(내용은 환경에 따라 다름):
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 127.0.0.1 46.11 KB 256 100.0% 2a680007-8c30-4bde-9a3f-9fa212b96d11 rack1또는 CQL 셸에 접속해 확인합니다:
cqlsh정상 접속 시 메시지 예시:
Connected to Test Cluster at localhost:9160.
[cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh>기본 구성: 클러스터 이름 변경
기본 클러스터 이름을 변경하려면 CQL 셸에서 system.local 레코드를 업데이트하고 cassandra.yaml 파일에도 반영해야 합니다.
CQL에서 변경:
cqlsh
cqlsh> UPDATE system.local SET cluster_name = 'HowtoForge Cluster' WHERE KEY = 'local';
cqlsh> exit;또는 cassandra.yaml 파일을 편집:
nano /etc/cassandra/default.conf/cassandra.yaml다음 라인을 찾아 새 이름으로 변경합니다:
cluster_name: 'HowtoForge Cluster'시스템 캐시를 비우고 Cassandra를 재시작합니다:
nodetool flush system
systemctl restart cassandra재접속 후 CQL 셸에 표시되는 클러스터 이름을 확인하세요.
운영 전 고려사항 요약
- 시드 노드: 클러스터 시작 시 시드 노드를 계획하세요(보통 2~3개). 시드 노드는 토폴로지 안정화에 중요합니다.
- 토큰 및 파티셔닝: 기본 256 토큰 분포가 사용됩니다. 대규모 클러스터는 토큰/가상 노드(VNode) 전략을 검토하세요.
- 복제 인자: 일반적으로 복제인자(replication_factor)는 3을 권장합니다(내결함성 고려).
- 모니터링: nodetool, JMX, Prometheus exporter와 같은 모니터링을 구성하세요.
- 백업/스냅샷: 정기 스냅샷과 SSTable 기반 백업 전략을 설계하세요.
보안 강화 권장 사항
- 바인딩 주소 제한: cassandra.yaml에서 listen_address와 rpc_address를 로컬이 아닌 내부 네트워크로 설정해 불필요한 외부 접근을 차단하세요.
- 인증과 권한: 내부 사용자와 역할 기반 권한 제어(Authenticator 및 Authorizer)를 활성화하세요.
- 암호화: 노드 간 통신과 클라이언트-노드 통신에 TLS를 적용하세요.
- 방화벽: 필요한 포트만 열어두세요(기본 포트: 7000, 7001, 7199, 9042, 9160).
중요: 보안 설정은 서비스 중단을 초래할 수 있으므로 테스트 환경에서 단계별로 검증하세요.
문제 해결 가이드(간단한 런북)
문제: cassandra 서비스가 시작되지 않음
- 확인 1: systemctl status cassandra로 로그를 확인하세요.
- 확인 2: /var/log/cassandra/system.log를 확인하세요.
- 조치: Java 버전 확인, 권한 문제(데이터 디렉터리/사용자), 설정 파일 문법 오류(cassandra.yaml)를 점검.
문제: nodetool status에서 노드가 DOWN으로 표시됨
- 확인: 네트워크 연결, 방화벽, listen_address 설정이 올바른지 확인.
- 조치: 로그에서 GC/메모리 압박 여부 확인, 필요 시 재시작 후 로그 재검토.
문제: cqlsh로 연결 불가
- 확인: Cassandra가 9042 포트에서 바인딩되어 있는지 확인(systemctl status 또는 ss -ltnp).
- 조치: rpc_address 또는 broadcast_rpc_address 설정을 점검하고 방화벽 규칙을 확인.
개발·운영 역할별 체크리스트
시스템 관리자
- Java, Python 패키지 설치
- systemd 유닛 등록 및 자동 시작 설정
- 방화벽과 SELinux 정책 검토
DBA/플랫폼 엔지니어
- 복제 인자 및 키스페이스 설계
- 백업·복구 계획 수립
- 모니터링 및 경보 설정
개발자
- 데이터 모델(광범위한 쓰기 패턴과 파티셔닝)을 Cassandra 특성에 맞게 설계
- CQL 쿼리 최적화 및 TTL/압축 정책 검토
대안 및 언제 Cassandra를 사용하지 않을지
언제 Cassandra가 적합하지 않은가:
- 복잡한 조인과 강한 일관성(ACID)이 필요한 트랜잭션 중심 애플리케이션에는 적합하지 않습니다.
- 단일 노드 환경이나 관계형 스키마가 필요한 경우에는 MySQL/PostgreSQL이 더 적절합니다.
대체 기술:
- 관계형 DB: MySQL, PostgreSQL
- 문서형 DB: MongoDB (다른 일관성·쿼리 모델)
- Cassandra와 호환되는 대체: ScyllaDB(더 빠른 C++ 기반 대체)
소규모 프로덕션 체크리스트(미니 방법론)
- 요구사항 수집: 예상 쓰기/읽기 IO, 데이터 크기, 가용성 목표 정의.
- 용량 계획: 노드당 CPU/메모리/디스크 산정.
- 네트워크 설계: 내부 전용 네트워크, 방화벽 규칙.
- 시드 노드·리플리케이션 전략 결정.
- 모니터링·백업·업데이트 정책 수립.
- 스테이징에서 롤아웃 테스트 후 프로덕션 전개.
용어집(한 줄 요약)
- 노드: 클러스터에 참여하는 Cassandra 인스턴스.
- 시드 노드: 클러스터 부트스트랩 시 초기 연결 대상 역할을 하는 노드.
- 토큰: 데이터 파티셔닝을 결정하는 범위 값.
- 키스페이스: Cassandra에서 데이터베이스와 유사한 범위(복제 정책 포함).
결론
이제 CentOS 8에서 Apache Cassandra를 설치하고 기본적으로 구성하는 방법을 배웠습니다. 개발·테스트 환경에서는 이 구성으로 시작할 수 있습니다. 프로덕션 환경에서는 시드 노드 설계, 복제/백업 전략, 보안 및 모니터링을 반드시 추가로 구현하세요.
Important: 질문이나 특정 오류 로그가 있으면 그 로그와 함께 요청하세요. 더 구체적으로 도와드리겠습니다.
