다음을 통해 공유

단순성과 효율성을 고려한 설계에 대한 권장 사항

  • 아티클

Power Platform Well-Architected 안정성 체크리스트 권장 사항에 적용됩니다.

RE:01 비즈니스 목표에 맞게 워크로드를 설계하고 불필요한 복잡성이나 오버헤드를 방지하세요. 실용적이고 균형 잡힌 접근 방식을 사용하여 원하는 결과를 제공하는 설계 결정을 내립니다. 비효율성과 잠재적인 문제를 줄이기 위해 설계에 필수 사항을 포함하십시오.

이 가이드에서는 워크로드를 단순하고 효율적으로 유지하기 위해 불필요한 복잡성과 오버헤드를 최소화하기 위한 권장 사항을 설명합니다. 워크로드의 안정성을 최적화하는 데 필요한 워크로드 작업을 수행하는 데 가장 적합한 구성 요소를 선택하십시오. 개발 및 관리 부담을 줄이려면 플랫폼에서 제공하는 서비스가 제공하는 효율성을 활용하세요. 이 설계는 복원력이 뛰어나고 반복 가능하며 확장 가능하고 관리 가능한 워크로드 아키텍처를 만드는 데 도움이 됩니다.

정의

용어 정의
작업 부하 다른 작업과 논리적으로 분리할 수 있는 개별 기능 또는 컴퓨팅 작업입니다.

주요 디자인 전략

신뢰성을 위한 설계의 핵심 원칙은 모든 것을 단순하고 효율적으로 유지하는 것입니다. 불필요한 복잡성이나 과도한 오버헤드의 위험을 줄이기 위해 비즈니스 요구 사항을 충족하는 데 워크로드 설계에 집중하세요. 간결하고 효율적이며 안정적인 워크로드를 만들기 위한 설계 결정을 내리는 데 도움이 되도록 이 문서의 권장 사항을 고려하세요. 워크로드마다 가용성, 확장성, 데이터 일관성 및 재해 복구에 대한 요구 사항이 다를 수 있습니다.

비즈니스 요구 사항에 따라 모든 디자인 결정을 정당화해야 합니다. 이 설계 원칙은 당연해 보일 수 있지만 워크로드 설계에는 매우 중요합니다. 워크로드가 수백만 명의 사용자를 지원하나요, 아니면 수천 명의 사용자를 지원하나요? 트래픽이 폭증하거나 워크로드가 꾸준히 발생하나요? 허용되는 가동 중단 수준은 어느 정도입니까? 비즈니스 요구 사항에 따라 이러한 설계 고려 사항이 결정됩니다.

트레이드오프: 복잡한 솔루션은 더 많은 기능과 유연성을 제공할 수 있지만 구성 요소에 대한 더 많은 조정, 통신 및 관리가 필요하기 때문에 작업 부하의 안정성에 영향을 줄 수 있습니다. 또는 더 간단한 솔루션이 사용자 기대를 완전히 충족하지 못하거나 워크로드가 발전함에 따라 확장성에 부정적인 영향을 미칠 수도 있습니다.

협업 설계 연습

