핵심 인사이트 (3줄 요약)

  1. 과거의 스토리지(SAN/NAS) 시스템은 무조건 중앙에 '마스터 노드'나 '메타데이터 서버'를 두어 파일의 위치를 장부에 적었다. 하지만 서버가 1만 대가 넘어가면 이 중앙 서버 자체가 끔찍한 병목이 된다.
  2. **Ceph(세프)**는 이 중앙 장부를 아예 없애버린 혁명적인 아키텍처다. 데이터를 저장하거나 찾을 때 CRUSH 알고리즘이라는 수학 공식을 돌려, 0.1초 만에 "아! 이 데이터는 3번 랙의 42번 서버에 있겠구나!"라고 스스로 답을 찾아낸다.
  3. Ceph는 밑바닥에 오브젝트 스토리지를 깔고(RADOS), 그 위에서 블록(RBD), 파일(CephFS), 오브젝트(RGW) 스토리지를 동시에 3가지 형태로 제공할 수 있는 유일무이한 만능 스토리지다.

Ⅰ. 중앙 장부(Metadata Server)의 한계

전통적인 분산 파일 시스템(HDFS 등)은 대개 '마스터-슬레이브' 구조입니다.

  1. 고객이 cat.jpg 파일을 달라고 합니다.
  2. 먼저 마스터 서버에게 가서 묻습니다. "마스터님, cat.jpg 어딨나요?"
  3. 마스터가 장부를 뒤진 뒤 대답합니다. "응, 1번 슬레이브 서버에 있어."
  4. 그제야 1번 슬레이브 서버로 가서 파일을 받아옵니다.

만약 초당 1,000만 명이 파일을 달라고 하면, 1,000만 명이 일제히 마스터 서버 한 대에 줄을 서서 질문해야 합니다. 마스터 서버는 과부하로 터져버립니다(Single Point of Failure).

📢 섹션 요약 비유: 도서관에 들어갈 때마다 무조건 1명뿐인 안내데스크 사서(마스터)에게 책 위치를 물어봐야 하는 갑답한 시스템입니다. 도서관이 커질수록 사서 앞의 줄만 길어집니다.

Ⅱ. Ceph와 CRUSH 알고리즘의 마법

Ceph는 "안내데스크 사서를 해고하고, 손님에게 책을 찾는 수학 공식을 알려주자!"는 아이디어입니다.

CRUSH (Controlled Replication Under Scalable Hashing) 고객이 앱에서 cat.jpg를 요청하면, 앱 안에 내장된 Ceph 라이브러리가 다음과 같이 스스로 계산합니다.

  1. cat.jpg의 이름을 해시(Hash) 함수에 넣습니다. (예: 결괏값 12345)
  2. 이 숫자를 현재 Ceph 클러스터의 상태 지도(Cluster Map)와 버무려 CRUSH 공식에 넣고 돌립니다.
  3. 뿅! 하고 서버 42번, 디스크 3번이라는 답이 나옵니다.
  4. 마스터 서버를 거치지 않고, 다이렉트로 42번 서버로 쳐들어가서 파일을 빼옵니다.

Ceph 아키텍처 (ASCII)

 ┌── 클라이언트 (CRUSH 알고리즘 내장) ──┐
 │ "수학 공식 돌려보니 42번이네!" 직행!  │ ◀ (마스터 서버 없음, 병목 0%)
 └──────┬───────────────────────┬───────┘
        ▼                       ▼
 [ OSD 노드 1 ]            [ OSD 노드 42 ] ◀ (실제 하드디스크가 꽂힌 서버)
 [ OSD 노드 2 ]            [ OSD 노드 43 ]
   (RADOS: Reliable Autonomic Distributed Object Store, 거대한 데이터 호수)

📢 섹션 요약 비유: 사서를 없앴습니다. 대신 책 이름만 넣으면 서가 번호가 튀어나오는 '공식'을 모두에게 알려주었습니다. 1,000만 명이 동시에 들어와도 각자 속으로 계산하고 바로 자기 책을 찾아 흩어지므로 교통체증이 0입니다.

Ⅲ. 만능 스위스 아미 나이프 (Unified Storage)

Ceph가 오픈스택(OpenStack) 등 클라우드의 표준 스토리지가 된 결정적 이유는 이 녀석이 변신 로봇이기 때문입니다.

