단순성과 효율성을 위한 디자인에 대한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

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

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

정의

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

주요 디자인 전략

안정성을 위한 디자인의 핵심 신조는 작업을 간단하고 효율적으로 유지하는 것입니다. 불필요한 복잡성 또는 과도한 오버헤드의 위험을 줄이기 위해 비즈니스 요구 사항을 충족하는 데 워크로드 디자인을 집중합니다. 이 문서의 권장 사항을 고려하여 설계를 결정하여 효율적이고 신뢰할 수 있는 워크로드를 만듭니다. 여러 워크로드마다 가용성, 스케일링 성능, 데이터 일관성 및 재해 복구에 대한 요구 사항이 서로 다를 수 있습니다.

비즈니스 요구 사항으로 모든 디자인 결정을 정당화해야 합니다. 이 디자인 원칙은 분명해 보일 수 있지만 워크로드 디자인에는 매우 중요합니다. 애플리케이션에서 수백만 명의 사용자 또는 수천 명의 사용자를 지원하나요? 트래픽이 많거나 워크로드가 안정적입니까? 어떤 수준의 애플리케이션 중단이 허용됩니까? 비즈니스 요구 사항으로 인해 이러한 디자인 고려 사항이 고려됩니다.

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

공동 작업 디자인 연습

관련자와 협력하여 다음을 수행합니다.

  • 워크로드의 사용자 흐름 및 시스템 흐름에 중요도 수준을 정의하고 할당합니다. 필요한 구성 요소와 필요한 복원력 수준을 달성하는 최선의 방법을 결정하는 데 도움이 되도록 중요한 흐름 에 디자인을 집중합니다.

  • 기능적 및 비기능적 요구 사항을 정의합니다. 애플리케이션이 작업을 수행하는지 여부를 확인하려면 기능 요구 사항을 고려합니다. 애플리케이션이 작업을 얼마나 잘 수행하는지 확인하려면 비기능 요구 사항을 고려합니다. 확장성, 가용성 및 대기 시간과 같은 비기능 요구 사항을 이해해야 합니다. 이러한 요구 사항은 디자인 결정 및 기술 선택에 영향을 줍니다.

  • 워크로드를 구성 요소로 분해합니다. 디자인에서 단순성, 효율성 및 안정성의 우선 순위를 지정합니다. 흐름을 지원하는 데 필요한 구성 요소를 결정합니다. 일부 구성 요소는 여러 흐름을 지원합니다. 구성 요소가 개념적으로 해결하는 문제를 식별하고 전체 기능을 제공하면서 전체 디자인을 간소화하기 위해 개별 흐름에서 구성 요소를 제거하는 것이 좋습니다. 자세한 내용은 실패 모드 분석을 수행하기 위한 권장 사항을 참조하세요.

  • 오류 모드 분석을 사용하여 단일 실패 지점 및 잠재적 위험을 식별합니다. 지역 내 모든 가용성 영역에 영향을 주는 주요 자연 재해가 발생하는 지리적 영역과 같이 예상치 못한 상황을 고려해야 하는지 여부를 고려합니다. 비용이 많이 들고 이러한 드문 위험을 완화하기 위해 상당한 절충이 수반됩니다. 비즈니스의 위험 허용 오차를 명확하게 이해합니다. 자세한 내용은 실패 모드 분석을 수행하기 위한 권장 사항을 참조하세요.

  • 흐름에 대한 가용성 및 복구 대상을 정의하여 워크로드의 아키텍처를 알릴 수 있습니다. 비즈니스 메트릭에는 SLO(서비스 수준 목표), SLA(서비스 수준 계약), MTTR(평균 복구 시간), MTBF(오류 간 평균 시간), RTO(복구 시간 목표) 및 RPO(복구 지점 목표)가 포함됩니다. 이러한 메트릭에 대한 대상 값을 정의합니다. 이 연습에서는 각 팀의 목표가 비즈니스 목표를 충족하고 현실적인지 확인하기 위해 기술과 비즈니스 팀 간의 타협과 상호 이해가 필요할 수 있습니다. 자세한 내용은 안정성 대상을 정의하기 위한 권장 사항을 참조하세요.

