구름속APM, 데이터센터서 사용자 코앞까지

일반입력 :2013/03/30 13:22    수정: 2013/03/30 14:46

애플리케이션성능관리(APM) 분야가 시장에 알려진지 오래지만 올해는 특히 중요도가 높아진 것으로 평가된다. 모든 산업군의 기업들이 클라우드로 고객지원 프로세스를 옮기면서다. 이는 초창기 APM 시장의 형성 흐름과는 다른 양상이다. 데이터센터의 장비들이 제구실을 하는지에 그쳤던 APM의 역할은 기업 인프라를 벗어나 일반 사용자 브라우저까지 아우른 관점을 제공하는 것으로 확장됐다. APM전문업체 컴퓨웨어의 주장이다.

이달 중순 미국 지디넷 편집자 앤드류 누스카는 전 다이나트레이스 최고경영자(CEO)로서 APM분야의 진화를 목격해온 존 반 시클렌 컴퓨웨어 부사장을 상대로 이 주제에 대해 인터뷰했다. 시클렌 부사장은 최근 데이터센터에서 일반사용자 브라우저까지 아우르는 성능관리를 화두로바라보는 APM의 본질, 시장 변화에 따른 향후 전략에 대해 얘기했다.

그에 따르면 사실상 기업 전산 환경의 규모가 달라지면서 APM에 주어진 문제의 본질이 바뀌었다. 점차 기업들이 수익을 내기 위해 더 많은 애플리케이션을 다루게 된 환경에서, 전산 장애는 '절대로' 허용되지 않는 문제다.

누스카는 웹, 모바일, 스트리밍, 클라우드 등의 애플리케이션으로 점점 더 많은 수익이 창출되고 있는 기업들에게 애플리케이션의 증가는 문제가 되고 있다며 특히 엄청난 비용이 걸린 문제라면 ‘장애’와 같은 이유는 고객에게 용인되지 않는다고 지적했다.

아래는 누스카와 시클렌 부사장의 문답이다.

-처음부터 시작해봅시다. APM 시장은 어떻게 만들어졌나요?

APM은 시장의 선구적 기업인 IT관리업체 '머큐리(Mercury)'와 '와일리(Wily)', 트랜잭션성능관리(TPM)업체 '프리사이스(Precise)'에 의해 시작됐습니다. '네트워크가 곧 성능'이었던 시절도 되짚는다면 시스템모니터링업체 '티볼리(Tivoli)'까지 거슬러올라가죠. 꽤 오래됐다고 할 수 있어요.

이 회사들은 2005년 HP, IBM, 시만텍 등에 인수됐습니다. 초기 APM은 대형업체 통합소프트웨어(스위트)에 들어간 형태였죠. 시장이 움직이는 방식은 혼란기에 파편화됐다가 다시 통합되기 시작하는 식이었고요. 2000년대에 위축되고 통합되는 시기를 겪었어요. 당시 제품은 글로벌 1천대기업에 실제 구축됐는데요. 트레이딩, 신용카드, 소매 e커머스, 운송, 서비스업 등에 쓰였죠.

이 시기엔 문제 예방에 초점을 맞춰서 데이터센터에서 운영되는 애플리케이션을 감시하는 방식이 주를 이뤘죠. 처음엔 사람들이 하드웨어를 운용하는 방식을 흉내냈어요. 애플리케이션 구성요소들의 상태를 확인하기 위해 가상머신(VM)에 '파랑, 노랑, 빨강' 색으로 된 척도를 보여줬죠. 트랜잭션 완료여부가 아니라 단지 어떤 구성요소가 '양호'하다는 것만 알려준 셈입니다.

하드웨어 영역에선 문제가 있을 경우 어느 서버를 손봐야 할 지 알 수 있게 되지만, '1'과 '0'으로 이뤄진 소프트웨어는 달라요. 어딘가에 이상증세가 나타났다는 것만으론 근본 문제를 파악할 수 없죠. 사람 몸같은 (복잡한) 존재니까요. 그게 초기 통합된 세대의 APM 제품이 보인 양상이었어요. 이 시기는 제가 '완전한 복잡성의 난리(the perfect storm of complexity)'라 부르는 일련의 현상들이 불거진 시깁니다.

