Azure での SaaS ワークロードの DevOps プラクティス
DevOps プラクティスは、特に SaaS アプリケーションの場合、Azure でのワークロードの管理に不可欠です。 主な側面としては、オンボード、オフボード、顧客インスタンスの変更があります。 これらのプラクティスは、運用を効率化するだけでなく、スケーラビリティと信頼性を向上し、停止の可能性を最小限に抑えます。
この記事では、効率的な顧客ライフサイクル管理と安全なデプロイ プラクティスのための設計上の考慮事項について説明します。
顧客ライフサイクルを管理する
"顧客ライフサイクル イベント" の管理は、SaaS アプリケーションにとって非常に重要です。 通常、これらのイベントとしては、次のものがあります。
- オンボード: 顧客がサインアップしたとき。
- 変更: 価格レベルの変更など、顧客のインスタンスの変更。
- オフボード: 顧客がアカウントをキャンセルしたとき。
その他のライフサイクル イベントが発生する可能性もあります。 たとえば、顧客がデータを保持したままサブスクリプションを一定期間一時停止し、その後にサブスクリプションを再開できるようにする場合などです。 各イベントはアプリケーションに固有の影響を与える可能性があります。
顧客ライフサイクル管理で、データベース テーブル内のデータの作成または管理のみが必要なソリューションもあれば、 Azure インフラストラクチャ、アプリケーション コード、より複雑な構成のデプロイを調整する必要があるソリューションもあります。
ライフサイクル管理は、SaaS ソリューションのコントロール プレーンが担う重要な役割です。 チームは、最初はこれらのアクティビティを手動で処理していても、時間が経つにつれて、形式化されたコントロール プレーン ソリューションまたはアプリケーションにより多くの機能を移行しようとする可能性があります。
設計上の考慮事項
整合性: ライフサイクル管理戦略を計画する場合、各顧客ライフサイクル イベントに必要なアクションの複雑さを考慮します。 これには、ソリューションのサイズ、顧客ベース、組織のオーバーヘッドが含まれます。 必ず、各イベントに必要な手順を明確に理解し、一貫性を維持するための制御に投資します。 ソリューションが進化してもプロセスの有効性を維持できるように、プロセスを定期的に見直して更新します。
テナント モデル。 顧客ライフサイクル イベントを処理する方法は、テナント モデルによって異なります。
- インフラストラクチャ リソースを使用する完全にマルチテナントのソリューション。 通常、顧客のオンボードまたはオフボードには、アプリケーションのデータ ストア内の顧客リストと関連データの更新が伴います。
- 顧客ごとの専用リソース。 通常、タスクには、Azure へのデプロイの開始、進行状況の監視、デプロイの失敗の処理が含まれ、場合によっては人的介入が必要です。
- 顧客がデプロイしたリソース。 オンボードまたはオフボードのために、顧客のエンジニアリング チームと直接やり取りすることが必要な場合があります。
レベル。 特に顧客がいつでも自由に SKU を変更できるようにする場合は、価格モデルと各レベルのさまざまなインフラストラクチャのニーズを考慮します。
- たとえば、SaaS ソリューションにコア アプリケーションと複数の有料アドオン モジュールが含まれている場合、オンボード時にコア アプリのリソースがデプロイされていることを確認します。 さらに、アドオン モジュールの動的な追加と削除を可能にします。 モジュールを削除する場合、関連データを削除するか、再アクティブ化の可能性に備えて保存するかを決定します。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| 顧客ライフサイクル イベントの各種類を文書化します。 各イベントのプロセスの詳細な手順を必ず記録します。 |
イベントを理解すると、ソリューション設計で、各イベントの対応方法を計画できます。 明確な指示は、人間のオペレーターが一貫性を維持するのに役立ち、将来の自動化の基礎となります。 |
| 各ライフサイクル イベントについて、お客様とお客様の顧客が共同で負う責任を伝えます。 ライフサイクル ステージを完了するために顧客に期待するアクションを、早い段階で明確に伝えます。 | コミュニケーション不足によって生じる潜在的なエラーや顧客の不満を軽減できます。 |
| ライフサイクル イベントごとに容量計画を行います。 たとえば、新しい顧客をオンボードするときに、追加の負荷を処理するのに十分な容量が既存のインスタンスにない場合、アプリケーションの新しいインスタンスをデプロイすることを計画します。 詳細については、「Azure での SaaS ワークロードの課金とコスト管理」を参照してください。 |
より簡単にスケーリングし、デプロイの失敗を回避できます。 |
| 可能な場合は、ライフサイクル イベントを自動化します。 少量または初期段階のソリューションの場合、手動によるデプロイと構成で十分な場合もありますが、ライフサイクル イベントが発生するたびにエンジニアがスクリプトを実行するとしても、スクリプトを使用する必要があります。 ソリューションが成熟するにつれて、これらの責任を完全なコントロール プレーンに統合して、人的エラーを減らし、より高いスケールをサポートします。 |
人為的エラーの重大なリスクを軽減し、より高いスケールをサポートできます。 |
インフラストラクチャ管理戦略を計画する
Azure インフラストラクチャのデプロイ、保守、管理を行うための戦略を早期に策定します。 SaaS をスケーリングすると、リソースの数が増加します。 インフラストラクチャが複雑になりすぎて手動で処理できなくなってから調整するよりも、最初から管理戦略に従う方が簡単です。
設計上の考慮事項
顧客リソース管理。 テナント モデルは、SaaS ソリューションでのリソースのデプロイに影響します。 顧客ごとに専用の Azure リソースをデプロイしたり、一定数の顧客間でリソースを共有したりする場合があります。 または、単一の共有リソース セットを使用して、新規顧客をオンボードするときに再構成する場合もあります。 リソースのライフサイクルを管理するための一般的なアプローチは、次のとおりです。
- 顧客リストを、デプロイするリソースの構成として扱います。 これらのリソースをデプロイおよび構成するには、一元化されたデプロイ パイプラインを使用します。
- 顧客リストをデータとして扱います。 コントロール プレーン アプリケーションを使用して、インフラストラクチャをプロビジョニングおよび構成します。
インフラストラクチャの自動化。 多くの組織は、Azure portal を使用してクラウド インフラストラクチャを手動でデプロイすることから始めますが、これは、最初は簡単であっても、十分に拡張することはできません。 Bicep や Terraform などのコードとしてのインフラストラクチャ (IaC) ツールを使用して、インフラストラクチャのセットアップを自動化することを計画します。 要件がより複雑な場合、Azure Resource Manager API を直接使用するコントロール プレーンを作成します。
インフラストラクチャの帰属情報。 どの顧客がどのインフラストラクチャにデプロイされているかを追跡します。 追跡は、正確な容量計画とコストの帰属にとって重要です。 顧客データベースで顧客インフラストラクチャを一元的に追跡できます。また、専用インフラストラクチャの場合は、顧客固有のリソース グループとリソース タグを含む Azure リソース メタデータを使用することもできます。 詳細については、SaaS ワークロードのリソース編成に関するページを参照してください。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| チームが既に使い慣れているツールを使用したデプロイ パイプライン、スクリプト、またはテンプレートを使用して、インフラストラクチャの自動化を構築します。 | ツールが理解されていない場合、インフラストラクチャの自動化によって混乱が生じる可能性があるため、既知のツールを使用すると、エラーのリスクが軽減されます。 |
| 可能な場合は、IaC を使用してインフラストラクチャをデプロイします。 | インフラストラクチャの量が増えるにつれて、インフラストラクチャを手動で保守することはリスクが高まり、負担も大きくなります。 |
| コア インフラストラクチャを顧客レベルのインフラストラクチャから分離します。 | インフラストラクチャの種類によって、ライフサイクルと管理アクティビティが異なります。 これらを分離すると、各セットを独自のスケジュールで個別に管理できます。 |
| Azure Managed Applications を使用して、顧客がデプロイしたリソースをデプロイおよび管理します。 | Azure Managed Applications には、顧客の Azure サブスクリプション内でリソースをデプロイおよび管理するために使用できるさまざまな機能が用意されています。 |
アプリケーションのデプロイ計画
機能性を強化するために、アプリケーション コードと構成を定期的に更新します。 顧客は、停止のリスクを最小限に抑えるために、更新中の一貫したアップタイムと安全なロールアウトを期待しています。
設計上の考慮事項
ツールとプロセスの標準化。 業界で実証済みの DevOps ツールを使用すると、機能全体の一貫性が確保され、アプリケーションのデプロイを管理するプロセスの成熟度が高まります。 独自のツールを開発することは、ほとんどの場合、アンチパターンと見なされます。
「OE:03 ソフトウェア開発プラクティス」を参照してください。
トレードオフ: 複雑さとコスト。使い慣れた DevOps ツールを使用すると、費用とスキルの面でコスト効率が高くなります。 ただし、各ツールを個別に管理する運用上の負担が増加します。 ワークロードに役立つ可能性のある新しい技術革新に対してオープンな姿勢を維持することが重要です。更新の段階的なデプロイ。 ユーザーを論理的なグループに分割し、一度に 1 つの顧客のサブセットに更新をデプロイします。 構成の変更によってコードの動作が変更され、停止が発生する可能性があるため、構成の変更にも同じ厳格さを適用します。 これらの変更については、デプロイ プロセスに従います。
バージョン管理戦略の導入。 顧客がアプリケーションのバージョンを選択できるようにすると柔軟性は向上しますが、運用は複雑になります。 古いバージョンの非推奨に関する明確な期待を設定し、サポートされなくなったときにどうなるかを概説します。
自動化 手動によるデプロイでは、人為的なエラーや一貫性の欠如に起因するリスクが発生しやすくなります。 デプロイが手動でトリガーされる場合でも、デプロイ プロセスを可能な限り自動化し、人的介入を必要最小限に抑える必要があります。 デプロイ プロセスの手順と、それらを最適に自動化する方法を検討します。
テストします。 次のテストを実行して、テストをデプロイ プロセスに統合します。
- コード ビルド中の単体テスト
- デプロイ後の統合テスト
- 定期的なパフォーマンス テスト
- 定期的なセキュリティおよび侵入テスト
どの段階でも、テストが失敗した場合に実行するアクションを決定します。
デプロイの失敗。 必要なアクションを考慮し、ロールバック戦略を準備して、デプロイの失敗に備えた計画を立てます。
顧客環境へのアクセス。 顧客環境にリソースをデプロイする場合は、それらの環境内で更新をどのように適用できるかを理解します。 アプリケーションの更新のデプロイなど、Azure Managed Applications によって提供される機能を検討します。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| 確立され、業界で実証済みの DevOps ツールとプロセスを使用して、アプリケーションのデプロイを管理します。 独自のツールを開発することは、ほとんどの場合、アンチパターンと見なされます。 詳細については、「OE:03 ソフトウェア開発プラクティス」を参照してください |
カスタム ビルド ツールを習得する必要がないため、エンジニアリング チームは効果的にデプロイできるようになります。 |
| 今後のデプロイや実行するデプロイについて顧客に事前に通知します。 | アプリケーションに今後加えられる変更について、顧客に適切な期待を抱かせることができます。 |
| 段階的公開、正常性モデリングなどの戦略を使用して、顧客グループに更新をデプロイする安全なデプロイ プラクティスを採用します。 より重要な顧客に移る前に、機密性の低い顧客または早期導入顧客から始めます。 詳細については、「安全なデプロイ方法に関する推奨事項」を参照してください。 |
このアプローチは、問題がすべての顧客に影響を与える前に問題を特定するのに役立ちます。 |
| 構成をコードとして扱う。 | ダウンタイムの可能性を低減し、運用環境の変更に一貫したプロセスを採用できます。 これにより、変更のテストや、構成およびコードの更新の段階的なロールアウトなど、運用上の責任を一元化できます。 |
| 変更管理プロセスを定義し、バージョン更新ポリシーを伝えて、更新をトリガーする担当者、更新の頻度、条件を顧客が確実に把握できるようにします。 顧客がアプリケーションのバージョンを選択できる場合は、古いバージョンを非推奨にするための明確なガイドラインを設定します。 運用環境で実行されるアプリケーション バージョンの数を最小限に抑えます。 |
古いバージョンを維持すると、運用上の非効率性が発生します。 明確な期待とポリシーを設定して、チームに過度の負担をかけないようにしながら、顧客に必要な制御を提供します。 |
| 単一の顧客向けにアプリケーションをカスタマイズすることは避けます。 さまざまな顧客のニーズをサポートするには、ソリューションのさまざまなレベルを作成するか、機能フラグを使用して特定のユーザーに対して特定の機能を有効にすることができます。 |
どの機能がどのバージョンにデプロイされているかがあいまいにならず、メンテナンスの負担も軽減されます。 |
| トリガーの基準や必要な承認など、デプロイが失敗した場合のロールバック計画を立てます。 | ロールバック計画は、予期しない状況でもデプロイのミスから確実に復旧するのに役立ちます。 |
| ソフトウェア開発プロセスの複数の段階でアプリケーションを定期的にテストします。 "シフトレフト"の考え方を採用し、ライフサイクルの早い段階でバグや逸脱を検出します。 | 重大なエラーが顧客に影響を与えるのを防ぐのに役立ちます。 |
その他のリソース
マルチテナント機能は、SaaS ワークロードを設計するための主要なビジネス手法です。 以下の記事では、DevOps プラクティスの採用について詳しく説明しています。
- マルチテナント ソリューションのデプロイと構成のアーキテクチャに関するアプローチ
- マルチテナント ソリューションの更新に関する考慮事項
- マルチテナント コントロール プレーンに関する考慮事項
- マルチテナント ソリューションでのコントロール プレーンのアーキテクチャに関するアプローチ
次のステップ
Azure で SaaS ソリューションをサポートするプロセスとツールを実装するためのインシデント管理に関する考慮事項について説明します。