2021.03.31

관찰가능성과 모니터링으로 애플리케이션 신뢰도를 높이는 방법

Isaac Sacolick | InfoWorld
개발자가 애플리케이션이나 마이크로서비스를 프로덕션 단계로 새로 릴리스 할 때, IT 운영 부서는 이것이 규정한 서비스 수준 밖에서 작동하는지 여부를 어떻게 파악할까? 사전에 문제가 있음을 인식하고, 파급력이 큰 사고로 악화되기 전에 이를 해결할 수 있을까?

사고가 성과와 안정성, 신뢰도에 영향을 미칠 때, 빠르게 문제를 파악하고 비즈니스 영향을 최소화해 문제를 해결할 수 있을까? 

한 걸음 더 나아가, IT 운영 부서는 지원 인력이 문제를 시정하는 대신, 상황에 대응하는 작업을 자동화할 수 있을까?

퍼블릭/프라이빗 클라우드에서 실행되는 데이터 관리 및 분석 서비스는 어떨까? IT 운영 부서는 데이터 통합, 데이터옵스(Dataops), 데이터 레이크, 데이터 과학자가 배치한 머신 러닝 모델과 데이터 시각화 알림을 어떤 방식으로 받고, 검토 및 평가를 하고, 사고 세부사항을 파악하고, 문제를 해결할까? 

이것은 디지털 트랜스포메이션 과정에서 IT 리더들이 더 많은 애플리케이션과 분석 기술을 배포할 때 답해야 할 핵심적인 질문이다. 더욱이 데브옵스 부서가 CI/CD와 IaC(Infrastructure as Code)로 배포하는 일이 늘어나면서, 변화는 방해나 중단을 초래할 확률이 높아진다.

개발자, 데이터 과학자, 데이터 엔지니어, IT 운영 부서가 신뢰성을 높이려면 어떻게 해야 할까? 애플리케이션을 모니터링하고, 관찰가능성(Observabiligy)을 높여야 할까? 모니터링과 관찰가능성은 대립하는 개념일까? 아니면 함께 배치해 신뢰성을 높이고, 사고 해결 평균 시간(MTTR: Mean Time to Resolve)을 개선할 수 있을까?

필자는 IT 애플리케이션 개발, 프로덕션 단계 배포를 담당하는 기술 업체 운영진을 대상으로 모니터링과 관측가능성, AI옵스, 자동화에 대한 관점을 질문했다. 그리고 이들은 운영 신뢰성을 개선하기 위해 집중해야 할 5가지 실천 분야를 제시했다.
 

개발자와 운영자 간 SSOT(Single Source of Operational Truth)를 개발할 것

IT는 지난 10년 간 사고방식과 목적, 책임, 도구 등 전반적인 수준에서 개발자와 운영자 사이의 장벽을 없애려 노력했다. 이런 변화의 중심에는 데브옵스 문화와 프로세스 변경이 있고, CI/CD 파이프라인 및 IaC를 도입하면서 이런 여정을 시작하는 조직도 많다.

사용할 도구와 보고서, 데이터, 방법론을 합의해 애플리케이션 성능과 신뢰성에 기여하도록 애플리케이션 개발 부서와 운영 부서의 방향을 일치하는 것은 아주 중요하다.

빅팬더(BigPanda)의 제품 마케팅 담당 VP인 모한 콤펠라 또한 여기에 동의하면서, SSOT를 개발하는 것이 중요하다고 강조했다. 콤펠라는 “애자일 개발자와 데브옵스 부서는 앱 성능을 최적화하는 상세 진단과 포렌식에 독자적인 전문 관측가능성 도구를 사용한다. 이 과정에 인프라의 다른 부분에 대한 가시성을 상실하면서 상대방을 탓하는 문제가 생기거나, 사고 조사에서 시행착오가 발생할 수도 있다”라고 지적했다.

