Power Platform 작업 부하에 대한 안정성 트레이드오프
안정적인 워크로드는 정의된 안정성 목표를 지속적으로 충족합니다. 이상적으로는 안정성에 영향을 미치는 이벤트를 회피하여 설정된 복원력 목표에 도달해야 합니다. 그러나 현실적으로 워크로드는 이러한 이벤트의 영향을 허용 및 제어하고 활성 오작동 중에 미리 결정된 수준으로 작업을 유지해야 합니다. 재해가 발생한 경우에도 안정적인 워크로드는 이해 관계자 간에 합의된 일정 기간 내에 특정 상태로 복구되어야 합니다. 신속한 탐지 및 복구를 가능하게 하는 인시던트 대응 계획은 매우 중요합니다.
워크로드의 설계 단계에서는 안정성 설계 원칙과 안정성 설계 검토 체크리스트의 권장 사항을 기반으로 한 결정이 다른 요소의 목표와 최적화에 어떻게 영향을 미칠 수 있는지 고려해야 합니다. 특정 결정은 일부 핵심 요소에 도움이 될 수 있지만 다른 원칙에는 트레이드오프를 구성할 수 있습니다. 이 문서에서는 워크로드 팀이 안정성을 위해 워크로드 아키텍처 및 작업을 설계할 때 발생할 수 있는 트레이드오프 예를 설명합니다.
보안과 안정성의 트레이드오프
트레이드오프: 작업 표면적 증가. 보안 핵심 요소는 공격 벡터를 최소화하고 보안 제어 관리를 줄이기 위해 감소되고 격리된 표면적을 우선시합니다.
안정성은 복제를 통해 획득되는 경우가 많습니다. 복제는 구성 요소 수준, 데이터 수준 또는 지리적 수준에서도 발생할 수 있습니다. 복제본은 워크로드의 표면적을 늘리도록 설계되었습니다. 보안 관점에서는 잠재적인 공격 벡터를 최소화하고 보안 제어 관리를 간소화하기 위해 노출 영역을 줄이고 억제하는 것이 좋습니다.
마찬가지로 백업과 같은 재해 복구 솔루션은 워크로드의 노출 영역을 늘립니다. 그러나 워크로드의 런타임에서 격리되는 경우가 많습니다. 이를 위해서는 재해 복구 솔루션에 특정한 추가 보안 제어를 구현해야 합니다.
안정성 목표를 위해 아키텍처에 추가 구성 요소가 필요할 수 있으며 이로 인해 표면적이 늘어납니다. 이렇게 복잡성이 증가하면 시스템에서 아직 사용되지 않는 방식으로 보안이 필요한 새 구성 요소를 추가하여 워크로드의 노출 영역이 늘어납니다. 일반적으로 이러한 구성 요소에는 해당 사용 또는 일반적인 안정성 패턴을 지원하기 위한 추가 코드가 함께 제공되며, 이로 인해 애플리케이션의 노출 영역도 늘어납니다.
워크로드에서 활성 사고 대응에 따라 해결되는 안정성 이벤트가 발생하는 경우 긴급성으로 인해 워크로드 팀이 일상적인 액세스에 최적화된 보안 제어를 우회해야 한다는 압력이 생길 수 있습니다.
문제 해결 활동으로 인해 팀이 보안 프로토콜을 일시적으로 비활성화하여 이미 스트레스를 받은 시스템이 잠재적으로 추가적인 보안 위험에 노출될 수 있습니다. 보안 프로토콜이 즉시 재설정되지 않을 위험도 있습니다.
역할 기반 액세스 제어 할당 또는 방화벽 규칙과 같은 보안 제어를 세부적으로 구현하면 구성이 복잡해지고 민감도가 발생하여 구성이 잘못될 가능성이 높아집니다. 광범위한 규칙을 사용하여 이러한 잠재적인 안정성 영향을 완화하면 세 가지 제로 트러스트 아키텍처 원칙이 모두 침식됩니다.
타사 구성 요소나 솔루션과 같은 공급업체 라이브러리에 릴리스 웨이브 업데이트를 적용하면 잠재적으로 대상 구성 요소가 중단되어 변경 중에 가용성이 저하될 수 있습니다. 패치 적용을 지연하거나 피하면 잠재적인 안정성 위험을 피할 수 있지만 진화하는 위협으로부터 시스템을 보호할 수 없습니다.
앞의 고려 사항은 워크로드의 코드에도 적용됩니다. 예를 들어 이전 라이브러리와 구성 요소를 사용하는 애플리케이션 코드에 적용됩니다. 애플리케이션 코드 업데이트 및 배포가 완화되지 않은 안정성 위험으로 간주되면 애플리케이션은 시간이 지남에 따라 추가적인 보안 위험에 노출됩니다.
운영 효율성과 안정성 트레이드오프
워크로드에 대한 포괄적인 모니터링 전략을 갖추는 것은 운영 효율성의 핵심 부분입니다. 안정성 설계 패턴을 구현하기 위해 아키텍처에 추가 구성 요소를 도입하면 관리해야 할 데이터 원본이 더 많아지고 분산 추적 및 관찰 가능성 구현의 복잡성이 증가합니다.
여러 지역을 사용하여 단일 지역 리소스 용량 제약을 극복하거나 활성/활성 아키텍처를 구현하면 워크로드 운영 관리의 복잡성이 증가합니다. 이러한 복잡성은 여러 지역을 관리해야 하고 지역 간 데이터 복제를 관리해야 하기 때문에 발생합니다.
안정성 구성 요소와 패턴을 추가하여 워크로드가 더욱 강력해짐에 따라 운영 절차와 아티팩트 문서를 유지하는 데 더 많은 시간이 걸립니다.
워크로드의 구성 요소 수가 증가하면 학습이 더욱 복잡해집니다. 이러한 복잡성은 온보딩에 필요한 시간에 영향을 미치고 제품 로드맵 및 서비스 수준 지침을 추적하는 데 필요한 지식을 증가시킵니다.
환경 최적화와 안정성 트레이드오프
엄격한 테스트를 강조하면 채택에 필수적인 환경 기능의 릴리스가 지연될 수 있습니다.
안정성을 최적화하면 복잡성을 최소화하는 데 지나치게 집중할 수 있으며, 이로 인해 사용자 지정 구성 요소 및 통합과 같은 보다 매력적인 사용자 경험을 위한 기능의 우선 순위가 낮아질 수 있습니다.
성능 효율성과 안정성의 균형
신뢰성 패턴에는 종종 복제 오류에서 살아남기 위해 데이터 복제가 통합됩니다. 복제는 안정적인 데이터 쓰기 작업에 추가적인 지연 시간을 발생시키며, 이는 특정 사용자 또는 데이터 흐름에 대한 성능 예산의 일부를 소모합니다.
안정성은 때로 다양한 형태의 리소스 밸런싱을 사용하여 부하를 정상적인 복제본에 분산하거나 재분배합니다. 밸런싱에 사용되는 전담 구성 요소는 일반적으로 밸런싱되는 요청이나 프로세스의 성능에 영향을 미칩니다.
범위가 정해진 영향을 견뎌내기 위해 지리적 경계나 가용성 영역에 구성 요소를 분산시키면 해당 가용성 경계에 걸쳐 있는 구성 요소 간 통신에 네트워크 지연이 발생합니다.
작업 부하의 상태를 관찰하기 위해 광범위한 프로세스가 사용됩니다. 모니터링은 안정성에 중요하지만, 계측은 시스템 성능에 영향을 미칠 수 있습니다. 관찰성이 증가함에 따라 성능이 저하될 수 있습니다.
자동 확장 작업은 즉각적으로 이루어지지 않기 때문에 형성하거나 완화할 수 없는 갑작스럽고 극적인 수요 급증을 안정적으로 처리할 수 없습니다. 따라서 수요 신호와 공급 생성 사이의 지연을 설명하기 위해 더 큰 인스턴스나 여러 인스턴스를 통한 과도한 프로비저닝은 중요한 안정성 전략입니다. 사용되지 않은 용량은 성능 효율성의 목표에 어긋납니다.
때로는 수요에 맞춰 구성요소를 확장할 수 없는 경우가 있으며, 수요를 완벽하게 예측할 수 없습니다. 최악의 상황을 대비해 대규모 인스턴스를 사용하면 해당 사용 사례가 아닌 상황에서 과도한 프로비저닝 낭비가 발생합니다.