Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Start graceful degradation

Start graceful degradation

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

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

LINE Developers
PRO

May 18, 2023
Tweet

More Decks by LINE Developers

Other Decks in Technology

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