Start graceful degradation

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Graceful degradationのはじめ方

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

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

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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