Vantiq 애플리케이션의 오류 및 확장성 문제 진단
폴 버터워스
2019 년 5 월 26 일
수정 : 0.30
개요
오류 및 성능 문제 발견 및 수정
복잡한 고성능 시스템을 개발하는 동안 항상 중요한 것은
도전적인 문제. 조사하고 분석하는 데 사용할 수 있는 전략 및 기술
이러한 문제를 해결하려면 이 문서에 나와 있습니다.
이 문서는 최근에 발생한 문제를 토대로 작성되었습니다.
두 개의 서로 다른 VANTIQ 시스템을 개발하는 동안. 응용 프로그램 중 하나
재현할 수 없는 것으로 보이는 시스템 전체에 오류가 발생했습니다. 두번째
애플리케이션은 완고한 확장성 문제를 보였습니다. 이러한 응용 프로그램은
본 문서에서는 예시로 사용됩니다.
예제 응용 프로그램
이벤트 브로커 애플리케이션
고급 이벤트 브로커인 Pronto의 이 애플리케이션은
ERP 시스템의 이벤트를 게시된 이벤트로 받아들입니다. 이벤트에 요청이 포함되어 있습니다.
특정 서비스 실행을 위해 다양한 서비스 이용 가능
특정 서비스를 식별하는 데 사용되는 별도의 이벤트(주제)
요청했습니다. 서비스는 이벤트를 전송하여 호출됩니다. 서비스가 응답합니다.
완료 이벤트로 완료 이벤트와 관련된 페이로드는 다음과 같습니다.
이후에 지원되는 REST 작업을 호출하여 ERP 시스템으로 반환됩니다.
ERP 시스템을 통해
Pronto 애플리케이션의 전반적인 제어 흐름은 다음과 같습니다.
다음 다이어그램에 설명되어 있습니다.
엘리베이터 관리
이 애플리케이션은 첫 번째 릴리스에서 최대
엘리베이터 250,000개. 각 엘리베이터는 XNUMX초에 한 번씩 상태를 보고합니다.
HTTPS를 통해 VANTIQ REST 인터페이스를 사용하는 주제.
애플리케이션은 엘리베이터 상태를 포함하는 테이블을 표시합니다.
선택된 엘리베이터 하위 집합에 대해. 사용자는 드릴다운하여 다음을 볼 수 있습니다.
특정 엘리베이터의 상세 상태. 특정 엘리베이터를 선택하면,
사용자는 세부 상태에 대한 실시간(XNUMX초에 한 번) 업데이트를 볼 수 있습니다.
선택한 엘리베이터. 사용자는 드릴다운하여 비디오를 보도록 선택할 수 있습니다.
원한다면 엘리베이터를 이용하세요.
응용 프로그램은 또한 한 번에 여러 통계를 계산합니다.
분 간격. 통계에는 엘리베이터가 온라인 상태였던 시간,
위아래로 움직이는 횟수와 지속 시간, 평균 온도,
다른 사람. 이러한 분당 통계는 추가로 집계되어 시간별,
각 엘리베이터에 대한 일일, 주간, 월간 및 연간 통계입니다. 골재
보고 목적의 통계는 XNUMX년간 보관됩니다.
엘리베이터의 상태는 관찰에 의해 결정됩니다
엘리베이터가 매초마다 상태 보고서를 생성하는지 여부. 엘리베이터는
XNUMX분 이상의 간격 동안 상태 보고서를 생성하지 않습니다.
오프라인. 이후에 엘리베이터가 유효한 상태 보고서를 게시하면 엘리베이터는
온라인 상태로 돌아갑니다.
진단 전략
다양한 진단 및 디버깅이 있습니다.
전략. 이 문서는 매우 구체적인 세트를 제시하는 매우 독선적입니다.
저자가 가장 효과적이라고 믿는 진단 전략은 다음과 같습니다.
복잡한 시스템의 문제를 진단해 온 오랜 역사.
일반적으로 문제는 시스템 수준에서 드러납니다.
문제 :
·
응용 프로그램이 작동 중임을 나타내는 시스템 오류가 발생하고 있습니다.
올바르게 작동하지 않습니다.
·
일부 예상 처리가 발생하지 않습니다. 문제가 나타날 수 있습니다
일관된 증상이 나타나면 예상되는 처리가 전혀 발생하지 않거나 다음과 같은 현상이 나타날 수 있습니다.
임의의 증상처럼 보입니다. 때로는 예상된 처리가 발생하지 않습니다. ~ 안에
이벤트 중심 시스템에서는 문제가 "메시지는 다음과 같습니다"로 보고될 가능성이 높습니다.
길을 잃다".
·
시스템은 지정된 로드를 지원하도록 확장되지 않습니다.
·
요청 지연 시간이 너무 깁니다.
전반적인 진단 전략은 개념적으로 간단합니다.
·
시스템의 간단한 모델을 구축합니다.
·
시스템 실행
·
오류 로그 검사
·
오류 로그에서 시스템 오류를 수정하세요.
·
시스템에 알려진 워크로드 적용
·
리소스 소진 오류 수정
·
허용되지 않는 응답 시간 문제를 수정하세요.
전반적인 진단 전략의 단계는 항상
이 순서대로 실행됩니다. 그 이유는 진단할 수 없다는 것입니다.
시스템이 올바르게 작동하지 않는 경우 성능 문제. 마찬가지로 당신도
시스템이 소진된 경우 허용할 수 없는 응답 시간을 진단할 수 없습니다.
사용 가능한 리소스.
진단 전략은 진단 모드에 크게 의존합니다.
시스템의 어떤 구성 요소를 결정하기 위한 기본 오류 격리 기술로 시스템을 사용합니다.
시스템은 고려 중인 문제를 담당하고 드릴링을 수행합니다.
이러한 진단 기술을 재귀적으로 적용하여 해당 구성 요소에까지
문제가 해결되고 시정 조치가 취해질 때까지.
모델
시스템 문제를 진단하는 핵심은 간단한 방법을 아는 것입니다.
주요 구성 요소 측면에서 애플리케이션이 작동하는 방식과 데이터가 어떻게 작동하는지에 대한 모델
구성 요소에서 구성 요소로 흐릅니다.
이 모델은 다음과 같은 방식으로 제작된 모델이 아닙니다.
App Modeler, App Builder 또는 Collaboration Builder. 그 모델들이 중점을 두고 있는 것은
요구 사항 및 응용 프로그램 의미에 대해 설명합니다. 확장성이나 확장성에 중점을 두지 않습니다.
성과에 큰 영향을 미치는 리소스를 명확하게 식별합니까?
및 확장 성.
결함 진단을 위해서는 모델이 단순해야 합니다. 일반 규칙
경험상 모델을 약 6개 구성 요소 이하로 유지하는 것이 좋습니다. 더 많은 모델
구성 요소는 쉽게 추론하기에는 너무 복잡해집니다. 게다가,
구성 요소가 작을수록 문제가 여러 개에 걸쳐 발생할 확률이 높아집니다.
결함 격리 문제를 더욱 복잡하게 만드는 구성 요소.
이벤트 브로커 애플리케이션에 대한 설명(위)
애플리케이션의 기본 흐름을 묘사하는 비공식 모델이 포함되었습니다. 그것
시퀀스 다이어그램을 사용하여 보다 공식적인 모델을 구축하는 것도 가능합니다.
애플리케이션의 주요 구성요소에 대한 실행 흐름을 보여줍니다. 만약 너라면
시퀀스 다이어그램으로 형식화하기로 결정하고 유일한 리소스가
다이어그램에 표시된 것은 확장성에 큰 영향을 미치는 항목입니다.
더 많은 세부정보를 추가하면 문제가 발생할 때 혼란을 야기할 뿐입니다.
확장성 문제를 진단합니다. 이벤트 브로커의 샘플 시퀀스 다이어그램
신청서는 아래와 같습니다:
확장성 진단을 위해 모델은 다음을 중심으로 구성됩니다.
확장이 필요한 주요 사용 사례. 이 컨텍스트 내에서 모델은 다음과 같아야 합니다.
트래픽이 많은 각 사용 사례에 맞게 구성되었습니다. 모든 사용 사례에 대한 모델은 다음과 같아야 합니다.
인바운드 및 아웃바운드 이벤트를 모델링할 정도로 단순화됩니다.
사용 사례를 지원하기 위해 수행되는 데이터베이스 활동입니다. 추가 세부정보는 다음과 같습니다.
이 시점에서는 불필요합니다. 확장성 모델을 다이어그램으로 작성하기로 선택한 경우
다이어그램에 모든 리소스 소비 활동을 포함하는 데 필수적입니다.
·
인바운드 이벤트
·
아웃바운드 이벤트
·
데이터베이스 작업
·
SOURCE를 통한 외부 시스템 호출
시스템 실행
모델을 손에 쥐고 있으면 이제 시스템을 시험해 볼 시간입니다. 만약에
아직 시스템 지침을 개발하는 과정에 있습니다.
운동 시스템이 구성되어 있습니다.
먼저 시스템을 통해 단일 요청을 실행하여
행동. 시스템이 지원해야 하는 각 주요 사용 사례에 대해 요청을 실행합니다. 만약에
오류가 발생하면 오류가 수정될 때까지 테스트를 확대하지 마십시오.
손상된 애플리케이션을 더 큰 규모로 실행하려는 시도는 완전한 낭비입니다.
시간.
단일 요청 실행이 견고하고 오류가 없으면
이제 더 복잡한 워크로드로 넘어갈 시간입니다. 프로세스의 다음 단계
일련의 요청인 워크로드를 적용하는 것입니다. 이는 다음을 확인합니다.
시스템에는 한 번만 작동하고 이후에는 작동하지 않는 동작이 없습니다.
요청. 일반적으로 이러한 문제는 일부 상태가 저장되어 있기 때문에 발생합니다.
데이터베이스가 완전히 이해되지 않아 일관성이 없는 상태로 남아 있습니다.
다음 요청에서 오류를 일으키는 상태입니다. 이 수준의 문제는 다음과 같습니다.
또한 외부 시스템의 동작이 그렇지 않은 원인으로 인해 발생할 수도 있습니다.
잘 이해되었으며 VANTIQ에서 외부 시스템으로의 요청이
일련의 요청을 처리할 수 있도록 적절하게 구성되었습니다.
이 시점에서 대기 시간을 먼저 살펴볼 수도 있습니다.
일련의 요청을 실행하는 데 걸리는 시간을 수집하고
각 개별 요청의 평균 응답 시간. 우리가 얻은 숫자는
응답 시간은 우리의 기준으로 삼을 것입니다. 왜냐하면 우리가
시스템에 더 큰 부하를 가합니다.
간단한 실행을 완료하고 수정을 마치면
오류가 감지되면 더 큰 동시 작업 부하로 전환해야 합니다. 하다
시스템에서 오류가 계속 발생하거나
지연 시간은 이미 허용되지 않습니다. 더 큰 부하가 증가하지 않습니다
시스템이 이미 나타내고 있는 문제를 진단하는 능력. 참조
아래 섹션: 알려진 워크로드 적용, 로드 방법에 대한 제안사항
응용 프로그램을 테스트하십시오.
오류 로그 검사
아무리 강조해도 지나치지 않은 한 가지는 시스템이
오류가 발생하고 시스템이 올바르게 작동하지 않으며
나중에 처리할 수 있다고 생각하는 오류는 결코 작동하지 않습니다.
오류가 예상되지만 모두 예상되는 경우가 있습니다.
오류는 애플리케이션에서 처리해야 합니다. 처리되지 않은 오류는 다음과 같습니다.
결함으로 간주되어 수정되어야 합니다.
오류 수정
여기서는 할 말이 많지 않습니다. 오류를 수정해야 합니다.
또는 시스템에 의해 처리됩니다. 예외는 없습니다. 일반적으로 오류가 발생함
시스템 내부 문제는 적절한 변경으로 수정될 수 있습니다.
시스템의 코드. 외부와의 통신으로 인해 발생하는 오류
시스템은 제거할 수 있다는 의미에서 수정이 불가능할 수도 있습니다. 이러한 오류
시스템에서 수용해야 합니다. 예를 들어 SOURCE를 통해 요청을 보내는 경우
네트워크가 다운되거나 네트워크가 다운될 가능성이 항상 있기 때문에 실패할 수 있습니다.
소스에 연결된 외부 시스템이 다운되었거나 자격 증명이 만료되었습니다.
등. 그러한 경우 시스템은 일부 문제를 처리할 수 있어야 합니다.
우아한 패션. 오류를 처리하는 코드를 개발하여 포함해야 합니다.
필요한 복구 절차를 문서화하는 것과 함께.
알려진 워크로드 적용
이 시점에서 점차적으로 부하를 늘리기 시작합니다. ~ 안에
이전 테스트에서는 순차적인 요청 스트림을 실행했습니다. 그러나 우리는
우리가 처리할 필요가 없도록 통제된 방식으로 부하를 적용합니다.
적용되는 부하와 시스템 동작 모두에 대해 알 수 없습니다. 우리는 바란다
테스트 중인 시스템의 동작에서 알 수 없는 사항만 처리합니다.
제어된 로드를 제공하는 가장 간단한 방법은 테스트를 사용하는 것입니다.
발전기. 그러나 테스트 생성기를 잘 이해해야 하며 로드는
그들이 생성하는 것은 잘 이해되어야 합니다. 이것은 말하기는 쉽지만 달성하기는 어렵습니다.
확장성 문제를 처음 접하는 개발자가 저지르는 첫 번째 실수는
확장되지 않거나 적용되지 않는 테스트 생성기의 구성
예상 부하. 예를 들어, 10을 제출하는 애플리케이션을 빌드하는 경우
요청/초이고 실제로는 1,000개 요청/초의 로드가 필요합니다.
100개의 애플리케이션 복사본을 실행한다고 상상해 보세요. 말이 되지만 질문이 있습니다.
다음과 같은 질문을 제기하고 답변해야 합니다.
·
100개의 생성기 복사본이 모두 단일 시스템에서 실행되고 있습니까?
·
생산된 빵의 원인이 되는 어떤 갈등을 볼 수 있습니까?
요청이 초당 1,000개 미만인가요?
·
컴퓨팅 성능이 충분하지 않습니까?
·
메모리가 부족합니까?
·
로드가 균일하지 않게 되는 일정 문제
배포?
·
사용 가능 여부를 제한할 수 있는 I/O 문제 또는 로컬 네트워킹 문제
처리량?
테스트 생성기를 구축하는 것이 너무 복잡하다고 판단되면
Gatling과 같은 기존 테스트 생성 기술에 매력을 느낄 수도 있습니다.
(VANTIQ 엔지니어링에서는 일부 테스트에 사용함) 하지만 지금은 미리 주의하세요.
Gatling의 동적 동작과 인프라를 이해해야 합니다.
당신이 그것을 실행합니다. 위의 모든 질문에 여전히 답해야 하지만 지금은
테스트 인프라의 맥락. 이러한 기술의 이점은 다음과 같습니다.
일단 당신이 그것들을 이해하는 데 투자했다면, 그 knxhaustion 오류는
적용된 워크로드가 증가하면 리소스가 발생할 수 있습니다.
피로 오류. 이러한 오류는 논의된 오류와 약간 다릅니다.
이전에는 애플리케이션의 논리적 오류를 나타내지 않았습니다.
오히려 애플리케이션이 애플리케이션보다 더 많은 리소스를 사용하고 있다는 사실을 나타냅니다.
할당되었습니다.
분명히 이에 대한 두 가지 가능한 수정 사항이 있습니다.
문제:
1. 할당
더 많은 자원
2.
적은 자원
선택된 접근법은 다음을 고려할 때 매우 중요합니다.
당신이 어떻게 생각하든 리소스는 시스템의 장기적인 상태이기 때문입니다.
한정된. 더 많은 리소스를 사용할 수 없기 때문에 유한합니다.
또는 더 많은 리소스로 인해 시스템 운영 비용이 예산을 초과하게 됩니다.
이러한 고려 사항은 증가가 가능한지 여부에 영향을 미칩니다.
자원.
시스템을 더욱 효율적으로 만들기(일명 더 적은 리소스 사용)
일반적으로 시스템 운영에 드는 예상 비용이 초과되는 경우 필요합니다.
예산이 부족하거나 애플리케이션이 사용 가능한 용량의 엄격한 제한에 부딪히게 됩니다.
자원.
자세한 내용은 다음 장에서 설명합니다. 확장성 진단
문제.
올바른 지연 문제
시스템이 워크로드를 지원할 수 있게 되면
리소스를 소진하지 않고 다음 작업은 대기 시간을 확인하는 것입니다.
허용됩니다. 시스템이 리소스를 고갈시키고 있지는 않지만 너무 많은 리소스를 사용하고 있습니다.
지연 시간이 너무 긴 리소스. 응용 프로그램이 응답하는 경우
10초 안에 응답해야 하는데 할 일이 너무 많습니다.
자세한 내용은 다음 장에서 설명합니다. 진단
확장성 문제.
제품 개요
이 장에서는 일반 사항에 대한 개요를 제시했습니다.
시스템 오류 및 확장성 오류에 대해 권장되는 진단 프로세스입니다.
시스템 오류에 대한 자세한 진단 전략은 다음에서 논의됩니다.
다음 장에서는 다음과 같은 세부적인 진단 전략을 논의합니다.
확장성 문제.
시스템 오류 진단
복잡한 애플리케이션에서 가장 먼저 발생하는 진단 문제는
시스템 오류를 처리해야 합니다. 시스템 오류는 오류 로그에서 발견됩니다.
로그에서 오류를 발견하면 애플리케이션이 작동하지 않을 가능성이 높습니다.
바르게. 특히 오류가 표시되고 해당 오류가 표시되지 않는 경우
응용 프로그램에서 처리하는 동안 응용 프로그램이 올바르게 작동하지 않습니다. 그것
당신이 이것들을 만족스러운 방식으로 설명할 수 없을 것 같으며 그들은 그렇게 할 것입니다.
문제를 해결할 때까지 모든 진단 활동을 계속 괴롭히십시오!
예상되고 적절하게 처리된 오류의 예
VANTIQ이 모든 사람의 건강을 모니터링하는 데 사용하는 응용 프로그램을 통해 설명됩니다.
VANTIQ 클라우드. 모니터 애플리케이션은 각 서버로부터 이벤트를 수신할 것으로 예상합니다.
몇 초마다 VANTIQ 클라우드. 모니터 응용 프로그램이 수신되지 않는 경우
60초 이내에 클라우드에서 이벤트가 발생하면 오류가 발생합니다. 구체적으로 규칙은
이벤트 대기 시간이 초과되었습니다. 모니터 애플리케이션은 결과를 포착합니다.
예외가 발생하고 시스템을 오프라인으로 표시합니다. 시스템 오류가 일부로 예상됩니다.
응용 프로그램의 정상적인 작동 및 내에서 적절하게 처리됩니다.
응용 프로그램.
적절하게 처리된 시스템 오류의 또 다른 예
REST 서비스가 실행 중이기 때문에 시간 초과될 수 있는 REST 서비스에 대한 요청입니다.
호출이 느리거나 신뢰할 수 없습니다. 이러한 실패를 처리하는 올바른 방법은 다음과 같습니다.
·
일시적인 오류일 수 있으므로 요청을 다시 시도하세요.
·
재시도할 때 지수 백오프 방식을 사용하는 것이 가장 좋습니다.
앞으로 수행될 REST 서비스에서 시도되는 재시도 횟수를 줄입니다.
더 오랜 기간 동안 오프라인 상태로 유지됩니다.
·
애플리케이션에 응답이 필요한 경우 오류를
시스템 오류를 사용자 오류로 바꾸고 사용자에게 해결 방법에 대한 지침을 제공합니다.
발하다.
오류가 포착되지 않고 애플리케이션이 단순히
매번 작동할 것으로 예상하면 응용 프로그램이 올바르게 실행되지 않습니다.
이는 다음의 좋은 예입니다.
분산 시스템에서 나타나는 본질적인 행동. 신청하는 경우
네트워크를 통해 다른 애플리케이션이나 서비스와 통신하는 경우
원격 애플리케이션이나 서비스에 대한 요청이 있는 시간임을 보장합니다.
실패할 것이다. 이것은 이론적인 것이 아니며 실패할 것입니다. 신청서의 경우
신뢰성을 유지하려면 원격 요청으로 인해 발생하는 모든 오류를 포착해야 하며
처리. 이 요구 사항에서 벗어나려고 정교하게 노력하지 마십시오. 거기 있을 것이다
결국 실패할 수 있으므로 이에 대비해야 합니다.
실제 고장 진단 사례를 살펴보겠습니다.
이벤트 브로커 예시.
이 문제는 원래 100개의 메시지가 있을 때 감지되었습니다.
ERP 시스템을 통해 플랫폼에 제공됩니다. 불행하게도 그 중 90개만이
메시지가 성공적으로 결과를 생성했습니다. 이 문제는 다음과 같이 보고되었습니다. “Pronto는
메시지를 잃어버림”. 물론 “Pronto is loss message”는 외부적으로 보고합니다.
관찰된 행동이지만 실제 문제에 대한 통찰력을 제공하지는 않습니다.
메시지가 손실되는 원인입니다. 이 클래스의 문제 보고서에는
일부는 작동하고 다른 일부는 작동하지 않는 결과가 무작위로 나타납니다.
전통적으로 진단하기가 매우 어려운 문제 유형입니다.
항상 실패하는 이벤트의 예는 없습니다.
이 문제는 시스템 모델을 생성하여 진단되었습니다.
세 가지 최상위 구성 요소로 구성되었습니다.
·
SAP의 요청 수락
·
대상 서비스에 요청 전달
·
SAP에 응답을 보내는 중입니다.
취한 진단 접근법은 먼저 다음을 분리하는 것이었습니다.
각 구성 요소를 분리된 상태로 테스트하여 주요 구성 요소 중 하나에 문제가 있는지 확인합니다.
가능한 한 환경.
1. Test
ERP 시스템에서 이벤트 브로커로 메시지를 게시합니다. 메시지 없음
응용 프로그램의 이 부분만 실행할 때 손실되었습니다.
2. Test
서비스에 메시지 전달 및 응답 게시
이벤트 브로커에게. 모든 메시지가 전달되었으며 모든 응답이 완료되었습니다.
발표했다.
3. Test
ERP 시스템에 응답을 전달합니다. 모든 응답이 그런 것은 아니었습니다.
ERP 시스템에 대한 일부 REST 요청에 시간이 걸리는 것으로 확인된 대로 전달되었습니다.
아웃.
이 시점에서 문제는 단일 구성 요소로 격리됩니다.
이 시점에서 개발자의 임무는 특정 항목을 드릴다운하고 결정하는 것입니다.
실패를 일으키는 조건입니다. 에는 여러 가지 요소가 있습니다.
확인될 수 있는 요청:
·
응답이 너무 커서 ERP 시스템이
합리적인 시간 내에 처리할 수 없나요?
·
시간 초과 값이 너무 작은 값으로 설정되어 있습니까?
·
VANTIQ REMOTE 서비스에 문제가 있나요?
ERP 시스템과의 상호작용?
·
REST 요청의 형식이 잘못되었나요? 일반적으로 이는 일부를 의미합니다.
헤더 또는 콘텐츠 유형이 잘못 설정되었거나 전혀 설정되지 않았습니다.
이러한 잠재적인 문제 중 다수는 다음을 통해 확인할 수 있습니다.
ERP 시스템에 대한 대체 인터페이스를 구축합니다. 예를 들어 CURL을 사용하여
동일한 데이터로 동일한 요청을 ERP 시스템에 제출합니다. 대체
인터페이스가 작동하면 REST 서비스 요청을 확인하여 확인할 수 있습니다.
성공적인 요청을 반영합니다. 기타 문제는 검사 또는 다음을 통해 확인할 수 있습니다.
일련의 테스트 케이스를 실행합니다. 예를 들어 다양한 메시지 크기를 적용하는 경우
메시지 크기에 대해 문서화되지 않은 제한이 있는지 확인합니다.
ERP 시스템 예시에서는 상세한
분석 결과 요청 자체에는 아무런 문제가 없었습니다.
VANTIQ 원격 서비스. ERP 시스템은 단순히 요청을 빠르게 처리하지 못했습니다.
충분하거나 완전히 무시합니다. ERP인지 여부를 판단하는 것은 불가능했습니다.
문제를 진단하기 위해 ERP 시스템에 접속했기 때문에 시스템에 문제가 있었습니다.
사용할 수 없었습니다.
실패한 REST 요청을 포착하여 문제가 해결되었습니다.
ERP 시스템을 다시 시도해보세요. 실패가 무작위로 발생했기 때문에 다시 시도하세요.
일반적으로 성공할 것입니다.
이전에 우리는 필요성에 대해 논의했습니다.
오류 로그를 검사하고 처리되지 않은 시스템 오류를 제거합니다.
응용 프로그램에 의해. 이 예에서는 로그에 시간 초과 오류가 포함되어 있습니다.
출처에서보고했습니다. 진단 프로세스 초기에 오류 로그 검사
문제를 직접 지적하고 개발팀이 다음을 수행하도록 허용했을 수도 있습니다.
문제를 보다 신속하게 격리할 수 있습니다. 물론 로그는 일반적으로 시끄럽습니다.
왜냐하면 여기에는 많은 로그 항목과 개별 로그의 중요성이 포함될 수 있기 때문입니다.
로그에 내재된 잡음으로 인해 항목이 손실될 수 있습니다. 그러한 경우,
위에 제시된 진단 기술은 일반적으로 문제를 해결합니다.
이 장과 관련된 주요 교훈은 대부분의 경우
잘못된 시스템 수준 동작의 경우 일반적으로 문제로 격리될 수 있습니다.
응용 프로그램의 특정 구성 요소. 그러나 이는 볼 때 명확하지 않습니다.
무작위처럼 보이는 애플리케이션의 외부 동작
실패. 비결은 애플리케이션을 몇 개의 거친 입자로 나누는 것입니다.
각 구성 요소를 차례로 테스트하여 올바르게 작동하는지 확인합니다.
문제가 있는 테스트에 구성 요소가 추가되면 이제
드릴다운하여 해당 구성 요소 내부의 문제가 무엇인지 정확히 파악하고 수정하세요.
그것.
확장성 문제 진단
확장성 문제는 모든 응용 프로그램에서 나타날 수 있지만
경험상 초당 100개 미만의 이벤트를 처리하는 애플리케이션
일반적으로 확장성 문제가 없습니다. 100개 이상의 애플리케이션을 처리 중
이벤트/초 또는 100개/초 이상의 이벤트로 증가할 것으로 예상됩니다.
확장성 문제를 보여줍니다. 처리량과 대기 시간이 반드시 중요합니다
문제.
확장성 문제는 일반적으로 다음과 같은 경우에 관찰됩니다.
애플리케이션은 더 많은 워크로드가 적용된 상태로 실행됩니다. 첫 번째 징후
애플리케이션에 확장성 문제가 있는 경우 다음 중 하나가 표시됩니다.
다음과 같은 행동:
·
응답 시간이 상당히 길어지고 있습니다.
·
할당량을 초과하고 있습니다.
·
시스템 오류가 생성되고 있습니다(할당량 문제 제외).
·
무작위 오류가 발생합니다.
전체적으로 관찰된 행동이 문제를 만든다
압도적으로 보입니다. 로그에는 수천 개의 오류와 응답 시간이 포함될 수 있습니다.
허용 가능한 수준에서 다음과 같은 지점까지 빠르게 증가합니다.
애플리케이션이 요청을 처리하지도 않습니다. 그러나 일부 기본 시스템 수준
생각은 문제를 해결하는 데 도움이 될 수 있습니다.
성과 모델 구축
응용 프로그램이 있는지 여부를 확인하려면
제대로 수행하는 데 필수적인 첫 번째 단계는 다음과 같은 모델을 개발하는 것입니다.
트랜잭션별로 사용하는 리소스를 추정하는 애플리케이션
애플리케이션을 전체 규모로 실행하는 데 필요한 총 리소스입니다. 건물
그러한 모델은 중요한 연습이다. 그런 모델을 만들 수 없다면,
당신은 당신의 응용 프로그램이 어떻게 작동하는지 모르고 있으며
리소스에 대해 추론할 수 없기 때문에 성능 문제가 발생합니다.
애플리케이션에 제공되는 모든 이벤트를 처리하는 데 필요합니다.
애플리케이션에 대한 성능 모델을 구축하는 쉬운 방법:
·
애플리케이션의 주요 사용 사례를 식별합니다. 주요 사용 사례는 다음과 같습니다.
정기적으로 실행되는 모든 것. 가장 관심을 끄는 것은 적용되는 사용 사례입니다.
모든 인바운드 이벤트 또는 최소한 다수의 인바운드 이벤트에 적용됩니다. 사용
가끔씩만 실행되는 사례는 더 깊은 분석을 위해 저장할 수 있습니다.
필수).
·
각 사용 사례에 대해
o
인바운드 이벤트를 계산합니다.
o
각 사용 사례에 대한 처리 흐름을 추적하여
사용 사례를 대신하여 실행되는 데이터베이스 활동입니다. 이것을 계산해 보세요
유형 :
§
선택 - 행 XNUMX개
§
선택 – 많은 행
§
끼워 넣다
§
업데이트
§
업서트
§
.
o
각 사용 사례에 대한 처리 흐름을 추적하여 식별
기계 학습 모델 호출 또는 외부 시스템 호출. 이것들은
두 가지 비용이 많이 드는 작업은 모두에 상당한 영향을 미칠 것입니다.
애플리케이션의 확장성.
o
아웃바운드 이벤트 계산
성능 모델을 사용하여 작업 부하 분석
모델링 연습이 완료되고 우리는
각 사용 사례를 실행하는 데 필요한 리소스가 있으면 워크로드 사양을 사용할 수 있습니다.
각 사용 사례의 빈도를 계산하고 전체 부하를 결정합니다.
애플리케이션에서 처리해야 합니다. 워크로드는 일반적으로 다음 문서에 문서화되어 있습니다.
초당 작업 수(일반적으로 기록됨 /비서). 확장성을 위해
분석에서는 평균 작업량과 최대 작업량 모두에 관심이 있습니다.
작업량. 최대 워크로드는 컴퓨팅 양을 결정하므로 중요합니다.
최대값을 충족하려면 애플리케이션에 전력(자원)을 할당해야 합니다.
자원에 대한 수요.
예를 들어 간단한 엘리베이터 모델을 만들어 보겠습니다.
애플리케이션. 참고로 이 애플리케이션은 최대 250,000개를 지원합니다.
각 엘리베이터는 XNUMX초에 한 번씩 상태를 보고합니다. 주요 용도
사례는 다음과 같습니다
1. 각각의
각 엘리베이터의 상태 보고서가 수집되고 기록됩니다.
2. A
클라이언트는 선택한 엘리베이터 세트에 대한 엘리베이터 상태 요약을 다음과 같이 표시합니다.
목록.
a. Client
엘리베이터를 선택하고 해당 엘리베이터의 실시간 상세 상태를 확인할 수 있습니다.
3. The
각 엘리베이터의 온라인/오프라인 상태 및 해당 엘리베이터가 유지된 시간
현재 상태는 각 엘리베이터가 적어도 하나의 엘리베이터를 생성하는지 확인하여 계산됩니다.
매분 이벤트. 분당 단일 이벤트가 게시되면 카운터가
엘리베이터가 해당 위치에 있음을 나타내는 데이터베이스에 증가하고 저장됩니다.
XNUMX분 동안 현재 상태입니다.
4. 엘리베이터
통계는 XNUMX분에 한 번씩 집계되어 저장됩니다. 구체적인 집계는 다음과 같습니다.
올라가는 시간, 내려가는 시간, 방문한 층 수, 평균 기온.
5. 고객사
시간별, 일별, 월별, 연간 엘리베이터 통계를 표시할 수 있습니다.
기초.
엘리베이터에 해당하는 성능 모델:
인바운드 이벤트: 250,000/초
사용 사례 1: 인바운드 저장
상태 보고서를 데이터베이스에 업로드하여 보고합니다. 이것은 우리에게 250,000을 제공합니다
모든 엘리베이터에 걸쳐 upsert/sec입니다.
사용 사례 2: 상태 표시 가정
각 클라이언트에 대해 10초마다 한 번씩 업데이트됩니다. 100개의 엘리베이터가 표시됩니다.
각 클라이언트. 200명의 고객이 있습니다. 균일한 분포를 가정하면 다음과 같습니다.
각 선택이 20개의 엘리베이터(객체)를 반환하는 경우 초당 100개의 선택이 수행됩니다.
사용 사례 3: 누락된 활동 사용
일정 기간 동안 상태 보고서를 보내지 않은 엘리베이터를 감지하는 패턴
분. 이 엘리베이터가 오프라인이라는 사실을 데이터베이스에 기록하세요. 한도 사용
온라인 상태인 엘리베이터를 결정하는 활동 패턴입니다. 분 표시에
유형을 업데이트하여 엘리베이터의 온라인 시간을 늘립니다.
엘리베이터의 현재 상태를 담고 있습니다. 결과는 4,167입니다.
업데이트/초 우리는 또한 통계를 간단히 읽어도 다음과 같은 결과가 나온다는 사실을 관찰할 필요가 있습니다.
우리는 초당 4,167개의 데이터베이스 작업을 수행하지만 실제로는 제한적인 활동이 진행되고 있습니다.
해당 시점에 모든 온라인 엘리베이터에 대해 이 처리를 예약하려면
간격에 도달했습니다. 따라서 전체 로드 시에는 다음만큼 대기열에 추가됩니다.
250,000개의 활동이 즉시 이루어지며 각 활동은 결국
데이터베이스 요청.
사용 사례 4: 인바운드 데이터 집계
VANTIQ 실시간 통계를 사용하여 매초마다. 또한 한도를 사용하십시오.
각 엘리베이터에 대해 분당 하나의 이벤트를 트리거하는 활동 패턴입니다. 때
한도는 이벤트를 트리거하고 마지막 순간의 통계를 로그에 기록합니다. 가정
균일한 분포를 사용하면 초당 4,167회의 Upsert가 발생합니다. 우리는 또한
통계를 간단히 읽으면 4,167개의 데이터베이스가 제공됩니다.
작업/초이지만 실제로는 제한된 활동이 이 작업을 예약합니다.
분 간격에 도달할 때 모든 온라인 엘리베이터에 대한 처리입니다.
따라서 전체 로드 시 최대 250,000개의 활동이 대기열에 추가됩니다.
즉각적으로 각각은 결국 데이터베이스 요청을 하게 됩니다.
사용 사례 5: 이는 집계된 것입니다.
지난 시간, 일, 주, 월, 연도에 대한 분당 쿼리
통계. 평균 쿼리가 한 달 간의 데이터에 대한 것이라고 가정해 보겠습니다.
집계해야 하는 레코드 수는 60 * 24 * 30.5개입니다. 이는 다음과 같이 작동합니다: 43,920
평균 쿼리당 기록입니다. 또한 평균적으로 그러한 사람은 단 한 명뿐이라고 가정합니다.
집계가 동시에 실행되고 있습니다.
이 신청서의 헤드라인은 다음과 같습니다.
·
이벤트: 250,000/초
·
Upsert: 258,334/초
·
쿼리: 11/초.
이 데이터를 사용하여 컴퓨팅 리소스를 추정할 수 있습니다.
이 워크로드를 지원하는 데 필요합니다.
·
250,000개 이벤트/초. 단일 vCPU가 1,000을 처리할 수 있다고 가정
vCPU 250개를 의미하는 이벤트/초입니다. 4개의 63vCPU를 제공하는 4개의 코어 머신을 가정합니다.
이벤트를 처리하는 기계.
·
초당 258,334 upserts는 DBMS를 가정하기 때문에 실행 가능하지 않습니다.
초당 20,000회 이하의 upsert를 수행할 수 있습니다. 이것은 엄격한 제한이므로
애플리케이션이 최대 작업량을 지원하지 않음을 나타냅니다. 협상은 없다
가능한. 앱은 다른 아키텍처를 사용해야 합니다.
·
초당 11개의 쿼리는 나머지 워크로드에 비해 작습니다.
그러므로 우리는 그것을 무시할 것입니다.
·
XNUMX분에 한 번 트리거되는 활동 제한 패턴은
실제로 생성된 이벤트를 분당 균일하게 배포하지 않습니다.
간격. 오히려 XNUMX분 타이머가 울리면 마지막까지의 모든 작업은
분이 예정되어 있습니다. 이는 최대 500,000개의 이벤트가 거의 게시됨을 의미합니다.
동시에. 시스템이 이벤트를 처리할 수 없기 때문에
즉시 작업이 대기열에 추가됩니다. 안타깝게도 시스템이 대기열에 추가되지 않습니다.
이 정도의 작업은 메모리를 심각하게 손상시키지 않고 수행됩니다. 피하기 위해
메모리 문제, 대기열의 크기가 제한되어 있으며 이를 대기열에 넣으려는 시도가 있습니다.
많은 작업을 수행하면 할당량 위반이 많이 발생합니다. 이것은 또 다른 것입니다
해결해야 할 이 애플리케이션의 확장성 문제입니다.
이 연습은 다음의 이점 중 하나를 보여주었습니다.
모델. 사용 사례를 정의하고 모델을 구축하는 데 XNUMX시간도 채 걸리지 않았습니다.
이는 신청 처리에 대해 상당히 정확한 설명을 제공하며,
상상한 대로 응용 프로그램이 지정된 항목을 지원하지 않을 것임을 분명히 했습니다.
작업량. 코드를 작성할 필요가 없습니다. 스트레스 테스트를 실행할 필요가 없습니다. 대신에,
한 시간 만에 우리는 더욱 확장 가능한 아키텍처를 개발해야 한다는 사실을 발견했습니다.
확장 가능한 애플리케이션 아키텍처 개발
이제 초기 애플리케이션을 시연했으므로
아키텍처는 확장 가능하지 않으므로 확장 가능한 아키텍처를 개발해야 합니다.
모델에 적용된 워크로드를 분석하여 식별된 문제를 해결합니다.
먼저 가장 문제가 되는 부분 중 하나를 다루겠습니다.
작업 부하 – 실시간 상태를 캡처하는 데 필요한 초당 250,000회의 Upsert
모든 엘리베이터의. 또한 상태는 유일한 목적으로 캡처됩니다.
최대 200명의 클라이언트에게 표시합니다. 우리는 그런 아키텍처를 찾을 수 있을까?
모든 상태를 저장하는 것보다 클라이언트 디스플레이를 채우는 것이 더 효율적입니다.
데이터베이스에 보고하나요?
다음에서 논의된 몇 가지 대체 접근 방식이 있습니다.
다음 하위 섹션.
상태를 클라이언트에 직접 스트리밍
한 가지 접근 방식은 상태를 직접 스트리밍하는 것입니다.
클라이언트에 대한 인바운드 이벤트. 가장 공격적인 버전의
아키텍처는 어떤 종류의 데이터베이스 작업도 수행하지 않습니다. 관찰하다
최대 200명의 클라이언트와 각 클라이언트는 실시간 상태를 표시할 수 있습니다.
언제든지 정확히 하나의 엘리베이터. 또한, 모든 엘리베이터 선택
클라이언트는 매우 빠르게 변하지 않습니다. 평균적으로 30분에 한 번씩 전화하자
분. 이는 평균적으로 하나의 엘리베이터 디스플레이를 변경하고 있음을 의미합니다.
9초마다 할당됩니다.
런타임 시 시스템은 상태를 모든 클라이언트로 라우팅해야 합니다.
상태 보고서가 처리 중인 엘리베이터를 표시하는 것입니다.
이를 수행하는 한 가지 방법은 각 고객이 자신이 알고 있는 고유한 주제를 듣게 하는 것입니다.
클라이언트가 현재 표시하고 있는 엘리베이터의 실시간 상태는
출판. 이 클라이언트 주제를 지정된 상태 이벤트에 바인딩하려면
엘리베이터의 상태 보고서를 감지하는 규칙을 동적으로 구성합니다.
특정 엘리베이터를 선택하고 고유한 클라이언트 주제에 대한 이벤트를 다시 게시합니다. 메모
이러한 규칙은 각 클라이언트가 선택하는 대로 즉석에서 구성되어야 합니다.
엘리베이터를 볼 수 있지만 우리가 말하는 속도로 동적으로 생성됩니다.
이러한 규칙은 그다지 부담이 되어서는 안 됩니다.
클라이언트를 바인딩하기 위한 규칙을 동적으로 생성하는 대안
엘리베이터는 도착하는 모든 엘리베이터 상태 이벤트를 고유한 위치에 다시 게시하는 것입니다.
각 엘리베이터의 주제 물론 이는 250,000개의 주제가 있다는 것을 의미하지만
주제의 수가 많은 것은 확장성 문제가 아닙니다. 클라이언트가 선택하면
실시간 상태를 표시하는 엘리베이터, 클라이언트가 주제를 구독합니다.
실시간 상태를 수신하기 위해 해당 엘리베이터에 해당합니다.
SELECTS를 사용하여 UPSERTS 수 줄이기
또 다른 대안은 upsert를 선택 항목으로 변환하는 것입니다.
이 경우 각 고객은 다음을 추가하여 엘리베이터에 대한 관심을 등록합니다.
유형에 반대합니다. 상태 보고가 들어오면 상태를 처리하는 규칙
보고서는 선택을 수행하여 데이터베이스를 참조하고 상태 보고서를 다음으로 보냅니다.
해당 엘리베이터를 관찰하고 있는 모든 클라이언트. 이것은 250,00을 변환합니다
초당 250,000개 선택으로 업데이트(클라이언트 관찰을 확인하기 위해).
선택은 아마도 upsert보다 10배 더 효율적이므로 훨씬 더 효율적입니다.
시스템이 upsert보다 선택 로드를 더 효율적으로 지원할 수 있을 가능성이 높습니다.
짐. 그러나 이 접근 방식은 여전히 너무 많은 것을 바치고 있는 것처럼 느껴집니다.
200명의 클라이언트에 상태를 표시할 수 있도록 하는 데 필요한 리소스입니다.
계속 저장하는 위 아키텍처의 변형
데이터베이스의 상태는 데이터베이스의 통계적 속성에 따라 달라집니다.
업서트를 다음으로 변환하여 작업 부하를 줄이는 엘리베이터 상태 보고서
더 적은 수의 upsert가 선택되고 이어집니다. 이 접근법의 통계적 특성
엘리베이터가 상태를 자주 보고하지만 실제 엘리베이터 상태에 따라 달라집니다.
변경되지 않아 많은 상태 보고서가 중복되는 경우가 많습니다.
엘리베이터는 대부분의 시간 동안 유휴 상태이므로 실제 상태는 다음과 같습니다.
변하지 않음. 이 의미 체계를 활용하여 시스템은 현재 상태를 검색합니다.
상태 보고서가 도착하면 각 엘리베이터의 기존 상태와
새 상태는 의미상 동일하므로 굳이 업데이트하지 마세요. 그냥 추측이에요
이 시점에서는 업데이트 수가 다음과 비슷할 것으로 생각됩니다.
이 접근 방식을 사용하면 5,000/초가 아닌 250,000/초가 됩니다. 그러나 우리는 여전히
초당 250,000개의 선택을 처리합니다. 같은 번호보다 관리가 더 편해요
upsert가 많이 발생했지만 이는 여전히 많은 수의 작업을 의미합니다.
애플리케이션의 운영 비용은 우리가 원하는 것보다 높을 것입니다.
클라이언트가 표시하는 엘리베이터에 대해서만 UPSERT 상태
다음으로 upsert rate를 감소시키는 방식을 살펴본다.
현재 보고 있는 엘리베이터에 대해서만 상태 보고서를 저장합니다. 이것은
클라이언트가 구독할 때 규칙을 동적으로 구성하여 수행됩니다.
엘리베이터 상태 업데이트. 규칙은 상태 업데이트가 다음에 대한 것인지 감지합니다.
엘리베이터가 전시되어 있습니다. 그렇다면 상태를 데이터베이스에 기록합니다. 따라서,
실제로 데이터베이스에 기록되는 유일한 상태는 엘리베이터에 대한 것입니다.
실시간 디스플레이에 바인딩되어 있습니다. 클라이언트가 다른 엘리베이터로 전환하면,
규칙이 제거됩니다.
샘플링 속도 줄이기
마지막 접근 방식은 단순히 속도를 줄이는 것입니다.
업데이트가 기록됩니다. 예를 들어, 매 XNUMX번째 상태만 저장하도록 선택한 경우
보고서에 따르면 upsert 속도는 약 25,000으로 한 단계 정도 감소했습니다.
upserts/second - 여전히 매우 크지만 가능할 수도 있는 속도입니다.
불행하게도 이것은 실용적일 수 있지만 별로 만족스럽지 않습니다.
애플리케이션의 요구 사항을 변경하는 데 필요하며 표시만 가능합니다.
XNUMX초마다 상태가 수집됩니다. 클라이언트의 실시간 디스플레이가 적습니다.
원래 지정된 것보다 실시간으로.
개발 중인 애플리케이션의 확장성 문제 진단
이전 섹션에 설명된 내용
모델 구축이 애플리케이션 평가에 있어 매우 효율적인 접근 방식인 이유
성능 관점에서 아키텍처. 그러나 이것이 항상 그런 것은 아니다
확장성 문제를 보이는 기존 애플리케이션이 있을 수 있습니다. 이에
섹션에서는 다음과 같은 애플리케이션의 문제를 진단하기 위한 전략을 논의합니다.
진단을 위해 개발 중이거나 개발 중에 있을 수 있음
확장성 문제. 변경하거나 배치할 수 없는 프로덕션 애플리케이션
개발은 아직 작성되지 않은 다른 문서에서 논의됩니다.
앞에서 설명한 것처럼 기존 VANTIQ 애플리케이션은
확장성 문제는 다음 동작 중 하나를 나타냅니다.
·
오류
·
응답 시간이 느려짐(또는 전혀 응답이 없음)
오류
가장 먼저 검사해야 할 것은 오류 로그입니다. 하려고
애플리케이션이 무엇을 하고 있는지, 어떻게 수행되고 있는지 파악하는 것은 낭비입니다.
지속적으로 오류가 발생하는 경우 시간입니다. 오류로 인해 유용한 정보가 가려집니다.
애플리케이션의 동적 동작에 대한 정보입니다.
고려해야 할 오류에는 두 가지 종류가 있습니다.
·
사용자 오류
·
애플리케이션 오류
사용자 오류는 예상되는 것이며 일반적으로 문제가 되지 않습니다.
사용자가 데이터를 입력하거나 구성할 때 실수를 해서 생성됩니다.
활동. 예를 들어, 시스템은 사용자에게 파일을 요청하고 사용자는 다음을 입력합니다.
파일 이름으로. 파일 이름이 유지될 시간의 합리적인 비율
잘못 입력하면 "파일을 찾을 수 없습니다" 오류가 생성됩니다. 일반적으로,
그러한 오류는 예상되고 처리되므로 걱정할 필요가 없습니다.
응용 프로그램.
대조적으로, 시스템 오류는 예상치 못한 것이며,
발생하면 응용 프로그램의 올바른 동작을 방해합니다. 일부 전형적인
오류에는 다음이 포함됩니다.
·
시간 초과. 시간이 초과되는 것은 문제가 될 가능성이 높습니다.
시간 초과는 다음 두 가지 이유로 발생합니다.
o
뭔가 작동하지 않습니다. 이는 일반적으로 IO 작업에 적용됩니다.
전형적인 예는 REST 서비스를 호출하고 요청 시간이 초과되기 전에 발생하는 것입니다.
완료됩니다. 네트워킹 문제일 수도 있고 원격 서비스의 문제일 수도 있습니다.
또는 너무 많은 작업을 요청하여 제때에 응답하지 못할 수도 있습니다.
이러한 문제는 네트워크가 열악하거나 과부하되어 발생할 수도 있습니다. 가장 나쁜
이러한 오류는 예측하기가 쉽지 않으며 개발자는
문제의 근본 원인을 찾기 위해 더 자세히 살펴보겠습니다.
o
너무 많은 작업이 진행되고 있습니다. VANTIQ에는 최대 한도가 있습니다.
프로시저의 런타임. 그 제한은 2분입니다. 시스템에 요청하면
XNUMX분 이상 걸리는 작업에는 오류가 발생합니다. 올바른
그러한 오류에 대한 대응은 작업을 더 작은 규모로 수행할 수 있도록 분할하는 것입니다.
덩어리.
·
일반 실행 오류. 넓은 이유에는 여러 가지가 있을 수 있습니다.
런타임 오류 범위:
o
누락된 리소스 - 존재하지 않는 프로시저를 호출합니다.
존재하지 않는 원격 프로시저를 호출합니다. 다음을 수행하는 유형 참조
존재하지 않습니다. VANTIQ에서는 존재하지 않는 원격 리소스일 수 있으므로 비용을 지불해야 합니다.
오류 메시지에 주의하세요.
o
VAIL 코드에 오류가 있습니다. 다음과 같은 일반적인 오류가 모두 발생할 수 있습니다.
누락된 변수, 잘못된 할당 등
o
누락된 이벤트. 앱이
아무도 듣지 않는 이벤트. 반대로 앱이 듣고 있을 수도 있지만
아무도 출판하지 않습니다. 이러한 불일치는 오타로 인해 발생하는 경우가 많습니다.
주제 이름. Pronto는 이러한 문제를 진단하는 데 도움을 줄 수 있습니다.
게시자와 구독자가 카탈로그에 나열되므로 쉽게 확인할 수 있습니다.
방정식의 절반이 누락되었습니다.
·
반환 값을 올바르게 처리하지 않습니다. 이것은 교활한
값이 반환되지만 예상한 값이 아니기 때문에 문제가 발생합니다.
값을 반환하는 방법에 대한 문서를 읽고 이해하는 것이 중요합니다.
비동기 실행 모델이 항상 일치하지 않기 때문에 생성됩니다.
반환 값이 어떻게 생성되는지에 대한 직관.
·
쿼리 결과를 스트리밍 방식으로 처리하지 않습니다. 당신이 그것을 만들면
일반적인 쿼리에서 문제가 발생할 수 있는 배열입니다.
·
사용자에게 충분한 권한이 없을 때 발생하는 인증 오류
무언가에 접근하세요.
·
특히 외부 시스템과 통신할 때 구성 오류가 발생합니다.
·
할당된 리소스에 대한 리소스 소진 및 할당량 위반
응용 프로그램에. 이는 응용 프로그램에 결함이 있음을 의미합니다.
사용 가능한 모든 리소스를 소비하거나 애플리케이션이 다른 애플리케이션보다 더 많은 작업을 수행하고 있습니다.
할당된 리소스는 허용됩니다. 할당량 및 리소스 오류는 주요 논의입니다.
아래 주제.
할당량 및 리소스 소비 오류
할당량 및 리소스 위반을 나타내는 오류
수정해야 합니다. 조직에는 특정 수량의 할당이 할당됩니다.
리소스이며 해당 한도를 초과할 수 없습니다. 한도는 할당량에 따라 설정됩니다.
제한에는 언제든지 활성화될 수 있는 규칙의 수가 포함됩니다.
실행 대기 중인 규칙 수, 프로시저 실행 시간
(항상 최대 2분으로 설정됨)
이벤트가 시스템에 표시될 수 있습니다. 할당량 초과 메시지 결과
애플리케이션의 일부가 종료된다는 것입니다. 그러므로,
응용 프로그램이 올바르게 실행될 수 없습니다!
위반이 앱의 버전이 만료되었기 때문인지 평가하세요.
너무 많은 리소스를 제어하고 사용하거나 할당량이 너무 낮습니다. 이런 종류의
일반적으로 분석에는 일종의 리소스 사용량 분석이 필요합니다.
이전처럼 현재 적용하고 있는 부하에 투영된 애플리케이션
모델링 섹션에서 논의되었습니다.
애플리케이션이 리소스를 다음과 같이 사용하고 있다고 판단되면
예상되며 지정된 예산 제약 내에서 자원을 사용하고 있습니다.
더 큰 할당량을 요청하면 이를 달성할 수 있습니다. 할당량을 나타내는 요청
should be는 항상 처리하기 가장 간단합니다. 정량적이지 않은 요청
요구 사항에 따라 할당량이 다음과 같이 반복되는 프로세스로 이어질 수 있습니다.
증가하면 앱이 다시 테스트되고 나머지 할당량 위반이 처리됩니다.
할당량을 다시 늘려서
할당량 늘리기는 다음과 같은 경우에만 작동합니다.
더 많은 리소스를 사용할 수 있습니다. 엘리베이터의 예에서 250,000
초기 애플리케이션 아키텍처에서는 초당 업데이트가 필요했습니다.
애플리케이션이 작동하도록 할당할 수 있는 할당량입니다. 응용 프로그램
단순히 제공할 수 있는 것보다 더 많은 자원을 요구하고 있는 것입니다. 할당량을 늘리면
이 문제를 해결하지 마십시오.
문제는 적절한 컴퓨팅 리소스가 충분하지 않다는 것입니다.
사용할 수 있는 경우 추가 컴퓨팅 리소스를 제공해야 합니다. 단순화된 용어로
이는 VANTIQ 서버 클러스터의 컴퓨팅 성능을 다음과 같이 향상시키는 것을 의미합니다.
추가 기계를 추가하거나 기존 기계의 크기를 늘립니다.
적절한 데이터베이스 리소스가 확보되지 않은 것이 문제인 경우
사용 가능한 경우, 이를 실행하는 서버의 크기를 늘릴 수도 있습니다.
DBMS. 그러나 DBMS 서버를 추가하여 용량을 늘릴 수는 없습니다.
따라서 데이터베이스 리소스의 양에는 상한선이 있습니다.
공급받다.
몇 가지 교활한 사례에는 대기열에 있는 애플리케이션이 포함됩니다.
짧은 시간에 많은 양의 작업을 수행합니다. LIMIT 활동 패턴은 다음과 같습니다.
제한이 있을 때 많은 양의 작업을 대기열에 넣을 수 있는 대표적인 예입니다.
간격이 만료됩니다. 한 번에 너무 많은 작업이 제공되면 할당량 진단이 수행됩니다.
할당량을 초과했으며 너무 많은 이벤트를 대기열에 추가했음을 나타냅니다. 할당량
어느 정도 높아질 수 있지만 대부분의 경우 애플리케이션을 다시 작업해야 합니다.
시스템에 요청을 원활하게 전달하려면 아키텍처가 필요합니다.
이와 관련된 현상은 거래량이 많다는 것입니다.
속도 애플리케이션은 부하가 상당히 일정하게 유지되는 경우에만 잘 작동합니다. 만약 너라면
초당 100,000개의 이벤트를 실행하고 주기적으로 로드를 200,000으로 늘립니다.
events/sec, 스파이크 부하가 발생한 후 시스템이 완전히 안정화되지 않을 수 있습니다.
제시. 이로 인해 대기 시간이 증가하고 리소스 사용량이 과도하게 늘어납니다. 을 위한
트랜잭션 속도가 높은 애플리케이션은 로드를 최대한 안정적으로 유지하려고 합니다.
지나치게 긴 지연 시간
시스템이 과부하되면 응답 시간이 저하됩니다.
기하급수적인 패션. 실제로 과부하된 시스템은 일반적으로 정지된 것처럼 보입니다.
물론 어떤 경우에는 오래 기다리면 응답을 받을 수도 있지만
일반 사용자라면 누구나 시스템이 중단되었다고 생각할 만큼 이는 끔찍한 승리입니다.
응답하지 않습니다.
긴 지연 시간에 대한 일반적인 대응은 다음을 계측하는 것입니다.
애플리케이션을 자세히 기록하려면 모든 계측을 기록하는 앱을 실행한 다음
기록된 결과를 검사하여 문제가 발생한 위치를 파악하십시오.
이 접근 방식을 사용하면 일반적으로 문제가 있음을 확인할 수 있지만 문제가 발생하는 경우는 거의 없습니다.
문제의 위치는 분명합니다. 과잉행동의 가장 극단적인 예
진단 출력은 실행 프로파일링입니다. 프로파일링은 많은 세부 정보를 제공합니다.
그러나 시스템 문제를 찾고 있다면 아마도 너무 자세한 내용일 것입니다. ㅏ
더 나은 접근 방식은 애플리케이션의 단순화된 모델로 돌아가서
경과 시간 계측을 통해 각 주요 구성 요소를 계측합니다. 그 다음에
응용 프로그램을 실행하고 어떤 구성 요소가 과도한 결과를 생성하는지 확인하십시오.
런타임 및 암시적으로 긴 대기 시간이 발생합니다. 구성 요소가 일단 만들어지면
식별된 경우 분해 접근 방식을 사용하여 애플리케이션을 추가로 계측합니다.
공격받을 수 있는 특정 문제를 식별할 때까지.
문제는 리소스를 과도하게 사용하는 것입니다.
VANTIQ 애플리케이션 또는 외부 시스템의 과부하
VANTIQ 애플리케이션과 통합되었습니다. 외부 통합은 핵심 영역입니다.
지나치게 긴 지연 시간이 발생하는 경우에 중점을 둡니다.
그라 파나
VANTIQ은 리소스 관찰을 위한 도구를 제공합니다.
VANTIQ 시스템 내 소비. 이 정보는 Grafana에서 확인할 수 있습니다.
VANTIQ IDE에서 대시보드를 사용할 수 있습니다.
Grafana 대시보드의 장점 중 하나는
애플리케이션 모델의 정확성을 확인하는 데 사용할 수 있습니다. 있다
사용 가능한 여러 대시보드:
·
규칙 실행
·
절차 실행
·
자원 사용
·
소스 활동
·
유형 저장
이벤트 중심 시스템의 경우 관찰해야 할 첫 번째 대시보드는 다음과 같습니다.
규칙 실행 대시보드. 규칙 실행은 집계 규칙을 표시합니다.
각 특정 규칙에 대한 실행 속도 및 실행 속도. 당신이 가지고 있다면
애플리케이션의 정확한 모델을 개발하고 알려진 로드를 적용하고 있습니다.
각 규칙 및 시스템 전체의 실행 속도는 귀하의 요구 사항과 일치해야 합니다.
모델. 요율이 일치하지 않으면 보다 정확한 결과를 개발하기 위해 해야 할 일이 있습니다.
모델!
먼저 모든 규칙이 실행되고 있는지 확인하세요. 구체적으로,
확인하다 떨어 뜨린 실패한 요금은 XNUMX입니다. 이 요금이라면
XNUMX이 아니면 규칙이 완료될 때까지 실행되지 않습니다. 이는 다음으로 인해 발생할 수 있습니다.
·
오류(실패한 규칙 실행)
·
귀하의 애플리케이션이 할당량을 초과했습니다(삭제됨).
·
동일한 조직에서 실행되는 다른 애플리케이션은 다음과 같습니다.
할당량을 초과
앞서 이 글에서 밝혔듯이
문서가 실패하는 경우 애플리케이션을 확장하려고 시도할 필요가 없습니다.
지금 이러한 오류를 처리하세요!
아래는 대시보드 스크린샷입니다.
두 개 이상의 할당량이 초과된 실행 간격을 표시합니다.
13:39 및 13:40에 오류가 발생했습니다.
오류가 거의 눈에 띄지 않음
단어로 인해 스크린샷의 해상도가 감소했기 때문입니다. 확대
위 화면 이미지에서 관련 영역을 보면 두 개의 작은 파란색 표시가 보입니다.
아래 이미지에서 13:40 이전과 XNUMX:XNUMX에. 파란색 표시는 초과된 할당량을 나타냅니다.
실행 실패.
오류도 기록되었습니다.
오류 로그에 있으며 아래에 중복되어 있습니다.
리소스 오류
ID가 '/rules/catchTimer'인 '감사'를 입력하세요. 감사 경고:
Vantiq 조직의 실행 크레딧이 소모되었습니다. 그 결과,
규칙 catchTimer가 제한되고 있습니다.
|
|
|||||||||||||||||
|
|
||||||||||||||||
이 시점에서는 쉬울 것이다.
이 오류를 무시하십시오. 우리 애플리케이션은 초당 XNUMX개의 이벤트만 실행하고 있으며
할당량을 초과할 수 없습니다. 그런 가정을 하는 것은 시간 낭비일 뿐입니다.
문제를 진단해야 합니다. 이 시점에서 우리는 코드를 검토하고 확신했습니다.
우리는 초당 두 개의 규칙을 실행할 것으로 예상합니다. 그런 다음 우리는
장기적으로 대시보드를 검토하고 초당 XNUMX개의 규칙을 실행하는 것으로 확인했습니다.
비율. 마지막으로 우리는 다음을 포함하는 조직에서 운영되고 있음을 관찰했습니다.
많은 추가 응용 프로그램이 있으며 이는 다음과 같은 응용 프로그램 중 하나입니다.
조직 할당량을 초과했습니다. 불행히도 그 결과는 다음과 같습니다.
우리의 애플리케이션이 실패에 빠졌습니다. 이것은 매우 중요한 교훈입니다.
배우다. 확장성과 리소스 사용량을 정확하게 측정하고 싶다면
다른 사용자가 없는 격리된 환경에서 실행해야 합니다.
자원 할당량을 공유하기 위해 귀하와 경쟁합니다.
이것이 VANTIQ의 주요 이유입니다.
SE 및 PS 팀이 구축 시 다음 규칙을 준수할 것을 권장합니다.
신청 :
·
데모 – 데모는 대규모로 실행되지 않으며 VANTIQ에서 실행할 수 있습니다.
다음과 같은 조직:
o
VantiqEval
o
반틱POC
·
PoC – 대규모로 실행되지 않습니다. 그들은 보여주기 위해 사용됩니다
높은 가치의 잠재 고객을 위한 기능(규모 아님). VANTIQ에서 PoC를 실행할 수 있습니다.
다음과 같은 조직:
o
VantiqEval
o
반틱POC
·
파일럿 – 파일럿은 다음을 위해 구축되는 애플리케이션입니다.
잠재 고객/고객이며 일반적으로 고객이 후원하고 비용을 지불합니다.
조종사는 일반적으로 확장성을 입증해야 하므로
파일럿 프로젝트를 전담하는 별도의 조직에서 개발되었습니다. 일부에서는
시점에 파일럿이 고객에게 넘겨질 수 있으며 이것이
고객의 개발 조직.
·
애플리케이션 – 애플리케이션은 고객용으로만 제작되었으며 유료입니다.
고객을 위해. 애플리케이션은 조직에서 개발 및 테스트되어야 합니다.
고객에게 헌신합니다.
이러한 규칙을 무시하고 애플리케이션을 확장하려고 하면
VANTIQ 네임스페이스는 실패할 뿐만 아니라 개발에도 피해를 줄 것입니다.
동료들의 노력.
규칙 실행 대시보드에는 실행 시간도 표시됩니다.
규칙을 위해. 디스플레이에는 p50(중앙값 실행 시간) 및 p99가 포함됩니다.
(99th 우리가 일반적으로 최악의 경우로 해석하는 백분위수
응답 시간). 이 값은 예상보다 큰 경우 중요합니다.
또는 당신이 견딜 수 있는 것보다 더 큰. 예를 들어 아래 대시보드 예는 다음과 같습니다.
p20 수준에서 50msec 미만, p250 수준에서 300-99msec 미만의 규칙 실행
수준. p99 번호는 다음을 나타냄에 따라 항상 변동성이 커집니다.
최악의 행동이며 처리 지연으로 인해 영향을 받습니다.
규칙. 예를 들어 가비지 수집은 큰 영향을 미칠 수 있습니다. 예를 들어
애플리케이션에서는 초당 하나의 이벤트를 수신하므로 문제가 되지 않습니다.
따라서 다음 이벤트가 발생하기 전에 각 규칙을 실행하는 데 1000밀리초가 필요합니다.
도착합니다. 그러나 실행 시간이 항상 1000msec를 초과하면
다음 이벤트가 도착하기 전에 규칙 실행이 완료되지 않는 문제. 이것
만성 질환인 경우, 작업이 완료되는 것보다 새로운 작업이 더 빨리 도착합니다.
시스템은 붕괴될 때까지 점점 더 많은 작업을 대기하게 됩니다.
위 이미지는 Grafana 규칙 실행 대시보드를 보여줍니다.
초당 2개의 규칙을 실행하는 애플리케이션 안정된 상태에서 아무 것도 없이
오류.
매우 가치 있는 또 다른 대시보드는 리소스입니다.
사용량 대시보드. 이 대시보드에는 선택, 삽입, 업데이트, 삭제 활동이 표시됩니다.
영구 저장소에 저장된 리소스(유형)에 대한 정보입니다.
경고: 당신은 쉽게 이끌릴 수 있습니다
"api" 설정에 주의를 기울이지 않으면 이 디스플레이를 잘못 볼 수 있습니다.
대시보드는 REST 인터페이스 또는 VAIL의 리소스 사용량을 표시합니다.
응용 프로그램. 다음과 같은 경우 규칙 활동(VAIL)을 보고 있다고 생각하기 쉽습니다.
실제로 REST API에서 발생한 활동을 표시하고 있습니다(또는 그 반대).
반대)
이 문서의 앞부분에서 살펴본 것처럼 데이터베이스 리소스는
VANTIQ 내 확장성의 궁극적인 한계를 나타냅니다. 다른 리소스는
증가하다. 애플리케이션이 초당 백만 개의 규칙을 더 실행해야 하는 경우
컴퓨팅 파워가 문제를 해결해 줄 것입니다. 그러나 데이터베이스에는 상한이 있습니다.
확장성에 대해. 이는 리소스 사용량 수치가 매우 중요하다는 것을 의미합니다.
특히 총 자원 처리량은 합리적인 범위 내에서 유지됩니다.
에 대해서도 소개했습니다.
우리의 경험 법칙은 싱글을 유지하는 것입니다
초당 20,000개 요청 미만의 객체 SELECT 활동 및 단일 객체 업데이트
5,000/초 이하
수술에 주의를 기울이는 것도 중요합니다
과도한 응답 시간과 같은 응답 시간은 여기에서 다음과 같은 효과를 갖습니다.
작업이 예상보다 빨리 도착하기 시작하는 규칙 실행에서는 그렇습니다.
처리됨.
위 이미지는 리소스 사용량 대시보드를 보여줍니다.
초당 2개의 규칙을 실행하는 동일한 애플리케이션 각 규칙은 단일 항목에 대한 업데이트를 수행합니다.
단일 유형의 객체입니다. 따라서 시스템은 초당 2번의 업데이트를 수행합니다.
안정된 상태.
제품 개요
우리는 진단에 대한 다양한 접근법을 논의했습니다.
VANTIQ 시스템의 오류 및 확장성 문제. 토론은 그렇지 않습니다.
사용 가능한 기술의 대표적인 샘플링만을 철저하게 제시
발견된 문제를 진단하고 수정하기 위해.
이 정보가 도움이 되기를 바랍니다.
이러한 공격에 사용한 다른 기술이 있는 경우
문제를 문서화해 주시면 이 가이드에 추가하겠습니다.