임계값 정책은 클라우드 환경에서 요구되는 중요한 속성이다. 워크로드 수요가 사전에 결정된 임계값 레벨에 도달하여 워크로드 수요를 동적으로 조정해야 하는 경우에는 이 정책을 사용하여 자원을 확인하고 관리한다. 이 정책에서는 임계값 레벨을 초과한 워크로드 수요의 양에 따라 시스템이 필수 자원의 인스턴스를 작성하게 한다.

임계값 정책을 설정하고 사용하여 자원 인스턴스를 자동으로 작성하고 릴리스함으로써 워크로드 수요를 동적으로 조정하는 데 필요한 고려사항을 더 자세히 살펴보기 전에 이러한 컨텍스트에서 임계값 정책을 정의해 보자.

임계값 정책 개요

임계값 정책의 몇 가지 주요 속성을 살펴보자.

응답 시간

시스템이 임계값 레벨에 도달한 워크로드 수요를 발견하는 시간과 시스템이 추가 자원 인스턴스를 작성하는 시간 사이의 응답 기간은 가능한 짧아야 한다. 워크로드 수요가 임계값 레벨 아래 지점으로 돌아가면 시스템은 이러한 자원을 할당 해제하여 다른 용도로 사용한다.

크게 영향을 주는 고려사항

임계값 정책에 있어야 하는 정보는 다음 사항에 영향을 받는다.

• 소비자가 임대하는 클라우드 서비스 유형
• 소비자가 운영 체제, 하드웨어 및 소프트웨어를 제어할 수 있는 정도
• 소비자가 속해 있는 산업 유형(예: 소매, 에너지와 유틸리티, 금융시장, 건강관리 및 석유화학)

서비스 제공자와 정책

클라우드 서비스 제공자가 조직에서 제어하는 데이터 센터의 내부에 있거나 IBM®과 같은 전자통신 산업의 멤버가 외부에서 호스트할 수도 있다. 클라우드 서비스 제공자는 프로비저닝, 계량, 평가 및 청구, 결재 및 기타 기능을 통해 소비자 활동과 트랜잭션을 지원할 수 있게 이러한 기능과 사무관리 시스템의 통합을 보장해야 한다.

임계값 정책을 적용하는 방법

하나의 사례로서 소매 산업의 클라우드 서비스 소비자가 클라우드에서 신용카드의 유효성 검증을 수행하는 대규모의 애플리케이션을 데이터 센터에 갖추고 있었지만, 워크로드 수요는 임계값 레벨 아래에 있었다. 크리스마스 쇼핑 시즌에 자원 부족이 최고치에 이르자 워크로드 수요가 임계값을 초과한다는 사실을 시스템이 발견했다. 이에 대응하여 시스템은 추가로 자원 인스턴스를 신속하게 작성하여 워크로드 수요를 동적으로 조정하였다.

소매 상인이 구매하는 시기가 지나자 워크로드 수요는 임계값 아래로 떨어졌으며 클라우드에서 작성된 자원 인스턴스는 지정이 해제되었다. 조직에는 하드웨어를 제어할 수 있는 권한이 일부 있기 때문에 임계값 정책의 조항 설정에 관해 클라우드 서비스 제공자와 협상할 수 있다. (자원이 부족하기 전에 정책 매개변수를 협상하는 것이 언제나 유익하다.)

이 기사의 나머지 부분에서는 클라우드 서비스 유형에 대한 몇 가지 배경 지식을 설명하고 클라우드 유형 간의 임계값 정책의 차이점을 살펴본다. 또한, 애플리케이션 테스트, 프로덕션 및 용량 계획을 위한 자원 관리 임계값 정책을 검토하고 SLA(Service Level Agreement)에 대한 임계값 정책의 영향과 같이 더욱 중요하게 고려해야 할 문제점을 몇 가지 살펴본다.

위로

클라우드 서비스 유형

먼저 다음과 같은 세 가지 클라우드 서비스 유형 중 어느 것이 자신의 요구에 적합한지 고려한다.

• SaaS(Software as a Service)
• PaaS(Platform as a Service)
• IaaS(Infrastructure as a Service)

