次の方法で共有

Dataverse と、財務と運用アプリのストレージ管理

組織がデジタルトランスフォーメーションを加速させるにつれて、データを効果的に管理する能力が戦略的なビジネス上の必須事項になります。 AI を活用したアプリケーションや Copilot を活用したワークフローの台頭により、企業はかつてない速度でデータを生成および消費しています。 このデータはイノベーションを促進し、パーソナライズされたエクスペリエンスを可能にし、重要な意思決定をサポートしますが、それはインテリジェントに管理および保存されている場合に限ります。

これらの進化するビジネスニーズをサポートするために、組織はプロアクティブなストレージ管理戦略を採用する必要があります。 これにより、日常業務に不要になったデータが責任を持って処理され、価値の高いワークロードのために容量が解放され、運用上の摩擦が軽減され、コンプライアンスと監査の要件に準拠できるようになります。

技術的な観点から、Dataverse と Dynamics 365 の効果的なストレージ管理は、システムのパフォーマンスを向上させ、コスト効率を改善し、長期保存 (LTR) ポリシーの遵守を保証します。 どちらのプラットフォームも、組織が ストレージ を管理できるようにするツールと自動化機能を提供します。

この記事で概説した戦略を実装することで、企業はサポートのオーバーヘッドを削減し、コンプライアンスを合理化し、ビジネスアプリケーションからより大きな価値を引き出し、ストレージを制約から競争上の優位性に変えることができます。

主な利点

技術的な観点から、Dataverse と Dynamics 365 の効果的なストレージ管理は、システムのパフォーマンスを向上させ、コスト効率を改善し、長期保存 (LTR) ポリシーの遵守を保証します。

  • LTR 遵守率の向上: 効果的なストレージ管理により、データが LTR ポリシーに準拠した保存を促進します。 これにより、規制要件を満たすだけでなく、重要なデータを保存し、必要なときにアクセスできるようになります。

  • パフォーマンスの向上: ストレージ管理を最適化することで、企業はシステムのパフォーマンスを大幅に向上させることができます。 効率的なストレージ割り当てと管理により、レイテンシーが削減され、データ取得の速度が向上し、よりスムーズで高速な運用が可能になります。

  • コスト効率の向上: 効果的なストレージ管理により、企業はストレージ環境を合理化し、整理することで、価値の高いデータに集中することができます。 必要なものだけを保持することで、企業はストレージフットプリントを最適化でき、よりスマートなリソース活用と費用対効果の高いスケーラビリティにつながります。

経歴

組織が成長し、業務のデジタル化が進むにつれて、Dataverse や Dynamics 365 などのシステムに保存されるビジネス データの量は着実に増加しています。 これには、アクティブなトランザクション データだけでなく、監査、規制、または事業継続の目的で保持する必要がある履歴記録も含まれます。 時間の経過とともに、この蓄積はパフォーマンスの低下、運用オーバーヘッドの増加、ストレージコストの上昇につながる可能性があります。特に、アクティブに使用されなくなったデータが高パフォーマンスのストレージ層に残っている場合です。

明確に定義されたストレージ管理戦略は、アーカイブ、クリーンアップ、または低コストで読み取りに最適化されたストレージへの移動が可能なデータを特定することで、組織がこれらの課題に対処するのに役立ちます。 これは、財務記録、監査ログ、規制当局への提出書類など、データを不変、低いアクセス、読み取り専用に保つ必要があるコンプライアンス シナリオにとって重要です。 このようなデータが、実稼働システムのパフォーマンスに影響を与えることなく、コンプライアンスに準拠した方法で保持されるようにすることは、多くの企業にとって重要な要件です。

両方のプラットフォームで利用可能なツールと戦略を使用することで、組織はストレージフットプリントの可視性を高め、不要な消費を削減し、コンプライアンスクリティカルなデータが適切に処理されるようにすることができます。

この記事では、お客様がデータ保持のプラクティスをビジネスおよび規制のニーズに合わせるのに役立つ、ストレージ管理への実践的なアプローチについて概説します。 これにより、システムパフォーマンスが向上し、運用上のオーバーヘッドが削減され、妥協することなくコンプライアンス義務が満たされます。

データを保存する理由

データに適したデータ保持パターンを選択して最適化するには、データを保存する理由と用途を熟考することが重要です。

業務データ

ビジネス アプリケーションでは、運用データは、営業、財務、またはサプライ チェーンのアクションを追跡するために使用されます。

このデータにリアルタイムでアクセスし、顧客との対話、注文、在庫活動などのきめ細かなアクションを記録する顧客および内部の運用プロセスをサポートする必要があります。

