チームを巻き込みエラーと向き合う技術

by maru

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© LY Corporation © LY Corporation Public SRE がチェスタトンのフェンスを立てていたチェスタトンのフェンス： SRE がやっていたこと：仕組みを増やす／変える（= 新しい柵を立てる）でも、その背景・意図・運用の勘所がSRE の中に閉じた属人化ならぬ属チーム化( 「あなたたちとわたしたち」状態) ログを追えば理解はできるが、SWE にとって自分のものという感覚ではなくなった今後、SWE が自律的に信頼性改善をする足枷になりそうだった理由が分からない柵（仕組み）を、先に壊すな。壊すなら“ なぜあるか” を理解してから “ “ 7 / 56

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© LY Corporation © LY Corporation Public このセッションでは「会話」にフォーカスします背景・意図・運用の勘所を残しながら、開発チーム(+SRE) で自律的に議論を進める姿技術や特定サービスの話というより、意思決定とすり合わせの話さらに公式のAskTheSpeaker に加えて、セッション内でもSlido でQ&A もやります。持ち時間の許す限り、双方向にしたいです。曖昧な質問や初歩的な質問も大歓迎です！ *Slido のQR コードは右上から 9 / 56

Slide 10

Slide 10 text

© LY Corporation © LY Corporation Public 伝えたいことどういう状況で、どこまで許容できるかを会話して設計する開発チーム、関係者を課題認識から巻き込む正常と異常は2 値ではなく、グラデーションなことを理解するサクサク動く少し遅いが使える一部エラーが出るが目的は達成できる見たことがある（古い）コンテンツが増える目的が達成できない異常時ハンドリングの実装は適切に後回しにするやる／やらないではなく、いつやるかを議論する Facebook のProduction Engineering のエンゲージモデルを紹介 10 / 56

Slide 11

Slide 11 text

© LY Corporation © LY Corporation Public 自己紹介 @maru 2020: LINE に入社（LINE スタンプ/ 着せかえ/ タブのSRE ） 2022: LYP プレミアム立ち上げSRE 2023 以降: 新サービス立ち上げSRE プロダクト開発に近い立場で、開発チームと日々協業しています。あわせてSRE チームのリードとして、意思決定や推進も担当しています。 11 / 56

Slide 12

Slide 12 text

© LY Corporation © LY Corporation Public 担当しているプロダクトの特性 LINE アプリのタブを開くと、私たちのサービスが複数のファミリーサービスから情報を集めます。それをUI にレンダリングできる形に変換して返します。 Read-heavy で、突発的なアクセスや想定外の事象にも耐える必要があります。障害が起きると、LINE アプリの体験に広く影響します。 12 / 56

Slide 13

Slide 13 text

© LY Corporation © LY Corporation Public 私たちの開発チームとの関わり方 Embedded SRE としてプロダクトチームに参加し、開発メンバーとして協業しています。先ほどの失敗談から学んで、各プロダクトチームにはSRE は1 人だけです。そのため、改善のためには開発チームとの密なコミュニケーションが必須です。最近は、 Federated( 連邦) Embedded SRE と自称しています。 13 / 56

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© LY Corporation © LY Corporation Public 議題1: API レスポンスに独自のエラーコードを入れるべき？例えば次のように、ステータスコードとは別にエラーコードを返すべき？レスポンスボディ（エンベロープ）パターン: { "meta": {"error_code": "ID_NOT_FOUND"}, "data": null } レスポンスヘッダのパターン: HTTP/1.1 404 Not Found Error-Code: ID_NOT_FOUND {"data": null} 16 / 56

Slide 17

Slide 17 text

© LY Corporation © LY Corporation Public 意見交換: 独自エラーコードを持つべきかユーザーが知る必要ないし、いらないんじゃない？パンダさんクライアント側が実装時にデバッグしやすくなるから、あると嬉しいトラさんでも、エラーコード粒度の合意コストが継続的にかかりそうパンダさんデバッグ目的なら、エラーコード以外の手段は？ウサギさんエラーコードの代わりにトレーシングID をクライアントのログに出そう SRE 17 / 56

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© LY Corporation © LY Corporation Public 意見交換: サーキットブレイカーの粒度サーキットブレイカーってどういう挙動なんだっけ？パンダさん今の実装は、エラー率が50% を超えたら10 秒オープン。その後10 秒は少量（数RPS ）だけ通し、それが成功してたらクローズ、失敗してたら再度オープン。トラさんファミリーサービス(upstream) 単位で十分な気がするね。パンダさんでも、 /path/to/api1 が常に成功して、 /path/to/api2 が常に失敗するケースだとサーキットブレイカーがon/off を繰り返しちゃうかも。トラさんパス単位だと、RPS が低いとサーキットブレイカーが反応しすぎちゃわない？パンダさん低RPS ではオープンしないように設定できるから、大丈夫そうトラさん 21 / 56