또한, 이 기사에서는 클라우드 서비스 유형을 공용이나 사설 중 어느 것으로 하는 것이 최선의 선택인지 결정하는 데 운영 규모가 어떻게 영향을 줄 수 있는지 검토한다.

SaaS(Software as a Service)

온디맨드 서비스로서 웹에서 사용할 애플리케이션을 실행할 회사를 위해 소매 산업의 소비자인 사용자가 SaaS 제공자로부터 라이센스를 받았다고 가정하자. 사용자는 하드웨어나 소프트웨어를 구입하여 설치하고 유지보수하거나 애플리케이션을 업데이트하지 않아도 되기 때문에 등록 방식이나 선불제 방식을 선택한다.

사용자가 제어할 수 있는 것은 데스크탑이나 모바일 장치에서 서비스 제공자의 애플리케이션을 사용하여, 컴퓨터로 처리되는 결재 및 대금 청구 그리고 인적 자원 관리와 같은 비즈니스 태스크를 처리하는 것뿐이다.

사용자가 배치된 애플리케이션나 운영 체제, 스토리지, 네트워킹을 제어하지 못한다고 하더라도 계획되었거나 예상하지 못한 워크로드 수요가 갑자기 늘어나는 경우에는 자원 관리에 대한 서비스 제공자의 임계값 정책을 직접 확인해야 한다.

• 사용자는 서비스 제공자가 SaaS의 운영상의 가용성을 계속해서 보장하기 위해 임계값 레벨을 어떻게 설정하는지 알고 싶어한다.
• 사용자는 서비스 제공자의 SLA 조항과 백업 정책이 무엇인지 확인하고 싶어한다.
• 서비스 제공자가 갑작스런 수요 증가를 동적으로 처리하지 못했기 때문에 서비스에 장애가 발생하는 경우, 사용자는 SLA에 제시된 대로 크레딧을 받거나, 환불을 받거나, 무료 사용 기간을 제공 받거나 SaaS를 해지할 수 있는지 알고 싶어 한다.

PaaS(Platform as a Service)

사용자는 PaaS를 사용하여 소매 애플리케이션을 개발하려고 하며 여기에는 애플리케이션을 작성하고 배치하여 테스트하거나 서비스 형태로 프로덕션하기까지의 과정이 포함된다.

SaaS와 달리, 해당 플랫폼의 전체 비즈니스 라이프사이클에 존재하는 모든 애플리케이션(예: 스프레드시트, 워드프로세서, 백업, 결재, 급여 처리 및 대금 청구)을 제어할 수 있다.

서비스 제공자는 애플리케이션을 실행 중인 운영 시스템이나 하드웨어, 네트워크 인프라를 제어한다. 서비스 제공자는 소매 관리 애플리케이션의 모든 기능에 대한 업그레이드와 패치를 빌드하고 배치, 실행 및 관리할 수 있다.

물론, 사용자는 PaaS 제공자의 임계값 정책을 알고 싶어한다.

• PaaS가 계속 사용 가능하다는 것을 보장하기 위해 서비스 제공자가 임계값 레벨을 어떻게 설정하는지 사용자는 알고 싶어한다.
• 서비스 제공자가 갑작스런 수요 증가를 동적으로 처리할 수 없었기 때문에 서비스에 장애가 발생하면 사용자는 크레딧을 받거나, 환불을 받거나, 무료 사용 기간을 제공 받으려고 하거나 서비스를 해지할 것이다.

IaaS(Infrastructure as a Service)

IaaS를 사용하는 사용자는 가상 머신 레벨에서 운영 체제, 네트워크 장비 및 배치된 애플리케이션을 제어할 수 있다.

• 사용자는 가상 서버의 수나 작동 중이거나 작동이 중지된 스토리지 영역의 블록 규모를 조정할 수 있다.
• 클라우드 환경에서는 이러한 기존의 컴퓨팅 자원 인프라에 대한 사용 요금을 사용량에 따라 지불할 수 있다.

사용자는 IaaS 제공자의 인프라에 대한 임계값 정책을 확인해야 한다.

