Application Signalsで始めるSLO ユーザー満足度を数値化する第一歩 #jawsfesta2024_d 浅見 則彦 / @rubihiko JAWS FESTA 2024 in 広島

浅見 則彦 / Asami Norihiko ● Work ○ ニフティ株式会社 SREチーム ● Communiy ○ AWS community builder | Cloud Operations ● 好きなAWSサービス ○ Amazon CloudWatch @rubihiko rubihiko

所属している会社について ネットワークサービス WEBサービス インターネット回線 生活インフラを支える 生活を豊かにする メディア・コンテンツ オプションサービス 格安スマホ

X NIFTY Developers エンジニアポータル NIFTY engineering @NIFTYDevelopers https://engineering.nifty.co.jp/ 当社エンジニアの発信について

本セッションについて 話すこと ● Application Signalsの概要と主要機能 ● SLI/SLOの基本概念と重要性 ● ユーザーが満足しているかどうかを可視化するには ● Application Signalsを使ったSLOの設定手順 話さないこと ● オブザーバビリティの実装について ● SLO以外の機能について(Synthetics Canaries, RUM, Evidently)

Application Signalsの概要と主要機能

Application Signals AWS ネイティブでSLOの 作成ができるように！！！

昨年のre:Inventで発表がありました ● AWS re:Invent 2023 - Keynote with Dr. Werner Vogels ○ https://youtu.be/UTRBVPvzt9w?si=ByHWl6IJRAmKC3Ou&t=3020 ● AWS re:Invent 2023 - [LAUNCH] Application monitoring for modern workloads (COP351) ○ https://youtu.be/T2TovTLje8w?si=gPFWo7u-n_lRCQ5r ● アプリケーションモニタリング (APM) 用の Amazon CloudWatch Application Signals の一般提供を開始 ○ https://aws.amazon.com/jp/about-aws/whats-new/2024/06/amazon-cloudwatch-ap plication-signals-application-monitoring/

主にサービスレベル目標(SLO)の機能に注目

Application Signals | サービス 対応プラットフォーム ● EKS ● EC2 ● Kubernetes ● ECS、その他 アプリケーションが計装（イ ンストゥルメンテーション） されており、テレメトリデー タを発信していれば表示さ れます 計装するには、以下を使う ● AWS Distro for OpenTelemetry （ADOT） ● CloudWatchエー ジェント

サービス | サービスオペレーション ● 機能一覧 ● SLI ● レイテンシー (p50, p90, p99) ● 障害 ● エラー ● 可用性 ● トレース ● など

Service Map アプリケーションの運用状態可視化 ● クライアント ● サービス ● 依存関係

サービスレベル目標 (SLO)

Synthetics Canaries, RUM, Evidently ● Synthetics Canaries: ○ 合成モニタリング、外形監視、Canaryという単位で実行されるスクリプトで監視できる ● RUM: ○ リアルタイムユーザーモニタリング、クライアント側のデータ分析できる ● Evidently: ○ フューチャーフラグ、A/Bテスト、新しい機能リリースを安全に検証できる

SLI/SLOの基本概念と重要性

SLI/SLOについて Application Signals の概念 https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/ja-JP/aws-native/app-m onitoring/application-signals/concepts “Service Level Indicator (SLI) - Service Level Objective (SLO) を達成しているかどうかを判断するために使用される指標です。SLI は、レイテ ンシや可用性など、ユーザーが実際に体験しているエクスペリエンスを表し、しき い値を使用してそれが許容できるエクスペリエンスかどうかを判断します。 Service Level Objective (SLO) - お客様の期待に対するサービスの信頼 性を監視するメカニズムです。SLO では、SLI を定義し、長期間にわたってサー ビスが SLI に準拠する頻度を示す達成目標を定義します。 例えば、 「GetResource API は、14日間のローリングで、1分間の99.9%が 1000ms未満のレイテンシを達成する」などです。”

SLI/SLO/SLA SLO(Service Level Object) サービスレベルの目指す べき目標のことで、SLIの 目標値になります。 SLA(Service Level Agreement) サービスレベルを保証す るユーザーとの合意のこ とで、契約です。 例) 対象サービスの30日間の稼 働率が99%以上を保証する。下 回った場合は全額返金する。 例) 対象サービス(機能)の30日 間のリクエストの成功率(SLI)の目 標値は99.9%とする SLI(Service Level Indicator) サービスレベルの指標の ことで、可用性やレイテン シーなどがよく使われま す。 例) 対象サービス(機能)のリクエ ストの成功率を指標とする サービスの信頼性と性能を測定・管理するための重要な概念です

