[스토리지] OpenStack Swift vs Ceph 선택 기준 심층 비교

목차

• 1. 왜 OpenStack Swift vs Ceph 비교가 계속 나올까요?
• 2. 핵심 개념 설명: Swift와 Ceph를 쉽게 풀어보면
• 2-1. OpenStack Swift란?
• 2-2. Ceph란?
• 2-3. 한 줄 차이
• 3. 클라우드 스토리지 선택 기준: 무엇을 먼저 봐야 할까요?
• 4. 실전 구현: Swift와 Ceph를 어떻게 검증해보면 좋을까요?
• 4-1. Swift 검증 포인트
• 4-2. Ceph 검증 포인트
• 4-3. S3 호환성과 테스트 업로드
• 5. Swift Ceph 성능, 숫자보다 더 중요한 운영 특성
• 6. ⚠️ 실제 운영에서 자주 만나는 문제와 트러블슈팅
• 6-1. Swift에서 겪기 쉬운 문제
• 6-2. Ceph에서 겪기 쉬운 문제
• 7. 검증과 결과: 어떤 팀에 무엇이 더 맞았나
• 8. 정리: 대규모 객체 스토리지 선택, 이렇게 가져가시면 됩니다

[스토리지] OpenStack Swift vs Ceph 선택 기준 심층 비교

대규모 객체 스토리지(Object Storage) 이야기를 하다 보면 결국 많이 나오는 조합이 있습니다. 바로 OpenStack Swift Ceph 비교죠. 저도 처음엔 둘 다 그냥 "오브젝트 스토리지니까 비슷한 거 아닌가?" 싶었는데, 실제로 설계하고 운영해보니 성격이 꽤 다르더라고요. 특히 객체 스토리지 솔루션을 새로 도입하려는 팀, 혹은 프라이빗 클라우드(private cloud)를 운영하는 팀이라면 여기서 방향을 잘못 잡으면 나중에 운영 복잡도가 확 올라갑니다.

제가 13년 정도 인프라 쪽에서 일하면서 느낀 건, 스토리지는 벤더 브로셔보다 운영팀의 현실이 더 중요하다는 점입니다. 성능 숫자 몇 개보다도, 장애 났을 때 복구 흐름이 명확한지, 팀이 감당할 수 있는 아키텍처인지, 기존 클라우드 스택과 얼마나 잘 붙는지가 훨씬 중요했거든요. 이번 글에서는 OpenStack Swift와 Ceph를 기능 나열식이 아니라, 실제 선택 기준 중심으로 풀어보겠습니다.

Swift의 프록시 기반 구조와 Ceph의 클러스터형 구조를 한눈에 보여주는 비교 이미지입니다.

1. 왜 OpenStack Swift vs Ceph 비교가 계속 나올까요?

쉽게 말해 둘 다 분산 스토리지(Distributed Storage)이고, 둘 다 대규모 확장을 염두에 둔 설계거든요. 근데 접근 방식이 다릅니다. Swift는 오브젝트 스토리지에 좀 더 집중된 구조이고, Ceph는 오브젝트(Object), 블록(Block), 파일(File)을 함께 다룰 수 있는 범용 분산 스토리지에 가깝습니다.

현장에서 이 차이가 바로 드러나는 순간이 있어요. 예를 들어 개발팀은 S3 호환 API만 있으면 된다고 말하는데, 플랫폼팀은 나중에 가상머신 디스크나 Kubernetes 스토리지까지 같이 보고 싶어 합니다. 이럴 때 Swift는 "오브젝트 저장소를 깔끔하게 운영"하는 쪽으로 강점이 있고, Ceph는 "스토리지 플랫폼을 하나로 통합"하는 쪽으로 무게가 실립니다.

• Swift: 오브젝트 스토리지 중심, OpenStack 친화적
• Ceph: 오브젝트, 블록, 파일을 아우르는 통합형
• 선택 포인트: 기능 수보다 운영 목적과 팀 역량이 더 중요

혹시 이런 경험 있으신가요? 처음엔 백업 저장소로 시작했는데, 나중엔 이미지 저장, 로그 아카이브, VM 디스크, 컨테이너 볼륨까지 다 얹히는 경우요. 저도 몇 번 겪었는데, 그때 초기 선택이 발목을 잡기도 했습니다.

2. 핵심 개념 설명: Swift와 Ceph를 쉽게 풀어보면

2-1. OpenStack Swift란?

OpenStack Swift는 OpenStack 생태계에서 나온 오브젝트 스토리지입니다. 데이터는 Account / Container / Object 구조로 관리되고, 프록시(proxy)와 스토리지 노드(storage node), 그리고 링(ring) 기반 데이터 배치 개념이 핵심이거든요. 저도 처음 링 파일 개념을 봤을 때는 "이걸 왜 이렇게까지 나눴지?" 싶었는데, 실제로는 대규모 노드 분산과 재배치 관점에서 꽤 실용적이더라고요.