• 워크로드 수요가 갑자기 증가하는 경우에도 IaaS가 계속 사용 가능하다는 것을 보장하기 위해 서비스 제공자가 임계값 레벨을 어떻게 설정하는지 사용자는 알고 싶어 한다.
• 사용자는 소속 회사를 위해 임계값 정책과 SLA의 조항을 IaaS 제공자와 협상할 수 있기를 원한다.
• 서비스 제공자가 갑작스런 수요 증가를 동적으로 처리할 수 없어서 응답시간이 느려졌기 때문에 서비스에 장애가 발생하면, 사용자는 SLA에 제시된 대로 크레딧을 받거나, 환불을 받거나, 무료 사용 기간을 제공 받으려고 하거나 서비스를 해지할 것이다.

운영 규모: 공용 vs. 사설

하나의 예로서 필자의 회사는 10억 달러가 넘는 매출을 창출한다. 필자는 사설 클라우드가 공용 클라우드보다 비용 면에서 더욱 효과적이라는 사실을 깨달았다. 사설 내부 클라우드는 공용 클라우드와 비즈니스 특성이 매우 비슷하지만, 거버넌스, 보안, 가용성 및 회복가능성 레벨이 매출 규모가 백만 달러 미만인 소규모 기업보다 훨씬 더 높다.

공용 클라우드에서는 데이터를 알 수 없는 위치에 저장하기 때문에 데이터를 쉽게 복구할 수 없다. 이와는 대조적으로 사설 클라우드에서는 특정 관할구역(예: 미국)의 알려진 위치에 있는 데이터를 소비자가 복구할 수 있다. 준수, 개인정보 보호 데이터 및 민감한 테스트 데이터를 알 수 없는 곳에 저장하는 것은 적절하지 않다. 이러한 데이터는 한 국가의 개인정보 보호와 준수 규정이 다른 국가의 그것과는 다른 지리적 영역에 있을 수 있다. 데이터 반출을 제어하는 법규는 국가마다 다르다.

임계값 정책을 작성할 때, 필자의 회사는 클라우드 환경에서 동적으로 워크로드 수요를 조정할 수 있는 가장 높은 레벨을 요구한다. 워크로드 수요가 임계값 레벨을 초과하면 시스템이 신속하게 자원 인스턴스를 추가로 작성할 수 있어야 한다.

필자가 소속된 회사의 운영 규모가 컸기 때문에 트랜잭션 지향의 워크로드가 소규모 기업에서 보다 더 많았다. 트랜잭션 유형의 범위와 수는 필자의 회사가 소규모 기업보다 더 광범위하고 많았다. 트랜잭션 유형은 2비트나 3비트 숫자 코드나 문자 코드로 식별되기 때문에 규모가 큰 회사나 소규모 기업에서는 비즈니스 트랜잭션 카테고리를 각 유형에 맞게 연관시켜야 한다. 금융 리스 회사와 같이 규모가 큰 회사에 적합한 비즈니스 트랜잭션 카테고리는 소규모 기업에는 적합하지 않다.

위로

산업 유형

각 클라우드 서비스 유형의 임계값 정책은 산업마다 다르다. 임계값 정책은 조직 유형, 조직 규모, 시장 조건, 계절적 워크로드 수요, 경제, 요구 변경, 최신 기술 및 불리한 기상 조건의 빈도에 영향을 받는다.

또한, 데이터 센터의 수는 산업에 따라 달라진다. 다시 말해서 정부는 데이터 센터를 매우 많이 사용하는 사용자이며 수요에 따라 서비스를 임대하여 클라우드 환경에서의 운영상 가용성과 보안을 보장하기 위해 비용을 절약하는 방법을 찾고 있다.

필자는 이미 소매, 에너지, 유틸리티, 금융시장, 건강관리 및 석유화학, 이렇게 여섯 가지 산업을 예로 들었지만, 다음과 같은 산업도 있다.

• 항공 및 방위
• 자동차
• 건설
• 소비재
• 교육
• 전자
• 산림 및 제지
• 정부
• 보험
• 생명과학
• 미디어 및 오락
• 금속 및 광업
• 여행 및 운송
• 제조 및 조립
• 산업재
• 생명과학
• 조선
• 도매 유통 및 서비스