Slide 22

Slide 22 text

© LY Corporation © LY Corporation Public 意見交換: サーキットブレイカーのテスト実装はできたし、たぶん動くはずパンダさん念の為、自動のインテグレーションテストを作っておこう。ここにバグがあると、障害になるまで気づけないから。トラさんどうやってテストする？ Upstream のMock サーバーを毎回立ち上げて、障害注入して、リクエストして、サーキットブレイカーの起動を確認するの？パンダさんそうだね。時間が予定よりかかってもいいし、優先タスクがあれば調整するから、しっかり動くことを保証できる状態まで作り込もう。トラさん 22 / 56

Slide 23

Slide 23 text

© LY Corporation © LY Corporation Public 結果: パス単位でサーキットブレイカーを設定したどれだけ事前に想定できるかが重要。パス単位にしないと、on/off を繰り返してしまう可能性があるもしかすると、もっと細かな粒度にすべきかもしれない異常時ハンドリングは、実装1 行・テスト100 行のようなケースも多い。テストの実装は後回しにしないテストを後回しにするなら、実装も含めて後回しにした方が良いもしくは、テストが簡易的で済む範囲で実装する 23 / 56

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© LY Corporation © LY Corporation Public 意見交換: カナリアリリースのトラフィックルーティングどのユーザーが最初に新バージョンを触るべきか悩ましいね・・・。パンダさんカナリアリリースするからには、一般ユーザーに届く前にロールバックできた方がいいねトラさんドッグフーディングみたいなものだから、社内の人をカナリアへルーティングするのがいいんじゃない？ウサギさんそれなら送信元IP 使って、社内アクセスだけカナリアへ寄せれば十分かもパンダさんとはいえ、本番環境で問題があってロールバックしたことは今のところないよね一旦ランダムのカナリアリリース自体はできてるから、設計までして実装は保留でいいかトラさん 26 / 56

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© LY Corporation © LY Corporation Public 議題4: 最新コンテンツ取得に失敗したとき、エラーメッセージは？ユーザーの状況（電波など）やサーバーの状況によっては、 LINE アプリで表示するコンテンツを最新化できないことがある。その結果、古いキャッシュが表示される。古い表示は、誤った意思決定（例：価格）につながりうる。不正確な情報でユーザーに不利益が出ることは可能な限り防ぎたい。 29 / 56

Slide 30

Slide 30 text

© LY Corporation © LY Corporation Public 意見交換: コンテンツ最新化失敗時のエラーメッセージそもそも価格表示でキャッシュを使っていいんだっけ？パンダさん決済ページなどは当然ダメ。検索結果やレコメンド一覧は許容できるトラさんサーバー側のエラーとして返せばよさそうだねウサギさんサーバーに届かない、サーバーがレスポンスを返せないケースも対応したいかな SRE それならクライアント側で状態を見て出し分けるしかないね。でも、サーバーのエラーレスポンスが必要なメッセージもありそうじゃない？ウサギさんエラーメッセージの取り扱いポリシーを整理してみようトラさん 30 / 56

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© LY Corporation © LY Corporation Public 結果: エラーの文脈によって、責務を分けるユーザーの是正が必要なエラーユーザーの判断と訂正が必要（入力ミスなど）サーバー側がレスポンスで返す端末状態/ 表示状態に依存するエラーデータが古い／不整合で、誤った行動につながりうるクライアント側で文脈に応じて出し分ける補足: SRE は「決める」より「判断軸を守る」原則：議論は開発チームの自律性に任せる介入：短絡的に決まりそうなときだけ、判断軸を戻すサーバーサイドのレスポンスでは網羅できないケースの再確認 32 / 56

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© LY Corporation © LY Corporation Public 議題5: ファミリーサービス(Upstream) を過負荷から守るためのレートリミットテレビ番組や災害など、さまざまな理由で突発的な負荷が発生しうる。すべてのファミリーサービスが高負荷に耐えられる潤沢なリソースを持つとは限らない。 BFF レイヤーで、ファミリーサービスごとのレートリミッターが必要では？ 34 / 56

