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 관련 사업·공고에 대비한 기술 자산 확보라는 명분도 더했다. 단순 절감을 넘어 “지금 투자하면 뒤에 이런 것도 가능하다”는 전망까지 보여주어야 설득이 되었다.
클러스터를 세운 것보다, 세워도 된다는 판단을 만들어내는 데 시간이 더 걸렸다.
6. 한계
기술 스택 선정과 구축 디테일(CNI·CSI 선택, BGP 연동, 관측가능성 스택 등)은 별도 시리즈로 정리해뒀다.
- 쿠버네티스가 필요했던 이유 — 같은 문제를 “왜 K8s인가” 각도에서 본 글
- 사내 쿠버네티스 클러스터 도입기 — 4개월간의 구축 여정 인덱스