옵저버빌리티의 시대

뉴렐릭의 창립자인 류 선(Lew Cirne)이 개발한 애플리케이션 성능 모니터링(APM)은 데이터 센터에서 실행되는 모놀리식(일체식 구조의) 애플리케이션의 코드 가시성을 크게 향상시킨 것이 주된 혁신이었습니다. 그는 이러한 가시성을 모든 개발 및 운영 담당 엔지니어들이 서비스형 소프트웨어(SaaS)로 사용할 수 있도록 만들었습니다. 클라우드, 마이크로서비스, 컨테이너, 서버리스, 데브옵스(DevOps), 사이트 안정성 엔지니어링(SRE) 등 코드에서 운영 환경으로 소프트웨어를 가져오는 과정에서 발생하는 마찰이 줄어들어 새로운 기술과 관행의 속도가 빨라지면서, 복잡성은 더욱 가중되고 있습니다.  

애플리케이션 성능 모니터링을 개척하고 완성시킨 기업인 뉴렐릭은 현대의 소프트웨어 팀이 직면한 과제들에는 새로운 접근 방식이 필요하다고 생각합니다. 복잡성을 해결하고, 최신 시스템의 가용성을 유지하며 뛰어난 고객 경험을 제공하려면, 옵저버빌리티를 확보해야 합니다.

소프트웨어 업계에서 옵저버빌리티는 주목받고 있습니다. 그 이유는 옵저버빌리티가 현대 디지털 기업의 복잡한 환경에서도, 엔지니어들이 소프트웨어로 탁월한 고객 경험을 제공할 수 있게 해주기 때문입니다 .

하지만 한 가지 명확하게 하고 넘어가야 할 것은 옵저버빌리티가 모니터링의 동의어는 아니라는 것입니다.

모니터링은 계측을 제공하여 소프트웨어 팀이 시스템에 대한 데이터를 수집하고 오류 및 문제가 발생하면 신속하게 대응할 수 있도록 합니다. 다른 말로 표현하면, 모니터링은 문제가 발생할 경우 이를 파악하고 신속하게 대응하는 것을 목표로 시스템이 데이터를 수집할 수 있게 만드는 것이라고 할 수 있습니다.  

반면에 옵저버빌리티는 툴을 사용해 이러한 시스템을 계측하여 언제 오류 또는 문제가 발생했는지 뿐만 아니라, 그보다 중요한 왜 발생했는지 그 이유를 제공해주는 실행 가능한 데이터를 수집합니다. 팀이 소프트웨어에서 발생하는 긴급 상황을 신속하게 해결하고 대응하려면 모니터링이 아니라 옵저버빌리티가 필요합니다.

옵저버빌리티이 현대의 소프트웨어 팀에게 제공하는 혜택:

• 고품질 소프트웨어의 대규모 배포

• 지속 가능한 혁신 문화 구축

• 클라우드 및 최신 툴에 대한 투자 최적화

• 디지털 비즈니스의 실시간 성능 확인 

뉴렐릭은 메트릭, 이벤트, 로그 및 트레이스(M.E.L.T.)가 옵저버빌리티의 필수 데이터 유형이라고 생각합니다. 그러나 옵저버빌리티는 단순한 데이터 그 이상입니다.

시스템에 대한 옵저버빌리티를 어떻게 얻을 수 있을까요? 그리고 옵저버빌리티로부터 어떤 성과를 기대할 수 있을까요? 옵저버빌리티가 필요한 이유는 크게 네 가지의 도전과제를 해결하기 위함입니다. 조직은 이러한 과제를 해결하기 위해 개방형 계측, 데이터 연결, 프로그래머빌리티의 세 가지 구성 요소를 기반으로 하는 관찰 관행을 도입해야 합니다. 이 eBook에서는 관련 추세, 도전과제 및 구성 요소를 살펴보겠습니다.

지난 5~10년간 놀라운 속도로 이루어진 기술 혁신은 소프트웨어 팀에 엄청난 영향을 미쳤습니다. 주요 추세는 다음과 같습니다.

• 빠른 혁신에 대한 부담: 소프트웨어 팀은 경쟁업체보다 빨리 새로운 기능과 경험을 시장에 빠르게, 또 자주 출시해야 한다는 엄청난 압력을 받고 있습니다. 클라우드는 진입 장벽을 낮추고, 소프트웨어 팀이 이전보다 적은 리소스로 빠르게 배포 및 적응하도록 요구함으로써 경쟁을 부추겨 왔습니다. 높은 성과를 내는 팀들은 소프트웨어를 시간당 한 번, 하루에 한 번 배포하며 최고 수준의 팀들은 하루에 여러 차례 온디맨드로 소프트웨어를 배포합니다.

