다음을 통해 공유

안정성 완성도 모델

안정성 여정은 시스템이 계속 사용 가능하고 사용자 기대치를 충족하도록 각 스테이지가 이전 단계를 기반으로 하는 단계별 프로세스입니다. 이 완성도 모델은 현재 상태를 평가하고 개선에 대한 구조적 경로를 제공하는 데 도움이 됩니다.

기초는 광범위한 최적화 오버헤드 없이 즉시 개선을 위해 영역 중복과 같은 기본 제공 Azure 안정성 기능을 사용하여 Azure에서 제공하는 기본 안정성 기능을 부트스트래핑하는 것으로 시작합니다.

직관에 반하여 높은 안정성을 달성하는 방법은 실패를 불가피한 것으로 받아들이는 것입니다. 모든 문제를 방지하는 것보다는 문제가 발생할 때 시스템이 어떻게 대응할지 계획하는 것이 더 효과적입니다. 비즈니스 요구 사항은 사전에 해결할 가치가 있는 위험을 결정하는 데 도움이 됩니다. Teams는 구조적 관찰성을 갖춘 고급 모니터링 기능에 투자하고, 애플리케이션 수준 문제를 포함하도록 오류 완화를 확장하고, 복원력 측정값 테스트를 시작합니다.

다음으로 팀은 비즈니스 인사이트를 기술 기술과 통합합니다. Teams는 상태 모델링을 구현하고, 실패 모드 분석을 수행하고, 포괄적인 재해 복구 계획을 준비합니다. 이 단계는 측정 가능한 목표와 다양한 오류 시나리오에 대한 체계적인 준비를 통해 책임을 보장합니다.

시스템이 라이브 상태가 된 후에는 변경 관리, 데이터 증가 및 운영 복잡성 처리, 시스템 안정성에 미치는 영향 등 프로덕션 환경의 문제를 관리하는 데 중점을 둡니다.

최종 수준은 무기한으로 실행되며 복원력을 유지하는 것이 목표입니다. 이 수준은 기술 제어를 넘어 아키텍처 적응성에 대한 진화를 나타냅니다. 이 수준은 워크로드가 진화하고 증가함에 따라 시스템이 새롭고 예기치 않은 위험을 견딜 수 있도록 하는 데 중점을 둡니다.

모델은 각각 기본 목표와 핵심 전략 집합이 있는 5개의 고유한 완성도 수준으로 구성됩니다. 아래 탭 보기를 사용하여 각 수준을 탐색합니다. 진행하면서 강조 표시된 장단 사항 및 관련 위험도 검토해야 합니다.

목표 아이콘 최적화 작업에 시간을 소비하는 대신 워크로드 인프라 및 운영에서 복원력을 위한 견고한 토대를 설정합니다.

완성도 모델의 수준 1은 워크로드 팀이 시스템 안정성을 위한 강력한 기반을 구축할 수 있도록 설계되었습니다. 향후 안정성 결정을 위한 기본 사항을 설정하는 프로세스인 부트스트래핑에 중점을 두고 있습니다. 이 단계에는 주로 현재 사례에 대한 사소한 확장이 있는 기능 구현이 포함됩니다.

이 단계에는 연구, 인사이트 얻기 및 시스템 인벤토리 만들기가 포함됩니다. 또한 즉시 개선을 위해 영역 중복성을 사용하도록 설정하는 것과 같은 Azure의 기본 제공 안정성 기능을 사용합니다.

이러한 기본 사항을 설정하면 팀이 안정성 완성도 모델의 수준을 발전시켜 시스템의 복원력과 성능을 점진적으로 향상할 수 있도록 준비할 수 있습니다.

주요 전략

✓ 운영 책임을 오프로드할 기회를 평가합니다.

