2021.04.12

IDG 블로그 | 멀티클라우드 아키텍처 3대 실수

David Linthicum | InfoWorld
멀티클라우드 아키텍처의 최적화는 쉽게 말해, 비용을 최적화하는 것은 물론, 비즈니스 요구사항에 맞춰 아키텍처를 최적화할 수 있도록 기술을 구성하는 역량이다. 클라우드 기술에 사용하는 비용 한푼 한푼이 극대화된 가치로 비즈니스로 되돌아오도록 하는 것이다.
 
ⓒ Getty Images Bank

사실 온전히 최적화된 클라우드 아키텍처는 드물다. 필자는 주된 원흉으로 복잡성에 대한 편향을 지적한 바 있다. 하지만 근본 원인은 배치와 운영이 이루어진 다음에야 아키텍처 최적화에 관해 생각하기 때문이다. 사실 그때는 너무 늦다.

그렇다면, 멀티클라우드 아키텍처는 어떨까? 온전히 최적화되지 못하는 상태에 이르지 못하는 주된 원인은 무엇일까? 세 가지 주된 원인과 그 해법을 소개한다.

너무 많은 기술을 이용한다. 과잉은 복잡성의 사촌이다. 멀티클라우드 아키텍트와 개발팀은 종종 가능한 한 많은 기술을 멀티클라우드에 넣으려 애쓰곤 하는데, 주로 ‘구체화할 수도 있는’ 모든 종류의 요구사항에 대응하는 식이다. 필요한 것은 하나의 서비스 거버넌스 기술일 텐데, 세 가지를 사용한다. 스토리지 서비스도 하나면 충분한데, 일곱 가지를 사용한다. 결국은 더 많은 비용을 들이고도 비즈니스는 추가 가치를 얻지 못한다.

모든 아키텍트는 아직 도달하지 않은 미래를 대비해 아키텍처를 구축하기 때문에 매우 어려운 문제이다. 아키텍트는 내장 미러링 기술을 갖춘 데이터베이스를 선택하는데, 나중에 완전히 분산된 데이터베이스 환경으로 이전할 수도 있기 때문이다. 하지만 몇 년은 뒤의 일이다. 따라서 데이터베이스의 종류는 정말로 충분한 이유가 없다면 2~4개 정도이다. 최적화된 상태에 근접하기 위해서는 ‘최소한의 실행 가능성’에 맞춰 구축해야 한다는 것을 잊지 말기 바란다.

구체적인 요구사항에 맞춰 구축하지 않는다. 요구사항이란 엄격하고 구체적이며 즉각적인 것으로, 이해하기도 쉽다. 주로 멀티클라우드 아키텍처가 어떤 것이 될지 결정하기 때문이다. 실제로 요구사항이 아키텍처가 해결해야 하는 문제의 패턴을 개략적으로 그려준다. 하지만 필자가 본 많은 멀티클라우드 프로젝트는 일반적인 요구사항에 맞춰 설계하고 구축하려고 한다. 정작 비즈니스가 필요로 하는 것에 기반을 둔 것은 별로 없다.

필자도 사람들이 컨설턴트가 하는 말 중 가장 싫어하는 말이 “때에 따라 다르다”인 줄은 안다. 하지만 완전한 최적화를 위해서는 요구사항이 최소한의 실행 가능한 멀티클라우드 아키텍처를 결정하는 것이라야 한다. 

변화에 대비하지 않는다. 멀티클라우드 구축을 책임진 사람들은 심지어 완전한 최적화를 추구하면서도 민첩성을 위한 설계를 어떻게 해야 하는지를 간과한다. 여기서 민첩성이란 아키텍처의 일부는 미래에 일어날 변화에 쉽게 적응할 수 있다는 것을 의미한다. 무수한 아키텍처 기법이 이런 민첩성을 달성했으며, 기본 개념은 매우 이해하기 쉽다.

바로 특정 도메인에 휘발성을 배치하는 것이다. 간단한 변화 때문에 데이터베이스나 애플리케이션을 완전히 새로 구축해야 하는 일을 피하고자 하는 경우를 예로 들어보자. 이때는 데이터베이스와 애플리케이션 간에 데이터 가상화를 이용해 가상 스키마를 필요한 만큼 여러 차례 변경할 수 있도록 한다. 매핑 툴을 이용하면 된다. 이를 통해 멀티클라우드에서 물리 데이터베이스를 변경하는 값 비싸고 위험한 일이 일어나지 않도록 하는 것이다.

이는 너무 많은 기술을 배치하는 것과는 다르다. 변경, 즉 정도나 빈도를 포함해 변경은 그 자체로 요구사항이기 때문이다. 이는 가정이나 추측이 아니다.

아키텍처는 과학이라기보다는 예술에 가까워야 한다. 하지만 새로이 떠오르는 베스트 프랙티스를 이해하면, 멀티클라우드를 설계하고 구축하는 아키텍트가 더 많은 가치를 비즈니스에 돌려줄 수 있을 것이다. 그것이 멀티클라우드 아키텍처의 진정한 목표이다. editor@itworld.co.kr