時間の経過とともに、運用データはアクティブな使用から使用頻度の低いものへと移行する可能性があります。 注文やサポートケースで顧客を支援するために、ほぼリアルタイムでデータにアクセスできる必要がある場合があります。 たとえば、次のようなシナリオが考えられます。

  • 顧客が注文を行い、しばらくビジネスとやり取りしていない別の顧客が注文を行います。
  • 発注され、出荷される注文は、常にアクセスされています。 また、3年間の保証期間内の注文もあり、サポートのために参照する必要があり、返金が必要になる場合があります。

これにより、次のような運用データ アクセスのニーズのフェーズが発生する可能性があります。

  • 1 年未満のアクティブにアクセスされるデータ。
  • アクセス頻度の低いデータが 3 年未満である。
  • データが運用上アクセスされなくなった 3 年以上。

運用ストレージはリアルタイムという性質上、他のストレージに比べて比較的高価です。そのため、運用上データにアクセスする必要があるときとないときを認識することは、リテンション戦略を定義する上で重要です。

運用統合

運用上の使用の特殊なカテゴリとして、次のようなパターンを含む複数の運用システム間でデータをレプリケートする必要がある場合があります。

  • 銀行業務: 顧客との最前線でのやり取りと、複数の銀行システムへのレプリケーションのための顧客関係管理。 たとえば、当座預金、クレジット カード、住宅ローン、信用調査システムがあるとします。
  • 製造: 最前線での受注活動のための顧客関係管理と、サプライチェーン管理のための企業資源管理システム。
  • 警察の緊急時対応: 市民との交流のための顧客関係管理、警察署のための派遣システムは、配備管理を提供します。

このような場合、各システムには追跡する固有のデータがあるかもしれませんが、多くの場合、システム間で共有して同期を維持する必要がある共通のマスター データがあり、統合の必要性につながります。

監査データ

企業は通常、財務監査、規制当局による開示、不正調査のサポートなど、内部または外部を問わず、監査目的でデータを長期間 (たとえば平均 7 年間) 保持する規制上の責任を負っています。

このデータは通常、運用目的に必要なデータと不要になったデータの両方にまたがり、データ セット全体を 1 か所から確認できます。

分析データ

組織は、ビジネスの状態を確認して分析する必要があります。 長期にわたる統計の測定と比較が必要です。また、事業の複数またはすべての部分にまたがって測定し、比較する必要があります。

この分析の対象となるデータの期間と幅が広いため、業務データを専用の分析ツールに複製する必要があります。 これにより、複雑な分析が運用システムのパフォーマンスに影響を与えるのを回避できるだけでなく、運用上データが必要な期間を超えてデータセット全体を分析することもできます。 たとえば、1 年から 2 年ではなく 7 年間のデータを比較する必要がある場合があります。 ただし、分析のニーズが異なれば、完全なデータ保持期間が必要な場合もあれば、運用システムに保持されるデータのみにまたがる場合もあります。

分析データでは、通常、ビジネスの複数の部分にわたるデータを集約し、複数のシステムからのデータを結合できます。

データの流れ

次の図に示すように、これらのタイプのデータは通常、時間の経過とともに運用データからトランザクション データまたは履歴データに流れます。

データのフロー。

さまざまなタイプのストレージ

Dataverse ストレージのタイプ

Dataverse では、ストレージを 3 つの主要なカテゴリーに分類しており、それぞれに明確な使用パターンと課金の意味合いがあります。

ストレージの種類 プロパティ 一般的なユース ケース
データベース ストレージ 構造化されたデータをテーブル (標準とカスタム) に格納します。 ビジネス レコード、メタデータ、リレーションシップ、および構成
ファイル記憶域 添付ファイルとバイナリ データを格納します。 メールの添付ファイル、画像、Power Apps を介してアップロードされたドキュメント
ストレージのログ 監査ログとプラグイントレースログを格納します。 変更の追跡、監査、診断、コンプライアンス

財務と運用プラットフォームのストレージ タイプ

財務と運用のストレージは別々に管理されていますが、Power Platform エコ システムに統合されるケースが増えています。 これには、次の ストレージ タイプが含まれます。

ストレージの種類 プロパティ 一般的なユース ケース
オペレーショナル データベース ストレージ 財務、サプライ チェーン、人事などのコア トランザクション データ 元帳エントリ、在庫、顧客注文
ドキュメント管理ストレージ Azure Blob ストレージに格納されたバイナリ ラージ オブジェクト (BLOB) 請求書、領収書、スキャンした文書
利用統計情報 と診断ログ システムログと利用統計情報データ パフォーマンスの監視、問題の診断。