이 전략은 근본적으로 구축과 구매 또는 의존 접근법의 대조입니다. 결정은 향후 개발을 지원하면서 이 단계에서 얼마나 많은 책임을 관리할 수 있는지에 따라 달라집니다. 워크로드와 관련된 리소스를 사용하려고 하지만 유지 관리를 오프로드할 수 있는 기회를 항상 탐색해야 합니다. 다음은 이 방법을 적용할 수 있는 몇 가지 클래식 사용 사례입니다.

  • PaaS(Platform as a Service) 솔루션을 선택하여 클라우드 플랫폼에 대한 책임을 오프로드합니다. 복제, 장애 조치(failover) 및 백업 저장소와 같은 일반적인 복원력 요구 사항에 대해 준비된 솔루션을 제공합니다. 이 방법을 사용하면 클라우드 공급자가 호스팅, 유지 관리 및 복원력 향상을 처리합니다.

    예를 들어 클라우드 공급자는 여러 컴퓨팅 노드에서 데이터를 복제하고 가용성 영역에 복제본을 분산합니다. VM(가상 머신)에서 고유한 솔루션을 빌드하는 경우 이러한 측면을 직접 관리해야 하며, 이는 시간이 많이 걸리고 복잡할 수 있습니다.

  • 워크로드의 비즈니스 목표에 직접 연결되지 않은 작업에 대한 책임을 오프로드합니다. 데이터베이스 관리 및 보안과 같은 일부 특수 작업은 워크로드의 안정성에 영향을 줄 수 있습니다. 숙련된 팀, 기술 또는 둘 다 이러한 작업을 처리할 수 있는 가능성을 살펴봅니다.

    예를 들어 팀에 데이터베이스 전문 지식이 없는 경우 관리되는 서비스를 사용하여 책임을 공급자로 전환할 수 있습니다. 이 방법은 팀이 워크로드의 기능에 집중할 수 있으므로 시작할 때 유용할 수 있습니다. 많은 기업에서 중앙에서 관리되는 서비스를 공유했습니다. 플랫폼 팀을 사용할 수 있는 경우 이러한 작업을 처리하는 데 사용합니다. 그러나 이 방법은 종속성과 조직의 복잡성을 더할 수 있습니다.

    또는 팀에 적절한 전문 지식이 있는 경우 자신의 기술을 사용하고 관리 기능이 포함되지 않은 서비스를 선택하도록 명시적으로 결정할 수 있습니다.

  • Microsoft가 아닌 공급업체에 책임을 오프로드합니다. 기성품을 출발점으로 선택합니다. 워크로드의 비즈니스 가치에 기여하는 경우에만 사용자 지정된 솔루션을 빌드합니다.

위험:구매 또는 신뢰 옵션이 요구 사항을 부분적으로 충족하는 경우 사용자 지정 확장을 구현해야 할 수 있습니다. 이 메서드는 업데이트 및 현대화가 실용적이지 않은 "사용자 지정 잠금" 상황을 초래할 수 있습니다. 요구 사항을 정기적으로 검토하고 솔루션의 기능과 비교합니다. 둘 사이에 상당한 편차가 있는 경우에 대한 종료 전략을 개발합니다.

반대 시나리오도 위험합니다. 처음에는 구매 또는 신뢰 옵션이 더 간단해 보일 수 있지만, PaaS 서비스, 공급업체 솔루션 또는 플랫폼 소유 리소스의 제한 사항이 워크로드에 필요한 세분성 또는 수준의 자율성을 충족하지 않는 경우 나중에 재평가 및 재설계가 필요할 수 있습니다.

✓ 중요한 사용자 및 시스템 흐름 식별

이 단계에서는 워크로드를 흐름으로 분해하는 것이 중요합니다. 사용자 및 시스템 흐름에 집중합니다. 사용자 흐름은 사용자 상호 작용을 결정하며 시스템 흐름은 사용자 작업과 직접 연결되지 않은 워크로드 구성 요소 간의 통신을 결정합니다.

예를 들어 전자 상거래 애플리케이션에서 고객은 검색 및 주문과 같은 프런트 엔드 작업을 수행합니다. 한편, 백 엔드 트랜잭션 및 시스템 트리거 프로세스는 사용자 요청을 처리하고 다른 작업을 처리합니다. 이러한 고유 흐름은 동일한 시스템의 일부이지만 서로 다른 구성 요소를 포함하고 다른 용도로 사용됩니다.

이 단계에서 흐름 카탈로그 작성을 시작합니다. 사용자 상호 작용 및 구성 요소 통신을 관찰합니다. 흐름을 나열 및 분류하고, 시작점과 끝점을 정의하고, 종속성을 기록합니다. 명확성을 위해 다이어그램을 사용하여 결과 및 예외를 문서화합니다. 이 카탈로그는 비즈니스 이해 관계자와의 초기 대화에서 자신의 관점에서 가장 중요한 측면을 식별하는 중요한 도구 역할을 할 수 있습니다. 이 대화는 우선 순위의 첫 번째 수준을 알릴 수 있습니다.

