2017.12.04

“선택 아닌 필수” 하이브리드 클라우드를 시작하는 방법

Andrew C. Oliver | InfoWorld
하이브리드 클라우드는 주요 IT 솔루션 업체들이 내세우는 말이지만, 인프라와 애플리케이션을 클라우드로 이전할 기업이라면 진지하게 받아들여야 한다.

누구라도 하룻밤에 퍼블릭 클라우드로 옮겨갈 수는 없다. 하이브리드 클라우드가 기업에 매우 중요한 개념인 이유이다. 하이브리드 클라우드란 서버 팜과 VM웨어나 오라클 등에 대한 대규모 투자를 유지하면서 일부 워크로드만 퍼블릭 클라우드로 재배치한다는 개념이다. 퍼블릭 클라우드와 같은 기술을 여럿 사용해 프라이빗 클라우드를 구축한다. 그렇지만 어떤 애플리케이션은 프라이빗으로도 퍼블릭으로도 옮기지 않는다.

Image Credit : GettyImagesBank

하이브리드 클라우드 환경에서 기업은 인프라를 자체적으로 운영하고 테넌시나 프로비저닝, 확장 등에서 클라우드의 기능 일부를 가져다 사용하고, 이후에 준비가 되면 퍼블릭이나 프라이빗 클라우드로 애플리케이션을 재배치할 수 있다. 실제로 일부 데이터나 서비스는 규제나 보안, 대역폭, 비용 등의 이유로 퍼블릭 클라우드로 보낼 수 없을지도 모른다.

또한, 하이브리드 클라우드의 점진적인 특성이 진정한 이점이 되는데, IT 부서가 클라우드를 조심스럽게 시험해 보고 필요하면 되돌릴 수도 있기 때문이다.

프라이빗이든 퍼블릭이든 클라우드를 시작하려면, 핵심 서비스를 이용할 수 있어야 하고, 무엇을 먼저 옮기고 어떤 것은 남겨둘 것인지를 정할 실현 가능한 전략이 있어야 한다.

하이브리드 클라우드에서 필요한 핵심 서비스
하이브리드 클라우드 전략이 제대로 작동하기 위해서는 온프레미스 데이터센터와 퍼블릭 클라우드 양쪽 모두에 세 가지 종류의 핵심 인프라 서비스가 있어야 한다.

1. 보안과 ID. 사용자를 인증하고 로컬과 클라우드 모두의 애플리케이션을 사용할 수 있는 권한을 부여할 방안이 있어야 한다. 특히 각 애플리케이션이 각각의 보안 환경을 만들어내지 않도록 중앙에서 관리할 수 있어야 한다.

2. 검색. 두 곳 모두에서 무엇인가를 찾아야 한다. 또한, 두 환경에 걸쳐서 무언가를 찾을 수 있는 검색 솔루션도 필요하다. 이때 중요한 것은 보안을 존중하는 것으로, 방화벽 뒤편의 데이터가 인터넷으로 나가면 안되기 때문이다. 참고로 필자는 검색 솔루션 전문업체 루시드웍스에서 일한다.

3. 코어 데이터. 물로 클라우드에도 데이터베이스가 있다. 하지만 모든 것이 RDBMS에 있지는 않다. 없으면 어떤 비즈니스 애플리케이션도 제대로 동작할 수 없는 핵심 기업 데이터 또한 애플리케이션이나 다른 저장소에 있다. 이런 데이터 일부는 이제 어떤 식으로든 클라우드에 있는데, 세일즈포스 같은 애플리케이션이 대표적이다. 하지만 그 외에도 클라우드에 두어야 할 데이터가 있다.

퍼블릭 클라우드로 옮겨야 하는 것
일반적으로 애플리케이션은 업데이트하기 전에는 클라우드로 옮기지 않는다. 이는 어떤 식으로든 이들 애플리케이션에 투자해야 한다는 의미이다. 업데이트가 이루어진 다음에 어떤 것을 클라우드로 옮길 것인지를 결정하려면, 다음 질문에 답해보기 바란다.

