이 문서에서는 AWS의 기본 블록스토리지인 EBS 대신 Ceph를 운영했을 때의 장단점을 분석한다. IDC 온프레미스 환경에선 EBS 같은 블록스토리지 서비스가 없으므로 Ceph 운영을 더 적극적으로 고민해볼만 하다.
비용
i3(en) 인스턴스 타입 위에 ceph를 운영해 블럭 스토리지를 직접 운영한다면 대략 다음과 같이 비용을 추산한다.
이 비용 구조의 주요 변수는 RI 할인률이다. 할인률에 따라 스토리지 운영 비용이 영향을 크게 받는다. 그래도 편의상 위의 조건을 받아들인다면 ceph를 운영해 스토리지 비용을 20% 정도 절감할 수 있다. 스토리지가 48TB라면 한화로 매월 150만원, 연간 1792만원을 절감한다. 작다고 볼 수도 있지만 스토리지가 10배쯤 많다면 절감액도 연간 1억 8천만원 정도가 된다. 규모가 큰 조직일수록 자체 운영을 정당화하기 쉽다.
IOPS를 많이 요구할수록 자체 운영이 비용효율적일 수 있다. 대체로 ceph가 EBS보다 random read에서 많이 앞서기 때문이다. Rook에서 제시한 벤치마크 사례에선 gp2보다 빠른 ip1과 비교했음에도 random read는 2배가량 빠르다. 대신 write는 최악의 경우 io1 타입의 75% 수준이긴 하다. 그러나 gp2와 비교하면 여전히 우위에 있거나 비슷한 수준일 것이다.
기타 장점
자체 운영시 비용 외의 추가 장점이 딸려온다. 우선 K8s에서 Statefulset을 운영하기 쉽다. EBS는 볼륨 detach와 attach가 느리기로 악명 높지만 ceph는 그런 문제가 없다. 그러므로 statefulset의 배포가 수월해진다. Kafka 브로커 한 대가 충돌이 났을 때 복구되는 속도가 월등하고 사람이 개입해 force-detach해야 하는 상황을 겪지 않아도 된다. 다시 말해 장애가 날 확률이 줄고 장애가 나더라도 빠르게 복구될 가능성이 높다.
앞선 비용 분석에선 ceph의 redundancy를 최소로 잡았다. EBS처럼 Multi AZ Failover가 안 되는 단순 구성을 취해 비용을 최소화했다. 재해복구(Disaster Recovery) 요구사항이 엄격한 조직이라면 ceph가 Failover를 지원하게 구성해도 된다. Redundancy를 2배 확보하면 비용도 2배가 되긴 한다. 하지만 특정 AZ가 무너졌을 때 그 AZ에만 데이터가 있어서 서비스 복구가 안 되는 상황을 맞이하고 싶은 사람은 없을 것이다.
단점
단점은 설명이 필요하나 싶을 정도로 분명하다. 스토리지 규모가 작은 조직에서는 비용 이점이 거의 없고 운영 비용만 증가한다.
그리고 스토리지 운영 책임을 스스로 져야 한다.
어쩌면 좀더 싼 Object Storage (AWS S3)를 더 활용하거나 IOPS 사용현황을 정확히 파악해 HDD 타입을 적극 활용하여 비용을 줄이는 편이 쉬울지 모른다. 단 블럭킹 IO에 의존하는 애플리케이션이 많으면 IO latency의 증가가 전체 컴퓨팅 리소스 활용 효율을 극적으로 끌어내릴 가능성이 있다.
마지막으로 Kubernetes 점검 시간이 길어진다. K8s의 메이저 업그레이드 등의 사유로 전체 클러스터를 내렸다 올릴 때가 있다. 각 노드가 뜨고 Pod가 작동하기 시작하면 서비스를 재개할 것인데 ceph에 대한 의존성이 있으면 그만큼 점검시간이 길어진다. ceph를 K8s 클러스터 밖에서 운영하면 의존성 이슈가 덜하나 그대신 i3(en) 컴퓨팅 리소스를 활용하지 못하므로 총 비용이 증가한다.
참고
- Run your own high performance EBS wherever Kubernetes runs
- Why We Chose Ceph to Build Block Storage
- Why Is Storage On Kubernetes So Hard? – Software Engineering Daily
- Storage on Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | has_many :codes
