アプリケーションの信頼性を効果的な SLO で向上させる

AWS では、信頼性とは許容できる範囲内で大規模な中断に耐え、許容できる期間内に回復できる能力であると考えています。サービスの信頼性は、その目標を達成するために、可用性やパフォーマンスのような従来の基準を超えるものです。システムまたはアプリケーションのコンポーネントは、時間の経過とともにやがて故障します。当社の CTO である Werner Vogels が言うように、「Everything fails, all the time（故障しないものは無い）」のです。問題は、エンドユーザーに影響を与えずにシステムまたはアプリケーションがどのように障害に耐えられるか、そしてシステムが障害に対してどの程度回復力があるかということです。私たちのお客様はインシデントによる被害範囲を縮小し、ビジネスが必要とする信頼性、パフォーマンス、スケーラビリティの期待に応えるための支援を常に求めています。

このブログでは、インシデント発生時の迅速な対応のために、パフォーマンスを客観的に測定し、信頼性を正確に報告することでチームの成功を後押しする信頼性に関するベストプラクティスについて説明します。また、サービスレベル目標 (SLOs) を、Amazon CloudWatch Application Signals を使ってすべての Amazon CloudWatch メトリクスから設定、監視し、アラートする方法についても説明します。

サービスレベル管理 (SLM)

サービスレベル管理 (SLM) は、お客様に提供する IT サービスとサービスレベルを定義、交渉、管理するためのフレームワークやプロセスを提供します。このフレームワークには、サービスの可用性、品質、データセキュリティ、スループットといった、いくつかの重要な要素が含まれます。これは、お客様の目的と、サービスプロバイダである自社の両方の目的を守ることを目指しています。初めに、お客様に対する保証を表す用語と、サービスの健全性を示す追跡可能な指標について理解しましょう。

SLI (Service Level Indicator) は、提供されるサービスレベルのある側面を慎重に定義した定量的な指標です。
SLO (Service Level Objective) は、SLI によって一定期間測定されたサービスレベルの目標値または値の範囲です。
SLA (Service Level Agreement) は、お客様に約束するサービスレベルを概説した、お客様との合意です。また、要件を満たせない場合の対応策 (追加サポートや価格割引など) も詳細に規定されています。
エラーバジェットは、SLO を満たせなかった割合です。これは 100 % の信頼性と SLO 目標値の差に相当します。つまり、エラーバジェットとは、他の SLO を満たすための SLO です。

次の図は、SLA、SLO、SLI がどのように相互作用するかを表しています。お客様 (サービス利用者) はサービスを所有するチームの外部にいます。サービスチーム内には、ビジネスオーナーやカスタマーサクセスエンジニアなどのセールス機能があり、プロダクトオーナー (ロードマップを所有) と、サービスの開発と運用を行うエンジニアリングチームがいます。エンジニアリングチームは、サービスを測定する SLI を所有し、SLO を推進します。通常、プロダクトとエンジニアリングは SLA に情報を与える SLO を共同で所有しています。お客様は SLA を確認でき、サービスの状況を把握できますが、通常、SLO と SLI はサービスチームの境界を超えて共有されません。

How SLAs, SLOs, and SLIs interact

実効的な SLO

SLO は性能基準が満たされることを保証し、主要業績評価指標 (KPI) を達成するための実績データとして機能します。そのため、SLO は SMART (具体的、測定可能、達成可能、関連性がある、期限付き) である必要があります。SLO は、達成すべき目標を明確に定義し、進捗状況を測定する方法を提供し、現在のリソースと能力を考慮して現実的に目標を達成できることを保証し、ビジネス目標と一致し、目標達成のための期限を設定する必要があります。効果的な SLO の主な利点は、効果的な意思決定を可能にする可視性の向上と、事業の中断を効果的に防止するサービス品質の向上の２つです。これらは、カスタマーエクスペリエンスの評価に役立つ効果的な SLO のほんの一例です。

Effective SLOs

一般的な課題

SLO は、エンドユーザーとビジネスにとって何が最も重要かを効果的に優先順位付けするのに役立つ強力なツールです。しかし、導入には課題もあります。以下は、お客様の間でよく見られる課題の一部です。

SLI に適切なメトリクスをキャプチャする: 効果的な SLO の出発点は適切なメトリクスです。ただし、使用する適切なメトリクスを特定し、ビジネスに影響を与えるメトリクスを正しく計測できるようにサービスが実装されているかを確認することは難しい場合があります。
違反にいつ、どのように対応すべきかを知る: 適切なサービス、メトリクス、目標を特定したら、次の課題はエラーバジェットの計算方法と、バーンレートに基づく適切なレベルのアラートを作成する方法を知ることです。
SLO を診断ツールに接続する: SLO 違反に対して運用アラームに対応する予定がある場合、SLO の監視ツールとアプリケーションパフォーマンスのデバッグに使用するツールが連携していないと、SLO を満たしていない理由を特定するのが難しくなります。エクスペリエンスの繋がりが深いほど、より多くの洞察が得られ、SLO のパフォーマンスを向上させるために何に焦点を当てるべきかをより早く特定できます。

