7.8K Views
May 23, 23
スライド概要
オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜 のLT資料です
https://findy.connpass.com/event/281991/
経済ニュースアプリのSREの仕事をしています。
New Relic Service LevelsとバーンレートアラートをCDK for Terraformで設定して SLOモニタリングをセルフサービス化した話 株式会社ニューズピックス 安藤裕紀 2023.5.23 オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜LT
00 自己紹介 安藤 裕紀 / Yuki Ando NewsPicks SREエンジニア 大手SIerで10年半エンジニア/アーキテクトとしてアプリケーション開発、イ ンフラ構築、クラウド活用コンサルティングなど大企業の技術支援を行った 後、2021年10月よりニューズピックス入社。 現在の仕事はSREチームのリードとエンジニア採用の推進。 ©NewsPicks Inc. All Rights Reserved.
00 本日お話すること 課題(Why) サービス運用と SLOモニタリングの 課題 ©NewsPicks Inc. All Rights Reserved. 技術選定(What) 解決策(How) 課題を解決するための 手段と採用技術の検 討 New Relic Service Levelsとバーンレート アラートをCDK for Terraformで設定して SLOモニタリングをセ ルフサービス化
00 本日お話すること 課題(Why) サービス運用と SLOモニタリングの 課題 技術選定(What) 解決策(How) 課題を解決するための 手段と採用技術の検 討 New Relic Service Levelsとバーンレート アラートをCDK for Terraformで設定して SLOモニタリングをセ ルフサービス化 本日の話: SLOモニタリングの課題と、解決するための技術選定について ©NewsPicks Inc. All Rights Reserved.
00 目次 1. SLOモニタリングの課題 2. 課題解決手段と採用技術の検討 3. 導入の効果と今後の展望 ©NewsPicks Inc. All Rights Reserved.
01 SLOモニタリングの課題 ©NewsPicks Inc. All Rights Reserved.
01 サービスレベル目標(SLO) 顧客体験(CUJ)からSLI/SLOを決め、SLOを基準にサイトの信頼性を維持していく ©NewsPicks Inc. All Rights Reserved.
01 SLOモニタリングするぞ〜〜〜 ひとまずSLIの現状をもとに教科書的なSLOを設定 SLIの種類 SLI ユーザーのタイプ SLO 可用性 リクエスト成功率 モバイルアプリ 99.9%以上 Web 99.8%以上 モバイルアプリ 90%以上 Web 80%以上 モバイルアプリ 99%以上 Web 95%以上 レイテンシー 100ms以内のレスポンス 1000ms以内のレスポンス ©NewsPicks Inc. All Rights Reserved.
01 SLOの準拠/違反の状況を週次でモニタリングしていくと… Webのレイテンシーが問題ということしかわからない。この状態からどうする? SLIの種類 SLI ユーザーのタイプ SLO 可用性 リクエスト成功率 モバイルアプリ 99.9%以上 Web 99.8%以上 モバイルアプリ 90%以上 Web 80%以上 モバイルアプリ 99%以上 Web 95%以上 レイテンシー 100ms以内のレスポンス 1000ms以内のレスポンス ©NewsPicks Inc. All Rights Reserved.
01 教科書的なエラーバジェットポリシーでは 「サイトリライアビリティワークブック 付録B エラーバジェットポリシー」より SLO違反のポリシー 以下の場合、チームは 機能の開発作業の代わりに信頼性に関する作業をしなければならない。 ○ ○ ○ コードのバグあるいは手続き的なエラーがサービスそのもののエラーバジェット超過を引き起こした。 ポストモーテムによって強い依存性を和らげる必要が明らかになった。 分類を間違えられたエラーが、サービスのSLO違反の原因となるようにエラーバジェットを きちんと消費しなかった。 「信頼性こそが、あらゆるプロダクトの基本的な機能である」という SREの発想のもと、 SLO/エラーバジェットポリシーが信頼性の門番として機能するようにみえる ©NewsPicks Inc. All Rights Reserved.
01 つまりこういうこと? SLOをモニタリングして、SREが信頼性の門番になる? ©NewsPicks Inc. All Rights Reserved.
01 つまりこういうこと? SLOをモニタリングして、SREが信頼性の門番になる? ©NewsPicks Inc. All Rights Reserved.
SLO違反したら全開発チームの作業止めるとか 現実的にはありえないですよね ©NewsPicks Inc. All Rights Reserved.
01 SRE実施のフェーズ 「SREの探求 22章 成功の文化としての SRE」より ● フェーズ1 : 消火活動/事後対応 「システムを何とか動かし続ける」と同時に、自動化を通じて新たなアプローチを構築 ● フェーズ2 : 門番 プロダクションシステムに対する変更は必ず承認を受けて通過しなければならない唯一の関門として機能する ● フェーズ3 : 支持者/パートナー 合意したターゲットをパートナーが達成し、その後も引き続き満足していけるように支援する ● フェーズ4 : 触媒 あらゆるサービスの構想から廃止までに関与して、適切なツールを提供できるように支援する ©NewsPicks Inc. All Rights Reserved.
01 SRE実施のフェーズ 「SREの探求 22章 成功の文化としての SRE」より ● フェーズ1 : 消火活動/事後対応 「システムを何とか動かし続ける」と同時に、自動化を通じて新たなアプローチを構築 ● フェーズ2 : 門番 プロダクションシステムに対する変更は必ず承認を受けて通過しなければならない唯一の関門として機能する ● フェーズ3 : 支持者/パートナー 門番フェーズを超えて 支持者/パートナーを目指す 合意したターゲットをパートナーが達成し、その後も引き続き満足していけるように支援する ● フェーズ4 : 触媒 あらゆるサービスの構想から廃止までに関与して、適切なツールを提供できるように支援する ©NewsPicks Inc. All Rights Reserved.
01 「門番」から「支持者/パートナー」へ Google CloudのBlogにも同様のことが書いてあります https://cloud.google.com/blog/ja/products/gcp/consequences-of-slo-violationscre-life-lessons SLO の規定内でサービスが稼働していたとしても、積極的に信頼性を向上させることは、障害の 将来的なリスクを抑え、効率性を改善し、そしてコスト削減につながります。 一方、SLO を満たしていないからといって、すぐに内部での機能開発を完全にやめてしまう組織 はほとんどありません。 (中略) 関連する開発チームにも知らせましょう。このプロセスは手動でもかまいません。 SRE チームは違反をフィルターにかけて集約し、意味のあるコンテキストを提供するなど価値を 付け加えることも可能です。 ©NewsPicks Inc. All Rights Reserved.
01 つまりこっちですね 開発チームがSLOのモニタリングと改善を自走できるまで、サポートをする ©NewsPicks Inc. All Rights Reserved.
/ エラーバジェットを消費する原因となった機能と 担当チームを素早く特定して、信頼性を回復するため の情報提供をしたい \ ©NewsPicks Inc. All Rights Reserved.
01 この状態から… Webのレイテンシーが問題ということしかわからない。この状態からどうする? SLIの種類 SLI ユーザーのタイプ SLO 可用性 リクエスト成功率 モバイルアプリ 99.9%以上 Web 99.8%以上 モバイルアプリ 90%以上 Web 80%以上 モバイルアプリ 99%以上 Web 95%以上 レイテンシー 100ms以内のレスポンス 1000ms以内のレスポンス ©NewsPicks Inc. All Rights Reserved.
01 こうなりたい 開発チームがSLOのモニタリングと改善を自走できるまで、サポートをする ©NewsPicks Inc. All Rights Reserved.
01 SLO違反からエスカレーションまでの調査 主にNew Relicを利用して、SLO違反から特定エンドポイントの更新に辿り着く SLO違反タイミングの特定 デプロイの特定 (Deployment Marker) デプロイしたユーザーとrevisionを特定し、 開発チームにリリース内容の影響を確認 ©NewsPicks Inc. All Rights Reserved.
01 エスカレーション100本ノックをしました 担当チームのSlackチャンネルにお伺いする ©NewsPicks Inc. All Rights Reserved.
01 ここからがSite Reliability Engineeringですよ ソフトウェアによる信頼性の確保とトイルの削減 これを自動化・セルフサービス化する ©NewsPicks Inc. All Rights Reserved.
02 課題解決手段と採用技術の検討 ©NewsPicks Inc. All Rights Reserved.
02 クリティカルユーザージャーニーに立ち返る SREチームがCUJを補足するのは難しいので、各開発チームに見てもらう ©NewsPicks Inc. All Rights Reserved.
02 解決すべき課題とその対応 分類 課題 / 要望 対応方針 開発者にとって New Relicに詳しくなくても エンドポイントとSLOを 簡単に設定したい ● configファイルにチームの監視対象エンドポイントを設定すればチーム用 New Relicダッシュボードが自動生成されるようにする ● エンドポイントのSLO違反から原因となったリリースのDeployment Markerを ダッシュボード上で特定できるようにする 自チームのSlackチャンネルに 通知を受け取りたい ● New Relic AlertsのSlack通知Workflowを、 上記configファイルをもとにチーム別に設定する NRQLやダッシュボードの IaC化 ● SLOの修正のたびにダッシュボード、NRQL、Alertsの設定を変えて回るのが 大変なのでIaCで共通化したい ● 普段はAWS CDKとTypeScriptで開発しているので開発体験を共通化したい バーンレートアラートの閾値自動 計算ロジックのコード化 ● New RelicのWebポータルからバーンレートアラートを設定するとAlertsの閾 値が自動設定されるが、IaCの場合は自分で決める必要がある。これをコード 化して自動計算するようにしたい SRE (インフラ担当) にとって ©NewsPicks Inc. All Rights Reserved.
02 できあがったもの エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©NewsPicks Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow
02 開発者はエンドポイントとSLOを設定してPR出すだけ エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 設定(PR) CDK for Terraform 反映 cdktf deploy ダッシュボード 確認 チームチャンネル に通知 New Relic Slack アラート ● APIエンドポイント ● SLOターゲット ● ターゲットレイテンシー目標 ● 担当チーム ©NewsPicks Inc. All Rights Reserved. ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow
02 cdktf deployでNew Relicのリソース一式が反映される エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©NewsPicks Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow
02 SLO・バーンレートからアラート閾値の自動設定 これはCDK for Terraform + TypeScriptの大きな利点 エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©NewsPicks Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow
02 アラートを受けてダッシュボードを見れば、SLO違反の 原因となったエンドポイント・デプロイの特定まで可能 エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) ダッシュボードにチーム別のタブがあり cdktf deploy チームの担当エンドポイントを確認できる ダッシュボード 確認 チームチャンネル に通知 Slack アラート New Relic ● Service Levels ● Dashboard ● AlertPolicy ● AlertConfition SLO準拠状況タイムライン ● Workflow APMのTransaction / DeploymentMarker ©NewsPicks Inc. All Rights Reserved.
03 導入の効果と今後の展望 ©NewsPicks Inc. All Rights Reserved.
03 ● 導入の効果と今後の展望 導入の効果 ○ configに追加するだけでSLOモニタリングのダッシュボードとアラートが作成できる 仕組みがあることで、SLO違反のエスカレーションをするたびに 「SLOモニタリング、やってみません?」と声掛けがしやすくなった ○ 開発チームにとっても、Service Levels、Dashboard、NRQL、Alertsの使い方を覚える ハードルが下がるのでSLOモニタリングをはじめやすくなった ○ ● TypeScript + CDK for TeraformでソフトウェアとしてSLMをメンテできるのは体験が良い 今後の展望 ○ 現在はリクエストベースの可用性・レイテンシーだが、ユーザー割合ベースの可用性・ レイテンシーを確認したいという要望があった。configとNRQLを作ってサービス化予定 ○ 現在はPRをマージ後手動cdktf deployだが、dev環境で気軽に試してCI/CDできるようにする ©NewsPicks Inc. All Rights Reserved.
ご清聴ありがとうございました! NewsPicksではエンジニアを積極採用中です! https://tech.newspicks.com ©NewsPicks Inc. All Rights Reserved.