[기술사례] Ceph 기반 스토리지 내재화로 상용 스토리지 대체하기

 

Tech-Frontier.md  kt cloud

$ whoami --team ❯ kt cloud Storage플랫폼팀 엄주관 님

📋 요약 TL;DR

이 글에서는 Ceph 기반 스토리지 내재화로 상용 스토리지를 대체하기 위한 배경과 설계 방향을 다룹니다. 비용 효율과 기술 통제권이 클라우드 운영 경쟁력에 미치는 의미를 정리합니다. #Ceph #스토리지내재화 #분산스토리지 #오브젝트스토리지 #클라우드인프라

---

왜 스토리지 내재화가 필요했는가

클라우드 서비스를 운영할수록 스토리지 비용은 누적되고, 서비스 규모가 커질수록 상용 라이선스 구조의 부담도 함께 커집니다. 특히 저장 용량 증가와 함께 비용이 지속적으로 상승하는 구조는 장기적으로 수익성에 직접적인 영향을 줍니다.

 

또한 벤더별 제품을 혼합 운영하는 환경에서는 운영 정책, 장애 대응 방식, 기능 차이가 누적되며 통합 관리 난이도가 높아집니다. 여기에 AI, 빅데이터, 아카이브 워크로드처럼 대용량과 비용 효율을 동시에 요구하는 신규 수요가 증가하면서 기존 방식만으로는 유연한 대응이 어려워졌습니다.

 

이런 배경에서 스토리지 내재화는 단순한 비용 절감 과제가 아니라, 핵심 인프라에 대한 기술 통제권을 확보하고 서비스 전략의 유연성을 높이기 위한 선택이 되었습니다.

---

왜 Ceph를 선택했는가

오픈소스 분산 스토리지 가운데 Ceph를 주목한 이유는 단순히 유명한 프로젝트이기 때문이 아닙니다. 다양한 스토리지 유형을 단일 플랫폼으로 통합할 수 있고, 대규모 확장성과 장애 대응 능력을 갖추고 있으며, 클라우드 환경과의 호환성이 높다는 점이 실제 서비스 관점에서 중요한 장점이었습니다.

하나의 플랫폼으로 오브젝트, 블록, 파일을 통합

Ceph는 RADOS를 기반으로 오브젝트 스토리지인 RGW, 블록 스토리지인 RBD, 파일 시스템인 CephFS를 제공합니다. 즉, 각기 다른 스토리지 서비스를 별도 솔루션으로 구축하는 대신 하나의 공통 플랫폼 위에서 통합 운영할 수 있습니다.

 

이 구조는 장기적으로 인프라 복잡도를 줄이고 운영 표준화를 가능하게 합니다. 서비스 유형이 늘어나더라도 기술 기반이 분산되지 않는다는 점에서 내재화 전략과 높은 궁합을 가집니다.

CRUSH 알고리즘 기반의 확장성과 장애 대응

Ceph의 핵심 설계 중 하나는 CRUSH(Controlled Replication Under Scalable Hashing) 알고리즘입니다. 일반적인 분산 스토리지가 데이터 위치 관리를 위해 중앙 메타데이터 서버에 의존하는 반면, Ceph는 계산 기반으로 데이터 배치 위치를 결정합니다.

 

CRUSH Map은 물리 인프라 구조를 반영하고, CRUSH Rule은 복제본을 어떤 장애 도메인 기준으로 분산할지 정의합니다. 예를 들어 복제본 수를 3으로 설정하고 장애 도메인을 호스트 단위로 두면, 서로 다른 3개의 호스트에 데이터가 분산됩니다. 랙 단위 장애까지 고려해야 한다면 장애 도메인을 랙으로 확장할 수 있습니다.

 

이 방식은 메타데이터 병목을 줄이는 동시에, 장애 상황에서도 예측 가능한 데이터 재배치를 가능하게 합니다.

Strong Consistency와 Self-Healing

Ceph는 Strong Consistency 모델을 기반으로 동작합니다. 쓰기 요청은 필요한 복제본에 기록이 반영된 뒤에야 성공으로 처리되므로, 데이터 신뢰성 측면에서 안정적인 동작을 기대할 수 있습니다.

 