해결책은 무엇일까? 콤펠라는 “개발자의 애플리케이션 중심 가시성을 네트워크, 스토리지, 가상화, 기타 계층에 대한 360도 각도의 가시성으로 보강해야 한다. 그래서 마찰을 없애고, 개발자가 사고와 중단을 더 빨리 해결할 수 있어야 한다”라고 말했다.
 

애플리케이션 문제, 고객과 비즈니스 운영에 어떤 영향 주나

애플리케이션과 시스템 신뢰성에 대한 전반적인 접근법을 깊이 알아보기 전에 고객의 요구와 비즈니스 운영에 대해 논의하는 것이 아주 중요하다.

델 테크놀로지스(Dell Technologies)의 사업 부문 부미(Boomi)의 엔지니어링 디렉터인 자레드 블리츠스타인은 전략 개발에서 중심은 고객과 비즈니스의 맥락이라고 강조했다. 블리츠스타인은 “고객, 고객이 통찰력 있는 정보를 수집하는 능력, 사업 운영에서 실천하는 능력을 중심으로 관찰가능성을 확보했다. 차이가 있다면, 모니터링을 이용해 특정 시점에서 시스템이 어떻게 작동하는지 파악하고, 관찰가능성 개념을 활용해 이런 부분이 고객 성과에 미치는 전반적인 영향과 맥락을 파악한다는 점이다”라고 설명했다.

고객 마인드와 비즈니스 매트릭스가 있어야 한다. 이는 부서의 전략 시행에 방향을 제시한다. 블리츠스타인은 “보유한 기술 솔루션이 일상 비즈니스 운영에 얼마나 효과적인지를 파악해야 한다. 이것은 점차 더 중요한 매트릭스가 되고 있다. 관찰가능성 플랫폼과 문화를 발전시키면, 올바른 의사결정에 필요한 모든 관련 데이터에 대한 맥락을 구축할 수 있다”라고 설명했다.
 

모니터링 및 관찰가능성으로 텔레매트리를 개선

이미 애플리케이션을 모니터링하고 있다면, 여기에 관찰가능성을 추가해 무엇을 얻을 수 있을까? 모니터링과 관찰가능성의 차이점은 무엇일까? 필자는 2명의 전문가에게 질문했다. 무그소프트(Moogsoft)의 최고 에반젤리스트 리차드 화이트허드는 다음과 같이 설명했다.

“모니터링은 디지털 인프라를 판단하기 위해 이벤트 기록, 성능 모니터링 시스템 보고서 같이 정밀하지 못한, 보통은 구조화된 데이터 유형을 사용한다. 많은 경우에 침입적인 확인 방법을 이용한다. 반면, 관찰가능성은 아주 세밀한 저수준의 텔레매트리로 이런 판단을 내린다. 관찰가능성은 두 가지 변화로 인해 모니터링이 논리적으로 진화 및 발전한 것이다. 2가지 변화란 클라우드로 마이그레이션되면서 애플리케이션이 다시 작성되는 것(계측 도구가 추가될 수 있도록), 개발자가 자신의 코드를 운영하기 더 쉽게 만들도록 유도하는 데브옵스의 부상을 말한다.

IBM 관계사 인스타나(Instana)의 관찰가능성 전략가인 크리스 패럴은 차이점에 대해 몇 가지를 더 추가해 설명했다.

“관찰가능성은 애플리케이션에 대한 데이터를 얻는 것을 넘어, 성능 모니터링에서 얻은 매트릭스, 사용자 요청을 분산 추적한 것, 인프라의 이벤트, 코드 프로파일러 등 애플리케이션 시스템에 대한 정보의 여러 요소가 서로 연결된 방식을 파악하는 것이다. 관찰가능성 플랫폼이 이런 관계들을 더 잘 이해할 수록, CI/CD 툴링이나 AIops 플랫폼이 소비하는 다운스트림이든 플랫폼이든 이런 정보에 대한 분석이 더 효과가 있다.”

간단히 말해, 모니터링과 관찰가능성의 목적은 비슷하지만 접근법이 다르다. 애플리케이션 모니터링을 늘릴 때, 애플리케이션이나 마이크로서비스에 대한 관찰가능성에 투자할 때를 알아보자.

