SLA と SLO
このユニットでは、サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO) について説明します。
サービス レベル アグリーメント (SLA)
SaaS は単なるソフトウェアではなく、主にサービスであるため、SaaS と従来のソフトウェア製品の違いの 1 つは SLA です。 SLA は、SaaS プロバイダーと顧客との間で締結される契約であり、アップタイムと接続に関するプロバイダーのコミットメントについて説明しています。 SaaS プロバイダーが SLA に規定されている各サービスのサービス レベルを達成および維持できない場合、顧客は報酬の対象となる場合があります。
ソフトウェア プロバイダーに対する SLA の報酬とペナルティは、業界とビジネスの種類によって異なります。 最も一般的な 2 つのシナリオは、制裁金とサービス クレジットです。 サービス クレジットの場合、顧客は、顧客の月額サービス料金についてクレジットの対象となる場合があります。
サービスのアップタイムを 100% に規定することはできますが、複雑なシステムでは 100% の可用性を達成するのは困難です。 ほとんどの SLA は、提供できる可用性に合わせて策定されます。
100% のアップタイムを指定した SLA でも、100% の可用性が保証されない場合があります。 100% のアップタイムは、停止が発生した場合に顧客が契約に従って報酬を受けることを意味する可能性があります。 可用性の高いシステムを構築することはエンジニアリングの仕事ですが、SLA は停止に対して会社を法的に保護する方法です。
Microsoft SLA の例については、「Microsoft Online Services サービス レベル契約 (SLA)」を参照してください。
サービス レベル目標 (SLO)
SLO は、顧客中心の主要なサービス レベル インジケーター (SLI) に対して設定される測定可能な目標です。 SLO によって、ビジネスまたはインフラストラクチャ ワークロードに関する顧客体験が測定されます。
SLO は、正式に交渉された SLA で行われたコミットメントを SaaS プロバイダーが満たしているかどうかを判断します。 SLO と SLI は、クラウド ビジネスまたはインフラストラクチャ ワークロードの設計段階で早期に規定する必要があります。
サービスの所有者が最も重要視するのは、以下を判断することです。
- どのシナリオが、顧客の観点から見てサービスの正常性の重要な指標であるか。
- どのように SLI を収集すれば、それらを可能な限り顧客体験に近づけることができるか。
- これらの SLI に対応する SLO は何か。
ソフトウェア業界には、次の 2 種類の SLO があります。
サービス中心の SLO は、チームが時間の経過と共にサービスの品質を徐々に向上するために定義する戦術的な目標です。
これらは、エンジニアリング マイルストーンで達成できる実用的な目標です。 たとえば、サービスが現在 99.7% の可用性を達成している場合、チームは次の四半期に 99.9% の可用性を達成するという目標を設定できます。
顧客中心の SLO は、顧客の期待が完全に満たされるため、それ以上の品質に向けてさらに投資する必要がない理想的な将来の状態または目標を定義します。
SLO は、クラウド ワークロードの開発と運用において重要であり、SLA とは異なる目的を果たします。 SLO は技術チームの状態と方向性を示すのに対し、SLA は、提供されるサービスと報酬の条件に関する顧客との契約です。
Azure では、Microsoft がインターフェイス、機能、メトリックを事前に定義しているため、サービス レベル管理は軽量です。 コンシューマーは、クラウド ワークロードを使用する際に、期待するサービス提供であるかどうかを管理する必要があります。
Contoso のシナリオ
Contoso とそのユーザー間のシンプルな SLA 契約では、まず次のような保証されるサービス レベルと SLI を定義します。
- ユーザーはシステムにアクセスしてサインインし、設計を生成して、システム内の他の利用可能な機能を使用できる。
- Contoso は、上記のシナリオに対応するサービスを 99.99% の可用性で提供する。
- 過去 5 分間の要求は、1,000 ミリ秒未満で 99% 処理される。
SLI は、時系列データの集計です。 SLI を収集する方法が重要です。 顧客が API を使用してサービスとやり取りする場合、システムの待機時間と要求の処理時間を測定すると、正確な SLI が得られます。 ただし、顧客が Web ポータルを使用してサービスとやり取りする場合は、要求を処理する合計時間に Web ページの JavaScript のパフォーマンスも含める必要があります。
SLA では、ダウンタイムと、ダウンタイムが発生した顧客への報酬も定義する必要があります。 たとえば、アップタイムの割合と 1 か月間に受け取られるクレジットの割合を関連付けた報酬構造や、ダウンタイムの 1 分あたりに支払う一定の報酬のシステムなどが考えられます。
SLO に関しては、Contoso は次の定義から始めることができます。
- サービスの品質 (QoS): AI モデルは、ユーザーが要求してから 3 分以内に新しい設計アイデアを生成する必要がある。
- 可用性: 1 か月間で 99.99%。
- 容量: CPU、ストレージ、メモリ、待機時間、スループット、スケーリングの目標使用率。
- 製品の導入: 提案されたデザイン アイデアの受け入れ率は 20% を超える必要がある。