Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
본문으로 건너뛰기

개발자

Observability는 생산성을 향상시키고, 애플리케이션 성능을 개선하며, 더 나은 의사결정과 빠른 문제 해결을 통해 비즈니스 성공을 이끄는 데 있어 개발자에게 매우 중요합니다. 이 가이드는 Observability를 효과적으로 활용하기 위한 모범 사례와 권장 사항을 제공합니다.

개발자에게 Observability가 중요한 이유​

개발자는 여러 핵심 목적으로 Observability를 활용합니다:

  • 빠른 문제 식별 및 해결:
    • Observability를 통해 개발자는 문제를 빠르게 식별하고 진단할 수 있으며, 문제 해결 시간(MTTR)을 단축하고 전반적인 소프트웨어 전달 성능을 개선합니다
    • 시스템이 프로덕션에서 어떻게 동작하는지 이해하여 정보에 기반한 결정을 내리고 운영을 개선할 수 있습니다
  • 고객 경험 개선:
    • 시스템 동작을 분석하여 성능과 안정성을 최적화하고, 더 나은 고객 경험과 사용자 만족도 향상으로 이어집니다
    • Observability 도구는 사용자 상호작용을 모니터링하여 UI/UX 문제를 즉시 식별하고 해결할 수 있게 합니다
  • 팀 효율성 및 혁신 향상:
    • Observability 플랫폼은 운영 데이터에 대한 단일 정보 소스를 제공하여 팀 간 협업을 촉진하고 문제 해결 시간을 단축합니다
    • 자동화된 인사이트와 알림 덕분에 개발자는 수동 디버깅에 소비하는 시간을 줄이고 혁신에 더 집중할 수 있습니다
  • 데이터 기반 의사결정:
    • Observability는 시스템 성능에 대한 상세한 인사이트를 제공하여 개발자가 코드 개선 및 리소스 할당에 대해 데이터 기반 의사결정을 내릴 수 있게 합니다
    • 개선이 필요한 영역을 식별하여 조직의 투자 최적화와 시장 출시 시간 단축을 돕습니다
  • 복잡성 관리:
    • Observability는 시스템 상호 의존성에 대한 포괄적인 뷰를 제공하여 최신 클라우드 네이티브 및 멀티 클라우드 환경의 복잡성을 관리하는 데 도움을 줍니다
    • 개발자가 복잡성을 정제하고 관련 데이터에 집중할 수 있게 하여 보다 효율적인 개발 프로세스를 촉진합니다

코드 품질을 위한 모범 사례​

  • 이슈 추적 메트릭 모니터링:

    • JIRA, Trello 또는 기타 이슈 추적 플랫폼과 같은 도구를 사용하여 다음과 같은 메트릭을 추적합니다:
      • 티켓이 코드 리뷰에서 테스트 리뷰로, 다시 진행 중 상태로 얼마나 자주 이동하는지. 높은 수치는 역량 부족, 높은 복잡성 또는 부적절한 도구를 나타낼 수 있습니다.
      • 외부 의존성으로 인해 티켓이 차단되는 횟수. 높은 수치는 의존성 간 높은 결합도 및/또는 높은 복잡성을 나타낼 수 있습니다.
    • 권장 사항:
      • Amazon Q Developer와 같은 도구를 사용하여 자동화된 코드 리뷰로 생산성과 코드 품질을 향상시킵니다. Amazon Q Developer는 소프트웨어 개발 작업 속도를 최대 80%까지 높일 수 있으며, 빠른 개발 주기에서 휴먼 에러 가능성을 줄여 더 높은 품질의 코드에 기여합니다.
      • 회고의 일환으로 정기적인 메트릭 리뷰를 예약하여 개선점을 파악하고 지속적 개선 마인드를 육성합니다

  • 성능 메트릭을 위한 코드 계측:

    • 코드 구현의 성능 효율성과 확장성을 평가하여 코드 품질의 간접적 척도를 제공하는 다음 항목을 측정할 수 있도록 코드를 계측합니다
      • RED Method: 마이크로서비스의 요청(Requests), 오류(Errors), 지속시간(Duration)을 모니터링합니다. 이는 서비스 성능과 안정성에 대한 인사이트를 제공합니다.
      • USE Method: 시스템 리소스의 활용도(Utilization), 포화도(Saturation), 오류(Errors)를 추적합니다. 이는 병목 지점과 리소스 제약을 식별하는 데 도움이 됩니다.
    • 다른 서비스, 데이터베이스, 캐시 등 요청 처리 경로상의 모든 외부 의존성 호출에 계측을 추가합니다. 이를 통해 요청 처리 시간의 급격한 변화를 조사하고 문제의 근본 원인을 더 빠르게 식별하는 데 필요한 정보를 얻을 수 있습니다
    • 권장 사항:
      • 요청 지연 시간과 오류율에 대한 SLO(Service Level Objective)를 설정하고 이를 기반으로 더 나은 품질과 성능을 위한 개선을 추진합니다
      • 핵심 데이터 흐름 및 요청 처리 경로를 실행하는 자동화된 테스트에 계측 유효성 검증을 추가합니다
      • 시스템 성능과 코드 품질 측정의 기준선을 만들기 위한 자동화된 부하 테스트 작업을 구축합니다
      • 단일 요청의 성능 영향을 식별할 수 있도록 계측에 컨텍스트를 추가합니다
      • SDK에서 제공하는 자동 계측을 구성하고 활용하여 수동 계측 작업을 줄입니다

