연습 - 애플리케이션 상태 모델 빌드
Contoso Shoes는 이 아키텍처 전체에서 문제를 감지, 진단 및 예측하는 방법이 필요합니다. 사용자 및 시스템 흐름에 적용된 상태를 통해 측정 가능한 상태 모델을 빌드하려고 합니다. 목표는 중단을 일으킬 수 있기 전에 잠재적인 실패 지점을 식별하는 것입니다.
현재 상태 및 문제
지금까지 상태 검사 API를 추가하고 아키텍처에서 다중 지역 기능을 빌드했습니다. 그러나 사용자 및 시스템 흐름을 포함하는 복잡한 토폴로지에 대한 인사이트를 얻을 수 있는 방법은 없습니다. SRE 팀이 문제를 신속하게 식별하고 해결할 수 있도록 이 격차를 해소해야 합니다.
최근 인시던트에서 팀은 플랫폼 종속성에 영향을 주는 API 구성 요소로 인한 문제의 연속적인 영향을 확인할 수 없었습니다. 비정상 구성 요소를 바로 찾을 수 없기 때문에 문제 해결에 상당한 시간이 소요되었습니다. 궁극적으로, 이러한 비효율성은 회사에 재정적 손실을 일으키는 더 긴 가동 중단으로 이어졌습니다.
규격
애플리케이션 구성 요소와 플랫폼 종속성을 포함하여 아키텍처의 모든 구성 요소 간 관계를 보여 주는 상태 모델을 디자인합니다. 게이트웨이, 컴퓨팅, 데이터베이스, 스토리지, 캐시 등을 포함하여 요청 흐름 내에 있는 항목을 고려합니다. 또한 일반적으로 요청 흐름 외부에 존재하는 구성 요소도 포함합니다. OCI(Open Container Initiative) 아티팩트, 비밀 저장소, 구성 서비스 등을 예로 들 수 있습니다. 진단 데이터를 보내도록 모든 Azure 서비스를 구성해야 합니다.
다양한 원본에서 데이터를 수집하기 위해 아키텍처에 통합 데이터 싱크를 추가합니다.
집계된 기록 로그 및 메트릭을 기준으로 전체 상태를 정의합니다. 비정상, 성능 저하 및 정상 상태의 세 가지 상태 중 하나를 나타냅니다.
모든 흐름을 나타내는 계층 구조에 있는 모든 구성 요소 상태를 시각화합니다.
권장 접근 방식
디자인을 시작하려면 다음 단계를 수행하는 것이 좋습니다.
Important
상태 모델링은 포괄적인 연습입니다. 이 섹션의 접근 방식은 시작하는 데 도움이 됩니다. 중요 업무용 디자인의 모든 기능 및 비기능 흐름에 모델을 광범위하게 적용하여 시스템의 전체적인 보기를 얻을 수 있습니다.
1– 상태 모델링 시작
이 연습은 이론적입니다. 아키텍처에 사용되는 구성 요소의 포괄적인 목록이 필요한 하향식 디자인 활동의 상태 모델링. 이 목록에는 모든 애플리케이션 구성 요소와 Azure 서비스가 포함되어야 합니다.
이러한 구성 요소를 솔루션의 계층적 보기를 보여 주는 종속성 그래프에 배치합니다. 최상위 계층에는 최종 사용자, 웹 사이트 및 애플리케이션 API 수준에서 요청을 추적하는 사용자 흐름이 있습니다. 최하위 계층에는 Azure 서비스의 ‘시스템 흐름’이 포함됩니다. 또한 Azure 리소스 간의 종속성을 매핑합니다.
그래프는 다음과 같이 표시됩니다.
진행 상황 확인: 계층화된 애플리케이션 상태
2–상태 점수 정의
각 구성 요소에 대해 메트릭 및 메트릭 임계값을 수집한 다음, 구성 요소가 정상, 성능 저하 및 비정상으로 간주되어야 하는 값을 결정합니다. 이러한 결정은 예상된 성능 및 비기능적 비즈니스 요구 사항에 의해 영향을 받아야 합니다. 메트릭을 다음과 같이 분류합니다.
애플리케이션 메트릭: 애플리케이션 코드의 데이터 포인트, 예외 수와 같은.
서비스 메트릭스: Azure 서비스의 데이터 요소, 사용 중인 DTU(데이터베이스 트랜잭션 단위)와 같은.
솔루션 메트릭: 요청의 엔드투엔드 처리 시간과 같은 솔루션 수준 데이터 포인트입니다.
다음은 Azure App Services의 예입니다.
| 앱 Services | 상태 |
|---|---|
| 응답 시간 < 200ms HTTP 서버 오류 < 2 |
 |