우리는 실제 생산영역의 환경을 가상화하기 시작했고, 애플리케이션 아키텍처 영역에선 구성요소별로 쪼개진 애플리케이션을 여러 서비스와 코드 덩어리가 엮인 복합형 애플리케이션까지 아우르기로 했습니다. 개발 방법론 관점에선 '폭포수'부터 '애자일'로, 1년에 1번이 아니라 1주에 1번씩, 이전보다 더 빠른 변화를 추구했죠. 저희가 기존에 갖춰온 낡은 시스템으로 다른 동기에 기반한 전혀 다른 세계의 폭발적 확산에 대응할 수 있었을까요? 환경이 견뎌주질 않았죠.

애플리케이션이 이전보다 더욱 중요해졌기 때문에 APM의 개념과 가능성도 한층 중요해졌습니다. 저희가 고객, 공급망, 나아가 모든 것과 관계를 맺고 있는 방식이죠. 복잡성과 변화는 더욱 커지고 있습니다. 복잡한 쿼리를 가져오는데 1초도 걸리지 않는 이른바 ‘구글 효과’로 인해, 사용자의 기대치도 덩달아 커졌어요. 이게 업계에 엄청난 압박을 줍니다.

모바일 쪽을 봅시다. IT복잡성을 폭증시키고 있죠. 브라우저도 마찬가지예요. 기업들의 애플리케이션이 모든 브라우저에서 제대로 돌아갈 수 있도록 보장하는 방법을 생각해 보면 그렇죠. 이 혼돈의 중심에 신규사업자들을 위한 기회도 있긴 합니다. 컴퓨웨어는 결국 고메즈나 다이나트레이스같은 미국 보스턴 소재 업체 몇곳을 인수했죠. 컴퓨웨어라는 이름 자체는 계속 살아남아왔지만, 몇년전의 선택은 혼란과 잠재적 기회를 동반했다는 점에서 APM에 대한 도박이었죠.

-APM에 대한 가장 흥미로운 것 중 하나는 개별 기업들이 APM을 쓰는 방식인데요. 산업별로 애플리케이션과 그 함의는 큰 차이를 보입니다.

저는 한때 미국 중서부 위쪽에 위치한 대형 소매업체를 방문했죠. 그 회사가 왜 빠른 속도로 대규모 물량을 처리하는데 우리 APM솔루션을 샀는지 의아했어요. 그 회사 최고정보책임자(CIO)는 이 의문에 대해 우리가 처한 업계 상황이 바뀐 탓이라 답했죠.

이제 그 회사는 모든 물량 단위의 모든 항목을 추적아이템들을 추적하고 있습니다. 운송과정상 상하기 쉬운 상품도 포함해서요. 그런 상품들이 상하기 전에 일련의 미국 식약청(FDA) 준수요건을 모두 맞춰야 하죠. 사실 회사가 이 상품들을 5분 이상 방치하긴 어려워요. 자동화된 선별포장처리를 해야죠. 운송조직도 완벽한 타이밍을 맞춰줘야 정상 제품들이 제때 매장에 진열될 수 있습니다. 만일 애플리케이션에 문제가 생긴다면 모든 과정이 멎어버리겠죠. 수작업으로 할 수 없어요. 연쇄반응 효과가 너무 크죠.

다른 사례를 들자면, NFL 슈퍼볼 시즌 광고를 내보냈던 자동차 매매 사이트 ‘Cars.com’가 있네요. 머리 작은 사람들이 불쑥 튀어나와서 말하기 시작하는 광고 보셨죠? 지난해 경기때 첫 방영됐는데, 그뒤 이 사이트 담당자들은 방문자가 폭증할 걸 예상했죠. 문제는 그들이 얼마나 늘어날지 감을 못잡았더란 거예요. 결국 담당자들은 30일 뒤 기존 애플리케이션에 수십가지 개선사항을 담아 정비했죠. 트래픽이 18배나 불어났거든요.