효율적인 로깅 및 모니터링​

  • JSON과 같은 구조화된 로그 형식을 사용하세요. 기존 애플리케이션의 경우 로그 변환 기능을 활용하여 더 많은 컨텍스트를 주입하고, 필드를 추가하거나 제거하는 것을 고려하세요
  • 의미 있는 신호를 도출하고 신호 간 교차 상관을 수행할 수 있도록 충분한 메타데이터를 포함한 와이드 이벤트 형식을 사용하세요.
  • OpenTelemetry 또는 ADOT SDK를 사용하면 로그에 추가 컨텍스트가 주입되어 신호 간 교차 상관이 가능해지고, 평균 식별 시간(MTTI)이 단축되어 평균 복구 시간(MTTR)이 감소합니다
  • 로그 레벨을 적절히 사용하세요 - 이를 통해 로그 볼륨과 수집 비용을 제어할 수 있습니다.
    • ERROR는 예상치 못한 오류 조건과 예상된 오류 조건 모두에 사용합니다. 근본 원인 분석을 가속화할 수 있도록 가능한 한 많은 추가 컨텍스트를 포함합니다.
    • INFO는 사용자 로그인과 같은 일반 런타임 이벤트에 사용하며, 이는 컨텍스트를 제공하고 중요한 정보입니다
    • DEBUG는 처리 경로의 호출을 로깅하여 애플리케이션의 흐름과 상태를 더 깊이 이해하는 데 사용합니다.
  • PII나 PHI와 같은 민감 정보로 간주될 수 있는 데이터는 로깅하지 마세요. 해당 요구사항이 있는 경우 데이터 보호 정책을 사용하거나 수집 시 데이터를 마스킹하는 것을 고려하세요. 원시 데이터를 볼 수 있는 사람을 제어하기 위해 IAM 정책을 사용합니다.
  • 로그 내에 메트릭을 포함하는 임베디드 메트릭 형식(EMF)을 사용하여 Observability 플랫폼에 대한 API 호출 수를 줄이고 비용을 절감합니다.
    • requestId와 같은 높은 카디널리티 차원을 가진 메트릭에는 EMF 사용을 피하세요
  • 알림:
    • 경직된 알림 임계값 설정을 피하기 위해 이상 탐지를 사용합니다. 이를 통해 시스템 사용량이 시간에 따라 변할 때 임계값을 업데이트하는 오버헤드를 피하고 알림 노이즈를 줄일 수 있습니다.
    • 메트릭 수학 및 복합 알림을 사용하여 특정 장애에 대해 생성되는 개별 알림 수를 줄입니다.
    • SLO가 위반 위험에 처하거나 실패할 때만 알림을 발생시킵니다. 이를 통해 팀이 불필요하게 깨어나는 것을 방지하고 인지적 부담과 컨텍스트 과부하를 줄일 수 있습니다
    • 장애 알림을 받은 사람이 조치를 취할 수 있는 경우에만 알림을 발생시킵니다
    • 가능한 경우 알림 해결을 자동화합니다. 예를 들어, 오토스케일링, 복제본 또는 대기 인스턴스로의 자동 장애 조치 등 플랫폼의 네이티브 구성을 활용합니다.
    • 알림을 받은 사람이 참조할 대시보드, 사용할 플레이북, 영향을 받는 서비스를 빠르게 식별할 수 있도록 알림 알림에 충분한 컨텍스트를 추가합니다
  • 대시보드:
    • 페르소나/이해관계자별로 하나 이상의 대시보드를 생성합니다.
      • 애플리케이션 개발자는 문제를 진단하고 애플리케이션의 성능을 이해하기에 충분한 컨텍스트가 필요합니다
      • 플랫폼 엔지니어는 SLO에 대한 영향과 주의가 필요한 인프라 구성 요소 및 이를 사용하는 서비스에 미치는 영향을 식별할 수 있는 컨텍스트가 포함된 대시보드가 필요합니다
      • 프로덕트 매니저는 사용자 여정, 제품 기능 사용 메트릭, 채택률, 이탈 지점 등을 보여주는 대시보드가 필요합니다
      • 비즈니스 이해관계자는 제품 채택률, 구독자 이탈 또는 비즈니스 성과와 매출에 영향을 줄 수 있는 항목을 보여주는 위젯에 관심이 있습니다
    • 모든 대시보드에서 일관된 시간대(예: UTC)를 사용합니다
    • 대시보드의 모든 위젯에서 동일한 시간 범위를 사용합니다
    • 대시보드에 더 많은 컨텍스트를 추가하기 위해 어노테이션을 사용합니다
    • 오류 해결을 돕는 컨텍스트를 제공하는 위젯만 대시보드에 배치합니다. 너무 많은 위젯은 노이즈와 인지적 과부하를 유발하여 MTTR이 높아집니다
      • 기타 참고용 위젯은 별도 대시보드로 이동하거나, 위젯이 너무 많지 않은 경우 대시보드 하단으로 이동합니다. 너무 많은 위젯은 로딩 시간에 영향을 주어 스트레스와 인지적 과부하를 높입니다.
    • 전체 대시보드가 단일 화면에 들어가고 노트북의 해상도와 화면 크기에서 추세가 보이도록 합니다
    • 대시보드에 대한 설명과 사용 방법에 대한 안내를 포함하는 위젯을 배치합니다
    • 위젯에 임계값을 구성하고 표시합니다
    • 추세와 스파이크가 평활화되어 목적을 상실할 수 있으므로 단일 위젯에 너무 많은 메트릭을 넣지 마세요. 이는 진단도 어렵게 만듭니다.
    • 추세와 스파이크가 보이도록 동적으로 조정되는 Y축을 사용합니다
  • 권장 사항:
    • 비용 제어:
      • 이해관계자 식별:
        • 기능 성능에 관심이 있는 다양한 페르소나를 결정합니다. 기능성, 가용성, 보안, 비용, 판매, 제품 사용 등이 포함됩니다.
        • 이해관계자에는 개발 팀, 최종 고객, 내부 비즈니스 이해관계자, 플랫폼 운영 팀 또는 애플리케이션 개발자가 포함될 수 있습니다.
      • 핵심 결과 식별:
        • 각 이해관계자에 대해 정량화 가능한 결과(예: 오류율, 요청 처리 시간, 분당 로그인 수, 분당 제품 구매 수, 장바구니 이탈 수 등)를 정의합니다. 이는 일반적으로 Service Level Objectives(SLO)를 사용하여 측정됩니다.
        • 페르소나별 SLO를 사용하여 필요한 계측을 식별합니다
      • 적절한 신호 선택:
        • 충분한 컨텍스트를 갖춘 와이드 로그는 메트릭과 트레이스로 변환할 수 있어 단일 정보 소스를 제공하고, 비용을 제어하며 신호 상관을 가능하게 합니다
        • Observability Strategy Workshop을 실행하여 애플리케이션에 계측할 적절한 신호를 식별합니다
    • 적절한 신호 선택:
      • 로그와 트레이스는 장애 또는 예상치 못한 동작의 근본 원인을 파악하는 데 도움을 줍니다. "특정 요청이 왜 실패했는가?" 또는 "요청 처리 시간의 p50이나 p99가 증가하면 요청 지속시간과 관련된 SLO에 대해 무엇을 알아야 하는가?"와 같은 질문에 답할 수 있는 로그를 추가하세요.
      • 메트릭은 기준선 성능을 이해하고, 추세와 이상을 예측하는 데 유용합니다. 예상대로 동작하지 않는 것을 사전에 알려줄 수 있습니다. 그러나 커스텀 메트릭은 비용이 높습니다.
    • 알림 피로 감소:
      • 구성에 따라 알림은 시스템의 문제를 사전에 또는 사후에 강조할 수 있습니다. 너무 많은 알림은 알림 피로와 비효율적인 팀으로 이어져 코드 품질과 제품 전달에 악영향을 줍니다.
    • 정기적 검토 및 지속적 개선:
      • 팀원 중 한 명이 정기적으로 대시보드를 모니터링하고 새로운 추세나 패턴을 보고하는 당번 로스터를 운영합니다.
      • 각 릴리스의 일정 부분을 신호 개선, 회고 및 로스터 관찰에서 식별된 격차에 따른 알림 임계값 및 대시보드 조정에 할당합니다
      • 반복적으로 발생하는 알림의 근본 원인 수정을 해결 노력과 알림 발생 횟수에 기반하여 우선순위를 지정합니다

