2019.04.24

IDG 블로그 | 워크로드 마이그레이션 예측이 잘못되는 이유

David Linthicum | InfoWorld
어떤 워크로드나 애플리케이션이라도 퍼블릭 클라우드로 이전하는 데는 짧게는 하루, 길게는 두 달이 걸린다. 기간을 예측하는 것은 상당히 힘들어서 소수의 컨설팅 업체와 퍼블릭 클라우드 서비스 업체, 그리고 필자와 같은 관련 전문가들은 실제로 비용이 얼마나 들지 시간이 얼마나 걸릴지 몇 퍼센트 정도만 성공적으로 모델링할 수 있다고 생각한다.
 
ⓒGettyImagesBank

괜찮은 생각이다. 현실에는 쉽게 모델링할 수 없는 나쁜 애플리케이션이나 데이터 아키텍처가 제법 많기 때문이다.

필자가 클라우드로 이전한 애플리케이션 워크로드와 데이터 세트의 대부분은 위원회에서 설계한 것처럼 보였다. 몇몇 경우는 실제로 그랬다. 확장이 안되거나 데이터베이스를 제대로 활용하지 못했으며, 데이터베이스는 너무 엉망으로 설계해 제대로 인덱싱도 안되고 애플리케이션 자체와 너무 밀접하게 연결되어 있었다.

클라우드 마이그레이션에는 올바른 방법과 잘못된 방법이 있다. 올바른 방법은 모든 아키텍처를 마이그레이션하기 전에 바로 잡는 것이다. 이는 재개발과 재테스트, 재배치에 몇 주, 몇 달이 걸린다는 의미다. 아니면 리프트 앤 시프트 방식으로 코드와 데이터를 그냥 클라우드로 밀어넣을 수도 있다. 행운은 기대하면서. 하지만 이 방식은 장기적으로 절대 먹혀들지 않는다.

마이그레이션 추정의 어려움은 끔찍한 아키텍처를 고려하지 않는다는 것이다. 실제로 두 달이 필요한데, 2주로 추정한다. 애플리케이션 책임자에게 기반 아키텍처 정보를 달라고 요청하지만, 이들은 제대로 평가하기에는 애플리케이션과 너무 밀접한 관계에 있다. 때에 따라 원본을 버리고 처음부터 새로 시작하는 것이 최상의 방안이 되기도 한다.

비록 코드 분석가와 데이터베이스 분석가가 있지만, 필자의 경험상 이들은 문제가 있다고만 하지 어떤 문제가 있는지, 바로 잡는 것이 어려운지에 대해서는 이야기하지 않는다.

마이그레이션 프로젝트의 규모를 제대로 판단하기 힘든 주된 이유는 이것이지만, 전부는 아니다. 이외에 조금 덜 성가신문제로는 나쁜 보안 관행이나 시스템 성능 문제, 자원의 과잉 사용 등이 있다. 안타깝게도 이런 문제를 바로 잡는 것은 생각보다 훨씬 오래 걸린다. 그렇다고 무시하면 클라우드 마이그레이션 자체가 위험해지며, 큰 재앙을 불러올 수도 있다.

애플리케이션과 데이터 마이그레이션에 소요되는 시간과 비용을 정확하게 추정할 수 있는 방법이 있을까? 현재로서는 숙련된 클라우드 애플리케이션 아키텍트가 필요하다. editor@itworld.co.kr


2019.04.24

IDG 블로그 | 워크로드 마이그레이션 예측이 잘못되는 이유

David Linthicum | InfoWorld
어떤 워크로드나 애플리케이션이라도 퍼블릭 클라우드로 이전하는 데는 짧게는 하루, 길게는 두 달이 걸린다. 기간을 예측하는 것은 상당히 힘들어서 소수의 컨설팅 업체와 퍼블릭 클라우드 서비스 업체, 그리고 필자와 같은 관련 전문가들은 실제로 비용이 얼마나 들지 시간이 얼마나 걸릴지 몇 퍼센트 정도만 성공적으로 모델링할 수 있다고 생각한다.
 
ⓒGettyImagesBank

괜찮은 생각이다. 현실에는 쉽게 모델링할 수 없는 나쁜 애플리케이션이나 데이터 아키텍처가 제법 많기 때문이다.

필자가 클라우드로 이전한 애플리케이션 워크로드와 데이터 세트의 대부분은 위원회에서 설계한 것처럼 보였다. 몇몇 경우는 실제로 그랬다. 확장이 안되거나 데이터베이스를 제대로 활용하지 못했으며, 데이터베이스는 너무 엉망으로 설계해 제대로 인덱싱도 안되고 애플리케이션 자체와 너무 밀접하게 연결되어 있었다.

클라우드 마이그레이션에는 올바른 방법과 잘못된 방법이 있다. 올바른 방법은 모든 아키텍처를 마이그레이션하기 전에 바로 잡는 것이다. 이는 재개발과 재테스트, 재배치에 몇 주, 몇 달이 걸린다는 의미다. 아니면 리프트 앤 시프트 방식으로 코드와 데이터를 그냥 클라우드로 밀어넣을 수도 있다. 행운은 기대하면서. 하지만 이 방식은 장기적으로 절대 먹혀들지 않는다.

마이그레이션 추정의 어려움은 끔찍한 아키텍처를 고려하지 않는다는 것이다. 실제로 두 달이 필요한데, 2주로 추정한다. 애플리케이션 책임자에게 기반 아키텍처 정보를 달라고 요청하지만, 이들은 제대로 평가하기에는 애플리케이션과 너무 밀접한 관계에 있다. 때에 따라 원본을 버리고 처음부터 새로 시작하는 것이 최상의 방안이 되기도 한다.

비록 코드 분석가와 데이터베이스 분석가가 있지만, 필자의 경험상 이들은 문제가 있다고만 하지 어떤 문제가 있는지, 바로 잡는 것이 어려운지에 대해서는 이야기하지 않는다.

마이그레이션 프로젝트의 규모를 제대로 판단하기 힘든 주된 이유는 이것이지만, 전부는 아니다. 이외에 조금 덜 성가신문제로는 나쁜 보안 관행이나 시스템 성능 문제, 자원의 과잉 사용 등이 있다. 안타깝게도 이런 문제를 바로 잡는 것은 생각보다 훨씬 오래 걸린다. 그렇다고 무시하면 클라우드 마이그레이션 자체가 위험해지며, 큰 재앙을 불러올 수도 있다.

애플리케이션과 데이터 마이그레이션에 소요되는 시간과 비용을 정확하게 추정할 수 있는 방법이 있을까? 현재로서는 숙련된 클라우드 애플리케이션 아키텍트가 필요하다. editor@itworld.co.kr


X