Slide 35

Slide 35 text

© LY Corporation © LY Corporation Public 意見交換: Upstream を守るレートリミット Upstream ごとに固定の制限値を持てば十分じゃない？パンダさんキャンペーンでUpstream がスケールアウトしても、BFF の制限値の変更する運用を忘れそう。 Upstream には余裕があるのにリクエストを拒否しちゃって障害になるよねウサギさん Upstream からのレスポンスに残りキャパシティ情報を付けてもらう？パンダさんそれはUpstream 側の仕様検討や実装の負担が大きすぎると思うトラさん Upstream からの Busy エラーをフィードバックにして、BFF の制限値を動的に変えよう SRE 35 / 56

Slide 36

Slide 36 text

© LY Corporation © LY Corporation Public 意見交換: Upstream を守るレートリミット Upstream からの Busy エラーをフィードバックにして、BFF の制限値を動的に変えよう SRE そうすると、Upstream からエラーが返ってくるまではトラフィックを流しちゃうけど大丈夫かな？トラさんむしろその方がいいと思う。Upstream 側のオートスケールで対応できる可能性もあるし私たちが勝手にリクエストを拒否してしまう方がサービス品質を悪化させかねない SRE この機能もなるべく早く実装しておいた方が良いだろうか実現はできそうだけど、開発工数が少し大きそうトラさん私の意見としては、サーキットブレイカーやスロットリング機能はすでにあるのでこの機能の優先度はそこまで高くない認識 SRE 36 / 56

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© LY Corporation © LY Corporation Public 結果: レートリミットの制限値をAIMD 制御で自動調整 busy レスポンスが返るまで、制限値を少しずつ緩和する busy レスポンスが返ったら、制限値を一気に厳しくする補足: SRE は「全部やる」ではなく、優先度を揃える既にCB/ スロットリングがあるなら、AIMD は“ 次の一手” 重要度とリスクで、いま作るもの／保留するものを整理する 38 / 56

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© LY Corporation © LY Corporation Public 意見交換: 過負荷時のアクセス拒否（優先度）ランダム拒否って、そんなに悪いんだっけ？パンダさんランダムだと、ユーザーによっては画面全体がエラーになるかもしれない特にLINE アプリを初めてインストールしたユーザーでは致命的トラさんサーバーに問題があっても、ユーザーが気づかず使えるのが理想だねウサギさん Netflix では、リクエストごとに優先度を付けて捨てる優先度付きロードシェディングがあるユーザーからのリクエストをいくつかの優先度に分類できれば良さそう SRE 41 / 56

Slide 42

Slide 42 text

© LY Corporation © LY Corporation Public 優先度付きロードシェディングリクエストを文脈に応じて分類し、優先度に応じて処理を遅延・拒否（捨てる）することで、重要な体験を守る方法。優先度は3 段階 NON_CRITICAL ユーザーが気づきにくい（ログ送信、キャッシュ更新など） DEGRADED_EXPERIENCE 気づくが致命的ではない CRITICAL 主要機能に影響する（表示できない等） 42 / 56

Slide 43

Slide 43 text

© LY Corporation © LY Corporation Public 意見交換: どこで優先度を計算する？私たちの場合、クライアントのキャッシュの有無で優先度を分類できそうパンダさん優先度はクライアント側で計算した方がよさそうかな？サーバー側が過負荷時に使う機能になるからトラさんクライアント実装だと、ストアでのリリースが必要で将来的な処理の変更が難しくなるねウサギさんサーバー側で計算しても問題ないか、負荷試験をしてから決めようトラさん 43 / 56

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© LY Corporation © LY Corporation Public 意見交換: 優先度の3 値に丸めるべきか？拒否するキャッシュヒット率を直接設定すれば十分じゃない？優先度を計算するコストもあるし、実装もちょっと複雑になるんだけどパンダさんたしかに、キャッシュヒット率を直接設定すれば柔軟になるねトラさん 3 段階の優先度にすることは、障害時のオペレーション速度の要だよ。レバーはシンプルにしないと、緊急時の作業は困ることになると思う SRE 障害時、責任者不在でも現場判断で切り替えられるようにする必要があるし将来、文脈を増やしても運用インターフェイスを変えずに済むからね。 SRE たしかに。3 段階の優先度に丸めるのは維持しようトラさん 45 / 56

Slide 46

