Start graceful degradation

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

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

Transcript

1. ো֐Λલఏʹ४උ͢Δ
   43&େू߹ʂΈΜͳͰֶͿɺ৴པੑΛߴΊΔऔΓ૊Έ-5େձ
   Ճ౻ढ़໻ !NBSVMPPQ
   
   -*/&גࣜձࣾ$PNNVOJDBUJPO4FSWJDFJOUFHSBUJPOࣨ43&5FDI-FBET
   -*/&ελϯϓண͔ͤ͑ֆจࣈ΢ΥϨοτλϒϗʔϜλϒ
   

   View Slide

2. WebAPIのエラー時に
   ユーザーにはどのように表示されるか
   把握してますか？
   

   View Slide

3. Graceful degradationのはじめ方
   

   View Slide

4. Graceful degradation(上品な劣化)とは？
   障害などでサービスの提供が限定的になった時に、サービス全体を停止させるのではなく、機能
   単位で停止できるようにしておくという考え方。
   例：
   パーソナライズドされたレコメンデーションを表示できない時に、
   共有のレコメンデーションへフォールバックするなど。
   

   View Slide

5. どのように進めたか？
   1
   2
   3
   4
   API * UserID単位でエラー注入できるようにする
   現在のエラーハンドリングを知る
   改善できそうな箇所をリストアップ&議論
   日々のタスクの中で、改善していく
   

   View Slide

6. どのように進めたか？
   1
   2
   3
   4
   API * UserID単位でエラー注入できるようにする
   現在のエラーハンドリングを知る
   改善できそうな箇所をリストアップ&議論
   日々のタスクの中で、改善していく
   

   View Slide

7. 私たちの基本的なアーキテクチャ
   • 実際のビジネスロジックは各マイクロサービスで実施
   • クライアントとサーバーサイドの間にgatewayがある
   • 認証や流量制限などの機能を持つ
   LINE App Gateway
   Microservice
   Microservice
   Microservice
   Microservice
   Microservice
   Microservice
   認証
   流量制限
   Etc…
   

   View Slide

8. 私たちの基本的なアーキテクチャ
   • 実際のビジネスロジックは各マイクロサービスで実施
   • クライアントとサーバーサイドの間にgatewayがある
   • 認証や流量制限などの機能を持つ
   LINE App Gateway
   Microservice
   Microservice
   Microservice
   Microservice
   Microservice
   Microservice
   認証
   流量制限
   Etc…
   流量制限の機能を流用すれば、User * API単位にエラー注入ができそう！
   

   View Slide

9. どのように進めたか？
   1
   2
   3
   4
   API * UserID単位でエラー注入できるようにする
   現在のエラーハンドリングを知る
   改善できそうな箇所をリストアップ&議論
   日々のタスクの中で、改善していく
   

   View Slide

10. 現在のエラーハンドリングを知る
    “誰が”現在の状態を把握しておくべきか？
    

    View Slide

11. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    

    View Slide

12. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい
    

    View Slide

13. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    

    View Slide

14. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    

    View Slide

15. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    企画サイド(プロダクトオーナー)
    

    View Slide

16. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    企画サイド(プロダクトオーナー)
    エラーハンドリングの改善を日々行なってほしい
    新規開発では、エラー注入タスクを含めるようにして欲しい
    

    View Slide

17. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    企画サイド(プロダクトオーナー)
    エラーハンドリングの改善を日々行なってほしい
    新規開発では、エラー注入タスクを含めるようにして欲しい
    スクラムマスター
    

    View Slide

18. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    企画サイド(プロダクトオーナー)
    エラーハンドリングの改善を日々行なってほしい
    新規開発では、エラー注入タスクを含めるようにして欲しい
    スクラムマスター
    流量制限の影響を認識して欲しい
    

    View Slide

19. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    企画サイド(プロダクトオーナー)
    エラーハンドリングの改善を日々行なってほしい
    新規開発では、エラー注入タスクを含めるようにして欲しい
    スクラムマスター
    流量制限の影響を認識して欲しい サーバーサイドエンジニア
    

    View Slide

20. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    企画サイド(プロダクトオーナー)
    エラーハンドリングの改善を日々行なってほしい
    新規開発では、エラー注入タスクを含めるようにして欲しい
    スクラムマスター
    流量制限の影響を認識して欲しい サーバーサイドエンジニア
    プロの視点から、さまざまな影響を確認して欲しい
    

    View Slide

21. 現在のエラーハンドリングを知る
    このプラクティスを進行する上で期待すること
    既存のエラーハンドリングを改善してほしい クライアントサイドエンジニア
    新機能開発で、エラーハンドリングを意識した仕様を考えてほしい
    企画サイド(プロダクトオーナー)
    エラーハンドリングの改善を日々行なってほしい
    新規開発では、エラー注入タスクを含めるようにして欲しい
    スクラムマスター
    流量制限の影響を認識して欲しい サーバーサイドエンジニア
    プロの視点から、さまざまな影響を確認して欲しい QAエンジニア
    

    View Slide