• 높아진 고객의 기대치: 고객의 기대치는 더 높아졌고 허용도는 더 낮아졌습니다. 고객들은 느리고 오류가 자주 발생하며 제대로 설계되지 않은 사용자 경험을 용납하지 않습니다. 고객이 앱이나 웹사이트를 방문한 목적을 달성할 수 없다면, 다시 방문하지 않을 것입니다. 모바일 앱 개발업체인 Dot Com Infoway에 따르면, 모바일 충돌, 멈춤 또는 오류가 발생할 경우 62%의 사용자는 앱을 제거하는 것으로 나타났습니다. 최고의 성과를 내는 소프트웨어 팀은 서비스 복구에 1시간이 채 걸리지 않는 반면, 성과가 낮은 팀은 1주에서 1개월 정도 걸립니다.1

• 다양한 기술 옵션: 오늘날의 조직들은 다양한 클라우드 공급업체와 컴퓨팅 플랫폼에 마이크로서비스 아키텍처와 분산 시스템을 구축합니다. 이러한 서비스들은 그 어느 때보다 쉽게 도입해 사용할 수 있으며, 점점 더 밀접하게 연동이 가능해지고 있습니다. 다양한 시스템과 서비스를 선택하여 최신 기술 스택에서 필요한 모든 것을 지원하는 동시에, 스택을 설정 및 유지 관리하는 데 필요한 핵심 작업만 추려 추상화할 수 있습니다.

• 데브옵스 및 자동화의 증가: 기업은 운영 과정에서 소유한 서비스의 포괄적인 설계, 배포 및 운영을 담당하는 자율적인 팀을 중심으로 조직을 구성하고 있습니다. 내부 플랫폼 팀이 서비스로 제공하는 공통 플랫폼과 툴을 활용하는 경우도 있습니다. 자동화는 반복적이고 가치가 낮은 작업(또는 노력)을 줄여주고 안정성을 향상시킵니다. 클라우드 네이티브 아키텍처에서는 스택의 모든 것이 소프트웨어로 제어되며, 전체 표면을 프로그래밍할 수 있습니다. 그리고 모든 자동화가 소프트웨어로 이루어지기 때문에 장애가 발생할 수 있습니다. 팀은 연속 통합/연속 배포(CI/CD)와 기타 자동화 툴을 고객에게 제공하는 애플리케이션과 마찬가지로 철저하게 모니터링해야 합니다. 시스템 내의  모든 구성 요소에 대한 데이터를 수집하는 것이 옵저버빌리티의 핵심입니다.

이러한 트렌드로 인해 현대 시스템에 대한 옵저버빌리티가 필요해지는 네 가지 주요 과제가 부상했습니다.

1. 복잡성 증가: 클라우드 네이티브 기술은 애플리케이션의 구축, 배포 및 운영 방식을 변화시켰지만, 이를 유지 관리하는 팀에게 더 큰 복잡성을 안겨주었습니다. 모놀리식 애플리케이션들은 컨테이너의 수명이 분 단위로 측정되는 마이크로서비스 형태로 리팩토링이 되기 때문에, 소프트웨어 팀은 갑자기 지속적으로 변화하는 서비스들을 지원하게 되었습니다. 각 개별 애플리케이션은 잠재적으로 수십 개의 마이크로서비스로 분해되기 때문에, 운영 팀은 대규모의 복잡성에 직면하게 되었고, 잘 알지 못하는 서비스들을 유지하고 관리해야만 하는 부담을 안게 되었습니다.

2. 위험 증가: 잦은 배포와 동적인 인프라는 더 많은 위험이 자주 발생한다는 의미입니다. 이렇게 증가한 위험으로 인해 즉각적인 감지 및 롤백이 훨씬 더 중요해졌습니다. 또한, 기업들이 애자일 관행과 연속 배포를 통해 소프트웨어를 더 빨리 출시할 수 있게 됨에 따라, (배포 툴과 파이프라인을 통해) 모니터링 및 유지 관리해야 하는 소프트웨어도 늘어나고 있습니다.

3. 기술 격차: 마이크로서비스 아키텍처가 폭발적으로 증가하면서 소프트웨어 팀은 애플리케이션 설계, 구축 및 배포 방식을 재고해야만 하였습니다. 또한 각 팀의 구성원은 이전에는 알지 못했던 애플리케이션의 일부를 이해하고 문제를 해결할 수 있어야 합니다. 예를 들어, 데이터베이스 전문가는 네트워킹은 물론 API에 대해서도 잘 알고 있어야 합니다. 문제는 팀원들이 익혀야 하는 새로운 기술의 수가 너무 많다는 것입니다. 때문에, 팀의 목표 달성이라는 맥락에서 이러한 기술을 효과적으로 이해할 수 있는 방법이 필요해 졌습니다.

4. 너무 많은 툴: 하이브리드 환경, 운영 중인 수천 개의 컨테이너, 하루 수 차례의 배포를 통해, 방대한 양의 운영 텔레메트리 데이터가 생성됩니다. 문제 해결에 가장 중요한 데이터를 찾거나 상관관계를 구축하느라 여러 모니터링 툴과 필요한 문맥 사이를 오가며 소중한 시간을 허비하다가, 정작 고객측 경험에 문제가 생기면 해결할 시간이 부족해집니다.