프로파일링 및 성능 최적화​

  • 실제 사용자 모니터링(RUM):
    • AWS X-Ray 또는 New Relic과 같은 도구를 사용하여 실제 사용자 상호작용을 모니터링하고 성능 병목을 식별합니다. 주요 전환 포인트에 집중하고 기술적 성능과 비즈니스 성과(전환율, 이탈 지점) 모두를 측정합니다.
    • 체크아웃 흐름 및 가입 프로세스와 같은 핵심 사용자 경로의 모니터링을 우선시합니다.
    • 기준선 성능과 사용자 행동을 수립하여 비즈니스 성과에 영향을 줄 수 있는 이상 및 추세를 빠르게 식별할 수 있도록 합니다
  • 합성 모니터링:
    • Amazon Cloudwatch Synthetics와 같은 도구를 활용하여 사용자 상호작용을 시뮬레이션하고 다양한 조건에서 애플리케이션 성능을 테스트합니다. 합성 카나리는 사용자 영향이 감지되기 전에 문제를 식별하는 데 도움이 됩니다.
    • 합성 카나리로 헬스 체크와 시스템 가동 시간을 검증합니다.
  • 프로파일링 도구:
    • AWS X-Ray와 같은 도구를 프로파일링에 사용하여 성능 병목을 식별하고 리소스 활용을 최적화합니다
    • 트래픽 패턴에 따라 조정되는 동적 샘플링 비율을 설정하고 오류 트레이스와 이상치에 대한 적절한 보존을 유지합니다. 이를 통해 데이터 볼륨과 비용을 관리하면서 중요한 이슈에 대한 포괄적인 가시성을 확보합니다.
    • 테일 샘플링을 사용하여 오류 상태, 지속시간 임계값, 커스텀 속성에 기반한 고가치 트레이스를 우선시하는 여러 샘플링 정책으로 컬렉터를 구성합니다. 이를 통해 가장 가치 있는 트레이스가 샘플링에 포함되도록 합니다
  • OpenTelemetry:
    • OpenTelemetry의 자동 계측을 사용하여 성능 메트릭과 트레이스 수집을 간소화합니다. 수동 계측을 추가하기 전에 자동 계측이 제공하는 텔레메트리를 검증하고, 신호와 비용을 제어하기 위한 요구사항에 따라 자동 계측을 튜닝합니다.

