클라우드

IDG 블로그 | 모두가 저지르는, 하지 말아야 할 클라우드 아키텍처 실수 3가지

David Linthicum | InfoWorld 2021.04.26
필자가 일을 의뢰한 기업과 갈등을 겪은 단 한 번은 의뢰주가 꽤 큰 실수를 저지른 필자 팀의 초보 IT 아키텍트를 처벌하려고 했을 때이다. 데이터베이스 중 하나가 기존에 있던 미들웨어 계층과 호환되지 않은 것이다.

분명 이 실수 때문에 시간과 비용을 더 들었다. 하지만 이런 실수는 클라우드 컴퓨팅이 포함된 IT 시스템을 구성할 때 거의 피할 수 없는 것이기도 하다. 필자는 이런 실수를 혁신 과정에 불가피한 것으로 본다. 새로운 것을 시도해 보지 않는다면, 그래서 그들 중 일부가 제대로 동작하지 않는다는 것을 찾아내지 않는다면, 아무것도 개선할 수 없다. 필자는 상사에게 다른 일을 찾자고 졸랐고, 결국 그렇게 했다.
 
ⓒ Getty Images Bank

만약 실수가 혁신적이고 새로운 아키텍처의 부산물이라면, 이제 자주 저질러지는 실수를 살펴봐야 한다. 클라우드 아키텍처는 이제 이런 실수를 이해하고 피할 수 있어야 한다. 흔한 실수 세 가지를 살펴보자.

1. 과도한 분산. 애플리케이션과 데이터 구성요소를 분리할 수 있다는 이유만으로, 그리고 이들을 네트워크 연결된 시스템을 통해 곳곳에서 구동할 수 있다는 이유만으로 분산해서는 안된다. 클라우드 아키텍처는 특히 이런 실수에 취약한데, 모든 종류의 플랫폼을 서로 다른 클라우드에 프로비저닝하기도, 이들을 연결하기도 쉽기 때문이다. 하지만 그 결과는 잘 알려진 것처럼, 열악한 지연과 안정성이다.

좋은 아키텍처의 법칙 중 많은 것이 여전히 유효하다. 특히 같은 애플리케이션과 데이터 저장소를 위한 프로세싱과 데이터 스토리지를 최대한 가까이 위치시켜야 한다. 보통은 인트라클라우드를 의미하지만, 같은 클라우드 상에서는 인트라플랫폼이 될 수도 있다.

2. 보안이 마지막 단계. 보안은 한때 프로세스의 마지막에 추가하는 것이었다. 하지만 클라우드 프로젝트에서도 이렇게 하면, 잘해야 최적화되지 않은 보안 시스템이 되고, 최악의 경우 전혀 안전하지 않은 보안 시스템이 된다.

클라우드 컴퓨팅 세계에서 보안은 나중에 생각할 수 있는 것이 아니다. 비록 시스템 설계와 구축 프로세스에 복잡성과 비용이 추가되겠지만, 효과적인 보안은 애플리케이션과 데이터, 플랫폼, 호스팅 클라우드에 체계적이어야 한다. 보안은 모든 단계마다 생각해야 한다.

3. 변화를 수용할 수 없는 설계. 20년 전에는 변화를 염두에 두지 않고 애플리케이션을 구축했다. 지금 이런 애플리케이션을 클라우드로 이전하기 위한 리팩터링으로 상당한 대가를 치르고 있다.

SOA(Service-Oriented Architecture)는 변경을 염두에 둔 설계는 나중에 큰 보상을 받는다고 가르쳤다. 이는 마이크로서비스처럼 변경 가능성이 큰 것은 전체 애플리케이션 체계의 변경이 일어나지 않도록 배치해야 한다는 의미이다. 이외에도 분산 객체나 컨테이너, 머신러닝, 로직 서버 등은 쉽게 바뀔 수 있는 것들이다.

지금도 누군가는 같은 실수를 저지르고 있을지 모른다. 이제 같은 실수를 반복하지 말아야 할 때이다. editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.