2-2. Ceph란?

Ceph는 객체 스토리지로만 보면 RADOS Gateway(RGW)를 통해 S3/Swift 스타일 API를 제공할 수 있고, 내부적으로는 RADOS라는 분산 객체 계층 위에 RBD(Block Device), CephFS(File System) 같은 서비스가 올라갑니다. 핵심은 CRUSH 알고리즘 기반의 데이터 배치와, 모니터(MON), 매니저(MGR), OSD(Object Storage Daemon) 조합이거든요.

2-3. 한 줄 차이

제가 실무에서 멘토링할 때 자주 하는 설명이 있습니다. Swift는 목적형 오브젝트 스토리지, Ceph는 스토리지 플랫폼입니다. 이 한 줄이 생각보다 많은 걸 정리해주더라고요.

항목	OpenStack Swift	Ceph
주 용도	객체 스토리지 중심	객체, 블록, 파일 통합
아키텍처 성격	역할 분리형, 링 기반	클러스터형, CRUSH 기반
OpenStack 연계	친화적	Cinder, Glance, Manila 등과 폭넓게 연동
운영 포인트	오브젝트 워크로드 최적화	통합 스토리지 운영 복잡도 관리

3. 클라우드 스토리지 선택 기준: 무엇을 먼저 봐야 할까요?

클라우드 스토리지 선택에서 가장 흔한 실수가 "성능이 더 좋다더라"만 보고 결정하는 거거든요. 근데 여기서 중요한 포인트! 객체 스토리지는 단순 벤치마크보다 워크로드 특성이 훨씬 중요합니다.

1. 워크로드 유형 확인
   백업, 로그 아카이브, 미디어 저장, VM 이미지, 컨테이너 볼륨 중 무엇이 주력인지 먼저 정리합니다.
2. API 요구사항 확인
   S3 호환성이 중요한지, OpenStack 네이티브 연동이 중요한지 봅니다.
3. 운영팀 역량 평가
   장애 분석, 리밸런싱(rebalancing), 확장 작업을 누가 얼마나 자주 할지 생각해야 합니다.
4. 확장 단위 확인
   단순 용량 확장인지, 멀티 서비스 확장인지에 따라 선택이 갈립니다.
5. 장애 도메인 설계
   랙(rack), 호스트(host), 존(zone), 리전(region) 단위 복제 전략을 어떻게 가져갈지 정해야 합니다.

제 경험상 아래처럼 정리하면 판단이 빨라졌어요.

• 오브젝트 저장이 핵심이고 OpenStack 친화성이 중요하다: Swift 우선 검토
• 향후 블록/파일까지 통합할 가능성이 높다: Ceph 우선 검토
• 운영팀이 분산 스토리지 튜닝 경험이 많지 않다: 단순한 운영 모델을 먼저 고려
• 대규모 자동화와 장기 확장을 노린다: 배치 정책과 장애 복구 절차를 먼저 설계

4. 실전 구현: Swift와 Ceph를 어떻게 검증해보면 좋을까요?

여기서는 "당장 프로덕션에 올리는 설치 가이드"보다는, 비교 검증용 랩(lab) 환경을 어떻게 잡으면 좋은지 중심으로 말씀드릴게요. 홈랩에서도 축소형으로 충분히 감을 잡을 수 있습니다. 저도 처음엔 큰 장비 없이 VM 몇 대로 감을 익혔어요. 삽질 좀 했습니다 ㅎㅎ

4-1. Swift 검증 포인트

Swift는 프록시 노드와 스토리지 노드 역할을 나누고, 링 파일을 통해 데이터 배치를 정의합니다. 실제 검증에서는 다음을 꼭 봅니다.

• 프록시를 통해 PUT/GET 지연이 어떻게 나오는지
• 리플리케이션(replication) 이후 데이터 일관성 흐름
• 노드 추가 시 링 재배포 절차 난이도

# 예시: Swift ring-builder 기본 흐름
swift-ring-builder account.builder create 18 3 1
swift-ring-builder container.builder create 18 3 1
swift-ring-builder object.builder create 18 3 1

swift-ring-builder account.builder add r1z1-10.0.0.11:6202/d1 100
swift-ring-builder container.builder add r1z1-10.0.0.11:6201/d1 100
swift-ring-builder object.builder add r1z1-10.0.0.11:6200/d1 100

swift-ring-builder account.builder rebalance
swift-ring-builder container.builder rebalance
swift-ring-builder object.builder rebalance

