오늘날의 IT 팀은 많은 과제를 안고 있습니다. 비정형 데이터는 매년 35%씩 증가하고 있지만, 이러한 데이터를 담당하는 IT 팀의 인력, 예산, 데이터 센터는 줄어들고 있습니다(데이터 센터가 실제로 줄어들고 있지는 않지만 더 커지고 있지는 않습니다). 이 글은 엔터프라이즈 전략가, 관리자, 관리자가 워크로드를 클라우드로 이전할 때 고려해야 할 과제와 기회, 그리고 장단점을 살펴보는 시리즈 글 중 네 번째 글입니다.
이전 게시물에서는 기업이 클라우드 서비스 통합 여부와 방법을 결정할 때 고려해야 할 몇 가지 공통 요소를 살펴봤습니다. 또한 다양한 전략의 장단점과 이를 서로 비교하여 기업에 가장 적합한 경로를 결정하는 방법도 다루었습니다.
다음 몇 개의 시리즈 게시물에서는 위험을 관리(및 최소화)하는 방법의 맥락에서 클라우드로 데이터를 마이그레이션하는 몇 가지 일반적인 전략을 분석해 보겠습니다.
시작하기 전에 어떤 기업은 본질적으로 다른 기업보다 위험에 더 잘 견디며, 비즈니스에서 허용 가능한 위험과 허용할 수 없는 위험을 결정해야 한다는 점을 알아두는 것이 중요합니다.
이는 비즈니스의 특성 및 관련 요인(예: 규제 기한 또는 보호해야 하는 개인 보호 정보(PPI)가 있는지 여부)에 따라 영향을 받습니다. 경우에 따라서는 규제 기한을 지키지 못하거나 PPI가 유출될 경우 그 결과가 매우 심각할 수 있습니다.
보험 회사가 실수로 HIPAA 법률을 위반했다고 상상해 보세요. 그 여파는 재정적 벌금, 민사적 처벌, 부정적인 여론, 심지어 형사 처벌까지 이어질 수 있습니다. 금융, 의료, 보험 및 기타 규제가 엄격한 비즈니스는 클라우드 마이그레이션에 따른 시스템, 소프트웨어 및 아키텍처 변경과 관련하여 위험에 대한 허용 범위가 훨씬 더 낮습니다.
클라우드 컴퓨팅과 스토리지의 전망은 많은 기업 시스템 관리자에게 미래를 위한 비즈니스의 혁신을 지원해야 한다는 압박과 현재의 비즈니스를 유지하기 위해 기존 서비스와 워크플로우를 온라인 상태로 유지해야 한다는 압박이라는 흥미로운 수수께끼를 안겨줍니다.
성공적인 클라우드 도입 전략에는 성장과 혁신을 가져오는 새로운 플랫폼과 기술을 도입하기 위해 계산된 위험을 감수하는 동시에 조명을 켜고 비즈니스를 계속 운영하는 신중한 균형이 필요합니다.
비현실적인 전략
무엇을 해야 하는지 살펴보기 전에, 무엇을 해야 하는지 이야기해 보겠습니다 not 해야 합니다. 그 중 첫 번째는 비즈니스를 운영하는 데 필요한 앱과 관련하여 불필요한 위험을 감수하지 않는 것입니다.
대규모 애플리케이션 리팩토링
많은 조직은 최소한 중요한 파일 기반 워크로드를 클라우드 네이티브 아키텍처로 리팩토링하는 것을 고려할 것입니다. 여기에는 파일 데이터가 아닌 객체 스토리지를 활용하도록 애플리케이션을 재작성하는 작업이 수반됩니다. 이 접근 방식에는 클라우드 운영의 유연성 향상, AWS 및 Azure에서 제공되는 일부 공급자별 클라우드 네이티브 서비스와의 긴밀한 통합 등 장기적인 이점이 있는 것은 사실이지만 몇 가지 중요한 단점도 염두에 두어야 합니다.
이 전략은 초기 비용이 많이 듭니다. 앱의 크기와 복잡성에 따라 앱 하나를 다시 작성하는 데 300만~3,000만 달러의 전환 비용이 발생할 수 있습니다.
앱 하나에 3,000만 달러가 넘는 금액입니다. 물론 성공한다는 가정 하에 말이죠.
대규모 실패의 위험이 매우 높을 뿐만 아니라 최악의 경우 문제를 진단하고 수정하는 동안 전체 비즈니스가 중단될 수도 있습니다. 프로젝트가 완료되는 데 2년 이상 걸리는 동안 조직이 얼마나 많은 실패를 감내할 수 있을까요?
맥락에서 위험 인식하기
위의 시나리오가 실제로 허용 가능한 위험으로 간주될 수 있는 합법적인 상황도 있습니다. 다음과 같은 상황을 고려해 보세요:
비즈니스에 중요하고 파일에 의존적인 앱 중 하나를 새로운 공급업체에서 구매했는데, 해당 공급업체가 특정 날짜부터 단계적으로 지원을 중단한다고 발표했다고 상상해 보세요. 갑자기 다음과 같은 일을 해야 하는 상황에 처하게 됩니다 무언가 실패와 비즈니스 중단으로 이어질 수 있습니다.
조직에서 공급업체가 다음 버전이 클라우드 네이티브가 될 것이라고 발표한 타사 앱에 의존하고 있을 수도 있습니다." 이러한 발표에 대해 여러분과 조직이 어떻게 생각하든 위험은 존재하며, 이를 피하려고 하기보다는 최소화하고 완화하는 것은 여러분의 책임입니다.
일부 대규모 비즈니스 혁신은 클라우드로의 이전 위험을 상쇄할 수도 있습니다. 대규모 리브랜딩을 진행 중이거나 비즈니스 모델을 전환하는 경우, a) 이미 다른 실패의 위험이 높지만 b) 클라우드로 이전함으로써 기존에 온프레미스에 보관되어 있던 일부 데이터를 복구할 수 있습니다.
이러한 경우에는 클라우드 마이그레이션이 감수할 수 있는 위험보다 더 큰 외부 요인이 충분히 존재합니다.
Y2K 버그를 기억하실 만큼 나이가 많으신 분들은 미션 크리티컬한 레거시 앱을 재설계, 마이그레이션 또는 교체하는 조치를 취하는 것보다 아무것도 하지 않는 것이 더 위험했던 '수용 가능한 위험'의 방정식을 바꾸는 외부 요인의 완벽한 예를 알고 계실 것입니다.
물론 위의 시나리오가 대부분의 사용자에게 적용되지는 않을 것입니다. 비즈니스 크리티컬 앱을 리팩토링할 때 많은 조직은 낮은 성공 가능성과 높은 실패 비용을 비교하여 앱을 그대로 두고 클라우드가 따라잡을 때까지 기다리는 것이 더 합리적이라고 결론을 내립니다.
무리한 사용
클라우드로의 모든 여정에서 비현실적인 또 다른 전략은 너무 빨리 이동하려는 것입니다. 애플리케이션을 망가뜨릴 뿐만 아니라 온프레미스 배포로 되돌아가거나 클라우드에서 앞으로 수정할 수 있을 때까지 발만 동동 구르게 될 것입니다.
속도를 늦추고 필요한 시간을 들여 애플리케이션을 철저히 평가하고 테스트하지 않으면 마이그레이션 후 지연 시간 문제, 데이터 오류, 처리량 부족 문제가 발생할 위험이 있습니다. 이러한 문제가 특정 임계값을 초과하면 전체 마이그레이션 실패로 이어질 수 있습니다. 온프레미스에서 클라우드로 원활하게 전환하는 데 필요한 시간과 노력을 기울이면 이러한 오류가 발생할 위험이 크게 줄어듭니다.
그렇다면 워크로드를 클라우드로 이전하기 위한 현실적인 전략은 무엇일까요? 다음 편에서 어떤 접근 방식을 권장하는지 확인해 보세요.