Nutanix · Hybrid Cloud · Observability · DR
Nutanix 환경을 중심으로 클라우드 가시성 확보와 디지털 운영 회복력을 실무 관점에서 정리했습니다
2026년 6월, 약 15분 소요, Nutanix HCI · eBPF · MST · IaC · RTO/RPO
금요일 저녁 퇴근 30분 전, 슬랙 채널이 붉게 물들기 시작합니다. 처음엔 한두 개 알람이었는데 어느새 수십 개. 급하게 Prism 대시보드를 열어보지만, 온프레미스 클러스터와 AWS, Azure가 얽힌 환경에서 어디가 진짜 원인인지 금방 파악이 안 됩니다. CPU 사용률은 정상, 메모리도 이상 없음. 그런데 서비스 응답이 느립니다. 이런 상황이 낯설지 않다면, 가시성 문제가 있는 겁니다.
모니터링을 하는데도 원인을 못 찾는 이유
이 상황의 본질은 도구가 없어서가 아닙니다. 지표는 충분히 수집되고 있는데 그것들이 서로 연결되어 있지 않아서입니다. CPU 사용률은 보이지만 어떤 시스템 콜이 병목을 만드는지는 안 보이고, 네트워크 트래픽은 보이지만 어떤 VM 간 통신이 문제인지는 알 수 없습니다. 하이브리드 멀티클라우드 환경이 일반화될수록 가시성의 사각지대는 오히려 더 넓어집니다.
기존 모니터링의 한계도 여기서 드러납니다. 사전에 정해둔 임계치를 넘으면 알람을 보내는 구조는, 연쇄 장애를 잡지 못합니다. 스토리지 I/O 지연이 누적되어 애플리케이션 타임아웃이 발생하고, 그게 다시 재시도 트래픽을 유발해 네트워크 병목으로 번지는 식의 문제에서는 각 지표를 따로 보면 다 정상 범위 안에 있습니다. 연결해서 봐야만 보입니다.
이래서 '모니터링'과 '관측성(Observability)'의 차이가 중요해졌습니다. 모니터링이 "무엇이 실패했는가"를 알려준다면, 관측성은 "왜 실패했는가"를 추적할 수 있는 구조입니다. 메트릭, 로그, 트레이스가 실시간으로 연결되어야 진짜 가시성입니다.
Nutanix가 NCM(Nutanix Cloud Manager) 2.x에서 강조하는 방향도 여기 있습니다. 정적인 대시보드 리포팅을 넘어 커스텀 메트릭과 고해상도 텔레메트리 데이터를 직접 정의하고 시각화할 수 있게 됐습니다. 50개 이상의 내장 지표, 인벤토리 브라우저, Signals 기능이 추가됐고, 최대 10,000개 활성 VM 워크로드를 5개 Worker VM 폼팩터로 관리하면서 단일 VM 장애에도 관리 평면이 무너지지 않는 결함 허용 구조를 갖췄습니다. 금융이나 공공 부문처럼 운영 중단이 허용되지 않는 환경에서는 이 부분이 생각보다 큰 차이를 만듭니다.
서드파티 APM 도구와의 통합도 실무에서 자주 씁니다. Datadog 연동을 예로 들면, 에이전트 하나로 Prism Central이 관리하는 모든 클러스터·호스트·VM의 CPU, 메모리, 스토리지 I/O 지연을 초 단위로 수집할 수 있습니다. 단순 메트릭 수집을 넘어 Prism Central의 운영 이벤트, 감사 로그, 알람 정보가 Datadog 플랫폼으로 직접 스트리밍되기 때문에, 애플리케이션 응답 지연이 코드 문제인지 Nutanix 스토리지 컨트롤러 I/O 경합 때문인지를 단일 뷰에서 연관 분석할 수 있습니다. Dynatrace는 AHV 하이퍼바이저 전용 엔티티 모델을 기반으로 가상화 하위 계층부터 프론트엔드까지 장애 원인을 추적하는 뷰를 제공합니다.
eBPF: 커널 레벨까지 내려가는 이유
가시성 확보 기술 중에서 최근 가장 주목받고 있는 게 eBPF(extended Berkeley Packet Filter)입니다. 복잡한 기술인데, 실무 관점에서 핵심만 정리하면 이렇습니다.
기존에는 마이크로서비스 환경에서 컨테이너 트래픽을 모니터링하려면 각 Pod마다 사이드카(Sidecar) 프록시를 붙여야 했습니다. 수천 개 컨테이너 환경에서 이건 CPU·메모리 낭비가 상당하고, 레이턴시도 추가됩니다. eBPF는 이 구조를 바꿉니다. 애플리케이션 코드를 건드리지 않고 커널 내부에서 시스템 콜, 네트워크 이벤트, 패킷을 직접 추적합니다. 성능 부하는 1~2% 미만이면서 훨씬 정밀한 데이터를 뽑아낼 수 있습니다.
실무에서 특히 유용한 건 네트워크 레벨 가시성입니다. TCP 핸드셰이크 지연으로 특정 연결이 느린 건지, 패킷 재전송이 발생해 간헐적 타임아웃이 생기는 건지, DNS 조회 실패로 서비스 디스커버리가 깨진 건지를 커널에서 직접 포착합니다. 재현이 어려운 간헐적 장애의 원인을 Wireshark 같은 전통적 패킷 캡처 없이도 잡아낼 수 있습니다.
보안 관점에서도 달라집니다. 전통적인 CSPM 도구들은 클라우드 API 로그나 IAM 활동 기록에 의존하다 보니 공격이 일어나고 한참 뒤에야 로그가 남는 구조였습니다. eBPF는 커널 이벤트를 직접 검사하므로 비정상적인 권한 상승, 컨테이너 네임스페이스 탈출 시도, 알려지지 않은 취약 라이브러리 함수 호출을 거의 실시간으로 잡아낼 수 있습니다. Falco, Tetragon, KubeArmor 같은 런타임 보안 솔루션들이 모두 eBPF 기반인 이유가 여기 있습니다. eBPF와 LSM(Linux Security Modules)이 결합되면 탐지를 넘어 커널 레벨에서 불법 명령을 즉각 차단하는 방어까지 가능해집니다.
실무 팁 — Prism Syslog 연동
Prism의 Syslog 포워딩 기능을 활용해 eBPF 에이전트가 수집한 데이터를 사내 SIEM이나 중앙 로그 서버로 통합하면, 보안 위협과 성능 저하의 상관관계를 한 화면에서 볼 수 있습니다. 현재 Prism Central(pc.2024.3 기준)에서 Syslog 서버는 단일 대상만 지정할 수 있으니, 설계 단계에서 고성능 로그 집계기를 앞단에 배치하는 구조를 먼저 잡는 게 좋습니다. UDP 대신 RELP 기반 TCP 전송을 쓰면 패킷 정합성도 보장됩니다.
Prism의 Syslog 포워딩 기능을 활용해 eBPF 에이전트가 수집한 데이터를 사내 SIEM이나 중앙 로그 서버로 통합하면, 보안 위협과 성능 저하의 상관관계를 한 화면에서 볼 수 있습니다. 현재 Prism Central(pc.2024.3 기준)에서 Syslog 서버는 단일 대상만 지정할 수 있으니, 설계 단계에서 고성능 로그 집계기를 앞단에 배치하는 구조를 먼저 잡는 게 좋습니다. UDP 대신 RELP 기반 TCP 전송을 쓰면 패킷 정합성도 보장됩니다.
RTO와 RPO: 숫자 뒤에 있는 비즈니스 질문
운영 회복력을 이야기할 때 RTO와 RPO는 항상 등장하는 개념인데, 실무에서는 조금 다르게 접근하는 게 유용합니다.
RPO(Recovery Point Objective)는 단순히 "몇 시간 백업 주기"가 아닙니다. "1시간 전 백업으로 복구할 때 결제 트랜잭션 몇 건이 유실되는가, 그리고 그게 비즈니스적으로 감당 가능한가"라는 질문입니다. RTO(Recovery Time Objective)는 "복구에 몇 시간이 걸리는가"가 아니라 "핵심 결제 시스템이 2시간 멈추면 비즈니스 손실이 얼마인가, 그 손실을 줄이기 위해 인프라에 얼마를 투자할 수 있는가"의 문제입니다.
이 두 지표를 비즈니스 영향 평가(BIA)와 연결해서 생각하면 DR 전략이 명확해집니다. 실시간 결제 시스템처럼 15분 RTO, 거의 0에 수렴하는 RPO가 필요한 워크로드가 있는가 하면, 내부 정산 시스템처럼 24시간 RTO·4시간 RPO로도 충분한 워크로드가 있습니다. 모든 시스템에 동일한 수준의 보호를 적용하는 건 비용 낭비입니다.
랜섬웨어 상황에서는 다릅니다.
랜섬웨어 공격 시에는 하드웨어는 멀쩡한데 파일이 암호화됩니다. 감염되지 않은 복구 지점을 찾아 과거로 계속 되돌려야 하기 때문에, RPO를 얼마나 촘촘하게 잡느냐가 복구 가능성을 직접 결정합니다. 물리적 재해 대비 DR과는 설계 기준이 다릅니다.
랜섬웨어 공격 시에는 하드웨어는 멀쩡한데 파일이 암호화됩니다. 감염되지 않은 복구 지점을 찾아 과거로 계속 되돌려야 하기 때문에, RPO를 얼마나 촘촘하게 잡느냐가 복구 가능성을 직접 결정합니다. 물리적 재해 대비 DR과는 설계 기준이 다릅니다.
MST: DR을 하드웨어 구매에서 클라우드 소비로
전통적인 DR 구성의 가장 큰 문제는 비용 구조입니다. 원격지에 주 데이터센터와 비슷한 규모의 하드웨어를 상시 대기 상태로 유지해야 한다는 것, 평소엔 아무것도 안 하는 장비에 계속 돈을 써야 한다는 겁니다.
Nutanix의 MST(Multicloud Snapshot Technology)는 이 구조를 바꿉니다. 온프레미스 AHV 클러스터의 VM과 볼륨 그룹 스냅샷을 AWS S3나 Azure Blob 같은 오브젝트 스토리지로 주기적으로 복제합니다. 비싼 블록 스토리지 DR 사이트 대신, 기가바이트당 과금되는 저렴한 클라우드 스토리지에 복구 지점을 쌓아두는 방식입니다. 최대 300TB 규모의 보호 환경을 지원하고, 실제 재해가 발생하거나 복구 훈련을 돌릴 때만 NC2(Nutanix Cloud Clusters) 노드를 동적으로 프로비저닝해서 데이터를 재수화(Rehydrate)합니다.
배포 모델 선택이 실무에서 중요합니다.
Zero Compute 모델
비용 최적화
평시 클라우드 자원
없음 (S3 스냅샷만)
RPO
1시간 주기 비동기
RTO
수 시간 (수동 복구)
적합 워크로드
Tier 3/4 (개발, 정산)
Pilot Light 모델
빠른 복구
평시 클라우드 자원
최소 노드 상시 대기
RPO
1~15분 NearSync
RTO
수 분 (자동 페일오버)
적합 워크로드
Tier 1/2 (결제, 인증)
실제 설계에서는 보통 이 둘을 섞습니다. 핵심 결제나 인증 시스템에는 Pilot Light, 내부 협업 도구나 개발 인프라에는 Zero Compute를 적용하는 식입니다. Prism Central 7.5.1과 함께 배포된 Instant Restore 기능은 이 회복 시나리오의 응답성을 한층 끌어올려 줍니다.
IaC로 복구 절차를 코드에 굳혀두기
DR 구성이 아무리 잘 돼 있어도, 막상 장애가 났을 때 복구 절차를 매뉴얼 보면서 수동으로 따라가야 한다면 대응 속도가 나오지 않습니다.
IaC(Infrastructure as Code)를 사용하면 Nutanix 환경 전체(VM 구성, 네트워크 설정, 스토리지 정책)를 Terraform 코드로 정의하고 Git으로 버전 관리할 수 있습니다. 재해 상황에서 관리자는 감염된 환경에서 수동으로 복구 스크립트를 타이핑하는 대신, 사전에 구문 검증과 보안 스캔이 완료된 코드로 지리적으로 격리된 안전한 클라우드 리전에 인프라를 즉각 프로비저닝할 수 있습니다.
부수적인 효과도 있습니다. 모든 변경 사항이 Git 커밋 로그로 남기 때문에 DORA 같은 규제가 요구하는 감사 추적이 자동으로 충족됩니다. 담당자가 바뀌거나 조직 개편이 있어도 운영 노하우가 코드에 남아 있습니다. GitOps 워크플로우와 결합하면 구성 오류(Configuration Drift)도 원천 차단됩니다.
MST와 IaC를 함께 쓰면 흐름은 이렇습니다. 평소에는 MST가 온프레미스 스냅샷을 S3로 주기적으로 복제하고, Pilot Light 클러스터가 클라우드에서 최소한의 불씨를 유지합니다. 재해가 발생하면 Terraform 코드가 트리거되어 클라우드 리소스를 프로비저닝하고, MST 스냅샷에서 데이터를 복원해 서비스를 재개합니다. 이 시퀀스가 자동화되어 있으면 RTO를 수 시간에서 수십 분 수준으로 줄이는 게 현실적으로 가능해집니다.
Flow Network Security와 마이크로 세그멘테이션
가시성과 회복력의 마지막 퍼즐은 보안입니다. 랜섬웨어나 APT 공격이 성공하는 전형적인 패턴은 하나의 VM을 뚫은 뒤 내부 네트워크를 수평으로 이동하며 피해를 키우는 방식입니다.
Nutanix의 FNS(Flow Network Security)는 이 수평적 이동(Lateral Movement)을 막는 데 초점이 맞춰져 있습니다. VM과 애플리케이션 카테고리 단위로 세분화된 방화벽 정책을 부여하는 마이크로 세그멘테이션 기능을 기본 제공합니다. 감염된 VM이 인접한 중요 VM이나 관리망으로 확산하려 할 때, 하이퍼바이저 내장 네트워크 계층에서 이를 차단합니다.
복잡한 마이크로 세그멘테이션 룰셋이 적용될 때 발생하는 패킷 검사 연산 부하는 NVIDIA BlueField DPU 같은 스마트 닉으로 오프로딩하는 구조를 활용하면, 보안 정책을 넓게 적용하면서도 애플리케이션 성능 저하를 피할 수 있습니다.
오늘 우리 환경을 점검해보려면
마지막으로 현재 상태를 스스로 점검해볼 수 있는 질문들을 남깁니다.
지금 모니터링 도구가 메트릭, 로그, 트레이스를 연결해서 보여주고 있는가, 아니면 각각 따로 수집하고 있는가?
NCM 또는 Datadog·Dynatrace 같은 통합 관측성 플랫폼을 통해 Nutanix 인프라 레이어와 애플리케이션 레이어를 같은 화면에서 보고 있는가?
DR 목표(RTO/RPO)가 비즈니스 영향 평가(BIA)와 연결되어 워크로드별로 차등 적용되고 있는가?
복구 절차가 매뉴얼로만 존재하는가, 아니면 IaC 코드로 자동화되어 있는가?
MST를 쓰고 있다면, Zero Compute와 Pilot Light 중 어떤 모델이 우리 워크로드 특성에 맞는지 검토해봤는가?
FNS 마이크로 세그멘테이션 정책을 설정한 뒤 최근 리뷰를 한 적이 있는가?
인프라는 절대로 망가지지 않도록 만들 수 없습니다. 하지만 망가졌을 때 얼마나 빠르고 예측 가능하게 복구할 수 있는지는 설계 단계에서 결정됩니다. 위의 질문들에 자신 있게 답할 수 있다면, 금요일 저녁 알람도 조금은 다른 마음으로 받을 수 있을 겁니다.
Subscribe to 'BLOGGER'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'BLOGGER'!
Join Slashpage and subscribe to 'BLOGGER'!
Subscribe