이 명령 흐름에서 중요한 건 숫자 외우는 게 아닙니다. 파티션(partition) 수, 복제 수, 장애 도메인 배치가 운영 철학을 반영한다는 점이거든요. 실제로 써보니까 여기 설계를 대충 하면 나중에 증설할 때 정말 피곤해지더라고요.

4-2. Ceph 검증 포인트

Ceph는 최소한 MON, MGR, OSD 구조를 이해하고 들어가야 합니다. 오브젝트 스토리지만 보더라도 결국 내부 건강 상태는 OSD 분포와 PG(Placement Group) 균형에서 드러나거든요.

# 예시: Ceph 상태 확인과 풀(pool) 생성 흐름
ceph -s
ceph osd tree
ceph health detail

radosgw-admin user create --uid=testuser --display-name="Test User"
ceph osd pool create object-test 32
rados ls -p object-test

여기서 초반에 꼭 확인할 건 클러스터 헬스(cluster health)입니다. API 붙이기 전에 저장 계층이 안정적인지부터 봐야 해요. 이 순서를 거꾸로 하면 문제 원인 추적이 정말 힘들어지더라고요.

Swift의 링 기반 분산과 Ceph의 CRUSH 기반 분산 개념을 비교하는 구성도입니다.

4-3. S3 호환성과 테스트 업로드

실전에서는 결국 애플리케이션이 붙어야 하니 간단한 업로드 테스트를 같이 봅니다.

# 예시: S3 API 엔드포인트 검증용 aws cli 테스트
aws --endpoint-url http://rgw.example.local s3 mb s3://lab-bucket
aws --endpoint-url http://rgw.example.local s3 cp sample.log s3://lab-bucket/
aws --endpoint-url http://rgw.example.local s3 ls s3://lab-bucket/

Swift도 미들웨어(middleware)나 호환 계층을 어떻게 둘지에 따라 접근 방식이 달라집니다. 그래서 단순 기능 체크보다 현재 애플리케이션이 어떤 API를 기대하는지 먼저 보는 게 맞습니다.

5. Swift Ceph 성능, 숫자보다 더 중요한 운영 특성

Swift Ceph 성능 이야기를 할 때 조심해야 할 게 있습니다. 동일한 하드웨어, 동일한 네트워크, 동일한 복제 정책이 아니면 숫자 비교 자체가 큰 의미가 없거든요. 그래서 저는 성능을 볼 때 아래처럼 나눠서 봅니다.

• 소형 객체 처리: 메타데이터 부담, API 처리량
• 대용량 스트림: 순차 업로드/다운로드 안정성
• 복구 중 성능: 장애 이후 리밸런싱 시 서비스 영향
• 확장 후 균형: 노드 추가 뒤 데이터 재배치 비용

Swift는 오브젝트 스토리지에 맞춘 단순성과 분리가 장점으로 느껴질 때가 있습니다. 반면 Ceph는 잘 구성하면 매우 유연하지만, 그만큼 봐야 할 지표와 튜닝 포인트가 더 많아요. 저도 초반에는 Ceph가 만능처럼 보여서 무조건 좋은 줄 알았는데, 작은 팀에서는 그 유연성이 오히려 운영 부담으로 돌아오더라고요.

비교 기준	Swift에서 볼 점	Ceph에서 볼 점
확장성	링 재배치 운영 절차	OSD 추가 후 데이터 재균형
장애 복구	복제/재동기화 흐름	클러스터 헬스와 백필(backfill) 영향
운영 복잡도	역할 구분이 명확	기능이 많은 만큼 관리 포인트 증가
API 활용	오브젝트 중심 설계	RGW 기반 S3/Swift 스타일 접근

6. ⚠️ 실제 운영에서 자주 만나는 문제와 트러블슈팅

여기부터가 진짜 중요합니다. 비교표는 다들 잘 만드는데, 실제 문제는 운영 중에 나오거든요.

6-1. Swift에서 겪기 쉬운 문제

• 링 변경 후 기대와 다른 분산
  원인: 초기 장비 가중치(weight) 설계가 부정확했거나 증설 정책이 일관되지 않은 경우가 많습니다.
• 프록시 병목
  원인: 백엔드 디스크보다 앞단 프록시 처리량이 먼저 막히는 경우가 있습니다.
• 운영자 이해도 편차
  원인: 링, 존, 디바이스 매핑 개념을 팀 전체가 공유하지 않으면 장애 대응 속도가 확 떨어집니다.

6-2. Ceph에서 겪기 쉬운 문제

• HEALTH_WARN 장기 지속
  원인: PG 불균형, OSD out/in 반복, 복구 작업 장기화 같은 문제가 숨어 있는 경우가 많습니다.
