클라우드 마이그레이션 이점을 정량화하고 검증하는 방법

엔터프라이즈 비즈니스의 미래가 클라우드에 있다는 것은 이미 알고 있는 결론입니다. 클라우드 마이그레이션이 지난 몇 년 동안 엔터프라이즈 영역에서 얼마나 큰 역할을 수행했는지 고려할 때 특히 그렇습니다.

클라우드 컴퓨팅에 대한 지출은 2009년 이후 IT 지출의 4.5배 증가했으며 2020년까지 6배 이상 증가할 것으로 예상됩니다.

Forbes 클라우드 컴퓨팅 요약

이는 Oracle의 최신 데이터에 의해 뒷받침됩니다. Oracle의 2019년 두 번째 예측은 "미션 크리티컬"로 간주되는 워크로드를 포함하여 모든 엔터프라이즈 워크로드의 80%가 향후 12개월 동안 클라우드로 이동할 것이라는 것이었습니다.

기업 전반에 걸쳐 클라우드가 거의 보편화되고 IT 전문가와 일반인 모두에게 클라우드 기술에 대한 친숙도가 증가하고 있음에도 불구하고 워크플로를 클라우드로 이동하는 것은 쉬운 일이 아닙니다. 마이그레이션이 완료되면 기대치를 관리하고 비용이나 성능과 관련하여 실제로 개선 사항을 제공할 때 특히 그렇습니다.

팀이 지킬 수 없는 약속을 하지 않도록 하려면 클라우드 마이그레이션의 모든 단계에서 가시성이 필요합니다. 결국 "측정할 수 없는 것은 관리할 수 없으며 " 오래된 만트라가 통용되므로 IT 팀은 전체 벤처가 탈선하기 전에 정확한 기대치를 설정하고 문제를 미리 파악하기 위해 마이그레이션의 모든 단계에서 가시성을 확보해야 합니다.

허용되는 성능 목표 정의

우선 팀은 어떤 애플리케이션, 네트워크 인프라 또는 프로세스가 가장 자주 고장나는지 완전히 이해해야 합니다. IT 부서는 정보를 얻고 조직 전체의 동의를 얻기 위해 부서 간 인터뷰를 해야 할 것입니다.

IT가 일반론의 관점에서 생각할 때 클라우드 마이그레이션의 사례를 만드는 것은 쉬울 수 있습니다. 물론, 네트워크 하드웨어의 유지 관리 부담을 덜어주는 것은 예산에 민감한 의사 결정권자에게 매력적으로 보일 것입니다. 하지만 기업에서 이러한 절감 효과를 거두려면 얼마나 많은 선행 투자가 필요할까요?

비용만으로는 모든 의사 결정자를 유인하기에 충분하지 않을 수도 있습니다. 클라우드 마이그레이션이 비즈니스 크리티컬로 간주되는 여러 앱의 성능을 향상시킨다면 다른 곳에서 사용되는 도구의 비용이 발생합니까? 마이그레이션 전반에 걸쳐 앱 성능이 영향을 받습니까? 얼마나 오랫동안? 사용자를 위한 새로운 교육이 필요합니까?

팀은 마이그레이션 제안을 경영진에게 가져오기 전에 이러한 모든 질문을 파악해야 합니다. 이를 위해 IT는 기존 성능의 기준선을 만들기 위해 네트워크의 현재 상태를 심각하게 반영해야 합니다. 이러한 방식으로 팀은 개선이 가장 필요한 부분에 대한 의사 결정자의 의견을 확인하거나 알리고 클라우드 컨텍스트에 솔루션을 배치할 수 있습니다.

마이그레이션 전 성능 기준 설정

최종 사용자 경험은 이 모든 것이 시작되는 곳입니다. 클라우드 마이그레이션 후 직원의 최종 사용자 경험이 개선되지 않거나 실제로 눈에 띄게 악화된다면 IT는 성공하지 못할 것입니다. 열악한 사용자 경험이 더 큰 비즈니스의 성과에 도미노 효과를 줄 수 있기 때문에 수익에만 집중하는 의사 결정권자라도 동의할 것입니다. 따라서 IT는 아키텍처가 뿌리 뽑히기 전에 네트워크의 "현재 상태"(사용자 만족도 포함)에 집중해야 합니다.

애플리케이션의 경우 전체 전달 경로에 대한 명확한 가시성과 함께 사용자가 작업 위치에서 실제로 경험하고 있는 것에 대한 IT 로컬 관점을 제공하는 종합 웹 테스트가 필요합니다. 이 정보를 통해 IT는 및 이후 동안 충족해야 하는 "수락 기준"을 설정할 수 있습니다. 사용자가 만족할 수 있도록 클라우드 마이그레이션. 일부 샘플 기준은 다음과 같습니다.

