次の方法で共有

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

  • [アーティクル]

この Power Platform Well-Architected 信頼性チェックリストのレコメンデーションに適用されます:

RE:01 ビジネス目標に合わせてワークロードを設計し、不必要な複雑さやオーバーヘッドを回避します。 実用的かつバランスの取れたアプローチを採用して、望ましい結果をもたらす設計上の決定を下します。 非効率性や潜在的な問題を軽減するために、必要なものを設計に含めます。

このガイドでは、ワークロードをシンプルかつ効率的に維持するために、不要な複雑さとオーバーヘッドを最小限に抑えるためのレコメンデーションについて説明します。 ワークロードの信頼性を最適化するには、必要なワークロード タスクを実行するための最適なコンポーネントを選択します。 開発と管理の負担を軽減するには、プラットフォームが提供するサービスがもたらす効率性を活用します。 この設計は、回復力があり、繰り返しが可能で、拡張でき、管理ができるワークロード アーキテクチャを作成するのに役立ちます。

定義

任期 定義
ワークロード 他のタスクから論理的に分離できる個別の機能またはコンピューティング タスク。

主要な設計戦略

信頼性を高める設計の重要な考え方は、物事をシンプルかつ効率的に保つことです。 ビジネス要件を満たすことに重点を置いてワークロード設計を行い、不必要な複雑さや過剰なオーバーヘッドのリスクを軽減します。 この記事のレコメンデーションを考慮して、無駄がなく、効率的で信頼性の高いワークロードを作成するための設計を決定するのに役立ててください。 ワークロードが異なれば、可用性、スケーラビリティ、データ整合性、ディザスター リカバリーに対する要件も異なる場合があります。

すべての設計上の決定はビジネス要件に基づいて正当化する必要があります。 この設計原則は当たり前の事に思えるかもしれませんが、ワークロードの設計には非常に重要です。 ワークロードは数百万人のユーザーをサポートしていますか、それとも数千人のユーザーをサポートしていますか? トラフィックが大規模に混雑していますか、それともワークロードは安定していますか? どの程度の停止が許容されますか? ビジネス要件によって、これらの設計上の考慮事項が決まります。

トレードオフ: 複雑なソリューションは、より多くの機能と柔軟性を提供できますが、コンポーネントの調整、通信、管理に多くの労力を要するため、ワークロードの信頼性に影響を与える可能性があります。 あるいは、よりシンプルなソリューションでは、ユーザーの期待に完全に応えられない可能性があり、また、ワークロードが進化するにつれて拡張性に悪影響を与える場合もあります。

共同で設計する練習

関係者と協力して以下を行います。

  • ワークロードとそのコンポーネントに重要度レベルを定義して割り当てる。 この練習は、必須コンポーネントと最適なアプローチを決定し、必要な回復力レベルを達成するのに役立ちます。 詳細については、アプリケーションの層の定義を参照してください。

  • 機能要件と非機能要件を定義します。 機能要件は、システムの機能と動作を定義します。 これらはユーザーが指定し、ユース ケースでキャプチャされます。 非機能要件は、システムのパフォーマンスと品質の属性を定義します。 可用性、コンプライアンス、データ保持/データ所在地、パフォーマンス、プライバシー、回復時間、セキュリティ、スケーラビリティなどの非機能要件を必ず理解してください。 これらの要件は、設計上の決定とテクノロジの選択に影響します。

    以下は、経費報告書を処理するワークロードのコンテキストにおける機能要件と非機能要件の例です。

    機能要件 非機能要件
    ワークロードでは、ユーザーが自分の資格情報を使用してログインし、個人データのみにアクセスできるようにする必要があります。 ワークロードは少なくとも 99.9% の時間で利用できる必要があります。
    ワークロードには、未処理、承認済み、および拒否された経費レポートの概要を含むダッシュボードが必要です。 ワークロードは、データ保護とプライバシーに関する関連規制および標準に準拠する必要があります。
    ワークロードは、ワークロード データのバックアップおよび復元操作をサポートする必要があります。 ほとんどのユーザー要求に対して、ワークロードの応答時間は 5 秒未満である必要があります。
    ワークロードは、特定のイベントまたはしきい値がトリガーされたときに、ユーザーと管理者に通知を送信する必要があります。 ワークロードには、転送中および保存中のデータに対して高レベルのセキュリティと暗号化が必要です。

    詳細については、Microsoft Power Platform および Dynamics 365 の要件を満たすというトレーニング モジュールを参照してください。

  • ワークロードをコンポーネントに分割する。 探索および要求収集プロセスでは、ソリューション案を明確化していく必要があります。 ビジネス要件を満たすために、提案されたソリューションを構成する可能性のあるソリューション コンポーネントを特定します。 設計のシンプルさ、効率性、信頼性を優先してください。 ワークロードをサポートするために必要なコンポーネントを決定します。 既定の機能が使用できる場所とカスタム開発が必要な場所を強調表示します。

  • 故障モード解析を使用する 故障と潜在的なリスクがある一時点を特定します。 ビジネスのリスク許容度を明確に理解します。 詳細については、故障モード解析を実行するためのレコメンデーション。

  • ワークフローの可用性と回復のターゲットを定義して、アーキテクチャの決定を報告します。 ビジネス メトリックには、サービス レベル目標 (SLO)、サービス レベル アグリーメント (SLA)、平均復旧時間 (MTTR)、平均故障間隔 (MTBF)、復旧時間目標 (RTO)、復旧ポイント目標 (RPO) が含まれます。 これらのメトリクスの目標値を定義します。 この練習では、各チームの目標がビジネス目標を満たし、現実的であることを確認するために、技術チームとビジネス チーム間の妥協と相互理解が必要になる場合があります。 詳細については、信頼性の目標の定義に関するレコメンデーションを参照してください。 Power Platform SLA は、稼働時間と接続性に関するマイクロソフトのコミットメントです。 サービスごとに SLA が異なり、サービス内の SKU ごとに SLA が異なる場合もあります。 詳細については、オンライン サービスのサービス レベル アグリーメント を参照してください。