또한 일부 OSD에 장애가 발생하더라도 클러스터는 상태를 감지하고 자동으로 데이터를 재복제하는 Self-Healing 메커니즘을 수행합니다. 운영자가 모든 복구 작업을 수동으로 처리하지 않아도 된다는 점은 대규모 환경에서 중요한 운영상 이점입니다.

클라우드 생태계와의 높은 호환성

Ceph는 OpenStack, Kubernetes, S3 API 기반 애플리케이션, NFS, NVMe-oF 등 다양한 플랫폼과 연계 가능합니다. 범용 x86 또는 ARM 하드웨어 위에서 구축할 수 있기 때문에 하드웨어 선택권 역시 넓습니다.

 

이는 특정 하드웨어나 벤더 조합에 종속되지 않는 스토리지 플랫폼을 설계하는 데 유리하며, 향후 서비스 확장 방향에도 유연하게 대응할 수 있게 합니다.

---

운영 현실과 기술적 도전

Ceph는 강력한 기능을 제공하지만, 실제 운영은 결코 단순하지 않습니다. 분산 시스템 특유의 복잡성 때문에 리눅스 커널, 네트워크, 스토리지 미디어 특성, 장애 복구 동작에 대한 폭넓은 이해가 필요합니다.

 

특히 초기 아키텍처 설계와 튜닝은 결과에 큰 영향을 미칩니다. 복제 정책, 장애 도메인 설계, 디스크 클래스 분리, 네트워크 구성, 워크로드별 풀 설계 등은 단순 설정이 아니라 서비스 품질을 좌우하는 핵심 결정입니다. 따라서 Ceph 도입은 제품 설치보다 운영 체계 설계에 더 가까운 과제라고 볼 수 있습니다.

---

안정성 확보를 위한 빌드 및 검증 전략

운영 안정성과 기능 확보 속도를 동시에 고려하기 위해, 커뮤니티 버전을 그대로 사용하는 대신 엔터프라이즈 소스 기반 내부 빌드 전략을 검토했습니다. 핵심 아이디어는 필드에서 충분히 검증된 엔터프라이즈 계열 소스를 바탕으로 내부 컨테이너 이미지를 구성하고, 필요한 검증을 자체적으로 수행하는 방식입니다.

 

이 접근은 커뮤니티 릴리즈에 즉시 반영되지 않은 수정 사항이나 기능을 더 빠르게 확보할 수 있다는 장점이 있습니다. 실제로 상용 환경에서 필요한 일부 호환성 기능이 커뮤니티 정식 릴리즈에는 늦게 반영되는 경우가 있기 때문에, 안정성과 민첩성 사이에서 현실적인 대안이 될 수 있습니다.

 

물론 특정 엔터프라이즈 소스 흐름에 대한 의존성이 커질 수 있다는 점은 주의해야 합니다. 따라서 내부 빌드 전략은 단기 대응책이 아니라, 오픈소스 버전과의 전환 가능성까지 포함한 이중 검증 체계를 함께 가져가야 의미가 있습니다.

---

테스트 자동화의 중요성

빌드 전략만으로는 충분하지 않습니다. 내부적으로 생성한 이미지와 패키지가 실제 운영 환경에서 기대한 대로 동작하는지를 반복적으로 검증할 수 있어야 합니다.

 

이를 위해 유닛 테스트와 통합 테스트 체계를 함께 운영하는 접근이 필요합니다. 특히 Ceph 전용 테스트 프레임워크인 Teuthology 기반 검증은 클러스터 구성, 기능 동작, 회귀 테스트를 체계적으로 수행하는 데 유용합니다. 테스트가 자동화될수록 기능 반영 속도는 빨라지고 운영 반영 리스크는 낮아집니다.

---

클라우드 플랫폼과 일관된 통합을 위한 고민