오류 처리 및 디버깅 기술​

  • 일반:
    • 일시적 장애에 대해 지수 백오프를 사용한 재시도 메커니즘을 설계합니다. 외부 의존성에 대한 서킷 브레이커를 구현합니다. 이는 분산 시스템에서 특히 유용하며 다운스트림 컴포넌트/서비스에 대한 과도한 부하를 방지합니다. 모든 시나리오에 적용 가능하지 않을 수 있으므로 이 설계를 채택하기 전에 충분한 검토를 수행하세요.
    • 중요한 작업에 대한 폴백 메커니즘을 생성하고 실패한 트랜잭션에 대한 명확한 롤백 절차를 유지합니다.
    • 모든 진입점에서 입력 유효성 검사를 추가합니다.
    • 재시도 가능한 작업이 멱등성을 갖도록 합니다.
  • 로깅:
    • Cloudwatch Log Insights 저장된 쿼리의 레포지토리를 유지합니다. 폴더를 사용하여 쿼리를 그룹화합니다
    • 오류를 무시하지 마세요. 항상 로깅하거나 적절히 처리합니다.
    • 기타 관련 컨텍스트와 함께 상관 관계 ID 또는 요청 ID와 같은 식별자를 로그에 추가합니다.
  • 플레이북 및 런북:
    • 플레이북 작성 시 필요한 권한, 도구 및 예상 결과와 함께 명확하고 실행 가능한 단계를 포함합니다.
    • 플레이북과 런북에 검증 단계, 롤백 절차, 관련 대시보드 링크를 포함합니다.
    • 플레이북에 버전을 매기고 인시던트 후 학습 내용과 핵심 인사이트를 포함하여 업데이트합니다.
  • 샘플링 규칙 조정:
    • 서비스 중요도와 트래픽 패턴에 기반한 동적 샘플링 규칙을 구현합니다.
    • 오류 조건과 비즈니스 크리티컬 경로에 대해 더 높은 샘플링 비율을 설정합니다.
    • 운영 필요와 비용 고려사항에 따라 정기적으로 샘플링 규칙을 검토하고 조정합니다.

