Share via

マルチテナント ソリューションの更新に関する考慮事項

  • [アーティクル]

クラウド テクノロジの利点の 1 つは、継続的な改善と進化です。 サービス プロバイダーとして、ソリューションに更新プログラムを適用する必要があります。たとえば、Azure インフラストラクチャ、コード/アプリケーション、データベース スキーマ、またはその他のコンポーネントに変更を加えることが必要になる場合があります。 環境を更新する方法を計画することが重要です。 マルチテナント ソリューションでは、更新ポリシーについて明確にすることが特に重要です。テナントによっては、環境への変更を許可したがらない場合や、サービスを更新できる条件が制限される要件がある場合があるためです。

ソリューションを更新する戦略を計画するときは、次を行う必要があります。

  • テナントの要件を特定します。
  • サービスを運用するための独自の要件を明確にします。
  • 自分とテナントの両方が受け入れ可能なバランスを見つけます。
  • テナントやその他の利害関係者に戦略を明確に伝えます。

この記事では、テナントのソフトウェアを更新するために検討できるアプローチと、関連するトレードオフについて、技術的な意思決定者向けのガイダンスを提供します。

顧客の要件

以下の質問を検討します。

  • 要望と要件: 顧客には、更新のタイミングについて要望や要件がありますか? これらは、契約またはサービスレベル アグリーメントで正式に伝えられる場合もあれば、非公式になる場合もあります。
  • メンテナンス期間: 顧客は、サービス定義型または自己定義型のメンテナンス期間を想定していますか? 場合によっては、障害発生の可能性について、自身の顧客に伝える必要があります。
  • 規制: 顧客には、更新プログラムを適用する前に追加の承認を必要とする規制上の懸念事項がありますか? たとえば、IoT コンポーネントが含まれるヘルス ソリューションを提供する場合は、更新プログラムを適用する前に、米国食品医薬品局 (FDA) からの承認が必要になる場合があります。
  • 過敏性: 更新プログラムを適用することについて、特に過敏になったり、抵抗を示したりしている顧客はいますか? その理由を把握するようにしてください。 たとえば、物理ストアや小売 Web サイトを運営している場合、リスクが潜在的メリットを上回るため、ブラック フライデー近くの更新を避けたい場合があります。
  • 履歴: 顧客に影響を与えることなく更新を正常に完了した実績はいかがですか? 障害の可能性を低減し、更新によって発生する問題を迅速に特定できるように、適切な DevOps、テスト、デプロイ、および監視のプラクティスに従う必要があります。 顧客が、自身の環境をスムーズに更新できるとわかったら、反対する可能性は減ります。
  • ロールバック: 破壊的変更があった場合、顧客は更新をロールバックすることを希望しますか?

自身の要件

自身の立場から、次の質問の回答を検討する必要もあります。

  • 提供する用意がある制御: 更新プログラムが適用されるタイミングを顧客が制御できるようにするのは妥当ですか? 大企業の顧客が使用するソリューションを構築している場合、答えは "はい" になる可能性があります。 ただし、消費者重視のソリューションを構築する場合は、ソリューションのアップグレードまたは運用方法の管理を顧客に預ける可能性は低いでしょう。
  • バージョン: 一度に合理的に維持できるソリューションのバージョン数はどのくらいですか? バグが見つかり、修正する必要がある場合、使用中のすべてのバージョンに修正プログラムを適用しなければならない可能性があることに注意してください。
  • 古いバージョンの結果: 顧客の現在のバージョンへの更新を大きく遅れさせた場合、どのような影響がありますか? 新しい機能を定期的にリリースした場合、古いバージョンはすぐに廃止されますか? また、アップグレード戦略と変更の種類によっては、ソリューションのバージョンごとに異なるインフラストラクチャを維持することが必要になる場合があります。 そのため、古いバージョンのサポートを維持するときに、運用コストと財務コストの両方が発生する可能性があります。
  • ロールバック: デプロイ戦略では、以前のバージョンへのロールバックをサポートできますか? これは自身で有効にしますか?

注意

更新またはメンテナンスのためにソリューションをオフラインにする必要があるかどうかを検討してください。 一般に、停止期間は古いプラクティスと見なされており、最新の DevOps プラクティスやクラウド テクノロジによって更新やメンテナンス中のダウンタイムを回避することができます。 ただし、ダウンタイムなしのデプロイに向けて設計する必要があるため、ソリューション アーキテクチャを設計する際に更新プロセスを検討することが重要です。

更新プロセス中の停止を計画していない場合でも、通常のメンテナンス期間を定義することを検討できます。 期間は、特定の時間に変更が発生することを顧客に伝えるのに役立ちます。

ダウンタイムなしのデプロイの実現について詳しくは、「バージョン管理されたサービス更新によってダウンタイムを排除する」を参照してください。

バランスを見つける

サービス更新の頻度をテナントの裁量に完全に委ねると、まったく更新しないことが選ばれる場合があります。 顧客が抱きそうな懸念や制約を考慮するときに、自身でソリューションを更新できるようにすることが重要です。 たとえば、顧客が金曜日の更新を特に気にしている場合 (その日が一週間で最も忙しい曜日のため)、ソリューションに影響を与えることなく月曜日に更新を簡単に延期できますか?

有効な方法の 1 つとして、以下に示す方法のいずれかを使用して、テナントごとに更新をロールアウトすることができます。 計画された更新について顧客に通知してください。 顧客が (永続的にではなく) 一時的にオプトアウトできるようにします。更新プログラムを適用する必要がある期間に妥当な制限を設けます。

また、最小限の通知により、または事前に通知せずに、セキュリティ修正プログラムやその他の重要な修正プログラムを自身でデプロイできるようにすることを検討してください。