共有および統合された ストレージ シナリオ

  • 二重書き込み ストレージ

    • Dataverse と財務と運用アプリケーション間のリアルタイム同期を可能にします。
    • 重複や過度の使用を避けるために、慎重な ロール と容量管理が必要です。

  • 長期保有 (LTR)

    • 過去のデータをマネージド データ レイク (MDL) に移動します。
    • プライマリ ストレージ の使用量を削減しながら、コンプライアンスと分析へのアクセスを維持します。
    • 次と統合されます:
      • 簡易検索 (Dataverse ネイティブ検索)
      • OneLake (ファブリックベースの分析)
      • Synapse Link (カスタムレイク分析)

時間の経過に伴うデータの増加

企業が Dataverse と Dynamics 365 財務と運用プラットフォームの利用を拡大するにつれ、データの増加は成功の証であると同時に戦略的な課題でもあります。 無駄のないトランザクション データセットとして始まったものが、複雑な多層データ資産に急速に進化する可能性があります。 このセクションでは、データ増加の 5 つの主要な要因と、ストレージ、パフォーマンス、ガバナンスへの影響について説明します。

業務データに対するデータウェアハウスの使用

業務システムから分析情報を引き出すため、多くの組織は Azure Synapse リンク、OneLake、またはデータ エクスポートを使用して、Dataverse および財務と運用アプリから分析システムにデータを複製します。 これは高度なレポートや AI ワークロードをサポートする一方で、次のようなことももたらします:

  • 運用レイヤーと分析レイヤーにわたる冗長ストレージ

    運用環境と分析環境の間でデータが重複することがよくあります。 この冗長性により、全体的な ストレージ 消費量が増加し、特に履歴データが両方のシステムに無期限に保持されている場合は、コストが高くなる可能性があります。

  • スキーマの重複とバージョン管理のオーバーヘッド

    システム間の一貫性を維持するには、スキーマの変更 (新しいフィールドや列の名前変更など) を運用レイヤーと分析レイヤーの両方にレプリケートする必要があります。 これにより、データガバナンスが複雑になり、スキーマドリフトのリスクが高まり、ダウンストリームのレポートやモデルが壊れる可能性があります。

  • トレンド分析のための履歴データ保持の増加

    分析システムは通常、傾向分析、予測、および規制レポートをサポートするために、データを長期間保持します。 価値があるものである一方、適切なアーカイブと階層化戦略で管理しなければ、このような長期保存はデータセットの肥大化につながります。

データウェアハウスは分析に不可欠ですが、ライフサイクルポリシーがなければ、ストレージフットプリントが2倍または3倍になる可能性があります。

データ検索の使用

Dataverse 検索、Copilot インデックス、関連検索などの機能には、大量の構造化データと非構造化データのインデックス化が必要です。 これらのインデックスは、多くの場合、次のことを行います。

  • ログとデータベース ストレージの消費

    検索インデックスは、ログとデータベース ストレージ の両方に格納されます。 検索可能としてマークされるテーブルやフィールドが増えると、それに比例してインデックスのサイズも大きくなります。 これは、特に大量のレコードや頻繁なスキーマ変更がある環境で、全体的な ストレージ の使用に大きな影響を与える可能性があります。

  • 未使用または非推奨のテーブルでも保持する

    特定のテーブルが非推奨になったり、アクティブに使用されなくなったりした場合でも、明示的に削除されない限り、関連する検索インデックスは保持されます。 これにより、不必要な ストレージ の消費が発生し、容量計画が複雑になる可能性があります。

  • 開発環境、テスト環境、運用環境など、環境間で重複することが多い

    検索インデックスは、通常、開発、テスト、および運用環境間でレプリケートされます。 これにより、一貫した検索動作が保証されますが、特に環境が頻繁に複製または更新される場合は、ストレージ フットプリントも倍増します。

検索はユーザビリティと AI 対応を改善しますが、インデックスの肥大化は ストレージ 超過の無言の原因となります。

データのログ記録の有効化

監査ログ、プラグイン トレース ログ、利用統計情報 は、コンプライアンス、デバッグ、および監視にとって重要です。 ただし、次の点に注意してください:

  • ストレージのログは、使用量とユーザー数に比例して増加します。

    ログデータは、次のことに比例して増加します。

    • ユーザー数とその活動レベル
    • トランザクションと統合の量
    • プラグインやワークフローなどのビジネスロジックの複雑さ

    使用率の高い環境では、これによりログ テーブルが急速に拡張され、データベースとログ ストレージ の両方のクォータが消費される可能性があります。

  • 既定の保存期間は、寛大すぎる傾向があります (90 日など)。

    既定では、多くのログ機能は、90 日以上など、長期間データを保持します。 これにより長期的なトレーサビリティがサポートされますが、特にログが積極的にレビューまたはエクスポートされていない場合、不要な ストレージ 消費が発生する可能性があります。

  • システムで生成されたログは、Dataverse で顧客に請求されます。

    Dataverse では、監査ログやプラグイン トレース ログを含むシステム生成ログは、顧客のストレージ権限にカウントされます。 つまり、適切なクリーンアップまたはエクスポート戦略を行わないと、ログ記録は ストレージ の超過とライセンス コストの増加に直接貢献する可能性があります。

