2010.04.23

[글로벌 칼럼] 클라우드 컴퓨팅과 호스팅 2.0은 다르다

Bernard Golden | CIO

지난 수 주 동안 아마존의 클라우드 인프라에 애플리케이션을 설치했다가 문제에 부딪힌 몇몇 기업들의 연락을 받았다. 다음과 같은 문제들이었다.

 

- AMI(Amazon Machine Image) 상에 애플리케이션이 설치되어 잘 구동되었으나 EC2 인스턴스(Instance)가 고장 나거나 종료시켜야 할 상태가 되면, 새 인스턴스가 온라인이 될 때까지는 그 애플리케이션을 쓸 수 없게 된다.

- EC2 인스턴스에 과부하가 걸리면, 애플리케이션 성능 개선을 위해 더 많은 자원을 추가시킬 방법이 없다.

- 애플리케이션을 완전히 오프라인으로 만들기 전에는 해당 애플리케이션을 업데이트할 방법이 없다.

- 데이터베이스에 의해 성능에 병목현상이 발생해도, 데이터베이스 복제(Replication)로 이동을 처리할 수 있는 방법이 없다.

 

이들 기업과의 협의 과정에서 다음과 같은 질문이 공통적으로 생겨났다.

 

"이 문제는 클라우드 컴퓨팅에서 해결해야 하는 것이 당연하게 아닌가? 결국, 자원의 탄력성, 주문형 처리 능력, 엄청난 확장성을 제공하는 주체는 클라우드인데, 왜 내 애플리케이션이 이런 문제에 부딪혀야 하는가?"

 

이 회사들이 직면한 과제는 클라우드 컴퓨팅을 호스팅 2.0처럼 취급했기 때문이며, 그 결과 상응하는 대가를 치르고 있는 것이다.

 

클라우드 확장성과 애플리케이션 확장성

이에 대한 간단한 응답은 "클라우드 확장성과 애플리케이션 확장성은 같은 것이 아니므로, 클라우드 애플리케이션을 설계하지 않는 한 클라우드 컴퓨팅의 이점들을 얻을 수 없을 것이다. 우리는 이를 "애플리케이션을 클라우드에 설치하지 말고, 클라우드용 애플리케이션을 구축하라"라는 문구로 표현한다.

 

그렇다면 "클라우드 애플리케이션 구축"은 어떤 의미이며, 클라우드를 호스팅 2.0처럼 취급하는 것과는 어떻게 다른가?

 

다음은 클라우드 애플리케이션 구축에 관한 핵심 원칙이다:

 

- 각각의 컴퓨팅 자원은 장애 소지가 있으며, 실제로도 장애를 일으킨다는 점을 인정하라. 아마존에서, 각 EC2 인스턴스는 때로 성능 저하, 응답 불능 또는 고장이 날 것이다. 그리고 이런 일은 모든 클라우드 공급업체에서 발생한다. 구글은 무방비로 노출된 메인보드(구글의 머신에는 금속 케이스가 없다) 상에 (글자 그대로) 연결된 디스크 드라이브를 장착한 극히 저렴한 컴퓨터를 구축한다는 철학으로 유명하다; 컴퓨터 중 한 대가 망가지면, 구글은 그것을 분리해서 재활용한다. 수백만 대의 머신을 운영하다 보면, 장애는 흔한 일이므로 구글은 자원에 장애가 발생해도 견고함을 유지하도록 솔루션들을 설계한다. 그와 마찬가지로, 클라우드 환경에서 구동하는 각각의 애플리케이션도 마치 (가상 머신을 포함하여) 각 자원들이 장애를 일으킬 수 있다는 것을 전제로 설계해야만 한다. 그러므로 최소한 두 개의 EC2 인스턴스 상에서 구동할 수 있도록 애플리케이션을 작성해야 한다.

 

- 장애 가능성은 애플리케이션이 최소 2개의 EC2 인스턴스 상에서 구동해야만 한다는 의미임을 이해하라. 이는 애플리케이션 파일들이 양쪽 가상머신 상에 있거나 두 가상 머신이 액세스할 수 있는 중앙 위치에 있어야 함을 의미한다. 이는 모든 애플리케이션이 자체 인스턴스와 분리되어야 한다는 의미는 아니다. 하나의 EC2 인스턴스가 여러 개의 애플리케이션을 지원할 수 있다. 예를 들면, 하나의 인스턴스가 여러 개의 상이한 웹 사이트를 호스팅할 수 있다. 다시 말해 각 애플리케이션이 여러 인스턴스에 확장될 수 있도록 작성되어야만 한다는 의미이다.

 