코드 리뷰 및 협업 전략​

  • 티켓 상세화:
    • 기능 상세화 프로세스의 일부로 Observability 요구사항을 식별합니다. 여기에는 다음이 포함될 수 있습니다
      • 영향을 받는 이해관계자 및 관련 SLO
      • 필요한 텔레메트리/신호
      • 필요한 알림
      • 생성하거나 업데이트할 대시보드 목록
  • 비난 없는 회고:
    • 모든 인시던트 후 비난 없는 회고를 수행하여 프로세스를 개선하거나 자동화를 추가할 기회를 찾습니다. 항상 변경 비용을 고려하고, 각 사후 분석 활동에서 완료 기한이 연결된 최소 하나 이상의 합의된 실행 항목을 도출합니다.
  • 운영 준비도 검토:
    • 플랫폼 및 운영 팀과 함께 운영 준비도 검토에 참여하여 Observability 체계의 격차를 식별합니다 - 이는 체크리스트가 될 수 있으며 프로덕션 배포 전 필수 활동이 될 수 있습니다. 여러 팀이 있는 대규모 조직에서 이 프로세스가 병목이 되지 않도록, 새 기능 및 릴리스 주기에 맞춰 정기적으로 수행합니다.
  • 권장 사항:
    • AWS Systems Manager Incident Manager와 같은 도구를 사용하여 사후 인시던트 분석을 안내받습니다
    • 운영 준비도 검토 체크리스트 또는 프로세스에 포함할 질문에 대한 영감을 얻기 위해 Operational Readiness Review를 참조합니다.
    • 회고, 운영 준비도 검토에서 얻은 학습 내용은 항상 공유합니다 - 위키나 메일 그룹 구독을 통해 공유할 수 있습니다

API 설계 및 문서화 지침​

  • 버전 관리:
    • API에 버전을 매기고 처리되는 모든 요청에 대해 버전이 컨텍스트로 추가되도록 합니다
    • 커스텀 메트릭을 보낼 때 해당되는 경우 버전을 차원으로 추가합니다
    • 한 버전에서 다른 버전으로의 전환을 명확히 구분하기 위해 대시보드에 어노테이션 또는 식별자를 추가합니다
    • 각 버전에 대한 요청을 추적하고 버전 사용량을 시각화하는 위젯을 배치합니다. 이를 통해 요청이 예상대로 라우팅되는지 확인하고 근본 원인 식별 시간을 줄일 수 있습니다. 이전 버전을 폐기하고 제거할 때 더 높은 확신을 제공합니다
  • 하위 호환성:
    • 이전 API 버전과 관련된 코드 경로를 제거하기 전에 이전 버전에 대한 요청이 없는지 확인합니다
  • 배치 API:
    • 각 개별 요청의 상태와 전체 배치 요청에 대한 신호를 발생시킵니다
    • 배치 요청 ID와 개별 요청을 식별하는 컨텍스트를 로그에 추가합니다