View a markdown version of this page

1단계: North Star 정의 - AWS 권장 가이드

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

1단계: North Star 정의

관찰성의 성공적인 구현은 운영 및 도구뿐만 아니라 소유권, 지속적인 개선 및 선제적 문제 해결의 문화를 조성하는 것입니다. 성공적인 전략과 마찬가지로 관찰성 전략에는 사람, 프로세스, 기술이라는 세 가지 원칙을 전체적으로 고려해야 합니다.

관찰성 태세를 설정하거나 개선하려면 먼저 무엇이 중요한지 정의하고, 비즈니스 성과에서 다시 작업하고, 비즈니스, 팀 및 제품이 발전함에 따라 전략을 지속적으로 검토, 조정 및 재조정하는 것이 좋습니다.

이 첫 번째 단계에서는 North Star를 정의하고 설정합니다. North Star는 조직에 좋은 모습이 무엇인지에 대해 합의되고 잘 이해된 정의입니다. 비즈니스가 발전하거나, 새 제품, 애플리케이션 또는 서비스를 시작하거나, 주요 아키텍처 변경을 설계할 때이 단계의 일부 또는 모든 활동을 다시 검토하여 관찰성 플랫폼과 조직 요구 사항을 재평가하는 것이 좋습니다.

개발 수명 주기 초기에 관찰성 통합(교대-왼쪽 접근 방식)

관찰성을 엔지니어링, 운영 및 제품 팀의 모든 구성원에 대한 책임으로 삼고 단위 테스트 또는 보안을 처리하는 방식과 유사한 주요 기능 요구 사항으로 취급합니다. 이는 운영 팀에서 개발 팀으로 책임을 이전하지 않지만 여러 팀에서 필요한 협업을 강조합니다. 팀이 개발 수명 주기 초기에 공동 작업으로 다음 활동을 수행하는 것이 좋습니다. 이러한 작업은 티켓별, 기능별 또는 제품별로 수행할 수 있습니다.

  • 이해관계자를 식별합니다. 이해관계자는 누구이며이 기능이나 제품이 예상대로 작동하지 않는 경우 이해관계자에게 중요한 것은 무엇입니까? 이해관계자를 식별할 때는 기능, 가용성, 보안, 비용, 판매 및 제품 사용과 같은 측면을 고려하세요. 이해관계자에는 팀, 제품 고객, 내부 비즈니스 이해관계자, 플랫폼 운영 팀 구성원, 애플리케이션 개발자가 포함될 수 있습니다. 시나리오에 따라 보안 및 재무 팀도 이해관계자가 될 수 있습니다.

  • 주요 결과를 식별합니다. 주요 성과와 비즈니스 및 각 이해관계자에 미치는 영향을 결정합니다. 각 성과 및 이해관계자의 성공과 실패를 식별합니다. 결과는 일반적으로 서비스 수준 목표(SLOs)로 정의되며 정량화 가능해야 합니다. SLO는 각 결과에 대한 척도입니다. 좋은 SLO에는 목표로 노력하거나 유지해야 하는 목표 값이 있습니다. SLO는 사용자 만족도의 척도일 수 있습니다. 서비스 수준 지표(SLI)는 SLO를 충족하는지 확인하는 데 사용되는 실제 측정 또는 지표입니다. 이는 목표를 기준으로 추적하는 정량화 가능한 데이터 포인트입니다. 예를 들어 MTTR을 60% 줄이거나, 애플리케이션 가용성을 99.99%로 유지하거나, 개발자 생산성을 30% 개선합니다.

    애플리케이션 가용성을 99.99%로 유지하는 예제를 살펴보고 성공을 측정하고 검증하는 데 필요한 SLO, SLI 및 지표를 정의해 보겠습니다. 이 예제에서는 RESTful 애플리케이션을 고려하고 애플리케이션 가용성을 모든 수신 요청의 성공적인 완료로 정의해 보겠습니다. 이를 위해서는 애플리케이션에 대한 총 요청 수와 각 요청의 완료 상태를 측정해야 합니다. 이를 SLO 및 SLI로 변환할 때는 수신 요청을 캡처하는 지표 하나와 요청 상태를 캡처하는 지표 하나가 필요합니다. 모든 요청이 성공적으로 완료되면 애플리케이션을 사용할 수 있는 것으로 간주됩니다. 하나 이상의 요청에 오류가 발생하면 애플리케이션을 사용할 수 없는 것으로 간주됩니다. 따라서 SLI는 오류 상태인 요청 완료의 합계를 5분 간격으로 수신되는 요청의 합계로 나눈 값입니다. 실제로 오류율입니다. 이 SLI에 목표를 추가하여 SLO로 전환할 수 있습니다. 예를 들어 3회 연속 5분 간격으로 오류율이 0.1% 미만이 되도록 Strive를 실행할 수 있습니다.

  • 주요 결과의 우선순위를 정합니다. 각 결과에 대해 설정한 우선 순위에 따라 모든 작업을 동시에 수행하는 대신 가장 큰 영향을 미치는 결과에 먼저 집중하도록 선택할 수 있습니다. 작게 시작하고 반복하여 관찰성 태세를 조금씩 개선합니다. 관찰성은 성숙도와 이점을 높이기 위해 지속적인 검토, 감사, 개선 및 개선이 필요한 프로세스입니다. 또한 우선순위 지정을 통해 식별된 결과에 대한 점진적 마일스톤을 정의할 수 있습니다.

  • 필요한 계측을 식별합니다. 이전 단계에서 식별된 대로 중요한 결과에 영향을 미칠 수 있는 아키텍처 또는 구현의 구성 요소 및 관련 기능은 무엇입니까? 예를 들어 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 애플리케이션을 실행하면 코어 수와 사용 가능한 RAM이 애플리케이션의 응답성과 처리량에 영향을 미칠 수 있습니다. 이 단계에서는 사용하는 도구 또는 라이브러리가 이미이 계측 중 일부를 제공하는지 확인하는 것도 도움이 될 수 있습니다. 일련의 예비 검토를 수행하거나 티켓의 준비 완료(DoR) 정의에 다음과 같은 질문을 추가하면이 활동이 표준 프로세스의 일부가 될 수 있습니다.

    • 이 작업이 실패할 경우 실패를 해결하기 위해 알아야 할 사항은 무엇입니까? 일반적인 작업이나 문제가 있는 작업은 관련된 구성 요소에 어떤 영향을 미칩니까? 로그, 지표 또는 추적 등이 작업은 어떤 종류의 신호를 전송해야 합니까? 이 계측의 값과 비교한 비용은 얼마입니까? SLOs를 위반하지 않으면 어떤 종류의 집계가 허용됩니까?

    • 이 작업에서 장애를 일으킬 수 있는 구성 요소와 종속성은 무엇입니까? 어떤 구성 요소 또는 종속성이 장애를 일으켰는지 어떻게 식별할 수 있습니까? 이러한 구성 요소와 종속성의 다양한 구성 레버는 무엇이며 각각 작업에 어떤 영향을 미치나요?

    • SLI 및 SLO를 정확하게 측정하는 데 필요한 지표 세부 수준 및 샘플링 속도는 얼마입니까?

  • 성공 기준을 정의합니다. 우선순위가 지정된 각 결과에 대해 목표 달성 여부에 따른 영향과 일치하는 임계값을 정의합니다. 성공 기준은 팀이 알림에 응답할 때 팀에 추가 컨텍스트를 제공합니다. 또한 필요한 가시성을 위해 계측 비용을 예측하고 절충할 수 있는 기능도 제공합니다.