基本的な計算式 例: あるAPIエンドポイントの1000リクエスト中、5XXが100リクエストあった場合の信頼性は・・・ ● 良いリクエスト: 900 (5XX以外のリクエスト数) ● 悪いリクエスト: 100 (5XXのリクエスト数) ● 有効なリクエスト: 900+100=1000 (良いリクエストと悪いリクエストの合計) ● (900 / 1000) * 100 = 90% The Art of SLOs より https://sre.google/intl/ALL_jp/reso urces/practices-and-processes/art -of-slos/ × 100 良いイベント 有効なイベント SLI[%] =

Application Signalsでは以下のよう計算 “SLI には、Application Signals で収集した新規の標準アプリケーションメトリクスの 1 つ、あるいは、任意の CloudWatch メトリクスまたはメトリクス式を使用できます。標準ア プリケーションメトリクスとして SLI に使用できるのは、Latency と Availability です。 Availability は、成功の応答をリクエストの合計で割った数値で表し、(1 - 障害率)*100 のように計算します。ここでの Fault 応答数は 5xx エラーの件数を意味し、成功の応答と は 5XX エラーのない応答を指します。4XX 応答は成功の応答と見なされます。” https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html ● 障害率が10％だとすると ● (1 - 0.1) * 100 = 90％

エラーバジェットについて エラーバジェット = 1 - SLO 期間ベースの SLO のエラーバジェットと達成度の計算 https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWat ch-ServiceLevelObjectives.html#CloudWatch-ServiceLevelObjectives-budget リクエストベースの SLO のエラーバジェットと達成度の計算 https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Service LevelObjectives.html#CloudWatch-ServiceLevelObjectives-budget-request ● 期間ベース(残り時間で表現) ● リクエストベース(残りカウントで表現) 許容できるエラーの予算

SLI、SLO、エラーバジェットがあると ● 今、このサービスは使えているのか・使えていないのか分かるようになる ● ユーザーは満足しているのかどうか、分かるようになる ● ビジネス判断にも活用できる 「ユーザーに提供する機能はこのくらいの性能を維持しておけ ば満足してくれるだろう」 「品質が一定以上（エラーバジェットが残っている状態)なら、開 発をどんどんしよう（ビジネスを加速させよう）という判断がで きる」

ユーザーが満足しているかどうかを 可視化するには

(クリティカル) ユーザージャーニー

(クリティカル) ユーザージャーニー ステージ ユーザーの行動 タッチポイント ユーザーの思考 ユーザーの感情 機会 発見 ウェブサイトを見つける 検索エンジン/紹介 「オンラインで予約できるクリニックがあ るんだ」 興味 (+) SEO最適化、口コミ促進プログラム 登録 アカウント作成 登録ページ 「必要な情報は最小限で良いな」 安心 (+) ソーシャルログインの追加 ペット登録 ペット情報入力 ペット登録フォーム 「詳細な情報を入力できるのは良いけ ど、少し面倒かな」 やや煩わしさ (-) フォームの簡素化、段階的な情報収集 予約 獣医と日時の選択 予約ページ 「空き状況が一目で分かって便利」 満足 (++) AIによる最適な予約時間の提案 診療前 リマインダー確認 Eメール/アプリ通知 「忘れずに済んで助かる」 安心 (+) 予約変更のワンクリック対応 診療 クリニック訪問・診療 実際のクリニック 「予約情報とペット情報が連携していてス ムーズ」 満足 (++) クリニックでのデジタルチェックイン フォローアップ 診療記録確認 アプリ/ウェブサイト 「次回のケアが分かりやすい」 安心 (+) ペットの健康状態グラフ化 継続利用 次回予約・情報更新 アプリ/ウェブサイト 「定期的なケアが簡単に管理できる」 満足 (++) ロイヤリティプログラムの導入