1. 비용이 얼마나 드는가? 애플리케이션을 클라우드로 이전하면 장비나 관리 비용을 절감할 수도 있다. 하지만 클라우드가 항상 더 저렴하다는 것은 잘못된 미신이다. 만약 해당 애플리케이션이 엄청난 CPU 성능을 필요로 하고 막대한 양의 데이터를 내놓으면서 24/7 동안 비교적 적은 사용자가 이용하고, 여기에 더해 업데이트할 일도 없고 확장도 절대로 하지 않는다면, 클라우드가 더 저렴한 시나리오는 생각하기 어렵다.

2. 애플리케이션의 아키텍처는? 현대적인 웹 기술을 기반으로 구축한 애플리케이션은 구식 아키텍처의 애플리케이션보다 이전하기가 더 쉽다. 구식 아키텍처를 클라우드를 염두에 두지 않았고, 그렇기 때문에 구식 애플리케이션을 클라우드에서 구동하려면 밑바닥부터 다시 작성해야 한다.

3. 지원 팀이 있는가? 만약 개발팀과 인프라 팀이 이전을 지원하지 않는다면, 매우 어려운 장애물이 있는 것이고, 실패할 가능성이 아주 크다.

4. 규제 문제는 없는가? 만약 규제를 준수해야 하거나 다양한 인증이 필요하다면, 클라우드 인프라를 이를 제공하는지 확실히 해야 한다. 이런 요구사항이 클라우드에서는 아주 복잡한 문제가 될 수 있다. 애플리케이션이나 데이터를 특정 국가에 두는 것이 허용되는가? 클라우드 서비스 업체가 제대로 된 자격이 있는가? 클라우드에 배치된 애플리케이션이 이런 요구사항을 만족하는가?

5. 의존성 문제는 없는가? 애플리케이션의 모든 의존성이 클라우드에서도 그대로인가?

6. 데이터를 어떻게 찾을 수 있는가? 만약 데이터를 클라우드로 이전한다면, 누군가 이 데이터를 찾을 수 있는가? 이를 어떻게 공개할 것인가? 어떻게 찾고 어떻게 내부 데이터로 보강할 것인가?

한편, 이런 고려사항은 프라이빗 클라우드로 이전할 때도 똑같이 적용된다. 어떤 경우, 규제 준수나 애플리케이션 의존성 문제는 프라이빗 클라우드로 이전하면 좀 더 쉽게 해결할 수도 있다. 하지만 프라이빗 클라우드 인프라는 기업이 자체적으로 보호하고 관리하고 운영하고 진화시켜야 한다. 어쨌든 자체 데이터센터이다.

전용 인프라에 그대로 남겨둘 것
어떤 애플리케이션은 그냥 클라우드나 하이브리드로 이전하지 않는다. 장기적으로는 새로운 애플리케이션을 찾는 방안을 생각해 볼 수 있겠지만, 단기적으로 다음과 같은 애플리케이션은 온프레미스에 원래대로 두고자 할 것이다.

- 극히 안정적이고 정적인 애플리케이션. 업데이트하지 않으면서 계속 사용하고 매우 안정적인 애플리케이션이 있다면, 긁어 부스럼을 만들 필요는 없다.

- 웹 방식이 아닌 애플리케이션. 1990년대 초반에 작성된 분산 컴퓨팅 환경의 괴물이라 모든 것이 고정된 주소를 갖는다면? 아마도 4GL 데스크톱 애플리케이션으로 터미널 서비스가 필요할 것이다. 웹 이전 시대, 클라우드 이전 아키텍처와 기술을 사용하는 어떤 애플리케이션도 클라우드로 이전하기 어렵다. 확장도 어렵다. 다른 후보자를 찾아보기 바란다.

- 높은 의존성. 만약 해당 애플리케이션이 아직 클라우드를 지원하지 않는 수많은 요소에 의존하고 있다면, 나중으로 미루기 바란다.  editor@itworld.co.kr