이해관계자와 협력하여 다음을 수행합니다.

  • 워크로드와 해당 구성 요소의 중요도 수준을 정의하고 할당합니다. 이 연습은 필요한 복원력 수준을 달성하기 위해 필요한 구성 요소와 최선의 접근 방식을 결정하는 데 도움이 됩니다. 자세한 내용은 애플리케이션 계층 정의를 참조하세요.

  • 기능적 요구 사항과 비기능적 요구 사항 정의. 기능적 요구 사항은 시스템의 기능과 동작을 정의합니다. 사용자가 지정하고 사용 사례에서 캡처됩니다. 비기능적 요구 사항은 시스템의 성능 및 품질 특성을 정의합니다. 가용성, 규정 준수, 데이터 보존/상주, 성능, 개인 정보 보호, 복구 시간, 보안, 확장성과 같은 비기능적 요구 사항을 이해하고 있는지 확인하세요. 이러한 요구 사항은 설계 결정과 기술 선택에 영향을 미칩니다.

    다음은 비용 보고서를 처리하는 워크로드의 맥락에서 기능적 및 비기능적 요구 사항의 몇 가지 예입니다.

    기능적 요구 사항 비기능적 요구 사항
    워크로드에서는 사용자가 자격 증명을 사용하여 로그인하고 개인 데이터에만 액세스할 수 있도록 허용해야 합니다. 워크로드는 최소한 99.9%의 시간 동안 사용할 수 있어야 합니다.
    워크로드에는 공개, 승인 및 거부된 비용 보고서의 개요를 제공하는 대시보드가 ​​포함되어야 합니다. 워크로드는 데이터 보호 및 개인 정보 보호에 대한 관련 규정 및 표준을 준수해야 합니다.
    워크로드는 워크로드 데이터에 대한 백업 및 복원 작업을 지원해야 합니다. 워크로드는 대부분의 사용자 요청에 대해 5초 미만에 응답해야 합니다.
    워크로드는 특정 이벤트나 임계값이 트리거되면 사용자와 관리자에게 알림을 보내야 합니다. 워크로드에는 전송 중인 데이터와 저장 중인 데이터에 대해 높은 수준의 보안과 암호화가 적용되어야 합니다.

    자세한 내용은 Microsoft Power Platform 및 Dynamics 365 요구 사항에 따른 작업이라는 제목의 교육 모듈을 참조하세요.

  • 워크로드를 구성 요소로 분류합니다. 검색 및 요구 사항 수집 프로세스 중에 일부 솔루션 아이디어가 명확해지기 시작해야 합니다. 비즈니스 요구 사항을 충족하기 위해 제안된 솔루션을 구성할 수 있는 솔루션 구성 요소를 식별합니다. 설계의 단순성, 효율성 및 신뢰성을 우선시하십시오. 워크로드를 지원하는 데 필요한 구성 요소를 결정합니다. 기본 제공 기능을 사용할 수 있는 위치와 사용자 지정 개발이 필요할 수 있는 곳을 강조합니다.

  • 장애 모드 분석을 사용하여 단일 장애 지점과 잠재적 위험을 식별합니다. 위험에 대한 비즈니스의 허용 범위를 명확하게 이해하십시오. 자세한 내용은 장애 모드 분석 수행에 대한 권장 사항을 참조하세요.

  • 워크로드에 대한 가용성 및 복구 대상을 정의하여 아키텍처 결정에 도움을 주세요. 비즈니스 지표에는 SLO(서비스 수준 목표), SLA(서비스 수준 약정), MTTR(평균 복구 시간), MTBF(평균 장애 간격), RTO(복구 시간 목표) 및 RPO(복구 지점 목표)가 포함됩니다. 이러한 메트릭에 대한 목표 값을 정의하세요. 이 연습에서는 각 팀의 목표가 비즈니스 목표를 충족하고 현실적이 되도록 하기 위해 기술 팀과 비즈니스 팀 간의 타협과 상호 이해가 필요할 수 있습니다. 자세한 내용은 안정성 목표 정의에 대한 권장 사항을 참조하세요. Power Platform SLA는 가동 시간 및 연결에 대한 Microsoft 약정을 제공합니다. 서비스마다 SLA가 다르며, 서비스 내의 SKU에 SLA가 다른 경우도 있습니다. 자세한 내용은 온라인 서비스용 서비스 수준 약정을 참조하십시오.

추가 설계 권장 사항

