프라이빗 클라우드 구축 프로젝트가 기존 IT 인프라와 다른 3가지

퍼블릭 클라우드가 기업용 컴퓨팅 인프라에 점점 더 폭넓게 적용되고 있지만 외부 클라우드로 돌릴 수 없는 워크로드는 여전히 많다. 일정 수준의 성능이 필요하거나 법적 규제를 받는 분야이거나 혹은 클라우드 접속을 위한 고속 네트워크 비용이 부담스러운 경우가 대표적이다.

그러나 이런 경우에도 기업 부서별로 자체적으로 컴퓨팅 자원을 관리하고 사용한 만큼 요금을 내는 것이 바람직하다. 프라이빗 클라우드로 눈을 돌려야 하는 지점은 바로 여기다. 기업 내부 인프라에 클라우드를 구축해 퍼블릭 클라우드 장점을 실현하면서 필요한 성능 수준과 보안 요건까지 만족할 수 있다. 프라이빗 클라우드를 구축하면 잠재적인 비용 요소가 될 수 있는 클라우드 WAN 연결도 필요없다.

그렇다면 이 장점 많은 프라이빗 클라우드를 어떻게 구축해야 할까? 프라이빗 클라우드는 많은 부분에서 기존 기업 데이터 센터 인프라 구축과 비슷하다. 그러나 3가지 부분에서 큰 차이를 보인다. 다음 3가지를 미리 알아두면 프라이빗 클라우드 구축시 시행착오를 크게 줄일 수 있을 것이다.

1. 균형 잡힌 관리 역량
기존의 온프레미스(on-premises) 가상화 인프라와 프라이빗 클라우드의 가장 큰 차이는 관리 계층(management layer), 즉 IT 부서가 실제로 관리 계층을 사용하는 방식이다.

예를 들어 블레이드 기반의 가상화 인프라를 지원하는 전통적인 IT 부서를 생각해 보자. 이들 인프라를 통합하면 프라이빗 클라우드를 지원할 수 있지만 관리 계층은 IT 부서만 사용하게 될 가능성이 높다. 즉 현업 부서가 서버 자원을 IT 부서에 요청하면 IT 부서가 보유한 관리 툴을 이용해 부서 일정에 따라 이러한 요청을 처리하게 된다.

그러나 일반적으로 프라이빗 클라우드는 일정 수준의 사용자 셀프 서비스 기능을 제공한다. 현업 부서가 '요람에서 무덤까지' 컴퓨팅 리소스의 모든 부분을 관리할 수 있거나 적어도 특정 부분을 자동화해서 사용할 수 있도록 허용한다.

균형 잡힌 관리 역량이 필요한 지점도 바로 여기다. IT 부서가 현업이 컴퓨팅 자원을 요청할 수 있는 프라이빗 클라우드 관리 툴을 제공하고 그 요청을 승인하는 권리를 유지하는 방법이 있다. 현업이 구매한 리소스를 필요한 때 업그레이드할 수 있도록 전체 프로세스를 100% 자동화한 셀프 서비스를 구현하는 것도 방법이다.

그렇다면 이러한 허용 수준을 어떻게 결정해야 할까? 사실 이 문제는 구축하려는 클라우드가 얼마나 뛰어난가 와는 관련이 없다. 또한 대부분의 클라우드 관리 프레임워크가 최종 사용자에게 다양한 관리 기능을 제공하기 때문에 비용과도 상관이 없는 경우가 많다.

오히려 허용 수준에 대한 의사결정은 클라우드 관리 소프트웨어 계층의 기능과 현업의 IT 역량 간의 매칭에서 찾아야 한다. 예를 들어 고수준 컴퓨팅 인스턴스를 이를 이해할 능력이 없는 현업 부서에 제공하는 것은 의미도 없고 바람직하지도 않다. 반대로 현업이 높은 전문성을 갖고 있음에도 불구하고 그 이하로 접속을 제한하면 IT 부서와의 갈등이 초래된다.

따라서 해법은 현업 부서의 요구에 부합하는 클라우드 관리 패키지를 도입하거나 혹은 자체 개발하는 것이다.

2. 멀티테넌트 보안
전통적인 IT 부서 중심의 인프라와 프라이빗 클라우드의 두번째 큰 차이점은 보안 모델이다. 전형적인 IT 환경에서는 현업 부서가 보안을 신경써야 할 부분은 많지 않았다. 대부분 IT 부서가 관리했기 때문이다.

그러나 현업 부서가 자체적으로 서버를 배치해 관리 계층에서 이를 관리하는 프라이빗 클라우드 환경이라면 상황이 달라진다. IT 부서는 특정 부서가 사용하는 IT 인프라를 신뢰할 수 없는 영역으로 보고 이를 전체 프라이빗 클라우드의 핵심 인프라와 다른 현업 부서의 인프라로부터 분리해 다른 시스템들을 보호해야 한다.

이러한 형태의 내부 보안을 구현하는 것은 쉽지 않기 때문에 전혀 다른 사고방식으로 고민해야 한다. 즉 이제 '내부와 외부, DMZ'로 네트워크를 구분하던 시대는 갔다. 지금은 단 하나의 '외부'와 여러 개의 '내부'만 있을 뿐이다. 여러 개의 내부 각각에 보안 정책과 관리 영역을 구현해야 하는 것이다.

이처럼 내부 보안 모델을 서로 구분해 적용하면 관리 통제 경계가 명확해 지기 때문에 프라이빗 클라우드 인프라의 외부 보안도 더 강화할 수 있다. 단일 관리 체계와 철저한 하향식 관리 체계를 적용하고 있는 네트워크에서도 일정 수준의 내부 보안 역량을 갖추면 해킹이나 악성코드 확산을 막는데 매우 유용하다. 이는 프라이빗 클라우드를 구축할 때 충분히 검토해 볼만한 가치가 있는 방법이다.

3. 비파괴적인 확장
마지막으로 프라이빗 클라우드 구축 프로젝트가 기존 IT 인프라 프로젝트와 다른 것은 시스템을 확장할 때 기존 리소스를 재활용하면서 간편하게 이뤄질 수 있어야 한다는 점이다.

이러한 특성은 인프라의 규모와 복잡성에 따라 크게 달라질 수 있다. 어떤 경우는 초기 규모 대비 몇배로 확장할 수 있는 인프라를 구축하는 문제로 불거지고 또 어떤 경우는 확장성과 안정성을 갖춘 복잡한 객체 기반 스토리지를 설계해야 하는 상황이 발생하기도 한다.

인프라를 구축, 관리하는 방법을 어떻게 변경하든, 가장 중요한 것은 현업 부서가 자유롭게 컴퓨팅 자원을 사용할 수 있도록 하는 것이 IT인프라를 유지하는 IT 부서의 역할에 어떤 영향을 미칠 것인가를 고민하는 것이다.

결국 프라이빗 클라우드는 현대적인 기업 컴퓨팅 인프라와 크게 다르지 않다. 인프라 관리 방법, 포함되는 내부 보안의 종류, 확장 방식에 있어 일부 차이가 있지만 사용하는 하드웨어와 소프트웨어는 사실상 같다. 여러분의 기업이 지금 당장 프라이빗 클라우드를 구축하지는 않더라도 이런 차이들은 미리 알아둘 필요가 있다. 언젠가는 프라이빗 클라우드가 전통적인 컴퓨팅 인프라 개념을 대체할 것이기 때문이다. editor@idg.co.kr