- 세션 관리를 적절하게 처리할 수 있도록 애플리케이션을 작성하라. 이는 세션 밀접성(Session Affinity)을 가령, 애플리케이션 앞에 위치하고 있는 로드밸런서(Load Balancer)에서 처리하거나 애플리케이션 자체가 세션 정보를 공유 위치에 놓는 것을 의미한다. 물론 세션 정보를 여러 애플리케이션 서버가 공유하는 데이터베이스에 저장하는 방식으로 구현할 수도 있다. 하지만, 이 방법은 데이터베이스 서버에 대한 부하로 병목현상을 초래할 수도 있다. 이 문제에 대한 일반적인 해결책은 세션 정보를 더 나은 성능을 제공하는 고성능 분산 메모리 시스템인 Memcached 계층으로 옮기는 것이다. 어떤 경우에도, 세션 정보는 애플리케이션의 어떤 부분에서 요구할 지라도 반드시 사용할 수 있게 해주어야 한다.

 

- 추가 컴퓨팅 자원이 애플리케이션에 동적으로 자연스럽게 연결되고 끊어질 수 있게 보장 해주어야 한다. 클라우드를 사용하는 한 가지 중요한 이유는 애플리케이션이 필요한 자원에 동적으로 액세스할 수 있게 해 부하에 따라 자원 양을 조절할 수 있기 때문이다. 자원의 추가나 제거를 위해 사람의 개입이 필요해지면, 병목이 컴퓨팅 자원에서 인적 자원으로 이동하기 때문에 바람직하지 않다. 자원 수준이 동적으로 달라지도록 애플리케이션이 작성되지 않으면, 누군가가 고정된 자원을 할당해 주어야만 한다. 이렇게 되면, 가용성과 투자 즉, 돈을 버릴 것인가 사용자를 버릴 것인가라는 과거의 상충요소로 되돌아가는 결과를 유발한다.

 

동적 애플리케이션 서버 구성의 어려움

필자가 "클라우드 애플리케이션"으로의 이전을 쉬운 일이라고 생각하는 것이 아니다. 사람의 개입 없이 동적으로 확장하는 애플리케이션 작성은 사소한 일이 아니다. 우선 한 가지 이유는 대부분의 소프트웨어 구성요소가 자동이 아니라 수작업 관리를 전제로 하고 있어서 "구성 파일을 업데이트 한 다음, 서버를 재가동 시키시오"라는 접근 방식을 따르고 있다. 상당히 정적인 애플리케이션 서버 구성에서는 문제가 없으나 동적으로 변하는 애플리케이션 서버 구성에서는 심각한 문제이다.

 

또 다른 문제는 한 애플리케이션의 여러 사본이 공통적으로 사용하는 파일과 객체(Object) 처리 방법을 결정하는 것이다. 네트워크 파일 시스템에 저장할 수도 있으나, 흔히 성능 문제가 발생한다. SAN이나 NAS 유형의 기능을 지원하는 클라우드 환경에서는 파일들을 중앙에 저장할 수도 있으나, 지연 편차(Latency)문제가 발생할 수도 있다.

 

파일 사본을 각 서버마다 저장하면, 분산과 버전 관리라는 문제가 발생할 수 있다. 최상의 방법은 모든 파일을 중앙 위치(즉, 아마존 기반의 애플리케이션인 경우, S3)에 저장하고, 가상머신이 "공식" 파일을 다운로드해 인스턴스를 만들 때 스스로 설치하게 하는 것이다. 다시 말하지만, 이는 약간 특이한 방법으로 정적인 환경에서는 흔치 않다. 대부분의 환경에서 일반적인 방법은 하드웨어(그리고 가상머신)의 견고성만 강조하고 동적 애플리케이션 서버 구성은 계획하지 않는다.

 

