Market Trend - BSM(Business Service Management)
상태바
Market Trend - BSM(Business Service Management)
  • 승인 2005.10.13 00:00
  • 댓글 0
이 기사를 공유합니다

제품이 아니라 하나의 프로세스 … 일석이조 효과 노린다
조직적·기술적 목표 동시 추구 … 포괄적이고 유연한 IT 전략 필수


기상학자인 에드워드 로렌즈(Edward Lorenz)는 복잡하고 역동적인 환경에서 작은 날개짓 하나가 생각지도 않은 곳에서 혼돈(chaos)를 불러올 수 있다는 것을 이론화했다. BSM(Business Service Management) 이니시어티브는 제멋대로인 IT 시스템에 질서를 주고, 결과를 연결하기 위해 흩어진 인프라들로 접근하며, 따라서 관리 사일로에서 일어난 작은 변화가 큰 서비스 고장 사태로 연결되지 않게 지켜준다.

업체들이 언급하곤 하는 야심적인 BSM 이니시어티브는 실현이 될 수도 있고 안될 수도 있지만, 그것은 상관이 없다. BSM은 제품이 아니라 하나의 프로세스며, IT 인프라 관리가 성숙했음을 의미하는 것이기 때문이다. 그리고 여기서는 기반 인프라로의 향상된 서비스 매핑을 약속하는 소프트웨어가 초석이 된다(본고 제2부에서는 바로 이런 제품들을 평가해 보았다). 하지만 BSM에서 보다 중요한 부분은 포괄적이고 유연한 내부 IT 관리 전략으로, 여기에는 베스트 프랙티스, 특히 ITIL(IT Infrastructure Library)에서 채택한 것들이 포함돼 있어야 한다.

아직 시장이 혼란스럽다
IT에서도 BSM 메시지를 듣고 있다. 포레스터 리서치에 따르면 BSM과 SLM(Service Level Management)은 인프라 관리 기술 영역에서 가장 빨리 성장하는 두 부문이었으며, 이는 곧 이런 동향이 계속될 것임을 시사한다. 하지만 아직 이 시장은 혼란스러운데, 그 이유는 많은 BSM 업체들과 툴, 그리고 심지어 그 개념까지도 1990년대 중반의 프레임워크와 매우 유사하기 때문이다. 일관성 있는 사용자 인터페이스를 이용해 관리 사일로들을 연결하는 일은 단일 관리 데이터 저장소까지도 데자부처럼 완전히 다시 한 번 되풀이되는 것처럼 들릴 것이다. 그리고 BMC, 컴퓨터 어쏘시에이츠, 휴렛팩커드 및 아이비엠 등과 같은 모든 유수의 프레임워크 업체들도 BSM에 매우 깊이 관여하고 있다.
그 차이는 포착하기 힘들긴 하지만 기능성과 이행에서 확실하게 존재한다. BSM 업체는 서비스를 출발점으로 삼는 데 비해 프레임워크 업체들은 인프라에서 시작했다. 프레임워크 이니시어티브는 IT에서 주도했지만, BSM은 비즈니스쪽과의 협업을 통해 이루어진다. 단순한 작업처리량이나 서버 가동시간을 척도로 삼는 대신, 이제는 좋은 애플리케이션 응답시간과 비즈니스 쪽 척도를 맞출 수 있는 능력이 IT의 우선순위를 차지하고 있다.
IT는 기반 인프라를 향한 자신들의 목표를 매핑하기 위해 비즈니스 쪽 소유주들과 함께 작업해야만 한다. BSM 툴은 좋은 응답과 필요한 가용성에 대한 IT의 통계를 기록한 다음, 페이지 로드 시간과 24/7 응답과 같은 척도를 특정 사양과 운영적 프랙티스로 매핑해야 한다. 예를 들어 웹 고객들에게 빠른 페이지 뷰를 제공하는 데 있어 어떤 서비스와 네트워크가 열쇠가 되는가? 빠른 응답시간을 유지하는 데는 무엇이 필요할까? 특정 서버의 고장이 제품 판매에 어떤 영향을 끼치게 될까?
BSM 이니시어티브에서는 IT와 비즈니스 그룹간에 서비스 지향적인 공통어를 만드는 게 가장 중요한 과제이자 이점이다. 비즈니스 소유주와 경영진은 너무 상세한 세부사항들은 알고 싶어하지 않을 것이다. 이들은 IT에서 필요한 척도에 도달하기 위해 어떤 일을 해야 하는지를 듣고 싶어 하지 않는다. 이들이 듣고 싶어 하는 것은 고객의 니즈와 비즈니스 목표에 부합하는 것에 대한 얘기다.
하지만 명심해야 할 점이 있다. 이러한 모든 팀워크에 대한 말들은 따듯하고 훈훈하게 들리며, 매핑 서버 응답시간과 가용성은 그다지 어려운 문제가 아닌 것 같다. 하지만 BSM이 제대로 되려면 엔드유저와 고객을 위하는 일만이 IT 경영진의 칙령을 준수할 수 있기 때문에 법을 만드는 데 익숙한 IT 그룹에게 있어서 현실은 그리 만만치가 않다.
이것이 간단하리라고 말하는 사람은 아무도 없다. 관리 프레임워크에서 일상적인 서비스 중단과 비용 초과는 중앙 IT 제어에 대한 거부감을 불러 일으켰으며, 비즈니스 부문에서 편협한 애플리케이션, 하드웨어 및 관리 시스템을 채택하도록 했다. 반면 IT ROI는 신속하고 확실하게 수반되어야 한다. 또한 우리는 기존의 시스템을 중심으로 관리를 구축하면서 동시에 서비스 전달을 향상시켜야만 한다.