이해관계자 참여 없이 다음 권장 사항을 수행할 수 있습니다.

  • 디자인의 단순성과 명확성을 위해 노력하세요. 구성 요소와 서비스에 대해 적절한 수준의 추상화 및 세분성을 사용하십시오. 솔루션을 과도하게 엔지니어링하거나 과소 엔지니어링하지 마십시오. 예:

    • Power Automate을 사용하여 프로세스 자동화 요구 사항을 해결하는 경우 대규모 프로세스를 여러 개의 작은 클라우드 흐름으로 나누면 이해, 테스트, 유지 관리가 더 어려워질 수 있습니다. 반면에 모든 것을 대규모 흐름으로 유지하면 성능과 API 호출량에 부정적인 영향을 미칠 수 있습니다.

    • Power Apps를 사용하여 사용자가 직면하는 요구 사항을 해결하는 경우 컨트롤이 많은 대규모 모놀리식 캔버스 앱은 성능에 부정적인 영향을 미칠 수 있습니다. 단일 앱이나 사용자 지정 페이지로 나누면 테스트가 더 어려워질 수 있지만 성능에 상당히 긍정적인 영향을 미칠 수 있습니다.

  • 버그 수정, 새로운 기능이나 기술 구현, 기존 시스템의 확장성 및 복원력 향상 등 시간 경과에 따른 변화를 예측하세요.

  • 크로스 커팅에 대한 문제를 별도의 서비스로 오프로드하세요. 다양한 기능에 걸쳐 코드를 복제할 필요성을 최소화합니다. 다양한 구성 요소에서 쉽게 사용할 수 있는 잘 정의된 인터페이스로 서비스를 재사용하는 것을 선호합니다. 예를 들어 일련의 데이터 작업을 여러 위치에서 수행해야 하는 경우 이 기능을 로우코드 플러그인으로 이동할 수 있습니다.

  • 귀하의 요구에 맞는 일반적인 패턴과 관행의 적합성을 평가하세요. 상황이나 요구 사항에 가장 적합하지 않을 수 있는 추세나 권장 사항을 따르지 마세요. 예를 들어 사용자 지정 코드 구성 요소를 구현하는 것은 복잡성, 오버헤드 및 종속성 문제를 초래할 수 있으므로 모든 애플리케이션에 가장 적합한 옵션이 아닐 수 있습니다.

필요한 만큼만 코드 개발

단순성, 효율성 및 안정성의 원칙은 개발 방식에도 적용됩니다. 다음 권장 사항을 고려하세요.

  • 비즈니스 요구 사항을 충족할 때 플랫폼 기능을 사용하십시오. 예:

    • 사용자 고유의 코드 구성 요소를 개발하는 대신 최신 컨트롤을 사용하여 Fluent 2 디자인 표준을 달성하십시오.
    • 사용자 지정 커넥터를 개발하는 대신 네이티브 커넥터를 사용하여 사용자 지정 코드를 줄입니다.
    • Microsoft Copilot Studio에서 생성형 답변을 사용하면 에이전트가 수동으로 만든 주제 없이 내부 또는 외부의 여러 소스에서 정보를 찾고 제공할 수 있습니다.

  • 개발 방식으로 전용 코드 검토 세션을 도입합니다.

  • 데드 코드를 식별하는 접근 방식을 구현합니다. 자동화된 테스트에서 다루지 않는 코드에 대해 회의적이어야 합니다.

  • 개발팀의 기술 세트를 고려하십시오. 새로운 기술을 배우거나 새로운 기술을 채택하는 데는 시간이 걸립니다.

데이터의 위치 고려

아키텍처 설계의 일부로 데이터를 저장하는 방법이나 읽기 활동을 위해 데이터를 검색하는 방법을 고려해야 합니다. 데이터는 다양한 방식으로 검색하고 저장할 수 있습니다.

  • 새 데이터: 기존 비즈니스 프로세스가 종이에 수행된 경우와 같이 앱이 아직 존재하지 않는 데이터를 생성하는 경우 해당 데이터를 Microsoft Dataverse에 저장하는 것이 좋습니다.

  • 기존 시스템에서 읽기/쓰기: 앱이 기존 데이터베이스 또는 시스템에서 데이터를 검색해야 하는 경우 기본 제공 커넥터, 사용자 지정 커넥터 또는 가상 테이블을 사용하여 데이터베이스 또는 시스템에 연결하는 가장 좋은 방법을 평가해야 합니다.

  • 데이터의 사본 만들기: 원본 데이터를 수정하거나 덮어 쓰지 않아야 하는 경우 데이터를 Dataverse와 같은 다른 데이터 저장소에 복사할 수 있습니다. 이 전략은 원래 시스템의 데이터를 변경하지 않고 유지하면서 앱이 함께 작동할 수 있도록 합니다. 이 시나리오는 회계 및 수익 관련 시스템의 데이터로 작업할 때 일반적입니다. 데이터가 복사되는 방법, 업데이트되는 빈도 및 양방향 동기화가 발생해야 하는지 여부를 고려해야 합니다.

Power Platform 간편 사용

실용적인 디자인 조언은 다음 문서를 참조하십시오.

안정성 체크리스트

전체 권장 사항 세트를 참조하세요.

안정성 체크리스트