애자일 데브옵스 부서와 IT 운영 부서가 밀접히 협력해 클라우드 네이티브 애플리케이션과 마이크로서비스를 개발 및 현대화하는 것은 개발 과정에 관찰가능성 기준을 수립하고 엔지니어링할 좋은 기회이다. 레거시나 모놀리식 애플리케이션에 관찰가능성을 추가하는 것은 실용적이지 못할 수도 있다. 이 경우, 구형이나 모놀리식 애플리케이션을 모니터링하는 것이 프로덕션 단계에서 무엇이 일어나고 있는지 이해하는 가장 최적의 방법이 될 수도 있다.


모니터링 및 관찰가능성 문제에 대응하는 자동화된 액션
관찰가능성이나 모니터링, 또는 둘 모두에 투자하면 데이터 수집과 텔레매트리가 강화되고, 애플리케이션 성능을 더 잘 이해할 수 있다. 이후 AI옵스 플랫폼에서 모니터링 및 관찰가능성 데이터를 중앙화, 운영에 대한 더 깊이 있는 인사이트를 생성하고, 응답과 대응을 자동화할 수 있다.

현재 IT 운영 부서는 해야 할 일이 너무 많다. 리졸브(Resolve)의 아메리카 세일즈 엔지니어링 이사 마커스 레벨로는 더 많은 애플리케이션의 수요에 계속 부응하고, 신뢰성을 강화할 때 필요한 역량은 인사이트를 액션에 연결하고 자동화를 이용하는 것이라고 강조했다.

레벨로는 “다양한 종류의 데이터 소스를 수집, 통합, 분석해 값진 인사이트를 창출하고, IT 부서가 복잡한 하이브리드 클라우드 환경에서 일어나는 일을 이해하도록 도움을 줘야 한다”라고 강조했다. 그러나 이것만으로는 불충분하다.

레벨로는 “이런 인사이트를 자동화에 연결시켜 IT 운영을 혁신하는 것이 아주 중요하다”라고 덧붙였다. 그는 “현재 IT 환경에서는 갈수록 복잡해지는 복잡성을 다루고 인사이트의 가치를 극대화하기 위해 자동화와 관찰가능성, AI옵스를 결합해야 한다”라고 설명했다.
 

가치 흐름을 전달하기 위해 모니터링과 관찰가능성을 최적화

고객 니즈와 비즈니스 매트릭스를 한편에서는 모니터링과 관찰가능성, AIops, 다른 한편에서는 자동화와 연결하면, IT 운영 부서는 가치 흐름의 운영 신뢰성을 보장하는 완전한 전략을 갖추게 된다.

플루토라(Plutora)의 밥 데이비스 최고 마케팅 책임자(CMO)는 가치 흐름 포트폴리오를 지원하기 위해서는 모니터링과 관찰가능성이 모두 다 필요하다고 말했다. 데이비스는 “모니터링 도구는 특정 업무에 대한 정확하면서 깊은 정보를 제공한다. 사용과 관련된 트리거나 결함을 주시할 수도 있으며, AP 성능을 추적할 수도 있다. 반면 관찰가능성 도구는 모든 것을 조사한 후, 전체 시스템이나 가치 흐림에서 일어는 일에 대해 결론을 도출한다”라고 설명했다.

관찰가능성 도구는 가치 흐름에 특별한 역할을 한다. 데이비스는 “관찰가능성 도구들이 제공하는 정보를 이용, 개발자는 조직의 상태를 더 잘 이해할 수 있고, 효율성을 높이고, 조직의 가치 전달을 강화할 수 있다”라고 강조했다.

도구와 사용례, 여러 가지 상호 보완되는 것들이 많다. 그러나 최종적으로 애플리케이션 전달과 신뢰성을 강화하기 위해서는 개발과 운영이 동일한 목적을 추구해야 한다는 점을 염두에 두어야 할 것이다. editor@itworld.co.kr 