その他の設計に関するレコメンデーション

関係者の関与がなくても、次のレコメンデーシを実行できます。

  • 設計にシンプルさと明瞭さを追求する。 コンポーネントとサービスに適切なレベルの抽象化と詳細を使用します。 ソリューションのオーバーエンジニアリングやアンダーエンジニアリングを避けてください。 例:

    • Power Automate を使用してプロセス自動化の要件を解決する場合、大規模なプロセスを複数の小さなクラウド フローに分割すると、理解、テスト、保守が困難になる場合があります。 一方、すべてを大きなフロー内に保持すると、パフォーマンスと API 呼び出し量に悪影響を与える可能性があります。

    • ユーザー向けの要件を Power Apps で解決する場合、多数のコントロールを備えた大規模なモノリシック キャンバス アプリはパフォーマンスに悪影響を及ぼす可能性があります。 単一のアプリまたはカスタム ページに分割すると、テストが難しくなる場合がありますが、パフォーマンスに大きなプラスの影響を与える場合があります。

  • バグを修正するか、新しい機能やテクノロジを実装するか、既存のシステムをよりスケーラブルで復元力のあるものにするかなど、時間の経過による変化を予測します。

  • 横断的な懸念を別のサービスにオフロードします。 異なる機能間でコードを重複させる必要性を最小限に抑えます。 さまざまなコンポーネントで簡単に使用できる、明確に定義されたインターフェースを備えたサービスを再利用することを優先します。 たとえば、一連のデータ操作をさまざまな場所から実行する必要がある場合は、この機能をローコード プラグインに移動できます。

  • 一般的なパターンとプラクティスがニーズに適しているかどうかを評価します。 状況や要件に最適ではない可能性のあるトレンドやレコメンデーションに従わないようにしてください。 たとえば、カスタム コード コンポーネントの実装は、複雑さ、オーバーヘッド、依存関係の問題が発生する可能性があるため、アプリケーションによっては最適なオプションではない場合があります。

適度なコードを開発する

シンプルさ、効率性、信頼性の原則は、開発手法にも適用されます。 次のレコメンデーションを検討してください。

  • プラットフォーム機能がビジネス要件を満たす場合は、それを使用します。 例:

    • 独自のコード コンポーネントを開発する代わりに、最新のコントロールを使用して、Fluent 2 設計標準を達成します。
    • カスタム コネクタを開発する代わりにネイティブ コネクタを使用して、カスタム コードを減らします。
    • Microsoft Copilot Studio で生成された回答を使用すると、エージェントが手動で作成したトピックなしで、社内外の複数のソースから情報を検索し、提示できるようになります。

  • 開発プラクティスとして専用のコード レビュー セッションを導入します。

  • デッド コードを特定するアプローチを実装します。 自動テストでカバーされていないコードには疑いを持ちましょう。

  • 開発チームのスキル セットを考慮してください。 新しいスキルを習得したり、新しいテクノロジを導入したりするには時間がかかります。

データの保存場所を考慮する

アーキテクチャ設計の一環として、データを保存する方法、または読み取りアクティビティのためにデータを取得する方法を検討する必要があります。 データは、さまざまな方法で取得され保管されます。

  • 新しいデータ: 既存のビジネス プロセスが紙で行われてた場合など、まだ存在しないデータをアプリで作成する場合、Microsoft Dataverse にデータを保存することをお勧めします。

  • 既存のシステムからの読み取り/書き込み: アプリで既存のデータベースまたはシステムからデータを取得する必要がある場合は、すぐに使用できるコネクタ、カスタム コネクタ、または仮想テーブルを使用して、データベースやシステムに接続する最適な方法を評価する必要があります。

  • データのコピーを作成する: 元のデータを変更または上書きしてはならない状況では、Dataverse などの別のデータ ストアにデータをコピーできます。 この方法では、元のシステムのデータは変更されずに維持されますが、アプリはそのデータを操作できます。 このシナリオは、会計システムや収益関連システムでデータを操作する場合に一般的です。 データのコピー方法、更新頻度、双方向同期が必要かどうかを考慮する必要があります。

Power Platform の促進

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

信頼性チェックリスト

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

信頼性チェックリスト