次の方法で共有

シンプルさと効率性を考慮した設計に関するレコメンデーション

  • [アーティクル]

この Power Platform Well-Architected Reliabilityチェックリストの推奨事項に適用されます:

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 の促進

実用的な設計アドバイスについては、次の記事を参照してください。

信頼性チェックリスト

完全なレコメンデーションのセットを参照してください。

信頼性チェックリスト