2021.03.31

관찰가능성과 모니터링으로 애플리케이션 신뢰도를 높이는 방법

Isaac Sacolick | InfoWorld
개발자가 애플리케이션이나 마이크로서비스를 프로덕션 단계로 새로 릴리스 할 때, IT 운영 부서는 이것이 규정한 서비스 수준 밖에서 작동하는지 여부를 어떻게 파악할까? 사전에 문제가 있음을 인식하고, 파급력이 큰 사고로 악화되기 전에 이를 해결할 수 있을까?

사고가 성과와 안정성, 신뢰도에 영향을 미칠 때, 빠르게 문제를 파악하고 비즈니스 영향을 최소화해 문제를 해결할 수 있을까? 

한 걸음 더 나아가, IT 운영 부서는 지원 인력이 문제를 시정하는 대신, 상황에 대응하는 작업을 자동화할 수 있을까?

퍼블릭/프라이빗 클라우드에서 실행되는 데이터 관리 및 분석 서비스는 어떨까? IT 운영 부서는 데이터 통합, 데이터옵스(Dataops), 데이터 레이크, 데이터 과학자가 배치한 머신 러닝 모델과 데이터 시각화 알림을 어떤 방식으로 받고, 검토 및 평가를 하고, 사고 세부사항을 파악하고, 문제를 해결할까? 

이것은 디지털 트랜스포메이션 과정에서 IT 리더들이 더 많은 애플리케이션과 분석 기술을 배포할 때 답해야 할 핵심적인 질문이다. 더욱이 데브옵스 부서가 CI/CD와 IaC(Infrastructure as Code)로 배포하는 일이 늘어나면서, 변화는 방해나 중단을 초래할 확률이 높아진다.

개발자, 데이터 과학자, 데이터 엔지니어, IT 운영 부서가 신뢰성을 높이려면 어떻게 해야 할까? 애플리케이션을 모니터링하고, 관찰가능성(Observabiligy)을 높여야 할까? 모니터링과 관찰가능성은 대립하는 개념일까? 아니면 함께 배치해 신뢰성을 높이고, 사고 해결 평균 시간(MTTR: Mean Time to Resolve)을 개선할 수 있을까?

필자는 IT 애플리케이션 개발, 프로덕션 단계 배포를 담당하는 기술 업체 운영진을 대상으로 모니터링과 관측가능성, AI옵스, 자동화에 대한 관점을 질문했다. 그리고 이들은 운영 신뢰성을 개선하기 위해 집중해야 할 5가지 실천 분야를 제시했다.
 

개발자와 운영자 간 SSOT(Single Source of Operational Truth)를 개발할 것

IT는 지난 10년 간 사고방식과 목적, 책임, 도구 등 전반적인 수준에서 개발자와 운영자 사이의 장벽을 없애려 노력했다. 이런 변화의 중심에는 데브옵스 문화와 프로세스 변경이 있고, CI/CD 파이프라인 및 IaC를 도입하면서 이런 여정을 시작하는 조직도 많다.

사용할 도구와 보고서, 데이터, 방법론을 합의해 애플리케이션 성능과 신뢰성에 기여하도록 애플리케이션 개발 부서와 운영 부서의 방향을 일치하는 것은 아주 중요하다.

빅팬더(BigPanda)의 제품 마케팅 담당 VP인 모한 콤펠라 또한 여기에 동의하면서, SSOT를 개발하는 것이 중요하다고 강조했다. 콤펠라는 “애자일 개발자와 데브옵스 부서는 앱 성능을 최적화하는 상세 진단과 포렌식에 독자적인 전문 관측가능성 도구를 사용한다. 이 과정에 인프라의 다른 부분에 대한 가시성을 상실하면서 상대방을 탓하는 문제가 생기거나, 사고 조사에서 시행착오가 발생할 수도 있다”라고 지적했다.