핵심은 CMDB
조직의 규모가 BSM을 고려할 정도로 크다면, 하나의 관리 프레임워크로 모든 서비스 전달 니즈를 커버할 수는 없다. 마지막 세대의 프레임워크를 테스트해 본 결과에 따르면, 이들은 선전만큼 그다지 하나로 통일된 모습이 아니었다. 그보다 이들은 IT 사람들이 시간을 들여 이행하고 관리해야 하는 여러가지 스크립트와 API, 기술 및 제품 등을 포함하고 있다. 우리의 애플리케이션 의존성 매핑 제품 테스트에서는 이러한 상황이 지속되고 있음을 알 수 있었다. 그리고 조직적으로나 기술적으로 관리상의 목표에 도달하기 위해 기존의 시스템을 대폭 업그레이드하는 일은 더 이상 받아들이기 힘들다. 기존의 시스템들은 가능한 한 언제나, 그리고 최소한의 수고를 들여 통합될 수 있어야만 한다.
회사에서 이용하고 있는 관리 업체가 통합을 제공할 것을 요구할 수 있고 또 당연히 그래야 하겠지만, 프로세스의 안정성과 베스트 프랙티스는 IT의 책임이며, 이것은 곧 ITIL이 전체 BSM 이행에 포함돼야만 하는 이유이기도 하다. 이러한 실제 현실의 핵심에는 IT 시스템 구성이 정확하게 이루어지도록 유지해 주는 저장소(repository)인 CMDB(Configuration Management Database)가 존재한다.
ITIL은 CMDB를 사건이나 변화 관리와 같은 프로세스를 지원하기 위해 구성, 메타데이터, 상태, 그리고 심지어 성능 데이터와 이들의 상호관계를 추적하는 저장소로 정의하고 있다.
ITIL의 등장은 BSM 운동을 촉진시켰다. 이것은 IT 서비스 전달의 버팀목이며, 그 인프라 관리 프로세스와 워크플로는 BSM 업체들에게 서비스 관리 접근방안을 제공한다. 특히 CMDB는 당신의 IT 인프라에서 발생하는 모든 일을 놓치지 않는다고 약속하기 때문에 새로운 IT 관리를 이상적인 것으로 만들어준다.
하지만 좋은 표준이나 새로운 기술이면 어떤 것이든 마찬가지겠지만 여기에도 일종의 종교적인 문제가 포함돼 있는데, 그것은 바로 연방식(federated)이냐 중앙집중식(centeralized)이냐를 둘러싼 성전(holy war)이다.

