View a markdown version of this page

2단계: 관찰성 구현 - AWS 권장 가이드
관찰성 플랫폼 선택애플리케이션 계측원격 측정 수집관찰성 구성 요소 구현관찰성 시스템 검증

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

2단계: 관찰성 구현

이 단계에서는 팀이 North Star로 점진적으로 이동하는 프로세스를 시작합니다.

관찰성 플랫폼 선택

첫 번째 단계는 신호를 수집, 시각화 및 분석하고 알림을 전송하는 데 적합한 도구를 식별하는 것입니다. 도구를 선택할 때 기능 세트, 라이선스 모델, 가격, 기술 요구 사항 및 유지 관리를 고려합니다.

기능 세트

고려해야 할 몇 가지 질문은 다음과 같습니다.

  • 구성 가능성 및 사용자 지정. 도구는 조사 경험을 간소화하고 MTTR을 줄이는 데 도움이 되는 어떤 기능을 제공합니까? 도구가 경보 상관관계, 지표 수학, 누락된 원격 측정 처리의 유연성 또는 이상 탐지를 제공합니까?

  • 세분화. 원격 측정 신호 수집 및 시각화에서 지원되는 세분화는 무엇입니까?

  • 페르소나. 도구가 개발자, 플랫폼 엔지니어 및 기타 페르소나에게 제공하고자 하는 경험을 지원하나요? 기술 페르소나와 비즈니스 페르소나 모두에서 작동하나요?

  • 위젯. 대시보드는 어떤 종류의 위젯을 지원하나요? 도구에서 사용자 지정 위젯 생성을 허용하나요?

  • 사전 구축된 솔루션. 도구에서는 가치 실현 시간을 줄이기 위해 어떤 종류의 사전 구축된 관찰성 솔루션을 제공하나요?

  • 자동화 및 생성형 AI. 이 도구는 사용자와 팀의 토일을 자동화하거나 줄이는 데 도움이 되는 어떤 기능을 제공하나요? 예를 들어 자동 이상 탐지, 예측 분석 및 기타 생성형 AI 기능은 가정 및 알 수 없는 것(즉, 인식하지 못하거나 완전히 이해하지 못하는 것)의 스트레스를 줄이는 데 도움이 될 수 있습니다. 도구가 생성형 AI/ML 모델을 사용하여 대규모 데이터 분석을 개선하는 것을 지원하나요? AIOps를 자동화하고 구현할 수 있는 옵션이 제공되나요?

  • 보안. 도구는 어떤 종류의 인증 및 권한 부여 통합을 지원하나요? 사용자 및 로그인 경험이 조직의 요구 사항을 충족하나요?

  • OpenTelemetry 지원. 도구와 에이전트가 OpenTelemetry를 지원하나요? 대부분의 관찰성 플랫폼은 OpenTelemetry 호환 신호 수집을 지원하지만 모든 에이전트가 이러한 신호를 관찰성 플랫폼에 전달하는 구성 옵션을 제공하는 것은 아닙니다.

  • 통합. 도구는 어떤 통합을 제공하나요? Slack에게 알림을 전송해야 하는지, 팀원을 호출해야 하는지 또는 해결을 자동화해야 하는지 고려합니다.

  • 확장성. 도구의 확장성과 성능은 어느 정도입니까? 관찰성 솔루션은 수요와 사용량이 증가함에 따라 확장해야 하므로 애플리케이션을 사용할 수 없는 경우에도 진단을 제공할 수 있습니다.

  • 지원. 어떤 지원 모델이 제공되나요? MTTR 및 애플리케이션 가용성 목표 또는 서비스 수준 계약(SLAs)을 충족할 수 있도록 애플리케이션이 실패하더라도 관찰성 도구를 사용할 수 있어야 합니다. 오픈 소스 솔루션은 제한된 공식 지원을 제공할 수 있습니다.

라이선스 및 배포 모델

솔루션의 라이선스 모델(오픈 소스 또는 상용) 및 배포 모델(자체 호스팅 또는 클라우드 기반)을 고려합니다. 오픈 소스 옵션은 종종 선결제 비용이 낮지만 가치를 제공하기 전에 배포, 설정 및 구성, 유지 관리 및 팀 업그레이드에 더 많은 시간이 필요할 수 있습니다. 오픈 소스 옵션을 고려하는 경우 관찰성 전문가로 구성된 전담 팀이 필요할 수 있습니다. 상용 소프트웨어는 일반적으로 더 높은 선결제 비용으로 더 빠른 가치 실현 시간을 제공하며, 채택, 복잡성 및 성숙도가 증가함에 따라 전담 관찰성 팀의 필요성이 시간이 지남에 따라 진화합니다. 자체 호스팅 솔루션은 클라우드 기반 솔루션에 비해 배포, 설정 및 구성, 유지 관리 및 운영 오버헤드에 더 많은 시간이 필요합니다.

차원 사용

애플리케이션이 새로운 사용자, 더 큰 아키텍처 공간 또는 새로운 기능 및 애플리케이션을 확보함에 따라 도구의 요금 모델이 총 소유 비용(TCO)에 어떤 영향을 미칠까요? 예를 들어, 일부 일반적인 라이선스 모델은 영구적이거나 구독, 명명된 사용자 수, 소비 또는 볼륨을 기반으로 합니다. 애플리케이션과 관찰성 도구가 사용량을 어떻게 확장하고 라이선스 모델이 도구 비용에 어떤 영향을 미칠 수 있는지 고려합니다.

팀 스킬

