次の方法で共有


Azure 上の SaaS ワークロードのデータ

データをソリューションの最も価値のある資産として扱います。 独立系ソフトウェア ベンダー (ISV) として、あなたは顧客のデータを管理する役割を担っています。 あなたのデータ設計戦略とデータ ストアの選択は、顧客に大きな影響を与える可能性があります。

この記事では、ビジネス パフォーマンスの要件を満たしながら、顧客のデータの整合性と機密性を確保する方法に関するガイダンスを提供します。 この記事では、これらの目標を効果的に達成するための主な考慮事項に重点を置いて説明します。

データ ストアの選択

サービスとしてのソフトウェア (SaaS) ソリューションのデータ ストアは、そのアーキテクチャ、パフォーマンス、信頼性、トランザクションの複雑さに影響します。 Azure マネージド サービスの機能と、Microsoft 以外の同様のオファリングを比較します。 状況によっては、仮想マシン上でオープンソース製品を実行することを検討する場合もあります。

設計上の考慮事項

  • トランザクション操作と分析操作を区別します。 トランザクション データ ストアはアプリケーションをサポートするように設計されており、分析データ ストアは、機械学習などのレポートやタスクに使用されます。 これらのストアは専用の製品で構築されており、パフォーマンス、アクセス パターン、スキーマ、ユース ケースに関する独自のニーズがあります。

    このガイドでは、トランザクション データ ストアに焦点を当てます。

  • データのニーズを把握します。 保存する必要があるデータの容量、変更頻度、種類を見積もります。

    時間の経過とともにデータが大幅に増加することを予想します。 SaaS ソリューションの場合、成長は複数のディメンションで行われます。 顧客数の増加に応じて、データの容量と種類が増加することを予測します。 その成長を見据えた計画を立て、それをサポートできるテクノロジに投資するようにしてください。

    データの性質に基づいて、リレーショナルと非リレーショナルのデータ プラットフォームのどちらを使用するかを決定します。 多くのトランザクション ワークロードの場合、リレーショナル データベースは、アプリケーション エンティティを個別のテーブルとしてモデル化する場合に適したオプションです。 このアプローチでは、リレーショナル データ モデル全体でクエリを操作できます。 あるいは、データがドキュメント モデルに自然に適合するか、グラフ構造に従う場合は、非リレーショナル アプローチの方が適している可能性があります。

    詳細については、「SQL と NoSQL データ プラットフォーム」を参照してください。

  • データ ストアの種類を最小限にします。 さまざまな種類のデータを複数の異なるデータ ストアに保存することは、さまざまなデータ プラットフォームにわたる専門知識を持つ成熟した組織にとって有益です。 しかし、このアプローチでは、スタートアップ企業や小規模な組織にとっては不要な複雑さが生じることが多くあります。 1 つまたは少数のデータ ストアに焦点を当てる方が効果的です。

    複数のデータ ストアを使用することについて業務上の正当な理由がない場合は、1 つまたは少数のデータ ストアに焦点を絞って取り組みます。

  • 知っていることを使用し、それに投資します。 チームが特定のデータ ストアに関する専門知識を既に持っている場合は、新しいスキルの習得に投資するのではなく、そのデータ ストアを使用することをお勧めします。 データ ストアとプラットフォームは複雑であり、設計上の決定を取り消すのが難しい場合があります。

    ただし、潜在的な成長に留意してください。 現在のデータ ストアが要件を満たさなくなった場合は、ソリューションのパフォーマンス、回復性、セキュリティ、運用効率を高めることができるデータ ストアを選択します。 そうすることで、チームが専門知識を深めることにも役立ちます。

設計の推奨事項

推奨 特長
日常的な業務用のトランザクション データ ストアと、分析およびレポート作成用のデータ ストアを区別します。 データ ストアの意図を混在させると、不要な複雑さが生じる可能性があります。 データのセグメント化により、運用効率が向上し、各データ ストアの使用率が最大化されます。
要件に基づいて、リレーショナルまたは非リレーショナル データ構造のいずれかを選択します。 1 つまたは少数のデータ ストアから始めます。