22. エラー注入のワークショップを開催
    • 参加者：
    • 企画/スクラムマスター
    • サーバーサイドエンジニア
    • クライアントサイドエンジニア
    • QAエンジニア
    • 時間：1時間/回
    • 頻度： (今のところ)1回/年
    • 環境：開発環境
    

    View Slide

23. エラー注入のワークショップを開催
    • 参加者：
    • 企画/スクラムマスター
    • サーバーサイドエンジニア
    • クライアントサイドエンジニア
    • QAエンジニア
    • 時間：1時間/回
    • 頻度： (今のところ)1回/年
    • 環境：開発環境
    進め方
    1. 事前にAPI一覧をアクセス数順に準備
    全APIを確認するのは時間がかかりすぎるため
    優先度をアクセス数でつける
    

    View Slide

24. エラー注入のワークショップを開催
    • 参加者：
    • 企画/スクラムマスター
    • サーバーサイドエンジニア
    • クライアントサイドエンジニア
    • QAエンジニア
    • 時間：1時間/回
    • 頻度： (今のところ)1回/年
    • 環境：開発環境
    進め方
    1. 事前にAPI一覧をアクセス数順に準備
    2. APIごとにエラー注入を行う
    

    View Slide

25. エラー注入のワークショップを開催
    • 参加者：
    • 企画/スクラムマスター
    • サーバーサイドエンジニア
    • クライアントサイドエンジニア
    • QAエンジニア
    • 時間：1時間/回
    • 頻度： (今のところ)1回/年
    • 環境：開発環境
    進め方
    1. 事前にAPI一覧をアクセス数順に準備
    2. APIごとにエラー注入を行う
    3. みんなで影響を確認
    

    View Slide

26. エラー注入のワークショップを開催
    • 参加者：
    • 企画/スクラムマスター
    • サーバーサイドエンジニア
    • クライアントサイドエンジニア
    • QAエンジニア
    • 時間：1時間/回
    • 頻度： (今のところ)1回/年
    • 環境：開発環境
    進め方
    1. 事前にAPI一覧をアクセス数順に準備
    2. APIごとにエラー注入を行う
    3. みんなで影響を確認
    4. APIの重要度をランクづけ
    1. High: ユーザー体験に致命的なダメージ
    2. Middle: ユーザーは気づくが、不満は少なそう
    3. Low: ユーザーは気づかない
    Rank Example
    High スタンプの購入ができない
    Middle レコメンドが表示されない
    Low 内部的なログの送信, 日次同期の失敗
    

    View Slide

27. エラー注入のワークショップを開催
    • 参加者：
    • 企画/スクラムマスター
    • サーバーサイドエンジニア
    • クライアントサイドエンジニア
    • QAエンジニア
    • 時間：1時間/回
    • 頻度： (今のところ)1回/年
    • 環境：開発環境
    進め方
    1. 事前にAPI一覧をアクセス数順に準備
    2. APIごとにエラー注入を行う
    3. みんなで影響を確認
    4. APIの重要度をランクづけ
    1. High: ユーザー体験に致命的なダメージ
    2. Middle: ユーザーは気づくが、不満は少なそう
    3. Low: ユーザーは気づかない
    5. HighのものをMiddle以下にできるか検討
    

    View Slide

28. どのように進めたか？
    1
    2
    3
    4
    API * UserID単位でエラー注入できるようにする
    現在のエラーハンドリングを知る
    改善できそうな箇所をリストアップ&議論
    日々のタスクの中で、改善していく
    

    View Slide

29. 実際に改善された事例
    • LINEスタンプのホームにて、LINEスタンププレミアム
    の加入状態を確認していた
    • 加入状態の確認エラー時にホーム全体が表示でき
    なくなっていた
    

    View Slide

30. 実際に改善された事例
    • LINEスタンプのホームにて、LINEスタンププレミアム
    の加入状態を確認していた
    • 加入状態の確認エラー時にホーム全体が表示でき
    なくなっていた
    エラー時には、
    LINEスタンププレミアム会員向けのコンテンツのみを非表示に
    

    View Slide

31. まとめ
    • Graceful Degradationを実践し、エラー時にもユーザー体験を損なわないようにしている
    • 実際にエラーを注入し、ステークホルダー全員で挙動を確認している
    • 既存のエラーハンドリングだけでなく、将来のエラーハンドリングも改善できるように巻き込む
    • SREロールとしての私はワークショップの企画まで行った
    • ワークショップの進行やエラーハンドリングの改善など、すべて開発者たちに移譲した
    • SREプラクティスのEnablingだけでうまく回った事例
    • どうやら新機能開発の中で、SREsの介在なしに自然とエラー注入試験も行われ始めている
    

    View Slide