효과적인 조직 및 팀 구조 설정

아키텍처 복잡성과 비즈니스 규모에 따라 관찰성에 초점을 맞춘 전담 팀을 구성해야 할 수 있습니다. 이 팀은 관찰성 도구를 구성하고 다른 팀을 위한 관찰성 플랫폼을 설정할 책임이 있습니다. 또한 표준 OpenTelemetry 구현을 선택하는 경우 전용 팀을 설정하는 것이 좋습니다. 소규모 조직에서는 관찰성을 모든 팀원의 추가 책임으로 할당하고 팀 전체에서 모범 사례를 전파하고 적용하는 관찰성 챔피언을 지정할 수도 있습니다. 이러한 챔피언은 하루의 일부를 자원하여 프로세스를 정의하고 조직의 표준을 설정합니다. 이들은 자율 조정 팀으로 작동하거나 전담 관찰성 전문가가 주도할 수 있습니다. 다음 다이어그램은 투자가 조직의 접근 방식을 결정하는 방법을 보여줍니다.

투자를 기반으로 관찰성에 대한 책임을 결정하는 방법.

챔피언은 팀에 완전히 포함되거나(다음 그림의 팀 2에 표시됨) 팀 전체에서 교체하여 모범 사례를 수립하고 홍보하는 지원 팀의 일원이 될 수 있습니다(그림의 팀 1).

팀을 활성화하거나 관찰성 챔피언을 임베딩하도록 설정합니다.

비용 할당 추적

조직은 리소스 사용 및 비용에 대한 팀별 책임을 설정하면서 지표, 로그 및 추적 전반에 걸쳐 포괄적인 비용 추적 및 가시성을 구현해야 합니다. 재무 운영(FinOps) 사례를 성공적으로 통합하려면 체계적인 데이터 보존 및 수집 최적화와 결합된 예산 알림이 포함된 자동 모니터링 시스템이 필요합니다. 엔지니어링 및 재무 팀은 공유 대시보드와 정기적인 검토를 통해 목표를 조정해야 합니다. 조직은 명확한 차지백 모델과 비용 할당 전략을 구현하여 소유권과 책임을 높일 수 있습니다.

표준 정의

알림 및 대시보드 전략을 포함하여 애플리케이션에 필요한 기본 신호와 원격 측정을 식별하고 정의합니다. 모든 애플리케이션에 대한 체크리스트 또는 공식 검토 프로세스를 생성합니다. AWS 관찰성 모범 사례 웹 사이트에서는 적절한 알림 임계값 설정, 알림 피로 최소화, 각 페르소나에 대해 충분한 컨텍스트가 있는 대시보드 생성 등과 같은 알림 및 대시보드 생성 지침을 제공합니다. 연결되고 선별된 관찰성 경험은 Amazon CloudWatch 설명서의 애플리케이션 신호를 참조하세요.

에스컬레이션 프로세스 설정

에스컬레이션 메커니즘, 알림 소유권 및 대응 절차를 설정하고 적용하는 것이 중요합니다. 에스컬레이션이 중단되지 않는 문화를 장려하는 것이 좋습니다.

훈련을 통한 기술 향상

기존 및 신규 팀원의 역량을 높이고, 관찰성의 중요성을 강화하고, 지속적인 개선 문화를 조성하는 가장 좋은 방법을 식별합니다. 조직의 요구 사항에 따라 관찰성 챔피언 또는 전문가가 제공하는 사전 녹화된 온디맨드 교육 또는 강의실 교육 중에서 선택할 수 있습니다. AWS 계정 팀은 One Observability 워크숍 또는 GameDays와 같은 심층적인 실습 훈련 세션을 제공하여 관찰성 기술과 모범 사례를 지도하고 개선할 수 있습니다. 또한 모범 사례를 강화하고 조직에서 정의한 표준을 홍보하는 메커니즘을 통합합니다.