수집 데이터가 올바르게 차트화되면 원격 측정 최적화를 시작하여 중복 수집 데이터를 줄이고 수집 비용을 낮출 수 있습니다. 첫 번째 단계는 최적화 계획을 수립한 다음 데이터 최적화 기술을 사용하여 해당 계획을 실행하는 것입니다.
관찰 가능성 목표 이해
데이터 수집 거버넌스 프레임워크의 가장 중요한 부분 중 하나는 관찰 가능성 가치 동인을 만드는 것입니다. 이를 통해 데이터가 목표에 얼마나 중요한지(또는 중복되는지) 측정하는 데 사용할 수 있는 구체적인 메트릭과 데이터를 정렬할 수 있습니다.
또한 향후 새로운 원격 분석을 구성해야 할 때 목표를 이해하는 데 도움이 됩니다. 그렇게 할 때 불필요한 중복을 방지하기 위해 전체 관찰 가능성 시스템에 무엇을 제공하는지 이해하고 싶을 것입니다. 아래 목표와 일치하지 않는 새 원격 분석 데이터를 생성하는 경우 데이터가 필요하지 않으며 생성을 방지하여 비용을 절감할 수 있다는 좋은 신호일 수 있습니다.
내부 SLA 충족
외부 SLA 충족
기능 혁신 지원(A/B 성능 및 채택 테스트)
고객 경험 모니터링
공급업체 및 내부 서비스 제공업체의 SLA 준수
비즈니스 프로세스 상태 모니터링
기타 규정 준수 요구 사항
이러한 목표에 맞추면 가치 우선 순위 지정에 대한 올바른 결정을 내릴 수 있고 새로운 플랫폼과 서비스를 구축할 때 팀이 어디서부터 시작해야 하는지 알 수 있습니다.
최적화 계획 개발
목표를 이해했다면 이제 최적화 계획을 수립해야 합니다. 이 계획은 수집 데이터의 가치를 측정하고 비용을 낮추기 위해 안전하게 제외할 수 있는 데이터를 찾는 데 도움이 됩니다.
아래에는 자체 원격 분석 수집을 평가하고 조직의 요구 사항에 맞는 올바른 결정을 내리는 방법에 대한 세 가지 예가 있습니다. 이러한 각 예는 하나의 가치 동인에 초점을 맞추고 있지만 대부분의 계측은 많은 가치 영역에 대한 데이터를 제공합니다.
계정이 예산보다 약 20% 더 많이 수집하고 있습니다. 그들은 소비를 줄이는 방법을 찾도록 관리자로부터 요청을 받았습니다. 가장 중요한 가치 동인은 가동 시간, 성능 및 안정성 입니다.
그들의 재산에는 다음이 포함됩니다.
(개발, 스테이징, 프로덕션)
분산 추적
브라우저
100개 호스트의 인프라 모니터링
Kubernetes 모니터링(개발, 스테이징, 프로덕션)
로그(dev, staging, prod - 디버그 포함)
최적화 계획
디버그 로그를 생략하여(문제가 있는 경우 켤 수 있음을 알고 있음) 5%를 절약합니다.
Kubernetes 클러스터 탐색기를 표시하는 데 필요하지 않은 여러 Kubernetes 상태 메트릭을 생략하여 10%를 절약합니다.
새로운 기능을 테스트할 때 수집하던 일부 사용자 지정 브라우저 이벤트를 삭제하여 10%를 절약했습니다.
이러한 변경 사항을 실행한 후 팀은 예산보다 5% 적고 NPM 파일럿을 수행할 수 있는 공간을 확보하여 관리자가 할당한 작업을 완료했습니다.
최종 결과
원래 예산보다 5%
가동 시간, 성능 및 안정성 목표를 제공하는 NPM 파일럿을 위해 생성된 헤드룸
가동 시간 및 신뢰성 관찰 가능성의 손실 최소화
다음에 중점을 두고 새로운 사용자 대면 플랫폼을 담당하는 팀 브라우저 모니터링은 예산을 50% 초과하여 실행되고 있습니다. 수집 크기를 적절하게 조정해야 하지만 Customer experience [고객 경험] 관찰 가능성을 희생하지 않는다는 점에 대해 단호합니다.
그들의 재산에는 다음이 포함됩니다.
이동하는
브라우저
APM
분산 추적
프로세스 샘플을 포함한 30개 호스트의 인프라
일부 백엔드 비동기 프로세스에 대한 서버리스 모니터링
서버리스 기능의 로그
다양한 클라우드 통합
최적화 계획
Lambda 통합으로 인해 필요에 따라 중복되는 서버리스 로그를 생략합니다.
호스트의 프로세스 샘플링 속도를 1분마다 줄입니다.
개발 환경에서 프로세스 샘플 데이터를 삭제합니다.
New Relic 인프라 에이전트에서 제공하는 다른 인프라 모니터링과 고도로 중복되는 EC2 통합을 끕니다.
최종 결과
원래 예산의 5%
성수기를 통과하기에 충분합니다.
고객 경험 관찰 가능성 손실 없음
변경 사항을 실행한 후 원래 예산보다 5%밖에 남지 않았으며 이 정도면 성수기 내내 유지하기에 충분하다는 결론을 내립니다.
한 팀이 대규모 Python 모놀리스를 4개의 마이크로서비스로 리팩토링하는 과정에 있습니다. 모놀리식은 고객 데이터베이스 및 캐시 계층을 포함한 새로운 아키텍처와 인프라를 공유합니다. 그들은 예산을 70% 초과했으며 모놀리스를 공식적으로 폐기하기까지 두 달이 남았습니다.
그들의 재산에는 다음이 포함됩니다.
Kubernetes 모니터링(마이크로서비스)
New Relic 호스트 모니터링(모놀리스)
APM(마이크로서비스 및 호스트 모니터링)
분산 추적(마이크로서비스 및 호스트 모니터링)
PostgreSQL(공유)
Redis(공유)
MSSQL(마이크로서비스 아키텍처용 미래 DB)
로드 밸런서 로깅(마이크로서비스 및 호스트 모니터링)
최적화 계획
5xx 응답 코드만 모니터링하도록 로드 밸런서 로깅을 구성합니다.
모놀리식을 실행하는 호스트에 대해 ProcessSample, StorageSample 및 NetworkSample 의 맞춤 샘플링 속도를 60초로 설정합니다.
새 아키텍처에서는 MSSQL 모니터링을 사용하지 않으므로 MSSQL 모니터링을 비활성화합니다.
모놀리스에 대한 분산 추적은 마이크로서비스 아키텍처에 비해 훨씬 덜 유용하므로 비활성화합니다.
최종 결과
원래 예산보다 1%
혁신 및 성장 관찰 가능성 손실 없음
팁
최적화 계획을 관리하고 각 최적화 작업에 미치는 영향을 이해하는 데 도움이 되도록 작업 관리 도구에서 계획을 추적하는 것이 좋습니다. 이 데이터 최적화 계획 템플릿을 사용하여 도움을 받을 수 있습니다.