マネージド データ ストアを優先します。 一般的な選択肢として、Azure Cosmos DB、Azure SQL、MySQL、MongoDB、PostgreSQL などがあります。
このアプローチにより、複雑さを最小限に抑え、適切な製品を使用して効率を最大限に高めることができます。 マネージド データ ストアでは、リソースとコストを柔軟に管理し、ニーズに合わせてスケーリングできます。 マネージド データ ストアを使用すると、独自のデータ ストアを独自のインフラストラクチャに配置する場合と比べて、管理上の負担が少なくて済みます。
選択したテクノロジの学習に投資します。 SaaS ソリューションの高度なスケーリング要件やその他の複雑性を管理できるように、チームに知識を身につけさせます。 スケーリング時にデータ プラットフォームを効果的に使用できるように、使用するツールとその広範なエコシステムについて学習します。
データ設計に柔軟性を取り入れます。 SaaS ソリューションが成長したり、要件が変更されたりした場合、データ ストアを追加または変更することで適応できます。 この柔軟性により、1 つのデータ ストアから始めて、徐々に進化することでニーズを満たすことができます。

テナント モデルとデータベース戦略

データ設計の重要な側面は、顧客に代わってリソースをホストするか、顧客の環境内でリソースをホストするかの決定です。 ほとんどの SaaS プロバイダーは、すべての顧客のリソースをホストするため、データベース管理に柔軟性がもたらされます。 顧客の環境でリソースをホストする場合は、それらのリソースにアクセスして管理する方法を検討してください。

設計上の考慮事項

  • データベースのセグメント化を計画します。 企業間 (B2B) SaaS ソリューションでは、顧客ごとに専用データベースを作成することをお勧めします。 このアプローチでは、顧客間の厳密な分離を維持することでデータ セキュリティが強化されます。これにより、データの混在リスクが軽減され、カスタマー マネージド暗号化キーがサポートされます。 また、一部の顧客の規制コンプライアンス要件を満たすのにも役立ちます。

    顧客データを個々のデータベースに分離すると、うるさい隣人の問題を最小限に抑えることで、パフォーマンスを向上させることができます。 一部のマネージド データ ストアには、これらの問題の軽減、コスト効率の実現、複数のデータベースを大規模に管理するためのツールの組み込みを行うためのリソース割り当て制御が組み込まれています。

    場合によっては、複数の顧客のデータを 1 つのデータ ストアに保存することが適切です。 たとえば、企業間 (B2C) ソリューションでは、顧客 ID に基づいた論理パーティション分割を使用して 1 つのストアにデータを保存できます。 コンポーネントを共有する B2B ソリューションでは、イベント ストアなど、特定の部分に 1 つのデータ ストアを使用すると同時に、各イベントに顧客 ID を必ず含めるようにすることができます。

  • データ ストアをアプリケーション コンポーネントと併置します。 顧客に代わってリソースをホストする場合は、同じ Azure リージョンに展開して、エグレス帯域幅の料金と待機時間を回避します。 アプリケーションとデータ ストアを顧客の環境でホストする場合は、環境間の複雑さを避けるために、それらを同じ環境にまとめて配置します。

  • データ ストアの管理を実用的な範囲でできる限り標準化します。 統一性は、顧客間でデータを管理する際の鍵となります。 ビジネスが成長するにつれて、顧客間の相違によってリスクと複雑さが増大します。 これらの相違により、運用停止の可能性が高くなり、トラブルシューティングがより困難になる可能性もあります。

    個々の顧客をサポートするために管理に 1 回限りの変更を加えないようにします。 たとえば、カスタマー マネージド メタデータをサポートするために、データベースに列を追加するなどのスキーマ変更は行わないようにします。 代わりに、顧客が独自のメタデータを追加するための機能を構築します。 同様に、異なる顧客に対して異なるレベルのデータベース パフォーマンスを提供する必要がある場合は、異なる顧客層に異なる構成を適用するために使用できる単一のプロセスを作成します。