ベストプラクティス

組織におけるサービスレベル目標の導入を成功させるには、チーム間のコラボレーションが最も重要です。SLA を満たすための SLO を作成する際は、次のベストプラクティスを検討することをお勧めします。

全てのステークホルダーの目標を一致させる：効果的な SLO を設定する際、プロダクト、エンジニアリング、オペレーションの全てで目標を合わせることが重要です。この目標の統一により、信頼性を検査し改善する SLO の実践を強化できます。
100 % を達成するのは現実的ではない：好ましくないかもしれませんが、故障しないものはありません。そのため、100% の信頼性という目標を設定することは失敗の元になります。代わりに、達成すべき現実的な目標は何か、エンドユーザーはサービスに何を期待するかを考えてください。また、サービスは失敗したリクエストを再試行するように設計する必要があることを覚えておいてください。
対応計画を立てる（自動診断）： SLO 違反に対して、警告をいつ、どのように受け取るかを慎重に検討することが重要です。一部の運用イベントは、他のイベントよりも速くバーンレートを消費するため、より重大なアラートを必要とする場合があります。可能な限り、SLO に影響を及ぼすアプリケーションの問題を自動検知し、改善するための自動化を利用しましょう。
文書化し、共有し、オープンスタンダードを活用する：組織全体で SLO の採用を進める際は、チームが一貫したパターンを使用できるように、SLO の文書化と共有のための共通のフレームワークを用意しておくとよいでしょう。日次または週次の運用会議に SLO のレビューをどのように組み込むかを検討してください。
繰り返す（フィードバックループ、目標の再評価）：厳格なSLAとは異なり、SLO はより柔軟で、サービスの信頼性を向上させることを目的としています。SLO の目標を達成できているかを継続的に評価し、ビジネスとお客様にとって適切な信頼性のバランスを実現できるように繰り返すことが重要です。

Amazon CloudWatch でネイティブの SLO を作成する方法

Amazon CloudWatch Application Signals の導入により、AWS ネイティブで SLO を作成および監視できるようになりました。これらの SLO と Application Signals を使って、手動でのインストルメンテーション、メトリクス計算、観測された問題と根本原因の相関付けなどの作業なしに、重要なビジネス目標に対するアプリケーションのパフォーマンスを追跡できるようになります。CloudWatch Application Signals は、SLO を APM エクスペリエンスに接続できる包括的なアプリケーションパフォーマンス監視ソリューションを提供します。現在 CloudWatch で利用可能なメトリクスを使って SLO を開始できるため、簡単に使い始めることができます。

たとえば、ユーザーがログインしてワークアウトを確認したり、主要なフィットネスアクティビティを確認できるアプリケーションを提供するフィットネス会社で働いているとしましょう。このアプリケーションは、 Application Load Balancer (ALB) の背後にある EC2 インスタンスフリートで実行されます。ある日、サポートチームから、アプリにログインしてもワークアウトが表示されないという苦情がユーザーから寄せられているという緊急の通知が届きました。この問題を解決した後、同じようにエンドユーザー体験が低下させるような大規模な問題が発生したときに的確に把握できるように、可用性を監視する SLO を設定する必要があります。

CloudWatch に既にある ALB メトリクスを使用して可用性をモニタリングするための SLO を作成する方法を見てみましょう。この例では、1 分間のメトリクス期間においてリクエストの 95% が 28 日間にわたって99% 正常に処理されるという目標を設定します。これにより、毎分 95% を超えるリクエストの成功という期待どおりの結果が得られない場合に迅速に通知を受けることができます。また、すぐに対処する必要はないが、最終的には SLO 違反につながるような小さな問題を特定することもできます。