2017.12.04

“선택 아닌 필수” 하이브리드 클라우드를 시작하는 방법

Andrew C. Oliver | InfoWorld
하이브리드 클라우드는 주요 IT 솔루션 업체들이 내세우는 말이지만, 인프라와 애플리케이션을 클라우드로 이전할 기업이라면 진지하게 받아들여야 한다.

누구라도 하룻밤에 퍼블릭 클라우드로 옮겨갈 수는 없다. 하이브리드 클라우드가 기업에 매우 중요한 개념인 이유이다. 하이브리드 클라우드란 서버 팜과 VM웨어나 오라클 등에 대한 대규모 투자를 유지하면서 일부 워크로드만 퍼블릭 클라우드로 재배치한다는 개념이다. 퍼블릭 클라우드와 같은 기술을 여럿 사용해 프라이빗 클라우드를 구축한다. 그렇지만 어떤 애플리케이션은 프라이빗으로도 퍼블릭으로도 옮기지 않는다.

Image Credit : GettyImagesBank

하이브리드 클라우드 환경에서 기업은 인프라를 자체적으로 운영하고 테넌시나 프로비저닝, 확장 등에서 클라우드의 기능 일부를 가져다 사용하고, 이후에 준비가 되면 퍼블릭이나 프라이빗 클라우드로 애플리케이션을 재배치할 수 있다. 실제로 일부 데이터나 서비스는 규제나 보안, 대역폭, 비용 등의 이유로 퍼블릭 클라우드로 보낼 수 없을지도 모른다.

또한, 하이브리드 클라우드의 점진적인 특성이 진정한 이점이 되는데, IT 부서가 클라우드를 조심스럽게 시험해 보고 필요하면 되돌릴 수도 있기 때문이다.

프라이빗이든 퍼블릭이든 클라우드를 시작하려면, 핵심 서비스를 이용할 수 있어야 하고, 무엇을 먼저 옮기고 어떤 것은 남겨둘 것인지를 정할 실현 가능한 전략이 있어야 한다.

하이브리드 클라우드에서 필요한 핵심 서비스
하이브리드 클라우드 전략이 제대로 작동하기 위해서는 온프레미스 데이터센터와 퍼블릭 클라우드 양쪽 모두에 세 가지 종류의 핵심 인프라 서비스가 있어야 한다.

1. 보안과 ID. 사용자를 인증하고 로컬과 클라우드 모두의 애플리케이션을 사용할 수 있는 권한을 부여할 방안이 있어야 한다. 특히 각 애플리케이션이 각각의 보안 환경을 만들어내지 않도록 중앙에서 관리할 수 있어야 한다.

2. 검색. 두 곳 모두에서 무엇인가를 찾아야 한다. 또한, 두 환경에 걸쳐서 무언가를 찾을 수 있는 검색 솔루션도 필요하다. 이때 중요한 것은 보안을 존중하는 것으로, 방화벽 뒤편의 데이터가 인터넷으로 나가면 안되기 때문이다. 참고로 필자는 검색 솔루션 전문업체 루시드웍스에서 일한다.

3. 코어 데이터. 물로 클라우드에도 데이터베이스가 있다. 하지만 모든 것이 RDBMS에 있지는 않다. 없으면 어떤 비즈니스 애플리케이션도 제대로 동작할 수 없는 핵심 기업 데이터 또한 애플리케이션이나 다른 저장소에 있다. 이런 데이터 일부는 이제 어떤 식으로든 클라우드에 있는데, 세일즈포스 같은 애플리케이션이 대표적이다. 하지만 그 외에도 클라우드에 두어야 할 데이터가 있다.

퍼블릭 클라우드로 옮겨야 하는 것
일반적으로 애플리케이션은 업데이트하기 전에는 클라우드로 옮기지 않는다. 이는 어떤 식으로든 이들 애플리케이션에 투자해야 한다는 의미이다. 업데이트가 이루어진 다음에 어떤 것을 클라우드로 옮길 것인지를 결정하려면, 다음 질문에 답해보기 바란다.

