Scaling Factors
ABB의 소프트웨어 확장
로봇이 현장에서 점점 가치를 발휘하고 있음에 따라, 로봇을 직접 작동하는 사용자들에게 제공하는 서비스의 수준도 높아져가고 있다. 특히 최근에는 로봇이 현장에서 최상의 생산력에 기여할 수 있도록 통신을 매개로 한 관리도 이어지고 있다. 로봇을 원격으로 작동시키면서 고객의 요구에도 즉각적인 대응이 가능한 이 시스템은 로봇의 유지보수에서 앞으로 중요한 역할을 할 것으로 보인다. 본문은 이러한 역할을 수행하는 소프트웨어 기술에 대해 최근 ABB가 발표한 자료이다.
로봇은 어떤 생산라인에서나 제 역할을 묵묵히 수행하는 성실한 일꾼이기도 하지만, 고장 등의 문제가 발생하게 되면 큰 생산량 감소를 유발하기도 한다. 이 때문에 로봇 제조업체에서는 로봇이 생산현장에서 문제가 발생하지 않도록 노력을 기울이고 있으며 ABB 역시 고객들에게 유지보수와 관련된 서비스도 함께 제공해 현장에서 발생하는 문제를 최소화하고 있다.
이 서비스는 기본적으로 현장의 고객들과 지속적인 커뮤니케이션을 통해 로봇이 항상 최적의 기능을 유지할 수 있도록 관리하고 있으며, 서비스가 도입된 2007년 이래로 점차 많은 수의 로봇에 적용시켜왔다. 뿐만 아니라 이 소프트웨어를 통해 제공할 수 있는 기능도 점차 확산되어 가고 있는 추세이다.
ABB 또한 최근 이러한 요소들의 인프라를 향상시키기 위해 Back-end 시스템의 확장성과 성능 및 요구사항을 최적화 할 수 있는 방법을 연구 중이다.
ABB의 Back-end 시스템
피라미드 형태의 복잡한 구조를 가진 ABB의 Back-end 시스템은 생산성 뿐 아니라 다양한 서비스로의 확장까지 염두에 두고 제작되었다. 이 시스템은 기본적으로 통신을 통해 로봇의 원격 진단을 수행할 수 있게 설계되어 업계에서 직면하는 여러 문제에 대한 해결책으로 떠오르고 있다.
로봇 원격 진단 플랫폼으로 알려진 이 Back-end 시스템은 총 4가지 요소로 이루어져있는데, 그 중 첫 번째는 로봇 컨트롤러 자체에 연결된 서비스 박스창이다. 바로 이 박스창을 통해 현장에서는 ABB 내부의 Back-end라 불리는 다른 요소와의 커뮤니케이션을 이어가게 된다.
한편 이 Back-end는 액세스 포인트, 응용프로그램 서버 및 데이터베이스로 구성되어 있다. 먼저 액세스 포인트는ABB 내부 네트워크상의 어플리케이션 서버 및 데이터베이스와 고객사의 로봇 서비스 박스 사이의 정보의 흐름을 보장한다. 엑세스 포인트는 고객의 사이트에서 로봇의 서비스 창으로 흘러들어오는 데이터 흐름 및 ABB의 내부 네트워크에 있는 응용프로그램 서버와 데이터베이스를 보호하는 역할을 한다. 어플리케이션 서버는 원격 서비스 시스템의 심장에 해당하는 역할을 하는 요소로, 로봇의 유지와 보수에 필요한 진단을 수행하게 된다. 이 과정에서 발생되는 모든 데이터가 저장되는 곳이 마지막 요소인 데이터베이스이다.
최근 퍼포먼스와 서비스부분에서 로봇에 대한 요구사항이 늘어나고 있다는 사실은 많은 서비스 박스창들이 앞서 말한 세 가지의 Back-end 시스템과 상호작용을 하고 있음을 의미한다. 이 과정에서는 트래픽이 지속적으로 증가하므로 이로부터 Back-end의 용량을 확보하는 방법이 무엇보다 중요하다. 이를 위해 Back-end의 용량을 증가시키기 위해서는 세 가지 요소를 세밀하게 다시 설계해야 한다. 세 가지 Back-end 요소의 용량은 동일한 것이 이상적이며, 한쪽 요소의 용량이 너무 낮은 경우에는 다른 계층의 성능까지 저하시켜 일반적으로 느린 응답 시간과 처리지연이 발생하기 때문이다.
원격 진단 플랫폼의 확장성을 위해서는 먼저 많은 로드가 될 것을 대비해 수요보다 약간 높은 용량을 갖출 필요가 있다. 초기 단계에서 빠른 조사를 통해 방해요소를 제거한다면 56%에 이르는 용량 증가도 가능하다.
하드웨어 업그레이드를 통해 추가적으로 용량을 향상시킬 수 있지만, 사실 수요 증가와 서비스의 지속적인 확장은 1~3년 밖에 그 효과를 나타내지 못할 것으로 보인다. 장기적으로 비즈니스 목표를 지원하기 위해서는 지금의 열배 이상의 용량 증가가 필요한데, 이는 소프트웨어에 대한 처리기술과 안내 시스템 변화에 대한 로드맵이 요구되는 일이다.
시스템의 확장성을 위한 로드맵을 수립하기 위해서는 다음의 세 단계에 이르는 과정이 중요하다. 첫째는 현재의 성능에서 발생하는 방해요소들을 식별하고 측정하는 것이다. 소프트웨어의 병목현상은 웹서비스가 중지되거나 느려지는 등 소프트웨어의 루틴이 느려졌을 때 발생된다. 이러한 병목현상이 발생되면 하드웨어의 사용을 억제함으로써 효과를 얻을 수 있다.
두 번째는 시스템 구조와 자원이 만들어낸 가격모델에 대한 성과모델이며, 마지막은 각각 다른 로봇들을 예상해 그에 대한 성능수행방법을 시뮬레이션해보는 것이다.
모델 기반의 테스트를 바탕으로 제작된 이 로드맵은 비용절감 및 용량과 확장성을 모두 고려해 제작되었다.
▲ 그림 1. 원격 진단 서비스의 소프트웨어 구성
▲ 그림 2. 로봇 서비스 플랫폼에 따라 필요한 용량
병목현상(Bottlenecks)
정확한 성능 모델을 제작하려면 먼저 시스템의 성능을 이해하고 병목현상을 식별하는 것이 중요하다. 이 작업은 dynaTrace 1이라는 어플리케이션 프로그램을 통해 이루어지며, 이 프로그램은 통합 어플리케이션 성능 관리 및 성능 프로파일을 제공한다. 이 도구의 자동소스 코드 계측 및 분산 처리 추적 기술은 최근 .NET 플랫폼이 지원하는 58가지 도구에 선정되기도 했다. 이러한 서버 로그의 분석은 주로 성과처리나 발생빈도를 나타내준다. 수집된 정보는 실험을 통해 시스템의 작업 부하를 시뮬레이션 하기 위한 응용프로그램에 입력되며, 이 프로그램은 다양한 성능 측정(CPU 부하, 네트워크 지연)을 수행한다.
성능모델(Performance Model)
한편 데이터는 Palladio라는 소프트웨어 Architecture처리 시뮬레이션 툴 도구에 공급된다. 이 때 Palladio가 모델링에서 쓰는 언어는 업계 표준에 속하는 통합 표기법과 유사한 표기를 사용한다. 때문에 작성, 사용 및 모델과의 의사소통, 시뮬레이션이 용이하고 모델은 재사용과 대체 소프트웨어 처리를 조사하기 위한 재배열도 가능하다. 이 과정을 통해 추상적인 개념이 디테일해지고 예측의 정확도도 지속적으로 높아지면서 성능모델이 만들어 지는 것이다.
성능모델은 먼저 현재의 시스템을 재구성하는 작업이 이루어지는데, 이 과정에서 성능의 측정이 모델의 예측에 적용될 수 있도록 조정된다. 이후 작업량 및 다양한 시스템의 변화에 대해서도 정확한 예측을 할 수 있도록 모델의 견고함을 높여간다.
비용모델(Cost Model)
용량을 예측하고 제공하는 계획을 세우는 것은 성능만의 문제가 아니라, 하드웨어와 소프트웨어, 호스팅 비용 등 모든 비용도 고려해야 한다. 따라서 비용모델이라는 두 번째 문제를 해결하기 위해서는 여러 가격 목록을 기반으로 한 성능모델의 작성이 필요하다. 이렇게 되면 이 모델은 성능모델 단계에서 들어가는 비용까지도 함께 지정하게 된다.
만약 성능모델만으로 로드맵을 만든다면 이는 용량을 증가시키기 위한 목적만 달성할 수 있을 뿐 경제적인 요건은 반영되지 않을 것이다. 하지만 여기에 비용모델을 결합한다면 그만큼 용량을 높이는 데 들어가는 비용까지 고려한 가장 효율적인 변환계획에 도움을 줄 수 있다.
대안 설계 및 이동에 대한 로드맵
시스템이 수 십개에 달하는 구조를 수용하는 동안 열 배 이상의 용량 증가가 필요해졌다. 이러한 상황에서는 효율적인 용량관리가 중요하다. 예를 들면 필요한 기능을 적용해 현재 서비스의 책임을 나누어 여러 서버 사이에 배분할 수 있도록 더 나은 방법을 제공해 줄 수도 있으며, 들어오는 요구사항에 대해서도 각각의 전용서버에서 처리할 수 있도록 분리할 수 있다.
현실적으로 모델링이 제안하는 순서대로 실제 성능을 측정한다면, 시스템을 구현하고 배분하기에 많은 비용이 들어가게 된다. 비용문제를 해결하기 위해서는 성능모델을 변경한 여러 모델들을 대안으로 제시해 적합한 비용의 모델을 선택하게 하는 방법을 사용한다. 시뮬레이션을 수행하고 용량을 결정하는 각 대안들은 비용이라는 또 다른 측면까지 고려할 수 있어, 완성된 비용모델은 각 대안의 연간 운영비용까지도 제안해 줄 수 있다.
그림 4에 제시된 대안 2와 8을 살펴보면 각각은 5배와 10배라는 용량 증가를 제공하기 위해 비용 대비 가장 효율적인 솔루션을 제안한다. 대안 2는 시스템의 REST API(A Type of Distributed Web Service) 구현과 전용 서버에 데이터베이스 배분을 제안하는 반면, 대안 8은 여러 서비스를 호스팅하는 응용 프로그램 서버를 복제하고, 다양하게 들어오는 요청들을 배포하는 균형적인 조정 메커니즘을 제안하고 있다. 하지만 이 경우에는 바로 대안8을 실행할 것을 권하지 않는다. 대안 8이 지원하는 용량은 최소 몇 년 동안은 필요하지 않을 것이기 때문이다. 또한 대안 2와 8은 서로 호환이 가능하므로 지금은 대안 2로 이동한 후, 나중에 8로 옮겨가는 것도 하나의 방법이다. 이렇듯 이 방법은 10배 이상의 용량 증가가 필요한 상황에 대해서도 최적의 비용으로 효율적인 방법을 제공한다.
▲ 그림 3. 응답 시간 모니터링 및 서버 간의 흐름을 보여주는 dynaTrace 스크린 샷 |
▲ 그림 4. 대안에 따른 비용 |
IT 용량계획의 필요성 증가
제시된 확장성 접근 방식은 갈수록 다양한 요구가 이어지고 있고, 수준 높은 서비스가 필요해진 최근 시장에 대응하기 위해 개발되었다. 또한 ABB의 Back-end 시스템은 사람과 로봇, 로봇과 로봇의 대화가 필요한 상황에서도 유용하게 활용될 수 있다.
이는 또한 새로운 원격 진단 장치에 대한 고객의 요구를 채우는 데 유용하게 이용되는 한편, 확장된 소프트웨어 구조에 대한 논의는 ABB의 원격 진단 제품을 위한 청사진 역할을 할 것으로 기대하고 있다. 파워풀한 하드웨어가 단순히 용량 뿐 아니라 미래의 원격 서비스 솔루션에 도달하기 위해서는 그만큼의 충분한 역량을 갖추어야 하기 때문이다.
인터넷의 출현으로 인해 ABB는 높은 확장성을 가지는 Back-end를 증가시켜왔으며, 시스템의 적용을 확장해 사용자가 스마트 홈과 공장에서도 끊기거나 지연되지 않는 서비스를 이용할 수 있도록 여러 차원에서의 연구가 이루어지기도 했다. 이러한 과정을 통해 배운 확장성에 대한 접근 방법은 앞으로도 ABB가 확장 가능한 시스템을 구축하고 발생시켜 성능의 문제를 해결하는 데도 큰 도움이 될 것으로 보인다.
<필 자>
THIJMEN DE GOOIJER
ANTON JANSEN
HEIKO KOZIOLEK
STEVE MURPHY
<출 처>
「ABB review」 2012년 12월호 35~38p