이러한 트렌드와 당면 과제, 그리고 전반적인 기술 변화의 속도를 고려하면, 팀은 적은 노력과 시간으로 복잡성과 위험을 줄여주는 단일 솔루션이 필요합니다. 이러한 솔루션은 기술 격차를 해소해 주어야 하며, 쉽게 사용 및 이해가 가능하고 중요한 문맥을 수집할 수 있게 해주어야 합니다. 이 솔루션을 통해 조직 내 모든 팀은 한 곳에서 모든 관찰 데이터를 볼 수 있어야 하며, 신속하게 의미를 도출하고 적절한 조치를 취하는 데 필요한 문맥을 확보할 수 있어야 합니다.

1. “Accelerate: State of DevOps 2019,” DORA, 2019년 9월

모니터링의 역사는 Unix의 시대(1971년 첫 버전 발표)로 거슬러 올라가지만, 애플리케이션 성능 모니터링(APM)이라는 용어가 널리 사용되기 시작한 것은 2000년대 초반 부터입니다. 그 이후, 모니터링은 진화를 거쳐 클라우드를 비롯, 전체 기술 스택에 걸쳐 성능 및 사용자 경험에 대한 세부적인 측정 지표, 추적 및 알림을 제공할 수 있게 되었습니다.

오늘날 환경이 점점 더 복잡해지면서, 옵저버빌리티는 소프트웨어 팀과 조직의 성공에 매우 중요한 역할을 하게 되었습니다. 옵저버빌리티는 팀들에게 실시간으로 모든 성능 데이터를 연결해 한 곳에서 확인하고 문제를 더 신속하게 파악하며, 문제의 근본 원인을 이해하여 궁극적으로 탁월한 고객 경험을 제공할 수 있도록 합니다.

옵저버빌리티는 완전히 새로운 개념은 아닙니다. 엔지니어링 및 제어 이론에서 기인한 이 개념은 헝가리 출신의 미국 엔지니어 루돌프 E. 칼만(Rudolf E. Kálmán)이 선형 동적 시스템에서 처음 도입했습니다. 엔지니어링 및 제어 이론에 적용된 옵저버빌리티의 일반적인 정의는 ‘외부 데이터로부터 시스템 내부 상태를 얼마나 잘 유추할 수 있는지에 대한 척도’ 입니다.

옵저버빌리티는 소프트웨어의 수명주기 전반에서 시스템 운영에 대한 포괄적인 이해를 돕기 위해 메트릭, 이벤트, 로그 및 트레이스를 수집, 시각화 및 분석하는 것을 아우릅니다. 무엇이 잘못되었는지를 보여주는 모니터링과 비교해, 옵저버빌리티는  무엇이 '왜' 잘못되었는지를 보여줍니다.

Uber Technologies의 소프트웨어 엔지니어이자 작가인 유리 슈쿠로(Yuri Shkuro)는이러한 방식의 차이를 “모니터링은 사전에 결정된 중요한 사항을 측정하지만, 옵저버빌리티는 시스템에 대해 미리 알지 못하는 부분에 대한 질문을 할 수 있는 역량”이라고 설명합니다.

앞서 언급했듯이, 뉴렐릭은 메트릭, 이벤트, 로그 및 트레이스가 옵저버빌리티에 필수적인 데이터 유형이며, 종종 간과되는 이벤트는 모든 관찰 솔루션의 일부가 되어야 하는 중요한 텔레메트리 데이터라고 생각합니다. 이에 대해서는 뒷부분에서 다시 자세히 설명하겠습니다. 궁극적으로, 모든 것을 계측하고 텔레메트리 데이터를 사용해 시스템 내의 관계와 종속성은 물론, 성능과 상태에 대한 기본적인 실무 지식을 구축하고 있다면, 옵저버빌리티를 활용하고 있는 것입니다.

그러나 뉴렐릭의 접근 방식은 거기에서 한층 더 나아가 옵저버빌리티의 세 가지 핵심 요소에 대한 강한 확신을 줍니다.

지금까지 옵저버빌리티를 오류 또는 문제가 발생한 시기뿐만 아니라 발생한 이유를 제공해주는 실행 가능한 데이터를 수집하기 위한 시스템 계측 관행으로 정의했습니다 . 발생한 이유에 대한 답을 제공하는 역량은 팀이 어떻게 근본 원인을 해결하고 시스템의 안정성을 보장하는지에 달려 있습니다. 시스템의 옵저버빌리티를 확보하려면 세 가지 핵심 요소가 필요합니다.

1. 개방형 계측: 애플리케이션, 서비스, 인프라 호스트, 컨테이너, 클라우드 서비스, 서버리스 함수, 모바일 애플리케이션 또는 데이터를 생성하는 기타 모든 소스에서 수집된 오픈 소스 또는 공급업체별 텔레메트리 데이터의 컬렉션으로 정의될 수 있으며, 개방형 계층은 비즈니스에 핵심적인 애플리케이션과 인프라의 전체 영역에 대한 가시성을 제공합니다.