| 응답 시간 < 500ms HTTP 서버 오류 < 2 |
 |
| 응답 시간 > 500ms HTTP 서버 오류 > 2 |
 |
3–전체 상태 정의
각 사용자 및 시스템 흐름에 대해 전체 상태를 정의합니다. 해당 흐름에 참여하는 개별 구성 요소의 상태를 집계해야 합니다.
시스템 흐름이 애플리케이션 구성 요소, Azure App Service 플랜 및 App Services로 구성되어 있다고 가정합니다.
| API | App Service 계획 | 앱 Services | 상태 |
|---|---|---|---|
| 최대 대기 시간 < 30ms | CPU % < 70% HTTP 큐 길이 < 5 |
응답 시간 < 200ms HTTP 서버 오류 < 2 |
|
| 최대 대기 시간 < 30ms | CPU % < 90% HTTP 큐 길이 < 5 |
응답 시간 < 500ms HTTP 서버 오류 < 2 |
|
| 최대 대기 시간 > 30ms | CPU % > 90% HTTP 큐 길이 > 5 |
응답 시간 > 500ms HTTP 서버 오류 > 2 |
|
사용자 흐름의 상태 점수는 매핑된 모든 구성 요소에서 가장 낮은 점수로 표시되어야 합니다. 시스템 흐름의 경우 비즈니스 중요도에 따라 적절한 가중치를 적용합니다. 두 흐름 간에 재정적으로 중요하거나 고객 관련 사용자 흐름에 우선 순위를 두어야 합니다.
진행 상황 확인: 예제 - 계층화된 상태 모델
4–모니터링 데이터 수집
지역 스탬프의 일부로 배포된 모든 애플리케이션 및 플랫폼 서비스에 대한 로그 및 메트릭을 수집하는 통합 데이터 싱크가 각 지역에 필요합니다. Azure Front Door 및 Cosmos DB와 같은 글로벌 리소스에서 내보낸 메트릭을 저장하기 위한 다른 싱크가 필요합니다.
기술 선택
- Azure Application Insights: 모든 응용 프로그램 원격 분석을 수집하는 데 사용됩니다.
- Azure Monitor 로그: Azure 서비스에 대한 Application Insights 및 플랫폼 메트릭에서 보낸 데이터를 수집합니다.
- Azure Log Analytics: 모든 애플리케이션 및 인프라 구성 요소에서 로그 및 메트릭을 분석하기 위한 중앙 도구로 사용됩니다.
진행 상황 확인: 상관 관계가 있는 분석을 위한 통합 데이터 싱크
5–데이터 모니터링을 위한 쿼리 설정
KQL(Kusto 쿼리 언어)은 Log Analytics와 잘 통합됩니다. Azure Monitor에서 데이터를 검색하는 함수로서 사용자 지정 KQL 쿼리를 구현합니다.
CI/CD(연속 통합/지속적인 업데이트) 파이프라인의 일부로 자동으로 가져오고 적용되도록 코드 리포지토리에 사용자 지정 쿼리를 저장합니다.
6–상태 시각화
상태 점수에 따른 종속성 그래프를 신호등 표현으로 시각화할 수 있습니다. Azure 대시보드, Monitor 모니터링 또는 Grafana와 같은 도구를 사용합니다. 예를 들면 다음과 같습니다.
진행 상황 확인: 시각화
7–상태 변경에 대한 경고 설정
문제에 대한 즉각적인 주의를 환기하기 위해 알림 기능이 있는 대시보드를 사용해야 합니다.
구성 요소의 상태가 성능 저하 또는 비정상으로 변경되면 운영자는 즉시 알림을 받아야 합니다. 이 노드의 모든 변경 내용은 기본 사용자 흐름 또는 리소스의 비정상 상태를 나타내므로 루트 노드에서 경고를 설정합니다.
진행 상황 확인: 경고
작업 확인
모니터링 및 상태 모델링에 대한 이 데모를 시청하세요. 디자인의 모든 측면을 다루셨나요?
- 상관 관계 분석을 위한 통합 데이터 싱크가 있나요?
- 애플리케이션 로그, 플랫폼 메트릭 및 솔루션 데이터 포인트를 포함했나요?
- 모든 구성 요소의 상태를 시각화하도록 대시보드를 설정했나요?
- 가동 중단을 유발하거나 스케일링, 배포, 모니터링을 방해할 수 있는 각 서비스(또는 해당 서비스의 일부)의 오류 지점을 고려했나요?
- 문제를 더 빠르게 심사하는 데 도움이 되는 주요 쿼리를 캡처하기 위해 쿼리 팩을 고려했나요?
- 이 모델에서 상태 검사 API가 도움이 되었나요? 상태 모델에 더 적합하도록 해당 API를 변경해야 했나요?