메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

IT/모바일

클라우드 컴퓨팅 환경에서 자동조정 방식을 좋아하지 않는 이유

한빛미디어

|

2009-07-06

|

by HANBIT

10,562

제공 : 한빛 네트워크
저자 : George Reese
역자 : 강상진
원문 : On Why I Don"t Like Auto-Scaling in the Cloud

나는 얼마 전 트위터(Twitter)에서 열띤 토론에 참가한 적이 있다(클릭). 영업회의에서 만난 고객에게 동적조정 방식에 대해 열정적으로 알려 줌으로서 자동조정 방식에 대한 그들의 사고방식을 바꿀 수 있었다. 난 자동조정 방식을 별로 좋아하지 않는다.

자동조정(Auto Scaling) 방식 이란 무엇인가?

자동조정 이란 클라우드 컴퓨팅 구조를 가진 인프라의 실제 사용량에 비례하게 시스템 용량을 추가하거나 줄이는 기능을 의미한다. (주로 enStratus - 올해 말 기능 제한된 베타버전 예정 -와 같은 클라우드 컴퓨팅 인프라 관리도구를 사용한다.)- 이 과정에서 사람의 부수적인 작업은 필요하지 않다. 이것은 아주 대단한 기능이다! - 웹 사이트에서의 더 이상의 시스템 부하는 없게 될 테니까. 당신의 사이트를 클라우드 구조화 시킨다면 안전하다. 당신은 그저 당신이 사용하는 만큼에 대해 대가만을 치르면 되는 것이다. 그렇지만 나는 자동조정 방식을 썩 좋아하지는 않는다.

동적조정(Dynamic Scaling) 방식 이란 무엇인가?

자동조정은 동적조정에 비해 클라우드 컴퓨팅 구조에서의 중요한 기능에 대해서 장점을 가지고 있다. 동적조정은 클라우드 구조에 필요한 용량을 필요에 따라 관리자가 고의적으로 추가하거나 줄이는 기능을 수행한다. - 이상적으로, 당신은 이미 당신의 트래픽 패턴이 변화될 것이라는 사실을 알고 있으며 그에 맞게 작업을 하게 된다. 나는 동적조정 방식을 좋아한다.

용량산정

만약 어플리케이션의 용량에 대한 고려를 한다면 - 그것이 클라우드 방식, 호스팅 방식 혹은 내부방식이든.. - 용량산정 방식에 대한 정확한 이해가 필요하다. 만약 이해가 부족하다면, John Allspaw의 The Art of Capacity Planning을 읽어보길 권장한다.

간단히 말해서 용량산정이란 시스템내의 트래픽 패턴을 잘 알고 있는지, 어떤 주기로 패턴들이 변경되고 있는지, 얼마나 더 늘어날지 그리고 어떤 구조를 준비해야 이러한 트래픽 패턴을 대비할 수 있는지 알아내는 과정이다. 알맞은 용량 산정 없이 어떤 종류의 인프라도 설계하기 어려울뿐더러, 비용을 과다지출 하고, 사이트가 멈추거나 불필요한 돈이 낭비된다.

정확한 용량산정이 용량과 수요의 조합을 통해 인프라 구축비용을 제한하여 조직에게 이익을 가져다 줄 수 있다는 관점에서 볼 때 용량산정은 매우 중요한 작업이라 할 수 있다.

예를 들어보자, 당신은 한 대의 서버가 처리 할 수 있는 평균적인 수요를 알고 있다. 만약 1년 중에 오로지 1시간 동안만 10대의 서버가 필요하다면, 클라우드 컴퓨팅 환경을 구축한다고 할지라도 한 시간 수요를 위한 고객과의 미팅을 합리화 하지 못할 것 이다. 다시 말해서, 클라우드 환경은 비용 대비 효과적인 수요공급에 대한 도구 일뿐이거나, 그 한 시간이 당신의 사업에서 매우 중요하여 나머지 시간들을 무의미하게 만들 수도 있을 것이다.

알맞은 용량산정 없이는 트래픽 패턴 자체의 분석이 어려울 뿐만 아니라 이러한 트래픽 패턴 지원을 위한 어떠한 추기 비용이 필요한지 조차 파악하기 어렵다.

자동조정 방식을 쓴다고 용량산정을 안 해도 될까?

그렇지 않다. 단순한 생각 외에 것들을 생각해 보자. 대부분의 업무영역에서 자동조정은 용량 산정을 게을리 하는 사람들을 위한 버팀목 역할만을 한다. 사실, 사이트를 자동조정 방식을 사용하여 따로 관리자를 두지 않고 최대 용량 제한만을 설정하여 구성한다면, 그 사이트는 다운되지는 않겠지만, 예상 못했던 용량의 한계에 다다른다면 그러한 구조의 시스템은 기본 구성으로 돌아가게 된다.

