파일 데이터를 클라우드 스토리지로 마이그레이션할 때 중요한 고려 사항

 “첫째, 해를 끼치 지 마십시오” - 히포크라테스

오늘날 IT 팀은 해야 할 일이 많습니다. 비정형 데이터가 연간 35%씩 증가하고 있지만, 해당 데이터를 담당하는 IT 팀의 인력, 예산, 데이터 센터는 줄어들고 있습니다(해당 데이터 센터는 실제로 줄어들지는 않을 수도 있지만 더 커지지는 않을 것입니다). 이는 워크로드를 클라우드로 이동할 때 엔터프라이즈 전략가, 관리자 및 관리자가 고민해야 하는 과제와 기회는 물론 장점과 단점을 평가하는 일련의 게시물 중 네 번째입니다.

이전 게시물에서는 기업이 클라우드 서비스 통합 여부와 방법을 결정할 때 고려해야 하는 몇 가지 공통 요소를 살펴보았습니다. 또한 다양한 전략의 장단점을 다루었고, 이를 서로 비교하여 기업이 앞으로 나아갈 최선의 길을 결정하는 방법도 다루었습니다.

시리즈의 다음 몇 게시물에서는 위험을 관리(및 최소화)하는 방법의 맥락에서 데이터를 클라우드로 마이그레이션하기 위한 몇 가지 일반적인 전략을 분석하겠습니다. 

시작하기 전에 일부 기업은 본질적으로 다른 기업에 비해 위험에 대한 내성이 더 높다는 점을 염두에 두는 것이 중요합니다. 따라서 기업에서 허용할 수 있는 위험과 허용할 수 없는 위험이 무엇인지 판단해야 합니다. 

이는 비즈니스의 성격과 관련 요인(예: 규제 기한 또는 보호해야 하는 개인 보호 정보(PPI))이 있는지 여부에 따라 영향을 받습니다. 어떤 경우에는 규제 기한을 지키지 않거나 PPI 유출로 인한 결과가 엄청납니다. 

실수로 HIPAA 법률을 위반한 보험 회사를 상상해 보십시오. 후속 효과에는 금전적 처벌, 민사 처벌, 부정적인 평판, 심지어 형사 처벌까지 포함될 수 있습니다. 금융, 의료, 보험 및 기타 규제가 심한 기업은 클라우드 마이그레이션과 마찬가지로 시스템, 소프트웨어 및 아키텍처 변경과 관련된 위험에 대한 허용 범위가 훨씬 낮습니다. 

클라우드 컴퓨팅 및 스토리지의 전망은 많은 엔터프라이즈 시스템 관리자에게 흥미로운 난제를 제시합니다. 즉, 미래를 위한 혁신을 위한 비즈니스 요구 사항을 지원해야 하는 경쟁적 압력과 현재 비즈니스를 유지하기 위해 기존 서비스 및 워크플로를 온라인 상태로 유지해야 한다는 필요성입니다. 

성공적인 클라우드 채택 전략에는 신중한 균형이 필요합니다. 계산된 위험을 감수하여 성장과 혁신을 제공하는 새로운 플랫폼과 기술을 채택하는 동시에 가동 상태를 유지하고 비즈니스를 운영하는 것입니다.

비현실적인 전략

무엇을 해야할지 살펴보기 전에 무엇을 해야할지 이야기 해 봅시다. 지원 할 것. 그 중 첫 번째는 비즈니스를 계속 운영하는 앱에 있어서 불필요한 위험을 감수하지 마세요.

대규모 애플리케이션 리팩터링

많은 조직에서는 적어도 중요한 파일 기반 워크로드를 클라우드 네이티브 아키텍처로 리팩터링하는 것을 고려할 것입니다. 이를 위해서는 파일 데이터가 아닌 객체 스토리지를 활용하도록 애플리케이션을 다시 작성해야 합니다. 이 접근 방식에는 클라우드 운영의 유연성 향상, AWS 및 Azure에서 사용할 수 있는 일부 공급자별 클라우드 네이티브 서비스와의 긴밀한 통합 등 몇 가지 장기적인 이점이 있다는 것은 인정되지만 명심해야 할 몇 가지 중요한 단점이 있습니다. 또한. 

