성공적인 통합 디자인은 볼륨 및 빈도, 방향성 및 기능의 세 가지 기본 차원을 이해하는 것으로 시작합니다. 이러한 차원은 비즈니스 요구 사항, 시스템 제약 조건 및 확장성 요구 사항을 평가하는 데 도움이 됩니다.
예를 들어 사용자가 작업하는 사례에 대한 업데이트가 있을 때마다 SAP를 Dataverse에 연결하거나 알림을 보내는 것과 같은 높은 수준의 목표가 있다고 상상해 보십시오. 통합을 디자인하기 위한 시작점은 무엇인가요?
첫 번째 단계는 요구 사항을 통합의 세 가지 주요 구성 요소로 분해하는 것입니다.
볼륨 및 빈도 는 의사 결정 프로세스의 첫 번째 주요 구성 요소입니다. 비즈니스 요구 사항을 구현하는 데 사용해야 하는 도구 종류를 결정하는 데 도움이 됩니다.
다음 구성 요소인 방향성은 데이터가 들어오고 가는 위치를 다룹니다. 방향성을 이해하면 성공적인 통합을 위한 패턴을 설정하는 데 도움이 됩니다.
기능 또는 각 시스템의 데이터 수신, 처리 및 전송 기능이 최종 단계입니다. "가장 약한 링크" 접근 방식을 사용하여 기능을 평가하여 제한 사항 및 가능성을 식별합니다.
볼륨 및 빈도
이 차원은 전송되는 데이터의 양과 빈도를 정의합니다. 볼륨과 빈도가 함께 작동하여 통합 아키텍처를 형성합니다. 유사하게 표시될 수 있지만 고유한 방식으로 솔루션 디자인에 영향을 미칩니다. 다음 구성 요소는 볼륨과 빈도가 상호 작용하고 통합 결정에 미치는 영향을 자세히 설명합니다.
볼륨과 빈도 비교
두 가지 통합 시나리오에는 시간당 60,000개의 레코드와 분당 1,000개의 레코드와 같은 총 볼륨이 포함될 수 있지만 빈도는 다릅니다. 둘 다 동일한 시간당 볼륨과 같지만 분당 예상은 솔루션 디자인을 변경합니다.
- 하나의 솔루션이 둘 다에 맞는다고 가정하지 마세요.
- 더 높은 빈도 부하를 처리하는 시스템의 기능의 유효성을 검사합니다.
- 한 패턴이 리소스를 많이 사용하거나 거의 사용되지 않는 경우 별도의 솔루션을 빌드하는 것이 좋습니다.
트리거 유형
트리거는 통합이 실행되는 방법과 시기를 정의합니다. 예측 가능성 및 시스템 부하에 따라 올바른 트리거를 선택합니다.
"Batch"라고도 하는 예약된 트리거:
- 고정된 간격으로 실행합니다.
- 예측 및 관리가 더 쉽습니다.
- 안정적인 데이터 증가 패턴에 적합합니다.
이벤트 기반 트리거: 이벤트는 단추 선택, 시스템 중 하나의 레코드 변경 또는 API 호출일 수 있습니다.
- 사용자 작업 또는 시스템 이벤트를 기반으로 시작합니다.
- 예측하기가 더 어렵습니다.
- 특히 공용 시스템에서 예기치 않게 급증할 수 있습니다.
Seasonality
데이터 볼륨은 비즈니스 주기에 따라 변동합니다. 예약된 통합과 이벤트 기반 통합 모두에서 계절별 급증을 계획합니다.
- 월별 또는 분기별 청구 주기로 인해 예측 가능한 급증이 발생할 수 있습니다.
- 세금 시즌 또는 공공 서비스 마감일은 예측할 수 없는 급증을 일으킬 수 있습니다.
- 사용량이 많은 기간 동안 오버로드를 방지하기 위한 안전 장치를 구현합니다.
이해 관계자 공동 작업
프로세스 소유자 및 비즈니스 사용자와 볼륨 및 빈도를 논의합니다. 실제 워크플로에 대한 가정의 유효성을 검사합니다.
- 비즈니스 사용자는 전체 프로세스를 모를 수 있습니다.
- 설계자는 운영 현실을 조사하고 확인해야 합니다.
미래 계획
성장을 염두에 두고 통합 솔루션을 설계합니다.
- 운영 조건을 명확하게 정의합니다.
- 장기 확장성 계획을 포함합니다.
- 크기 조정이 필요한 시기를 예측합니다.
방향성
방향성은 시스템 간의 데이터 흐름을 정의합니다. 통합을 구성하고 실행하는 방법을 구체화하기 위해 데이터가 시작되는 위치와 전달되는 위치를 정의합니다. 데이터 흐름의 방향을 결정할 때 안정적이고 안전한 작업을 보장하기 위해 시스템 가용성, 규정 준수 요구 사항 및 보안 조치를 고려합니다. 예를 들어 데이터는 항상 사용할 수 없거나 엄격한 규정 준수 및 보안 규정의 적용을 받을 수 있는 프라이빗 시스템에서 제공될 수 있습니다.
관련자 및 규정 준수
규정 준수는 통합 디자인에서 중요한 역할을 하며 시스템마다 다릅니다. 연결이 조직의 보안 및 규정 표준을 충족하는지 확인하려면 인프라 설계자 및 보안 담당자와 상의하세요.
- 높은 보안 환경에서는 통합 아키텍처에 영향을 주는 엄격한 액세스 제어를 적용하는 경우가 많습니다.
- 레거시 온-프레미스 시스템은 인바운드 연결을 제한할 수 있습니다. 이러한 경우 레거시 시스템이 클라우드 애플리케이션과의 통신을 시작할 수 있도록 통합을 디자인합니다.
Capability
통합 성능은 관련된 각 시스템의 기능에 따라 달라집니다. 체인에서 가장 약한 시스템은 전체 결과를 제한합니다.
- 비즈니스 요구 사항에 따라 시스템 기능을 평가합니다.
- 고주파 또는 대용량 데이터 전송에 영향을 줄 수 있는 병목 상태를 식별합니다.
- 시스템이 성능 기대치를 충족할 수 없는 경우 향상된 기능을 고려합니다.
기능 및 빈도
빈도는 시스템에서 데이터 전송을 처리하는 정도에 영향을 줍니다. 하루에 한 번 성능이 좋은 시스템은 매일 여러 번 부하가 걸릴 경우에 실패할 수 있습니다.
- 시스템 기능을 필요한 빈도에 맞춥니다.
- 볼륨만으로도 타당성이 결정된다고 가정하지 마세요.
Caching
캐싱은 시스템이 성능 요구 사항을 충족할 수 없는 일반적인 솔루션입니다.
- Dataverse용 Azure Synapse Link와 같은 도구를 사용하여 확장 가능한 스토리지에 데이터를 복제합니다.
- 단점 이해: 캐싱은 응답 시간을 개선하지만 오래된 데이터를 제공할 수 있습니다.
- 실시간 프로세스에서 부정확한 결과를 방지하기 위해 데이터가 최신 상태로 유지되도록 합니다.
변환 및 비즈니스 논리
시스템 기능에는 비즈니스 요구 사항을 충족하기 위해 필요한 변환 및 비즈니스 논리를 수행하는 기능이 포함됩니다.
- 각 시스템이 데이터 전송 전, 도중 및 후에 수행할 수 있는 작업을 평가합니다.
- 원본 데이터, 변환 요구 사항 및 대상 시스템 처리의 복잡성을 고려합니다.
예를 들어 저장 프로시저가 있는 SQL 뷰를 Dataverse로 내보내려면 비행 중 적응 및 도착 후 플러그 인 실행이 필요할 수 있습니다.
역량 관련자
시스템 관리자는 시스템 기능에 대한 인사이트를 제공합니다. 중앙 집중식 또는 탈중앙화 IT 팀과 협력하여 가정의 유효성을 검사합니다.
- 통합 패턴을 선택하기 전에 각 시스템을 평가합니다.
- 기술 기능이 비즈니스 기대에 부합하는지 확인합니다.
전부 합치세요
효과적인 통합 디자인은 세 가지 핵심 구성 요소를 이해하는 것부터 시작합니다. 요약:
- 볼륨 및 빈도 는 전송되는 데이터의 양과 빈도를 정의합니다. 이러한 메트릭은 도구 선택, 성능 기대치 및 확장성 계획에 영향을 줍니다.
- 방향성은 데이터의 원본 및 대상을 식별합니다. 시스템 간에 데이터가 흐르는 방식을 결정하고 보안 및 규정 요구 사항을 준수하는지 확인하는 데 도움이 됩니다.
- 접근 권한 값은 각 시스템의 데이터 전송, 수신 및 처리 기능을 측정합니다. 성능 제한을 강조 표시하고 통합 프로세스에서 잠재적인 병목 상태를 식별하는 데 도움이 됩니다.
각 구성 요소는 초기 비즈니스 요구 사항에 직접 매핑됩니다. 관련자와 함께 볼륨, 빈도, 방향성 및 기능이 전체 통합 프로세스에 미치는 영향을 분석합니다.
이해 관계자 협업은 분석하는 동안 필수적입니다. 해당 입력은 통합 접근 방식을 재구성할 수 있습니다.
- 프로세스 소유자는 초기 비즈니스 요구 사항을 제공합니다.
- 인프라 설계자 및 보안 책임자는 규정 준수 및 보안 연결을 보장합니다.
- 시스템 관리자는 시스템 기능 및 제약 조건을 평가합니다.
예제 시나리오
예제 시나리오를 통해 모든 것을 함께 살펴봅시다. 비즈니스 요구 사항은 사례 작업을 하는 외부 고객과 내부 서비스 엔지니어 간에 사례 정보를 동기화하는 통합 프로세스를 만드는 것이라고 상상해 보십시오. 고객은 웹 사이트를 통해 사례에 의견을 추가할 수 있으며 엔지니어는 Power App을 통해 사례 정보를 추가할 수 있습니다.
요청 볼륨 및 트리거 빈도
볼륨 및 빈도는 시스템이 전송하는 데이터의 양과 전송 빈도를 결정합니다. 이 시나리오에서 고객은 주로 사례 생성을 주도하므로 볼륨은 회사에서 제공하는 고객 수와 예상 성장 궤적에 따라 달라집니다.
업데이트의 총 볼륨은 다음과 같이 계산될 수 있습니다.
[Customers] × [Cases per customer] × [Average updates per case]
차트에서 이 숫자를 시각화하여 시간이 지남에 따라 증가하는 방식을 보여 줍니다. 예를 들어 연간 1,000만 개의 업데이트로 시작하고 매년 20개% 증가할 것으로 예상되는 경우 차트는 전년 대비 업데이트가 꾸준히 증가합니다.
기록 데이터 및 성장 예측을 사용하여 향후 부하를 예측합니다. 예를 들어 시스템이 현재 연간 1,000만 개의 업데이트를 처리하고 매년 20% 증가하는 경우 통합은 5년 동안 연간 2,500만 개의 업데이트를 지원해야 합니다.
빈도 분석에는 월별 최고점이 표시됩니다. 현재 수요가 매월 320만 개의 요청인 경우 향후 수요는 매월 800만 개에 달할 수 있습니다. 이러한 성능 임계값을 충족하도록 통합을 디자인합니다.
일반적인 5년 ROI(투자 수익률) 기간 동안 통합이 유효하도록 하려면 연간 최소 2,500만 개의 요청을 지원하도록 솔루션을 설계합니다. 이 용량 계획은 예상 성장을 고려하며 비즈니스 요구 사항이 진화함에 따라 솔루션을 확장 가능하고 안정적으로 유지하는 데 도움이 됩니다.
볼륨의 빈도 부분은 1년 이내에 정보를 처리하는 시스템의 기능입니다. 다시 한 번 기록 데이터를 차트로 기록하여 빈도가 적용되는 방식을 이해할 수 있습니다.
방향성 및 데이터 흐름
방향성은 시스템 간의 데이터 흐름을 정의합니다. 이 시나리오에는 다음과 같은 4개의 고유한 데이터 스트림이 포함됩니다.
- Dataverse에 사례 업데이트를 작성하는 웹 사이트의 데이터 스트림
- Dataverse에서 업데이트를 읽는 웹 사이트의 또 다른 스트림
- 엔지니어가 Power App에서 Dataverse에 업데이트를 작성하는 세 번째 데이터 스트림
- Power App에서 업데이트를 읽을 최종 데이터 스트림
이 다이어그램은 4개의 고유한 데이터 스트림을 통해 웹 사이트, Dataverse 및 Power App 간에 데이터가 이동하는 방식을 보여 주는 직접 통합 패턴을 보여 줍니다.
이러한 흐름을 이해하면 안전하고 효율적인 통합을 구성할 수 있습니다. 시스템 기능 및 성능 요구 사항에 따라 직접 또는 분리된 패턴을 사용합니다.
작동 중인 기능
이 예제 통합에서 기본 제공 커넥터는 프로세스를 간소화합니다. Dataverse에서 사례 정보를 검색할 때 필터를 적용하고 요청 제한을 설정하여 데이터 검색을 최적화하고 앱에 필요한 데이터만 표시합니다. 웹 사이트의 경우 Power Automate HTTP 트리거 를 사용하여 엔드포인트를 게시하여 데이터를 읽고 쓸 수 있도록 합니다. Power Automate 흐름과 Dataverse의 용량을 평가하여 예상 부하를 지원하는지 확인합니다. 플랫폼 제약 조건을 초과하지 않도록 자동화, 예약 및 인스턴트 흐름의 제한을 검토합니다.
Dataverse Analytics를 사용하여 현재 사용량을 모니터링합니다. Dataverse가 예상 요청 로드에 접근하는 경우 Azure Data Lake 형식으로 보호 버퍼를 추가하는 것이 좋습니다.
이 다이어그램은 읽기 트래픽을 오프로드하고 확장성을 개선하기 위해 Dataverse와 웹 사이트 간에 Data Lake가 도입되는 분리된 읽기 패턴을 보여 줍니다.
이 전략은 Dataverse의 읽기 볼륨을 줄이고 제한 오류(예: HTTP 429 너무 많은 요청)를 방지하는 데 도움이 됩니다.
종속성을 더욱 줄이려면 Azure Service Bus와 같은 큐 서비스를 사용하여 웹 사이트에서 만들기 및 업데이트 요청을 분리합니다.
이 다이어그램은 읽기 및 쓰기가 모두 Data Lake 및 큐를 통해 오프로드되어 안정성을 최대화하고 수요 급증으로부터 Dataverse를 보호하는 완전히 분리된 통합 패턴을 보여 줍니다.
오류를 처리하고, 재시도 논리를 구현하고, 안정성에 대한 모범 사례를 따르도록 클라우드 흐름을 디자인합니다. 통합 패턴을 선택할 때 복잡성을 최소화하면서 비즈니스 요구 사항을 충족하는 솔루션의 우선 순위를 지정합니다. 비용, 라이선스 및 유지 관리 요구 사항과 기술 기능의 균형을 유지합니다. 요구 사항을 충족하고 불필요한 투자를 방지하는 가장 간단한 방법을 선택합니다.
다음 단계
일반적인 패턴을 탐색하여 요구 사항 분석을 실용적이고 확장 가능한 통합 아키텍처로 변환합니다.