연방식이냐 중앙 집중식이냐
중앙집중식 CMDB는 하나의 관리 업체에서 제공하는 하나의 통합된 데이터 저장소인 반면에 연방식 CMDB는 여러 업체들로부터 제공되며 하나의 써드파티 애플리케이션을 이용해 함께 연결이 되는 분산된 데이터 저장소들의 세트를 말한다.
아마도 업체들이 중앙집중식을 좋아하리라고 생각하겠지만 그렇지 않다. 관리 업체들은 마치 자신이 관리라는 우주의 한 가운데에 있는 것처럼 가능한 한 많은 교차 관계를 갖고 싶어 하기 때문에 연방식 방안을 선호한다.
우리의 프레임워크 판매업체인 경우는 소규모 업체들처럼 부가가치 업체들과 많은 관계를 맺고 있을 뿐만 아니라 자체 조직의 관계들도 갖고 있다. 이것은 특히 아이비엠, HP 및 BMC 등 자신들의 다양한 관리 제품을 통합시키는 데 열심인 업체들의 경우에 두드러진다. BMC와 HP는 현재 서비스 데스크를 포함해 거의 모든 관리 영역에 손을 뻗고 있다. 이들이 밖에서 찾아야 하는 유일한 곳은 네트워크 장비 구성 쪽이다.
IT로서는 서로 다른 데이터 저장소가 있는 다중 관리 제품들을 갖는 게 보통이기 때문에, 연방식을 택함으로써 큰 통합 프로젝트를 피할 수 있다. 하지만 CMDB 데이터가 저장되거나 통합되는 방식에 대한 표준이 없고 베스트 프랙티스가 조직마다 다양하기 때문에 모든 데이터 저장소의 아웃 오브 더 박스 통합은 사실상 불가능하다.
ITIL은 CMDB에 얼마간의 기본적인 네이밍 필드와 각각의 자산에 하나의 IT가 연결돼 있도록 규정하고 있는데, 이 때문에 CMDB가 개방이거나 상호운용이 가능하다고 보일지 모르지만 그렇지가 않다. 업체들은 자신들의 CMDB와 통합할 수 있게 해줄 API를 언급하겠지만 연방식을 생각할 때는 전문가 서비스도 함께 생각해야 한다.
모든 데이터 저장소가 행복하게 수다를 떨 수 있게 만들었다고 해도 통합의 정도는 다양할 것이다. 예를 들어 써드파티 상태 모니터링 애플리케이션으로부터 서비스 데스크 제품에서 자동으로 티켓을 열 수 있다는 사실은 굉장하지만, 상황이 바뀔 때 티켓이 자동으로 닫히는가? 써드파티 구성 관리 애플리케이션이 변화 제어 티켓에 의해 트리거링된 구성 변경을 적용시키라는 요청을 받은 다음, 변화 감사 기록을 수정하고 티켓을 닫힌 것으로 업데이트할 수 있는가? 전문가 서비스가 있으면 가능한 일이지만 필수 사양이 아니기 때문에 요청을 해야 한다.
장비 구성용으로는 옵스웨어(OpsWare)나 블레이드로직(BladeLogic), 자동화된 실시간 시스템 QoS용으로는 옵티어(Optier), 그리고 성능 관리용으로는 인티그리언(Integrien) 등과 같이 전문적인 장비 및 시스템 지식을 갖춘 업체들로부터 보다 깊이 있는 통합도 또한 지원되고 있다.

Executive Summary
“BSM 자체를 거부하면 안된다”

