비즈니스 요구 사항에 맞게 빌드

  • 아티클

모든 디자인 결정은 비즈니스 요구 사항에 맞춰 정당화되어야 합니다. 이 디자인 원칙은 명확해 보일 수 있지만 Azure 애플리케이션을 디자인할 때 반드시 명심해야 합니다.

애플리케이션에서 사용자를 몇 명이나 지원해야 합니까, 수백만 명 또는 몇 천 명이면 됩니까? 트래픽이 많거나 워크로드가 안정적입니까? 어떤 수준의 애플리케이션 중단이 허용됩니까? 궁극적으로 비즈니스 요구 사항은 이러한 디자인 고려 사항을 염두에 둡니다.

다음 권장 사항은 비즈니스 요구 사항을 충족하기 위해 솔루션을 설계하고 빌드하는 데 도움이 됩니다.

  • 비즈니스 목표 정의(예: RTO(복구 시간 목표), RPO(복구 지점 목표) 및 MTO(최대 허용 중단)). 이러한 수치는 아키텍처를 결정하는 데 필요합니다.

    예를 들어 비즈니스에 매우 낮은 RTO와 매우 낮은 RPO가 필요하다고 가정합니다. 이러한 요구 사항을 충족하기 위해 영역 중복 아키텍처를 사용하도록 선택할 수 있습니다. 비즈니스에서 더 높은 RTO 및 RPO를 허용할 수 있는 경우 중복성을 추가하면 비즈니스 혜택이 없는 추가 비용이 추가될 수 있습니다.

  • 완화해야 하는 오류 위험을 고려합니다. 자체 복구를 위한 디자인 지침에 따라 다양한 유형의 일반적인 오류 모드에 복원할 수 있도록 솔루션을 디자인합니다. 지역의 모든 가용성 영역에 영향을 줄 수 있는 주요 자연 재해가 발생하는 지리적 영역과 같이 가능성이 낮은 상황을 고려해야 하는지 여부를 고려합니다. 이러한 드문 위험을 완화하는 것은 일반적으로 더 비싸고 상당한 절충을 수반하므로 비즈니스의 위험 허용 오차를 명확하게 이해해야 합니다.

  • 가용성 및 성능 메트릭을 포함하여 SLA(서비스 수준 계약) 및 SLO(서비스 수준 목표)를 문서화합니다. 예를 들어 제안된 솔루션은 99.95%의 가용성을 제공할 수 있습니다. SLO가 SLA를 충족하는지 여부는 비즈니스 결정입니다.

  • 비즈니스 도메인에 맞춰 애플리케이션을 모델링합니다. 비즈니스 요구 사항을 분석하고 이러한 요구 사항을 사용하여 솔루션을 모델링합니다. DDD(도메인 기반 디자인) 접근 방식을 사용하여 비즈니스 프로세스 및 사용 사례를 반영하는 도메인 모델을 만드는 것이 좋습니다.

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

  • 워크로드를 분해합니다. 여기서 워크로드는 별개의 기능 또는 계산 작업을 의미하며, 다른 작업과 논리적으로 분리할 수 있습니다. 여러 워크로드마다 가용성, 스케일링 성능, 데이터 일관성 및 재해 복구에 대한 요구 사항이 서로 다를 수 있습니다.

  • 확장 계획. 솔루션은 사용자 수, 트랜잭션 볼륨 및 데이터 스토리지에 대한 현재 요구 사항을 지원할 수 있지만 주요 아키텍처 변경 없이 성장을 처리해야 합니다. 또한 비즈니스 모델 및 비즈니스 요구 사항은 시간이 지남에 따라 변경될 수 있습니다. 애플리케이션의 서비스 모델 및 데이터 모델이 너무 엄격하면 새로운 사용 사례 및 시나리오에 맞게 솔루션을 변화시키기가 어려워집니다.

  • 비용 관리. 기존 온-프레미스 애플리케이션에서는 하드웨어 비용을 자본 지출로 미리 지불합니다. 클라우드 애플리케이션에서는 사용하는 리소스에 대해 비용을 지불합니다. 서비스의 가격 책정 모델을 이해해야 합니다. 총 비용에는 네트워크 대역폭 사용량, 스토리지, IP 주소 및 서비스 사용량이 포함될 수 있습니다.

    또한 운영 비용도 고려해야 합니다. 클라우드에서 하드웨어 또는 기타 인프라를 관리할 필요는 없으나, 애플리케이션 DevOps, 인시던트 응답, 재해 복구 관리는 여전히 필요합니다.

다음 단계