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