밑바닥(RADOS)은 철저한 '오브젝트 스토리지'이지만, 그 위에 껍데기를 어떻게 씌우냐에 따라 고객에게 3가지 얼굴로 서비스합니다.

  • Ceph 블록 디바이스 (RBD): 가상 머신의 C드라이브(블록)처럼 쓰게 해줍니다.
  • Ceph 오브젝트 게이트웨이 (RGW): AWS S3처럼 개발자용 웹 스토리지로 쓰게 해줍니다.
  • CephFS: 일반 윈도우/리눅스 공유 폴더(파일 스토리지)처럼 쓰게 해줍니다.

데이터센터 관리자는 비싸게 SAN, NAS, Object 스토리지를 따로 살 필요 없이, 값싼 x86 깡통 서버만 잔뜩 사서 Ceph 하나만 깔아두면 모든 스토리지 요구를 통일해서 방어할 수 있습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

  1. 시나리오 — 오픈스택 기반 프라이빗 클라우드의 스토리지 통합: 5,000대의裸 서버로構成되는私有クラウド에서, VM용块存储(RBD)、オブジェクト存储(RGW)、ファイル共有(CephFS)를 각각別々の-storage设备로采购하면導入費用이 数억원이 되고, 管理도複雑해진다. Ceph를Deploy하면, 5,000 HDD를 단일 RADOS集群으로統合し、상이한 인터페이스로동시에提供할 수 있어, 스토리지 구매 비용을 60% 절감하고 운영 인원을 40% 줄였다.

  2. 시나리오 — 온라인 게임服务器的 스토리지 아키텍처: 초당 100만 명의 사용자가 접속하는 MMORPG에서,玩家의 진행 상황(오브젝트)、로그 데이터(オブジェクト)、게임 리플레이(ファイル)를 각각 다른 스토리지 유형으로 保存해야 한다. Ceph의 unified storage를 使用하면, 所有数据类型을 single RADOS cluster에 저장하고, 필요한 만큼의副本(replica)을 配置하여, Region 별 지연시간을 20ms 이하로 유지하면서도 每年 스토리지 비용을 45% 절감했다.

  3. 시나리오 — 블루스크린 방지를 위한 Ceph의 자체 복구机制: 일반 스토리지 RAID controllerが故障했을 때, hot-spare가 合体质어换上 때까지業務が停止하지만, Ceph의 OSD가故障하면 CRUSH map根据 자동 재배치되고, 장애 노드의 데이터는 其他 OSD에 자동 복제된다. 이 과정이 全程自動化되어, 관리자의 개입 없이도 99.999% 이상의可用性을 달성한다.

도입 체크리스트

  • 기술적: Ceph의 OSD (Object Storage Daemon) 配置数量と 서버間 네트워크 대역폭의 관계를 분석. OSD당 处理 가능한OPS가 제한적이므로, 密集的なIOワークロード에서는 每台服务器的 OSD数を 조정하거나, NVMe OSD를 使用하여 성능을늘려야 한다.
  • 운영·보안적: CRUSH map의 rule을预先 设计하여, 同一部屋(server room)의 노드가 동시에 장애가 나는 상황에 대비. also, Ceph의默认副本수(replication size=3)가 네트워크故障로 全node障害時 数据 손실을 방지할 수 있는지 확인한다.

안티패턴

  • OSD 配置의 임의 설정: 每台服务器에 OSD数を 무작위로 설정하면, 클러스터의balanced가 깨지고 특정 노드에 I/O가集中하는 "소일人口" 현상이 발생한다. 每台服务器的 디스크 数을 기준으로 均一하게 OSD를 配置하고, Crush weight를 통해 균형을맞춰야 한다.
  • Cache tier 미설정 또는 과도한 설정: SSD cache tier를 설정하면 hot data의 처리량이 大幅 향상되지만, cache와 backing store간의 数据 movement가 잦으면 오히려 성능 저하가 발생할 수 있다. 워크로드의 hot/cold 데이터 비율을 分析하여 적절한 cache 크기를 설정해야 한다.

📢 섹션 요약 비유: Ceph는「自走り翻訳者のいない 다국어 통역 서비스」와 같다. 고객이 어떤 언어로 질문하든(블록/オブジェクト/ファイル),統一된翻译 аппарата(CRUSH)가 자동으로 올바른 처리반에 연결하고,故障시에도다른 通訳사가 즉시対応한다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

정량/정성 기대효과

구분기존 SAN + NAS + Object 별도 구축Ceph 통합개선 효과
도입 비용개별 스토리지 3종 × 수억원통합 Ceph 클러스터 구축60% 비용 절감
관리 복잡도3套 스토리지別々 관리단일 관리 인터페이스70% 관리 효율화
확장성각 스토리지 별도 스케일링RADOS 클러스터로 통합 스케일링無停止 확장 가능
복구 시간RAID 재구성 4~8시간OSD 자동 복제 + CRUSH 재배치80% 단축