BSM(business service management)은 얼마 되지 않는 삶을 살아오면서 과대선전이 되어오기도 했지만 BSM 자체를 거부해서는 안 된다. 제대로만 되면 BSM은 기술적인 목표와 조직적인 목표를 함께 달성할 수 있는 하나의 큰 진전이기 때문이다. IT에서 온라인 물품 판매가 저조한 원인이 무엇인지를 집어낼 수 있다면(그리고 그 문제를 고칠 수 있다면) 우리는 이런 IT에 대한 모든 이야기가 비즈니스의 성공에 필수가 아니라는 말을 이미 듣고 있을 것이다.
본고 제1부에서는 IT가 서비스 전달 능력을 향상시킴으로써 기존의 시스템을 중심으로 하여 관리를 구축할 수 있는 방안을 논의해 보았다. 여기에는 단순한 칙령 하달을 그만두고 성능 목표를 이행, 모니터링 및 보고하고, 정해진 조직의 우선순위에 따라 IT의 우선순위, 차지백(chargeback) 및 예산을 설정하고자 하는 의지와 함께, ITIL(IT Infrastructure Library)이 열쇠가 된다.
그리고 제2부 리뷰에서는 애플리케이션 의존성 제품들을 분석해 보는 자리를 마련했다. 각 제품에게는 NWC 비즈니스 애플리케이션 네트워크에서 돌아가는 애플리케이션을 검색하고 문서화하도록 요청했다. 테스트한 제품들은 BMC 소프트웨어의 BMC 토폴로지 디스커버리 1.2(BMC Topology Discovery 1.2), 센두라(Cendura Corp.)의 코히전 3.5(Cohesion 3.5), 콜레이션(Collation)의 컨피그니아 3.1(Confignia 3.1), n레이어즈(nLayers)의 인사이트 4.0(InSight 4.0), 그리고 릴리코어(Relicore)의 클래리티 4.1(Clarity 4.1)이었으며, 이들 가운데 클래리티가 그 정밀성에 힘입어 에디터즈 초이스로 선정되었다. 모든 서버에서 대행자를 둠으로써 마술을 부리는 방식은 어떤 조직들에게는 달갑지 않게 느껴지겠지만 그 결과를 보면 이런 수고를 할 만한 가치가 충분했다.



SLM/BSM 시장 성장률 전망

라이선스 및 메인터넌스 매출 (백만 달러)

1,000 900 600 300 0
2003 2004 2005 2006 2007
=======================================

Network computing 2005.9.1 P.37~
Market Trend / BSM 툴 리뷰

‘매핑·감사·탐색’ 세 박자 제대로 갖춰야
‘클래리티’ 의존성 매핑 최고 … ‘인사이트’ 가격대비 성능 최고

BSM에서 성공적이 되려면 애플리케이션을 매핑해야 한다. 아니면 어떤 IT 고장이 비즈니스 서비스를 망쳐놓고 있는지를 어떻게 알겠는가? 우리는 본지 비즈니스 애플리케이션 랩 네트워크에서 다섯 가지의 BSM 애플리케이션 토폴로지 매핑 스위트를 평가해 보았다. 이들은 시스템 구성 데이터를 모으고, 패킷을 디코딩하며, 커널 I/O를 살펴서 애플리케이션의 의존성(dependencies)을 파악하는 툴들이다.

BSM 애플리케이션 토폴로지 매핑 스위트는 서비스나 성능, 혹은 상태 모니터가 아니다. 이들은 모든 서버와 시스템, 애플리케이션, 프로세스, 서비스, 사용자, 그리고 가끔은 심지어 네트워크 장비까지 매핑을 함으로써, 애플리케이션이 무엇에 의존하고 있는지, 그리고 무엇이 이들에게 의존하고 있는지를 해독해 낸다. 이러한 매핑은 또한 진단, 용량 및 서비스 관리 애플리케이션 전달을 한층 수월하게 만들어 준다.
테스트를 위해 우리는 NWC 비즈니스 애플리케이션 네트워크를 이용했다. 물론 NWC가 어떻게 돌아가고 있는지를 정확히 알고 있긴 하지만, 우리는 마치 우리가 모르는 것처럼 제품들이 이것을 모두 보도해주기를 기대했다. 애플리케이션 설계자, 개발자, 혹은 관리자가 만드는 문서를 사용하는 게 더 편리하거나 저렴하지 않을지 의심이 들지 모르지만, 이것은 현실이라는 사실을 명심하라. 정말 작은 인프라가 아니라면 이런 기록들은 개략적인 것들에 불과하다. IT에서 수백 개의 서버를 이용해 많은 애플리케이션을 전달해야 한다면, 수동 문서화, 동기화 및 감사 작업은 거의 불가능에 가깝다.
우리는 8개의 IT 서비스 매핑 및 모니터링 업체들에게 참가를 요청했다. 이들에게는 주 포커스가 애플리케이션 서비스 의존성을 파악하는 일이 될 것이며, 따라서 네트워크 인프라 모니터링과 상호연관 기능만을 수행하는 제품은 적합지 못하다고 말했다. 초청에 응한 업체는 BMC TD(Topology Discovery) 1.2의 BMC 소프트웨어, 코히전 3.5(Cohesion 3.5)의 센두라, 컨피그니아 3.1(Confignia 3.1)의 콜레이션, 인사이트 4.0(InSight 4.0)의 n레이어즈(nLayers), 그리고 클래리티 4.1(Clarity)의 릴리코어(Relicore) 등이었다.
머큐리 인터랙티브(Mercury Interactive)와 타이드웨이 시스템즈(Tideway Systems)는 거절을 했으며, 인티그리언(Integrien Corp.)의 경우 인티그리언 얼라이브(Integrien Alive)를 보내긴 했지만 그 뛰어난 성능 관리 기능 속에 애플리케이션 매핑이 없었다.

