라이브 성능 문제에 대응하기 위한 권장 사항

이 Azure Well-Architected Framework 성능 효율성 검사 목록 권장 사항에 적용됩니다.

PE:11 라이브 성능 문제에 대응합니다. 명확한 통신 및 책임 라인을 통합하여 성능 문제를 해결하는 방법을 계획합니다. 문제가 있는 상황이 발생하면 학습한 내용을 사용하여 예방 조치를 식별하고 워크로드에 통합합니다. 비슷한 상황이 발생할 때 더 빨리 정상 작업으로 돌아가는 메서드를 구현합니다.

이 가이드에서는 라이브 성능 문제에 대응하기 위한 모범 사례를 설명합니다. 라이브 성능 문제는 워크로드의 최적 작동을 방해할 수 있는 실시간 문제 및 병목 상태를 나타냅니다. 이러한 문제를 즉시 해결하면 성능 딸결의 즉각적인 검색 및 수정이 용이할 뿐만 아니라 워크로드가 성능 벤치마크를 일관되게 충족할 수 있습니다. 이 문제를 해결하지 못하면 속도 저하, 충돌 및 시스템 응답하지 않는 등의 합병증이 발생할 수 있으며 사용자 환경이 저하됩니다. 또한 사용자가 작업을 효율적으로 완료하지 못하도록 방지하고 organization 평판을 손상할 수 있습니다.

정의

용어 정의
데이터 상관 관계 워크로드의 다양한 부분에서 로그, 메트릭 및 이벤트를 정렬하여 기본 원인을 정확히 파악합니다.
근본 원인 분석 문제를 담당하는 기본 요소를 식별하는 프로세스입니다.
자동 복구 사람의 개입 없이 문제를 자동으로 복구할 수 있는 기능입니다.
자가 예방 잠재적인 문제 및 오류를 방지하기 위한 워크로드 내 구현

주요 디자인 전략

라이브 성능 문제가 발생하면 올바른 데이터와 문제에 대응할 계획을 준비해야 합니다. 이 계획에는 명확한 의사 소통 및 책임 라인이 포함되어야 합니다. 주요 목표는 정기적인 작업에 빠르게 복귀하고 인시던트로부터 인사이트를 제공하는 솔루션을 구현하는 것입니다. 예방 조치를 워크플로에 통합하는 것은 중요한 전략입니다. 목표는 동일한 문제가 다시 발생하지 않도록 방지하거나 예방할 수 없는 경우 성능에 미치는 영향을 줄이는 것입니다.

문제 준비

라이브 사이트 성능 문제에 대한 이상적인 응답은 정확하고 빠릅니다. 성능 수정의 정밀도와 속도에는 준비가 필요합니다. 라이브 성능 문제에 효과적으로 대응하려면 주요 성능 메트릭을 모니터링하고, 문제의 근본 원인을 식별하고, 적절한 솔루션 또는 최적화를 구현하는 것이 중요합니다. 이러한 단계를 수행하려면 워크로드 로그를 분석하고, 성능 테스트를 수행하고, 코드 또는 구성을 최적화하고, 리소스를 확장해야 할 수 있습니다. 다음 예제에서는 몇 가지 중요한 준비 영역을 간략하게 설명합니다.

  • 정확한 아키텍처 다이어그램이 있습니다. 아키텍처 다이어그램은 모든 구성 요소를 포함하고 상호 작용하는 방법을 보여 주어야 합니다. 시각적 표현은 성능 저하 또는 사용 불가로 이어질 수 있는 병목 상태 및 단일 실패 지점을 식별하는 데 도움이 될 수 있습니다. 문제를 일으키기 전에 이러한 문제를 파악하고 제거하는 것이 가장 좋지만, 최신 다이어그램을 사용하면 스트레스가 많은 순간에 문제를 정확히 파악하는 데 도움이 될 수 있습니다.

  • 데이터 액세스를 확인합니다. 모니터링 프로세스의 데이터 및 로그는 실시간으로 성능 문제에 대응하고 근본 원인 분석을 수행하는 데 중요합니다. 그러나 데이터의 무결성과 기밀성을 유지하는 것이 중요합니다. 라이브 사이트 성능 문제에 대응하려면 일반적으로 액세스할 수 없는 기본 데이터에 액세스해야 하는 경우가 많습니다. 문제가 발생할 때 직원이 필요한 데이터에 액세스할 수 있도록 해야 합니다. 그러나 시간 제한, 최소 권한 액세스 권한만 부여해야 하며 권한 있는 담당자에게 해당 액세스를 제한해야 합니다.

  • 자동 경고를 설정합니다. 경고는 문제가 발생하는 즉시 식별하고 해결하는 데 도움이 될 수 있습니다. 워크로드 성능이 성능 기준에서 벗어나면 경고가 알림을 생성해야 합니다. 시간이 지남에 따라 너무 많거나 너무 적은 알림을 생성하지 않도록 경고 구성을 조정해야 합니다. 사용하는 모니터링 솔루션은 경고를 생성하기에 충분한 데이터를 수집해야 합니다. 이러한 경고는 성능 목표 및 설정된 기준에 맞춰야 합니다. 목표와 관련된 문제에 대한 경고를 생성하지 않아야 합니다. 경고의 예로는 CPU 사용량, 메모리, 응답 시간 및 데이터베이스 성능 저하가 있습니다.

