次の方法で共有

マルチテナント ソリューションでのテナントのライフサイクルに関する考慮事項

  • [アーティクル]

マルチテナント アーキテクチャを検討するときは、テナントのライフサイクルにおけるすべての異なるステージを考慮することが重要です。 このページでは、ライフサイクルのステージと各ステージの重要な考慮事項に関する技術的な意思決定者向けのガイダンスを提供します。

試用版テナント

SaaS ソリューションを構築するときは、多くの顧客がソリューションを購入する前に試用版を要求または必要とすることを考慮してください。

試用版には、次のような固有の考慮事項があります。

  • サービス要件: 試用版を、完全な顧客用のデータと同じデータ セキュリティ、パフォーマンス、サービス レベル要件の対象とするか。
  • インフラストラクチャ: 完全な顧客用と同じインフラストラクチャを試用版テナントに使用するか、それとも試用版テナント専用インフラストラクチャを使用するか。
  • 移行: 顧客が試用後にサービスを購入する場合、試用版テナントから有料テナントへのデータの移行をどのように行うか。
  • 要求プロセス: 試用版を要求できるユーザーに関して制限を設けるか。 どのようにすれば、ソリューションの不正使用を防ぐことができますか。 試用版テナントの自動作成を許可するか、それとも各要求にチームが関与するか。
  • 制限: 時間の制限、機能の制限、パフォーマンスに関する制限など、試用版の顧客に対してどのような制限を設ける必要があるか。

状況によっては、試用版を提供する代わりにフリーミアム価格モデルを選択できます。

新しいテナントをオンボードする

新しいテナントをオンボーディングするときは、次の質問を考慮してください。

  • プロセス: オンボードは、セルフサービス、自動、または手動プロセスのいずれにするか。
  • データ所在地: テナントはデータ所在地に関して特定の要件を持っているか。 たとえば、適用されるデータ主権の規制はありますか。
  • コンプライアンス: テナントは何らかのコンプライアンス標準 (PCI DSS、HIPAA など) を満たす必要があるか。
  • ディザスター リカバリー: テナントは、目標復旧時間 (RTO) や回復ポイントの目標 (RPO) など、特定のディザスター リカバリー要件を持っているか。 それらは、他のテナントに対して提供している保証と異なるか。
  • 情報: テナントを完全にオンボードするためにはどのような情報が必要か。 たとえば、組織の登録名を知る必要があるか。 アプリケーションをブランド化するために会社のロゴが必要か。その場合、どのようなファイル サイズと形式が必要か。
  • 課金: プラットフォームには、さまざまな価格オプションと課金モデルが用意されているか。
  • 環境: テナントは運用前環境を必要としているか。 また、その環境の可用性について期待されることはありますか。 それは一時的なもの (オンデマンド) ですか、常に使用可能ですか。

オンボードされた後、テナントは "通常の業務" 状態に移行します。 ただし、この状態になっても、まだいくつかの重要なライフサイクル イベントが発生する可能性があります。

テナントのインフラストラクチャを更新する

テナントのインフラストラクチャに更新プログラムを適用する方法を検討する必要があります。 テナントが異なれば、更新プログラムを適用するタイミングも異なる場合があります。

テナントのデプロイの更新に関するその他の考慮事項については、更新に関する記事を参照してください。

テナントのインフラストラクチャをスケーリングする

テナントに季節的なビジネス パターンがあるかどうか、またはそれ以外でソリューションの消費レベルが変化するかどうかを検討します。

たとえば、小売業者向けのソリューションを提供する場合、一部の地域では一年の特定の時期が特に忙しく、それ以外の時期は閑散としていると予想される場合があります。 この季節性がソリューションの設計とスケーリング方法に影響するかどうかを検討します。 季節性が、テナントのサブセットで負荷が突然予期せずに増加して他のテナントのパフォーマンスが低下するなどのノイジー ネイバー問題にどのように影響するかに注意してください。 個々のテナントのインフラストラクチャをスケーリングしたり、デプロイ間でテナントを移動したり、トラフィックの急増と低下に対応するのに十分なレベルの容量をプロビジョニングしたりするなどの軽減策を適用することを検討できます。

インフラストラクチャ間でテナントを移動する

次のようなさまざまな理由により、インフラストラクチャ間でテナントを移動する必要がある場合があります。

  • 再調整：垂直方向にパーティション分割されたアプローチに従ってテナントをインフラストラクチャにマップし、負荷を再調整するためにテナントを別のデプロイに移動する必要がある。
  • アップグレード: テナントが SKU または価格レベルをアップグレードしたため、他のテナントからの分離レベルが高い、シングルテナントの専用デプロイに移動する必要がある。
  • 移行： テナントが、データを専用のデータ ストアに移動するように要求している。
  • リージョンの移動: テナントがデータを新しい地理的リージョンに移動する必要がある。 この要件は、企業買収時、または法律や地政学的状況の変化時に発生する可能性があります。

テナントのデータをどのように移動し、インスタンスをホストする新しいインフラストラクチャ セットにリクエストをどのようにリダイレクトするかを検討します。 また、テナントの移動によってダウンタイムが発生するかどうかを検討し、テナントがこのリスクを十分認識していることを確認する必要があります。

テナントを統合および分割する

テナントや顧客は静的で変化しないエンティティであると考えたくなります。 しかし、実際には、多くの場合、これは正しいことではありません。 次に例を示します。

  • ビジネス シナリオでは、企業が買収または統合される可能性があり、それは地理的に異なる地域の企業である場合があります。
  • ビジネスシナリオでは、企業が分割または売却する場合があります。
  • コンシューマー シナリオでは、個々のユーザーが家族に加わったり離れたりする可能性があります。

データ、ユーザー ID、リソースの統合と分離を管理する機能を提供する必要があるかどうかを検討します。 また、データの所有権が統合操作と分割操作の処理にどのように影響するかを検討します。 たとえば、家族による写真の共有用に作成されたコンシューマー向けの写真アプリケーションについて考えます。 写真は、それを投稿した個々の家族、または家族全体によって所有されていますか。 ユーザーが家族を離れる場合、データを削除するか、家族のデータ セットに残す必要がありますか。 ユーザーが別の家族に加わる場合、古い写真を一緒に移動する必要がありますか。

テナントをオフボードする

また、場合によっては、ソリューションからテナントを削除する必要があることも避けられません。 マルチテナント ソリューションでは、これに関して次のようないくつかの重要な考慮事項があります。

  • 保持期間: 顧客データをどのくらいの期間維持する必要があるか。 一定の期間が経過した後で、データを破棄する法的要件がありますか。
  • 再オンボーディング: 顧客が再オンボーディングできる機能を提供する必要がありますか? データ保持期間内に再加入した場合、そのデータは引き続き利用できますか?
  • 再調整: 共有インフラストラクチャを実行する場合、インフラストラクチャへのテナントの割り当てを再調整する必要があるか。

テナントを非アクティブ化して再アクティブ化する

顧客のアカウントを非アクティブ化または再アクティブ化することが必要な場合があります。 次に例を示します。

  • 顧客が非アクティブ化を要求しました。 コンシューマー システムでは、顧客がサブスクリプションの解除を選択する場合があります。
  • 顧客に請求できず、サブスクリプションを非アクティブ化する必要があります。

非アクティブ化は、一時的な状態を意図しているという点で、オフボードとは異なるものです。 ただし、しばらくしてから、非アクティブ化されたテナントのオフボードを選択する可能性があります。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

  • Chad Kittel | プリンシパル ソフトウェア エンジニア
  • Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

ソリューションに使用する価格モデルを検討します。