이 전략의 초기 비용은 높습니다. 크기와 복잡성에 따라 단일 앱을 다시 작성하는 데 3만~30천만 달러의 전환 비용이 발생할 수 있습니다. 

맞습니다. 하나의 앱에 30천만 달러 이상이 듭니다. 그리고 그것은 성공한다고 가정합니다.

단점은 대규모 오류의 위험이 매우 높을 뿐만 아니라 최악의 경우 문제가 진단되고 수정되는 동안 전체 비즈니스가 중단될 수 있다는 점입니다. 이는 단지 하나의 실패일 뿐입니다. 프로젝트를 완료하는 데 2년 이상 걸릴 수 있는 실패 중 얼마나 많은 것을 조직에서 견딜 수 있습니까? 

상황에 따른 위험 인식

위의 시나리오가 실제로 허용 가능한 위험으로 간주될 수 있는 합법적인 상황이 있습니다. 다음을 고려하세요:

비즈니스에 중요한 파일 종속 앱 중 하나를 새로운 공급업체가 구입했는데, 이 앱이 특정 날짜부터 단계적으로 폐지되고 더 이상 지원되지 않을 것이라고 발표했습니다. 갑자기 당신은 해야 할 상황에 놓이게 되었습니다. 무언가, 이는 모두 실패 및 비즈니스 중단으로 끝날 수 있습니다. 

어쩌면 귀하의 조직은 공급업체가 다음 버전이 클라우드 기반이 될 것이라고 발표한 타사 앱에 의존할 수도 있습니다.” 귀하와 귀하의 조직이 해당 발표에 대해 어떻게 생각하든 관계없이 위험은 존재하며 위험을 피하려고 하기보다는 최소화하고 완화하는 것은 귀하의 몫입니다.  

일부 대규모 비즈니스 혁신을 통해 클라우드로의 전환 위험을 상쇄할 수도 있습니다. 대규모 브랜드 변경 또는 비즈니스 모델 전환을 진행 중인 경우 a) 이미 다른 실패의 위험이 높지만 b) 클라우드로 이동하여 지금까지 온프레미스에 보관되었던 이전 데이터 중 일부를 복구할 수 있습니다. 

이러한 경우에는 클라우드 마이그레이션이 허용 가능한 위험으로 간주되는지 여부보다 더 중요한 외부 요인이 충분합니다. 

Y2K 버그를 기억할 만큼 나이가 많은 여러분은 "허용 가능한 위험" 방정식을 변경하는 외부 요인의 완벽한 예를 갖고 있습니다. 즉, 아무것도 하지 않는 위험이 임무를 재설계, 마이그레이션 또는 교체하는 조치를 취하는 것보다 더 높았습니다. -중요한 레거시 앱.

물론 위의 시나리오는 대부분의 사용자에게 적용되지 않을 것입니다. 비즈니스에 중요한 앱을 리팩터링할 때 많은 조직은 높은 실패 비용과 낮은 성공 가능성을 비교하여 앱을 그대로 두고 클라우드가 따라올 때까지 기다리는 것이 더 합리적이라는 결론을 내립니다. 위로.

그것을 과장

클라우드로의 여정에서 또 다른 비현실적인 전략은 너무 빨리 움직이려고 하는 것입니다. 애플리케이션이 중단될 뿐만 아니라 온프레미스 배포로 되돌리거나 클라우드에서 수정할 수 있을 때까지 물속에 빠져 있을 것입니다. 

속도를 늦추지 않고 애플리케이션을 철저하게 평가하고 테스트하는 데 필요한 시간을 투자한다면 마이그레이션 후 대기 시간 문제, 데이터 오류 및 처리량 부족이 발생할 위험이 있습니다. 특정 임계값을 초과하면 전체 마이그레이션이 실패할 수 있습니다. 온프레미스에서 클라우드로 원활하게 전환하는 데 필요한 시간과 노력을 투자하면 이러한 오류가 발생할 위험이 크게 줄어듭니다.  

그렇다면 워크로드를 클라우드로 이동하기 위한 현실적인 전략은 무엇입니까? 어떤 접근 방식을 권장하는지 알아보려면 다음 회차를 계속 지켜봐 주시기 바랍니다.