ログ記録は、規制対象の業界では交渉の余地がありませんが、Azure Monitor や Log Analytics などの保持およびエクスポート戦略と組み合わせる必要があります。

運用環境のコピーを複数用意する

開発、テスト、トレーニング、トラブルシューティングをサポートするために、お客様は多くの場合、サンドボックス環境または複製環境を作成します。 各コピー:

  • 完全なデータとインデックスのフットプリントをレプリケートします。
  • 検索インデックス、監査ログ、メタデータなど、明白でない依存関係が含まれる場合があります。
  • 使用後に後片付けされることはめったにありません。

環境の無秩序な増加は、ストレージコストと複雑さの主な要因です。 ガバナンス ポリシーと自動化が封じ込めの鍵です。

データに対するクエリの最適化

データ量が増加し、アプリケーションの応答性が重要になるにつれ、顧客や ISV は、Dataverse や Dynamics 365 のパフォーマンスを向上させるために、さまざまなクエリ最適化技術を実装することが多くなります。 これらの戦略は、レポート、分析、および統合を多用するシナリオで特に一般的です。

パフォーマンスを向上させるために、顧客と ISV は多くの場合、次のものを作成します。

  • カスタム インデックスと具体化されたビュー

    これらは、結合または集計を事前に計算することにより、クエリの実行を高速化するために使用されます。 これらは、複雑なフィルターや大規模なデータセットを含むシナリオで役立ちます。

  • レポート用の非正規化されたテーブル

    レポートを簡素化し、クエリの複雑さを軽減するために、開発者は多くの場合、リレーショナル データのフラット バージョンを作成します。 これらのテーブルにより、ランタイム結合の必要性が減り、ダッシュボードのパフォーマンスが向上します。

  • レイヤーまたは集計のキャッシュ

    頻繁にアクセスされるデータは、プライマリ データベースの負荷を軽減するために、事前に集計されたり、中間テーブルや外部ストアにキャッシュされたりすることがあります。

これにより応答性が向上しますが、次の点も考慮してください:

  • ストレージ使用率の増加

    各最適化レイヤーでは、非正規化された形式の既存データのコピー、事前計算済みビュー、キャッシュテーブルなど、より多くのデータ構造が導入されます。 これらの構造は、すでに別の場所に保存されているデータと重複することが多く、全体的なストレージフットプリントが大きくなります。 Dataverse のように、厳しいストレージ クォータやコスト ベースのライセンス モデルを持つ環境では、これはすぐに回避可能な超過分にエスカレートする可能性があります。

  • アプリの進化に伴って孤立する可能性がある

    アプリケーションが進化するにつれて、一部の最適化成果物は、アクティブ・レポート、ダッシュボード、または統合によって参照されなくなる可能性があります。 これらの孤立化したオブジェクトは、識別して削除しなければ、ストレージを消費しつづけ、バックアップやインデックス作成時など、システムの動作を遅くする可能性さえあります。 定期的な監査がなければ、気づかないうちに蓄積され、サポートするために作成されたパフォーマンスの向上そのものが損なわれる可能性があります。

クエリの最適化はスケールに不可欠ですが、ストレージの衛生や遠隔測定に基づくチューニングとのバランスを取る必要があります。

インデックスと ストレージ への影響

インデックスは、クエリのパフォーマンスを向上させ、大規模なデータセットで高速なデータ取得を使用するために不可欠です。 Dataverse と Dynamics 365 の財務と運用アプリケーションでは、主キーと頻繁にクエリされるフィールドに対してインデックスが自動的に作成されます。その他のカスタム インデックスは、特定のビジネス シナリオをサポートするために定義することができます。

インデックスはパフォーマンスにとって重要ですが、ソリューション設計時に過小評価されがちな ストレージ の消費にも直接影響します。