사실 새로운 APM은 단순한 예방책을 넘어서 애플리케이션 성능을 최적화하는 실질적인 방법이예요. 그 가치는 문제 관측 차원을 벗어나 애플리케이션 최적화와 더불어 엄청 신속한 문제해결까지 아우르게 됐지요.

-좋아요. 그럼 APM을 주도하는 요인은 뭐죠? 특정 산업영역인가요, 사용방식인가요?

요샌 금융서비스분야가 APM을 주도하는 것 같아요. 이 산업은 APM이 사업성패를 좌우하는 문제들을 안고 있죠. 모든 트랜잭션이 중요한데다 당국의 규제도 많이 받으니까요. 첨단기술도 곧잘 적용하구요.

e커머스도 APM을 주도하는 산업 중 하납니다. 온라인 종합 쇼핑몰 '자포스(Zappos)' 외에도 백화점 '시어스(Sears)'와 '메이시(Macy's)'나 소매 업체들이 사업 주요영역을 e커머스로 이전중이죠. 괄목할 상황이죠.

서비스와 여행 산업도 있습니다. 이게 e커머스냐고 묻는다면, 네 그렇습니다. 동시에 금융서비스이기도 하죠. 은행거래 서비스처럼요. 사람들이 항공편을 예약할 경우 전화를 거는 대신 온라인(웹사이트)으로 가잖아요. 10~12년 전에 10%였던 온라인 트랜잭션이 90%로 늘었어요. 이런 업체들은 고객들에게 더 적절한 서비스를 제공하도록 노력해 그들을 붙잡으려 하죠.

저희는 공공부문에 점점 더 많은 일들을 하고 있는데요. 공공영역엔 엄청 많은 온라인애플리케이션이 있고 그게 잘 돌아가지 않을 경우 대혼란이 생기죠. 제조산업분야도 같아요. 파트너와 공급망을 지속하는 측면에서요. 보험업계서도 사업규모와 고객충성도를 좌우하는 그들 역량 상당부분이 그들 애플리케이션의 안정성에 달렸죠.

이렇게 APM을 활용하지 않고 있는 경우 기업 활동에 심각한 불이익을 초래하게 됩니다.

-얘기중에 가장 궁금한 질문을 해야겠는데요. 그럼 왜 APM을 모든 기업들이 쓰지는 않는 거죠?

저희 사업상 최대 도전과제가 그런 기업들이 낡은 세대의 APM에 대한 인식을 걷어내는 겁니다. 많은 이들이 큰 비용을 들인 APM으로 이렇다할 가치를 얻지 못했다는 생각을 품었어요. 새로운 세대의 APM이 그런 과거 이슈를 상당수 해결했고 완전히 다른 관점에서 실제로 유효성이 입증됐다는 점을 말하고 싶네요.

APM을 안 쓰는 누군가에게 이 얘길 한다면 '그게 뭐냐'고 묻는 경우는 없을 거예요. 대신 '아 그거 비싸고 (쓰기) 어려워'라고 하겠죠. 또 그 회사가 큰 곳이라면 '응, 그걸로 수백만달러를 썼는데 대단한 성과는 못 얻었어'라고 말할 겁니다.

저는 새로운 고객들과 개념증명(PoC)을 수행하는 걸 거의 의무화했어요. 하는데 몇 분밖에 안 걸리고, 전 APM의 실익을 입증하고 싶으니까요. 애플리케이션을 구성하고 유지하는데 필요한 노력의 규모는 1천가지 요소로 줄었습니다. 하지만 그걸 기업들에게 보여줄 필요는 있죠. 마무리되기 전까지 믿지 않을 것이고, HP와 CA와 IBM같은 회사는 아예 그럴 수 없다고 할테니까요. 제때 가치를 줄 수 있느냐가 관건입니다.

관점의 문제예요. 기존 APM은 데이터센터에서 돌아가는 모니터링에 불과했죠. 사용자는 뭔가에 접근할 수 없어요. 모든게 '양호'한데 어떻게 그런 판정이 나왔는지, 안 되는 게 있을땐 어째야 하는지 답이 안 나오죠. 그래서 우리는 데이터센터에서 모니터링을 하는 게 아니라 브라우저부터 데이터센터까지 살펴보죠. IT담당자들이 사용자와 같은 관점을 얻게 돼요. 사용자 관점이 완전히 뒤집히는 거죠.

