統合設計の成功は、ボリュームと周波数、方向性、および機能という 3 つの基本ディメンションを理解することから始まります。 これらのディメンションは、ビジネス要件、システムの制約、スケーラビリティのニーズを評価するのに役立ちます。
たとえば、SAP を Dataverse に接続したり、ユーザーが作業するケースに更新があるたびに通知を送信したりするなどの大まかな目標があるとします。 統合を設計するための出発点は何ですか?
最初の手順では、統合の 3 つの主要なコンポーネントに要件を分解します。
ボリュームと頻度 は、意思決定プロセスの最初の主要なコンポーネントです。 ビジネス要件を実装するために使用する必要があるツールの種類を決定するのに役立ちます。
次のコンポーネントである方向性は、データの流れの行き先を示します。 方向性を理解することは、統合を成功させるためにパターンを設定するのに役立ちます。
最終段階は、各システムがデータを受信、処理、送信する機能または能力を持つことです。 "最も弱いリンク" アプローチを使用して機能を評価し、制限事項と可能性を特定します。
ボリュームと頻度
このディメンションは、転送されるデータの量と頻度を定義します。 ボリュームと周波数が連携して統合アーキテクチャを形成します。 これらは似ているように見えるかもしれませんが、ソリューションの設計に異なる方法で影響を与えます。 次のコンポーネントでは、ボリュームと頻度がどのように相互作用し、統合の決定に影響するかを詳しく説明します。
ボリュームと頻度を比較する
2 つの統合シナリオには、1 時間あたり 60,000 レコード、1 分あたり 1,000 レコードなど、同じ合計ボリュームが含まれる場合がありますが、頻度は異なります。 どちらも同じ時間単位のボリュームですが、分単位の期待値によってソリューションの設計が変わります。
- 1 つのソリューションが両方に適合するとは考えないでください。
- より高頻度の負荷を処理するシステムの能力を検証します。
- 1 つのパターンがリソースを大量に消費するか、ほとんど使用されない場合は、個別のソリューションを構築することを検討してください。
トリガーの種類
トリガーは、統合の実行方法とタイミングを定義します。 予測可能性とシステム負荷に基づいて適切なトリガーを選択します。
スケジュールされたトリガー ("Batch" とも呼ばれます):
- 一定の間隔で実行します。
- 予測と管理が簡単です。
- 安定したデータ拡張パターンに適しています。
イベント ドリブン トリガー: イベントには、ボタン選択、いずれかのシステム内のレコードの変更、または API 呼び出しを指定できます。
- ユーザー アクションまたはシステム イベントに基づいて起動します。
- 予測が困難です。
- 特に一般向けシステムでは、予期せず急増する可能性があります。
Seasonality
データ量は、ビジネス サイクルによって変動します。 スケジュールされた統合とイベント駆動型統合の両方における季節的なスパイクの計画。
- 毎月または四半期ごとの請求サイクルでは、予測可能な急増が発生する可能性があります。
- 税務シーズンや公共サービスの期限により、予測できないピークが生じる可能性があります。
- ピーク期間中の過負荷を防ぐためのセーフガードを実装します。
利害関係者の共同作業
プロセス所有者とビジネス ユーザーとボリュームと頻度について話し合います。 実際のワークフローに対する前提条件を検証します。
- ビジネス ユーザーは、完全なプロセスを知らない可能性があります。
- アーキテクトは、運用上の現実を調査して確認する必要があります。
将来の計画
成長を念頭に置いて統合ソリューションを設計します。
- 動作条件を明確に定義します。
- 長期的なスケーラビリティ プランを含めます。
- スケーリングが必要な場合の見積もり。
方向性
方向性は、システム間のデータフローを定義します。 統合の構成と実行方法を形成するために、データの発生元と配信先を定義します。 データ フローの方向性を決定する場合は、システムの可用性、コンプライアンス要件、セキュリティ対策を考慮して、信頼性とセキュリティで保護された運用を確保します。 たとえば、データは、常に使用できるとは限らないプライベート システムから取得される場合や、厳格なコンプライアンスとセキュリティ規制の対象となる可能性があります。
利害関係者とコンプライアンス
コンプライアンスは統合設計において重要な役割を果たし、システムによって異なります。 接続が組織のセキュリティおよび規制基準を満たしていることを確認するには、インフラストラクチャ アーキテクトおよびセキュリティ責任者に相談してください。
- セキュリティが高い環境では、多くの場合、統合アーキテクチャに影響を与える厳密なアクセス制御が適用されます。
- 従来のオンプレミス システムでは、受信接続が制限される場合があります。 このような場合は、レガシ システムがクラウド アプリケーションとの通信を開始するように統合を設計します。
能力
統合のパフォーマンスは、関係する各システムの機能によって異なります。 チェーン内で最も弱いシステムでは、全体的な結果が制限されます。
- ビジネス要件に照らしてシステム機能を評価します。
- 高頻度または大量のデータ転送に影響する可能性があるボトルネックを特定します。
- システムがパフォーマンスの期待を満たさない場合は、拡張機能を検討してください。
機能と頻度
頻度は、システムがデータ転送を処理する方法に影響します。 1 日に 1 回適切に動作するシステムは、複数の日次負荷の下で失敗する可能性があります。
- システム機能を必要な頻度に一致させます。
- ボリュームだけでは実現可能性が決まらないと想定しないでください。
キャッシュ処理
キャッシュは、システムがパフォーマンス要件を満たさない場合の一般的なソリューションです。
- Azure Synapse Link for Dataverse などのツールを使用して、スケーラブルなストレージにデータをレプリケートします。
- トレードオフを理解する: キャッシュを使用すると応答時間は向上しますが、古いデータが配信される可能性があります。
- リアルタイム プロセスで不正確な結果を防ぐために、データを最新の状態に保ちます。
変革とビジネス ロジック
システム機能には、ビジネス要件を満たすために必要な変換とビジネス ロジックを実行する機能が含まれます。
- 各システムがデータ転送前、転送中、および転送後に実行できることを評価します。
- ソース データ、変換のニーズ、およびターゲット システムの処理の複雑さを考慮してください。
たとえば、ストアド プロシージャを含む SQL ビューを Dataverse にエクスポートするには、フライト中の調整と到着後のプラグインの実行が必要になる場合があります。
ケイパビリティの利害関係者
システム管理者は、システム機能に関する分析情報を提供します。 一元化または分散化された IT チームと連携して、前提条件を検証します。
- 統合パターンを選択する前に、各システムを評価します。
- 技術的な機能がビジネスの期待に沿っていることを確認します。
すべてをまとめる
効果的な統合設計は、3 つのコア コンポーネントを理解するから始まります。 要約すると、次のようになります。
- ボリュームと頻度は、 転送されるデータの量と頻度を定義します。 これらのメトリックは、ツールの選択、パフォーマンスの期待、スケーラビリティの計画に影響します。
- 方向性 は、データのソースと宛先を識別します。 これは、システム間のデータフローを決定し、セキュリティと規制の要件に確実に準拠するのに役立ちます。
- この機能は、 データの送受信、処理を行う各システムの能力を測定します。 パフォーマンスの制限事項が強調され、統合プロセスの潜在的なボトルネックを特定するのに役立ちます。
各コンポーネントは、最初のビジネス要件に直接マップされます。 利害関係者と共に、ボリューム、頻度、方向性、および機能が統合プロセス全体にどのように影響するかを分析します。
利害関係者の共同作業は、分析中に不可欠です。 入力によって統合アプローチを変更できます。
- プロセス所有者 は、最初のビジネス要件を提供します。
- インフラストラクチャ アーキテクトとセキュリティ責任者は、 コンプライアンスとセキュリティで保護された接続を確保します。
- システム管理者は、 システムの機能と制約を評価します。
サンプル シナリオ
シナリオの例を使用して、すべてをまとめてみましょう。 ビジネス要件は、ケースに取り組む外部の顧客と内部サービス エンジニアとの間でケース情報を同期する統合プロセスを作成することです。 顧客は Web サイトを通じてケースにコメントを追加できますが、エンジニアは Power App を使用してケース情報を追加できます。
要求ボリュームとトリガーの頻度
ボリュームと頻度によって、システムが転送するデータの量と転送頻度が決まります。 このシナリオでは、顧客は主にケースの作成を推進するため、ボリュームは、会社がサービスを提供する顧客の数とその予想される成長軌道によって異なります。
更新の合計量は、次のように計算される場合があります。
[Customers] × [Cases per customer] × [Average updates per case]
この数値をグラフで視覚化して、時間の経過と伴う成長を示します。 たとえば、1 年あたり 1,000 万件の更新プログラムから始めて、毎年 20% 増加すると予想される場合、グラフは更新プログラムが年々着実に増加していることを示すはずです。
履歴データと増加予測を使用して、将来の負荷を見積もります。 たとえば、現在、システムが年間 1,000 万更新プログラムを処理し、年間 20% で拡張する場合、統合では 5 年間で年間 2,500 万更新プログラムをサポートする必要があります。
頻度分析は、毎月のピークを示します。 現在の需要が 1 か月あたり 320 万件の要求である場合、将来の需要は 1 か月あたり 800 万に達する可能性があります。 これらのパフォーマンスしきい値を満たすように統合を設計します。
一般的な 5 年間の投資収益率 (ROI) 期間にわたって統合を確実に有効にするには、1 年あたり少なくとも 2,500 万件の要求をサポートするようにソリューションを設計します。 この容量計画は、予想される成長を考慮し、ビジネス ニーズの進化に合わせてソリューションの拡張性と信頼性を維持するのに役立ちます。
ボリュームの頻度部分は、1 年以内に情報を処理するシステムの能力です。 繰り返しになりますが、履歴データをグラフにして、頻度がどのように適用されるかを理解できます。
方向とデータ フロー
方向性は、システム間のデータフローを定義します。 このシナリオには、次の 4 つの異なるデータ ストリームが含まれます。
- ケースの更新を Dataverse に書き込む Web サイトからのデータ ストリーム
- Web サイトが Dataverse から更新プログラムを読み取るための別のストリーム
- エンジニアが Power App から Dataverse に更新プログラムを書き込む 3 番目のデータ ストリーム
- Power App で更新プログラムを読み取る最終的なデータ ストリーム
この図は、Web サイト、Dataverse、Power App の間で 4 つの異なるデータ ストリームを介してデータがどのように移動するかを示す、直接統合パターンを示しています。
これらのフローを理解することは、セキュリティで保護された効率的な統合を構成するのに役立ちます。 システムの機能とパフォーマンスのニーズに基づいて、直接または分離されたパターンを使用します。
実際の能力
この統合例では、組み込みのコネクタによってプロセスが効率化されます。 Dataverse からケース情報を取得する場合は、フィルターを適用し、要求の制限を設定してデータの取得を最適化し、必要なデータのみをアプリに表示します。 Web サイトでは、 Power Automate HTTP トリガー を使用してエンドポイントを発行して、データの読み取りと書き込みを有効にします。 Power Automate フローと Dataverse の両方の容量を評価して、予想される負荷を確実にサポートします。 プラットフォームの制約を超えないように 、自動化された、スケジュールされた、インスタント フローの制限 を確認します。
Dataverse Analytics を使用して現在の使用状況を監視します。 Dataverse が予想される要求の負荷に近づく場合は、 Azure Data Lake の形式で保護バッファーを追加することを検討してください。
この図は、Dataverse と Web サイトの間で Data Lake が導入され、読み取りトラフィックをオフロードし、スケーラビリティを向上させる、分離された読み取りパターンを示しています。
この戦略は、Dataverse からの読み取り量を減らし、調整エラー (HTTP 429 要求が多すぎるなど) を防ぐのに役立ちます。
依存関係をさらに減らすには、 Azure Service Bus などのキュー サービスを使用して、Web サイトからの作成要求と更新要求を切り離します。
この図は、完全に分離された統合パターンを示しています。読み取りと書き込みの両方が Data Lake とキューを介してオフロードされ、信頼性を最大化し、需要の急増から Dataverse を保護します。
エラーを処理し、再試行ロジックを実装し、信頼性の ベスト プラクティス に従うクラウド フローを設計します。 統合パターンを選択する場合は、最小限の複雑さでビジネス ニーズを満たすソリューションに優先順位を付けます。 技術的な機能とコスト、ライセンス、メンテナンスの要件のバランスを取る。 要件を満たし、不要な投資を回避する最も簡単なアプローチを選択します。
次のステップ
要件分析を実用的でスケーラブルな統合アーキテクチャに変換するための一般的なパターンについて説明します。