2. 엔티티 연결: 텔레메트리 데이터를 생성하는 엔티티들을 식별하고 연결하려면, 모든 텔레메트리 데이터를 분석해야 하며, 엔티티와 해당 데이터 간의 상관 관계를 생성하려면 메타데이터를 통합해야 합니다. 이러한 두 가지 작업은 대량의 데이터에서 문맥과 의미를 생성합니다. 이러한 맥락에서 큐레레이션은 별도의 설정이 필요없는 시스템 또는 기술의 시각적 모델로서 제공될 수 있습니다. 엔티티 연결을 통해 얻을 수 있는 또 다른 혜택은, 인텔리전스를 적용해 더 많은 의미를 도출할 수 있다는 것입니다. 응용 인텔리전스는 인간이 의사 결정을 내리고 조치를 취할 수 있도록 머신 러닝과 데이터 과학을 응용해 데이터에서 패턴이나 이상 징후를 찾아내는 것입니다.

3. 프로그래머빌리티: 모든 비즈니스는 고유하기 때문에, 비즈니스의 다양한 요구를 충족하거나 모든 사용 사례에 맞게 큐레이션을 자동화할 수는 없습니다. 기업은 중요한 비즈니스 데이터와 차원들을 혼합해 모든 텔레메트리 데이터를 기반으로 고유한 문맥과 큐레이션를 생성할 방법이 필요합니다. 이러한 필요성을 인지하고 고객에게 모든 텔레메트리 데이터를 기반으로 애플리케이션을 구축할 수 있는 역량을 제공한다는 측면에서 뉴렐릭은 고유합니다. 한 가지 예를 들면, 뉴렐릭은 비즈니스 프로세스에서 오류와 장애의 비용을 명확하게 보여주고, 이러한 장애에 실제 비용을 합산해 표시해주며, 데이터를 세부 분석해 이유를 찾을 수 있는 경로를 제공합니다.

최신 소프트웨어를 지원할 수 있도록 옵저버빌리티가 어떻게 진화하고 있는지에 대한 보다 자세한 내용을 원하시면 옵저버빌리티의 10가지 원칙: 최신 소프트웨어를 사용한 성공의 경로에 대한 지침을 확인해보시기 바랍니다.

뉴렐릭이 설립된 2008년, 옵저버빌리티를 확보하기 위해 텔레메트리를 수집하는 가장 좋은 방법은 에이전트를 사용하는 것이었습니다. 소프트웨어 개발자와 운영 팀들은 애플리케이션 및 호스트 내에 에이전트를 배포했으며, 이러한 에이전트는 메트릭, 이벤트, 트레이스 및 로그 데이터를 수집해 독점적인 방식으로 패키징하여 집계 및 표시에 이용되도록 전송해 주었습니다.

지금까지도 이는 텔레메트리 수집을 위한 효과적인 방법임에도 불구하고, 업계는 변화하고 있습니다. 이제 텔레메트리 소스가 더 많이 존재합니다. 소프트웨어 개발을 지원하는 많은 오픈 시스템과 프레임워크에는 메트릭, 이벤트, 로그 및 트레이스를 보편적인 형식으로 내보내는 기능이 내장되어 있습니다. 옵저버빌리티를 위해서는 오픈소스와 독점소스 모두에서 데이터를 수집하고 한 곳에 결합해야 합니다. 적절한 위치에 자동으로 계측을 적용하고, 가시성이 가장 필요한 곳에 계측을 추가해야 합니다.

M.E.L.T. : 신속한 고장

대부분의 경우 , 메트릭은 옵저버빌리티를 위한 출발점입니다. 메트릭은 낮은 오버헤드로 수집이 가능하고 저장 비용이 적게 들며, 여러 차원에서 빠른 분석이 가능하여 전반적인 상태를 측정하는 좋은 방법입니다. 이 때문에 Prometheus, Telegraf, statsd, DropWizard, Micrometer와 같은 메트릭 수집용 툴도 많이 등장했습니다. Elasticsearch와 같이, 시계열에 친화적인 오픈 데이터스토어를 기반으로 메트릭을 수집하기 위해 자체적으로 고유한 형식을 만드는 기업들도 많이 있습니다. 관찰 솔루션은 다양한 팀들이 현대의 디지털 기업에 도입하는 이러한 모든 소스의 메트릭을 사용할 수 있어야 합니다.

트레이스는 분산 아키텍처에서 각 호출의 전체적인 레이턴시를 표시하는 데 유용합니다. 이러한 호출은 시스템을 통과하는 수많은 고객 여정에 대한 구체적인 인사이트를 제공합니다. 트레이스는 엔지니어들이 이러한 여정을 이해하고 병목 현상을 찾아내어, 오류를 식별하여 수정하고 최적화할 수 있게 해 줍니다. 메트릭과 유사하게, 정교한 조직들이 만든 맞춤형 솔루션으로부터 수많은 툴(Jaeger, Zipkin, AWS X-ray 등)이 등장했습니다.