정확하게 어느 정도의 애플리케이션이 부하에 따른 동적 서버 구성을 필요로 할지에 대해서는 명확하지 않다. 그러므로 모든 애플리케이션이 "클라우드 애플리케이션"일 필요가 없을지도 모른다. 반면에, 애플리케이션의 전 생애 동안 어느 정도의 부하가 걸릴지를 예측하기는 어려운 일이다. 2010년 4월 12일 밤 해커 도조(Hacker Dojo)의 발표에서 NASA 네뷸러(Nebular) 클라우드 프로젝트의 책임 아키텍트인 조쉬 맥켄티(Josh NcKenty)는 NASA 애플리케이션은 특이한 사용자 부하를 자주 갖곤 했다고 지적했다.

 

수 년 동안 트래픽이 없다가, 특정 미션이 극적인 무엇인가를 하면(맥켄티가 예로 든 것은 물을 찾기 위해 달에 착륙한 프로젝트) 하루 이틀 정도의 짧은 기간 동안 엄청난 트래픽이 발생한다는 것이다.

 

종착점은 “클라우드 애플리케이션”

미래의 애플리케이션에서는 점점 더 일반화될 부하의 예측 불가능성과 특이한 부하 패턴 때문에, 동적 애플리케이션 작성과 관련된 디자인 패턴은 궁극적으로 표준 관행이 될 것이다. 다시 말해 모든 애플리케이션은 고도로 동적인 부하에 대해 견고함을 유지하도록 작성될 것이다.

 

이런 유형의 부하를 감내하는 애플리케이션은 말하자면, 대응 준비가 된 것이다. 이런 부하를 견뎌낼 수 없는 애플리케이션은 그런 기능이 확보해야만 하고, 발휘되지는 않았지만 만일의 사태에 대비해서 꼭 필요하게 될 것이다.

 

지금 설계되고 작성되는 애플리케이션은 수 년 동안 사용될 것이고 십중팔구는 클라우드 환경에서 구동하게 될 것이므로, 아키텍트와 소프트웨어 엔지니어들이 이런 설계 패턴을 지금 배우는 것이 중요하다. 이는 현재 계획에는 클라우드 환경에서 운영될 필요가 없더라도, "클라우드 애플리케이션"을 전제로 작성되어야 함을 의미한다.  editor@idg.co.kr



2010.04.23

[글로벌 칼럼] 클라우드 컴퓨팅과 호스팅 2.0은 다르다

Bernard Golden | CIO

지난 수 주 동안 아마존의 클라우드 인프라에 애플리케이션을 설치했다가 문제에 부딪힌 몇몇 기업들의 연락을 받았다. 다음과 같은 문제들이었다.

 

- AMI(Amazon Machine Image) 상에 애플리케이션이 설치되어 잘 구동되었으나 EC2 인스턴스(Instance)가 고장 나거나 종료시켜야 할 상태가 되면, 새 인스턴스가 온라인이 될 때까지는 그 애플리케이션을 쓸 수 없게 된다.

- EC2 인스턴스에 과부하가 걸리면, 애플리케이션 성능 개선을 위해 더 많은 자원을 추가시킬 방법이 없다.

- 애플리케이션을 완전히 오프라인으로 만들기 전에는 해당 애플리케이션을 업데이트할 방법이 없다.

- 데이터베이스에 의해 성능에 병목현상이 발생해도, 데이터베이스 복제(Replication)로 이동을 처리할 수 있는 방법이 없다.

 

이들 기업과의 협의 과정에서 다음과 같은 질문이 공통적으로 생겨났다.

 

"이 문제는 클라우드 컴퓨팅에서 해결해야 하는 것이 당연하게 아닌가? 결국, 자원의 탄력성, 주문형 처리 능력, 엄청난 확장성을 제공하는 주체는 클라우드인데, 왜 내 애플리케이션이 이런 문제에 부딪혀야 하는가?"

 

이 회사들이 직면한 과제는 클라우드 컴퓨팅을 호스팅 2.0처럼 취급했기 때문이며, 그 결과 상응하는 대가를 치르고 있는 것이다.

 

클라우드 확장성과 애플리케이션 확장성

이에 대한 간단한 응답은 "클라우드 확장성과 애플리케이션 확장성은 같은 것이 아니므로, 클라우드 애플리케이션을 설계하지 않는 한 클라우드 컴퓨팅의 이점들을 얻을 수 없을 것이다. 우리는 이를 "애플리케이션을 클라우드에 설치하지 말고, 클라우드용 애플리케이션을 구축하라"라는 문구로 표현한다.

 