SLOドキュメントに落とし込む カテゴリ 機能 SLI SLO ウィンドウ 可用性 GET /owners/*/pets/{petId}/visits 1分間の成功したリクエストの割合 99% 7, 14, 28日 可用性 POST /owners/*/pets/{petId}/visits 1分間の成功したリクエストの割合 99.5% 1日 レイテンシ GET /owners/*/pets/{petId}/visits ５分間の P50 レイテンシー < 100ms P90 レイテンシー < 300ms P99 レイテンシー < 500ms 99.9% 3, 7, 14日 レイテンシ POST /owners/*/pets/{petId}/visits ５分間の P50 レイテンシー < 200ms P90 レイテンシー < 500ms P99 レイテンシー < 800ms 99.9% 3, 7, 14日 エラー POST /owners/*/pets/{petId}/visits １５分間のエラー率 < 0.1% 99.9% 1日

Application Signalsを使ったSLOの設定 手順

SLO ドキュメント

サービスから作成

Service Mapから作成

サービスレベル目標(SLO)から作成

SLI/SLOの設定 タイプ サービスオペレーション CloudWatch メトリクス 計算方法 ● 期間ベース ● リクエストベース 条件 ● 可用性 ● レイテンシー

SLI/SLO作成 (期間ベース - 可用性) SLI: ５分間におけるオペレーションの可用性が99.9%であれば、正常と判 断とする ● 条件: 可用性が99.9%以上 ● 評価期間: 5分 (1分, 5分, 15分) ● 機能を指定 ● 期間を指定 ● 可用性を指定

SLI/SLO作成 (期間ベース - 可用性) SLO: １日に99%以上を維持することを目標とする ● SLO測定の間隔: 1日 （1,3,7,14,28やカレンダー選択も（１ヶ月等）） ● 達成目標値: 99% エラーバジェット: 1日に14.4分 ● 1% (=1-SLO=1-0.99=0.01) ● 1440分 (=1日 * 24 * 60) ● 14.4分(=１４４０分 * 1%)

SLI/SLO作成 (期間ベース - レイテンシー) ● レイテンシーだとXXms以下という条件 ● 統計には、p50,p90,p99 (パーセンタイル)を用いる

SLI/SLOの作成(リクエストベース - 可用性) SLI: 良いリクエストの割合 ● 悪いリクエスト: 5XXのカウント ● 良いリクエスト: それ以外

SLI/SLOの作成(リクエストベース - 可用性) SLO: 1日に80%以上を維持すること目標とする ● 間隔: 1日,3日,7日,28日 など間隔を指定 ● 達成目標: 80%など エラーバジェット: １日リクエストの20% ● 20% (=1-SLO=1-0.8=0.2) ● 予算: 20リクエスト (=有効なリクエスト * エラーバジェット = 100 * 0.2) ● 減少例） ○ 悪いリクエスト: 10 ○ 残り予算: 10リクエスト (=予算 - 悪いリクエスト = 20 - 10)

SLI/SLOの作成（リクエストベース - レイテンシー） ● レイテンシーだとXXms以下という条件 ● 統計には、p50,p90,p99 (パーセンタイル)を用いる ● XXms以上だと悪いリクエストとしてカウント

CloudWatch メトリクスでSLO作成 (期間ベース) ● 基本的な作成方法は同じ ● サービスオペレーションが使えな い場合（計装されていない場合)で もCloudWatchメトリクスより SLI/SLOが作成可能 ● 任意のメトリクスを選択可能 ● 正常となる条件を指定

CloudWatch メトリクスでSLO作成 (リクエストベース) リクエストベースの場合 ● ターゲットリクエスト ○ Good Requests ○ Bad Requests ● 合計リクエスト (ターゲットリクエスト / 合計リクエスト) * 100

メトリクスベースならより細かな指定も可能 ● 良いイベント、悪いイベントを任意のメトリクスとして定義し使用可能 ● より柔軟なSLI/SLOの作成が可能

SLOダッシュボード

まとめ ● Application SignalsはAWSネイティブでSLO作れる ● ユーザージャーニーから機能を洗い出すと効果的に SLI/SLOを決めることができる ● SLOドキュメントからApplication Signalsの設定に落と し込むと作りやすい ● 計装していなくても、CloudWatchメトリクスベース SLI/SLOを作成することができる ● SLOダッシュボードを活用すると誰でもサービスが使える かどうか、ユーザーが満足しているかどうか分かる

学習コンテンツ ● Application Signalsを使用したアプリケーションパフォーマンスモニタリング ○ https://catalog.workshops.aws/observability/ja-JP/aws-native/app-monitor ing/application-signals ● opsjaws-application-signals-handson ○ https://github.com/YoshiiRyo1/opsjaws-application-signals-handson ● Service level objectives (SLOs) ○ https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cloud Watch-ServiceLevelObjectives.html ● Application Signals ○ https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cloud Watch-Application-Monitoring-Sections.html ● SRE Books ○ https://sre.google/books/ ● The Art of SLOs ○ https://sre.google/intl/ALL_jp/resources/practices-and-processes/art-of-sl os/

ありがとうございました