소매 산업과 석유화학 산업에서의 임계값 정책에 대한 고려사항을 비교해 보자. 각 산업의 시스템이 워크로드 수요가 임계값 레벨을 초과하는 상황을 발견하면 시스템은 자동으로 자원 인스턴스를 추가로 작성하여 워크로드 수요를 동적으로 조정한다. 워크로드 수요가 임계값 레벨 아래로 떨어지면, 할당된 자원 인스턴스는 지정이 해제된다.

소매 산업은 완성품을 일반 사용자인 소비자에게 판매하는 소규모 기업과 대형 회사로 구성된다. 석유화학 산업은 석유, 휘발유 및 화학제품을 산업 소비자에게 제공하고 판매하는 소규모 및 대형 회사와 산업 설비로 구성된다.

일반적으로 소매 산업에서는 워크로드 수요가 증가하는 시기(예: 크리스마스 쇼핑 시즌)를 예측할 수 있다. 일반적으로 석유화학 산업에서의 워크로드 수요 증가는 추적한다고 해도 예측하기가 쉽지 않은 다른 요인, 즉 경제 상황, 공급망 최적화 동인, 원유 시추에 대한 투자 및 예측할 수 없는 불리한 기상 조건(예: 한 해는 겨울이 따뜻했는데, 다음 해는 추운 경우)을 기초로 한다.

트랜잭션 유형(산업 vs. 소매)의 차이와 공용이나 사설 또는 하이브리드 클라우드에 대한 선택이 임계값을 작성하는 데 영향을 준다. 트랜잭션 유형은 비즈니스나 제품 그룹에 따른 그룹 매출과 지출 항목에 사용된다.

위로

내부의 우수한 임계값 정책

클라우드 환경에서 자원의 소비량을 조정하는 데는 자원을 효과적으로 관리하는 것이 중요하다. 임계값 정책을 사용하면 애플리케이션을 테스트하고 프로덕션하기 위한 자원 소비량을 동적으로 조정할 수 있다. 애플리케이션을 테스트하기 위한 임계값 요구사항과 프로덕션을 위한 임계값 요구사항은 다르다. 워크로드 수요가 임계값 레벨에 도달하여 시스템이 추가 자원 인스턴스를 할당하게 하기에 앞서 용량을 계획한다.

추상적인 사고를 하기 위해 IT 전문가를 활용한다고 하더라도 임계값 정책을 작성하는 데 있어 핵심적인 측면은 워크로드 수요의 중요한 컴포넌트는 실제적인 것이라는 사실을 기억하는 것이다. 사용자는 무선 인터넷 서비스를 사용하는 경우에도 실제 컴포넌트의 신뢰성 등급에 의존한다.

임계값 정책에는 하나 이상의 디스크 용량의 75 ~ 85%를 임계값 레벨로 설정하듯이 임계값 레벨에 필요한 값을 설정해야 한다. 이 정책에는 자원의 소비량을 기록하고 모니터하는 메커니즘이 포함되어야 한다.

임계값 레벨에 도달하면, 용량은 물론이고 할당된 자원 인스턴스의 수와 이 인스턴스를 할당하는 과정에서의 응답 시간이 기록되어야 한다. 또한, 다음과 같은 사항들이 기록되어야 한다.

• 애플리케이션의 상태성
• 재개 지점
• 장애 복구 메커니즘
• 클라우드 서비스 보안

상태성

상태성은 클라우드 환경에서 애플리케이션의 한 상태가 애플리케이션 기능의 후속 상태에 적절하게 응답하는지 여부를 나타낸다. 다시 말해서 매우 단순화된 다음과 같은 시나리오에서는 한 상태가 기능의 다음 상태로 완전히 이동해야 한다.

1. 소비자가 온라인에서 소매 물품을 선택한다.
2. 소매상이 선택된 품목을 카트에 놓는다.
3. 소비자가 신용카드 정보를 제공한다.
4. 소비자가 주문서를 제출한다.
5. 소매상이 신용카드 정보의 유효성을 검증한다.
6. 소매상이 주문번호와 추정되는 배송 시간을 제공한다.
7. 소비자가 주문해 준 것에 대해 소매상이 소비자에게 감사를 표한다.
8. 소비자가 주문 확인 이메일을 받는다.
9. 소비자가 주문한 물품이 배송되고 있다는 이메일을 받는다.