그렇다면 "클라우드 애플리케이션 구축"은 어떤 의미이며, 클라우드를 호스팅 2.0처럼 취급하는 것과는 어떻게 다른가?

 

다음은 클라우드 애플리케이션 구축에 관한 핵심 원칙이다:

 

- 각각의 컴퓨팅 자원은 장애 소지가 있으며, 실제로도 장애를 일으킨다는 점을 인정하라. 아마존에서, 각 EC2 인스턴스는 때로 성능 저하, 응답 불능 또는 고장이 날 것이다. 그리고 이런 일은 모든 클라우드 공급업체에서 발생한다. 구글은 무방비로 노출된 메인보드(구글의 머신에는 금속 케이스가 없다) 상에 (글자 그대로) 연결된 디스크 드라이브를 장착한 극히 저렴한 컴퓨터를 구축한다는 철학으로 유명하다; 컴퓨터 중 한 대가 망가지면, 구글은 그것을 분리해서 재활용한다. 수백만 대의 머신을 운영하다 보면, 장애는 흔한 일이므로 구글은 자원에 장애가 발생해도 견고함을 유지하도록 솔루션들을 설계한다. 그와 마찬가지로, 클라우드 환경에서 구동하는 각각의 애플리케이션도 마치 (가상 머신을 포함하여) 각 자원들이 장애를 일으킬 수 있다는 것을 전제로 설계해야만 한다. 그러므로 최소한 두 개의 EC2 인스턴스 상에서 구동할 수 있도록 애플리케이션을 작성해야 한다.

 

- 장애 가능성은 애플리케이션이 최소 2개의 EC2 인스턴스 상에서 구동해야만 한다는 의미임을 이해하라. 이는 애플리케이션 파일들이 양쪽 가상머신 상에 있거나 두 가상 머신이 액세스할 수 있는 중앙 위치에 있어야 함을 의미한다. 이는 모든 애플리케이션이 자체 인스턴스와 분리되어야 한다는 의미는 아니다. 하나의 EC2 인스턴스가 여러 개의 애플리케이션을 지원할 수 있다. 예를 들면, 하나의 인스턴스가 여러 개의 상이한 웹 사이트를 호스팅할 수 있다. 다시 말해 각 애플리케이션이 여러 인스턴스에 확장될 수 있도록 작성되어야만 한다는 의미이다.

 

- 세션 관리를 적절하게 처리할 수 있도록 애플리케이션을 작성하라. 이는 세션 밀접성(Session Affinity)을 가령, 애플리케이션 앞에 위치하고 있는 로드밸런서(Load Balancer)에서 처리하거나 애플리케이션 자체가 세션 정보를 공유 위치에 놓는 것을 의미한다. 물론 세션 정보를 여러 애플리케이션 서버가 공유하는 데이터베이스에 저장하는 방식으로 구현할 수도 있다. 하지만, 이 방법은 데이터베이스 서버에 대한 부하로 병목현상을 초래할 수도 있다. 이 문제에 대한 일반적인 해결책은 세션 정보를 더 나은 성능을 제공하는 고성능 분산 메모리 시스템인 Memcached 계층으로 옮기는 것이다. 어떤 경우에도, 세션 정보는 애플리케이션의 어떤 부분에서 요구할 지라도 반드시 사용할 수 있게 해주어야 한다.

 

- 추가 컴퓨팅 자원이 애플리케이션에 동적으로 자연스럽게 연결되고 끊어질 수 있게 보장 해주어야 한다. 클라우드를 사용하는 한 가지 중요한 이유는 애플리케이션이 필요한 자원에 동적으로 액세스할 수 있게 해 부하에 따라 자원 양을 조절할 수 있기 때문이다. 자원의 추가나 제거를 위해 사람의 개입이 필요해지면, 병목이 컴퓨팅 자원에서 인적 자원으로 이동하기 때문에 바람직하지 않다. 자원 수준이 동적으로 달라지도록 애플리케이션이 작성되지 않으면, 누군가가 고정된 자원을 할당해 주어야만 한다. 이렇게 되면, 가용성과 투자 즉, 돈을 버릴 것인가 사용자를 버릴 것인가라는 과거의 상충요소로 되돌아가는 결과를 유발한다.

 