Slide 46 text

© LY Corporation © LY Corporation Public 意見交換: 無限スクロールはどう扱う？無限スクロールのページはどうする？パンダさん毎回新しいコンテンツが多いから、キャッシュヒット率は下がりがちだねそうなると、過負荷でも拒否できないかもトラさんすでに十分見てるコンテンツはあるし、拒否するべきだよね？パンダさん深くスクロールして多くのコンテンツを消費するユーザーは重要。そのユーザーは優先したい Product Owner では、むしろ今の優先度のロジックで問題なさそうですねトラさん 46 / 56

Slide 47

Slide 47 text

© LY Corporation © LY Corporation Public 意見交換: 無限スクロールはどう扱う？では、むしろ今の優先度のロジックで問題なさそうですねトラさんでも、既視コンテンツが混ざるとヒット率が上がって優先されないかももっと明確に、コンテンツをたくさん消費したユーザーを優先度上げられないかなパンダさんスクロール量やすでに表示しているコンテンツの数をメタデータに含めると良さそうだね SRE 一旦現状の実装のまま行って、追加のメタデータはメトリクスを見て確認しようトラさん 47 / 56

Slide 48

Slide 48 text

© LY Corporation © LY Corporation Public 結果: 優先度付きロードシェディングを小さく実装負荷試験なども行いつつ、必要な議論を慎重に Product Owner も議論に含めて、ケースごとに議論補足: SRE はOps 視点で「運用できる仕様」にするために介入障害時に迷わない “ レバー” を設計する（3 値で丸める）将来の拡張を見据えて、抽象（優先度）を守る 48 / 56

Slide 49

Slide 49 text

Slide 50

Slide 50 text

© LY Corporation © LY Corporation Public このような議論ができるようになったきっかけ SRE として Graceful Degradation （上品な劣化）PJ を立ち上げて、場を作った。この場で、さまざまな障害時の振る舞い改善の提案が職種問わず出てきた。これによって関係者（プロダクトオーナー、開発者）全体で、障害は起きうるもの異常時でも、ユーザー体験を少しでも維持するという認識が揃い、異常時の挙動にチームとして意識が向くように。 50 / 56

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© LY Corporation © LY Corporation Public でも、その異常時のための処理はいつ実装すべき？エンジニアの開発リソースは常に不足している。異常時に備える実装の多くは、使われる頻度が低く、費用対効果が見えにくい。よくある成熟度モデル（5 段階など）は「十分成熟しているか」を教えてくれる一方で、いま何を優先すべきかどこまでやれば今は十分かの判断には使いにくいことがある。 52 / 56

Slide 53

Slide 53 text

© LY Corporation © LY Corporation Public スコア制の成熟度モデルのジレンマユーザーにとって重要なシステムほど、実験的な機能導入は慎重になりやすい。実験を目的とし、さまざまな試行錯誤がしやすい小さなサービスはスコアが上がりやすい。スコア制の成熟度だけでは、重要なシステムほど未熟で、小さなシステムほど優秀に見える。サービス間の成熟度比較によって、異常時ハンドリング実装の優先度を決めてしまうと、特に大きなシステムの開発者からすると納得しにくい場面がある。 53 / 56

Slide 54

Slide 54 text

Slide 55

Slide 55 text

© LY Corporation © LY Corporation Public Facebook のProduction Engineering のエンゲージモデル Facebook のSRE （Production Engineering ）のエンゲージモデルが参考になる。参照点はいま開発チームがどこに投資しているか。サービスのライフサイクルを意識して「今やるべきこと」を揃える。立ち上げフェーズにやるべきこと拡大フェーズにやるべきこと安定フェーズにやるべきことこれをベースにすると、異常時ハンドリングも「今はここまでにしておこう」という判断がしやすくなる。立ち上げ期に、SRE だけが0.1% 改善のチューニングへ偏るのはミスマッチ “ “ 55 / 56

Slide 56

Slide 56 text

© LY Corporation © LY Corporation Public まとめ & 質疑応答信頼性は「正解」を当てることではなく、会話で決め続けることでした。判断軸：異常を前提に、何を守るかを決める（重要度・優先度）レバー：過負荷や失敗時に、何を捨てるかを決める（ Load Shedding / 表示ポリシー / etc ）タイミング：やる/ やらないではなく、いつやるかを決める（PE Engagement model ）そして、その会話が回るように SRE は「決まったことの発信者」にならない 56 / 56