まず、左側のナビゲーションの Application Signals > サービスレベル目標 (SLO) を選択し、CloudWatch コンソールの SLO ダッシュボードに移動します。
次に SLO を作成 をクリックし、 SLI と SLO を定義します。
SLO のフォームから、サービスレベル目標 (SLO) 名を設定 フィールドに名前「My Availability SLO」を入力し、SLI に CloudWatch メトリクス を選択します。
次に、評価するメトリクスを選択します。このケースでは、アプリケーションが利用可能かどうかを評価したいとします。 CloudWatch メトリクスの Metric Math を使用して、1 分以内に 5xx エラーにならなかったリクエストの割合を計算します。CloudWatch メトリクスを選択 ボタンをクリックし、メトリクスの選択 ウィジェットを表示します。最初に名前空間 ApplicationELB を選択し、次に AppELB 別メトリクス を選択して ALB のメトリクスを検索します。次に、 RequestCount と HTTPCode_ELB_5XX_Count の 2 つのメトリクスを選択します。これら 2 つのメトリクスを使用して、5xx エラーを返さなかったリクエストの割合を計算し、アプリケーションの可用性を測定します。
RequestCount メトリクスと HTTPCode_ELB_5XX_Count メトリクスを選択したら、グラフ化したメトリクスタブを選択し、5xx エラーを返さなかったリクエストの割合を計算する数式を作成します。まず、両方のメトリクスの統計を サンプル数 に変更し、期間を 1 分 に変更します。RequestCount の ID を「totalrequests」に変更し、HTTPCode_ELB_5XX_Countm の ID を「failedrequests」に変更します。次に、数式を追加 を選択し、空の式で始まる を選択します。数式の編集で次の式を追加して成功したリクエストの割合を計算します。 ((totalrequests-failedrequests)/totalrequests)*100。最後に、CloudWatch メトリクスのウィンドウで選択される唯一のメトリクスが数式になるように元のメトリクスの選択を解除し、メトリクスの選択 をクリックします。
SLI に使用するメトリクスを定義したら、サービスがその目標を達成しているかどうかを示す条件を設定します。今回は 95 以下 をしきい値として設定します。つまり、リクエストの成功率が 95% 以下だった時間は不適格な時間と判定されるということです。
次に、SLO の目標とその目標をどのくらいの期間で測定するかを設定する必要があります。CloudWatch Application Signals では、SLO の時間間隔を選択する際に、ローリング日(連続日)とカレンダーか月の 2 つのオプションが用意されています。最長の期間は12 か月です。この例では、「28 ローリング」日を選択し、達成目標を 99% に設定します。また、警告のしきい値を設定を登録することで、SLO を警告状態として指定するタイミングを選択できます。
オプションで、SLI がしきい値を満たさないとき (SLI 状態アラーム) 、 SLO 目標に違反したとき（SLO 達成目標アラーム）、警告のしきい値を超えたとき（SLO 警告アラーム）に通知する 3 つのアラームを自動的に作成することができます。次に、SLOを作成 を選択します。
SLO を作成すると、数分以内に SLO ページに、達成度やエラーバジェットなどの SLO メトリクスが表示されます。また、 Application Signals は、より高度なアラームやダッシュボードのユースケースに使用できる達成度(AttainmentRate)とSLI 違反回数(BreachedCount) のメトリクスを公開しています。

次のステップ

Application Signalsを使用すると、ビジネスへの影響が大きいメトリクスに焦点を当てたサービスレベル目標 (SLO) を作成できます。これにより、重大な問題に優先順位を付け、ビジネス KPI との相関性を高めるために SLO を継続的に微調整できます。根本原因の特定を迅速化するために、Application Signals は CloudWatch Synthetics と連携して重要な API とユーザー操作を監視し、CloudWatch RUM と連携して実際のユーザーパフォーマンスを監視することで、アプリケーションのパフォーマンスを包括的に監視できます。

CloudWatch Application Signalsを使用すると、アプリケーションを手動でインストルメントしなくても、AWS上のアプリケーションのパフォーマンスを簡単に確認できます。利用方法については、このブログを参照してください。
re:Invent 2023 の動画では、JP モルガン・チェースが Amazon CloudWatch Application Signals を使用してビジネス目標に対するパフォーマンスをトラックした方法をご覧頂けます。
Amazon CloudWatch Application Signals を使用したアプリケーションモニタリングの詳細については、この YouTube 動画を確認してください。
この新機能を実際に体験するには、ハンズオンワークショップをご利用ください。ここでは、Amazon EC2 上で実行している Amazon EKS ワークロードをモニタリングするためにApplication Signals を使う方法を学べます。

結論

このブログでは、パフォーマンスを客観的に測定し、信頼性を正確に報告し、アラートによる混乱の軽減とインシデント発生時の迅速な対応を可能にすることで、チームを成功へと導く効果的な SLO のベストプラクティスについて説明しました。SLO の継続的な改善と定期的な見直しは、SLO が現実的であり続け、システムの機能とビジネス目標の両方と一致していることを確認するために不可欠です。また、パフォーマンスに影響する可能性のあるシステムへの変更は、関連する SLO の見直しのきっかけとなるはずです。もし、サポートが必要な場合は、AWS サポートや AWS アカウントチームにお問い合わせください。

著者について

本記事は、Improve application reliability with effective SLOs を翻訳したものです。翻訳はテクニカルアカウントマネージャーの日平が担当しました。

Amazon Web Services ブログ