아래 내용은 이 방식이 왜 올바르지 않는지 보여준다.
  1. Amazon과 그 외 클라우드 시스템은 용량 증대를 위한 반응 속도가 빠르지 않다.

    Amazon EC2 인스턴스가 실행되기 위해서는 10분의 시간이 필요하다. 그 10분의 시간은 클라우드 인프라 관리도구가 추가용량 필요성을 파악하고 추가된 용량이 사용 가능하게끔 만드는데 필요한 시간이다. 이 10분 동안(어쩌면 더 많은 시간 동안) 고객은 불완전한 사이트의 성능에 불만을 가질 수 있다.

    아무튼, Amazon S3도, Amazon의 클라우드 시스템에 꼭 알맞게 안정적인지는 스스로도 증명하지 못했다. 중요한 업무환경에서 적시에 필요 용량을 증설하는 것은 불가능하다는 것을 알 수 있다.

    대부분의 용량 변화는 예상할 수 있다. 과거에 이러한 용량 산정 경험이 있다면 다음 2가지의 장점을 가질 수 있다.
    • 용량 추가가 필요한 시점이전에 용량 추가가 가능하다. 이 경우 필요한 만큼의 용량이 제때에 공급될 수 있다는 것이 보증 되어야 한다.
    • Amazon S3 시스템의 어떠한 운영결함이라도 발생한다면 그 결함들이 사이트 운영에 더 큰 해가 되기 전에 발견되어야 한다. (또한 대응책을 찾아 상황을 응대할 수 있어야 한다.)
  2. 불만이 가득한 직원들, 만족하지 않는 고객 혹은 악의에 찬 경쟁자들이 있는가?

    망하는 지름길은 간단하다. 자동조정 방식을 사용하고 관리자 없이 최대치 용량만 지정해 둔다. 지나가던 방문객이 DDoS(Distributed Denial of Service) 공격으로 당신의 시스템을 공격할 수 있을 것이다. 이 공격이 즉시 시스템을 파괴하지는 않는다. 왜냐면 클라우드 구조의 시스템은 이러한 공격을 확실이 방어할 수 있을 테니까. 다만 더욱 더 많은 서버를 인프라에 구축하다 보면 파산 될 수 있다.

  3. 그래서, 관리자를 각 필요한 위치에 배치한다면……

    자동조정 시스템에서는 관리자 없이 시스템을 운영하지는 않는다. 그러나 그 관리자들이 원하는 만큼의 일을 모두 하는 것은 아니다. 한두 가지 예를 들자면..
    • 지금까지 계획한 용량 수요가 실제로 자동조정 시스템에서 필요 없게 된 경우.
    • 계획이 불가능했던 용량 수요. 그래서 해당 트래픽에 적합한 관리자 수준이 어느 정도인지 예상할 수 없는 경우.
  4. 시스템이 다운되는 현상은 어떠한가?

    때때로 트래픽은 정말 예상하기 어렵지만 그러한 경우는 생각만큼 자주 발생하지는 않는다. 출판의 예를 들어, 만약 책의 판매부수가 어느 정도 되었다면 마케팅 팀은 ROI를 따져서 판매행사를 준비했을 테고 저자에게 더 많은 인세를 줄 수 있을 것이다.

    하지만 당신이 어떤 시스템의 충분한 용량을 안다고 해도 가끔씩 예외상황이 있다. 시스템 다운과 같은 현상이 갑자기 발생할 수 있기 때문에, 당신은 정말로 당신의 사이트에서의 예상하지 못한 트래픽을 대비할 수 있게 스케일링을 해야 한다.

    그렇지만, 당신은 오토 스케일 방식을 원하지 않는다. 자동조정은 정상적인 트래픽과 비정상적인 트래픽을 구분할 수 없다. 그렇지만 사람은 가능하다. 만약 당신의 환경이 갑자기 사용량이 증가한다면 필요한 조치는 최소한의 자동조정 방식과 관리자를 제자리에 배치하는 것이다. 그리고 클라우드 컴퓨팅 관리도구에서의 메시지를 확인하고, 시스템의 응답이 어떻게 흘러갈지를 결정해야 한다.

    그래서, 자동조정은 관리자가 동적조정을 사용하여 필요한 만큼의 정확하고 임시변통이 가능한 용량을 알아내어 예상치 못한 수요에 대비하는데 필요한 미봉책에 지나지 않는다.

  5. 자동조정 없이 클라우드 컴퓨팅을 구현하는 것이 맞는지?

    만약 동적조정이 적절히 사용한다면, 그것은 정확히 필요한 만큼의 용량을 사용하는 것이다. 용량이 더 필요하게 되면 추가하면 된다. 용량을 추가할 때는 외부에서 발생한 이벤트에 따라 무질서하게 추가하는 것이 아니라 올바른 추가계획을 사용한다.

    동적조정 방식의 계획은 만드는 것은 자동화가 가능하다. 만약 자정 12시부터 오전 3시까지 작동하는 배치파일이 윈도우 내에 있다면, 클라우드 컴퓨팅 관리도구를 사용하여 용량 추가를 미리 하는 작업을 11시 30분부터 3시 30분까지 작동할 수 있도록 설정한다. 이러한 작업은 단순히 사용량에 따른 용량을 자동적으로 조절하는 기능을 원하지 않을 때 사용한다.
번역자 주)
enStratus: 저자인 George가 대표로 있는 enStratus Networks LLC 사에서 개발한 클라우드 컴퓨팅 환경의 인프라 관리도구

클라우드 컴퓨팅: 정보가 인터넷 상의 서버에 영구적으로 저장되고 PC같은 클라이언트에는 일시적으로 보관되는 패러다임이다. 예로서 Google Apps가 있다. 웹 브라우저로 이용할 수 있는 일반적인 비즈니스 응용프로그램들을 온라인으로 제공한다. 소프트웨어와 데이터는 서버에 저장된다.

Amazon EC2: Amazon Elastic Compute Cloud의 약자로, Amazon Web Services사에서 제공하는 클라우드 컴퓨팅 기반 웹 서비스로, S3 와 메시지 검색, 전자상거래 같은 서비스와 연계하여 작동된다.

Amazon S3: Amazon EC2에서 제공하는 Simple Storage Service의 약자로서, 온라인 기반의 스토리지 웹 서비스이다.
TAG :
댓글 입력
자료실