W3C Trace Context 는 곧 프로세스의 경계를 넘어 “트레이스 컨텍스트"의 확산을 위한 표준이 될 것입니다. 트레이스 컨텍스트는 시스템을 통과하는 데이터 흐름을 추적하는 표준 방법을 제공하며, 복잡한 분산 시스템 전반에서 발생하는 호출(상위 호출 및 하위 호출)을 추적합니다. 개발자가 표준 트레이스 컨텍스트를 사용하면, 여러 다른 시스템의 스팬들을 서로 안정적으로 결합하여 단일한 관찰 플랫폼에서 표시 및 검색되게 할 수 있습니다. 트레이스 컨텍스트에는 또한 검색 및 상관 관계를 더욱 강력하게 만들어주는 중요한 태그와 메타데이터도 포함되어 있습니다.

CNCF(Cloud Native Computing Foundation)의 일부인 OpenTelemetry 프로젝트는 메트릭과 트레이스 수집을 하나의 오픈 포맷으로 결합합니다. OpenTelemetry를 채택하는 조직이 늘어남에 따라, 런타임 시 바이트코드 계측을 위해 에이전트를 실행할 필요가 없는 보다 표준적이고 일반적인 계측이 나올 것으로 기대됩니다. CNCF의 쿠버네티스와 Istio 같은 툴의 광범위하고 빠른 도입을 고려할 때, OpenTelemetry는 텔레메트리의 소스로서 현대 소프트웨어에서 보편화될 가능성이 높습니다.

로그는 엔지니어가 '딥' 디버깅 모드에서 문제를 이해하려고 할 때 중요합니다. 로그는 이벤트와 관련된 정확한 데이터와 상세한 문맥을 제공하므로, 엔지니어는 발생한 문제를 밀리초 단위로 다시 구성할 수 있습니다. 메트릭과 트레이스와 마찬가지로 로그를 수집, 필터링 및 내보내기하는 수고를 줄여주는 툴도 등장했습니다. 보편적인 솔루션인 Fluentd, Fluent Bit, Logstash, AWS CloudWatch 이외에도 다양한 최신 표준들이 나와 있습니다.

메트릭, 로그 및 트레이스에 대한 이러한 모든 프로젝트는 모든 것이 포함된 접근 방식을 통해, 모든 사람이 계측 기능을 쉽게 사용할 수 있는 미래를 구축하고 있습니다.

이벤트는 관찰 솔루션의 일부가 되어야 하는, 중요하지만 간과되는 텔레메트리 유형입니다. 이벤트와 로그는 몇 가지 유사점이 있기 때문에 종종 혼동되곤 합니다. 이벤트는 중요한 분석 지점에 대한 세부적인 개별 기록입니다. 하지만 로그가 제공하는 세부 수준보다 추상화 수준이 더 높습니다. 로그는 시스템 내에서 발생한 모든 것에 대한 종합적이고 개별적인 기록입니다. 이벤트는 정확한 문맥을 제공하기 위해 기록에 첨부되는 메타데이터에서 발생한 선별된 중요 사건에 대한 기록입니다. 예를 들어, 뉴렐릭은 트랜잭션 이벤트를 수집합니다. 트랜잭션 이벤트는 메서드 실행이나 프로세스 코드 블록의 개별 인스턴스로, 데이터가 자동으로 추가되어 실행된 데이터베이스 호출의 수와 호출의 지속 시간을 표시해 줍니다.

이벤트란?

이벤트는 옵저버빌리티를 위한 가장 중요한 데이터 유형입니다. 이벤트는 로그와는 다릅니다. 이벤트는 중요한 분석 지점에 대한 세부적인 개별 기록이지만 로그에서 제공하는 세부 정보보다 더 높은 수준의 추상화를 제공합니다. 알림과 배포는 이벤트입니다. 트랜잭션과 오류도 마찬가지입니다. 이벤트는 실시간으로 세분화된 분석을 수행할 수 있는 역량을 제공합니다.

필수적인 계측을 제공하는 대부분의 오픈소스 툴은 데이터를 수집, 저장 및 분석할 수 있도록 별도의 데이터 저장소가 함께 제공되지만, 이는 옵저버빌리티의 유용성을 저해합니다. 엔지니어와 팀들이 여러 툴에 대해 배우고 이해해야 하기 때문입니다. 통합된 데이터 저장소가 없다면, 문제나 더 심각한 긴급 상황이 발생할 때 엔지니어는 여러 툴의 문맥을 상황에 맞게 전환하여 문제의 원인을 찾아야 합니다. 오픈 관찰 솔루션은 소스와 관계없이 이 모든 데이터에 대한 상호 운용성을 제공합니다. 그리고 자동으로 엔티티를 생성하고 상호 연결하여 중요한 문맥을 제공합니다.