別の方法として、テナントが自分で選択したタイミングで、独自の更新プログラムを開始できるようにします。 ここでも、期限を指定する必要があります。この時点で、代わりに自身が更新プログラムを適用します。

警告

テナントが独自の更新を開始できるようにする場合には注意が必要です。 これは実装が複雑で、提供と管理に多大な開発およびテスト作業が必要になります。

どのような場合でも、特に更新が適用される前と後に、テナントの正常性を監視するプロセスがあることを確認してください。 多くの場合、重要な実稼働インシデント ("ライブサイト インシデント" とも呼ばれます) が、コードまたは構成の更新後に発生します。 そのため、顧客の信頼を維持するために、すべての問題をプロアクティブに監視し、対応することが重要です。 監視の詳細については、「DevOps の監視」を参照してください。

顧客とのコミュニケーション

明確なコミュニケーションは、顧客との信頼を築くうえで重要です。 新機能やバグ修正、セキュリティの脆弱性の解決、パフォーマンスの改善など、定期的な更新の利点を説明することが重要です。 最新のクラウドでホストされるソリューションの利点の 1 つは、機能と更新プログラムの継続的な配信です。

以下の質問を検討します。

  • 顧客に今後の更新を通知しますか?
  • その場合、オプトアウト プロセスを提供して暗黙的にアクセス許可を要求しますか? また、オプトアウトの制限は?
  • 更新プログラムを適用するときに使用する、予定メンテナンス期間はありますか?
  • 緊急の更新プログラム (重要なセキュリティ修正プログラムなど) がある場合はどうなりますか? それらの状況で更新を強制することはできますか?
  • 今後の更新プログラムを顧客に事前に通知できない場合、振り返り通知を提供できますか? たとえば、適用済みの更新プログラムの一覧を使用して、Web サイト上のページを更新できますか?
  • 運用環境で維持するシステムの個別バージョンの数は?

顧客サポートチームとのコミュニケーション

独自のサポート チームが、各テナントに適用されている更新プログラムを完全に表示できることが重要です。 顧客サポート担当者は、次の質問に簡単に答えられる必要があります。

  • 最近、テナントのインフラストラクチャに更新プログラムが適用されましたか?
  • それらの更新プログラムはどういったものでしたか?
  • 以前のバージョンは何ですか?
  • 更新プログラムはこのテナントにどのくらいの頻度で適用されていますか?

更新プログラムのために顧客に問題が発生した場合は、変更内容を理解するために必要な情報が顧客サポート チームにあることを確認する必要があります。

更新プログラムをサポートするためのデプロイ戦略

更新プログラムをインフラストラクチャにデプロイする方法を検討してください。 これは、使用するテナント モデルに大きく影響されます。 更新プログラムをデプロイするための一般的な方法には、デプロイ スタンプ、機能フラグ、およびデプロイ リングの 3 つがあります。 これらのアプローチは個別に使用することも、それらを組み合わせてより複雑な要件を満たすこともできます。

いずれの場合も、各テナントで使用されるインフラストラクチャ、ソフトウェア、または機能のバージョン、それらの可能な移行先、およびそれらの状態に関連付けられた時間に関連するデータを把握できるように、十分なレポート機能と可視性があることを確認してください。

デプロイ スタンプ パターン

多くのマルチテナント アプリケーションは、アプリケーションやその他のコンポーネントの複数のコピーをデプロイするデプロイ スタンプ パターンに最適です。 分離要件によっては、テナントごとにスタンプをデプロイしたり、複数のテナントのワークロードを実行する共有スタンプをデプロイしたりする場合があります。

スタンプは、テナント間の分離のための優れた方法です。 また、他に影響することなく、スタンプ全体に更新プログラムを段階的にロールアウトできるため、更新プロセスの柔軟性も確保できます。

機能フラグ

機能フラグを使用すると、ソリューションに機能を追加でき、その機能を顧客またはテナントのサブセットのみに公開できます。

次のいずれかの状況が当てはまる場合は、機能フラグの使用を検討してください。

  • 定期的に更新プログラムをデプロイするが、完全に実装されるまでは新機能が表示されないようにする必要がある。
  • 顧客がオプトインするまで、動作の変更を適用しないようにする必要がある。

機能フラグのサポートをアプリケーションに埋め込むには、自分でコードを記述するか、Azure App Configuration などのサービスを使用します。

デプロイ リング

デプロイ リングを使用すると、一連のテナントまたはデプロイ スタンプ間に更新プログラムを段階的にロールアウトできます。 テナントのサブセットを各リングに割り当てることができます。

作成するリングの数と、各リングが独自のソリューションに対して何を意味するかを決めることができます。 通常、組織では次のリングが使用されます。

  • カナリア: カナリア リングには、独自のテスト テナントと、更新プログラムが使用可能になったらすぐに入手したい顧客が含まれます。この場合、更新プログラムを受け取る頻度が高くなる可能性があることと、更新プログラムが他のものと同様の包括的な検証プロセスを通過していないことを理解していることが前提となります。
  • 早期導入者: 早期導入者リングには、もう少しリスク回避的ではあるが、定期的な更新を受け取る準備ができているテナントが含まれます。
  • ユーザー: ほとんどのテナントは "ユーザー" リングに属し、少ない頻度で、より高度にテストされた更新プログラムを受け取ります。

API のバージョン

サービスにより外部 API が発行されている場合、適用するすべての更新プログラムは、顧客またはパートナーがプラットフォームと統合される方法に影響を与える可能性があることを考慮してください。 特に、API に対する重大な変更に注意する必要があります。 API バージョン管理戦略を使用して、API に対する更新プログラムのリスクを軽減することを検討してください。

共同作成者

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

プリンシパル作成者:

  • John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア

その他の共同作成者:

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

次のステップ