オブザーバビリティが育むシステム理解と好奇心

by maru

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© LY Corporation © LY Corporation Public 自己紹介 @maru 2020: LINE に入社（LINE スタンプ/ 着せかえ/ タブのSRE ） 2022: LYP プレミアム立ち上げSRE 2023 以降: 新サービス立ち上げSRE 常にプロダクト開発のSRE として、開発チームと綿密にやりとりしつつ SRE チームのリーダーとして、マネジメントなども。 3 / 53

Slide 4

Slide 4 text

© LY Corporation © LY Corporation Public 担当しているプロダクトの特性色々なコンポーネントを限りなく省略すると、 LINE アプリのタブを開くと私たちのサービスがファミリーサービスから情報を集めてきて UI としてレンダリングできる形にして返します。 Read-heavy なシステムで、突発的なアクセスや想定外にも耐える必要があります。障害が発生すると、LINE アプリのユーザー体験が大きく損なわれます。 4 / 53

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© LY Corporation © LY Corporation Public オブザーバビリティ・エンジニアリングオブザーバビリティ・エンジニアリングの説明を引用すると... モニタリングとオブザーバビリティを分けるのは、システムの状態空間であり、さらにどのように状態空間を探索するか、どの程度の詳細さで探索するかということです。「状態空間」とは、システムが設計される段階から、開発される段階、テストされる段階、( 中略) 、さまざまな段階でシステムが示し得るすべての創発的なふるまいのことを指します。( 中略) オブザーバビリティがあれば、この状態空間を丹念にマッピングし、( 中略) システムの動作の分布をよりよく理解するために必要とされる( 中略) これに対し、モニタリングは、システムの健全性を大まかに把握するためのものです。引用: まえがき 8 / 53

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© LY Corporation © LY Corporation Public 例として、障害によるシステム理解このメンタルモデルと実システムがずれると、誤解や誤操作による障害が発生します。障害は、その“ ズレ” を修正する貴重な機会で、障害によるシステム理解といえます。しかし私たちのサービスでは、リリース後1 年半で障害はほぼありませんでした。安定稼働は良いことですが、障害を学びの機会にできなかったという課題もありました。 12 / 53

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© LY Corporation © LY Corporation Public ここまでの整理: 私たちの課題開発者とSRE は、異なるメンタルモデルを持っているようです。 Ops サイクルでは、障害が実システムとメンタルモデルのズレ解消の機会になります。障害が少ないと、そのズレの解消機会が訪れにくいです。オブザーバビリティツールは主にOps サイクルで拡充されがちです。その結果、開発者にとって使い慣れないツールになり、利用が避けられがちです。オブザーバビリティツールが活用されにくく、システム理解（メンタルモデルの構築）が難しくなっていました。 16 / 53

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© LY Corporation © LY Corporation Public GitHub PR ごとのPreview 環境の整備開発者がコードをマージせずに動作を確認できる環境を自動構築しました。 (Draft 含む)PR 作成時に Kubernetes 上に namespace を自動作成自動でアプリケーションをビルド・デプロイ LB/DNS/ メトリクス/ ログ収集まで全自動 PR クローズ時に環境を削除 → 本番と同じ観測データを、開発中にも取得できるようになりました。 22 / 53

Slide 23

Slide 23 text

© LY Corporation © LY Corporation Public カジュアルな負荷試験エコシステム Preview や開発環境はアクセスが少なく、意味のあるテレメトリを得にくいです。そこで、誰でも安全に実行できる負荷試験の仕組みを整えました。開発者自身がコメント1 つで負荷をかけられるモックサーバーにより他チーム依存を解消実行中の負荷試験は Grafana で可視化ローカル環境でも同じ試験を実施可能 → “ カジュアルに試す” ことで、観測が日常化しました。 23 / 53

Slide 24

Slide 24 text

© LY Corporation © LY Corporation Public 他の課題への対応（概要）このほかにも、負荷試験を気軽にできるように複数の工夫を実施しました。負荷試験実施時のレビューを最小限に負荷試験シナリオとパラメータを分離し再利用性を向上 RPS やDuration の変更はパラメータファイルの編集のみ過去と同一の負荷試験であれば、ヒストリの追加のみで実施可能負荷生成時のコミュニケーションが不要な環境分離を実現ローカル・Preview での並行実行、開発/ ステージングはGrafana で可視化誰が今負荷試験をしてるか、気にする必要がなくなった → 詳細は割愛しますが、どれも「安全に・簡単に試せること」を意識しています。 24 / 53

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© LY Corporation © LY Corporation Public 自動ロールバックにおけるスクレイピング間隔短縮の副作用デプロイ時に、エラー率やレイテンシーがしきい値を超えると、デプロイツールが異常を検知して対応を行います。明らかに異常と判断できる場合は、自動でロールバック人による判断が必要な場合は、デプロイを一時停止し、Slack に通知この仕組みは、スクレイピング間隔が短いほど異常検知の反応も早くなるため、間隔の短縮によって障害対応のスピードも向上しました。 31 / 53

Slide 32

Slide 32 text

Slide 33

Slide 33 text