2단계 기능의 상태가 3단계로 이동하지 않으면 어떤 문제가 발생할까?

• 애플리케이션에서 새롭게 빌드된 기능으로 인해 논리가 손상되었는가?
• 워크로드 수요가 임계값 레벨을 초과했다는 것을 시스템이 발견했을 때, 운영을 계속하기에는 남아있는 자원이 불충분했을 정도로 임계값 레벨을 너무 높게 설정하지 않았는가?
• 임계값 레벨이 적정한 경우, 한 단계에서 다음 단계로 이동하는 데 필요한 추가 자원 인스턴스가 클라우드에 충분했는가?

로그에는 애플리케이션이 어떤 상태에 있었고 상태가 성공적으로 완료되었는지 여부가 표시되어야 한다.

재개 지점

시스템은 시스템에서 문제가 발생하기 전에 다양한 방법(스케줄링을 하거나 수동으로 또는 설치 과정에서)으로 여러 위치에 재개 지점을 작성해야 두어야 한다.

재개 지점이 포함된 디스크의 스냅샷은 로컬 시스템에 있는 디스크와 다양한 원격 위치에 있는 또 다른 디스크에 백업해 두어야 한다. 로그에는 재개 지점을 작성한 시점과 시스템을 복원하는 데 사용한 재개 지점이 표시되어야 한다.

장애 복구 메커니즘

또한, 시스템은 장애 복구 메커니즘을 시작하여 운영이 계속될 수 있게 해야 한다.

만일을 생각하여 장애 복구 메커니즘에는 유선이나 무선 연결을 대체할 수 있는 수단이 포함되어야 한다. 예를 들면, 전기통신 서비스 제공자가 우연히 광케이블을 자르거나 소비자의 실제 설비에 연결된 무선 네트워크를 종료시킬 수 있다. 로그에는 장애 복구 과정에서 사용한 장치의 유형과 위치가 표시되어야 한다.

장애 복구 메커니즘과 관련된 예로는 다음과 같은 것들이 있다.

• 로드 분산 이중화. 세 개 이상의 시스템이 총 로드의 50%만을 부담한다. 장치에 장애가 발생하면 거의 중단 되지 않고 다른 장치가 로드를 부담한다.
• 인스턴스 자원 이중화. 세 개 이상의 자원 인스턴스가 총 로드의 50%만을 부담한다. 자원 인스턴스에 장애가 발생하면 다른 자원 인스턴스가 로드를 부담한다.
• 대체 연결 시도. 3분 이상 네트워크 중단이 지속되면 대체 연결을 통해 다른 서버로 재연결을 시도한다.

클라우드 서비스 보안

클라우드 서비스 보안은 잘못된 신임 정보, 프로토콜 노출 및 원격 관리 구현상의 결함으로 인해 위협을 받을 수 있다. IP 주소를 재사용하면 의도되지 않은 DoS(Denial of Service) 공격이 발생할 수 있다.

SaaS는 DoS 공격을 일으킬 수 있는 바이러스에 계획적으로 영향을 받을 수 있다. 해커는 PaaS뿐만 아니라 IaaS 플랫폼을 CnC(Command and Control Center)로 사용하여 봇넷(좀비 컴퓨터로 구성된 네트워크)의 조작을 지시함으로써 DDoS(Distributed Denial of Service) 공격을 하고 클라우드에 악성 소프트웨어를 설치한다.

로그에는 클라우드 서비스 유형이 안고 있는 보안 문제점의 유형과 이러한 문제점을 수정한 시점과 방법이 표시되어야 한다.

위로

고려해 볼 문제점

일반적으로 서비스 제공자가 기본적인 클라우드 컴퓨팅 시스템을 책임진다고 하더라도, 자신의 시스템이 해당 규정 요구사항을 만족시키며 자신의 행위가 합리적으로 안전하고, 권한이 없으면 자신의 관리자가 해당 데이터에 액세스할 수 없으며 SLA는 적절하다는 것을 보장할 법적 책임은 여전히 사용자에게 있다.

SLA가 어떻게 작동하는지, 임계값 정책이 SLA에 어떻게 영향을 주는지 그리고 서비스 제공자가 사용자를 실망시키는 경우에는 어떤 절차를 따를 수 있고 어떤 보상을 기대할 수 있는지 확인한다.