インデックスが ストレージ を使用する方法

  • データの物理的な複製: 各インデックスは、インデックスされた列のコピーと、対応する行へのポインタを格納します。 インデックスが付けられる列と行が多いほど、インデックス サイズは大きくなります。

  • データ量の増加: 基になるテーブルが大きくなると、インデックスも大きくなります。 トランザクションの多い環境では、特に大きな非正規化されたテーブルや、挿入や更新が頻繁に行われるテーブルでは、インデックスが急速に大きくなる可能性があります。

  • テーブルごとに複数のインデックス: 検索、フィルター、ソート、結合などの目的で、1 つのテーブルに複数のインデックスを持つことはよくあります。 それぞれのインデックスは、累積的なストレージ フットプリントに追加されます。

  • Dataverse の検索インデックス: Dataverse 検索や Copilot インデックスなどの機能により、複数のフィールドやテーブルにまたがる特殊なインデックスが作成されます。 これらは DataverseSearch テーブルに格納され、特に開発環境、テスト環境、運用環境など複数の環境で使用する場合、大きな容量を消費する可能性があります。

  • システム生成インデックス: ルックアップ フィールドやリレーションシップなど、プラットフォームが自動的に作成するインデックスもあります。 これらは、明示的に削除されない限り、関連するテーブルが非推奨になった場合でも存続する可能性があります。

ストレージの影響

  • データベースとログ ストレージの増加: インデックスは、データベースとログの両方のストレージ使用量に貢献し、Dataverse のライセンス コストに影響を与える可能性があります。
  • 環境の重複: 環境がコピーまたは更新されると、すべてのインデックスが複製されるため、開発、テスト、運用環境全体でストレージの使用量が増大します。
  • メンテナンスのオーバーヘッド: インデックスをデータの変更に合わせて更新する必要があるため、書き込みレイテンシやリソースの消費量が増加する可能性があります。

サーバー側同期が ストレージ に与える影響

Dataverse のサーバーサイド同期により、Microsoft Exchange と Dataverse 間のメール、予定、タスクのシームレスな統合が可能になります。 生産性と自動化を向上させると同時に、次のようにストレージ消費にも貢献します。

  • 活動レコードの作成: 各同期された電子メールまたは予定は、メタデータ、本文、添付ファイルの可能性を含む Dataverse の活動レコードを生成します。
  • 添付ファイル ストレージ: 添付ファイルがフィルターやオフロードされない場合、Dataverse に直接保存されるため、ストレージの使用量が増えます。
  • コンプライアンスと保持: コンプライアンス追跡のためにサーバーサイド同期を使用している組織は、必要以上のデータを保持し、ストレージをさらに膨張させる可能性があります。
  • 保護されたコンテンツ: Purview で保護されたメールでも、コンテンツの可視性は制限されるものの、プレースホルダー レコードが生成され、スペースを消費します。

この影響を管理するには、企業は保持ポリシーを実装し、添付ファイルのオフロードを検討し、アクティビティ レコードの量を定期的に監視する必要があります。

増え続けるストレージをどのように管理できますか?

既にストレージの超過分に直面している場合でも、超過分を回避することを目標としている場合でも、Dataverse と Dynamics 365 財務と運用プラットフォームにおけるデータ増加の管理には、意図的でポリシー主導のアプローチが必要です。 このセクションでは、事後対応型の修復と予防的なガバナンスという 2 つの戦略的エントリ ポイントについて概説します。

考えられるシナリオは 2 つあります:

  1. ベストプラクティスを積極的に適用してストレージを管理し、将来の高コストを回避する必要があります。
  2. あなたはすでにストレージのサイズとコストを削減する必要がある状況にあります。

ベスト プラクティスを適用してストレージのサイズとコストを管理

シナリオ 1: ストレージ を管理するためにベスト プラクティスをプロアクティブに適用する

まだ危機的状況に陥っていないなら、今こそツールとテクニックを適用して、ストレージをプロアクティブに管理する時です。

データの分析を構成する

組織が成長するにつれて、コアビジネスアプリケーションのパフォーマンスに影響を与えることなく、運用データから洞察を抽出する必要性も高まります。 Microsoft は、独自のデータレイクやウェアハウスと統合することで、Dataverse や Dynamics 365 財務と運用のデータを分析できるようにする複数の方法を提供しています。

ここでは、2 つの強力なオプションを紹介します:

オプション 1. Azure Synapse Link の使用 - レイクの持ち込み

Azure Synapse Linkを使用すると、Dataverse を自分の Azure Data Lake または Synapse ワークスペースに直接接続できます。 これにより、複雑なETLパイプラインを書き込むことなく、運用データをほぼリアルタイムで分析環境に複製できます。

メリット:

  • ライブ データまたはライブに近いデータに対して高度な分析と AI モデルを実行します。
  • 運用システムのパフォーマンスへの影響を回避します。
  • レポートには、T-SQL、Spark、Power BI などの使い慣れたツールを使用します。