추가 디자인 권장 사항

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

  • 디자인의 단순성과 명확성을 위해 노력합니다. 구성 요소 및 서비스에 적절한 수준의 추상화 및 세분성을 사용합니다. 솔루션을 과도하게 엔지니어링하거나 엔지니어링을 미달하지 않도록 합니다. 예를 들어 코드를 여러 개의 작은 함수로 나누는 경우 이해하고 테스트하고 유지 관리하기가 어렵습니다.

  • 버그를 수정하거나, 새로운 기능 또는 기술을 구현하거나, 기존 시스템을 확장성 있고 복원력 있게 만들든, 시간이 지남에 따라 모든 성공적인 애플리케이션이 변경된다는 점을 인정합니다.

  • 가능한 경우 IaaS(Infrastructure as a Service) 대신 PaaS(Platform as a Service) 옵션을 사용합니다. IaaS는 부품 상자를 사용하는 것과 같습니다. 어떤 것도 작성할 수 있지만 직접 조립해야 합니다. PaaS 옵션은 더 쉽게 구성하고 관리할 수 있습니다. VM(가상 머신) 또는 가상 네트워크를 설정할 필요가 없습니다. 패치 및 업데이트 설치와 같은 유지 관리 작업도 수행할 필요가 없습니다.

  • 비동기 메시징을 사용하여 메시지 생산자를 소비자와 분리합니다.

  • 추상 인프라를 도메인 논리와 분리. 도메인 논리가 메시징 또는 지속성과 같은 인프라 관련 기능을 방해하지 않도록 합니다.

  • 교차 적용되는 문제를 별도 서비스에 오프로드. 여러 함수에서 코드를 복제할 필요성을 최소화하고, 다양한 구성 요소에서 쉽게 사용할 수 있는 잘 정의된 인터페이스를 사용하여 서비스를 재사용하는 것을 선호합니다. 예를 들어 여러 서비스가 요청을 인증해야 하는 경우 이 기능을 자체 서비스로 이동할 수 있습니다. 그런 다음 인증 서비스를 발전할 수 있습니다. 예를 들어 이를 사용하는 서비스를 건드리지 않고 새 인증 흐름을 추가할 수 있습니다.

  • 요구 사항에 대한 일반적인 패턴 및 사례의 적합성을 평가합니다. 컨텍스트 또는 요구 사항에 가장 적합하지 않을 수 있는 추세 또는 권장 사항을 따르지 마십시오. 예를 들어 마이크로 서비스는 복잡성, 오버헤드 및 종속성 문제를 도입할 수 있기 때문에 모든 애플리케이션에 가장 적합한 옵션은 아닙니다.

충분한 코드 개발

단순성, 효율성 및 안정성의 원칙은 개발 관행에도 적용됩니다. 느슨하게 결합된 구성 요소화된 워크로드에서 구성 요소가 제공하는 기능을 결정합니다. 해당 기능을 활용하도록 흐름을 개발합니다. 개발 사례에 대해 다음과 같은 권장 사항을 고려합니다.

  • 비즈니스 요구 사항을 충족하는 경우 플랫폼 기능을 사용합니다. 예를 들어 개발 및 관리를 오프로드하려면 클라우드 공급자가 제공하는 하위 코드, 코드 없음 또는 서버리스 솔루션을 사용합니다.

  • 라이브러리 및 프레임워크를 사용합니다.

  • 쌍 프로그래밍 또는 전용 코드 검토 세션을 개발 사례로 소개합니다.

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

데이터에 가장 적합한 데이터 저장소 사용

과거에는 많은 조직에서 모든 데이터를 대규모 관계형 SQL 데이터베이스에 저장했습니다. 관계형 데이터베이스는 관계형 데이터 트랜잭션에 대한 ACID(원자성, 일관성, 격리 및 지속성) 보증을 제공합니다. 그러나 이러한 데이터베이스에는 다음과 같은 단점이 있습니다.

  • 쿼리에 비용이 많이 드는 조인이 필요할 수 있습니다.

  • 데이터를 정규화하고 쓰기 시 스키마를 위해 데이터를 재구성해야 합니다.

  • 잠금 경합은 성능에 영향을 줄 수 있습니다.

관계형 데이터베이스에 대한 대안

대규모 솔루션에서는 단일 데이터 저장소 기술이 모든 요구 사항을 충족하지 못할 수 있습니다. 관계형 데이터베이스에 대한 대안은 다음과 같습니다.

  • 키-값 저장소

  • 문서 데이터베이스

  • 검색 엔진 데이터베이스

  • 시계열 데이터베이스

  • 열 패밀리 데이터베이스

  • 그래프 데이터베이스

각 옵션에는 장단점이 있습니다. 다른 데이터 형식은 다른 데이터 저장소 형식에 더 적합합니다. 데이터 및 데이터를 사용하는 방법에 가장 적합한 스토리지 기술을 선택합니다.