© LY Corporation © LY Corporation Public ヒストグラム・バケットの活用では、単純にヒストグラムバケットで集計すればいいのかというと、実用上問題があります。等間隔なヒストグラムでメトリクスを出力する場合、集計してダッシュボードに表示する応答速度が犠牲になります。私たちの場合、15 分のダッシュボードは表示できるが、30 分は表示できない状態になりました。 * 時系列データが多くなりすぎるため 33 / 53

Slide 34

Slide 34 text

© LY Corporation © LY Corporation Public レイテンシーをHistogram Bucket 型のメトリクスにアプリケーションコードを修正し、Histogram Bucket の間隔などを個別にチューニング。実用に耐えるHistogram 型のレイテンシーメトリクスを出力するようにしました。 50ms ごとにカウント vs 解像度が必要なところだけ50ms ごと 34 / 53

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© LY Corporation © LY Corporation Public 開発環境で気づけるアラート管理負荷試験により、開発環境でも定期的な負荷をかけられるようになりました。 Preview 環境により、マージ前にもメトリクスを収集・集計できます。これにより、開発フェーズでも意味のあるアラートを設定でき、負荷がないと気づけない問題（例: レイテンシーの悪化）にも早く気づけるようになりました。しかし、アラートルールを開発環境などにももれなく設定することは従来の人手によるアラート設定では難しかったです。 36 / 53

Slide 37

Slide 37 text

© LY Corporation © LY Corporation Public Alert rules as Code の整備目的アラートをコードとして一元管理し、環境差異・属人運用を解消しきい値やラベルのみが異なるアラートを全環境に必ず設定変更は PR レビューと CI 検証を通す仕組み Terraform でアラート定義内製の監視プラットフォーム用にTerraform Provider も開発 CI で lint / policy / 生成物チェック cloudflare/pint でPrometheus alert rule lint OPA(Policy as Code) でRunbook 紐付け等を強制生成物（Alert YAML / しきい値）をPR 上でプレビュー 37 / 53

Slide 38

Slide 38 text

© LY Corporation © LY Corporation Public Alert rule as Code のBefore / After この変更によって、開発環境で気付ける問題が増加し、障害抑止へ観点 Before After 定義場所各環境で手作業・散在リポジトリに集約（Terraform ）差異管理人手管理でバラバラ Terraform で明示（差異は意図として記録）レビュー個人判断・口頭共有 PR レビュー必須（議論が履歴に残る）品質担保人力チェック CI でlint / policy / 生成物検証 Runbook 任意・未整備必須（OPA で強制）トレーサビリティ「なぜこの設定？」が失われる PR に理由・背景が残る 38 / 53

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© LY Corporation © LY Corporation Public 目的に基づくダッシュボードの整備従来のダッシュボードは、監視対象ごとにダッシュボードを用意していました。アプリケーションのダッシュボード DB のダッシュボードインフラのダッシュボード etc しかし、このダッシュボードだけでは、仮説を持って見なければ問題を発見しにくかったのです。「XXX が原因の可能性があるから、このダッシュボードをみよう... 」 42 / 53

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

© LY Corporation © LY Corporation Public ユーザーのキャッシュ利用状況の収集結果、95% 以上のユーザーが90% 以上のキャッシュヒット率を持つことがわかりました。キャッシュを多く保持しているユーザーは、表示に必要なデータをすでに持っています。そのため、一時的にエラーを返しても、ユーザー体験は大きく損なわれません。つまり、これは正常と言えるのかもしれません。 47 / 53

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© LY Corporation © LY Corporation Public “ 正常” とは何か？この負荷制御機能を導入する際に、チーム内で Graceful Degradation PJ を立ち上げました。実際のユーザー体験というのは、正常と異常の2 値ではありません。例えば、下記のように正常と異常はグラデーションになっています。アプリが全く使えない一部のコンテンツが更新されないアプリキルすると使えるけど、ときどき不安定になる使えるけど、遅い快適に使えるこのグラデーションを意図して設計するPJ を立ち上げ、その中で開発者と議論を深めています。 50 / 53

Slide 51

Slide 51 text

© LY Corporation © LY Corporation Public “ 正常” とは何か？そのPJ では、過去にこのような議論や問いがありました。エラーがあってもキャッシュで表示できるなら正常？認証エラーはクライアントが自動リトライするから、ユーザーは気づかないのでは？ SLO では、認証エラーは" 成功" にカウントしていい？リトライが1 回なら正常？ 3 回なら？期限切れの古いキャッシュは、どれくらい古いと異常？コンテンツの種類によるよね？「何を見れば、正常と言えるのか？」オブザーバビリティが、私たちに“ 考える問い” を与えてくれました。 “ “ 51 / 53

Slide 52

Slide 52 text

© LY Corporation © LY Corporation Public まとめ Dev サイクルでオブザーバビリティが活用できる環境の整備ユーザー体験に近い観測の整備と、問いと議論これらを通して、チームに少しずつオブザーバビリティの文化が浸透してきています。チームの議論は増え、また、答えが明確でないものも増えましたがおそらく良い方向に向かってると思います。リリースや障害対応のためのツールからシステムの理解と好奇心を育てる文化へ “ “ 52 / 53

Slide 53

Slide 53 text