4일 전

IDG 블로그 | 클라우드 아키텍처 최적화 쉽게 이해하기

David Linthicum | InfoWorld
클라우드 아키텍처 최적화의 개념에 관해 여러 번 논의했으니, 이제 평가 방법을 알아볼 차례다. 사실 감사(Audit) 없이 클라우드 아키텍처가 최적화되어 있지 않다는 것을 증명할 방법은 없는데, 여기서 감사란 솔루션의 접근법과 관련 비용 모두를 재검토하는 것을 의미한다.
 
ⓒ Getty Images Bank

과거에는 클라우드 솔루션을 구축하고 배치하는 기업이 자사의 선택에 의문을 제기하는 것을 꺼렸다. 하지만 클라우드 솔루션의 가치를 극대화하는 것이 중요해지면서 많은 기업이 이런 의문과 감독에 대한 마음가짐을 바꿨다. 기업 경영진의 변화도 적지 않다. 최근 필자가 참여한 프로젝트 중 많은 수가 구축과 배치, 마이그레이션보다는 평가와 개선을 위한 감사에 중점을 두고 있다.

일단 모든 것이 클라우드 아키텍처에서 동작하면, 기업은 애플리케이션을 배치하고 운영할 수 있다. 하지만 그저 동작하는 것과 최적화는 다르다. 자사의 아키텍처와 제대로 최적화된 아키텍처 간의 차이를 살펴보면, ‘잘 돌아가는’ 솔루션이 수백만 달러나 비용이 더 든다는 것을 발견할 수도 있다.

다음 그래프는 이를 시각적으로 표현한 것이다. 1과 37이 가장 최적화가 안된 지점으로, 비용은 많이 들고 효율은 낮다.
 
ⓒ IDG

양쪽을 보면, 클라우드 솔루션은 컨테이너와 서버리스 컴퓨팅처럼 덜 활용할 수도, 너무 활용할 수도 있다. 그래프 왼쪽은 컨테이너를 충분히 활용하지 않는 것이고, 반대로 오른쪽은 컨테이너를 과도하게 활용하는 것으로 볼 수 있다. 최적화 지점은 19가 되는데, 적절한 수의 컨테이너를 사용해 비용 효율과 솔루션 효율 모두가 극대화된 상태이다.

이 지표를 전체 아키텍처를 평가하는 데 사용할 수도 있고, 각각의 구성 기술을 평가하는 데 이용할 수도 있다. 참고로 데이터를 여러 항목으로 살펴보면, 좀 더 현실적인 곡선 그래프를 얻을 수 있을 것이다. 실제 환경에서 이런 직선은 나오지 않는다.

그렇다면 클라우드 아키텍처 감사는 어떤 의미가 있는가? 만약 이제 막 클라우드 여정을 시작했다면, 예정된 솔루션의 최적화를 테스트하고 확인하는 방법이 된다. 어느 기업이든 그래프의 중앙에 가까이 가고자 한다.

여정의 중간 지점에 도달했다면, 감사는 이미 배치된 솔루션과 현재 개발 중인 솔루션을 평가하는 방법이다. 힘든 부분은 다른 사람에게 자신의 결정에 대한 평가를 맡기는 것이다. 많은 경우, 외부 감사팀은 초기 아키텍처에 의문을 제기하고 순위 프로세스를 사용해 1~37 사이로 점수를 매길 것이다. 

사실 자사의 작업을 외부에 확인해 달라고 요청하는 것은 약한 모습이 아니다. 오히려 아키텍처 감사를 실시하는 기업을 칭찬해야 한다. 그렇지 않으면 나중에 수백만 달러의 불필요한 비용을 들이고, 심한 경우 비즈니스에 회복 불능의 피해를 입힐 수 있다. 자존심을 내세우기에는 판돈이 너무 크다. 현명해야 한다. editor@itworld.co.kr


4일 전

IDG 블로그 | 클라우드 아키텍처 최적화 쉽게 이해하기

David Linthicum | InfoWorld
클라우드 아키텍처 최적화의 개념에 관해 여러 번 논의했으니, 이제 평가 방법을 알아볼 차례다. 사실 감사(Audit) 없이 클라우드 아키텍처가 최적화되어 있지 않다는 것을 증명할 방법은 없는데, 여기서 감사란 솔루션의 접근법과 관련 비용 모두를 재검토하는 것을 의미한다.
 
ⓒ Getty Images Bank

과거에는 클라우드 솔루션을 구축하고 배치하는 기업이 자사의 선택에 의문을 제기하는 것을 꺼렸다. 하지만 클라우드 솔루션의 가치를 극대화하는 것이 중요해지면서 많은 기업이 이런 의문과 감독에 대한 마음가짐을 바꿨다. 기업 경영진의 변화도 적지 않다. 최근 필자가 참여한 프로젝트 중 많은 수가 구축과 배치, 마이그레이션보다는 평가와 개선을 위한 감사에 중점을 두고 있다.

일단 모든 것이 클라우드 아키텍처에서 동작하면, 기업은 애플리케이션을 배치하고 운영할 수 있다. 하지만 그저 동작하는 것과 최적화는 다르다. 자사의 아키텍처와 제대로 최적화된 아키텍처 간의 차이를 살펴보면, ‘잘 돌아가는’ 솔루션이 수백만 달러나 비용이 더 든다는 것을 발견할 수도 있다.

다음 그래프는 이를 시각적으로 표현한 것이다. 1과 37이 가장 최적화가 안된 지점으로, 비용은 많이 들고 효율은 낮다.
 
ⓒ IDG

양쪽을 보면, 클라우드 솔루션은 컨테이너와 서버리스 컴퓨팅처럼 덜 활용할 수도, 너무 활용할 수도 있다. 그래프 왼쪽은 컨테이너를 충분히 활용하지 않는 것이고, 반대로 오른쪽은 컨테이너를 과도하게 활용하는 것으로 볼 수 있다. 최적화 지점은 19가 되는데, 적절한 수의 컨테이너를 사용해 비용 효율과 솔루션 효율 모두가 극대화된 상태이다.

이 지표를 전체 아키텍처를 평가하는 데 사용할 수도 있고, 각각의 구성 기술을 평가하는 데 이용할 수도 있다. 참고로 데이터를 여러 항목으로 살펴보면, 좀 더 현실적인 곡선 그래프를 얻을 수 있을 것이다. 실제 환경에서 이런 직선은 나오지 않는다.

그렇다면 클라우드 아키텍처 감사는 어떤 의미가 있는가? 만약 이제 막 클라우드 여정을 시작했다면, 예정된 솔루션의 최적화를 테스트하고 확인하는 방법이 된다. 어느 기업이든 그래프의 중앙에 가까이 가고자 한다.

여정의 중간 지점에 도달했다면, 감사는 이미 배치된 솔루션과 현재 개발 중인 솔루션을 평가하는 방법이다. 힘든 부분은 다른 사람에게 자신의 결정에 대한 평가를 맡기는 것이다. 많은 경우, 외부 감사팀은 초기 아키텍처에 의문을 제기하고 순위 프로세스를 사용해 1~37 사이로 점수를 매길 것이다. 

사실 자사의 작업을 외부에 확인해 달라고 요청하는 것은 약한 모습이 아니다. 오히려 아키텍처 감사를 실시하는 기업을 칭찬해야 한다. 그렇지 않으면 나중에 수백만 달러의 불필요한 비용을 들이고, 심한 경우 비즈니스에 회복 불능의 피해를 입힐 수 있다. 자존심을 내세우기에는 판돈이 너무 크다. 현명해야 한다. editor@itworld.co.kr


X