심사 계획 만들기

심사 계획을 만들려면 라이브 사이트 성능 문제를 식별, 에스컬레이션, 분석, 우선 순위 지정 및 전달하기 위한 구조화된 접근 방식을 고안해야 합니다. 심사 계획은 라이브 성능 문제에 대응하기 위한 전략입니다. 명확한 역할 및 절차를 통해 성능 중단을 신속하고 효과적으로 해결할 수 있습니다. 대부분의 성능 문제는 재해 복구 프로토콜에 도움이 되지 않지만 심사 계획이 필요할 정도로 워크로드 기능에 영향을 줄 수 있습니다. 잘 문서화된 심사 계획을 사용하면 모든 팀 구성원이 정렬되고 신속하게 작동하여 사용자 및 워크로드에 미치는 영향을 최소화할 수 있습니다. 심사 계획에는 다음 구성 요소가 포함되어야 합니다.

  • 식별 및 모니터링: 성능 문제를 실시간으로 식별하고 모니터링하는 시스템을 구현합니다. 의사 결정을 내리거나 문제를 더 높은 수준으로 에스컬레이션할 수 있는 사람들의 연락처 정보 목록이 있어야 합니다. 또한 이 계획은 역할과 책임을 식별해야 합니다. 보호된 정보에 액세스할 수 있는 계정과 기간 동안 문서화해야 합니다.

  • 에스컬레이션 프로세스: 성능 문제가 적절한 팀 또는 개인에게 적시에 에스컬레이션되도록 명확한 에스컬레이션 프로세스를 정의합니다. 프로세스 정의에는 문제를 에스컬레이션하기 위한 연락처 정보 및 지침이 포함되어야 합니다.

  • 근본 원인 분석: 근본 원인 분석을 수행하기 위한 프로세스를 개발하여 각 성능 문제의 근본 원인을 식별합니다. 프로세스에는 로그 및 성능 메트릭을 분석하고 진단 테스트를 수행하여 각 문제의 원인을 정확히 파악해야 합니다.

  • 우선 순위 지정: 우선 순위 지정 프레임워크를 설정하여 성능 문제의 심각도를 확인하고 워크로드 및 사용자에게 미치는 영향에 따라 우선 순위를 지정합니다.

  • 커뮤니케이션: 이해 관계자에게 성능 문제의 상태 해결 진행 상황에 대한 정보를 제공하는 통신 계획을 만듭니다. 정기적인 업데이트, 상태 보고서 및 명확한 통신 채널을 고려합니다.

  • 설명서: 모든 단계, 프로세스 및 모범 사례를 포함하여 심사 계획을 문서화합니다. 이 설명서는 성능 문제에 대응하는 데 관련된 팀 구성원이 쉽게 액세스할 수 있어야 합니다.

문제를 식별하고 resolve 방법을 개발합니다.

라이브 성능 문제를 해결하려면 라이브 워크로드에서 성능 저하 또는 비효율성을 유발할 수 있는 요인을 식별하고 해결하는 작업이 포함됩니다. 모니터링 중에 수집하는 데이터는 성능 관련 인시던트 조사 및 resolve 때 매우 중요합니다. 이 데이터는 성능 메트릭의 기록 레코드를 제공합니다. 모니터링 데이터를 사용할 수 있는 경우 근본 원인을 분석하고 기여 요인을 식별할 수 있습니다. 각 성능 문제를 이해하고 해결하려면 모든 관련 모니터링 데이터를 사용해야 합니다.

근본 원인 분석 사용

근본 원인 분석에는 가설 테스트가 필요합니다. 모니터링 데이터를 검토한 후 성능 문제의 잠재적 원인을 나열하고 테스트해야 합니다. 라이브 성능 문제에 대한 근본 원인 분석을 수행하려면 다음 단계를 수행할 수 있습니다.

  1. 정보 수집 성능 문제에 대해 가능한 한 많은 정보를 수집합니다. 예를 들어 오류 메시지, 로그, 성능 메트릭 및 기타 관련 데이터가 있습니다.

  2. 문제를 정의합니다. 문제가 워크로드 또는 사용자에게 미치는 영향과 증상을 식별하여 문제를 명확하게 정의합니다.

  3. 잠재적인 원인을 조사합니다. 성능 문제가 발생하는 워크로드의 특정 구성 요소 또는 영역을 식별하여 분석의 scope 좁힐 수 있습니다. 수집된 정보를 기반으로 성능 문제의 잠재적 원인을 식별합니다. 이 프로세스에는 코드, 구성 설정, 인프라 또는 외부 종속성 분석이 포함될 수 있습니다.

  4. 데이터의 상관 관계를 지정합니다. 수집된 데이터를 자세히 분석하여 성능 문제에 영향을 미칠 수 있는 패턴, 변칙 또는 상관 관계를 식별합니다. 데이터 상관 관계는 성능 문제 및 원인을 식별하는 데 핵심입니다. 로그 검토, 성능 메트릭 분석 및 테스트 수행이 포함될 수 있습니다.

  5. 가설을 테스트합니다. 식별할 수 있는 잠재적인 원인에 따라 가설을 작성합니다. 테스트를 수행하여 가설의 유효성을 검사하거나 반박합니다. 테스트 환경을 사용하여 오류를 복제할 수 있는지 확인해야 합니다.

  6. 솔루션을 구현합니다. 근본 원인을 파악한 후에는 성능 문제를 해결하기 위한 솔루션을 개발하고 구현합니다.

  7. 모니터링하고 유효성을 검사합니다. 솔루션을 구현한 후 워크로드를 지속적으로 모니터링하여 성능 문제가 해결되었는지 확인합니다. 성능 메트릭 및 사용자 피드백을 모니터링하여 솔루션의 유효성을 검사합니다.