오늘날 대부분의 애플리케이션과 데이터 플랫폼은 사실상 표준이 된 AWS S3 API와 IAM 기반 권한 모델을 전제로 설계되고 있습니다. 따라서 오브젝트 스토리지 역시 AWS와의 호환성을 제공하는 것이 필수 요구사항이 되었습니다. 하지만 JWT 기반 인증 체계를 사용하는 자사의 클라우드 플랫폼 (kt cloud PLATFORM)과 S3 Access Key와 Secret Key 기반의 AWS 인증 방식을 사용하는 오브젝트 스토리지 서비스 간의 인증 통합은 쉽지 않은 과제입니다. 이로 인해 사용자는 플랫폼 로그인과 별도로 S3 인증 정보를 발급·관리해야 할 수 밖에 없습니다. 결국 AWS 호환성을 유지하면서도 사용자가 하나의 플랫폼처럼 자연스럽게 사용할 수 있도록 만드는 것이 중요한 과제가 됩니다.

 

이를 해결하기 위한 방안으로 Ceph 외에 다른 오브젝트 스토리지를 포함한 멀티 백엔드를 지원하는 별도의 서비스 통제 계층을 설계하여 JWT, AK/SK SigV4 등 다양한 인증 방식을 일괄 검증 후 재서명 처리하고 고객 별 정밀한 미터링/QoS 적용 기능을 제공하기 위한 방안을 고려 중입니다. 향후 좀 더 구체화된 기능과 내역을 공유드릴 수 있도록 하겠습니다.

---

적용 기대 효과

Ceph 기반 스토리지 내재화가 성공적으로 자리 잡는다면 기대할 수 있는 효과는 명확합니다.

• 상용 라이선스 중심 구조에서 벗어나 장기적인 원가 경쟁력을 확보할 수 있습니다.
• 스토리지 유형별로 분리된 솔루션을 줄여 운영 복잡도를 완화할 수 있습니다.
• 오브젝트, 블록, 파일 서비스로 확장 가능한 공통 플랫폼을 기반으로 신규 서비스를 빠르게 설계할 수 있습니다.
• 특정 벤더 정책 변화에 따른 리스크를 줄이고, 기술 로드맵을 내부 우선순위에 맞게 조정할 수 있습니다.
• AI, 빅데이터, 아카이브와 같은 고성장 워크로드에 대해 비용 효율적인 스토리지 전략을 수립할 수 있습니다.

---

향후 계획

다음 단계에서는 실제 서비스 환경에 가까운 조건에서 성능, 확장성, 가용성, 프로토콜 호환성, 암호화, 자원 관리, 모니터링 항목을 종합적으로 검증하는 작업이 중요합니다.

 

중장기적으로는 Ceph를 단일 스토리지 제품이 아니라 플랫폼으로 바라보고, 오브젝트 스토리지를 넘어 블록 및 파일 서비스까지 확장하는 방향을 고려할 수 있습니다. 이는 단순한 인프라 교체가 아니라, 클라우드 서비스 포트폴리오를 뒷받침하는 기반 체계를 새롭게 설계하는 과정이기도 합니다.

---

스토리지 내재화는 비용 절감만을 위한 선택이 아닙니다. 핵심 인프라 기술을 스스로 이해하고 통제할 수 있는 구조를 만드는 일이며, 장기적으로는 클라우드 서비스 경쟁력의 기반이 됩니다.

 

Ceph는 그 여정에서 매우 강력한 도구가 될 수 있지만, 동시에 높은 운영 성숙도를 요구하는 기술이기도 합니다. 결국 중요한 것은 소프트웨어 자체보다도, 이를 어떤 기준으로 설계하고 어떤 검증 체계를 통해 운영 가능한 플랫폼으로 만들 것인가에 있습니다.

 

---

?› 자주 묻는 질문 FAQ

Q. Ceph 운영에서 가장 어려운 지점은 무엇인가

A. 분산 시스템 운영 전반에 대한 이해가 필요하다는 점입니다. 단순 설치보다 설계, 튜닝, 장애 분석, 성능 검증이 훨씬 중요하며, 이를 뒷받침할 테스트 체계와 운영 경험이 요구됩니다.

Q. CRUSH의 장애 도메인 설계는 왜 중요한가

A. 복제본이 서로 독립적인 장애 구간에 배치되어야 실제 장애 상황에서 데이터 가용성을 보장할 수 있기 때문입니다. 호스트 단위, 랙 단위, 더 넓은 물리 도메인 단위로 설계 기준을 어떻게 잡느냐에 따라 가용성과 자원 효율의 균형점이 달라집니다.

---