Start graceful degradation

『障害を前提に準備する』
LINE株式会社 Toshiya Kato(@maruloop https://twitter.com/maruloop )

SRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会
https://findy.connpass.com/event/281605/

1. ো֐Λલఏʹ४උ͢Δ 
   43&େू߹ʂΈΜͳͰֶͿɺ৴པੑΛߴΊΔऔΓ૊Έ-5େձ Ճ౻
   ढ़໻ !NBSVMPPQ -*/&גࣜձࣾ
   $PNNVOJDBUJPO
   
   4FSWJDF
   JOUFHSBUJPOࣨ
   43&5FDI-FBET -*/&ελϯϓ
   
   ண͔ͤ͑
   
   ֆจࣈ
   
   ΢ΥϨοτλϒ
   
   ϗʔϜλϒ
2. WebAPIのエラー時に ユーザーにはどのように表示されるか 把握してますか？
3. Graceful degradationのはじめ方
4. Graceful degradation(上品な劣化)とは？ 障害などでサービスの提供が限定的になった時に、サービス全体を停止させるのではなく、機能 単位で停止できるようにしておくという考え方。 例： パーソナライズドされたレコメンデーションを表示できない時に、 共有のレコメンデーションへフォールバックするなど。
5. どのように進めたか？ 1 2 3 4 API * UserID単位でエラー注入できるようにする 現在のエラーハンドリングを知る 改善できそうな箇所をリストアップ&議論 日々のタスクの中で、改善していく
6. どのように進めたか？ 1 2 3 4 API * UserID単位でエラー注入できるようにする 現在のエラーハンドリングを知る 改善できそうな箇所をリストアップ&議論 日々のタスクの中で、改善していく
7. 私たちの基本的なアーキテクチャ • 実際のビジネスロジックは各マイクロサービスで実施 • クライアントとサーバーサイドの間にgatewayがある • 認証や流量制限などの機能を持つ LINE App Gateway Microservice Microservice Microservice Microservice Microservice Microservice 認証 流量制限 Etc…
8. 私たちの基本的なアーキテクチャ • 実際のビジネスロジックは各マイクロサービスで実施 • クライアントとサーバーサイドの間にgatewayがある • 認証や流量制限などの機能を持つ LINE App Gateway Microservice Microservice Microservice Microservice Microservice Microservice 認証 流量制限 Etc… 流量制限の機能を流用すれば、User * API単位にエラー注入ができそう！
9. どのように進めたか？ 1 2 3 4 API * UserID単位でエラー注入できるようにする 現在のエラーハンドリングを知る 改善できそうな箇所をリストアップ&議論 日々のタスクの中で、改善していく
10. 現在のエラーハンドリングを知る “誰が”現在の状態を把握しておくべきか？
11. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること
12. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい
13. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
14. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
15. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい 企画サイド(プロダクトオーナー)
16. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい 企画サイド(プロダクトオーナー) エラーハンドリングの改善を日々行なってほしい 新規開発では、エラー注入タスクを含めるようにして欲しい
17. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい 企画サイド(プロダクトオーナー) エラーハンドリングの改善を日々行なってほしい 新規開発では、エラー注入タスクを含めるようにして欲しい スクラムマスター
18. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい 企画サイド(プロダクトオーナー) エラーハンドリングの改善を日々行なってほしい 新規開発では、エラー注入タスクを含めるようにして欲しい スクラムマスター 流量制限の影響を認識して欲しい
19. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい 企画サイド(プロダクトオーナー) エラーハンドリングの改善を日々行なってほしい 新規開発では、エラー注入タスクを含めるようにして欲しい スクラムマスター 流量制限の影響を認識して欲しい サーバーサイドエンジニア
20. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい 企画サイド(プロダクトオーナー) エラーハンドリングの改善を日々行なってほしい 新規開発では、エラー注入タスクを含めるようにして欲しい スクラムマスター 流量制限の影響を認識して欲しい サーバーサイドエンジニア プロの視点から、さまざまな影響を確認して欲しい
21. 現在のエラーハンドリングを知る このプラクティスを進行する上で期待すること 既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア 新機能開発で、エラーハンドリングを意識した仕様を考えてほしい 企画サイド(プロダクトオーナー) エラーハンドリングの改善を日々行なってほしい 新規開発では、エラー注入タスクを含めるようにして欲しい スクラムマスター 流量制限の影響を認識して欲しい サーバーサイドエンジニア プロの視点から、さまざまな影響を確認して欲しい QAエンジニア
22. エラー注入のワークショップを開催 • 参加者： • 企画/スクラムマスター • サーバーサイドエンジニア • クライアントサイドエンジニア • QAエンジニア • 時間：1時間/回 • 頻度： (今のところ)1回/年 • 環境：開発環境
23. エラー注入のワークショップを開催 • 参加者： • 企画/スクラムマスター • サーバーサイドエンジニア • クライアントサイドエンジニア • QAエンジニア • 時間：1時間/回 • 頻度： (今のところ)1回/年 • 環境：開発環境 進め方 1. 事前にAPI一覧をアクセス数順に準備 全APIを確認するのは時間がかかりすぎるため 優先度をアクセス数でつける
24. エラー注入のワークショップを開催 • 参加者： • 企画/スクラムマスター • サーバーサイドエンジニア • クライアントサイドエンジニア • QAエンジニア • 時間：1時間/回 • 頻度： (今のところ)1回/年 • 環境：開発環境 進め方 1. 事前にAPI一覧をアクセス数順に準備 2. APIごとにエラー注入を行う
25. エラー注入のワークショップを開催 • 参加者： • 企画/スクラムマスター • サーバーサイドエンジニア • クライアントサイドエンジニア • QAエンジニア • 時間：1時間/回 • 頻度： (今のところ)1回/年 • 環境：開発環境 進め方 1. 事前にAPI一覧をアクセス数順に準備 2. APIごとにエラー注入を行う 3. みんなで影響を確認
26. エラー注入のワークショップを開催 • 参加者： • 企画/スクラムマスター • サーバーサイドエンジニア • クライアントサイドエンジニア • QAエンジニア • 時間：1時間/回 • 頻度： (今のところ)1回/年 • 環境：開発環境 進め方 1. 事前にAPI一覧をアクセス数順に準備 2. APIごとにエラー注入を行う 3. みんなで影響を確認 4. APIの重要度をランクづけ 1. High: ユーザー体験に致命的なダメージ 2. Middle: ユーザーは気づくが、不満は少なそう 3. Low: ユーザーは気づかない Rank Example High スタンプの購入ができない Middle レコメンドが表示されない Low 内部的なログの送信, 日次同期の失敗
27. エラー注入のワークショップを開催 • 参加者： • 企画/スクラムマスター • サーバーサイドエンジニア • クライアントサイドエンジニア • QAエンジニア • 時間：1時間/回 • 頻度： (今のところ)1回/年 • 環境：開発環境 進め方 1. 事前にAPI一覧をアクセス数順に準備 2. APIごとにエラー注入を行う 3. みんなで影響を確認 4. APIの重要度をランクづけ 1. High: ユーザー体験に致命的なダメージ 2. Middle: ユーザーは気づくが、不満は少なそう 3. Low: ユーザーは気づかない 5. HighのものをMiddle以下にできるか検討
28. どのように進めたか？ 1 2 3 4 API * UserID単位でエラー注入できるようにする 現在のエラーハンドリングを知る 改善できそうな箇所をリストアップ&議論 日々のタスクの中で、改善していく
29. 実際に改善された事例 • LINEスタンプのホームにて、LINEスタンププレミアム の加入状態を確認していた • 加入状態の確認エラー時にホーム全体が表示でき なくなっていた
30. 実際に改善された事例 • LINEスタンプのホームにて、LINEスタンププレミアム の加入状態を確認していた • 加入状態の確認エラー時にホーム全体が表示でき なくなっていた エラー時には、 LINEスタンププレミアム会員向けのコンテンツのみを非表示に
31. まとめ • Graceful Degradationを実践し、エラー時にもユーザー体験を損なわないようにしている • 実際にエラーを注入し、ステークホルダー全員で挙動を確認している • 既存のエラーハンドリングだけでなく、将来のエラーハンドリングも改善できるように巻き込む • SREロールとしての私はワークショップの企画まで行った • ワークショップの進行やエラーハンドリングの改善など、すべて開発者たちに移譲した • SREプラクティスのEnablingだけでうまく回った事例 • どうやら新機能開発の中で、SREsの介在なしに自然とエラー注入試験も行われ始めている