모든 사용자의 조작을 파악하는 e커머스를 예로 들죠. 이들은 불만사항에 대응하기 위해 데이터를 2주동안 보관합니다. 외부 관점에서 바라보는 헬프데스크 기능이 큰 비중을 차지하죠. 저희 초기고객사 가운데 하나인 자포스도 성능에 목을 맸어요. 그들은 사용자 관점을 선호했어요. 많은 논의를 통해 검증돼서죠.

저희는 이제 애플리케이션을 인프라에 연결하기 시작했습니다. 그것들이 디스크장애같은 걸 일으킨다면 즉시 그 영향을 받는 게 무슨 업무용 트랜잭션인지, 어떤 고객인지, 어느 장소인지 등을 찾아낼 수 있어요. 각 요소의 우선순위를 결정하는 것보다 훨씬 더 쉽죠.

-그럼 (APM업계) 향방이 어떻게 될거라 보시죠?

3개의 큰 궤적을 볼 수 있어요.

첫째로 그 구성요소 이상의 단일 시스템이 메인프레임, 닷넷, 브라우저, 하드웨어, 운영체제(OS), 하이퍼바이저 등 100가지 도구보다 적합한 수단이 될 겁니다. 팩트를 몇 안되는 곳에 통합하는 시스템이 얼마 남지 않게되면서 사용자가 더 크고 연관성 높은 뷰를 얻겠죠. 현업 IT가 일을 처리하기 훨씬 간편해질 겁니다.

둘째로 저는 이게 단지 실제 생산영역에 대한 인식만 강조하는 길로 이어지진 않을 것이라 예상합니다. 성능에 대한 관념은 테스트를 통해 추상화된 영역을 되짚어보거나 개발 영역으로 이어갈 필요가 있습니다. 저희는 이걸 '수명주기'라 부르는데 어떤 이들은 '디봅스'라 부르기도 하지요. 고립성이 거의 없으며 연속체 이상의 것으로 간주됩니다.

셋째는 분석입니다. 수명주기에 대한 '폭'과 '깊이'라는 2가지 전제 개념이 필요한데, 그 중심에 두뇌를 심는 거예요. 이 시스템들은 더 똑똑해져야 합니다. 저희는 문제 유형이 뭔지 알지요. 더 똑똑하고 탁월하고 정확하게 이상징후를 파악하고, 장애영역을 콕 짚어내고, 근본 문제 원인을 격리시키고, 데이터를 조사해 당신에게 스마트폰으로 뭐가 문제다 알려주게 돼 있는 시스템을 통해 전체 영역을 변경할 수 있다면 어떨까요? 데이터가 아니라 해답을 알려준다는 건 놀라운 아이디어죠.

확실히 그 기반에 빅데이터모델이 자리잡을 것 같아요. IT에 적용하면 굉장한 일이 되겠죠. 떠오를만한 의문이라면, 당신이 인텔리전스를 추출하기 위한 최상의 기초정보를 누가 갖고 있느냐는 것과, 문제와 관련된 광범위한 차원을 누가 조망할 수 있느냐는 거죠. 이건 말 그대로 베어메탈부터 운영체제(OS), 하이퍼바이저, 비즈니스트랜잭션 그 자체까지 해당하는 얘깁니다.

관련기사

-사업적인 목표를 어떻게 달성할 건가요?

전 정말 스마트한 연구개발인력을 데리고 있어요. 차세대 제품을 만드는 직원이 100명도 넘죠. 이 체제는 향후 3년간 지속될 겁니다. 정말 약동하는 시기죠. 전 업계에 30년동안 몸담아왔고 1990년대 중반부터 소프트웨어 인프라 분야에 있었어요. 지금보다 애플리케이션들이 이런 (APM같은) 종류의 소프트웨어를 필요로한 역사가 없었죠. 앞으로의 행보도 흥미로울 겁니다.