온프레미스 Kubernetes 스토리지 설계: 같은 서비스라도 규모가 커지면 기준이 바뀐다

Table of contents

1. 글의 배경

이 글은 고객사 온프레미스 환경에, 원래 SaaS로 운영하던 여러 컴포넌트를 하나의 Kubernetes 클러스터 위로 옮겨 설치하면서 겪었던 스토리지 설계 경험을 정리한 것이다.

클러스터 위에는 서비스뿐 아니라 DB, 오브젝트 스토리지, 그리고 각종 운영 데이터가 함께 올라갔다. 그래서 스토리지 설계는 특정 워크로드 하나의 볼륨 문제가 아니라, 이 시스템 전체를 하나의 클러스터 안에서 어떻게 안정적으로 운영할 것인가의 문제였다.

클라우드에서는 스토리지 증설이 비교적 간단하다. 볼륨 크기를 늘리거나 옵션을 바꾸면 끝나는 경우가 많다. 하지만 온프레미스는 다르다. 용량을 늘린다는 말 뒤에는 실제로 어떤 노드에 어떤 디스크를 붙일지, 디스크 장애는 어떻게 대비할지, 네트워크 대역폭은 충분한지 같은 물리적, 운영적 판단이 필요하다.

내가 경험한 기준점은 3노드 환경과 7노드 환경이었다. 사용 규모가 작은 환경은 3노드로, 큰 환경은 7노드로 구성했다. 이 둘은 서로 다른 서비스를 비교한 사례가 아니다. 같은 SaaS 서비스를 온프레미스에 옮겼지만, 사용 규모가 달라지면서 필요한 인프라 구조와 운영 방식도 함께 달라졌다.

2. 3노드에서는 RAID1 기반 노드 로컬 구성이 합리적이었다

3노드 환경에서는 노드 스토리지를 비교적 단순하게 나눌 수 있었다.

• OS 영역
• Data 영역

Data 영역은 hostPath 기반 스토리지 클래스와 함께, 컨테이너 이미지, 파드 임시 스토리지, 운영 데이터를 함께 저장했다. 그리고 디스크 장애에 대비하기 위해, 각 노드의 Data 영역은 RAID1으로 미러링했다.

여기서 RAID1의 역할은 분명했다. 이 구성은 클러스터 차원의 스토리지 추상화를 제공하기 위한 것이 아니라, 개별 디스크 장애가 곧바로 운영 중단으로 이어지지 않도록, 디스크를 교체할 시간을 벌기 위한 구성였다.

예를 들어 노드당 실사용 1TB를 확보하려면 물리 디스크 2개가 필요하다. 3노드라면 총 6개의 디스크가 필요하고, 각 노드는 자체 미러링을 가진 상태로 독립적으로 운영된다.

이 방식이 합리적이었던 이유는, 이 환경에서 중요한 상태 저장 컴포넌트들이 이미 상위 계층에서 복제와 장애 대응 구조를 갖고 있었기 때문이다. 즉, DB나 오브젝트 스토리지가 이미 서비스 수준의 고가용성을 담당하고 있었고, 스토리지 계층은 그 아래에서 디스크 장애만 막아주는 역할이면 충분했다.

정리하면 3노드 환경에서는 다음과 같은 역할 분리가 가능했다.

• 상위 상태 저장 컴포넌트가 서비스 수준의 복제와 장애 대응을 담당하고
• 스토리지 계층은 RAID1으로 디스크 장애만 방어한다

이 구조에서는 굳이 Ceph 같은 클러스터 단위 스토리지를 도입할 필요가 크지 않았다. 단순한 구조만으로도 요구사항을 만족할 수 있었고, Ceph 도입 시 설치, 업그레이드, 장애 복구, 네트워크 요구사항 같은 운영 부담이 이점보다 컸기 때문이다.

물론 3노드라고 해서 용량 확장이 쉬웠던 것은 아니다. RAID1 기반 노드 로컬 스토리지는 이 환경에서도 결국 노드 단위 재구성이 필요했다. 다만 노드 수가 적어 재구성 대상이 적었고, 그 제약이 전체 설계 방향을 바꿔야 할 수준은 아니었다.

3. 규모가 커지자 노드 단위 관리가 병목이 되었다

규모가 커진 환경에서도 디스크를 추가하거나 교체해서 노드당 용량을 늘리는 것 자체는 가능했다. 하지만 늘린 용량이 여전히 노드 안에 묶여 있다는 점이 문제였다.