모든 텔레메트리 데이터를 한 곳으로 가져오는 것은 좋은 시작점이지만 그것으로는 충분하지 않습니다. 엔티티 간의 관계를 이해할 수 있도록 데이터를 연결하고, 메타데이터와 상호 연결되어 있어야 비즈니스와의 관계를 이해할 수 있습니다. 이러한 연결은 데이터에 대한 문맥과 의미를 제공합니다. 예를 들어, 문맥은 데이터에 대한 가장 중요한 정보를 표면화해 정리한 뷰로 연결되며 특정 환경을 모델링합니다. 또한 모든 텔레메트리 데이터 및 연결이 한 곳에 저장되어 있는 경우, 대규모 데이터 세트에 인텔리전스를 적용하고, 사용자가 대시보드를 통해 쉽게 식별할 수 없는 패턴, 이상 징후 및 상관 관계를 부각시킬 수 있습니다.

기본적으로 언제, 어느 때라도 시스템의 모든 엔티티가 어떻게 서로 연결되어 있는지 볼 수 있는 방법이 필요합니다. 시스템이 시시각각으로 바뀌는데 시스템에 대한 정적인 맵을 유지하는 것은 불가능합니다. 이러한 관계의 관리를 설정에만 의존하는 것도 불가능합니다. 팀이 새로운 서비스를 추가하고, 기존 서비스를 리팩터링하고, 일시적으로 애플리케이션의 인스턴스를 스핀업하고 종료하는 상황에서 정적인 맵을 유지하는 것은 불가능해집니다. 그러나 엔티티와 이들의 연결 및 관계는 옵저버빌리티를 위한 필수적인 문맥 중 하나입니다.

메타데이터와 차원이 없으면 문맥을 얻을 수 없습니다. 시스템, 비즈니스 또는 애플리케이션에 따라 중요해지는 데이터의 범위는 엄청나게 커질 수 있습니다. 예를 들어, 이커머스 애플리케이션의 경우 유용한 문맥에는 다음이 포함될 수 있으며, 이에 국한되지는 않습니다.

• 애플리케이션, 런북 및 코드 저장소를 소유한 팀에 대한 세부 정보

• 도커의 태그와 도커를 배포한 클라우드 제공업

• 서비스 유형 및 함수

• 배포된 지역

• 업스트림 및 다운스트림 종속성

• 배포 또는 변경 이벤트

• 알림 상태

• 수행하는 트랜잭션과 관련된 모든 트레이스 또는 로그 데이터

• 추가적인 비즈니스 데이터(예: 장바구니 금액)

데이터 시각화의 큐레이션은 연결되어 쉽게 이해할 수 있도록 잘 정의된 엔티티를 표면화시켜 주는 강력한 툴입니다. 컨테이너에서 실행되는 Java 애플리케이션 프로세스나 SQS의 호출 후 DynamoDB를 호출하는 AWS Lambda 함수, 또는 동적 배포를 실행하는 쿠버네티스 클러스터를 가장 잘 표현하는 방법은 잘 알려져 있고 이러한 문제들은 이미 해결되었습니다. 바쁜 SRE 또는 데브옵스 엔지니어가 대시보드에서 이러한 환경을 모델링하는 것은 귀중한 시간을 낭비하는 일입니다. 관찰 플랫폼은 업계 리더들의 모범 사례를 통합하고 가장 중요한 상태 신호들을 표면화시킬 뿐만 아니라 엔지니어가 문제를 빠르게 해결할 수 있는 쌍방향 경험을 제공해야 합니다. 보편적인 특정 기술을 위해 수동으로 대시보드를 만들고 시각화하는 일은 많은 시간과 노력이 필요한 일입니다.

문맥을 통한 큐레이션도 복잡한 디지털 기업의 기술 격차를 해소하는 데 도움이 됩니다. 조직의 모든 구성원이 복잡한 시스템들의 흐름과 종속성을 시각화하고 전체 환경과 관련된 모든 것을 볼 수 있는 방법을 제공합니다. 이러한 큐레이션이 다양한 시스템을 잘 모델링해주기 때문에 특정 기술이나 코드에 익숙하지 않은 사람도 쉽게 이해할 수 있습니다.

시스템이 제대로 작동하지 않을 때 신속하게 조치를 취할 수 없다면 옵저버빌리티는 아무런 의미가 없습니다. 머신 러닝과 예측 분석을 통해, 응용 인텔리전스는 관찰 데이터를 가져다 의미 있고 실행 가능한 데이터로 만듭니다. IT 운영을 위한 인공 지능으로 산업 분석 기업 Gartner가 AIOps라고 부르는 응용 인텔리전스는 기업이 노이즈 속에서 신호를 찾아내어 적절한 조치를 취할 수 있도록 합니다.  

응용 인텔리전스는 데이터 세트가 크고 복잡한 경우에도 명확한 지침을 제공합니다. 기계는 인간의 힘으로는 불가능한 규모의 데이터에서 패턴, 추세 및 오류를 식별할 수 있습니다. 올바른 응용 인텔리전스 역량은 텔레메트리 데이터로부터 신속하게 문제를 감지하고, 이벤트의 상관 관계를 파악해 우선순위를 지정하여 노이즈와 알람 피로를 줄여줍니다. 응용 인텔리전스는 문제의 진정한 근본 원인과 해결 방법을 신속하게 파악하는 데 도움이 되는 권장 사항은 물론, 관련 문맥, 지침 및 제안 사항을 제공해 인시던트 알림을 자동으로 강화할 수 있습니다.