テナント モデルがデータ戦略に与える影響の詳細については、以下を参照してください。

設計の推奨事項

推奨 特長
複数の顧客間でデータベースを共有するか、共有データ プラットフォームを提供するかを判断します。

必要に応じて、顧客のデータごとに 1 つのデータベースを配置します。 B2C ソリューションの場合など、厳密な分離が要件でないときは、この戦略を緩和します。
このアプローチにより、うるさい隣人の問題を最小限に抑え、一部の顧客のコンプライアンス要件をサポートできます。
アプリケーションとそのデータベースを同じリージョンに配置します。 このアプローチにより、リージョン間のデータベース アクセスによって発生する帯域幅のコストと待機時間が最適化されます。
顧客定義のデータまたはメタデータを格納するための標準化されたアプローチを設計します。 個々の顧客のスキーマを変更したり、顧客環境に違いが生じたりしないようにします。 このアプローチは、顧客ごとにデータベース間の不整合を管理する運用上の負担を回避するのに役立ちます。
顧客がデプロイした環境における定期的なメンテナンス操作を計画します。

更新、スキーマの変更、メンテナンス、その他の操作のためにデータベースにアクセスする方法を計画します。
このプロアクティブなアプローチにより、メンテナンス不足による問題を最小限に抑え、ダウンタイムやパフォーマンスの問題のリスクを軽減できます。

容量を計画する

容量計画とは、CPU、メモリ、ストレージ、ディスク操作 (1 秒あたりの入出力操作 (IOPS) など) に重点を置いたリソース使用率の管理のことを指します。 一部のデータ ストアでは、これらのリソースをシンプルな統合リソース使用量メトリック (Azure SQL のデータベース スループット ユニット (DTU) や Azure Cosmos DB の要求ユニット (RU) など) に結合します。 マネージド データ ストアは、リソース管理に柔軟性をもたらし、時間の経過に伴う変更を可能にします。 初期計画を立てて、ニーズの進化に合わせて反復することが重要です。

設計上の考慮事項

  • リソース割り当ての要件を理解します。 SaaS ソリューションの顧客ごとに、リソース要件が異なる場合があります。 小規模な顧客は最小限のリソースしか必要とせず、大規模な顧客はより多くのリソースが必要になる場合があります。 多くの場合、大規模な顧客はより高額の料金を支払いますが、このことはより多くのリソース割り当てが行われていることを説明しています。 顧客ごとに個別のデータベースを使用することで、サイズとニーズに基づいてリソース割り当てを調整できます。

  • データ プラットフォームが提供するさまざまな容量モデルについて理解します。 クラウドベースのデータ プラットフォームでは、複数のリソース モデルが提供されることがよくあります。 たとえば、Azure Cosmos DB などの一部の Azure サービスでは、プロビジョニングされた、スループット ベースのモデルとサーバーレス モデルが提供されます。 Azure SQL Database には、エラスティック プールも用意されています。

    プロビジョニングされたスループットには、単一のデータベースまたはデータベースのグループからの、事前に決定されたリソース割り当てが必要になります。 エラスティック プールでは、複数のデータベース間でリソースを共有できます。 エラスティック プールは、SaaS ソリューションでよく使用されます。

    プロビジョニングされたスループットでは、事前にリソースを割り当てる必要がありますが、Azure Cosmos DB などのサービスには、自動スケーリングのスループットが用意されています。 指定したトリガーに基づいてリソースを動的に追加したり削除したりするためのルールを設定できます。

    サーバーレス リソース モデルは、必要に応じて自動的にスケーリングされます。 この機能を備えていることで、このモデルは、容量の要件を事前に予測できない場合の出発点として適しています。 ただし、サポートされている機能が少ない場合があり、また、成長するにつれてコスト効率が悪くなる可能性があります。 サーバーレス モデルは、Azure SQL Database および Azure Cosmos DB で使用できます。