맵 그리기
애플리케이션 매핑 툴은 서비스 고장과 변경의 영향을 파악하는 데 있어 신뢰할 수 있는 토폴로지 데이터의 자동화된 소스로서, 비즈니스 목표를 기반으로 하여 IT 인프라 성능을 서비스 수준 관리와 연관을 시키고자 하는 BSM 이니시어티브에서 핵심이 되는 기능이다. 신뢰할 수 있는 맵은 또한 애플리케이션이 생산 환경에서 돌아가는 방식을 나타내 줌으로써 MTTR(Mean Time To Repair)을 줄일 수 있다. 그리고 이 데이터는 특정 모듈이나 실행가능자(executables), 혹은 파일 등 업그레이드돼야 할 필요가 있는 것들을 식별해 내는 동시에 어떤 의존성이 존재하는지를 하이라이팅하여 자원이 어떤 식으로 영향을 받게 되는지를 판단해 줌으로써 IT의 용량 및 변경 기획자들에게 도움을 준다. 생산 제어(production control)는 계획된 변경작업을 감사하고, CMDB(configuration-management database)로의 업데이트를 자동화할 수 있다.
하지만 이것이 만병 통치약은 아니다. 애플리케이션 매핑 제품에 의해 수집된 데이터의 일부는 예를 들어 서버 성능 모니터링 목표를 한층 높여줄 수 있지만, 옵티어(OpTier)나 프로액티브네트(ProactiveNet)와 같은 성능관리 전문 스위트를 이용하는 게 더 나을 것이다. 그리고 앞서 언급한 것처럼 우리는 참가 제품들에게 네트워크 의존성을 매핑할 것을 요구하지 않았다. 일부 스위치 및 부하조절기 정보는 테스트한 툴을 이용하면 더욱 활발해지겠지만, 스위치와 라우터 연결성의 레이어 2 및 레이어 3 맵이 필요하다면 휴렛팩커드의 HP오픈뷰 네트워크 노드 매니저(OpenView Network Node Manager)나 컴퓨터 어쏘시에이츠의 아프리즈마(Aprisma) 같은 제품을 찾으라.
우리는 위스콘신 주 그린베이에 있는 NWC 비즈니스 애플리케이션 랩에 마련된 비즈니스 프로세스를 이용해 애플리케이션 매핑을 테스트했다. 애플리케이션 매핑 서버(와 테스터)는 시러큐스 대학 리얼월드 랩에 있었으며, 소닉월(SonicWall) VPN을 통해 두 개의 환경을 연결했다.
이 부품제조 운영의 세 가지 주 애플리케이션은 e-커머스 사이트, 인벤토리 사이트, 그리고 고객주문 추적(cusomer-order-tracking) 사이트며, 우리는 이 애플리케이션들을 모두 매핑했다. 인벤토리와 e-커머스는 하나의 오라클9i 데이터베이스를 공유하는 반면, 마이크로소프트 SQL 고객추적 데이터베이스는 오라클 데이터베이스로 동기화된다. 각각의 애플리케이션에는 웹 서버, 애플리케이션 서버, 데이터베이스 티어가 있으며, 단 애플리케이션과 웹 서버는 같은 기계에서 돌아간다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.