분산 NoSQL 데이터베이스의 대표 주자인 Apache Cassandra를 운영하고 계신다면, 각 버전의 지원 종료 일정을 정확히 파악하는 것이 무엇보다 중요합니다. 특히 2024년 9월 Cassandra 5.0 출시와 함께 3.x 시리즈의 공식 지원이 종료되면서, 많은 기업들이 업그레이드 계획을 재검토하고 있습니다. 이번 글에서는 Apache Cassandra의 모든 주요 버전별 지원 종료 일정과 각 클라우드 제공업체의 연장 지원 정책까지 상세히 알아보겠습니다.

1. Apache Cassandra 지원 정책 기본 이해하기

Apache Cassandra 프로젝트는 최신 3개 릴리즈를 동시에 지원하는 정책을 운영하고 있습니다. 이는 다른 오픈소스 프로젝트와 비교해 비교적 넉넉한 지원 정책으로, 기업 환경에서의 안정적인 운영을 고려한 것입니다.

지원 정책의 핵심 원칙

• 호환성 유지: 인접한 메이저 버전 간 호환성 보장
• 다운타임 없는 업그레이드: 한 메이저 버전에서 다음 메이저 버전으로의 온라인 업그레이드 지원
• 패치 릴리즈: 보안 취약점 및 중요 버그 수정을 위한 정기적인 패치 릴리즈

2. 현재 지원 중인 Cassandra 버전 현황

2024년 9월 현재, Apache Cassandra에서 공식 지원하는 버전은 다음과 같습니다:

상세 패치 버전 정보

Cassandra 5.0.x 시리즈:

• 5.0.0 (2024-09-05) – GA 릴리즈
• 5.0.1 (2024-11-08) – 최신 안정 버전

Cassandra 4.1.x 시리즈:

• 4.1.0 (2022-07-13) – 초기 릴리즈
• 4.1.1 (2022-10-03) – 버그 수정
• 4.1.2 (2023-02-23) – 보안 업데이트
• 4.1.3 (2023-05-10) – 안정성 개선
• 4.1.4 (2023-11-01) – CVE 대응
• 4.1.5 (2024-02-12) – 성능 최적화
• 4.1.6 (2024-04-15) – 버그 수정
• 4.1.7 (2024-06-20) – 보안 패치
• 4.1.8 (2024-08-14) – 안정성 개선
• 4.1.9 (2024-11-05) – 최신 패치 버전

Cassandra 4.0.x 시리즈:

• 4.0.0 (2021-07-26) – GA 릴리즈
• 4.0.1 (2021-09-30) – 초기 버그 수정
• 4.0.2 (2021-12-14) – 안정성 개선
• 4.0.3 (2022-02-11) – 보안 업데이트
• 4.0.4 (2022-05-17) – 성능 개선
• 4.0.5 (2022-08-29) – 버그 수정
• 4.0.6 (2022-10-03) – CVE 대응
• 4.0.7 (2022-10-23) – 안정성 강화
• 4.0.8 (2023-02-23) – 보안 패치
• 4.0.9 (2023-05-10) – 버그 수정
• 4.0.10 (2023-08-18) – 성능 최적화
• 4.0.11 (2023-11-01) – CVE 대응
• 4.0.12 (2024-02-12) – 안정성 개선
• 4.0.13 (2024-04-15) – 버그 수정
• 4.0.14 (2024-06-20) – 보안 업데이트
• 4.0.15 (2024-08-14) – 성능 개선
• 4.0.16 (2024-09-30) – 안정성 강화
• 4.0.17 (2024-10-25) – 버그 수정
• 4.0.18 (2024-11-05) – 최신 패치 버전

3. 지원 종료된 버전과 EOL 일정 완전 정리

Apache Cassandra 전체 버전 히스토리 및 EOL 상태

다음은 Apache Cassandra 프로젝트 역사상 출시된 모든 메이저 버전의 완전한 정리입니다:

3.x 시리즈 상세 패치 버전 정보

Cassandra 3.11.x 시리즈 (EOL: 2024년 9월):

Cassandra 3.0.x 시리즈 (EOL: 2024년 9월):

레거시 버전들 (Historical Versions)

Cassandra 2.2.x 시리즈:

• 초기 릴리즈: 2014년 8월 12일
• 최종 버전: 2.2.19 (2017년 추정)
• 주요 기능: JSON 지원, 사용자 정의 타입 (UDT), 개선된 압축

Cassandra 2.1.x 시리즈:

• 초기 릴리즈: 2014년 1월 9일
• 최종 버전: 2.1.22 (2016년 추정)
• 주요 기능: 증분 복구, 사용자 정의 함수

Cassandra 2.0.x 시리즈:

• 초기 릴리즈: 2013년 9월 3일
• 최종 버전: 2.0.17 (2015년 추정)
• 주요 기능: CQL3 완전 지원, 가벼운 트랜잭션 (LWT)

Cassandra 1.x 시리즈:

• 1.2.x: 2012년 10월 ~ 2014년 (최종: 1.2.19)
• 1.1.x: 2012년 4월 ~ 2013년 (최종: 1.1.12)
• 1.0.x: 2011년 10월 ~ 2012년 (최종: 1.0.12) – 첫 번째 안정 릴리즈