절충: 가능한 원인 식별, 가설 테스트 및 분석 문서화와 같은 근본 원인 분석 단계는 시간이 오래 걸릴 수 있습니다. 성능 문제를 상호 연결하려면 데이터를 수집하고 저장해야 합니다. 필요한 시간과 인프라는 운영 팀에 상당한 작업을 추가하고 워크로드에 비용을 추가할 수 있습니다.

위험: 적절한 보안 보호책 없이 근본 원인 분석을 수행하는 경우 로그 및 데이터에 대한 액세스를 제공할 때 중요한 정보를 노출할 위험이 있습니다.

공급업체 지원 참여

공급업체 지원은 지속적인 성능 문제를 해결할 때 필수적인 단계가 될 수 있습니다. 공급업체는 제품 문제를 해결하는 데 도움이 되는 전문 지식, 도구, 리소스 및 경험을 가지고 있습니다. 공급업체와의 지원 계약에 따라 공급업체가 제공하는 지원 수준이 결정됩니다.

공급업체와 병렬로 작업하는 것이 가장 좋은 경우가 많습니다. 일부 팀 구성원이 공급업체 지원과 공동 작업하도록 하는 계획을 만들어야 하며, 다른 팀 구성원은 성능 문제를 계속 심사하고 수정해야 합니다. 공급업체 지원 팀은 유사한 이벤트에 대한 응답을 방지하고 자동화하는 방법을 제안할 수도 있습니다.

담당자에게 연락처 정보를 사용할 수 있어야 합니다. 공급업체는 문제 해결에 효과적으로 참여하기 위해 데이터에 액세스해야 할 수도 있습니다. 모니터링 데이터에 액세스하려면 외부 또는 게스트 계정을 인증하고 권한을 부여하기 위한 계획이 있어야 합니다.

결과에서 알아보기

라이브 사이트 성능 문제를 해결한 후에는 발생한 작업을 검토해야 합니다. 목표는 문제를 식별하는 것뿐만 아니라 성능 문제에서 배우는 것입니다. 학습하는 가장 좋은 방법은 설명서를 통해서입니다. 각 문제를 문서화하고 해결 방법을 설명합니다. 공급업체가 도움을 준 경우 공급업체와 협력하여 설명서를 개선하고, 팀을 교육하고, 그에 따라 워크로드를 수정합니다.

설명서는 각 문제가 다시 발생하지 않도록 하는 방법을 나타내야 합니다. 반복되는 문제를 방지하는 한 가지 방법은 일반적인 문제에 대응하기 위해 자동화를 도입하는 것입니다. 자동화는 워크로드에 자체 복구 및 자기 방지 품질을 추가해야 합니다. 자동화와 함께 성능 문제 지표에 조기에 응답하는 데 도움이 되는 구체화된 경고를 만들 수 있습니다.

Azure 촉진

문제를 식별하고 resolve 방법 개발: Azure는 라이브 성능 문제에 대응하는 데 도움이 되는 몇 가지 도구를 제공합니다.

  • Azure Monitor는 애플리케이션 및 인프라의 성능 및 상태에 대한 인사이트를 제공하는 포괄적인 모니터링 솔루션입니다. 모니터링은 성능 문제를 모니터링하고 진단하는 데 도움이 되는 메트릭, 로그, 경고 및 대시보드와 같은 기능을 제공합니다.

  • Application Insights는 개발자와 DevOps 전문가가 라이브 애플리케이션을 모니터링하는 데 도움이 되는 APM(애플리케이션 성능 관리) 서비스입니다. 성능 변칙을 자동으로 검색하고, 애플리케이션 수준 로그 및 이벤트를 수집하며, 문제를 진단하는 분석 도구를 제공합니다.

  • Log Analytics는 애플리케이션, 가상 머신 및 Azure 리소스를 비롯한 다양한 원본에서 로그 데이터를 수집하고 분석하는 서비스입니다. Log Analytics를 사용하는 경우 로그 데이터를 쿼리하고 분석하여 애플리케이션의 성능 및 동작에 대한 인사이트를 얻을 수 있습니다.

성능 효율성 검사 목록

전체 권장 사항 집합을 참조하세요.