設計の推奨事項

推奨 特長
各顧客のデータベース要件をモデル化します。 多数の小規模なデータベース、少数の大規模データベース、またはその 2 つの組み合わせが必要かどうかを判断します。

T シャツのサイズ分けの演習を使って、顧客を小、中、大のバケットに分類します。
このアプローチは、顧客ごとに必要なリソースの大まかな見積もりを提供し、顧客を課金モデルにマップするのに役立ちます。
リソース プールを、それらを使用する顧客データベースのサイズに基づいてセグメント化します。

プロビジョニングされた容量を有効に利用します。 たとえば、小規模な顧客に共有 SQL エラスティック プールを、中規模の顧客に個別プールを、大規模な顧客に専用リソースを作成できます。
顧客のデータベース サイズに基づいてリソース プールをセグメント化することで、リソース割り当てとコスト効率を最適化できます。
マネージド サービスが提供する組み込みのスケーリング機能を利用します。 スケーリングの役割をプラットフォームにオフロードできます。 エラスティック プールや自動スケーリングなどの機能は、リソースの使用を最適化するのに役立ちます。
サーバーレス データ ストアを定期的に確認して、それらが継続的にニーズを満たしていることを確認します。 進化するニーズに合わせてデータ ストアの有効性を確実に維持できます。 要件の変化に応じて、パフォーマンスとコスト効率を最適化します。

高可用性とディザスター リカバリー

SaaS ソリューションのお客様は、高可用性 (HA) とディザスター リカバリー (DR) に対して高い期待を抱いていることがよくあります。 顧客が規制対象の業界で事業を行っている場合や、日常業務にあなたのソリューションを使用している場合は、その要件はさらに厳しくなる可能性があります。

HA と DR はすべてに対応できるソリューションではなく、さまざまな要因に依存します。 さまざまなリスクを軽減するための情報に基づいた意思決定を行うには、自分と顧客の両方の要件に適用できる利用可能なオプションについて明確に理解してください。

トレードオフ: 信頼性、コスト、パフォーマンス: データ サービスの回復性を確保するには、多くの場合、リスクを軽減するために、データのレプリカまたはコピーをより広い地理的領域に分散する必要があります。 ただし、トレードオフがあります。 データの移動距離が長いほど、局所的な障害に対する保護が強化されます。 しかし、長い距離にわたってデータをコピーすると、待機時間が長くなり、コストも増えることがよくあります。 多くのマネージド データ ストアでは自動データ レプリケーションが提供されますが、パフォーマンスを維持するために、さまざまな距離間で実行できるレプリケーションの種類に制限が課される場合があります。

設計上の考慮事項

  • 回復性を定量化します。 サービス レベル目標 (SLO) を使用して回復性の要件を測定します。これには、アップタイム、復旧時間、復旧ポイントなどのメトリックが含まれます。 これらのメトリックは、自分のビジネス要件と、さまざまなニーズを持つ可能性がある顧客の要件の両方によって決まります。 顧客に代わって大量のデータを保存する場合、厳格な要件を満たすために、HA および DR ソリューションをより複雑化する必要性が生じる場合があります。

    回復性のメトリックについて詳しくは、「RE:04 信頼性目標を定義するためのレコメンデーション」を参照してください。

  • プラットフォームの機能を使用します。 Azure では、データセンター内で、可用性ゾーンを使用してリージョン内で、複数のリージョンを使用してより広い地理的領域にわたって、回復性を実現する機能を提供しています。 可用性ゾーン、リージョン間バックアップ、マルチリージョン デプロイなどの戦略を組み合わせて、ソリューションに適したレベルの回復性を実現します。 回復性の要件が高い場合は、リージョン間の非同期データ レプリケーションを備えたマルチリージョンのアクティブ/パッシブ アーキテクチャを検討してください。 このアプローチでは、致命的な停止時に一部のデータが失われる可能性があります。

    トレードオフ: レプリケーションを使用したマルチリージョンのアクティブ/アクティブな設計は、最も回復力がありますが、ビルドとテストが複雑です。 ほとんどのアクティブ/アクティブ ソリューションでは、データ同期の遅延に対処する競合解決アプローチを設計する必要があります。 ほとんどのソリューションでは、このレベルの回復性は必要ありません。

    RE:05 可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

  • デプロイ スタンプを使用して、コンポーネントの影響範囲を分離します。 デプロイ スタンプ パターンは、デプロイ、管理、パフォーマンス、回復性にメリットをもたらすため、SaaS ソリューションで広く使用されています。 たとえば、1 つのスタンプを米国にデプロイし、別のスタンプをヨーロッパにデプロイすると、あるリージョンの顧客が他のリージョンでの停止から分離され、独立して運用できるようになります。