기본 비즈니스 활동에 대한 위험 및 영향을 평가하여 흐름을 중요로 분류합니다. 중단이 예상되는 경우, 점진적 성능 저하는 중요한 흐름을 유지하는 데 초점을 맞춥니다. 전자상거래 예제에서 중요한 흐름에는 제품 검색, 카트에 항목 추가, 체크 아웃 등이 포함됩니다. 이러한 작업은 비즈니스에 필수적이기 때문입니다. 제품 데이터 업데이트 및 제품 이미지 유지 관리와 같은 다른 프로세스는 중요하지 않습니다. 사용자가 제품을 계속 검색하고 카트에 항목을 추가할 수 있도록 하여 중단 시 중요한 흐름이 계속 작동하여 수익 손실을 방지합니다.

비고

비즈니스 프로세스는 시간이 중요하지 않더라도 중요할 수 있습니다. 시간 중요도는 핵심 요소입니다. 예를 들어 감사 요구 사항을 충족하는 것은 중요한 프로세스이지만 감사에 대한 데이터를 즉시 제공하지 않아도 될 수 있습니다. 프로세스는 여전히 중요하지만 몇 시간 내에 복구할 수 있기 때문에 안정성은 시간이 중요하지 않습니다.

자세한 내용은 Azure Well-Architected Framework: 흐름을 사용하여 워크로드 디자인 최적화를 참조하세요.

✓ 올바른 디자인 모델, 리소스 및 기능 선택

다음 수준에서 이 전략을 적용해야 합니다.

  • 건축학: 워크로드 디자인은 다양한 인프라 계층의 안정성 기대치를 고려해야 합니다. 초기 결정은 애플리케이션을 호스팅하기 위한 컨테이너화 또는 PaaS 중에서 선택할 수 있습니다. 또는 허브, 스포크 또는 단일 가상 네트워크와 같은 네트워킹 설정을 고려할 수 있습니다.

    또한 기능에 따라 구분을 만드는 경계를 설정해야 합니다. 예를 들어 단일 영역 가상 디스크를 사용하여 한 VM에서 모든 항목을 호스팅하는 대신 컴퓨팅 및 데이터 스토리지를 분할하고 전용 서비스를 사용하는 것이 좋습니다.

    주의

    마이그레이션 시나리오에서 새로운 기회를 검토하지 않고 리프트 앤 시프트 접근 방식을 채택하면 누락된 이점과 비효율성이 발생할 수 있습니다. 변경하기 어려운 설정에 갇히지 않도록 조기에 현대화를 연구하고 더 나은 옵션과 개선 사항을 활용하는 것이 중요합니다.

  • Azure 서비스: 의사 결정 트리를 사용하여 디자인에 적합한 서비스를 선택할 수 있습니다. 워크로드가 진화하고 더 많은 기능이 필요할 때 서비스를 전환할 수 있도록 현재 요구 사항을 충족하지만 유연하게 유지되는 구성 요소를 선택합니다.

  • Azure 서비스 내의 SKU 또는 계층: 각 SKU의 기능을 검토하고 플랫폼의 가용성 보장을 이해합니다. 서비스 수준 계약을 평가하여 게시된 백분위수 주위에 제공되는 적용 범위를 이해합니다.

  • 안정성을 지원하는 기능: 코드를 변경하지 않고 간단한 구성을 통해 가용성을 향상하려면 클라우드 네이티브 서비스를 선택합니다. 옵션을 이해하고 영역 중복을 늘리거나 보조 지역에 데이터를 복제하는 것과 같은 구성을 의도적으로 선택하는 것이 중요합니다.

✓ 기본 수준의 이중화로 배포

솔루션의 각 부분 내에서 단일 인스턴스와 같은 단일 실패 지점을 방지합니다. 대신 중복성을 위해 여러 인스턴스를 만듭니다. Azure 서비스는 일반적으로 기본적으로 로컬 중복성과 업그레이드 옵션을 포함하는 PaaS 서비스에서 중복성을 처리하는 경우가 많습니다. 바람직하게는 영역 중복성을 사용하여 여러 Azure 데이터 센터에 이러한 인스턴스를 분산하는 것이 좋습니다. 그렇지 않은 경우 적어도 로컬 중복성을 보장하지만 이 방법은 위험이 더 높습니다. 향후 수준에서는 지역 중복 구성 요소를 사용하여 솔루션을 확장하여 안정성 요구 사항이 충족될 수 있는지 여부를 평가합니다.

트레이드오프: 한 가지 중요한 타협은 중복성 비용 증가입니다. 또한 영역 간 통신으로 인해 대기 시간이 발생할 수 있습니다. 최소 대기 시간이 필요한 레거시 애플리케이션의 경우 중복성이 성능을 저하시킬 수 있습니다.

