SUMMARY
IDC 서버 약 30여 대가 서버 단위로 점유·방치되며 낭비되고 있었다. 이걸 “장비가 부족하다”가 아니라 “자원이 추적되지 않고 낭비된다”는 문제로 보고, 전수조사로 실물 자산을 파악한 뒤 노후 저사양 서버를 마스터·스토리지 노드로 재활용해 쿠버네티스 자원 풀로 묶었다. 이어 클라우드에서 상시 돌던 워크로드를 사내 클러스터로 역이전해 월 클라우드 비용을 줄였다.
이 글은 쿠버네티스가 필요했던 이유나 클러스터 구축 여정 같은 기술 도입기와는 결이 다르다. 그쪽이 “어떻게 만들었나”라면 이 글은 “왜 돈 들일 가치가 있다고 판단했고, 어떻게 설득해서 회수했나”에 대한 기록이다. 같은 프로젝트를 비용과 의사결정 쪽에서 다시 본 셈이다.
1. 현황
처음 인프라를 들여다봤을 때 눈에 들어온 건 서버가 부족하다는 게 아니었다. 오히려 반대였다. IDC에 서버가 약 30여 대 있었는데, 전부 개별 서버 단위로, 도커(Docker) 기반으로 돌고 있었다. 부서나 개인이 프로젝트·연구·개발 목적으로 서버를 하나씩 통째로 점유하는 형태였다.
문제는 그 점유가 “필요한 만큼”이 아니라 “서버 통째로”였다는 거다. 낭비가 여러 갈래로 샜다.
- 서버 단위로 잡아두니 실제 필요 리소스와 무관하게 자원이 놀았다. 사용량 모니터링은 아예 없었다.
- 자원이 필요하면 “지금 저 서버 누가 쓰세요?”를 부서마다 물어보고 다녀야 했다. 쥔 사람은 편한데 필요한 사람이 동냥하듯 도는 구조였다.
- 공용 계정으로 root를 쓰니 누가 뭘 올리고 내렸는지, 누가 서버를 죽였는지 추적이 안 됐다.
- disk pressure, fstab·grub 문제, 네트워크 다운이 터질 때마다 IDC로 직접 갔다. 포트포워딩·방화벽 허용 요청도 수시로 들어왔다.
- 특히 GPU는 비싸서 구매 결재가 까다로운데, 정작 놀고 있는 걸 보면 아까웠다.
그러니 “서버를 더 사자”로 풀 문제가 아니었다. 그러면 낭비는 그대로 둔 채 비용만 는다. 장비 부족이 아니라 추적성 부재 + 자원 낭비 + 운영 부하가 진짜 문제라고 보고 시작했다.
2. 실물 자산 전수조사
최적화 전에 뭐가 있는지부터 알아야 하는데, 그 “뭐가 있는지”조차 정리돼 있지 않았다. 그래서 IDC 서버를 하나씩 전수조사했다.
- 기본 사양(코어·메모리·디스크)
- 지금 어떤 서비스가 도는지
- 어느 부서가 어떤 사업과 엮여 쓰는지
- 폐기·존치 여부
조사 결과를 관리툴에 등록해 “어느 서버가 무슨 사양으로 뭘 하는지”를 한 곳에서 보게 만들었다. 화려한 단계는 아니지만 이후 모든 결정의 근거가 됐다.
막상 조사해보니 미사용 서버는 많지 않고 전반적으로 사양이 낮았다(램 64GB 이하, 8스레드 이하가 다수). OS도 Ubuntu 18.04가 대부분이라 노후했다. 이 사실이 계획을 바꿨다. 저사양 레거시를 옮기는 공수 대비 효과가 크지 않으니, 전부 갈아엎기보다 가용한 것부터 클러스터로 묶고 레거시는 두고두고 순차 이전하는 쪽이 현실적이었다.
3. 노후 서버를 마스터·스토리지 노드로 재활용
쿠버네티스는 역할별로 요구 사양이 다르다. 워커는 실제 워크로드를 받으니 자원이 필요하지만, 컨트롤플레인(마스터)은 상대적으로 가벼워도 된다. 그러면 좋은 서버를 굳이 마스터에 박아둘 이유가 없다. 이 점에 맞춰 배치했다.
- 가장 오래된 저사양 서버 3대: 메모리만 올려 마스터 노드로
- 코어·메모리가 작은 서버 3대: 케이스 교체하고 디스크 붙여 스토리지 노드로
- 나머지 가용 서버: 워커로
노후 서버는 OS를 Rocky 9로 정비하고(고객사에도 주로 Rocky로 납품해서 환경을 통일하는 편이 나았다) 디스크 배드섹터 검사와 정리를 거쳤다. 폐기 대상으로 보이던 장비도 최소 손질만으로 클러스터의 한 축을 맡게 됐다. 새 하드웨어를 지르는 대신 놀던 자산의 역할을 다시 정한 것이다.
클러스터링은 향후 노드 추가를 염두에 두고 Ansible(Kubespray)로 멱등성(Idempotency)을 지키며 구성했다. 이쪽 기술 결정은 도입기 시리즈에 따로 정리해뒀다.
NOTE
클러스터로 묶는 것만으로 낭비가 사라지진 않는다. 부서·프로젝트별로 네임스페이스(Namespace)를 나누고
ResourceQuota로 CPU·메모리·파드 수 총량을 제한해야 “서버 통째 점유”가 “필요한 만큼 할당”으로 바뀐다. 재편의 진짜 목적은 여기였다.
4. 클라우드 워크로드 역이전
자원 풀이 생기니 클라우드에서 돈 내고 돌리는 것 중 가져올 게 없나 싶었다. 온프레미스에서 클라우드로 가는 이야기는 흔한데 우리는 반대였다. 유휴 자원을 클러스터로 확보해두니, 클라우드에서 상시 돌던 워크로드를 사내로 도로 가져오는 역이전이 계산에 맞았다. 트래픽 특성상 클라우드의 탄력성이 굳이 필요 없고, 늘 켜둬야 해서 온프레미스 상시 가동이 더 싼 워크로드가 대상이었다.
그런 워크로드를 사내 클러스터로 옮겼고, 월 클라우드 비용을 1천만 원대 규모로 줄였다(정확한 액수는 구성에 따라 다르니 근사치로 적는다). 새 장비를 산 게 아니라 놀던 자산을 재편해 만든 자리라, 추가 투자 없이 회수한 셈이다.
대신 클라우드의 탄력적 확장이나 관리형 서비스의 편의는 포기해야 한다. 그래서 전부가 아니라 “상시 가동 + 탄력성이 덜 필요한” 워크로드로만 대상을 한정했다. 이 경계를 긋는 게 사실 제일 신경 쓴 부분이다.
5. 경영진 설득
기술보다 어려운 건 결재를 받아내는 쪽이었다. 하드웨어 재배치와 워크로드 이전은 일시적으로 리스크를 지는 일이라, 경영진 입장에선 “왜 지금, 왜 이 비용을”이 당연한 질문이었다.
그래서 보고서를 여러 번 썼다. 감이 아니라 전수조사에서 나온 실제 데이터를 근거로 삼았다. 낭비되는 자원 규모, 서버 점유로 생기는 커뮤니케이션·운영 부하, 역이전으로 회수할 클라우드 비용을 숫자로 냈다. 여기에 앞으로 있을 K8s 관련 사업·공고에 대비한 기술 자산 확보라는 명분도 얹었다. 단순 절감을 넘어 “지금 투자하면 뒤에 이런 것도 된다”는 그림까지 보여줘야 설득이 됐다.
클러스터를 세운 것보다, 세워도 된다는 판단을 만들어내는 데 시간이 더 걸렸다.
남은 이야기
기술 스택 선정과 구축 디테일(CNI·CSI 선택, BGP 연동, 관측가능성 스택 등)은 별도 시리즈로 정리해뒀다.
- 쿠버네티스가 필요했던 이유 — 같은 문제를 “왜 K8s인가” 각도에서 본 글
- 사내 쿠버네티스 클러스터 도입기 — 4개월간의 구축 여정 인덱스