우리는 3개월 만에 프로덕션 시스템을 Azure VM에서 Bare Metal Kubernetes로 이전했습니다

발행: 7시간 전 (2026년 4월 5일 AM 12:02 GMT+9)

6 분 소요

원문: Dev.to

Source: Dev.to

Overview

우리는 약 3개월에 걸쳐 Azure VM에서 베어메탈 Kubernetes로 프로덕션 시스템을 마이그레이션했습니다. 복잡한 솔루션을 구축하기보다 신중한 계획과 실행에 초점을 두었습니다.

Infrastructure: 여러 Azure VM, 자체 관리 MySQL 인스턴스, 로드 밸런서.
Configuration: 완전 수동 방식 – 인프라 코드, 컨테이너, 오케스트레이션이 전혀 없음.
Pain points:
- 부하가 걸릴 때 데이터베이스 락 및 쿼리 지연.
- 일부 머신에서는 CPU 스파이크가 발생하고 다른 머신은 활용도가 낮음.
- 깨끗한 스케일링이나 부하 재분배가 불가능.
- 트래픽 피크 시 예측 불가능한 동작; 요청이 조용히 실패하고 큐가 쌓임.
- 거의 이득이 없는 추상화 레이어 때문에 높은 비용 발생.

목표는 다운타임 없이 예측 가능하고 안정적인 환경을 만드는 것이었습니다. 우리는 Kubernetes를 실행하는 4대의 베어메탈 서버를 선택하고 잘 알려진 컴포넌트를 사용했습니다:

모든 프로비저닝 및 설정은 Terraform과 Ansible으로 관리하여 레거시 설정에서 발생한 수동 실수를 반복하지 않도록 했습니다.

Database replication
- Kubernetes에 새로운 MySQL 인스턴스를 배포했습니다.
- 기존 Azure 데이터베이스와 복제하도록 설정해 두 시스템을 동기화 상태로 유지했습니다.
Read traffic shift
- 데이터 일관성이 확인되면 읽기 쿼리를 새로운 데이터베이스로 전환했습니다.
- 이를 통해 쓰기 위험 없이 실제 트래픽 테스트가 가능했습니다.
Write traffic shift
- 읽기 테스트가 성공적으로 끝난 뒤, 쓰기 작업을 새로운 데이터베이스로 전환했습니다.
- 짧은 기간 동안 기존 데이터베이스를 안전망으로 유지했습니다.
Application cutover
- 애플리케이션 컴포넌트를 점진적으로 Kubernetes 클러스터로 이동했습니다.
- 외부 사용자에게는 전환이 매끄럽게 이루어졌으며, 변경된 것은 내부 인프라뿐이었습니다.

통합된 은행이 기존 IP 주소만 화이트리스트에 등록해 두었습니다. 새로운 베어메탈 IP가 문서화되지 않아 결제 실패가 조용히 발생했으며, 은행에 새로운 IP를 제공함으로써 신속히 해결되었습니다.

Responsibility: 전원, 네트워크, 하드웨어 장애, 물리적 접근을 직접 관리해야 합니다. 실패한 부품을 조용히 교체해 주는 제공자가 없습니다.
Fit: 트래픽이 예측 가능하고 일관된 성능이 중요하며 클라우드 비용이 소유 비용을 초과할 때 베어메탈이 정당화됩니다.
General recommendation: 대부분의 기업에게는 클라우드가 운영 위험을 낮추고 제품 개발에 집중할 수 있게 해 주므로 여전히 더 나은 선택입니다. 베어메탈은 사례별로 평가해야 합니다.