위험: 애플리케이션이 다중 인스턴스 환경을 위해 설계되지 않은 경우 여러 활성 인스턴스로 인해 어려움을 겪을 수 있으며 이로 인해 데이터가 일관되지 않을 수 있습니다. 또한 대기 시간이 짧은 온-프레미스 설치를 위해 애플리케이션을 빌드하는 경우 가용성 영역을 사용하면 성능이 저하될 수 있습니다.

✓ 메트릭, 로그 및 추적을 사용하도록 설정하여 흐름 모니터링

Azure Monitor와 같은 플랫폼 네이티브 도구를 선택하여 메트릭, 로그 및 추적의 가시성을 보장합니다. 기본 제공 기능을 사용하여 잠재적인 문제에 대한 경고를 설정합니다. 알림을 보내고 경고를 받을 수 있는 기본 경고가 있어야 합니다. 다음과 같은 서비스의 상태 변경을 나타내는 Azure 플랫폼 기능을 활용합니다.

인프라와 애플리케이션 모두에 대한 Azure Monitor 작업 그룹을 설정합니다.

트레이드오프: 더 많은 로그를 수집할수록 증가하는 로그의 양을 관리해야 하며, 이는 해당 로그의 저장 관련 비용에 영향을 미칩니다. 보존 정책을 사용하여 볼륨을 관리합니다. Azure Monitor를 사용하여 작업 영역에서 일일 한도를 설정합니다. 자세한 내용은 안정성에 대한 구성 권장 사항을 참조하세요.

다음 계층에서 관찰성 빌드를 시작합니다.

인프라

먼저 진단 로그를 사용하도록 설정하고 분석을 위해 플랫폼 구성 요소에서 네이티브 메트릭을 수집해야 합니다. CPU, 메모리, 입력/출력 및 네트워크 활동과 같은 리소스 사용량에 대한 정보를 수집합니다.

신청

메모리 사용량 또는 요청 대기 시간, 로그 애플리케이션 활동과 같은 애플리케이션 수준 메트릭을 수집합니다. 스레드 또는 주 애플리케이션 스레드와 별개인 프로세스에서 로깅 작업을 수행합니다. 이 방법을 사용하면 로깅이 애플리케이션의 기본 작업을 느리게 하지 않습니다.

또한 Application Insights에서 기본 가용성 테스트를 확인합니다.

데이터

기본 수준에서 데이터베이스를 모니터링하려면 데이터베이스 리소스에서 내보내는 주요 메트릭을 수집합니다. 인프라 구성 요소와 마찬가지로 네트워킹 메트릭과 같은 데이터 저장소의 컨텍스트에서 리소스 사용량을 추적합니다. 연결이 풀링되는 방법에 대한 데이터를 수집하는 것은 이후 단계에서 효율성을 향상시키는 데 중요합니다.

안정성을 위해 활성 및 실패한 연결 모니터링과 같은 연결 메트릭을 추적하는 것이 중요합니다. 예를 들어 Azure Cosmos DB에서 요청 수가 할당된 요청 단위를 초과하고 연결이 실패하기 시작하면 429 상태 코드가 반환됩니다.

✓ 오류 완화 플레이북 빌드 시작

오류는 간헐적 오류부터 약간 확장된 일시적 오류 및 치명적인 중단에 이르기까지 다양합니다.

수준 1에서는 플랫폼 오류에 집중합니다. 사용자가 제어할 수 없는 경우에도 이를 처리하기 위한 전략이 있어야 합니다. 예를 들어, 가용성 영역을 통해 영역별 중단 문제를 해결합니다. 플랫폼 수준에서 일시적인 오류를 예상하고 워크로드에서 처리합니다.

이러한 오류를 처리하는 프로세스는 복잡성에 따라 달라집니다. 잠재적인 플랫폼 수준 오류, 관련 위험 및 완화 전략을 문서화하기 시작합니다. 이 연습은 주로 이론적이고 이후 수준의 자동화로 완성됩니다.

가능성, 영향 및 완화 전략과 같은 요소를 포함하여 오류를 문서화해야 합니다. 워크로드의 목표에 맞는 중요도 배율을 사용합니다. 규모에는 다음이 포함될 수 있습니다.

  • 높음. 심각한 재정적 손실과 사용자 신뢰 감소를 초래하는 완전한 시스템 중단.

  • 보통. 워크로드의 일부에 영향을 미치고 사용자에게 불편을 주는 일시적인 중단입니다.

  • 낮다. 애플리케이션의 중요하지 않은 기능에 영향을 미치고 사용자에게 가동 중지 시간을 최소화하는 사소한 소프트웨어 문제입니다.