해결책은 무엇일까? 콤펠라는 “개발자의 애플리케이션 중심 가시성을 네트워크, 스토리지, 가상화, 기타 계층에 대한 360도 각도의 가시성으로 보강해야 한다. 그래서 마찰을 없애고, 개발자가 사고와 중단을 더 빨리 해결할 수 있어야 한다”라고 말했다.
 

애플리케이션 문제, 고객과 비즈니스 운영에 어떤 영향 주나

애플리케이션과 시스템 신뢰성에 대한 전반적인 접근법을 깊이 알아보기 전에 고객의 요구와 비즈니스 운영에 대해 논의하는 것이 아주 중요하다.

델 테크놀로지스(Dell Technologies)의 사업 부문 부미(Boomi)의 엔지니어링 디렉터인 자레드 블리츠스타인은 전략 개발에서 중심은 고객과 비즈니스의 맥락이라고 강조했다. 블리츠스타인은 “고객, 고객이 통찰력 있는 정보를 수집하는 능력, 사업 운영에서 실천하는 능력을 중심으로 관찰가능성을 확보했다. 차이가 있다면, 모니터링을 이용해 특정 시점에서 시스템이 어떻게 작동하는지 파악하고, 관찰가능성 개념을 활용해 이런 부분이 고객 성과에 미치는 전반적인 영향과 맥락을 파악한다는 점이다”라고 설명했다.

고객 마인드와 비즈니스 매트릭스가 있어야 한다. 이는 부서의 전략 시행에 방향을 제시한다. 블리츠스타인은 “보유한 기술 솔루션이 일상 비즈니스 운영에 얼마나 효과적인지를 파악해야 한다. 이것은 점차 더 중요한 매트릭스가 되고 있다. 관찰가능성 플랫폼과 문화를 발전시키면, 올바른 의사결정에 필요한 모든 관련 데이터에 대한 맥락을 구축할 수 있다”라고 설명했다.
 

모니터링 및 관찰가능성으로 텔레매트리를 개선

이미 애플리케이션을 모니터링하고 있다면, 여기에 관찰가능성을 추가해 무엇을 얻을 수 있을까? 모니터링과 관찰가능성의 차이점은 무엇일까? 필자는 2명의 전문가에게 질문했다. 무그소프트(Moogsoft)의 최고 에반젤리스트 리차드 화이트허드는 다음과 같이 설명했다.

“모니터링은 디지털 인프라를 판단하기 위해 이벤트 기록, 성능 모니터링 시스템 보고서 같이 정밀하지 못한, 보통은 구조화된 데이터 유형을 사용한다. 많은 경우에 침입적인 확인 방법을 이용한다. 반면, 관찰가능성은 아주 세밀한 저수준의 텔레매트리로 이런 판단을 내린다. 관찰가능성은 두 가지 변화로 인해 모니터링이 논리적으로 진화 및 발전한 것이다. 2가지 변화란 클라우드로 마이그레이션되면서 애플리케이션이 다시 작성되는 것(계측 도구가 추가될 수 있도록), 개발자가 자신의 코드를 운영하기 더 쉽게 만들도록 유도하는 데브옵스의 부상을 말한다.

IBM 관계사 인스타나(Instana)의 관찰가능성 전략가인 크리스 패럴은 차이점에 대해 몇 가지를 더 추가해 설명했다.

“관찰가능성은 애플리케이션에 대한 데이터를 얻는 것을 넘어, 성능 모니터링에서 얻은 매트릭스, 사용자 요청을 분산 추적한 것, 인프라의 이벤트, 코드 프로파일러 등 애플리케이션 시스템에 대한 정보의 여러 요소가 서로 연결된 방식을 파악하는 것이다. 관찰가능성 플랫폼이 이런 관계들을 더 잘 이해할 수록, CI/CD 툴링이나 AIops 플랫폼이 소비하는 다운스트림이든 플랫폼이든 이런 정보에 대한 분석이 더 효과가 있다.”

간단히 말해, 모니터링과 관찰가능성의 목적은 비슷하지만 접근법이 다르다. 애플리케이션 모니터링을 늘릴 때, 애플리케이션이나 마이크로서비스에 대한 관찰가능성에 투자할 때를 알아보자.