2021.04.12

IDG 블로그 | 멀티클라우드 아키텍처 3대 실수

David Linthicum | InfoWorld
멀티클라우드 아키텍처의 최적화는 쉽게 말해, 비용을 최적화하는 것은 물론, 비즈니스 요구사항에 맞춰 아키텍처를 최적화할 수 있도록 기술을 구성하는 역량이다. 클라우드 기술에 사용하는 비용 한푼 한푼이 극대화된 가치로 비즈니스로 되돌아오도록 하는 것이다.
 
ⓒ Getty Images Bank

사실 온전히 최적화된 클라우드 아키텍처는 드물다. 필자는 주된 원흉으로 복잡성에 대한 편향을 지적한 바 있다. 하지만 근본 원인은 배치와 운영이 이루어진 다음에야 아키텍처 최적화에 관해 생각하기 때문이다. 사실 그때는 너무 늦다.

그렇다면, 멀티클라우드 아키텍처는 어떨까? 온전히 최적화되지 못하는 상태에 이르지 못하는 주된 원인은 무엇일까? 세 가지 주된 원인과 그 해법을 소개한다.

너무 많은 기술을 이용한다. 과잉은 복잡성의 사촌이다. 멀티클라우드 아키텍트와 개발팀은 종종 가능한 한 많은 기술을 멀티클라우드에 넣으려 애쓰곤 하는데, 주로 ‘구체화할 수도 있는’ 모든 종류의 요구사항에 대응하는 식이다. 필요한 것은 하나의 서비스 거버넌스 기술일 텐데, 세 가지를 사용한다. 스토리지 서비스도 하나면 충분한데, 일곱 가지를 사용한다. 결국은 더 많은 비용을 들이고도 비즈니스는 추가 가치를 얻지 못한다.

모든 아키텍트는 아직 도달하지 않은 미래를 대비해 아키텍처를 구축하기 때문에 매우 어려운 문제이다. 아키텍트는 내장 미러링 기술을 갖춘 데이터베이스를 선택하는데, 나중에 완전히 분산된 데이터베이스 환경으로 이전할 수도 있기 때문이다. 하지만 몇 년은 뒤의 일이다. 따라서 데이터베이스의 종류는 정말로 충분한 이유가 없다면 2~4개 정도이다. 최적화된 상태에 근접하기 위해서는 ‘최소한의 실행 가능성’에 맞춰 구축해야 한다는 것을 잊지 말기 바란다.

구체적인 요구사항에 맞춰 구축하지 않는다. 요구사항이란 엄격하고 구체적이며 즉각적인 것으로, 이해하기도 쉽다. 주로 멀티클라우드 아키텍처가 어떤 것이 될지 결정하기 때문이다. 실제로 요구사항이 아키텍처가 해결해야 하는 문제의 패턴을 개략적으로 그려준다. 하지만 필자가 본 많은 멀티클라우드 프로젝트는 일반적인 요구사항에 맞춰 설계하고 구축하려고 한다. 정작 비즈니스가 필요로 하는 것에 기반을 둔 것은 별로 없다.

필자도 사람들이 컨설턴트가 하는 말 중 가장 싫어하는 말이 “때에 따라 다르다”인 줄은 안다. 하지만 완전한 최적화를 위해서는 요구사항이 최소한의 실행 가능한 멀티클라우드 아키텍처를 결정하는 것이라야 한다. 

변화에 대비하지 않는다. 멀티클라우드 구축을 책임진 사람들은 심지어 완전한 최적화를 추구하면서도 민첩성을 위한 설계를 어떻게 해야 하는지를 간과한다. 여기서 민첩성이란 아키텍처의 일부는 미래에 일어날 변화에 쉽게 적응할 수 있다는 것을 의미한다. 무수한 아키텍처 기법이 이런 민첩성을 달성했으며, 기본 개념은 매우 이해하기 쉽다.

바로 특정 도메인에 휘발성을 배치하는 것이다. 간단한 변화 때문에 데이터베이스나 애플리케이션을 완전히 새로 구축해야 하는 일을 피하고자 하는 경우를 예로 들어보자. 이때는 데이터베이스와 애플리케이션 간에 데이터 가상화를 이용해 가상 스키마를 필요한 만큼 여러 차례 변경할 수 있도록 한다. 매핑 툴을 이용하면 된다. 이를 통해 멀티클라우드에서 물리 데이터베이스를 변경하는 값 비싸고 위험한 일이 일어나지 않도록 하는 것이다.

이는 너무 많은 기술을 배치하는 것과는 다르다. 변경, 즉 정도나 빈도를 포함해 변경은 그 자체로 요구사항이기 때문이다. 이는 가정이나 추측이 아니다.

아키텍처는 과학이라기보다는 예술에 가까워야 한다. 하지만 새로이 떠오르는 베스트 프랙티스를 이해하면, 멀티클라우드를 설계하고 구축하는 아키텍트가 더 많은 가치를 비즈니스에 돌려줄 수 있을 것이다. 그것이 멀티클라우드 아키텍처의 진정한 목표이다. editor@itworld.co.kr


X