|
|
|
|
전체적 APM(Holistic Application Performance Management) |
| Market Analysis |
 |
2007년 07월 09일 00:00:00 |
데이터넷
|
 |
|
|
애플리케이션 성능, “미리미리 관리하라”
‘종합 트랜잭션 S/W·네트워크 프로브’로 분류 … ‘비용·시간’ 투자 각오해야
성능 문제가 발생하고 난 후에 여기에 집중하는 것만으로는 더 이상 충분치가 못하며, 새로 나오고 있는 전체적 APM(Holistic Application Performance Management) 제품들은 보다 예방적인 성능 모니터링에 대한 흥미로운 가능성을 제시하고 있다. 변화하고 있는 APM 시장의 지형도를 살펴 보자.
애플리케이션 성능 관리는 IT 관리자를 미치게 만드는 퍼즐이다. 애플리케이션 아키텍처는 복잡하며, 데이터 센터 가상화는 성능 관리의 수렁에 복잡함을 더 추가한다. 만약 회사의 이익이 애플리케이션 속도와 사용자 만족도에 의존하고 있다면, 애플리케이션 성능은 결정적이며, 중복되는 툴들을 함께 테이프로 붙여 놓는 것은 좋은 전략이 아니다.
APM 업체들은 새롭고 전체적인 접근 방식을 기반으로, 보다 뛰어나고 빠르고 신뢰성 있는 모니터링을 제공해줄 예방적인 애플리케이션 성능을 전달하고 싶어 하지만, 이것이 내 조직에 잘 맞을지는 어떻게 확신할 수 있을까?
여러 가지 구성 요소 파악 필수
수동의 노동 집약적인 방식에 의존하던 많은 제1세대 제품들과 달리, HP의 머큐리 애플리케이션 매핑(Mercury Application Mapping)과 같은 제품들은 애플리케이션과 그 기반 인프라와의 관계를 자동으로 검색 및 매핑하고자 애쓴다. 다른 소수의 APM 업체들도 이러한 매핑 기능을 제공하긴 하지만, 디지털퓨얼테크놀로지스(Digital Fuel Technologies), 인티그리언(Integrien), 오블리코어(Oblicore) 및 옵티어(OpTier) 등에서 나오는 제품들은 이러한 갭을 메워주거나, 혹은 다양한 업체들의 APM 데이터를 위한 전체적인 통합 지점으로서의 역할을 할 수 있다.
일단 문제가 확인이 되면, 전체적 APM은 성능 문제를 해결하기 위해 직접 개선 조치(corrective action)를 취하거나, 이것을 할 수 있는 다른 툴들, 즉 오팰리스 소프트웨어(Opalis Software), 옵스웨어/아이컨클루드(iConclude), 혹은 리얼옵스(Realops) 같은 업체의 툴들을 통합시킨다. 여기에는 추가 네트워크 대역폭 할당, 서버에서의 프로세싱 능력, 혹은 심지어 구성 변화 롤백(roll back) 등까지도 포함될 수 있다. 개선 조치 능력이 없을 경우에는 조직에서 신속한 문제 확인 및 통보 능력을 확보해야 한다. 이것은 여러 경우에 큰 진전이긴 하겠지만 결코 이상적인 상황은 아니다.
자신의 환경에 있는 여러 가지 구성요소들을 파악하고, 자동으로 이들을 상호연관 및 통합해주는 APM 제품은 즉각적으로 가치를 발휘할 수 있다. 애플리케이션 관계가 전체 토폴로지의 실시간 매핑은 네트워크, 시스템 및 애플리케이션 데이터를 포함한 근본 원인 분석을 제공하는 데 있어 매우 중요하다.
그렇다면 제대로 된 제품을 갖고 있다고 어떻게 얘기할 수 있을까? APM에서 진정으로 전체적인 접근을 하려면 시스템과 네트워크 성능을 포함해 애플리케이션 및 지원 인프라의 모든 구성요소에서 성능 문제의 위치를 파악하고 예측을 해야 한다. 이들은 기반 문제를 진단하고, 문제가 사용자 커뮤니티에 도달하기 이전에 개선 조치를 제안하거나 취해야 한다. 이들 중 어떤 것이든 제대로 하지 못하면 시간과 돈만 버릴 뿐이다.
전체적 아키텍처
전체적인 설계란 일반적으로 모든 분리된 조각들이 보기 좋게 보다 큰 그림으로 합쳐지는, 주변의 환경과 조화를 이루어 기능을 하는 구성을 의미하지만, APM에서는 아직 이 기술의 열반이 완전히 실현되지는 못하고 있다. APM 아키텍처에는 네트워크와 애플리케이션 레이어에 설치되는 몇 가지 컴포넌트가 포함된다. 이행하기 복잡하긴 하지만, 에이전트(agent)는 특히 애플리케이션 서버나 지원 시스템 컴포넌트에서는 필수다. 에이전트로부터 오는 정보가 없이는 문제의 원인을 잡아내기가 힘들며, 이것은 애플리케이션 성능 퍼즐에서 가장 흔한 소스 가운데 하나다.
게다가 애플리케이션 계층, OS, 하드웨어, 데이터베이스 컴포넌트 및 심지어 클라이언트 워크스테이션에까지 설치된 에이전트들은 메모리 이용량, CPU 및 네트워크 활동 등과 같이 애플리케이션에 영향을 미치는 문제를 탐지할 것이다. 사용자 워크스테이션에서 비롯된 성능 결함을 추적해 주는 클라이언트 에이전트가 없이 버티는 IT 조직들이 많겠지만, 고객의 만족도가 중요한 곳에서는 이것이 필수 항목이다. 마찬가지로 조직에서는 필요에 따라 수많은 VM에 에이전트를 설치해야 할 수도 있다. 이런 툴들의 가격은 배치 모델당 기반이기 때문에 아키텍처가 구매 의사결정에 영향을 미칠 수 있다.
종합 트랜잭션 모니터링(Synthetic Transaction Monitoring)은 오프 피크 시간 동안의 성능 저하를 탐지하고, 사용자가 결험은 하면서도 보고하지는 않는 문제를 찾아내는 한편, 네트워크 프로브(network probe)는 실제 사용자 데이터를 캡처해서 엔드유저의 경험을 모니터링 및 베이스라이닝하고, 애플리케이션 성능이 저하되는 동안 그 문제를 탐지할 수 있게 해준다. 넷QoS나 넷스카우트(NetScout) 같은 업체의 관리 프로브는 또한 소중한 네트워크 용량을 소모하거나, 애플리케이션에 영향을 미칠지도 모르는 다른 애플리케이션들로부터 전반적인 네트워크 성능 데이터를 수집해 준다.
조직에서 이 모든 데이터를 수집한다고 하더라도, 상호연관과 분석 기능을 제공하는 중앙 엔진이 없다면 IT 관리자는 금방 지치고 문제를 고립 및 해결할 수 없게 된다. 전체적 ATM 아키텍처에서는 데이터가 미드티어 서버에 의해 수집된 다음, 근본 원인 분석을 위해 상호연관 엔진으로 전달돼야 한다. 그런 다음에는 일단 상호연관 엔진이 문제를 탐지한 후 개선 조치를 취하도록 문제 자동화 소프트웨어를 찾는 조직들이 많다.
전체적 APM 아키텍처는 성능의 모든 부문을 고려해서 표면적인 진단 아래로 깊이까지 파고 들어가서 문제의 진짜 원인을 찾을 수 있게 도와준다. 점점 더 많은 통합 애플리케이션들이 널리 배치됨에 따라, 네트워크 수요와 잠재적인 성능 문제의 수도 계속 늘어날 것이다. 아키텍처에 있는 갭은 문제를 파악하기 힘들게 하며, 궁극적으로는 MTTR(Mean Time To Repair), 곤란함, 그리고 비용을 늘리게 된다.
능동과 수동
대부분의 업체들은 어떠한 유형의 애플리케이션 관리에서든 모두 APM이란 단어를 이용해 기본적인 능동/수동 범주를 사용하는 제품을 정의하고 있다. 이러한 범주는 대부분의 경우 지나치게 단순화돼 있을 수도 있겠지만, 능동적 툴과 수동적 툴은 여전히 실제 성능 문제를 삼각측량하고 타깃으로 하기 위해 서로 다른 관점에 가능한 한 많은 데이터를 제공하도록 고안된 전체적 방식의 백본을 제공한다. 이것은 결과적으로 기존의 관리와 중복성이 생기거나 중복 모니터링을 야기할 수도 있지만, 전체적 접근 방식은 IT의 시간을 절약해 주고 문제 식별 및 장애관리시 어려움을 덜어줄 수 있다.
종합 트랜잭션 제품은 성능 문제를 탐지하기 위해 특정 에이전트를 배치할 필요를 없애준다. 대신 이들은 시스템에 있는 실제 사용자들의 행동을 모방하고, 모니터링되고 있는 애플리케이션에 부하를 추가시킬 것이다. 사용자는 종종 적절한 종합 트랜잭션을 만들기 위해 애플리케이션 팀과 협동을 해야 한다. 또한 특정 애플리케이션들은 얼마간의 변경이 필요할 수도 있다. 결국 자신의 전자상거래 사이트에서 시뮬레이팅된 고객이 주문하는 제품을 출시하고 싶은 사람은 없을 것이다.
수동 모니터링 툴은 네트워크 애플리케이션 트래픽을 추적하고, 애플리케이션에 어떠한 부하도 추가되지 않게 해준다. 혹은 클라이언트나 애플리케이션 서버, 혹은 하드웨어에 에이전트를 배치하기도 한다. 어떤 툴들은 에이전트 없이 엔드유저의 응답 시간을 추적 및 측정한다. TCP 애플리케이션 패킷이 네트워크에서 돌아다님에 따라, 수동 모니터는 네트워크 왕복 시간, 서버 응답 시간, 데이터 전송 시간 및 기타 주요 통계를 추적한다. 이런 방식은 강제성은 떨어지지만 그 가능성은 네트워크의 아키텍처에 따라 달라진다. 분산형 환경에서는 모든 애플리케이션 데이터를 추적하기 위해 많은 수동 어플라이언스가 필요할 것이다.
APM 제품 동향
종합 트랜잭션 모니터링 제품은 엔드유저를 시뮬레이팅하고, 애플리케이션과 결과 보고서에 대해 스크립팅된 매크로 형태의 트랜잭션을 수행한다. 이것은 사용자 관점에서의 성능 문제를 식별해 주겠지만, 에이전트 기술이 없으면 애플리케이션이나 하드웨어 및 OS 인프라에서의 성능 문제에 대한 실제 원인을 분리시킬 수가 없다.
시만텍에서는 에이전트와 종합 트랜잭션을 제공하는 APM용으로 몇 가지 옵션을 제공하기 위해 인뎁스(Indepth), 인폼(Inform) 및 인사이트(Insight) 등 소위 i3 스위트를 내놓았다. 인뎁스 에이전트는 J2EE와 닷넷 애플리케이션뿐만 아니라, 다른 일반적인 엔터프라이즈 애플리케이션용으로 심층 애플리케이션 통계를 제공한다. 인뎁스는 또한 성능 문제를 야기할 수 있는 애플리케이션의 내면에 대한 정보도 제공해 준다. 인폼은 여기에 경보, 동향 추적 및 성능 보고를 추가했으며, 인사이트는 애플리케이션 계층들간에 응답 정보를 집합시키고, 개별적인 트랜잭션에 대한 활동을 상호연관시켜 주는 알고리즘을 적용시킨다.
한편 시만텍은 지난 1월 인사이트 인콰이어(Inquire)를 소개했는데, 이 제품에는 기간 웹 애플리케이션의 가용성과 성능을 추적하는 종합 트랜잭션 모니터링 기능이 추가됐다. 인사이트 인콰이어는 종합 트랜잭션을 애플리케이션의 트랜잭션 흐름에 삽입시키고, 가용성과 성능을 모니터링한다. 여기서는 다른 추가 비용없이 다중 인스턴스들이 사용 가능하며, 지리적으로 서로 다른 위치의 설치 기반도 허용된다.
시만텍은 애플리케이션 성능에 주안점을 두고 있긴 하지만, 네트워크 성능으로의 가시성은 제공하지 않으며, 애플리케이션에서 무엇이 잘못됐는지 파악하기 위해서는 서버 에이전트가 필요하다.
HP의 머큐리 엔드 유저 매니지먼트(Mercury End User Management)는 엔드유저의 관점에서 웹 사이트와 애플리케이션 가용성을 실시간으로 미리 모니터링한다. 이것은 피플소프트(PeopleSoft), 오라클, SAP 등 업체들의 엔터프라이즈 애플리케이션과, 일반 웹용 애플리케이션에 대한 엔드유저 프로세스를 시뮬레이팅한다.
머큐리 리얼 유저 모니터(Mercury Real User Monitor)는 여러 곳에 많은 사용자들이 분산된 환경에서 종합 모니터링을 보완해 준다. 이것은 사용자 요청을 처리하는 특정 애플리케이션으로 가는 사용자 정보를 추적하며, IT 관리자가 문제를 잡아내기 위해 별개의 사용자나 시간대에 초점을 맞출 수 있게 해준다. HP는 제품과 라이선싱 모델이 다양해서 자신의 특별한 상황에 맞는 제품과 컴포넌트를 정확히 선택하기 힘들어하는 IT 전문가들도 많을 것 같다.
BMC의 퍼포먼스 매니저/트랜잭션 매니저(Performance Manager/Transaction Manager), IBM의 티볼리 컴포지트 애플리케이션 매니저(Tivoli Composite Application Manager), 넷아이큐의 앱매니저(AppManager), 그리고 퀘스트소프트웨어의 포그라이트(Foglight) 제품 또한 이 부문에서 강세를 보이고 있다.
네트워크 탐색자 모니터링
복잡한 엔터프라이즈 환경에서, 애플리케이션 성능 문제를 파악하고 해결할 수 있는 비결 중 하나는 애플리케이션 응답 시간을 다른 애플리케이션 및 네트워크 활동과 상호연관시키는 것이다. 넷스카우트의 엔지니어스(nGenius)는 핵심 비즈니스 애플리케이션의 테스트 응답 시간을 모니터링하고, 문제 분석을 위한 폭넓은 컨텍스트를 제공한다.
이것은 서비스 레벨 전달에 대한 애플리케이션 트래픽과, 엔드유저에게서의 문제를 장애관리하기 위한 통계를 테스트한다. 넷스카우트의 방안은 트래픽 양, 활용도, 에러 조건, 경보, 호스트, 대화 및 패킷 캡처 등과 같은 애플리케이션 응답 시간용 컨텍스트를 제공한다. 하지만 일단 성능 문제가 탐지되면 엔지니어스는 결함을 야기할 수 있는 애플리케이션의 컴포넌트가 무엇인지를 알려줄 수 있는 서버 에이전트를 제공하지 않는다.
넷QoS의 수퍼에이전트(SuperAgent)도 또한 데스크톱이나 서버 에이전트 없이 엔드유저 응답 시간을 추적 및 측정한다. 이것은 모든 TCP 애플리케이션 패킷이 네트워크를 통과해 갈 때 이들을 모니터링하며, 왕복 시간, 서버 응답 시간, 데이터 전송 시간 및 기타 통계를 측정할 수 있는 수단을 제공한다. 수퍼에이전트는 응답 시간을 기본 컴포넌트들, 즉 애플리케이션, 네트워크 및 서버 대기시간 등으로 나눈다.
넷QoS는 모든 트랜잭션에서 지속적으로 성능을 측정 및 분석하고, 베이스라인에 응답 시간을 비교해 보며, 성능이 저하될 때 IT에게 경보를 보낸다. 넷스카우트 제품에서와 마찬가지로 성능 문제가 탐지된 다음 애플리케이션 내의 정보를 확보하기 위해서는 퀘스트소프트웨어나 시만텍, 혹은 와일리 테크놀로지의 수집 에이전트 같이 다른 도구가 필요할 것이다.
모니터와 탐색자의 결합
모든 애플리케이션에 에이전트를 배치하기 어렵다는 사실을 깨닫고 있는 조직들도 있지만, 상당수의 조직에서는 수동적인 네트워크 프로브 기술을 이용해 네트워크에 있는 모든 애플리케이션 트래픽을 모니터링하는 한편, 에이전트 기술을 이용해 기간 시스템에서 보다 심도 깊은 모니터링을 제공하고 있다.
2006년 3월 CA에 인수된 와일리는 성눙 문제를 진단하는 데 필요한 상세한 정보를 수집할 수 있는 애플리케이션 에이전트와 네트워크 트래픽 분석기를 제공하고 있다. 와일리 인트로스코프(Introscope) 에이전트는 웹 애플리케이션 내부에 있는 다양한 컴포넌트들로부터 성능 데이터를 수집한 다음, 콜렉터 엔터프라이즈 매니저(Collector Enterprise Manager)로 이 정보를 보고한다. 이것은 성능 통계의 저장소 역할을 하면서 하나 이상의 인트로스코프 에이전트로부터 데이터를 수신하며, 사용자가 중앙에서 여러 애플리케이션, 애플리케이션 서버 및 지원 시스템의 데이터를 수집할 수 있게 해준다.
이러한 정보를 이용해 콜렉터 엔터프라이즈 매니저는 성능 데이터를 처리하며, 사용자가 생산 모니터링, 분류 및 진단을 하는 데 이것을 사용할 수 있게 해준다. 인트로스코프 방안에서는 에이전트가 자바 클래스로 로딩이 될 때 J2EE 애플리케이션의 바이트 코드 인스트루먼트를 사용한다.
우리는 지난 3월, 자사의 커스터머 익스피리언스 매니저(Customer Experience Manager) 어플라이언스를 보완해 줄 종합 트랜잭션 제품을 발표했는데, 이것은 실질적인 모든 트랜잭션을 모니터링한다. 이 어플라이언스는 스위치 레벨에 배치되며 SPAN 포트로 연결된다. 와일리는 기반 네트워크 성능 관리에 초점을 두고 있지 않으며, 네트워크나 애플리케이션 성능 데이터를 다른 시스템에서 자신의 시스템으로 통합 및 상호연관시킬 수 있는 편리한 방법도 제공하지 않는다.
퀘스트 또한 서버 에이전트 기술에 네트워크 프로브 분석을 결합시킨 툴을 제공하고 있다. 포그라이트 익스피리언스 모니터(Foglight Experience Monitor)는 네트워크 트래픽 모니터링을 사용하며, 네트워크 인프라와 애플리케이션에 미치는 영향을 최소화한다. 익스피리언스 모니터는 각 개별 사용자의 애플리케이션 상호작동을 추적하며, 그 데이터를 중앙 보고 플랫폼에 수집한다.
또한 특정 능동적 모니터링 솔루션에 초점을 둔 수많은 ‘카트리지(Cartridge)’들도 또한 포그라이트의 제품 라인에 포함돼 있다. 포그라이트 카트리지는 자바, 닷넷, 오라클, SAP 및 피플소프트 등 다양한 애플리케이션을 모니터링하며, 성능이 좋지 못한 트랜잭션에 대한 진단 정보를 수집한다. 포그라이트는 애플리케이션 문제를 검색할 수 있으며, 일군의 다른 제품들을 통해 이 부문에서 얼마간의 도움을 제공하고 있다.
APM의 한계
이상적이고 전체적인 APM을 곰곰이 생각해 보면 현실적으로 몇 가지 한계점이 있다. 성능 문제를 개선할 수 있는 능력은 APM 능력 이상의 외부적인 요인들에 의해 제약을 받을 수 있다. 예를 들어 문제가 애플리케이션 안에 있고, 테스팅이나 품질 검증시 발견되지 않았다면, 이것은 APM 영역 밖의 문제다. 성능 문제는 새로운 보안 패치 같은 변화의 결과물일 수 있으며, 이런 경우에는 구성 관리 업체들이 이런 변화를 되돌리고(rollback) 문제를 집어내야 한다.
차세대 애플리케이션 관리의 성공에서 가장 중요한 것은 네트워크, 시스템 및 애플리케이션 문제를 자동으로 상호 연관시키고, 이러한 문제를 해결하기 위한 개선 조치를 취할 수 있는 능력이다.
현재 나와 있는 전체적 APM 방안들이 완벽하지는 않지만, 조직, 특히 원활한 애플리케이션 성능에 수익을 의존하고 있는 곳에서는 기간 애플리케이션과 이들의 기반 컴포넌트 내에 있는 문제를 다스림으로써 경쟁에서 앞서 나갈 수 있어야 한다.
애플리케이션 성능 측정하기
APM이 필요한지 여부를 판단하기 위해서는 애플리케이션 성능이 회사 수익에 얼마나 영향을 미치는지를 신중히 평가해야 한다. 애플리케이션 성능이 비즈니스에 직접적인 영향을 미치지 않는다면 APM을 쓸 필요가 없을 것이다. 늘어나는 관리 작업, 배치 비용, 그리고 유지보수 비용 등은 이미 빡빡한 IT 예산에 더욱 부담만 늘릴 뿐이며, 기존의 컴포넌트 레벨의 모니터링과 관리 툴로도 충분하기 때문이다.
APM 아키텍처에 대한 결정은 복잡하긴 하지만, 기존의 엔터프라이즈 관리 컴포넌트를 이용해 맞춤 APM 서비스를 구축하려면 막대한 시간과 노력이 필요하며, 이는 유수의 업체들의 애드온 모듈을 사용하더라도 마찬가지다. 이에 대해 전체적 대안은 이러한 환경의 문제를 해결해 주는 새로운 방식을 제공한다. 하지만 IT 관리자들은 많은 APM 셋업에서 이들을 필요로 하기 때문에 새로운 애플리케이션 에이전트를 배치할지 마음을 정해야 한다. 대부분의 조직에서는 추가로 대행자를 배치하는 것을 감당하기 힘들고 복잡하다고 판단하겠지만, 심층적 애플리케이션 성능 측정에는 에이전트가 필요하다.
성능 문제에 대해 전반적인 생각을 하고 있다 하더라도, 새 시스템의 비용을 정당화하기 위해 그 영향을 측량하기는 쉬운 일이 아니다. 물론 애플리케이션 영향 평가에 이용할 수 있는 외부의 서비스들도 있다. 하지만 이들은 능동적(종합 트랜잭션) 모니터링만 수행할 뿐이다. 이렇게 되면 일단 문제가 탐지된 후 그 문제가 무엇인지를 판단하는 데 있어 큰 구멍이 남게 된다. 물론 아무 것도 하지 않는 것보다는 나으며, 문제가 있다는 사실을 확인하는 데는 유용하지만, 원인을 판단하는 데는 별 도움이 되지 않는다. 애플리케이션 서비스 사업자 제품의 일부로 평가 서비스를 제공하는 회사들로는 BMC, 키노트 및 머큐리 등이 있다. 이들은 고객의 종단간 웹 사이트 경험을 시뮬레이팅한다.
조직에서는 또한 스스로 영향을 평가해야 하는 과제를 떠안을 수도 있는데, 이는 모든 기간 애플리케이션을 항목별로 나누고, 지원 시스템을 포함해 물리적 아키텍처와 논리적 아키텍처의 다이어그램을 확보함으로써 시작할 수 있다. 이 때는 웹 서버, 애플리케이션 서버 및 데이터베이스와 같이 모니터링되고 있는 모든 애플리케이션 의존적인 컴포넌트들뿐만 아니라, 어떠한 특정 네트워크 컴포넌트나 외부의 서비스 사업자들까지도 고려해야 한다.
APM 제품 분류
능동/수동 분류법으로 간단히 구분짓지 말고, 다양한 데이터 수집 기술을 갖춘 제품들의 등장을 눈여겨 보아야 한다. 제품들을 보다 정확히 분류할 수 있는 지침으로는 다음과 같은 것들이 있다.
>> 종합 트랜잭션 소프트웨어: 인프라의 핵심 위치에 배치되어 애플리케이션 사용과 성능 결과를 시뮬레이팅하는 트래픽을 만들어낸다.
>> 네트워크 탐색자: 네트워크에서 물리적 장비로 상주하며, 보통 스위치에 있는 SPAN 포트에 연결된다. 이들 탐색자는 TCP 트래픽을 모니터링하거나, 웹 애플리케이션 세션을 모니터링함으로써 애플리케이션 트래픽을 모니터링 및 분류한다.
>> 서버 에이전트: 애플리케이션 서버에 배치돼 특정 통계에 대한 보고를 함으로써 애플리케이션 내부에서 발생하는 성능 문제의 원인을 파악해 준다. 일부 애플리케이션에서는 실시간으로 로딩될 수 있다.
>> 클라이언트 에이전트: 엔드유저 기계에 배치돼 API를 이용해 애플리케이션 성능을 모니터링하거나, TCP 소켓을 모니터링한다.
>> 시스템 에이전트: OS와 서버의 물리적 하드웨어 성능을 심층 관찰하며, CPU, 디스크 성능 및 기타 주요 컴포넌트들에 대해 보고한다.
>> API(application performance integration): 기존의 하드웨어, 시스템, 애플리케이션 및 네트워크 모니터링 데이터에 의존하며, 애플리케이션 성능 문제의 원인을 짚어낼 수 있도록 애플리케이션 서비스 레벨을 만들어 준다. BSM(Business-Service Management)이나 SLM(Service-Level Management) 소프트웨어라고 불릴 때도 있다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