노드 로컬 중심 구조에서는 각 노드의 여유 공간이 클러스터 전체 자원으로 보이지 않는다. 예를 들어 어떤 노드는 여유 공간이 충분하고, 어떤 노드는 부족할 수 있다. 하지만 필요한 워크로드가 특정 노드에 붙어 있거나, 특정 노드에서만 실행 가능한 워크로드라면, 클러스터 전체로 보면 공간이 남아 있어도 실제 운영에서는 부족한 상태가 된다.

결국 배치 가능한 용량이 실제 병목이 된다.

이 구조에서는 다음과 같은 제약이 커진다.

• 특정 데이터가 어느 노드에 붙어 있는지가 점점 더 중요해진다
• 파드 배치와 이동이 스토리지 위치에 의해 제약된다
• 노드 유지보수나 드레인 시 고려할 조건이 많아진다
• 장애 복구와 재스케줄링이 더 까다로워진다

3노드에서는 배치 판단이 거의 필요 없었다. HA 구성의 최소 단위가 보통 3대이기 때문에, 어디에 무엇을 둘지 고민할 여지 자체가 적었다. 하지만 7노드가 되면서 상황이 달라졌다. 노드별 용도를 나누고, 어떤 워크로드를 어느 노드에 배치할지를 직접 설계해야 했다. 노드가 늘어난 만큼 이런 판단도 함께 늘어났고, 그 자체가 운영 부담이 되었다.

RAID1 증설은 기존 RAID 멤버 교체와 리빌드, LVM 확장까지 포함하는 노드 단위 재구성 작업이다.

기존 방식을 그대로 유지하면, 7노드에서도 노드당 실사용 1TB를 확보하려면 RAID1 기준 디스크 2개씩이 필요하다. 3노드에서 총 6개였던 디스크는 7노드에서 14개가 된다. 구매량은 늘어나지만, 그 자원은 여전히 노드별로 흩어져 있을 뿐이다.

문제는 “디스크를 더 붙일 수 있느냐”가 아니라, 늘어난 용량을 노드 단위로 관리할 것인가, 클러스터 단위 자원으로 다룰 것인가였다.

Ceph 같은 클러스터 단위 스토리지는 각 노드의 디스크를 하나의 전체 용량 풀처럼 다룰 수 있게 해준다. 물론 복제 정책 때문에 실사용 용량은 줄어든다. 하지만 중요한 차이는 남는다. RAID1이 노드 안에서 용량과 장애 대비를 함께 묶는 방식이라면, Ceph는 용량 관리와 디스크 장애 대비를 클러스터 전체에서 정책으로 처리한다.

4. Ceph로 가면 디스크 장애에 대비하는 방식도 달라진다

기존 노드 로컬 구성에서는 각 노드 안에서 RAID1으로 디스크를 미러링했다. 즉, 디스크 장애 대비는 노드 내부에서 이루어졌다.

Ceph 같은 클러스터 단위 스토리지로 전환하면 이 구조가 바뀐다. 개별 디스크는 Ceph OSD로 편입되고, 디스크 장애 대비는 더 이상 노드 내부 RAID가 아니라, 클러스터 전체의 복제 정책과 배치 정책으로 처리된다.

RAID1이 사라져도 디스크 장애 대비가 사라지는 것은 아니다. 대비의 주체가 노드 내부 RAID에서 클러스터 복제 정책으로 바뀌는 것이다.

5. Ceph를 도입하면 노드 스토리지 구조도 다시 설계해야 한다

Ceph 도입은 노드 스토리지 설계 자체를 다시 나눠야 하는 작업이었다.

3노드 환경에서는 OS + Data의 2영역이면 충분했다. Data 영역 안에서 hostPath 스토리지 클래스, 컨테이너 이미지, 파드 임시 스토리지, 로그를 함께 저장할 수 있었다.

하지만 7노드 환경에서 Ceph를 도입하면 구조가 달라진다.

• OS 영역
• Data 영역
• Ceph 영역

즉, OS + Data + Ceph의 3영역 구조가 된다.

여기서 중요한 점은, Ceph가 클러스터 차원의 영구 저장소를 담당하더라도 컨테이너 이미지나 파드의 임시 스토리지까지 대신해 주지는 않는다는 것이다. 로컬 Data 영역은 여전히 필요하고, 거기에 더해 Ceph용 디스크를 별도로 확보해야 한다.

