テナントポータビリティ: SaaS アプリケーションのティア間でテナントを移動する

この記事は、Tenant portability: Move tenants across tiers in a SaaS application を翻訳したものです。

今日の急速に変化する Software as a Service (SaaS) 環境において、テナントのポータビリティは、競争力を維持しようとする SaaS プロバイダーにとって重要な機能です。テナントのティア間の円滑な移動を可能にするポータビリティにより、企業は変化するニーズに適応できます。しかし、ティア移動のリクエストに手動で対応することは大きなボトルネックとなり、スケーラビリティを阻害し、多大なリソースを必要とします。テナントの数とポータビリティのリクエストが増加するにつれ、このアプローチはサステナブルではなくなり、より効率的な解決策を実装することが不可欠になります。

このブログ記事では、テナントのポータビリティの重要性を掘り下げ、SaaS サーバーレスリファレンスアーキテクチャへのシームレスな統合にフォーカスしながら、実装に不可欠なステップを概説します。次の図はティア移動のプロセスを示しており、テナントと管理者の役割、およびアーキテクチャ内の新規および既存サービスにおける影響が強調されています。次のセクションでは、この図に示されたイベントの順序を詳しく説明します。

図1. SaaS サーバーレスリファレンスアーキテクチャ内でテナントのポータビリティを組み込む

なぜテナントのポータビリティが必要なのか?

* 柔軟性: テナントによるティアのアップグレードまたはダウングレードの場合、ティアの移動は変化するテナントの需要、選択、予算、ビジネス戦略に合わせて行われます。これらのティア変更は、通常、テナントと SaaS プロバイダー間のサービス契約の変更を伴います。
* サービス品質: SaaS 管理者によるテナント移行は、セキュリティ違反や、テナントがサービス制限に達した際の対応として行われます。これらのインシデントでは、サービスレベル契約 (SLA) を維持するためにテナントの移行が必要になる可能性があります。

大まかなポータビリティフロー

テナントのポータビリティは、通常、ティア間の移行をシームレスに行うために適切にオーケストレーションされたプロセスを通じて実現されます。このプロセスは以下のステップで構成されています:

図2. テナントポータビリティの大まかなフロー

アイデンティティストアの移行: テナントのアイデンティティストアをターゲットのティアに移行する必要があるかどうかを評価します。既存のアイデンティティストアがターゲットティアと互換性がない場合は、移行先ティアのアイデンティティストアと管理者ユーザーをプロビジョニングする必要があります。
テナント設定の更新: SaaS アプリケーションは、テナント ID やティアなど、運用に必要なテナント設定情報を保存しています。
リソース管理: ターゲットのティアにリソースをプロビジョニングし、インフラストラクチャとテナントのマッピングテーブルを更新するためのデプロイメントパイプラインを開始します。
データ移行: テナントのデータを古いティアからターゲットティアの新しくプロビジョニングされたインフラストラクチャに移行します。
カットオーバー: テナントのトラフィックを新しいインフラストラクチャにリダイレクトし、更新されたリソースをダウンタイムなく利用できるようにします。

検討事項のウォークスルー

ここでは、ポータビリティのワークフローにおける各ステップを詳しく見ていき、実装における重要な検討事項を強調します。

1. アイデンティティストアの移行

アイデンティティの移行における主な検討事項は、パスワードのリセットやユーザー ID の変更を必要とせずに、一貫したエンドユーザーエクスペリエンスを維持しながら、ユーザーの ID を移行することです。
フロントエンドが使用できる新しい ID ストアと関連するアプリケーションクライアントを作成した後、ユーザーを移行するメカニズムが必要になります。Amazon Cognito を使用したリファレンスアーキテクチャでは、各テナントが独自のユーザープールを持つことを「サイロ」と呼び、複数のテナントがユーザーグループを通じてユーザープールを共有することを「プール」と呼んでいます。
スムーズな移行プロセスを確保するため、ユーザーとコミュニケーションを取り、パスワードのリセットを回避するオプションを提供することが重要です。1 つのアプローチとして、期限までにログインするようユーザーに通知し、パスワードのリセットを回避することができます。ログイン時にジャストインタイムマイグレーションを採用し、既存のパスワードを維持することで、ユーザーエクスペリエンスを阻害せずにパスワードを保持できます。
ただし、これにはすべてのユーザーが移行するまで待つ必要があり、移行期間が長期化する可能性があります。補完的な対策として、期限後に残りのユーザーを一括インポートを使用して移行することができます。これにより、パスワードのリセットが強制されますが、一定の期間内で一貫した移行を確実に行えます。ただし、一部のユーザーには不便をかけることになります。

2. テナント設定の更新