設計の推奨事項

推奨 特長
自分と顧客の全体的なデータ要件について検討しながら、回復性の要件に重点を置きます。 設計上の決定をこれらの要件に基づいて行うことで、適切なトレードオフを実施し、ニーズに対して過小または過剰なエンジニアリングを回避することができます。
課金モデルにさまざまなレベルの回復性を反映します。

期待する内容を顧客と一緒に設定します。 致命的な停止中にデータ損失をゼロにしたり、100% のアップタイムを期待するのは非現実的かもしれません。
課金モデルは、どの程度保証された回復性にサインアップしているかを顧客が理解するのに役立ちます。 たとえば、レベルが低い場合、顧客が受けるのは最小限の保証です。 レベルが高い場合は、複数のリージョン間でリソースをレプリケートできるため、より高い回復性を得ることができます。
運用ソリューションに Azure Availability Zones を使用します。 可能な場合は、ゾーン冗長データ ストアを使用します。 Availability Zones は、ソリューションのコスト、待機時間、複雑さを大幅に増やすことなく、データセンターの停止に対する回復性を提供します。
利用可能な場合はリージョン間レプリケーションを使用して、データ ストアのバックアップをグローバル冗長形式で保持します。 データのリージョン間バックアップによって、回復性のレベルが向上します。
デプロイ スタンプを使用して、地理的に分散した場所にソリューションの個別のインスタンスを作成します。 デプロイ スタンプを使用して、地理的に分散した場所にソリューションの個別のインスタンスを作成することで、回復性を高め、運用管理の容易さなど、より多くの利点を実現できます。
要件を満たすために、マルチリージョン デプロイが必要かどうか、およびアクティブ/アクティブな設計が必要かどうかを判断します。

関係するトレードオフを検討してください。 ステートレス コンポーネントは、データ ストアなどのステートフル コンポーネントよりも簡単にレプリケートできます。
ソリューションまたはスタンプを複数のリージョン間に分散すると、リージョン間でデータをレプリケートすることにより、より高いレベルの回復性が得られます。

セキュリティとコンプライアンス

あなたは、顧客のデータの機密性と整合性を確保する責任を負っています。 セキュリティ ベースラインを構築するときに、セキュリティの要件と約束を検討してください。 データ保持を含め、顧客のコンプライアンス ニーズを満たすように計画します。

設計上の考慮事項

  • ネットワーク: 誰がデータ ストアにアクセスするのかを検討します。 通常、あなたのアプリケーションのみ直接通信が必要になるため、プライベート専用のネットワーク向けにそれを構成します。

  • ID: データ ストアへのアクセス方法を検討します。 多くの SaaS ソリューションでは、すべてのデータ ストアに単一のアプリケーション ID を使用し、アプリケーション層で分離と認可を実施します。 行レベルのセキュリティやデータベース レベルの認可では、ユーザーの ID をデータ ストアに伝達することが必要になる場合がありますが、これはマルチテナント環境では複雑です。

  • データ保持: データ保持ポリシーを事前に計画します。 維持するデータが多くなると、ストレージのコストと管理の複雑さが増します。 たとえば、トランザクション データベース内の大量のデータにより、クエリや切り捨てのプロセスが複雑になる可能性があります。

    コンプライアンスや将来の分析などのための、長期的なデータ保持の場合は、長期保有に適したストアにデータを再配置することを検討してください。