ユースケースの例: ある小売企業は Synapse Link を使用して、Dataverse の顧客関係管理データと外部の市場データを独自のレイクで組み合わせ、地域間の顧客の購買行動を分析しています。

オプション 2. OneLakeの使用 - Microsoft Fabric との統合分析

Microsoft Fabric の一部である OneLake は、Dataverse や財務と運用アプリを含む複数のソースからのデータを重複することなく保存、分析できる統合データレイク体験を提供します。

メリット:

  • すべての分析ワークロードの一元化されたストレージ。
  • Power BI、Synapse、AI サービスとのネイティブ統合。
  • データドメイン全体のガバナンスとセキュリティの簡素化。

ユースケースの例: ある金融サービス会社では、OneLakeを使用して財務と運用アプリからの運用データと Dataverse を外部の経済指標と統合し、リアルタイムのリスク モデリングとエグゼクティブ ダッシュボードを可能にしています。 これにより、運用データをコアシステムから切り離し、ワークロードの重複やパフォーマンスへの影響なしに、そのデータを独自の分析環境にエクスポートすることで、スケーラブルで費用対効果の高い分析が可能になります。

ストレージを減らすためのツールとテクニック

Dataverse は、管理者がストレージを効率的に管理し、システムのパフォーマンスを維持するのに役立ついくつかの組み込みツールと戦略を提供します

Dataverse

環境とデータのクリーンアップ

  • 環境とデータのクリーンアップ: 環境を削除して記憶域を回復し、個人を特定できる情報 (PII) を削除できます。
  • ジョブの一括削除: 以下のデータを一括削除できます:
    • 古いデータやビジネスに無関係なデータ。
    • 不要なテスト データやサンプル データ。
    • 他のシステムから誤ってインポートされたデータ。

ダイルとテーブルの最適化

長期保存 (LTR) とアーカイブ

検索インデックスの最適化

  • Dataverse 検索の削減: Dataverse 容量ベースのストレージの詳細のすべての手順を実行することにより、ストレージ サイズを小さくすることができます。
  • DataverseSearch テーブルのサイズ縮小: DataverseSearchテーブルは、Dataverse インデックスが使用する累積ストレージです。 これには、環境用にインデックスを作成したテーブルのすべての検索可能、取得可能、フィルター可能なフィールドからのデータが含まれます。 1 つ以上のテーブルの検索列、ビュー列、フィルター条件を削除することで、テーブルのサイズを縮小できます。 Dataverse 検索をオフにして、すべてのインデックス付きデータを削除できます。
財務と運用アプリ

財務と運用アプリケーションは、運用環境とサンドボックス環境にわたってストレージを管理する柔軟なオプションを提供します。

環境管理

  • フル運用コピーの数を制限する: サンドボックス環境でフル運用コピーを削除することで、財務と運用アプリ の全体的な ストレージ 消費量を削減できます。 たとえば、Sandbox に本番環境のコピーが 5 部ある場合、ストレージ 消費量は、本番環境の合計に Sandbox 内の本番環境のコピー 5 部を加えたものになります。
  • サンドボックス環境でデータをトリミング: サンドボックス環境でデータをトリミングすることで、ストレージ全体のフットプリントを削減できます。 以下の方法に従って、サンドボックス内のデータをクリーンアップできます。
    • 復元プロセスでは、オープニングとトリミングを実行します
    • T-SQL の記述
    • 書き込み X++
  • 環境間のトランザクションレス コピーの実行: 財務と運用アプリの環境コピーは、従来、構成、マスター データ、トランザクションを含むデータベースの完全複製が必要でした。これによって、デバッグには便利となりますが、財務と運用と Dataverse の両方でストレージの消費量が大幅に増加します。

カスタム クリーンアップとログ管理

  • 必要に応じてカスタム クリーンアップ ルーチンを作成する: 不要なデータをクリーンアップするために、ビジネスの必要に応じてカスタム クリーンアップ ルーチンを記述できます。
  • ログの保存を避ける: SysDatabaseLog をトランザクションの少ないデータベースに移動して、全体的なストレージ フットプリントを削減できます。

アーカイブと長期保有

組み込みのクリーンアップ ルーチン

  • クリーンアップ ルーチン: Dynamics 365 Finance と Dynamics 365 Supply Chain Management では、クリーンアップ ルーチンがさまざまなモジュールで利用できます。 クリーンアップ ルーチンは、現在利用可能なルーチンの概要を提供します。 サンドボックス データベースをコピーした後、これらのクリーンアップ ルーチンをプロアクティブに実行して、バッチ履歴、ログ、小売トランザクション履歴などの不要なテーブルを削除します。 古いデータや無関係なデータを削除します。
  • クレジットカード取引データのアーカイブ: クレジットカードの支払いトークンをアーカイブすることで、データベースのスペースを解放できる Dynamics 365 Commerce のアーカイブ ジョブについて説明します。