<울>

응답 시간은 마이그레이션 전 수준의 5% 이내여야 합니다.

서비스 오류율은 마이그레이션 전 수준과 같거나 낮아야 합니다.

애플리케이션 가용성은 마이그레이션 전 수준과 같거나 낮아야 합니다.

인프라 비용은 마이그레이션 과정에서 최소 X% 감소해야 합니다.

따라서 팀은 현재 사용자에게 앱이 얼마나 빨리 제공되고 있는지, 서버 간 대기 시간(내부 및 외부, DNS 등), 오류율, 오류 유형 및 브라우저별 성능 문제에 대한 펄스 확인을 받아야 합니다. 이 모든 데이터가 있어야만 IT가 네트워크 사전 마이그레이션 상태를 파악할 수 있습니다.

마이그레이션 전반에 걸쳐 계속 모니터링

팀에서 기준선을 설정한 후에는 마이그레이션 프로세스 전반에 걸쳐 수락 기준을 계속 모니터링하는 것이 중요합니다. 팀은 네트워크가 기준을 충족하지 않을 때 플래그를 지정할 수 있는 대시보드 및 경고를 생성할 수 있어야 합니다. 이상적으로는 모니터링 솔루션이 아닌 경우 기준 성능에 대해 참조한 동일한 메트릭을 사용하는 것이 좋습니다.

<울>

가동시간 - 클라우드 애플리케이션의 경우 IT는 다운타임이 주어진 주 동안 몇 분으로 제한될 것으로 예상해야 합니다. 대부분의 공개 앱은 99.9% 이상(영업일 기준 최대 7분)을 위해 노력합니다.

DNS - 현재 클라우드에 있는 앱의 경우 IT는 IP 주소를 제공하는 로컬 DNS 서버 또는 공용 DNS 서비스를 가질 것입니다. 이는 특정 위치의 모든 사용자에 대한 연결을 방지하므로 적극적으로 모니터링해야 합니다.

지연 시간, RTT - 이제 서비스가 데이터 센터 외부 또는 사무실 외부에 있으므로 트래픽이 클라이언트에서 서버로 이동하는 데 걸리는 시간에 의미 있는 차이가 있을 수 있습니다. 여기서 급증하는 것은 LAN, ISP 또는 앱 문제와 관련이 있을 수 있습니다.

용량 - ISP로부터 대역폭 비용을 지불하는 것은 한 가지이지만 사용자 위치와 앱 서버 간의 네트워크 종단 간 용량은 다른 병목 현상을 가질 가능성이 높습니다. 이 측정을 통해 IT는 정체가 연결 속도에 영향을 미치는 시기를 식별할 수 있습니다.

급증 및 점프는 문제가 확산되기 전에 중지하기 위해 새로운 비즈니스 요청이 있기 전에도 즉시 해결해야 하는 마이그레이션 관련 버그의 유용한 지표입니다. 문제를 해결함으로써 IT 팀의 시선이 문제에 직접 집중되므로 팀에서 가장 적절한 솔루션을 구현할 가능성이 높아집니다.

모니터링을 활용하여 성공 여부 확인

새로운 네트워크 아키텍처가 배치되면 마이그레이션 전에 팀이 수행한 기준선을 다시 비교하여 비교해야 합니다. 여기서 핵심은 기존 네트워크에서 테스트한 것과 동일한 프로세스(사용, 패턴, 시간 등)를 사용하는 것입니다.

모든 클라우드 마이그레이션에는 손실되는 제어 수준이 있습니다. 베어 메탈, OS 또는 액세스 수준에 관계없이 팀이 새로운 클라우드 지원 네트워크에 대해 동일한 수준의 가시성을 제공할 수 있는 최신 모니터링 솔루션을 사용하는 것도 중요합니다. 인프라가 더 이상 IT 소유가 아닌 경우 이전 모니터링 도구의 가시성 수준이 손상됩니다. 많은 모니터링 솔루션이 클라우드 환경이나 IT 방화벽 외부에 대한 가시성을 제공할 수 없기 때문에 이는 매우 중요합니다.

방화벽 너머의 통찰력 없이는 IT가 ISP 또는 타사 인프라에서 발생하는 문제를 식별하고 신속하게 해결하기 어렵습니다. 이렇게 하면 진행 중인 마이그레이션이 지연되고 성능이 지속적으로 방해를 받는 경우 IT 외부의 사용자가 클라우드 이전 시대를 그리워할 수 있습니다.