대시보드, 마이그레이션 성공을 알렸다

출처: Dev.to

마이그레이션 대시보드는 운영 연속성을 측정하지 않는다. 왜냐하면 운영 연속성은 마이그레이션 계약에 처음부터 포함되지 않았기 때문이다. 이는 도구에 대한 비판이 아니라, 마이그레이션 프로젝트가 어떻게 범위가 정해지고, 계약되고, 실행되는지를 설명하는 것이다. 그리고 대시보드는 초록색이 되지만, 실제 운영에서는 전혀 다른 사실이 드러나는 이유이기도 하다.

대시보드는 정확했다. 설계된 대로 측정했기 때문이다. 미리 정의된 범위에 대한 작업 완료 상황을 측정했다: 이동된 VM, 재시작된 서비스, 검증된 연결성, 통과한 건강 체크. 하지만 — 측정할 수 없었고 — 측정하지 못한 것은 전환 후 환경이 이전 환경과 운영적으로 연속되는가 하는 점이다.

마이그레이션 도구는 마이그레이션 작업에만 초점을 맞춘다. 마이그레이션 프로젝트는 특정 VM, 서비스, 워크로드 집합에 대한 작업 완료를 성공으로 정의한다. 도구는 그 범위를 추적한다: 워크로드가 이동했는가, 재시작했는가, 새로운 플랫폼에서 건강 체크에 응답하는가. 모든 작업이 완료되고 모든 체크가 통과하면 대시보드는 초록색이 된다. 마이그레이션 경계 안에서는 이것이 정확하고 완전한 평가이다.

문제는 마이그레이션 경계가 제외한 부분에 있다. 마이그레이션 작업이 아닌 모든 것은 범위 밖이며, 따라서 측정 대상에서도 제외된다. 예를 들어 기존 환경에 연결된 백업 작업, 특정 스토리지 토폴로지를 전제로 한 DR 오케스트레이션, 소스 플랫폼에 등록된 모니터링 에이전트, 이제는 한 네트워크 홉 더 멀리 있는 아이덴티티 제공자에 의존하던 인증서 신뢰 체인 등이다. 이들은 모두 마이그레이션 작업이 아니므로 대시보드에 나타나지 않는다.

마이그레이션 계약은 무엇이 이동하는지를 정의한다. 운영 환경은 이동한 것보다 훨씬 크다.

마이그레이션 후 가장 먼저 깨지는 것은 대개 범위에 포함된 워크로드가 아니다. 신중히 마이그레이션되고 테스트·검증된 VM은 기대대로 동작한다. 문제가 되는 것은 그 주변의 운영 레이어다 — 예를 들어 더 이상 존재하지 않는 하이퍼바이저에서 VSS 정지를 전제로 했던 백업 정책, 다른 I/O 특성을 가진 스토리지에 기반한 성능 기준, 마이그레이션 중 재구성됐지만 문서화되지 않은 특정 장애 복구 경로를 전제로 한 런북 등이다.

범위 경계 착시 (Scope Boundary Illusion)

마이그레이션 도구 범위 밖에 있는 모든 것은 운영적으로 보이지 않게 된다. 설사 그것이 프로덕션에 필수적이라 하더라도 말이다. 대시보드는 마이그레이션을 측정하고, 프로덕션은 연속성을 측정한다. 두 측정은 같은 경계가 아니다.

01 — 아이덴티티 연속성: Kerberos 티켓, 인증서 신뢰 체인, 시간 동기화, 서비스 주체 매핑. 이들은 즉시 실패하지 않는다. 티켓이 만료되거나, 인증서 갱신이 잘못된 권한에 대해 이루어지거나, 시계 오차가 임계값을 초과할 때 비로소 문제가 발생한다.

02 — 운영 의존성 재연결: 백업 에이전트, 모니터링 훅, DR 오케스트레이션 등록, CMDB 항목. 마이그레이션 작업이 아니라 마이그레이션 이후에 수행되는 운영 위생 작업이다. 실제로는 종종 연기되거나, 부분적으로만 완료되거나, 워크로드와 함께 이동했다고 가정한다. 하지만 실제로는 이동하지 않았다.

03 — 잠재적 성능 저하: 큐 깊이 동작, 스토리지 지연 프로파일, 동서 트래픽 패턴. 워크로드는 검증 단계에서 정상적으로 동작한다. 그러나 검증이 성능 엔벨로프가 소스 플랫폼에서 설정한 것과 일치하는지를 드러내지는 못한다. 실제로는 성능 저하가 존재하지만 검증 창에서는 임계값 이하이기 때문에 눈에 띄지 않는다.

04 — 인간의 복구 준비도: 운영팀이 새로운 환경에서 장애를 진단하고 복구할 수 있는가? 소스 플랫폼용으로 작성된 런북, 더 이상 적용되지 않는 도구에 대한 근육 기억 등은 측정하기 가장 어렵고, 가장 큰 영향을 미친다.

마이그레이션 도구 공급업체는 작업 완료를 측정하도록 인센티브가 맞춰져 있다. 작업 완료는 객관적으로 보고할 수 있기 때문이다. 이동된 VM 하나, 재시작된 서비스 하나, 통과한 건강 체크 하나 — 이것은 숫자이며, 백분율이며, 대시보드상의 초록색 상태이다.

운영 연속성은 환경마다 다르고, 조직마다 의존성이 다르며, 자동화하기 어렵다. 백업 팀이 작업 대상지를 업데이트했는가? 모니터링 팀이 에이전트를 재등록했는가? 전환 후 첫 번째 인시던트에 대응하는 온콜 엔지니어가 새로운 플랫폼에 맞는 런북을 가지고 있는가? 이러한 요소들은 마이그레이션 공급업체가 측정·보고·보장할 수 있는 것이 아니다.

Uptime Institute의 인프라 분석에 따르면 현재 장애의 60% 이상이 최소 10만 달러 이상의 손실을 초래한다. 대부분은 마이그레이션 대시보드가 이미 초록색이 된 뒤에 드러난다. 이것이 마이그레이션 대시보드 실패의 구조적 원인이다: 대시보드는 자신의 범위 내에서는 정확하지만, 그 범위에 프로덕션이 의존하는 모든 것이 포함되지 않는다.

대시보드가 초록색을 보여 마이그레이션이 성공했다고 판단한 것은 대시보드가 오직 마이그레이션만을 측정했기 때문이다. 프로덕션은 연속성을 다른 방식으로 측정한다.

범위 경계 착시는 구조적이며 우연이 아니다. 마이그레이션 도구는 마이그레이션이 만든 결과물—이동된 워크로드, 통과한 건강 체크, 검증된 연결성—만을 측정한다. 운영 연속성을 위해 필요한 것—백업 인프라 재연결, 모니터링 재등록, 복구 절차 검증, 소스 환경과 일치하는 성능 기준—은 측정하지 않는다.

전환 후 검증을 담당하는 팀은 대시보드 초록색을 프로젝트의 결승선이 아니라, 운영 검증의 출발점으로 삼는 것이 가장 현명하다.

원문은 rack2cloud.com에 최초 게시되었습니다.