이 가이드는 관찰 가능성에서 얻는 가치를 극대화하기 위해 New Relic 설치 및 구성을 자동화하기 위한 아이디어와 프로세스를 안내합니다. 이것은 관찰 가능성 성숙도에 대한 시리즈 의 일부입니다.
개요
코드로서의 관찰 가능성은 관찰 가능성 도구의 구성을 일관되고 제어되고 자동화된 방식으로 자동화하는 프로세스를 설명하는 데 사용되는 용어로 원격 분석 데이터에서 최대 가치를 도출하는 데 도움이 됩니다. 이 리소스는 New Relic 구현을 위해 이 작업을 수행하는 데 중점을 둘 것입니다.
이 가이드를 사용해야 하는 이유는 무엇입니까?
인프라, 애플리케이션 및 서비스 기술이 발전함에 따라 그 규모와 복잡성이 증가하여 계측 도구(New Relic 포함)에서 수집된 데이터의 양이 증가하고 데이터를 이해하고 컨텍스트에 연결하고 조치를 취하는 것과 관련된 문제가 발생합니다. 그것의 뒤에 떨어져.
New Relic의 구성을 자동화하기 위해 Observability as Code 방법론을 사용하면 이러한 문제를 해결하여 조직이 채택을 가속화하고 안정성을 개선하며 더 나은 거버넌스를 추진할 수 있도록 지원합니다.
이 가이드는 관찰 가능성을 코드로 구현하는 방법에 대한 지침을 제공하고 New Relic 플랫폼을 속도와 규모에 맞게 구축하고 유지할 수 있도록 하는 모범 사례 조언과 참조 예제를 제공합니다. 자동화 워크플로 및 프로비저닝 도구를 활용하여 조직이 관찰 가능성 모범 사례를 확장하는 동시에 수동 작업을 줄이고 서비스 제공을 개선할 수 있습니다. 이러한 아이디어를 성공적으로 구현하면 IT 조직 자체와 이들이 지원하는 비즈니스 모두에 실질적인 가치를 제공해야 합니다.
원하는 결과
빠르게 변화하는 대규모 환경에서 최적으로 구성된 관측 가능성 솔루션을 구현하고 유지하는 것과 관련된 비용과 위험을 줄입니다.
특히 관찰 가능성을 코드 관행으로 채택할 때 얻을 수 있는 이점 중 일부는 다음과 같습니다.
반복 가능, 복제 가능, 재사용 가능
코드를 통해 New Relic 리소스를 관리한다는 것은 대량으로 쉽게 반복, 확장 및 업데이트할 수 있음을 의미합니다. Terraform과 같은 프로비저닝 도구와 함께 모듈식 접근 방식을 활용하면 대시보드, 경고 및 워크로드와 같은 패키지 리소스 세트를 빠르고 쉽게 공유 및 배포할 수 있으므로 시작 시간을 단축하고 조직 전체의 표준을 개선할 수 있습니다.
수고 감소
코드를 통해 관리되는 New Relic 리소스를 만들고 유지 관리하는 수고는 특히 대규모 작업 시 사용자 인터페이스를 통해 수동으로 관리하는 것보다 훨씬 적습니다. 우리의 인터페이스는 검색 및 테스트에 적합하지만 코드 관리 리소스에 대한 변경 사항을 대량으로 적용할 수 있어 리소스 관리 시간을 크게 줄일 수 있습니다. 한 가지 일반적인 접근 방식은 사용자 인터페이스 내에서 경고 및 대시보드를 개발한 다음 충분히 성숙한 것으로 간주되면 코드 관리 리소스로 마이그레이션하는 것입니다.
문서 및 컨텍스트
New Relic에서 구성할 수 있는 리소스는 매우 다양하기 때문에 단일 리소스를 볼 때 왜 그대로 생성되거나 구성되었는지 이해하기 어려울 수 있습니다. 코드를 통한 구성은 특정 선택이 왜, 언제, 누구에 의해 만들어졌는지 설명하는 데 도움이 되는 관련 주석 및 문서를 허용합니다.
감사 가능한 기록
누가 NRAuditEvent 이벤트를 통해 New Relic 리소스를 변경했는지 이해할 수 있지만 변경 이유 , 이전 상태 또는 변경 승인자에 대한 많은 배경 정보를 제공하지 않습니다. 자동화된 승인 기반 프로비저닝 워크플로와 함께 코드를 통해 리소스를 관리하면 변경 사항을 훨씬 더 명확하게 파악하고 거버넌스를 개선하는 동시에 롤백 및 복구 방법을 제공할 수 있습니다.
보안
코드로서의 관찰 가능성을 통해 New Relic 리소스를 관리하기 위한 API 키 사용을 보다 엄격하게 제어할 수 있습니다. 유통되는 API 키의 수를 줄이고 생성 및 배포와 관련하여 적절한 거버넌스를 보장함으로써 보안이 향상됩니다. 특히 자동화된 워크플로 내에서 사용자가 자신의 키를 사용하지 못하도록 하면 키 침해 또는 의도하지 않은 손상이 발생할 수 있는 노출 영역이 줄어듭니다.
효율적인 델타 변경
Terraform과 같은 프로비저닝 도구를 사용하면 기존 리소스를 델타로 변경할 수 있습니다. 따라서 최소한의 리소스 파괴 및 재생성으로 변경이 필요한 리소스 속성만 변경되므로 업데이트가 빠르고 효율적입니다. 이는 대시보드 및 경고와 같은 리소스의 GUID가 업데이트 시 변경되지 않도록 하기 때문에 중요합니다.
외부 자극에 반응
코드로서의 관찰 가능성을 자동화된 워크플로와 결합하면 애플리케이션 배포, 인프라 이벤트 또는 기타 데이터 입력과 같은 외부 자극의 결과로 New Relic 리소스를 생성하고 수정할 수 있습니다. 예를 들어 배포 시 코드 버전 릴리스 간의 주요 황금 신호 메트릭을 비교하는 대시보드 및 경고를 자동으로 생성할 수 있습니다.
컨텍스트 소유권 및 패키징
코드에서 리소스를 관리하면 관련 리소스를 함께 관리할 수 있습니다. 사용자 인터페이스에 분산되어 있을 때보다 코드로 한 곳에서 이해하고 관리하는 것이 더 쉽습니다. 예를 들어, 이를 통해 서로 다른 팀이 영향력 범위 내에서 리소스를 관리, 확인 및 유지할 수 있으며 관리하는 리소스를 찾을 필요가 없습니다.
재해 복구
때때로 실수가 발생하고 잘못된 리소스가 업데이트되거나 삭제됩니다. 수동 리소스 관리로 이러한 상황에서 복구하는 것은 리소스가 변경되거나 손실된 경우에도 이전에 무엇이 존재했는지 알기가 쉽지 않기 때문에 어렵습니다. 코드로서의 관찰 가능성은 모든 리소스를 다시 만들거나 예상 구성으로 재설정할 수 있도록 하여 이러한 문제로부터 보호하는 데 도움이 됩니다. 또한 구성 드리프트를 사전에 감지할 수 있는 기회를 제공합니다.
배포 속도
코드로서의 관찰 가능성은 팀 간에 공통 리소스 세트를 쉽게 공유하고 관찰 가능성 도구를 부트스트랩하는 데 사용할 수 있도록 하여 배포 속도를 가속화합니다. 이는 유사한 애플리케이션 배포 아키텍처가 쿠키 커터 모듈 기반 New Relic 리소스의 이점을 활용하는 마이크로서비스 아키텍처에서 특히 분명합니다. 재사용 가능한 중앙 관리 모듈을 생성하면 관측 가능성 도구에 대한 일반적인 접근 방식을 표준화하는 데 도움이 됩니다.
핵심 성과 지표
코드 배포로서의 관찰 가능성의 성숙도는 여러 가지 방법으로 평가할 수 있습니다. 일반적으로 환경에서 코드를 통해 관리되는 리소스가 많을수록 배포가 더 성숙해집니다. 다음은 몇 가지 KPI입니다.
전제 조건
New Relic을 사용하여 코드 구현으로 Observability를 시작하기 전에 New Relic University 에서 사용할 수 있는 기본 사항에 대해 알아야 합니다.
또한 다음을 수행해야 합니다.
- Terraform과 같은 프로비저닝 도구를 선택하고 숙지합니다.
- 자동화 워크플로를 지원하는 CI/CD 플랫폼에 액세스
- New Relic 플랫폼 및 API 기능에 익숙해지기
- 리소스에 대한 태그 지정 및 명명 규칙 또는 전략을 결정했습니다.
- KPI 결정을 위한 자산 세분화 전략 결정
- CI/CD 도구의 변경 사항을 적용하기 위한 서비스 계정 API 키 및 권한 모델을 준비했습니다.
현재 상태 설정
코드로 관찰 가능성을 채택하기 전에 현재 상태를 평가해야 합니다. 위에서 설명한 성숙도 평가 개념을 활용하여 환경의 성숙도를 결정하고 먼저 처리할 환경의 우선 순위를 지정할 수 있습니다.
개선 프로세스
New Relic과 함께 observability-as-code를 채택하기로 결정했지만 시작하는 방법을 확신하지 못하거나 일반적인 막다른 골목과 함정을 피하고 싶을 수 있습니다. 여기에서 코드로 관찰 가능성을 자신 있게 채택하는 데 도움이 되는 모범 사례, 조언 및 참조 예제에 대한 가이드를 제공합니다.
팀 기반 리소스 격리
많은 팀이 단일 New Relic 계정 또는 여러 계정에서 리소스를 관리하는 데 관여할 수 있습니다. 우리의 observability-as-code 방식은 리소스의 격리, 액세스 및 관리를 보다 엄격하게 제어하는 방법을 제공합니다. 개인에 대한 쓰기 액세스를 제한하고 관리 코드를 통해 변경 사항을 적용하면 팀이 서로의 리소스에 영향을 미칠 위험 없이 같은 공간에서 안전하게 작업할 수 있습니다.
예를 들어, 서로 다른 New Relic 계정에서 각각의 애플리케이션을 모니터링하는 여러 애플리케이션 팀을 대신하여 클라우드 인프라를 관리하는 공유 인프라 팀이 있을 수 있습니다. 이 공유 인프라 팀은 애플리케이션 팀의 자체 리소스와 함께 이러한 계정 내에서 자체 New Relic 리소스를 관리합니다. 사용자 쓰기 액세스를 제한하고 핵심 리소스가 observability-as-code 워크플로를 통해서만 관리되도록 하면 팀의 리소스가 조화롭게 함께 살 수 있고 무단 변경 또는 의도하지 않은 변경 가능성이 줄어듭니다.
이 다이어그램은 여러 팀의 CI/CD 파이프라인이 여러 중복 계정에서 격리된 리소스를 관리하기 위해 액세스할 수 있는 방법을 보여줍니다.
API 키
NerdGraph API를 사용하거나 Terraform과 같은 프로비저닝 도구를 통해 리소스를 관리하려면 New Relic 사용자 키 가 필요합니다. 사용자 키는 특정 사용자와 연결되며 해당 사용자의 권한을 상속합니다.
서비스 계정
실제 인간 사용자에 대해 New Relic 사용자 키를 생성하면 자동화된 파이프라인에 문제가 발생할 수 있습니다. 예를 들어, 해당 사용자의 권한이 팀 이동의 일부로 변경되거나 사용자가 조직을 떠나는 경우 해당 권한에 의존하는 자동화 파이프라인이 실패할 수 있습니다.
자동화 목적으로 특별히 생성된 중앙 관리 팀에서 관리하는 "서비스 계정" 사용자 생성을 고려하십시오. 그런 다음 이러한 팀은 다른 구현 팀에 배포할 키를 생성하고 관리할 수 있습니다. 서비스 계정을 사용하여 구현 팀이 자체 키만 사용하도록 여러 키를 생성할 수 있습니다. 이러한 방식으로 관리되는 키는 더 쉽게 감사되고 권한이 올바르게 설정되고 안정적으로 유지되도록 도와줍니다. 개인은 개발 및 테스트를 제외하고 자신의 사용자 키를 사용하지 않도록 권장해야 합니다.
자동화된 API 키 생성
NerdGraph 를 통해 New Relic 사용자 키를 생성할 수 있어 완전 자동화된 주문형 키 프로비저닝이 가능합니다. 이는 포털 또는 서비스 프로세스 흐름을 통해 키 생성을 자동화하는 데 사용할 수 있습니다.
자동화 도구
Terraform 을 사용하여 New Relic 리소스 프로비저닝을 관리하는 것이 좋습니다. Terraform과 같은 도구를 사용하면 호출할 API 또는 생성된 항목의 기록을 유지 관리하는 방법에 대해 걱정할 필요 없이 코드에서 리소스를 구성할 수 있습니다.
New Relic은 자체 New Relic Terraform 공급자 를 적극적으로 유지 관리합니다. 기능 요청 및 문제는 오픈 소스 Terraform GitHub 리포지토리 에 제출할 수 있습니다.
상태 관리
Terraform으로 New Relic 리소스를 관리할 때 Terraform 상태의 안정적인 기록을 유지하는 것이 중요합니다. 이상적으로는 상태를 원격 위치 에 안전하게 저장하고 버전을 제어하고 안정성을 보장하기 위해 상태 잠금 을 활용해야 합니다.
관리 리소스 식별
코드 관리되는 New Relic의 리소스를 쉽게 식별할 수 있는 것이 중요합니다. 이를 통해 성숙도 KPI를 평가할 수 있을 뿐만 아니라 UI와 상호 작용하는 사용자가 어떤 리소스가 코드로 관리되고 따라서 수동으로 변경해서는 안 되는지 이해하는 데 도움이 됩니다.
코드에서 관리되는 리소스에 태그를 지정하고 이름을 지정하기 위해 일관된 조직 전체 표준을 개발하는 것이 좋습니다. 최소한 리소스가 코드로 관리된다는 태그를 지정하고 식별해야 합니다. 예를 들어, 리소스 이름에 codeManaged=true 태그와 접미사 또는 접두사를 추가하여 식별에 도움을 줄 수 있습니다(예: "데이터베이스 성능 요약[CM]"). 또한 예를 들어 소유 팀, 리소스 소스 또는 코드 버전과 같은 유용한 추가 정보로 리소스에 태그를 지정하는 것을 고려해야 합니다.
대규모 리소스 세트 다루기
새로운 구성이 적용될 때 변경 사항을 찾기 위해 Terraform에 구성된 모든 리소스를 새로 고치고 평가해야 합니다. 구성의 양이 증가함에 따라 확인할 리소스 목록이 늘어납니다. 각 검사에는 API 호출이 필요하므로 대규모 구성을 완료하는 데 시간이 걸릴 수 있으며 너무 많은 요청이 병렬로 수행되는 경우 API 제한이 발생할 수 있습니다. 한 가지 접근 방식은 단일 상태 내에서 관리되는 리소스의 수를 줄여 구성을 여러 부분으로 나누는 것입니다. 또한 Terraform 요청의 병렬 처리를 줄이면 API 제한을 완화할 수 있습니다.
모듈식 접근 방식
모듈은 Terraform을 사용하여 리소스 구성을 패키징하고 재사용하는 주요 방법이며 원하는 수의 New Relic 리소스를 함께 패키징하는 데 활용할 수 있습니다. 이와 같은 패키징을 통해 매개변수 기반 배포가 가능합니다. 예를 들어, 애플리케이션 이름을 사용하여 개요 대시보드, 골든 시그널 경고 및 종합 여정을 모두 한 번의 작업으로 구축하는 모듈이 있을 수 있습니다.
Terraform 모듈은 팀이 다른 팀에서 개발한 리소스 패키지를 공유하고 사용할 수 있도록 원격 레지스트리에 게시 할 수 있습니다. 이는 표준화를 구현하고 버전 제어 변경 및 개선 사항을 쉽게 롤아웃할 수 있는 기회를 제공합니다.
구현 참조
자동화 워크플로
자동화 워크플로는 팀과 조직에 코드로 관찰 가능성을 확장하는 데 필수적입니다. Terraform 워크플로 를 구동할 수 있는 많은 CI/CD 도구와 서비스가 있습니다. 이를 통해 구성 변경 사항을 논의하고 승인하는 동시에 감사 가능한 변경 사항 추적을 제공할 수 있습니다.
팀이 New Relic 구성에서 함께 작업할 수 있도록 Terraform 워크플로 를 채택하는 것이 좋습니다. 이러한 워크플로 중 하나는 GitHub, GitLab 및 Bitbucket과 같은 코드 버전 관리 시스템의 CI/CD 기능을 활용하여 내장된 승인 및 검토 메커니즘을 사용하여 코드를 자동으로 계획하고 적용합니다.
이 다이어그램은 변경 사항이 PR로 제기된 다음 승인되고 리소스 배포를 트리거하기 위해 기본에 병합되는 방법을 보여줍니다.
워크플로 구현 예
다음 참조 예제 는 다양한 시스템에서 Terraform 워크플로를 설정하는 방법을 보여줍니다.
- GitHub Actions 예제 : 이 예제는 AWS S3 지원 상태 스토리지와 함께 GitHub Actions 를 사용하는 방법을 보여줍니다.
- GitLab 파이프라인 예제 : 이 예제에서는 Gitlab http 상태 저장소와 함께 GitLab 파이프라인 을 사용하는 방법을 보여줍니다.
- Bitbucket 파이프라인 예제 : 이 예제는 S3 지원 상태 스토리지와 함께 Bitbucket 파이프라인 을 사용하는 방법을 보여줍니다.
버전 고정
observability-as-code 워크플로를 통해 리소스를 자동으로 프로비저닝할 때 워크플로가 모든 실행에서 동일한 방식으로 수행되도록 하는 것이 중요합니다. 파이프라인 실패를 유발하는 예기치 않은 업그레이드가 발생하지 않도록 하기 위해 사용한 New Relic 공급자 및 Terraform의 버전을 고정하는 것이 좋습니다. 버전을 고정하기로 결정했다면 주기적으로 최신 버전으로 업그레이드하고 테스트해야 합니다. Terraform 문서 에서 버전 제한에 대해 자세히 알아볼 수 있습니다.
구성 드리프트 감지
관측 가능성 플랫폼의 안정성과 신뢰성을 보장하려면 구성 드리프트를 이해하는 것이 중요합니다. 액세스 제어 및 권한에 대한 전략에 따라 사용자가 코드로도 관리되는 UI의 리소스를 변경할 수 있습니다. 이 구성 드리프트를 감지하면 변경 사항을 이해하고 필요한 경우 구성을 수정할 수 있습니다.
두 가지 주요 작동 모드가 있습니다.
- 감지 및 알림 : 이 모드에서는 드리프트가 감지되고 운영자에게 알림이 전송됩니다. 그러나 수정 사항은 자동으로 적용되지 않습니다.
- 감지, 수정 및 알림 : 이 모드에서 드리프트가 감지되고 가능한 경우 워크플로에 의해 자동으로 수정됩니다.
이 다이어그램은 구성 드리프트 워크플로를 구현하는 방법을 보여줍니다. 감지된 변경 사항은 시간 경과에 따라 경고 및 추적할 수 있는 New Relic에 보고됩니다.
구성 드리프트 참조 예
이 참조 예제는 GitHub Actions를 활용하여 정기적인 Terraform 계획 작업을 예약합니다. 감지된 변경 수는 New Relic에 보고되며 선택적으로 Terraform의 재적용을 시작할 수 있습니다.
결론
채택할 모범 사례
- 코드로 관찰 가능성 성숙도를 측정하기 위해 KPI를 명확하게 정의하고 구현합니다.
- 새로운 observability-as-code 기능을 구현하기 전에 현재 상태를 설정하고 전달합니다.
- 가능하면 자동화를 활용하여 환경 전반에 걸쳐 관찰 가능성 제공을 가속화하십시오.
- 코드를 통해 생성된 자산을 자동 문서화합니다.
- 구성 드리프트를 추적하고 처리합니다.
- 여러 환경에서 자산 재사용을 확대합니다.
가치 실현
이 프로세스가 끝나면 다음과 같은 이점을 알게 됩니다.
- 현재 코드로서의 관찰 가능성 성숙도를 쉽고 효과적으로 전달합니다.
- 환경을 관찰할 수 있는 시간을 줄입니다.
- 관찰 가능성을 구현하고 생산적인 시간을 확보하는 데 필요한 수작업을 줄입니다.
- 프로덕션 환경에서 운영 위험을 줄입니다.
- 문제를 더 빨리 감지하고 해결하는 능력을 향상시킵니다.
- 새 릴리스 배포 시간을 단축합니다.
- 조직 전체에 대해 원격 분석 데이터를 보다 실행 가능하게 만드십시오.
- 서비스 가용성 및 비즈니스 제공을 개선하십시오.