4. 클라우드 제공업체 및 상용 배포판별 연장 지원 정책

공식 지원이 종료된 후에도 여러 클라우드 제공업체와 상용 배포판에서는 자체적으로 연장 지원을 제공하고 있습니다.

주요 클라우드 제공업체별 지원 정책

DataStax Enterprise (DSE) 지원 정책

DataStax Enterprise는 Apache Cassandra를 기반으로 한 상용 배포판으로, 별도의 지원 정책을 운영합니다:

DSE 지원 정책 설명:

• EOL (End of Life): 일반 기술 지원 종료
• EOSL (End of Service Life): 연장 지원도 완전 종료

Microsoft Azure – Cosmos DB for Cassandra

지원 내용:

• CVE 패치 적용 (CVE patches)
• 프로덕션 이슈 관련 버그 수정
• 턴키 인플레이스 메이저 버전 업그레이드 지원
• 하이브리드 클러스터 구성을 통한 마이그레이션 지원

마이그레이션 경로:

• 기존 셀프 호스팅 → Azure Managed Instance
• 하이브리드 클러스터를 통한 점진적 마이그레이션
• 자동화된 백업 및 복구 시스템

NetApp Instaclustr 연장 지원

지원 조건:

• 관리형 플랫폼 고객 대상
• Enterprise Support 고객에게 우선 제공
• 보안 패치 및 중요 버그 수정 포함
• 24/7 프로덕션 SLA 지원 유지

업그레이드 경로:

• Cassandra 3.11.19 → 4.0.17+ 직접 업그레이드
• Cassandra 3.11.19 → 4.1.8+ 직접 업그레이드
• 5.0으로의 추후 업그레이드 지원

AWS Amazon Keyspaces 전환 옵션

Amazon Keyspaces는 Apache Cassandra와 호환되는 완전 관리형 서버리스 데이터베이스 서비스입니다:

주요 특징:

• Cassandra 3.11.2와 호환되는 CQL API
• 서버리스 아키텍처로 자동 스케일링
• 기존 Cassandra 애플리케이션 마이그레이션 지원
• AWS 네이티브 보안 및 모니터링 통합

마이그레이션 도구:

• cqlsh COPY 명령어
• AWS Database Migration Service
• Cassandra Migration Toolkit

기타 상용 지원 옵션

5. 버전별 주요 기능과 업그레이드 호환성 매트릭스

전체 버전 업그레이드 호환성 매트릭스

다음 표는 Apache Cassandra 버전 간 업그레이드 호환성을 보여줍니다:

업그레이드 규칙:

• ✅ 직접 업그레이드: 바로 업그레이드 가능
• ❌ 지원안함: 메이저 버전을 건너뛰는 업그레이드는 지원되지 않음
• ❌ 다운그레이드: 하위 버전으로의 다운그레이드는 공식 지원되지 않음

JVM 호환성 매트릭스

각 Cassandra 버전별 지원되는 Java 버전:

운영체제 지원 매트릭스

각 버전별 혁신적 기능 상세 분석

Cassandra 5.0.x – 차세대 기능의 집약체

🔥 핵심 신기능:

Cassandra 4.1.x – 운영 편의성의 혁신

🛠️ 주요 개선사항:

Cassandra 4.0.x – 안정성의 이정표

⚡ 핵심 기능:

레거시 버전들의 역사적 의미

Cassandra 3.11.x (EOL)

중요한 마지막 3.x 버전:

• 마지막 Java 8 완전 지원 버전
• 안정적인 프로덕션 환경에서 가장 널리 사용됨
• 많은 엔터프라이즈 환경의 표준 버전

Cassandra 3.0.x (EOL)

새로운 시대의 시작:

• Materialized Views 도입 (후에 deprecated)
• 새로운 스토리지 엔진 (SSTable 3.0 format)
• JSON 지원 확대

Cassandra 2.x 시리즈 (EOL)

프로덕션 환경별 권장 버전

6. 상세 업그레이드 방법과 마이그레이션 체크리스트

버전별 맞춤형 업그레이드 전략

3.11.x → 4.0.x 업그레이드 (가장 일반적)

1단계: 사전 준비 (Pre-Upgrade)

2단계: 롤링 업그레이드 실행

# 노드별 순차 업그레이드 스크립트 예시
#!/bin/bash

# 1. 현재 노드 상태 확인
nodetool status

# 2. 해당 노드 드레인
nodetool drain

# 3. Cassandra 서비스 정지
sudo systemctl stop cassandra

# 4. 패키지 업그레이드
sudo yum update cassandra -y  # RHEL/CentOS
# 또는
sudo apt update && sudo apt upgrade cassandra  # Ubuntu/Debian

# 5. 설정 파일 검토 및 조정
sudo vim /etc/cassandra/cassandra.yaml

# 6. 서비스 재시작
sudo systemctl start cassandra

# 7. 노드 상태 확인
nodetool status
nodetool info

# 8. 다음 노드로 진행 전 안정성 확인
sleep 300  # 5분 대기