SLA의 중요 컴포넌트는 가동 시간의 가용성, 성능 표준, 긴급 상황에서의 응답 시간, 위반 해결 및 보안이다.

SLA에 있는 가동 시간 가용성의 성능 표준으로 지정된 값과 임계값 레벨의 차이를 확인한다. 임계값 레벨을 가동 시간 가용성 표준 이상으로 설정해서는 안 된다. 가동 시간 가용성을 97이나 99.9%로 선택한 다음, 비즈니스 요구와 예산을 가장 잘 충족시키는 임계값 레벨을 선택한다.

SLA가 위반되는 상황이 발생하면 해결 수단이 제공되어야 한다. 다시 말해서 클라우드에서 자원 인스턴스를 추가로 작성하는 과정에서 응답이 지연된 경우와 같이 SLA를 만족시키지 못한 경우에는 서비스 제공자가 무료 크레딧을 발행하거나 비용을 환불해야 한다. 서비스 제공자가 3개월 동안 여러 번 SLA를 만족시키지 못한 경우에는 사용자가 서비스를 해지할 수 있어야 한다. 해지와 관련된 조항이 SLA에 포함되었는지 확인하고 이 조항을 매우 주의 깊게 읽어본다.

사용자와 서비스 제공자가 주장하는 서비스 중단 기간이 일치하지 않는 경우에는 누구의 주장을 따라야 하는지 SLA에 표시되어 있는가? 사용자는 소송이 제기되고 나서 자신이 얼마나 기다려야 하는지 알아야 한다. 매출 손실이나 평판 손상, 데이터 침해를 포함하여 SLA에서 다루어지지 않은 사항이 자신의 보험 정책에서 처리되는지 검토한다.

위로

결론

워크로드 수요가 동적으로 조정되도록 임계값 정책을 설정하려면 클라우드 환경에서 자원 인스턴스를 추가로 작성해야 하는 문제를 해결하기에 앞서 계획을 해야 한다. 개발자는 경제적 규모(공용 vs 개인용 클라우드)의 이슈 및 애플리케이션 테스트 및 프로덕션을 위한 임계값 정책의 개발에 대해 클라우드 서비스 소비자 및 제공자와 의견을 나누어야 한다. 워크로드 수요가 임계값 레벨에 도달하여 시스템이 추가 자원 인스턴스를 할당하게 하기에 앞서 용량을 계획한다.

참고자료

교육

• "Cloud computing versus grid computing: Service types, similarities and differences, and things to consider" 기사에서 작성자는 임계값 정책을 검토한다.
  
  
• developerWorks cloud developer resources에서는 클라우드 배치를 위한 프로젝트를 개발 중인 애플리케이션 및 서비스 개발자의 경험과 지식을 찾아보고 공유할 수 있다.
  
  
• 이 기사와 관련된 다양한 developerWorks 자료는 developerWorks의 SOA and web services와 industries에서 확인할 수 있다.
  
  
• 다음 단계: IBM Smart Business Development and Test on the IBM Cloud에 액세스하는 방법을 확인하자.
  
  

제품 및 기술 얻기

• IBM Smart Business Development and Test on the IBM Cloud에서 사용 가능한 제품 이미지를 확인하자.
  
  

토론

• developerWorks에 있는 클라우드 컴퓨팅 그룹에 참여하자.
  
  
• developerWorks에 있는 뛰어난 클라우드 블로그를 모두 읽어보자.
  
  
• 연결, 공유 및 협업을 위한 전문가 네트워크이자 통합 커뮤니티 도구 세트인 developerWorks에 참여하자.
  
  

필자소개

Judith M. Myerson은 시스템 아키텍트이자 엔지니어다. 관심 분야는 미들웨어 기술, 엔터프라이즈 수준의 시스템, 데이터베이스 기술, 애플리케이션 개발, 네트워크 관리, 보안, RFID 기술, 프로젝트 관리 등이다.

아티클 순위

의견

위로

목차

• 임계값 정책 개요
• 클라우드 서비스 유형
• 산업 유형
• 내부의 우수한 임계값 정책
• 고려해 볼 문제점
• 결론
• 참고자료
• 필자소개
• 의견