다음은 응용 인텔리전스의 예시입니다. 팀이 애플리케이션의 응답 시간 임계값이 위반되었다는 알림을 받습니다. 인텔리전스는 알림 발생 6시간 이전부터 애플리케이션과 관련된 처리량, 지연 오류 및 트랜잭션 신호를 자동으로 검사합니다. 이 시나리오에서 인텔리전스는 애플리케이션이 의존하는 데이터 저장소에서 레이턴시를 감지하고 데이터베이스 문제와 애플리케이션의 느린 응답시간 간에 직접적인 관련이 있다는 사실을 밝혀줍니다. 이 시나리오에서 기업이 얻는 이점은 두 가지입니다.

1. 응용 인텔리전스가 이미 중요한 문제 해결 분석을 수행하고 평균장애복구시간(MTTD)을 감소시켰기 때문에, 팀은 기저 문제를 보다 신속하게 해결하고 평균해결시간(MTTR)을 줄일 수 있습니다.

2. 더 많은 데이터를 사용해 훈련이 되면, 응용 인텔리전스는 더욱 유용해지고 사소한 알림이나 잘못된 알림에서 노이즈를 걸러낼 수 있기 때문에, 팀은 전체적인 알림 피로를 크게 감소시키고 더 나은 소프트웨어를 더 빨리 출시하는 데 집중할 수 있게 됩니다.

의존성을 시각화하고 텔레메트리 유형을 실시간으로 세부 분석할 수 있으면, 시스템 문제를 보다 빠르고 쉽게 이해하고 해결하여 데이터 이면에 감춰진 이유를 파악할 수 있습니다. 시스템이 기술 환경을 자동으로 효과적으로 모델링해 일목요연하게 시각화 해 주면, 모든 사람이 근본 원인을 쉽게 찾을 수 있습니다. 또한 대규모 데이터 세트에 인텔리전스를 적용하면, 데이터 간의 연결 관계가 나타나 어려운 상황에서도 가장 효과적인 의사 결정을 내릴 수 있습니다.

관찰 데이터를 비즈니스 결과와 연결하는 것은 성숙한 디지털 비즈니스가 되기 위해 조직이 취해야 하는 중요한 단계입니다. 성공을 위한 중요한 비즈니스 척도를 시작으로, 해당 메트릭의 달성에 직접적으로 기여하는 핵심 성과 지표(KPI)를 파악해야 합니다. 레이턴시, 오류 또는 페이지 로드 같은 메트릭은 애플리케이션 성능을 이해하는 것에는 도움이 되지만, 애플리케이션이 고객 경험이나 비즈니스 KPI에 미치는 영향을 이해하는 데는 도움이 되지는 않습니다.

이러한 이유로 옵저버빌리티를 비즈니스에 연결하고, 팀에게 데이터에 기반해 의사 결정을 내리는 데 필요한 인사이트를 제공하는 것이 중요합니다. 이제 관건은 어떻게 제공하는가 입니다.  

대부분의 솔루션의 경우, 해답은 대시보드에서 KPI를 시각화하는 것입니다. 대시보드는 데이터에 대한 뷰를 즉석에서 표시해주는 유용한 툴입니다. 대시보드는 모든 관찰 솔루션에서 필수적인 유연하고 강력한 툴입니다. 하지만 기업의 고유한 비즈니스 기술 환경과 KPI를 고려할 때, 대시보드를 넘어서, 디지털 비즈니스에 대한 데이터를 가져와 이를 텔레메트리 데이터와 결합할 수 있도록 애플리케이션을 구축하는 것이 그 어느 때보다 중요해졌습니다. 관찰 플랫폼을 기반으로 비즈니스 데이터를 연결함으로써, 애플리케이션은 상호 작용이 가능한 큐레이션된 환경을 제공합니다. 애플리케이션에는 기본적으로 워크플로우가 내장되어 있는 경우가 많으며, 이는 외부 데이터 세트를 실시간으로 조합할 수 있게 해줍니다. 대시보드로는 불가능하지만, 애플리케이션으로는 할 수 있습니다. 

애플리케이션에서 비즈니스와 텔레메트리 데이터를 연결하려면, 관찰 솔루션이 이를 기반으로 구축을 할 수 있는 플랫폼이 되어 주어야 합니다. 즉, 프로그래밍이 가능해야 합니다.

사용자의 고유한 니즈에 맞게 애플리케이션을 구축할 수 있는 관찰 플랫폼이 있다면, 관찰 툴을 통해 이전에는 불가능했던 다음과 같은 작업들이 가능해집니다.