• 기능은 많은데 운영이 복잡함
  원인: 블록, 파일, 오브젝트를 한 번에 다 열면 초반 운영 난도가 급격히 올라갑니다.
• 성능 이슈 원인 파악 난이도
  원인: 네트워크, 디스크, PG 상태, 복제 정책 등 봐야 할 층이 많습니다.

제가 직접 해보니 공통 해법은 비슷했어요.

1. 처음부터 모든 기능을 열지 않습니다.
2. 장애 도메인과 확장 정책을 문서로 먼저 고정합니다.
3. 성능 테스트보다 복구 테스트를 먼저 합니다.
4. 운영팀이 매일 보는 대시보드 항목을 표준화합니다.

복구 중인 클러스터 상태, 용량 분포, 경고 지표를 시각화한 운영 관점 이미지입니다.

7. 검증과 결과: 어떤 팀에 무엇이 더 맞았나

랩과 운영 경험을 합쳐보면, 저는 보통 이렇게 정리합니다.

• Swift가 잘 맞는 경우: 대용량 오브젝트 저장이 주력이고, OpenStack와 자연스럽게 붙여 쓰려는 경우
• Ceph가 잘 맞는 경우: 오브젝트 외에 블록 스토리지와 파일 스토리지까지 함께 설계하려는 경우
• 작은 팀의 현실: 기능 많음이 항상 장점은 아닙니다. 운영 가능성이 더 중요해요.

특히 OpenStack Swift Ceph 비교에서 빠지면 안 되는 결론이 하나 있습니다. 무엇이 더 우월한가가 아니라, 우리 조직에 무엇이 덜 위험한가를 봐야 한다는 점이거든요. 이거 진짜 중요합니다.

검증할 때는 아래 체크리스트를 남겨두면 좋습니다.

# 공통 검증 체크 예시
# 1. 업로드/다운로드 정상 여부
# 2. 노드 1대 장애 시 접근 가능 여부
# 3. 복구 중 응답 지연 변화
# 4. 증설 후 재배치 시간과 영향도
# 5. 모니터링 지표 수집 가능 여부

이전 글에서 다뤘던 모니터링 스택과 연결하면 더 좋고, 다음 글에서는 Prometheus(프로메테우스)와 Grafana(그라파나) 기준으로 분산 스토리지 지표를 어떻게 봐야 하는지도 다뤄볼 만하겠네요.

8. 정리: 대규모 객체 스토리지 선택, 이렇게 가져가시면 됩니다

마무리해보겠습니다. 객체 스토리지 솔루션을 고를 때 Swift와 Ceph는 둘 다 훌륭한 선택지가 될 수 있습니다. 다만 성격이 다르거든요. Swift는 오브젝트 스토리지에 집중한 구조, Ceph는 더 넓은 범위를 아우르는 스토리지 플랫폼입니다.

저도 처음엔 기능이 많은 쪽이 무조건 정답인 줄 알았는데, 실제로 운영해보니까 그렇지 않더라고요. 팀이 이해하고, 장애를 감당하고, 확장을 반복할 수 있어야 비로소 좋은 선택이 됩니다. 드디어 됐다! 싶은 순간은 설치 완료가 아니라, 장애 한 번 겪고도 팀이 침착하게 복구할 수 있을 때 오더라고요.

• 오브젝트 중심 + OpenStack 친화성: Swift 쪽이 더 자연스러울 수 있습니다.
• 통합형 분산 스토리지 전략: Ceph 쪽이 더 유리할 수 있습니다.
• 성능보다 중요한 것: 운영 복잡도, 장애 복구, 증설 절차입니다.

워크로드, 운영 난이도, 확장성 기준으로 Swift와 Ceph를 요약 비교한 인포그래픽입니다.

혹시 지금 프라이빗 클라우드나 백업 스토리지 때문에 고민 중이시라면, 먼저 "우리 팀이 실제로 운영 가능한 구조인가"부터 체크해보세요. 그다음에야 아키텍처가 선명해집니다. 다음 글에서는 클라우드 스토리지 선택 관점에서 S3 호환 오브젝트 스토리지 검증 항목을 더 실무적으로 정리해보겠습니다. ✅

📚 함께 읽으면 좋은 글

• 오픈스택 플레이버 최적화로 유휴 자원 줄이기
• OpenStack Cinder 볼륨 생성 실패? 흔한 원인과 해결책
• OpenStack Trove vs RDS 마이그레이션, 왜 AWS RDS로 옮겼나
• Kubernetes 스토리지: Longhorn vs Rook-Ceph 성능 벤치마크
• Ceph 스토리지 성능 벤치마크: HDD vs SSD, 홈랩에서 직접 해보니