1. 비용이 얼마나 드는가? 애플리케이션을 클라우드로 이전하면 장비나 관리 비용을 절감할 수도 있다. 하지만 클라우드가 항상 더 저렴하다는 것은 잘못된 미신이다. 만약 해당 애플리케이션이 엄청난 CPU 성능을 필요로 하고 막대한 양의 데이터를 내놓으면서 24/7 동안 비교적 적은 사용자가 이용하고, 여기에 더해 업데이트할 일도 없고 확장도 절대로 하지 않는다면, 클라우드가 더 저렴한 시나리오는 생각하기 어렵다.

2. 애플리케이션의 아키텍처는? 현대적인 웹 기술을 기반으로 구축한 애플리케이션은 구식 아키텍처의 애플리케이션보다 이전하기가 더 쉽다. 구식 아키텍처를 클라우드를 염두에 두지 않았고, 그렇기 때문에 구식 애플리케이션을 클라우드에서 구동하려면 밑바닥부터 다시 작성해야 한다.

3. 지원 팀이 있는가? 만약 개발팀과 인프라 팀이 이전을 지원하지 않는다면, 매우 어려운 장애물이 있는 것이고, 실패할 가능성이 아주 크다.

4. 규제 문제는 없는가? 만약 규제를 준수해야 하거나 다양한 인증이 필요하다면, 클라우드 인프라를 이를 제공하는지 확실히 해야 한다. 이런 요구사항이 클라우드에서는 아주 복잡한 문제가 될 수 있다. 애플리케이션이나 데이터를 특정 국가에 두는 것이 허용되는가? 클라우드 서비스 업체가 제대로 된 자격이 있는가? 클라우드에 배치된 애플리케이션이 이런 요구사항을 만족하는가?

5. 의존성 문제는 없는가? 애플리케이션의 모든 의존성이 클라우드에서도 그대로인가?

6. 데이터를 어떻게 찾을 수 있는가? 만약 데이터를 클라우드로 이전한다면, 누군가 이 데이터를 찾을 수 있는가? 이를 어떻게 공개할 것인가? 어떻게 찾고 어떻게 내부 데이터로 보강할 것인가?

한편, 이런 고려사항은 프라이빗 클라우드로 이전할 때도 똑같이 적용된다. 어떤 경우, 규제 준수나 애플리케이션 의존성 문제는 프라이빗 클라우드로 이전하면 좀 더 쉽게 해결할 수도 있다. 하지만 프라이빗 클라우드 인프라는 기업이 자체적으로 보호하고 관리하고 운영하고 진화시켜야 한다. 어쨌든 자체 데이터센터이다.

전용 인프라에 그대로 남겨둘 것
어떤 애플리케이션은 그냥 클라우드나 하이브리드로 이전하지 않는다. 장기적으로는 새로운 애플리케이션을 찾는 방안을 생각해 볼 수 있겠지만, 단기적으로 다음과 같은 애플리케이션은 온프레미스에 원래대로 두고자 할 것이다.

- 극히 안정적이고 정적인 애플리케이션. 업데이트하지 않으면서 계속 사용하고 매우 안정적인 애플리케이션이 있다면, 긁어 부스럼을 만들 필요는 없다.

- 웹 방식이 아닌 애플리케이션. 1990년대 초반에 작성된 분산 컴퓨팅 환경의 괴물이라 모든 것이 고정된 주소를 갖는다면? 아마도 4GL 데스크톱 애플리케이션으로 터미널 서비스가 필요할 것이다. 웹 이전 시대, 클라우드 이전 아키텍처와 기술을 사용하는 어떤 애플리케이션도 클라우드로 이전하기 어렵다. 확장도 어렵다. 다른 후보자를 찾아보기 바란다.

- 높은 의존성. 만약 해당 애플리케이션이 아직 클라우드를 지원하지 않는 수많은 요소에 의존하고 있다면, 나중으로 미루기 바란다.  editor@itworld.co.kr

X