팀의 현재 스킬 세트와 성숙도에 따라 필요한 기술 향상 정도를 결정해야 합니다. 공급업체에서 팀을 교육하기 위해 어떤 종류의 지원을 제공하는지 고려합니다. 또한 조직 구조가 선택한 도구의 구성 및 관리를 지원하는지 여부를 고려합니다. 예를 들어 OpenTelemetry를 선택하는 경우 관찰성을 전문으로 하는 별도의 팀을 설정하는 것이 좋습니다.

운영 및 유지 관리

다음 질문을 평가합니다.

  • 관찰성 에이전트 또는 수집기는 어떤 배포 옵션을 제공합니까? 이러한 옵션이 아키텍처의 요구 사항을 충족하나요? 예를 들어 관찰성 도구에 컨테이너화된 배포를 사용하는 경우 데몬 세트 또는 사이드카를 지원하나요? 보안 및 기타 모든 프로세스에 부합하도록 운영 팀이 수행하거나 사용해야 하는 추가 단계 또는 도구는 무엇입니까?

  • 솔루션을 유지 관리하는 데 필요한 노력은 무엇입니까? 에이전트 또는 수집기를 업데이트하는 프로세스는 얼마나 간단하거나 자동화되어 있습니까? 에이전트 또는 수집기의 관리는 동일하게 유지되지만 완전 관리형 및 클라우드 기반 관찰성 인터페이스는 일반적으로 자체 배포 및 호스팅 애플리케이션에 비해 운영 오버헤드가 낮습니다. 팀 구조를 고려하고 선택한 옵션을 유지 관리하는 데 드는 인적 비용을 고려합니다.

애플리케이션 계측

이전 섹션의 질문에 대한 답변은 애플리케이션을 계측하는 데 필요한 정보, 즉 애플리케이션에 원격 측정 신호를 캡처하고 동작을 측정, 관찰 및 검증하는 코드를 추가하는 데 필요한 정보를 제공합니다. 애플리케이션 언어에 대한 OpenTelemetry SDKs와 같은 SDK를 사용하여 애플리케이션을 자동으로 계측할 수 있습니다. 격차를 해소하고 end-to-end 가시성을 보장하기 위해 수동 계측 코드를 추가해야 할 수도 있습니다. 추가하는 원격 측정에 대해 의도적으로 생각하고 이전 단계에서 설정한 하나 이상의 SLIs 및 SLOs에 다시 연결할 수 있는지 확인합니다.

원격 측정 수집

1단계에서 우선순위를 지정한 결과에 따라 관련 원격 측정 신호를 수집하도록 원격 측정 수집기 또는 에이전트를 구성합니다.

관찰성 구성 요소 구현

원격 측정이 흐르고 관찰성 플랫폼으로 수집되면 대시보드, 알림, 플레이북 및 런북을 생성합니다.

  • 대시보드: 우선순위가 지정된 결과와 관련된 현재 및 과거 추세의 시각적 표현을 포함하여 관련 정보가 포함된 대시보드를 생성합니다. 1단계에서 정의한 이해관계자가 이러한 대시보드를 사용할 수 있도록 합니다. 자세한 내용은 Amazon Builders' Library 웹 사이트에서 운영 가시성을 위한 대시보드 구축을 참조하세요.

  • 알림: 결과가 위험하거나 위반될 때 팀에 알리도록 알림을 정의합니다. 보안 및 성능 문제에 대한 알림을 추가하는 것이 좋습니다. 다음을 채택하여 알림을 최적화하여 알림 피로와 비용을 줄입니다.

    • 이상 탐지를 사용하면 자주 조정해야 하는 하드 임계값을 설정하지 않고 알 수 없는 항목의 발생을 줄일 수 있습니다.

    • 각 지표에 대해 개별 알림을 설정하는 대신 여러 관련 지표를 함께 살펴보는 지능형 알림 조합을 사용합니다. 예를 들어 CPU, 메모리 및 응답 시간에 대해 별도의 알림을 설정하는 대신 이러한 지표가 집합적으로 실제 문제를 나타내는 경우에만 트리거되는 하나의 의미 있는 알림을 생성합니다. 이 접근 방식은 알림 노이즈를 크게 줄이고 팀이 격리된 지표 스파이크에 대응하는 대신 서비스에 영향을 미치는 실제 문제에 집중할 수 있도록 도와줍니다.

    • 사용자 경험 또는 결과가 위험한 경우에만 알림을 생성합니다. 예를 들어 애플리케이션에 활성 사용자가 없는 경우 자동 업그레이드로 인한 CPU 급증에 대한 알림을 받지 마세요.

  • 플레이북: 플레이북은 인시던트 또는 알림에 대응하는 사람에게 사고 모델과 컨텍스트를 제공하고 근본 원인을 더 빠르게 식별하는 데 도움이 됩니다. 고도로 결합되고 복잡한 애플리케이션과 계측이 부족하지만 1단계에서 식별하고 우선순위를 지정한 결과에 직접적인 영향을 미치는 애플리케이션을 위한 플레이북을 만드는 것이 좋습니다.

  • 런북: 런북을 사용하여 인시던트 또는 알림을 해결하는 데 필요한 단계를 정의합니다.

관찰성 시스템 검증

소프트웨어 개발 수명 주기(SDLC) 동안 대시보드가 시스템 테스트 중에 예상되는 동작과 업데이트를 제공하는지 확인합니다. 카오스 엔지니어링을 구현하고 플레이북 및 런북에 문서화된 단계를 검증하여 정확성과 용도를 충족하는지 확인합니다. 또한 알림 소유권 및 에스컬레이션 경로를 검증해야 합니다.