애자일 데브옵스 부서와 IT 운영 부서가 밀접히 협력해 클라우드 네이티브 애플리케이션과 마이크로서비스를 개발 및 현대화하는 것은 개발 과정에 관찰가능성 기준을 수립하고 엔지니어링할 좋은 기회이다. 레거시나 모놀리식 애플리케이션에 관찰가능성을 추가하는 것은 실용적이지 못할 수도 있다. 이 경우, 구형이나 모놀리식 애플리케이션을 모니터링하는 것이 프로덕션 단계에서 무엇이 일어나고 있는지 이해하는 가장 최적의 방법이 될 수도 있다.


모니터링 및 관찰가능성 문제에 대응하는 자동화된 액션
관찰가능성이나 모니터링, 또는 둘 모두에 투자하면 데이터 수집과 텔레매트리가 강화되고, 애플리케이션 성능을 더 잘 이해할 수 있다. 이후 AI옵스 플랫폼에서 모니터링 및 관찰가능성 데이터를 중앙화, 운영에 대한 더 깊이 있는 인사이트를 생성하고, 응답과 대응을 자동화할 수 있다.

현재 IT 운영 부서는 해야 할 일이 너무 많다. 리졸브(Resolve)의 아메리카 세일즈 엔지니어링 이사 마커스 레벨로는 더 많은 애플리케이션의 수요에 계속 부응하고, 신뢰성을 강화할 때 필요한 역량은 인사이트를 액션에 연결하고 자동화를 이용하는 것이라고 강조했다.

레벨로는 “다양한 종류의 데이터 소스를 수집, 통합, 분석해 값진 인사이트를 창출하고, IT 부서가 복잡한 하이브리드 클라우드 환경에서 일어나는 일을 이해하도록 도움을 줘야 한다”라고 강조했다. 그러나 이것만으로는 불충분하다.

레벨로는 “이런 인사이트를 자동화에 연결시켜 IT 운영을 혁신하는 것이 아주 중요하다”라고 덧붙였다. 그는 “현재 IT 환경에서는 갈수록 복잡해지는 복잡성을 다루고 인사이트의 가치를 극대화하기 위해 자동화와 관찰가능성, AI옵스를 결합해야 한다”라고 설명했다.
 

가치 흐름을 전달하기 위해 모니터링과 관찰가능성을 최적화

고객 니즈와 비즈니스 매트릭스를 한편에서는 모니터링과 관찰가능성, AIops, 다른 한편에서는 자동화와 연결하면, IT 운영 부서는 가치 흐름의 운영 신뢰성을 보장하는 완전한 전략을 갖추게 된다.

플루토라(Plutora)의 밥 데이비스 최고 마케팅 책임자(CMO)는 가치 흐름 포트폴리오를 지원하기 위해서는 모니터링과 관찰가능성이 모두 다 필요하다고 말했다. 데이비스는 “모니터링 도구는 특정 업무에 대한 정확하면서 깊은 정보를 제공한다. 사용과 관련된 트리거나 결함을 주시할 수도 있으며, AP 성능을 추적할 수도 있다. 반면 관찰가능성 도구는 모든 것을 조사한 후, 전체 시스템이나 가치 흐림에서 일어는 일에 대해 결론을 도출한다”라고 설명했다.

관찰가능성 도구는 가치 흐름에 특별한 역할을 한다. 데이비스는 “관찰가능성 도구들이 제공하는 정보를 이용, 개발자는 조직의 상태를 더 잘 이해할 수 있고, 효율성을 높이고, 조직의 가치 전달을 강화할 수 있다”라고 강조했다.

도구와 사용례, 여러 가지 상호 보완되는 것들이 많다. 그러나 최종적으로 애플리케이션 전달과 신뢰성을 강화하기 위해서는 개발과 운영이 동일한 목적을 추구해야 한다는 점을 염두에 두어야 할 것이다. editor@itworld.co.kr 


X