ストレージのサイズとコストを削減します

シナリオ 2: ストレージのサイズとコストの削減が必要な状況にある場合

ストレージを消費しているものを評価する

  • Power Platform 管理センターと財務と運用のストレージ レポートを使用して、消費量の多いテーブル、ファイル タイプ、ログを特定します。
  • 使用可能な場合は利用統計情報を使用して、使用状況を特定のアプリ、ユーザー、または部署に帰属させます。

クリーンアップ候補の優先順位付け

  • フォーカス対象:
    • ステージング・テーブルと統合テーブル (二重書き込みバッファーなど)
    • 監査ログ: 独自のストレージに保持します
    • 未使用の環境またはサンドボックス
    • 孤立したメタデータと検索インデックス
    • 不要なものを削除します (一括削除など)

分析レポートに Synapse Link と OneLake を使用する

  • 分析データを Synapse Link にエクスポートします。
  • OneLake を使用して、レポートと分析の目的で保持データとビジネス データにアクセスします。

長期保有 (LTR) の適用

  • LTR ポリシーを使用して履歴データを マネージド Data Lake (MDL) に移動します。
  • クイック検索、Synapse Link、または OneLake による検索と分析へのアクセスを維持します。

ユース ケース

Dataverse や財務と運用環境におけるストレージ管理の使用用途は、データベース スペースの最適化、システム パフォーマンスの向上、規制要件への対応に不可欠です。 以下は、これらの戦略の適用方法を示すいくつかの一般的なシナリオです。

  • 履歴データの増加の管理

    • シナリオ: ある企業は Dynamics 365 を数年間使用しており、過去のトランザクションや添付ファイルが大量に蓄積されています。
    • アクション: 非アクティブ データを保持し、プライマリ データベースのサイズを縮小し、監査要件へのコンプライアンスを維持するために、長期保有の戦略を導入します。

  • コンプライアンスを重視したデータ保持

    • シナリオ: 規制業界の顧客は、財務データまたは顧客データを改ざんできない形式で 7～10 年間保持する必要があります。
    • アクション: LTR を使用することで、法的および規制上の要件に準拠して、不変の読み取り専用データを保持すると同時に、分析やレポーティングで妥協することなくビジネス データをスリムに保つことができます。

  • 検索と Copilot インデックスの最適化

    • シナリオ: 未使用のテーブルを含め、すべての環境で Dataverse 検索と Copilot インデックスが有効になっています。
    • アクション: 検索可能なフィールドを監査し、価値の低いテーブルや非推奨のテーブルのインデックスを無効にします。 DataverseSearch テーブルのサイズを監視し、構成を最適化して、ログとデータベースの ストレージ を減らします。

  • 監査と利用統計情報の管理

    • シナリオ : プラグインのトレースログと監査ログは急速に増加し、ストレージを消費し、パフォーマンスに影響を及ぼしています。
    • アクション: Azure Monitor などの外部システムにログをエクスポートし、古いエントリのクリーンアップを自動化することで、ストレージを肥大化させることなく可視性を維持できます。

  • データ ウェアハウスと分析の統合

    • シナリオ: 組織では、分析用に運用データを Azure Synapse または OneLake にレプリケートしているため、ストレージが重複しています。
    • アクション: 増分エクスポートを使用し、フィルターを適用し、データセットの完全な複製を避けることで、冗長性を最小限に抑えながら、豊富な分析情報を得ることができます。

  • ストレージ超過分の削減

    • シナリオ : ある顧客が、Dataverse ストレージのクォータ超過に関する通知を受け取り、予期せぬコストが発生しました。
    • アクション: キャパシティ レポートを使用して、消費量の多いテーブルを特定し、廃止された環境をクリーンアップし、使用されていない添付ファイルやログを削除します。 コールド データ (一般的に履歴やアクセス頻度の低いレコード) を低コストのストレージ層に移行することを検討します。

  • 大規模テーブルでのパフォーマンスの最適化

    • シナリオ : ビジネス クリティカルなプロセスが、大規模テーブルのために遅くなっています。
    • アクション: 古い記録をアーカイブし、システムジョブをクリーンアップします (AsyncOperationBase や WorkflowLogBase など)。

  • 環境のライフサイクル管理

    • シナリオ: 開発環境とテスト環境は運用環境からクローン化され、すべてのデータとインデックスが複製されます。
    • 処置: 更新後のサンドボックス環境のトリミング、不要な検索インデックスの無効化、テスト データの削除により、冗長なストレージの消費を削減します。 未使用のサンドボックス環境を削除して ストレージ を保存します。