동적 애플리케이션 서버 구성의 어려움

필자가 "클라우드 애플리케이션"으로의 이전을 쉬운 일이라고 생각하는 것이 아니다. 사람의 개입 없이 동적으로 확장하는 애플리케이션 작성은 사소한 일이 아니다. 우선 한 가지 이유는 대부분의 소프트웨어 구성요소가 자동이 아니라 수작업 관리를 전제로 하고 있어서 "구성 파일을 업데이트 한 다음, 서버를 재가동 시키시오"라는 접근 방식을 따르고 있다. 상당히 정적인 애플리케이션 서버 구성에서는 문제가 없으나 동적으로 변하는 애플리케이션 서버 구성에서는 심각한 문제이다.

 

또 다른 문제는 한 애플리케이션의 여러 사본이 공통적으로 사용하는 파일과 객체(Object) 처리 방법을 결정하는 것이다. 네트워크 파일 시스템에 저장할 수도 있으나, 흔히 성능 문제가 발생한다. SAN이나 NAS 유형의 기능을 지원하는 클라우드 환경에서는 파일들을 중앙에 저장할 수도 있으나, 지연 편차(Latency)문제가 발생할 수도 있다.

 

파일 사본을 각 서버마다 저장하면, 분산과 버전 관리라는 문제가 발생할 수 있다. 최상의 방법은 모든 파일을 중앙 위치(즉, 아마존 기반의 애플리케이션인 경우, S3)에 저장하고, 가상머신이 "공식" 파일을 다운로드해 인스턴스를 만들 때 스스로 설치하게 하는 것이다. 다시 말하지만, 이는 약간 특이한 방법으로 정적인 환경에서는 흔치 않다. 대부분의 환경에서 일반적인 방법은 하드웨어(그리고 가상머신)의 견고성만 강조하고 동적 애플리케이션 서버 구성은 계획하지 않는다.

 

정확하게 어느 정도의 애플리케이션이 부하에 따른 동적 서버 구성을 필요로 할지에 대해서는 명확하지 않다. 그러므로 모든 애플리케이션이 "클라우드 애플리케이션"일 필요가 없을지도 모른다. 반면에, 애플리케이션의 전 생애 동안 어느 정도의 부하가 걸릴지를 예측하기는 어려운 일이다. 2010년 4월 12일 밤 해커 도조(Hacker Dojo)의 발표에서 NASA 네뷸러(Nebular) 클라우드 프로젝트의 책임 아키텍트인 조쉬 맥켄티(Josh NcKenty)는 NASA 애플리케이션은 특이한 사용자 부하를 자주 갖곤 했다고 지적했다.

 

수 년 동안 트래픽이 없다가, 특정 미션이 극적인 무엇인가를 하면(맥켄티가 예로 든 것은 물을 찾기 위해 달에 착륙한 프로젝트) 하루 이틀 정도의 짧은 기간 동안 엄청난 트래픽이 발생한다는 것이다.

 

종착점은 “클라우드 애플리케이션”

미래의 애플리케이션에서는 점점 더 일반화될 부하의 예측 불가능성과 특이한 부하 패턴 때문에, 동적 애플리케이션 작성과 관련된 디자인 패턴은 궁극적으로 표준 관행이 될 것이다. 다시 말해 모든 애플리케이션은 고도로 동적인 부하에 대해 견고함을 유지하도록 작성될 것이다.

 

이런 유형의 부하를 감내하는 애플리케이션은 말하자면, 대응 준비가 된 것이다. 이런 부하를 견뎌낼 수 없는 애플리케이션은 그런 기능이 확보해야만 하고, 발휘되지는 않았지만 만일의 사태에 대비해서 꼭 필요하게 될 것이다.

 

지금 설계되고 작성되는 애플리케이션은 수 년 동안 사용될 것이고 십중팔구는 클라우드 환경에서 구동하게 될 것이므로, 아키텍트와 소프트웨어 엔지니어들이 이런 설계 패턴을 지금 배우는 것이 중요하다. 이는 현재 계획에는 클라우드 환경에서 운영될 필요가 없더라도, "클라우드 애플리케이션"을 전제로 작성되어야 함을 의미한다.  editor@idg.co.kr



X