この記事は、Achieving Operational Success of SaaS Solutions を翻訳したものです。
本投稿は、AWS SaaS Factory の Partner Solutions Architect である Ujwal Bukka により寄稿されました。
運用上の優秀性は、SaaS (Software-as-a-Service) プロバイダーにとって重要な課題です。運用上の優秀性とは、ワークロードを効果的に運用および監視し、サポートするプロセスや手順を継続的に改善してビジネス価値を提供する能力のことです。
それを得るために努力することは、SaaS ソリューションにおけるスムーズな運用、ひいては最適なカスタマーエクスペリエンスの確保につながります。
マルチテナント環境を運用する場合、SaaS プロバイダーは各テナントの現在のステータスを把握し、自動化されたプロセスが新規および既存のテナントに対して同一かつ期待どおりに機能していることを確認し、サポートするプロセスや手順を継続的に改善する必要があります。
マルチテナント環境に関連する運用上の優秀性の設計原則とベストプラクティスには、ソリューションの運用状態を効果的に監視し、管理する能力が含まれます。これには、システムが各テナントや利用プランに対してどの程度効果的にリソースをスケーリングしているかを把握すること、アラートやインサイトを生成するために適切なメトリクスデータを取得すること、テナントのオンボーディングなどの運用プロセスを管理すること、マルチテナント環境におけるテナントのさまざまなニーズをサポートすることなどが含まれます。
今回の記事では、運用上の優秀性の設計原則とベストプラクティスについて確認します。
これらのベストプラクティスを導入することで、継続的に変化するテナントのワークロードや利用パターンに対応し、データドリブンなインサイトを使用して、望ましいビジネス上および技術上の成果を達成できます。ここでの目標は、刻々と変化するビジネスの優先事項をサポートし、ビジネスコンテキストを提供し、顧客のニーズを反映するなど、運用の仕組みやプロセスを設計するのに役立つことです。
SaaSプロバイダーは、顧客を効果的にサポートし、ダイナミックなビジネスニーズに対応し、得られた教訓を取り入れる必要があります。運用上の優秀性の達成に役立つ SaaS デリバリーモデルには、運用の観点から考慮すべきいくつかのポイントがあります。
SaaS ソリューションを構築する際に検討することをお勧めする主な領域は 4 つあります。
マルチテナント環境では、テナントを共有インフラモデルでデプロイすることがあります。障害や問題が発生した場合、すべてのテナントに悪影響を及ぼし、すべてのお客様のサービスダウンを引き起こしてしまう可能性もあります。
このような事態を防ぐために、SaaS プロバイダーは、リソースがテナントや利用プランごとに適切にスケーリングされているか、テナントのリソース消費量が一定期間でどのように変化しているかなど、テナントの健全性やトレンドを監視できる運用体制の構築を重視しなければなりません。
さらに、SaaS プロバイダーは、テナントのアクティビティを監視し、現在または将来起こり得る問題を特定して分析し、予測可能な問題を積極的に修正する必要があります。
運用メカニズム導入の一環として、テナントの健全性やアクティビティを把握するためのダッシュボードやビューを構築することができます。これらのダッシュボードは、すべてのテナントの健全性を示すグローバルなビューに加え、運用に役立つデータをテナントや利用プランごとのビューとして提供するとよいでしょう。
例えば、Amazon Simple Storage Service (Amazon S3) に保存されているデータ量を把握するためには、すべてのテナントおよび個々のテナントの S3 に保存されているデータ量の全体像を把握できるダッシュボードが必要です。他にも、テナントごとのリソース消費量や、アプリケーションサービスごとのテナントのアクティビティなど、運用の仕組みを補完するダッシュボードが必要になるでしょう。
これらのダッシュボードを構築するためには、データベースへのクエリ時間、検索の待ち時間 (レイテンシー)、保存されているデータ量、結果数などの運用データを、テナントや利用プランのコンテキストとともに取得する必要があります。アーキテクチャ設計の一環として、運用データをテナントや利用プランのコンテキストとともに、どこでどのように取得するかを検討する必要があります。
この AWS SaaS Factory のブログ記事の「Instrumenting Your Application」のセクションを参照してください。ブログ記事では、運用データをキャプチャする方法と場所について説明しています。
優れた SaaS ソリューションは、お客様にスムーズな体験を提供します。テナントのオンボーディングは、テナントが最初に接する機能の一つです。SaaS ソリューションでは、新しいテナントをシームレスにオンボーディングする機能を提供し、このプロセスを繰り返し実行できるようにする必要があります。
ソリューションの要件に応じて、オンボーディングプロセスはセルフサービス方式で起動することも、SaaS プロバイダーが必要に応じて起動することもできます。オンボーディングプロセスの種類に関わらず、テナントのオンボーディングの一環としてすべてのリソースのプロビジョニングを自動化することをお勧めします。
オンボーディングプロセスでは、さまざまな方法でリソースを作成及び設定することができます。リソースには、同期的にプロビジョニングされるものと、非同期的にプロビジョニングされるものがあります。例えば、オンボーディングの一環として請求アカウントのプロビジョニングを非同期で行うことができます。その目的は、オンボーディングプロセスの俊敏性を高めることです。
テナントのオンボーディングプロセスの詳細については、SaaS レンズのドキュメントを参照してください。
SaaS プロバイダーとして、必ずすべてのテナントが同じバージョンの SaaS 製品を実行している必要があります。特定の顧客の要求を個別のバージョンでサポートすると、特定のメンテナンス作業や手作業が必要となり、ソリューション全体的な俊敏性が損なわれます。また、運用上の優秀性やイノベーションの目標にも支障をきたします。
1回限りの要件ごとに製品の別バージョンを作成するのではなく、これらの機能をコアプラットフォームに実装してすべての顧客が利用できるようにします。テナント毎の設定を利用すれば、どのテナントがそれぞれの機能を利用できるかを限定できます。
これを実装する一般的な方法の1つは、機能フラグ (Feature Flags) を使用することです。各機能フラグは、テナントの設定オプションと関連付けられ、実行時に評価されます。フラグの値に応じて、共通のコードベース内で異なる実行パスが生成されます。
例えば、一連のフラグは個々のテナントに対してオン/オフされ、どの機能を有効にするかを決定します。このように機能フラグは、各テナントの構成に基づいて、それぞれのテナントに対してそれぞれの機能を有効または無効にします。なお、機能フラグに基づくオプションが複雑に絡み合って、管理しきれない環境にならないように十分注意する必要があります。
機能フラグの詳細については、こちらの記事を参照してください。
SaaS ソリューションを継続的に成長させ改善していくためには、環境における使用状況やリソース消費に関するインサイトを提供する様々なメトリクスを収集する必要があります。そして、意味のある情報を得るために、これらのデータを分析する必要があります。
SaaS メトリクスは、CPU やメモリなどの基本的なメトリクスを取得するだけでなく、環境内のテナントアクティビティを基本的に理解するためのものです。このデータを分析することで、信頼性、スケーラビリティ、コスト効率、そして SaaS 全体の俊敏性を継続的に向上させることができます。
例えば、技術チームはこのデータを使って、現在のアーキテクチャでより多くのテナントをサポートできるかどうかなど、あらゆる問題のトラブルシューティングや予測を行うことができます。
ビジネスチームは、このデータを製品のロードマップや価格モデルの策定に利用することができます。例えば、テナントに利用されている機能のデータに基づいてビジネスチームは最も利用されている機能に優先順位をつけ、それらを強化したり、一部の機能をプレミアムプランでのみ利用可能と定義するなどの変更を行うことができます。
この機能を実現するためには、アプリケーション内の主要な領域を特定し、運用上の有益なインサイトを得るためのメトリクスを収集し、それらにアクセスして利用できるようにする必要があります。次のステップとして、図 1 に示すメトリクスインフラストラクチャの例のように、これらのデータを取り込み、集約、および表示することができるメトリックインフラストラクチャを構築します。
最後に、このデータを分析するためのダッシュボードやビューを構築します。SaaS アプリケーションのマルチテナントメトリクスを取り込み、集約し、可視化する方法については、この SaaS Factory のブログ記事を参照してください。メトリクスの取り込みと分析のフローを示すハイレベルな図を紹介しています。
図 1 – メトリックインフラストラクチャのサンプル
また、このワークショップを参考にして AWS クラウドの利用に関するコスト、利用状況、運用状況を表示するダッシュボードを作成することができます。
現在の運用上の優秀性に関する態勢を評価し、それを改善するための指針を得るためには、AWS Well-Architected SaaS レンズを使用することができます。これは以下の質問を使用して、上述の運用上の優秀性の考慮事項との整合性を評価します。
SaaS レンズの運用上の優秀性の柱は、既存の Well-Architected の原則を拡張したものです。全般的なベストプラクティスに合わせるために、レビューの一環としてこれらの基本的なプラクティスを含めていることを確認してください。詳細については、Well-Architected フレームワークの 「運用上の優秀性」の柱の説明を参照してください。
質問は、一般的な Well-Architected の設計原則に沿っていますが、SaaS ソリューションに特有の課題を取り上げています。それぞれの質問には、各トピックの推奨されるプラクティスの短い要約が付いています。この要約には Required、Good、Best の 3 つのプラクティスに加えて、トピックに関連するコンテンツへの参照も含まれています。
以下は、各質問の範囲と目標を示すハイレベルでの解説です。詳細については、SaaS レンズホワイトペーパー の「運用上の優秀性の柱」のセクションと、AWS Well-Architected Tool を参照してください。現在の状況を改善するためのガイダンスは、Well-Architected Tool 内の SaaS レンズ改善計画に記載されています。
堅牢な運用ツールを用いてテナントの消費、アクティビティ、健全性の傾向を把握することで、テナントや利用プラン毎の全体的なアクティビティや健全性の傾向を評価することができます。
技術系とビジネス系の両方のチームの異なる組織機能が、取得したテナントのメトリクスを見て、アーキテクチャや製品戦略、価格モデル、運用上の優秀性の形成に利用することができます。
テナントのオンボーディングプロセスには、テナントの作成、ユーザーアイデンティティの作成、分離ポリシーの作成、課金情報の作成、テナントの設定、必要なインフラの構築などが含まれます。これらのプロセスは、自動化された予測可能なプロセスを用いて行われるべきです。これにより、運用上の優秀性と組織の俊敏性が向上します。
テナント毎に別々の環境またはバージョンを管理すると、技術的負債が発生したり、SaaS 環境の管理能力に影響を与え、俊敏性が阻害されます。したがってすべてのテナントは、単一のバージョンのソリューションを使用する必要があります。カスタマイズしたものは、例えば機能の切り替えなどで、すべてのテナントが利用できるように実装することができます。これにより、カスタマイズが運用上の優秀性や SaaS の俊敏性に影響を与えることはありません。
詳細については、SaaS レンズホワイトペーパーの「運用上の優秀性の柱」のセクションを参照してください。
SaaS レンズは、AWS リージョン別のサービス表に記載されているように、AWS Well-Architected Tool が提供されているすべての地域で利用できます。
AWS Well-Architected Tool の利用にコストはかかりません。AWS Well-Architected レンズは、既存のワークロードに適用することも、ツールで定義した新しいワークロードに使用することもできます。作業中のアプリケーションを改善するために使用したり、作業中の部署やエリアで使用されている複数のワークロードを可視化するために使用したりすることができます。
新しい SaaS レンズの詳細を知り、AWS Well-Architected Tool を今すぐ使い始めましょう。
AWS をご利用のお客様は、AWS Well-Architected パートナープログラムまたは AWS SaaS Competency Partners にアクセスして、レビューを実施できる現在の AWS パートナーを見つけてください。
AWS SaaS Factory は、SaaS 導入のどの段階の企業でも支援します。新製品の構築、既存のアプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、どのようなご要望にもお応えします。AWS SaaS Factory Insights Hub では、技術的、ビジネス的なコンテンツやベストプラクティスをご覧いただけます。
また、SaaS 開発者の方は、エンゲージメントモデルや AWS SaaS Factory チームとの連携について、アカウント担当者にお問い合わせください。
こちらにご登録いただくと、最新の SaaS on AWS ニュース、リソース、イベントの情報を入手できます。
翻訳はソリューションアーキテクト 杉本 晋吾 が担当しました。原文はこちらです。