設計の推奨事項

推奨 特長
プライベート エンドポイントを使用するようにデータ ストアを構成し、パブリック エンドポイントを無効にします。 このアプローチでは、内部ネットワークへのアクセスを制限することによってセキュリティが強化されます。 アクセスを制限することで、不正アクセスや潜在的なデータ侵害のリスクを軽減できます。
認証にはマネージド ID と Microsoft Entra ID を使用します。 データベース キーや資格情報は使用しないでください。 マネージド ID を使用すると、データベース キーや資格情報が不要になり、資格情報の盗難のリスクが低減され、アクセス管理が簡素化されます。
共有データ ストアを使用する場合は、テナント識別子を WHERE 句に含めることで、アプリケーションですべての要求が 1 つのテナントにスコープ設定されるようにします。 このプロセスは、テナント間のデータ漏洩や偽装のリスクを軽減するのに役立ちます。
コンプライアンスとビジネス ニーズに基づいてデータ保持戦略を計画します。 不要な履歴データを保持しないようにします。 長期保有の場合は、データをプライマリ ストアからアーカイブ ストレージに移動します。 不要な保持を回避することで、攻撃可能領域をより小さく保つことができます。
データ ストア機能を使用して、データ ライフサイクルのニーズをサポートします。

Azure Cosmos DB では、ドキュメントの Time to Live を設定します。 Azure SQL では、テーブルのパーティション分割を使用してスライディング ウィンドウ戦略を実装し、アーカイブ プロセスがデータベースに与える影響を最小限に抑えます。
これらのアプローチにより、効率的なデータ ライフサイクル管理が保証され、古いデータをアーカイブまたは削除することでストレージが最適化され、可能な場合は手動介入が削減されます。

操作

SaaS ソリューションには、多くの場合、多数のデータベースやその他のストアが含まれています。 フリートの定期的なメンテナンスを計画し、自動化オプションを確認して、これらのタスクを効率的に管理することが重要です。

設計上の考慮事項

  • チームの能力を理解します。 個々の顧客のデータベースに関する詳細な分析を実行できるデータベース管理者の大規模なチームがない場合は、大規模に運用を実行するための計画を立て、可能な限りプラットフォーム ツールを使用します。

  • 定期的なメンテナンス手順を計画します。 必要とされる定期的なメンテナンス操作とその頻度を一覧表示します。 具体的な操作は、使用するデータ ストアの種類によって異なります。 次に例を示します。

    • データの合計量と、重要なテーブルなど、特定のエンティティにあるデータを監視します。
    • インデックスを再構築します。
    • 変化するクエリ パターンに基づいてインデックスを作成または削除します。
    • パーティションを再調整します。

    定期的なメンテナンスを実行し、新しい問題を事前に探すのに役立つプラットフォーム機能を調べます。 たとえば、Azure SQL Database の SQL Database Advisor は、問題を監視します。

  • 自動化を目指して設計します。 SaaS ソリューションを効果的にスケーリングするには、自動化された運用が不可欠です。 定期的なタスクと不定期のタスクを特定し、それらのプレイブックまたは自動化スクリプトを作成します。 すぐに自動化できないタスクの場合は、一貫性と明確さを確保するためにプロセスを詳細に文書化します。

設計の推奨事項

推奨 特長
可能であれば、顧客のデータ ストア間の一貫性を実現するよう努めます。

顧客が特別な対応を必要とする場合は、その顧客の構成をカスタマイズするのではなく、それらを全体的なプロセスに統合します。 たとえば、各データベースに同じスキーマを使用し、同じプロセスを使用してリソースを配置および管理します。
一貫性により、大規模な変更が容易になり、デプロイまたはメンテナンス手順中に偶発的な問題が発生するリスクが最小限に抑えられます。
限られたリソースを慎重に配置し、運用を合理化する機会を探します。 小さな効率化を回避し、リソース使用率と全体的なパフォーマンスを向上させることができます。
反復的なタスクの自動化を構築します。 カスタム ソリューションを構築するのではなく、自動ツールを購入することを選択します。