미래 전망

  • Ceph와 Kubernetes의 긴밀한 통합: Rook (Ceph Operator)가 Kubernetes와紧密结合되어, StorageClass를 통한动态Provision이 可能해졌다. 将来的には、Cloud-Native 应用이 Kubernetes YAML만으로 Ceph 스토리지를 自动配置하고 管理하는世界가 될 것이다.
  • 纠删码(Erasure Coding)와 Sephos의 결합: 3副本(replication) 대신纠删码(예: 10+4)를 使用하면, 동일 내장애 수준에서 스토리지 효율을 3倍程度上 향상시킬 수 있다. 단,纠删码의 CPU 오버헤드가 크므로, 低전력 CPU(ARM)와의 조합이 차세대 Ceph의 핵심이 될 것이다.
  • Ceph Mon (Monitor)_cluster의 Quorum 자동화: 현재는 Monitor 노드의 failover 시手動介入이 필요한 경우가 있지만, 이를完全自動化하여, 5-node monitor cluster에서 2-node 장애时에도 자동 failover되어 99.9999% 가용성을 달성하는 것이 목표다.

참고 표준

  • RADOS (Reliable Autonomic Distributed Object Store): Ceph의根本をなす オブジェクト 스토리지 시스템으로, CRUSH算法で自律的に 데이터 배치와 복제를管理한다.
  • CRUSH (Controlled Replication Under Scalable Hashing): 중앙 메타데이터 서버 없이 数学公式로 데이터의 配置位置를 결정하는 Ceph만의 알고리즘이다.
  • RBD (Rados Block Device), CephFS, RGW (Rados Gateway): RADOS 위에 实现된 3가지 스토리지 接口로, 블록・ファイル・オブジェクト 스토리지로 각각 활용된다.

Ceph는 SDS(Software-Defined Storage)의 정석으로서, "中央集権的な管理者を不要とする"라는 设计理念을 实现했다. CRUSH算法の发明により、存储系统的管理者は「データをどのノードに配置するか」を意識する必要がなくなり、システム自体が 数据の 配置と복제を自律的に管理する. 이 设计은 21세기 대규모クラウドストレージの必須技術として、 مزيد의 발전을 기대하게 한다.

📢 섹션 요약 비유: Ceph의 CRUSH算法는「도서관의 所有 책에 대해 中央 카탈로그 없이도, 책 제목만 있으면 어느 서가에 있는지를 全家伙が 自己計算できる魔法の索引システム」と 같다. この索引があれば、天津的な 文献管理者が不要になり、 library 성장에따라 管理 부담도 증가하지 않는다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭관계 및 시너지 설명
RADOS (Reliable Autonomic Distributed Object Store)Ceph의底部オブジェクト 스토리지クラスタで、データの 配置・복제・回復を自律的に 수행한다.
CRUSH (Controlled Replication Under Scalable Hashing)中央 카탈로그 없이 算法만으로 데이터의 配置位置를 결정하는 Ceph 고유의 알고리즘이다.
OSD (Object Storage Daemon)Ceph 클러스터의 각 서버에서 실행되는 데몬으로, 실제 디스크에 객체 데이터를 저장하고 접근한다.
Mon (Monitor)Ceph 클러스터의 membership과 상태를 관리하는 모니터로, 클러스터 전체의 MAP情報を 유지한다.
Erasure CodingRAID와 similar하게 데이터를 분할して冗長データを追加保存하는 방식으로、스토리지 효율은 높지만 CPU 오버헤드가 크다.
Rook (Ceph Operator)Kubernetes에 Ceph를Deploy하기 위한 Operator로, YAMLrick으로 스토리지 프로비저닝을 자동화한다.

👶 어린이를 위한 3줄 비유 설명

  1. 옛날 도서관에서는司書님(마스터)이 "이 책은 3번 서가 2층에 있어"라고 다Externally 기억해서, 여러분이 책을 찾으려면 항상司書님께 물어봐야 했어요. 하지만ceph는 "책 제목에서 바로 서가를 알아내는 공식"을 우리 모두에게 알려줘서, 이제는司書님께 물어볼 필요가 없어요!
  2. 이 공식이 너무天才적이라、책이 100만 권으로 늘어나도同じ公式로 바로 서가를 찾을 수 있어요. 그래서 도서관이 커져도司書증的人员을 늘릴 필요가 없어요.
  3. 만약3번 서가가 고장나면(디스크 장애),公式就知道 automatically 다른 서가(다른 OSD)에서故障書の副本를 찾아와서 복사해 둘가요. 그래서 고장 나도 книги는 모두 안전해요!