ケース スタディ

ケーススタディ 1: インデックスのクリーンアップによる ストレージ の超過分の削減

顧客プロファイル: サプライチェーンと財務と運用アプリケーションに Dynamics 365 を使用しているグローバル製造企業。

課題: この顧客は、運用環境で予期せぬストレージの超過分とパフォーマンスの低下を経験していました。 調査の結果、初期の実装時に作成された複数のカスタムインデックスとマテリアライズドビューは使用されなくなりましたが、依然としてかなりのストレージを消費していることがわかりました。

解決策: チームは四半期ごとにすべてのカスタム インデックスの監査を実施し、アクティブなクエリやレポートで参照されていないものを削除しました。 また、展開の前に新しいインデックス要求を確認するためのガバナンスポリシーも実装しました。

結果:

  • データベース ストレージを 28% 削減しました。
  • クエリのパフォーマンスが 15% 向上しました。
  • 年間 12,000 ドルの保管コストを削減しました。

ケーススタディ2:コンプライアンスとパフォーマンスの目標を達成するための履歴データのアーカイブ

顧客プロファイル: Dataverse と Dynamics 365 を使用し、顧客オンボーディングとケース管理機能を提供する金融サービス企業。

課題: この企業では、規制要件を満たすために顧客記録を 7 年以上保持する必要がありましたが、非アクティブなデータの量が増えていたため、アクティブなワークフローが滞り、保管コストが増加していました。

ソリューション: このお客様は、Dataverse のアーカイブ機能を使って長期保存戦略を実施しました。 使用頻度の低いレコードは、読み取り専用でコストが最適化されたストレージ階層に移動され、アクティブなデータは高パフォーマンスのストレージに残りました。

結果:

  • 120万件以上のレコードをアーカイブ。
  • プライマリデータベースのサイズを40%削減しました。
  • 完全な監査可能性と保存ポリシーのコンプライアンスを維持しました。

ケーススタディ 3: 環境間での検索インデックスの合理化

顧客プロファイル: 開発環境、テスト環境、運用環境など、複数の Dataverse 環境を持つ小売企業が、Copilot 対応の顧客関係管理ソリューションをサポートしています。

課題: 検索インデックスは、未使用のテーブルやテスト データを含むすべての環境で使用されました。 そのため、DataverseSearch テーブルが肥大化し、不必要なストレージを消費していました。

解決策: チームは検索可能なフィールドを見直し、開発環境とテスト環境の重要でないテーブルでのインデックス作成を中止しました。 また、環境の更新中にインデックスのクリーンアップも自動化されました。

結果:

  • 検索インデックス ストレージ を 35% 削減しました。
  • 環境の更新時間が 20% 短縮されました。
  • ログとデータベース ストレージ の全体的な使用率が低下しました。

ケーススタディ 4: ストレージを重複させることなく分析にデータエクスポートを使用する

顧客プロファイル: Dynamics 365 と Dataverse を患者エンゲージメントと請求業務に利用している医療機関。

課題: 分析チームは、トレンド分析と AI モデリングのために業務データへのアクセスを必要としていましたが、データを別の倉庫に重複して保管することで、保管コストと複雑さを増大させていました。

ソリューション: この顧客は、OneLake の増分エクスポートと階層型ストレージを備えた Azure Synapse Link を使用していました。 重要な分析データのみを保持し、保存ポリシーを適用して履歴の深さを管理しました。

結果:

  • 運用システムに影響を与えることなくリアルタイム分析を可能にしました。
  • 冗長なストレージを45%削減しました。
  • 分析データのライフサイクルにおけるガバナンスの向上。

結論

効果的なストレージ管理は、Dynamics 365環境でシステムパフォーマンスを維持し、リソース使用率を最適化するために重要です。 この記事で概説するクリーンアップ・ルーチンとアーカイブ・ジョブは、貴重なデータベース・スペースを解放し、操作を合理化するための堅牢なソリューションを提供します。 LTRなどのツールや類似の手法を使用することで、お客様はストレージの一般的な課題に対処し、持続可能なデータ管理プラクティスを構築できます。 さらに、実際のケーススタディは、これらのアプローチの有効性を実証し、実際のアプリケーションへの洞察を提供します。 これらの戦略を採用することで、組織はストレージのニーズをプロアクティブに管理し、全体的な効率を高めることができます。

参照

Dataverse におけるストレージのクリーンアップ:

財務と運用におけるストレージのクリーンアップ:

ストレージ容量:

  • Last updated on