2019.04.24

블로그 | 클라우드 이전 메트릭스를 덜컥 믿기 어려운 이유

데이빗 S. 린시컴 | InfoWorld
데이터나 애플리케이션을 퍼블릭 클라우드로 마이그레이션하는데 소요되는 비용과 시간을 예측해준다고 주장하는 ‘멋진’ 알고리즘들이 있다. 애석하게도 이들은 그리 잘 맞지 않는다. 

워크로드 또는 애플리케이션을 퍼블릭 클라우드로 이동하는 데 소요되는 시간은 천차만별이다. 하루에서 두어 달 사이를 오간다. 몇 퍼센트 오차 이내로 소용 비용과 시간을 예측할 수 있다고 자신하는 컨설팅 기업, 퍼블릭 클라우드 기업, 업계 전문가들이 소수에 그치는 이유다. 

그러나 이들 일부의 주장조차도 현실 속에서는 그리 정확하지 않다. 잘못된 애플리케이션 및 데이터 아키텍처와 같은 몇 가지 요소는 쉽게 모델화될 수 없기 때문이다. 

필자 경험에 따르면 클라우드로 이전한 거의 모든 애플리케이션 워크드로와 데이터 세트는 마치 위원회가 고안한 것처럼 보이곤 한다. (실제로 그런 사례도 있다.) 이들은 스케일링이 어렵거나 데이터베이스를 제대로 활용하지 못한다. 데이터베이스가 너무 불량하게 디자인돼 중복 데이터를 보유하거나 색인이 제대로 작성되지 않는 경우도 있다. 애플리케이션과 지나치게 결합된 사례도 있다. 익숙하게 들리는가?

클라우드로 이전하는 데에는 잘못된 길과 올바른 길이 있다. 올바른 길은 이전에 앞서 모든 아키텍처 문제를 해결하는 것이다. 즉 몇 주 또는 몇 달 간의 재개발, 재시험, 재배치를 의미한다. 반면 코드와 데이터를 클라우드로 밀어놓고 최선 결과를 기대하면 장기적으로 심각한 문제를 피할 수 없다. 

일부에서 주장하는 마이그레이션 예측 메트릭스의 문제는 아키텍처를 제대로 고려하지 않는 것이다. 이로 인해 2개월이 필요할 때 2주라는 예상 시간이 도출될 수 있다. 애플리케이션 소유자에게 기저의 아키텍처 정보를 요구한다고 해서 해결되는 문제가 아니다. 적절히 객관적으로, 때로는 자기 비판적으로 평가할 것으로 기대하기란 무리다. 경우에 따라서는 송두리째 처음부터 시작하는 방법이 가장 좋을 수 있다. 

코드와 데이터베이즈를 분석한다는 솔루션들이 있기는 하지만 필자의 경험으로는 모두 문제를 품고 있었다. 그리고  그 문제가 무엇인지, 수정 작업의 난이도는 어떤지 등에 대한 정보는 공개되지 않았다. 

클라우드 이전에는 또 보안 취약성, 시스템 성능 문제, 리소스 과다 사용 문제 등의 덜 까다로운 문제들이 있다. 이러한 문제 또한 생각보다 수정에 오랜 시간이 걸리는 것들이다. 이를 간과하고 이전을 덜컥 진행한다면 결과는 파국적일 수 있다. 

그렇다면 애플리케이션과 데이터를 마이그레이션하는 데 드는 비용과 시간을 적절히 예측할 방법은 없는 것일까? 숙련된 클라우드 애플리케이션 아키텍트가 주도한다면 가능하다. 그의 존재와 당신의 휴식 시간은 온전히 정비례할 것이다.

* 데이빗 S. 린시컴은 딜로이트 컨설팅 클라우드 전략 담당 책임자다. ciokr@idg.co.kr



2019.04.24

블로그 | 클라우드 이전 메트릭스를 덜컥 믿기 어려운 이유

데이빗 S. 린시컴 | InfoWorld
데이터나 애플리케이션을 퍼블릭 클라우드로 마이그레이션하는데 소요되는 비용과 시간을 예측해준다고 주장하는 ‘멋진’ 알고리즘들이 있다. 애석하게도 이들은 그리 잘 맞지 않는다. 

워크로드 또는 애플리케이션을 퍼블릭 클라우드로 이동하는 데 소요되는 시간은 천차만별이다. 하루에서 두어 달 사이를 오간다. 몇 퍼센트 오차 이내로 소용 비용과 시간을 예측할 수 있다고 자신하는 컨설팅 기업, 퍼블릭 클라우드 기업, 업계 전문가들이 소수에 그치는 이유다. 

그러나 이들 일부의 주장조차도 현실 속에서는 그리 정확하지 않다. 잘못된 애플리케이션 및 데이터 아키텍처와 같은 몇 가지 요소는 쉽게 모델화될 수 없기 때문이다. 

필자 경험에 따르면 클라우드로 이전한 거의 모든 애플리케이션 워크드로와 데이터 세트는 마치 위원회가 고안한 것처럼 보이곤 한다. (실제로 그런 사례도 있다.) 이들은 스케일링이 어렵거나 데이터베이스를 제대로 활용하지 못한다. 데이터베이스가 너무 불량하게 디자인돼 중복 데이터를 보유하거나 색인이 제대로 작성되지 않는 경우도 있다. 애플리케이션과 지나치게 결합된 사례도 있다. 익숙하게 들리는가?

클라우드로 이전하는 데에는 잘못된 길과 올바른 길이 있다. 올바른 길은 이전에 앞서 모든 아키텍처 문제를 해결하는 것이다. 즉 몇 주 또는 몇 달 간의 재개발, 재시험, 재배치를 의미한다. 반면 코드와 데이터를 클라우드로 밀어놓고 최선 결과를 기대하면 장기적으로 심각한 문제를 피할 수 없다. 

일부에서 주장하는 마이그레이션 예측 메트릭스의 문제는 아키텍처를 제대로 고려하지 않는 것이다. 이로 인해 2개월이 필요할 때 2주라는 예상 시간이 도출될 수 있다. 애플리케이션 소유자에게 기저의 아키텍처 정보를 요구한다고 해서 해결되는 문제가 아니다. 적절히 객관적으로, 때로는 자기 비판적으로 평가할 것으로 기대하기란 무리다. 경우에 따라서는 송두리째 처음부터 시작하는 방법이 가장 좋을 수 있다. 

코드와 데이터베이즈를 분석한다는 솔루션들이 있기는 하지만 필자의 경험으로는 모두 문제를 품고 있었다. 그리고  그 문제가 무엇인지, 수정 작업의 난이도는 어떤지 등에 대한 정보는 공개되지 않았다. 

클라우드 이전에는 또 보안 취약성, 시스템 성능 문제, 리소스 과다 사용 문제 등의 덜 까다로운 문제들이 있다. 이러한 문제 또한 생각보다 수정에 오랜 시간이 걸리는 것들이다. 이를 간과하고 이전을 덜컥 진행한다면 결과는 파국적일 수 있다. 

그렇다면 애플리케이션과 데이터를 마이그레이션하는 데 드는 비용과 시간을 적절히 예측할 방법은 없는 것일까? 숙련된 클라우드 애플리케이션 아키텍트가 주도한다면 가능하다. 그의 존재와 당신의 휴식 시간은 온전히 정비례할 것이다.

* 데이빗 S. 린시컴은 딜로이트 컨설팅 클라우드 전략 담당 책임자다. ciokr@idg.co.kr

X