예를 들어 유연한 스키마를 지원하는 Azure Cosmos DB와 같은 문서 데이터베이스에는 제품 카탈로그를 저장할 수 있습니다. 각 제품 설명은 자체 포함된 문서입니다. 전체 카탈로그에 대한 쿼리의 경우 카탈로그를 인덱싱하고 Azure Cognitive Search에 인덱스를 저장할 수 있습니다. 제품 인벤토리는 해당 데이터에 ACID 보장이 필요하기 때문에 SQL 데이터베이스로 전환될 수 있습니다.

권장 사항

  • 다른 데이터 저장소를 고려합니다. 관계형 데이터베이스가 항상 적절한 것은 아닙니다. 자세한 내용은 데이터 저장소 모델 이해를 참조하세요.

  • 데이터에는 지속적인 애플리케이션 데이터 그 이상이 포함됩니다. 또한 애플리케이션 로그, 이벤트, 메시지 및 캐시도 포함됩니다.

  • 데이터 저장소 기술의 조합을 사용하는 다각형 지속성 또는 솔루션을 수용합니다.

  • 가지고 있는 데이터 형식을 고려합니다. 예를 들어 다음을 저장합니다.

    • SQL 데이터베이스의 트랜잭션 데이터입니다.

    • 문서 데이터베이스의 JSON 문서입니다.

    • 시계열 데이터베이스의 원격 분석입니다.

    • Azure Cognitive Search 애플리케이션 로그.

    • Azure Blob Storage Blob입니다.

  • 일관성보다 가용성의 우선 순위를 지정합니다. CAP 정리는 분산 시스템의 가용성과 일관성을 절충해야 한다는 것을 의미합니다. CAP 정리의 다른 구성 요소인 네트워크 파티션을 완전히 피할 수는 없습니다. 그러나 고가용성을 달성하기 위해 최종 일관성 모델을 채택할 수 있습니다.

  • 개발 팀의 기술 세트를 고려합니다. Polyglot 지속성을 사용할 경우 장점도 있지만 속도가 느려질 수 있습니다. 새 데이터 스토리지 기술을 채택하려면 새로운 기술 집합이 필요합니다. 기술을 최대한 활용하려면 개발 팀이 다음을 수행해야 합니다.

    • 쿼리를 최적화합니다.

    • 성능을 조정합니다.

    • 적절한 사용 패턴을 사용합니다.

스토리지 기술을 선택할 때 다음 요소를 고려합니다.

  • 보정 트랜잭션을 사용합니다. 다중 글로트 지속성을 사용하면 단일 트랜잭션이 여러 저장소에 데이터를 쓸 수 있습니다. 오류가 있는 경우 보상 트랜잭션을 사용하여 완료된 단계를 실행 취소합니다.

  • 도메인 기반 디자인 개념인 제한된 컨텍스트를 고려합니다. 제한된 컨텍스트는 도메인 모델 주위의 명시적 경계입니다. 바인딩된 컨텍스트는 모델이 적용되는 도메인의 부분을 정의합니다. 원칙적으로 제한된 컨텍스트는 비즈니스 도메인의 하위 도메인에 매핑됩니다. 시스템의 제한된 컨텍스트에 대한 다각형 지속성을 고려합니다. 예를 들어 제품 카탈로그 하위 도메인 및 제품 인벤토리 하위 도메인에 제품이 표시될 수 있습니다. 그러나 이러한 두 하위 도메인에는 제품을 저장, 업데이트 및 쿼리하기 위한 요구 사항이 서로 다를 수 있습니다.

Azure 촉진

Azure는 다음 서비스를 제공합니다.

  • Azure Functions 최소한의 코드로 오케스트레이션을 빌드하는 데 사용할 수 있는 서버리스 컴퓨팅 서비스입니다.

  • Azure Logic Apps 는 GUI를 사용하거나 구성 파일을 편집하여 오케스트레이션을 빌드하는 데 사용할 수 있는 서버리스 워크플로 통합 플랫폼입니다.

  • Azure Event Grid MQTT 및 HTTP 프로토콜을 사용하는 유연한 메시지 사용 패턴을 제공하는 확장성이 뛰어난 완전 관리형 게시-구독 메시지 배포 서비스입니다. Event Grid를 사용하면 디바이스 데이터를 사용하여 데이터 파이프라인을 빌드하고, 이벤트 기반 서버리스 아키텍처를 빌드하고, 애플리케이션을 통합할 수 있습니다.

자세한 내용은 다음을 참조하세요.

예제

요구 사항에 따라 구성 요소 및 해당 기능을 결정하는 예제 워크로드는 신뢰할 수 있는 웹앱 패턴을 참조하세요.

안정성 검사 목록

전체 권장 사항 집합을 참조하세요.

안정성 검사 목록