プラットフォームおよび Microsoft 以外のベンダーが提供するオプションを検討します。
高品質な自動化に投資することで、これらの資産を繰り返し使用し、エラーが発生しやすい手動タスクを減らすことができます。 自動ツールは、使用しているデータ ストアの専門家でない場合や、必要なメンテナンス タスクがわからない場合に有用です。
チームのデータベース管理能力を慎重に配置します。 大規模な顧客を扱ったり、多くの顧客にわたってスケーリングできる自動化を構築したりするなど、最も影響の大きいアクティビティには人間のデータベース管理者を確保します。 価値のある機能を優先することで、効率を最大限に高めることができます。

データへの顧客のアクセス

一部の顧客は、カスタム レポートや分析のためにデータへの直接アクセスを要求する場合があります。 顧客がソリューション内のデータにアクセスする方法、および、これらの要求を許可するか、あるいは顧客のニーズを満たす別の方法を提供するかを慎重に検討してください。

設計上の考慮事項

  • 直接アクセスの理由を正当化します。 顧客のビジネス上の問題に関する情報を入手して、顧客が生データにアクセスする必要がある理由を理解します。 プラットフォームにリスクを導入することなく、顧客のニーズを満たすソリューションを見つけるために協力します。

    直接アクセスを付与するのではなく、要件を満たす別の方法を見つけます。 レポート作成の目的でアクセスが必要な場合は、アプリケーション層のアプローチが適しています。 たとえば、Microsoft Power BI を使用して顧客向けにレポートを作成したり、データのサブセットをファイルにエクスポートして顧客に提供したりできます。 また、データへのアクセスに使用できる API を作成することもできます。

  • セキュリティと分離の影響を評価します。 データ ストアへの直接アクセスを提供すると、重大なセキュリティ リスクが生じます。 顧客を含む外部関係者に内部リソースを公開しないようにします。 多くの顧客がソリューションを共有している SaaS 環境では、他の顧客のデータにアクセスするために環境が悪用される可能性があるため、リスクはさらに高くなります。

    運用システムに影響を及ぼさず、顧客のクエリを中断せずに内部データベースの設計を変更できる安全で分離された方法で、データへのアクセスを顧客に提供することを検討してください。

  • パフォーマンスへの影響を検討します。 トランザクション データ ストアへの直接アクセスを許可すると、メイン アプリケーションにパフォーマンスの問題が発生する可能性があります。 たとえば、顧客がリソースを大量に消費するクエリを実行して、アプリケーションの機能に問題が生じる場合があります。

設計の推奨事項

推奨 特長
データ ストアへの直接アクセスは付与しないようにします。

直接アクセスを付与する必要がある場合は、データ プラットフォームでサポートされていれば、読み取り専用レプリカへのアクセスを提供します。
アプリケーション層のアプローチにより、顧客によるデータの使用方法を制御できます。 アプリケーション層構造を作成できない場合は、読み取り専用レプリカを介したアクセスにより、顧客のクエリが運用に与える負担が軽減されます。
内部実装の詳細を公開しないでください。 データ構造へのアクセスを制御することで、顧客がデータベース スキーマの機能について仮説を立てることを防ぎます。 この柔軟性により、顧客が構築したツールや不正確な仮定の制約なしに、データベース構造を徐々に進化させ、最適化することができます。

その他のリソース

マルチテナント機能は、SaaS ワークロードを設計するための主要なビジネス手法です。 次の記事では、データ設計の考慮事項について詳しく説明しています。

次のステップ

効率的な顧客ライフサイクル管理や安全なデプロイ プラクティスなど、SaaS ワークロードの DevOps に関する考慮事項について学習します。