3단계: 업그레이드 후 검증

3.0.x → 4.1.x 업그레이드 (2단계 업그레이드)

권장 경로: 3.0.x → 4.0.x → 4.1.x

graph LR
    A[3.0.x] --> B[4.0.x]
    B --> C[4.1.x]
    
    A1[설정 준비] --> A
    B1[중간 검증] --> B
    C1[최종 검증] --> C

4.x → 5.0.x 업그레이드 (최신 기능 활용)

특별 고려사항:

• JDK 17 필수 요구사항
• SAI 인덱스 마이그레이션 계획
• Vector 데이터 타입 활용 검토

JDK 업그레이드 체크리스트:

클러스터 크기별 업그레이드 전략

소규모 클러스터 (3-6 노드)

권장 방식: 순차 롤링 업그레이드

• 소요 시간: 2-4시간
• 다운타임: 없음 (RF ≥ 2인 경우)
• 위험도: 낮음

중간 규모 클러스터 (7-20 노드)

권장 방식: 랙별 롤링 업그레이드

• 소요 시간: 6-12시간
• 다운타임: 없음
• 병렬 처리: 랙당 1노드씩

대규모 클러스터 (21+ 노드)

권장 방식: 데이터센터별 단계적 업그레이드

• 소요 시간: 1-3일
• 위험 관리: DC별 독립적 진행
• 트래픽 분산: 로드밸런서 활용

업그레이드 실패 시 롤백 절차

자동 롤백 스크립트

#!/bin/bash
# 긴급 롤백 스크립트

ROLLBACK_VERSION="3.11.19"
BACKUP_CONFIG="/opt/cassandra-backup/config"

echo "=== 긴급 롤백 시작 ==="

# 1. 서비스 정지
sudo systemctl stop cassandra

# 2. 이전 버전 패키지 설치
sudo yum downgrade cassandra-${ROLLBACK_VERSION} -y

# 3. 설정 파일 복원
sudo cp ${BACKUP_CONFIG}/cassandra.yaml /etc/cassandra/

# 4. 데이터 디렉토리 권한 확인
sudo chown -R cassandra:cassandra /var/lib/cassandra

# 5. 서비스 재시작
sudo systemctl start cassandra

# 6. 상태 확인
sleep 30
nodetool status

echo "=== 롤백 완료 ==="

업그레이드 모니터링 체크리스트

실시간 모니터링 지표

성능 벤치마크 비교

업그레이드 전후 성능 측정

# 업그레이드 전 성능 기준 측정
cassandra-stress write n=1000000 \
  -rate threads=50 \
  -node 192.168.1.10,192.168.1.11,192.168.1.12

# 업그레이드 후 성능 검증
cassandra-stress read n=1000000 \
  -rate threads=50 \
  -node 192.168.1.10,192.168.1.11,192.168.1.12

# 혼합 워크로드 테스트
cassandra-stress mixed ratio\(write=1,read=3\) n=1000000 \
  -rate threads=50 \
  -node 192.168.1.10,192.168.1.11,192.168.1.12

데이터 무결성 검증 절차

업그레이드 프로젝트 타임라인

전체 프로젝트 일정 (3.11 → 4.1 업그레이드 예시)

조직별 업그레이드 역할과 책임

7. 업그레이드 하지 않을 때의 리스크와 보안 고려사항

보안 취약점 노출

지원이 종료된 버전을 계속 사용할 경우:

• CVE 패치 미적용: 새로운 보안 취약점에 대한 패치 제공 중단
• 규정 준수 문제: 기업 보안 정책 위반 가능성
• 기술 부채 누적: 시간이 지날수록 업그레이드 복잡도 증가

성능 및 안정성 이슈

• 최적화 기회 손실: 새 버전의 성능 개선 혜택 미누림
• 하드웨어 호환성: 최신 하드웨어와의 호환성 문제 발생 가능
• 커뮤니티 지원 감소: 기술 지원 및 문제 해결 어려움 증대

Apache Cassandra 3.x 시리즈의 공식 지원 종료로 인해, 많은 조직들이 업그레이드 결정을 내려야 하는 시점에 있습니다.

즉시 엑션이 필요한 경우:

• 현재 3.x 버전 사용 중인 프로덕션 환경
• 보안 규정 준수가 중요한 환경
• 최신 기능 활용이 필요한 프로젝트

단계적 접근이 가능한 경우:

• 클라우드 제공업체의 연장 지원 이용 가능
• 내부 시스템으로 외부 노출 위험이 낮음
• 충분한 마이그레이션 계획 수립 시간 확보

무엇보다 중요한 것은 미루지 않는 것입니다. 시간이 지날수록 기술 부채는 커지고, 업그레이드의 복잡도는 증가하게 됩니다. 지금이 Cassandra의 최신 기능들을 활용하여 시스템을 한 단계 발전시킬 수 있는 절호의 기회입니다. 🙂

관련 링크:

• Apache Cassandra 공식 사이트
• Cassandra 5.0 릴리즈 노트
• EOL 공식 발표
• EndOfLife.date – Cassandra