SaaS プロバイダーは、すべてのテナント関連の設定を保持するためにメタデータストアを利用しています。移行プロセス中にテナントメタデータを更新する際は、慎重に行う必要があります。新しいティアのためにテナント設定を更新する際は、次の 2 つの重要な側面を考慮する必要があります。

移行プロセス全体を通してテナント ID を保持することで、移行後のテナントのログ、メトリクス、コスト請求について円滑に統合でき、イベントの継続的な記録が可能になります。
新しいティアに合わせて、テナントの使用量の上限を高めるための新しい API キーとスロットリングメカニズムを確立します。

SaaS リファレンスアーキテクチャに新しいテナントポータビリティサービスを導入することで、この処理を行います。このサービスは、ティア変更のリクエストに基づいてテナントに異なる AWS API Gateway の使用量プランを割り当て、後続サービスの呼び出しを調整します。その後、既存のテナント管理サービスを拡張し、リクエストに基づいてテナントメタデータ (ティア、ユーザープール ID、アプリクライアント ID) を更新する必要があります。

3. リソース管理

インフラストラクチャのプロビジョニングにおけるポータビリティの成功は、以下の 2 つの重要な側面に依存します。

移行プロセス中のテナント分離構成を尊重し、クロステナントのアクセスを防ぎます。ロールベースのアクセス制御 (RBAC) または属性ベースのアクセス制御 (ABAC) を使用して、これを確実にすることができます。前のステップでテナント ID が保持されている場合、ABAC 分離が移行中でも管理しやすいものとなります。
新しいティアで計装とメトリクス収集が正しく設定されていことを確認します。SaaS 運用の監視可視性を確保するために、同一のメトリクスフィルターを再作成します。

リファレンスアーキテクチャにおいて、インフラストラクチャのプロビジョニングとデプロビジョニングを処理するには、テナントプロビジョニングサービスを拡張します。

テナントスタックのマッピングテーブルを更新して、移行したテナントスタックの詳細を記録します。
必要に応じてインフラストラクチャのプロビジョニングまたは削除のパイプラインを開始します (例えば、データ移行とユーザーカットオーバーの手順の後に不要なインフラストラクチャを削除するパイプラインを実行します）。

最後に、関連するセキュリティ設定を適用し、コンプライアンスに準拠したアプリケーションのバージョンをデプロイすることで、新しいリソースが必要なコンプライアンス基準を満たすことを確認します。

これらの事項に対処することで、SaaS プロバイダーはテナント分離と運用の継続性を維持しながら、シームレスな移行を確実にすることができます。

4. データ移行

データ移行戦略は、ストレージエンジンや分離アプローチなどのアーキテクチャに大きく影響されます。移行中のユーザーのダウンタイムを最小限に抑えるには、移行プロセスの加速、サービスの可用性維持、増分更新のためのレプリケーションチャネルの設定に重点を置く必要があります。さらに、プールモデルに移行する際のデータ整合性を確保し、データ損失を回避するために、サイロモデルでテナントが行ったスキーマ変更に対処することが重要です。

リファレンスアーキテクチャを拡張し、新しいデータ移行サービスを導入することで、異なるティア間での Amazon DynamoDB データ移行を可能にできます。DynamoDB パーティション移行には、AWS Glue、カスタムスクリプト、DynamoDB テーブルの複製、パーティションの一括削除などの複数のアプローチがあります。ゼロダウンタイムの移行を実現するには、ハイブリッドアプローチをお勧めします。このソリューションは、DynamoDB のスキーマがティアを越えて一貫している場合にのみ適用されます。スキーマが変更されている場合は、データ移行にカスタムソリューションが必要です。

5. カットオーバー

カットオーバーフェーズでは、ユーザーを新しいインフラストラクチャに切り替え、継続的なデータレプリケーションを無効化し、コンプライアンス要件が満たされていることを確認します。これには、高い機密性が求められるサイロへの移行時には特に、テスト実行や監査や認証の取得を含むことになります。カットオーバーが成功した後、一時的なインフラストラクチャの削除や、以前のティアからの不要なテナントデータ履歴の削除など、クリーンアップ活動が必要です。ただし、データを削除する前に、監査証跡が規制要件に準拠して保存されており、データ削除が組織のポリシーに沿っていることを確認してください。

まとめ

ポータビリティはマルチテナント SaaS にとって重要な機能です。テナントはデータと構成情報をティア間で移行でき、上記のようにリファレンスアーキテクチャに組み込むことで移行を簡便に実施できます。主な考慮事項は、一貫したアイデンティティを維持すること、コンプライアンスを維持すること、ダウンタイムを減らすこと、プロセスを自動化することです。

翻訳はソリューションアーキテクト中山七美が担当しました。原文はこちらです。

Amazon Web Services ブログ