NRUG#2 SLOモニタリングをNew Relicに移行した話

NRUG (New Relic User Group) Vol.2 SLOモニタリングを New Relicに移行した話 2022/3/16 Yuki Ando

Yuki Ando / あんどぅ AWS好きのSRE。New Relic初心者です！！！ 経済ニュースメディアのSREチーム所属 好きなNew Relicのサービス：APM、NRQL 好きなSREのプラクティス：SLO、非難なきポストモーテム文化 @integrated1453 JAWS-UG SRE支部 AWS認定ネットワーク本 2

今日話すこと （所属会社の事業やSREとは何かについては触れません） 1 SLOのモニタリングどうしていたか 2 New Relicにどうやって移行したか 3 所感 3

今日話すこと 1 SLOのモニタリングどうしていたか 2 New Relicにどうやって移行したか 3 所感 4

SREが関わるテーマ 信頼性に関わることすべて： SRE Book 目次より SLO トイルの撲滅 分散システムのモニタリング 自動化 リリースエンジニアリング インシデント対応 ポストモーテムと根本原因分析 オンコール対応 過負荷への対応 …etc 5

サービスレベル目標(SLO) 顧客体験(CUJ)からSLI/SLOを決め、SLOを基準にサイトの信頼性を維持していく POINT 01 02 03 クリティカルユーザー サービスレベル指標 サービスレベル目標 ジャーニー(CUJ) (SLI) (SLO) SLOの主眼は顧客体験の ユーザーにとって重要であ SLIで計測されるサービス 改善。ユーザーにとって重 ると考えられるサービスの レベルのターゲット値 要なサービス上のタスクの アウトカムに対する評価と 顧客が満足するレベルに ステップを補足する その計測方法 調整していく POINT POINT 6

サービスレベル目標(SLO) 顧客体験(CUJ)からSLI/SLOを決め、SLOを基準にサイトの信頼性を維持していく APIのリクエスト成功率 記事ページのレイテンシー をアクセスログから 計測する スマホアプリから プッシュ通知された最新の 経済ニュースを読みたい 100ms以内で応答した リクエストの割合>80% 可用性>99.8% POINT 01 02 03 クリティカルユーザー サービスレベル指標 サービスレベル目標 ジャーニー(CUJ) (SLI) (SLO) SLOの主眼は顧客体験の ユーザーにとって重要であ SLIで計測されるサービス 改善。ユーザーにとって重 ると考えられるサービスの レベルのターゲット値 要なサービス上のタスクの アウトカムに対する評価と 顧客が満足するレベルに ステップを補足する その計測方法 調整していく POINT POINT 7

SLI/SLOの実装をどうやっていたか アクセスログを集計してSLOダッシュボードを見てSlackに定期レポートを設定する AWS Cloud 会社共通のデータ基盤 Amazon ECS Metabase & Request Users Amazon S3 output bucket Application Load Balancer nginx Amazon Redshift SREs AWS Glue App fluentd Access Logs Pulse Slack 8

データ可視化ツールでSLOをモニタリング 日別のSLO達成状況やエラーの兆候をSREチームのスプリント計画や朝会で確認 Slackに Daily Stats 送信 9

SLOモニタリングの課題 アクセスログを集計する場合… SLOモニタリングのリアルタイム性が低い（DWHにアクセスログが連携されるタイムラグ） ダッシュボードにアクセスするたびにSQLが実行されて、Metabaseにキャッシュされてない場合 グラフの表示まで数分かかる（MTGの前に誰かがアクセスしてキャッシュしておくなど） SLO違反の原因を調査する時に、時間帯別・API別の深堀りをするためにSQLを書く必要があり、 結果が返ってくるまでに時間がかかり、エスカレーションが遅くなり、MTTRが伸びる 事業KPIをモニタリングするためのデータ可視化ツールは、SLOをモニタリングしたりトラブルシュー ティングに使うツールとしては色々と不便があった 10

今日話すこと 1 SLOのモニタリングどうしていたか 2 New Relicにどうやって移行したか 3 所感 11

New RelicでSLOモニタリングをするために New Relic APMがすでに導入されていたので可視化とアラートを設定した New Relic Oneダッシュボード New Relic APMをデータソースに同様のダッシュボードを構築 Service Levels(Beta) エラーバジェットの枯渇状況を複数のタイムウィンドウで確認 New Relic Alerts 任意のタイムウィンドウでSLO違反のアラートを作成 12

SLOモニタリングをNew Relicに変更 APMで取得するTransactionをもとにリクエスト成功率・レイテンシーをモニタリング AWS Cloud 会社共通のデータ基盤 Amazon ECS Metabase & Request Users Amazon S3 output bucket Application Load Balancer nginx Amazon Redshift AWS Glue SREs App Slack fluentd Transaction Alert notification 13

New Relic Oneダッシュボード SREチームが確認するダッシュボードをNew Relicに集める（NRQLを頑張って書きました） よかったこと モニタリングとトラブルシューティングが快適 ダッシュボードの表示が爆速 クエリ(NRQL)の応答が爆速 結果、MTTRの短縮にもつながる キャパシティ計画の洞察が得られる パフォーマンスと合わせて見がちなAWSの メトリクス(ECS ServiceのdesiredCount)を統合 14

New Relic Service Levels(Beta) 複数のタイムウィンドウでSLOのエラーバジェット枯渇状況を確認 長期(4週間)〜短期(1日)でSLOの達成状況を一望できる。Dailyの確認、Weeklyの確認それぞれで有用 エラーバジェットの枯渇状況に対するアラートは、今後対応予定とのこと（そのためAlertsにはNRQLを利用） 15

New Relic Alerts 任意のタイムウィンドウでSLOアラートをNRQLで定義 よかったこと アラート通知の柔軟さ NRQLなので細かくリクエスト 条件を絞り込める 任意のタイムウィンドウで 即時Slack通知 PagerDuty連携も可能 16

今日話すこと 1 SLOのモニタリングどうしていたか 2 New Relicにどうやって移行したか 3 所感 17

所感 NRQLを制するものはNew Relicを制する、と思いました New Relic Oneダッシュボード SLOモニタリングとトラブルシューティングが快適に。キャパシティ計画の洞察も得られる Service Levels(Beta) エラーバジェットの枯渇状況を長期と短期で知ることができ、対応の重要度・緊急度が判断できるように New Relic Alerts 柔軟なアラート条件と、SlackやPagerDutyとのインテグレーションで、「毎日見なくていい」状況に 18

＼ご清聴ありがとうございました／