예제 템플릿은 다음과 같습니다.

문제 위험 출처 심각도 가능성 완화 방법
일시적인 네트워크 오류 클라이언트가 애플리케이션 서버에 대한 연결을 끊습니다. Azure 플랫폼 높음 매우 가능성이 높습니다. 다시 시도 논리 및 회로 차단기와 같은 클라이언트 쪽 논리에서 디자인 패턴을 사용합니다.
영역 장애 사용자가 애플리케이션에 연결할 수 없습니다. Azure 플랫폼 높음 가능성이 없음 모든 구성 요소에서 영역 복원력을 사용하도록 설정합니다.
TLS(전송 계층 보안) 인증서 만료 클라이언트는 애플리케이션을 사용하여 TLS 세션을 설정할 수 없습니다. 사용자 오류 높음 가능성 높음 자동화된 TLS 인증서 관리를 사용합니다.
CPU 또는 메모리 사용량이 정의된 제한에 도달하여 서버가 실패합니다. 요청 시간이 초과되었습니다. 신청 미디엄 가능성 높음 자동 다시 시작을 구현합니다.
업데이트하는 동안 구성 요소를 사용할 수 없습니다. 사용자가 애플리케이션에서 처리되지 않은 오류가 발생합니다. 구성의 배포 또는 변경 낮음 배포 중 가능성이 높고 다른 시간에는 가능성이 없습니다. 클라이언트 쪽 논리에서 구성 요소를 처리합니다.

수준 1에서는 항상 예기치 않은 오류 사례가 있기 때문에 완전성을 위해 노력하지 마세요. 예기치 않은 중단이 발생하는 경우 플레이북에서 원인 및 완화를 문서화합니다. 이 자산을 시간이 지남에 따라 업데이트하는 살아있는 문서로 처리합니다.

✓ 일시적인 오류로부터 복구하는 메커니즘 추가

클라우드 환경에서 일시적인 오류는 일반적입니다. 재시도는 일반적으로 몇 초 내에 해결할 수 있는 단기적인 문제를 나타냅니다.

기본 제공 SDK 및 구성을 사용하여 이러한 오류를 처리하여 시스템을 활성 상태로 유지합니다. 기본 제공 구성은 종종 기본 설정이므로 구현의 유효성을 검사하기 위해 테스트해야 할 수 있습니다. 또한 아키텍처에서 일시적인 오류를 처리하도록 설계된 패턴을 구현합니다. 자세한 내용은 안정성을 지원하는 아키텍처 디자인 패턴을 참조하세요.

지속성 문제는 일시적이지 않은 오류 또는 중단의 시작을 나타낼 수 있습니다. 이 시나리오에는 애플리케이션 내에서 지역화된 문제를 해결하는 것 이상이 필요합니다. 여기에는 시스템의 중요한 사용자 및 시스템 흐름을 검토하고 자체 보존 기술과 복구 노력을 추가하는 작업이 포함됩니다. 이러한 방법은 수준 2에서 설명하는 완성도 높은 사례입니다.

✓ 기본 테스트 실행

소프트웨어 개발 수명 주기의 초기 단계에서 기본 안정성 테스트를 통합합니다. 기능 및 구성의 유효성을 검사하는 단위 테스트부터 시작하여 테스트를 수행할 기회를 찾습니다.

또한 위험 완화 플레이북에서 식별하는 문제에 대한 간단한 테스트 사례를 개발합니다. 더 높은 영향, 낮은 노력 완화에 집중합니다. 예를 들어 네트워크 중단 또는 일시적인 연결 문제를 시뮬레이션하여 재시도 논리가 중단을 해결하는 방법을 확인합니다.

위험: 테스트는 종종 개발 주기에 마찰을 발생합니다. 이러한 위험을 완화하려면 개발 작업과 함께 안정성 테스트를 추적할 수 있도록 합니다.

기능 개발이 우선 순위이며 테스트는 개발 주기에 마찰을 가져올 수 있습니다. 기능 개발이 완료되기 전에 테스트를 시작하는 것이 더 쉽습니다. 처음에 애플리케이션의 비기능적 측면을 디자인하면 나중에 해결할 문제의 백로그를 작성하는 대신 기능 기능을 추가할 때 확장할 수 있습니다. 이 방법은 처음에는 더 많은 노력이 필요하지만 관리가 가능하고 나중에 더 큰 문제를 방지합니다.

다음 단계

  • Last updated on