노드에서 어떤 데이터를 어떤 영역이 책임질 것인지부터 다시 구분해야 한다.

결국 Ceph 도입은 노드 스토리지 레이아웃을 포함한 전체 인프라 설계 변경이다.

6. 이런 전환은 네트워크 설계까지 바꾼다

Ceph가 모든 문제를 해결해 주는 것은 아니다. 오히려 병목의 위치를 바꾼다.

노드 로컬 스토리지에서는 디스크와 노드 단위 제약이 더 직접적인 문제였다면, 클러스터 단위 스토리지에서는 노드 간 통신 품질과 네트워크 대역폭이 성능과 안정성에 더 직접적으로 영향을 준다.

클러스터 단위 스토리지를 쓰는 순간, 네트워크도 그에 맞는 대역폭을 갖춰야 한다.

그래서 Ceph는 10G 이상 네트워크를 전제 조건으로 요구한다.

실제로 10G 네트워크를 전제로 설계했지만, 현장에서는 스위치 포트 부족 때문에 일부 구간을 1G로 운영해야 했던 적이 있었다. 이 차이는 곧바로 스토리지 성능 문제로 드러났고, 결국 추가 네트워크 장비를 다시 들여와야 했다. 특히 장애 이후 복제본 재구성이나 재동기화가 시작되면, 네트워크 대역폭 부족은 저장소 성능과 복구 시간 모두에 영향을 준다.

Ceph를 도입하기 전에 네트워크 기반이 충분한지도 확인해야 했다.

7. 운영의 단위도 함께 바뀐다

규모가 커질 때 바뀌는 것은 용량만이 아니다. 운영의 단위도 함께 바뀐다.

노드 로컬 중심 구조에서는 노드 수가 늘어날수록 운영자가 계속 노드별 상태를 의식해야 한다.

• 어느 노드에 여유 공간이 있는지
• 어떤 데이터가 어느 노드에 붙어 있는지
• 유지보수 시 어떤 워크로드가 영향을 받는지
• 노드 드레인이나 장애 복구 시 어떤 제약이 생기는지

즉, 운영의 중심이 개별 노드와 그 안의 RAID 상태에 머문다.

반면 Ceph 같은 클러스터 단위 스토리지로 가면 이런 제약 일부는 줄어든다. 대신 운영의 중심이 다른 곳으로 이동한다.

• 클러스터 저장소의 건강 상태
• 복제 상태
• 리밸런싱
• 장애 후 복구 속도
• 네트워크와 저장소의 전체적인 안정성

즉, 운영이 쉬워지는 것이 아니라 운영의 대상이 바뀌는 것이다.

노드 로컬 방식은 단순하지만, 규모가 커질수록 사람이 직접 노드별 제약을 관리해야 한다. 클러스터 스토리지 방식은 그 제약을 완화하지만, 대신 클러스터 저장소 자체를 운영할 역량과 기반을 요구한다.

결국 노드별 제약을 사람이 직접 관리할 것인가, 클러스터 스토리지의 운영 복잡도를 선택할 것인가의 판단이다.

8. 정리

3노드와 7노드라는 숫자 자체가 절대적인 기준은 아니다. 어떤 환경에서는 3노드에서도 클러스터 단위 스토리지가 필요할 수 있고, 반대로 더 큰 규모에서도 노드 로컬 구성이 충분할 수 있다.

중요한 것은 다음과 같은 조건이 어느 시점부터 운영 문제로 드러나기 시작하느냐다.

• 노드별 용량 편차가 실제 배치 문제를 만드는가
• 워크로드가 특정 노드에 강하게 종속되는가
• 유지보수와 드레인 과정에서 스토리지가 운영 제약으로 작동하는가
• 증설이 계속 노드별 재구성 작업으로 반복되는가
• 스토리지를 클러스터 자원으로 다루는 편이 더 현실적인가

내가 경험한 3노드와 7노드의 차이는, 바로 이 기준이 달라지는 지점이었다.

현재 규모와 운영 조건에서, 스토리지를 어떤 단위로 관리하는 것이 더 현실적인가. 내가 경험한 변화도 결국 그 판단이었다. 처음에는 노드 단위로 처리하던 문제들이, 규모가 커지면서 노드 하나로는 해결할 수 없게 되었다. 그때부터 스토리지는 디스크의 문제가 아니라, 클러스터 전체를 어떻게 운영할 것인가의 문제가 되었다.