• 소프트웨어에 대한 투자의 우선순위를 정하고 이러한 투자의 효과를 실시간으로 측정할 수 있습니다.

• 기술, 비즈니스 및 고객 간의 관계를 풍부한 문맥으로 이해할 수 있습니다.

• 특정 KPI에 가장 크고 직접적인 영향을 주는 데이터에 기반해 의사 결정을 내릴 수 있습니다.

• 기술 환경뿐만 아니라 고유한 비즈니스를 모델링하도록 구축된 쌍방향 시각화를 통해 정보를 공유할 수 있습니다.

마지막으로, 프로그래밍이 가능한 관찰 플랫폼은 팀들이 다른 툴을 배포할 필요 없이 단일한 기록 시스템에서 그러한 기능을 갖춘 애플리케이션을 구축할 수 있게 해줍니다. 이를 통해 여러 가지 혜택을 얻을 수 있습니다. 응급 상황에서 툴 간의 문맥 전환을 감소시키고, 다른 시스템을 프로비저닝, 운영, 유지 관리 및 모니터링하는 데 드는 시간과 수고를 줄이며, 다른 툴을 구입, 구축 또는 익히는 데 드는 비용을 줄일 수 있습니다.

소프트웨어 혁신이 진행됨에 따라 세계는 더 빠르게 이동하고 더 복잡해 질 것입니다. 불과 몇 년 전만 해도 현재의 기술과 기술 트렌드를 예상할 수 없었습니다. 마찬가지로, 앞으로 어떤 혁신이 일어날지 알 수 없습니다. 우리가 알고 있는 것은 이러한 지속적인 혁신과 복잡성으로 인해, 팀이 더 빠르게 움직이고, 더 많은 기술을 수용하며, 오류 없이 빠른 속도로 작업을 수행해야 한다는 기대치가 계속 높아질 것이라는 사실입니다. 또한, 더 많은 것을 자동화하고 경쟁업체 등 다른 기업이 정한 고객의 기대치에 부응하여 최첨단 고객 경험을 제공해야 한다는 것입니다.

이러한 도전과제를 고려한다면, 낮은 오버헤드로 복잡성과 위험을 줄여주는 단일 관찰 플랫폼이 필요합니다. 쉽게 사용과 이해가 가능하고 핵심 문맥을 수집함으로써 기술 격차를 해소해주며 조직 내의 모든 팀이 플랫폼을 사용하는 데 장애가 되지 않는 플랫폼이 필요합니다. 팀이 모든 텔레메트리 및 비즈니스 데이터를 한 곳에서 볼 수 있고, 의미를 빠르게 도출해 적절한 조치를 취하는 데 필요한 문맥을 얻을 수 있으며, 비즈니스에 의미 있는 방식으로 데이터를 사용할 수 있도록 해주는 플랫폼이 필요합니다.

관찰 플랫폼이 지원해야 하는 기능

• 오픈 소스와 독점 소스 모두에서 텔레메트리 데이터를 수집하여 한 곳에 결합해주어야 합니다. 이러한 개방형 계측은 툴의 확산과 문제 및 응급 상황이 발생할 경우의 문맥 전환을 감소해줍니다. 소스와 관계없이 모든 데이터의 상호 운용성을 제공하기 때문입니다.

• 엔티티들을 연결해 상관시키고, 이러한 연결을 적용하여 데이터를 이해할 수 있도록 문맥과 의미를 생성해주어야 합니다. 문맥은 가장 중요한 정보를 표면화할 수 있도록 큐레이션된 뷰로 표시되어야 합니다.

• 맞춤화된 애플리케이션을 구축할 수 있는 기반이 되어야 합니다. 대시보드와 달리 애플리케이션은 상호작용이 가능한 큐레이션된 경험을 제공합니다. 애플리케이션에는 워크플로우가 기본으로 내장된 경우가 많으며, 외부 데이터 세트를 실시간으로 조합할 수 있도록 지원합니다. 프로그래머빌리티는 옵저버빌리티를 새롭게 정의합니다. 

오픈, 커넥티드, 프로그래머블 관찰 플랫폼이 있다면, 혁신 가속, 신속한 배포, 작업 감소, 비용 절감, 한정된 시간과 관심의 우선 순위 결정 등 비즈니스는 많은 혜택을 얻을 수 있습니다. 이 모든 것이 데이터, 시스템, 그리고 고객에 대한 보다 깊이 있는 공유된 이해로 연결됩니다. 이 모든 것은 기업의 문화를 향상시키고, 디지털 시스템의 성능과 고객의 소프트웨어 사용 방식에 대한 실시간 관점을 제공하여 비즈니스를 성장시켜 줄 것입니다. 이를 통해 직원들은 가장 중요한 것, 즉 비즈니스 성과를 달성하는 데만 집중할 수 있습니다.

최신 소프트웨어 팀을 위한 통합 옵저버빌리티

더 빨리 문제를 해결하고, 더 스마트하게 작업을 하며, 더 나은 디지털 경험을 만들 수 있습니다.

 시작하기