小さなバグが生んだ悲劇、そこから学ぶ耐障害性の高いアプリ設計

by Yosuke Imairi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© GO Inc. 8 障害時の対応がよくなかった 1. メンテナンス状態なのにアプリ側で適切な対応ができなかった ○ メンテナンスモードに切り替わらなかった ■ アプリの初期段階からメンテナンスモード自体は実装されていた ○ ユーザを混乱させてしまった ■ これは障害？一時的に負荷が高い状態？ ■ ユーザ側の環境の問題？（電波が悪い etc..） 2. バグを含んだバージョンの利用を抑えることに時間を要した ○ 修正版のアプリに更新してもらうことをただ祈るのみ…

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© GO Inc. ● メンテナンス状態のときにユーザに現状の報告ができる場 ○ アプリ内でユーザに現状を明確に伝える ■ 障害なのか定期メンテナンスなのか ■ いつ復旧するのか ● 復旧の目処が立たないという情報だけでも有益 ○ WebサイトやSNSなどで障害情報を発信できるがあくまで補助的 ● ユーザはアプリを使いたいのに使えない状態であることを肝に銘じる ○ これはユーザにとって最悪の体験の1つとなる 11 メンテナンスモードで何を伝えられるとよいか

Slide 12

Slide 12 text

© GO Inc. ● 根本的な原因は、API に依存した設計になっていたこと ○ メンテナンス状態かどうかを API 経由で取得していた 12 なぜ『GO』はメンテナンスモードに切り替わらなかったのか iOSアプリから通常の数百倍のリクエストが送られる（バグ） GO のサーバや DB に負荷がかかり捌けなくなるアプリは API からメンテナンス状態を受け取りたいが、API のレスポンスが返ってこないアプリ上は通信中状態のまま（ユーザには何が起こっているか分からない）

Slide 13

Slide 13 text

© GO Inc. ● JSONファイルの取得に成功した場合のみ、その状態を適用させる ● iOS / Android で別々のファイルで管理 ○ どちらか一方だけで障害が起きる可能性がある ● サーバ・DB に依存しない場所でメンテナンス状態を管理する ○ 『GO』の場合は GCS に JSONファイルを配置 ○ メンテナンス状態かどうかを Bool 値で管理 13 メンテナンス状態かどうかの判断をどうやるか【障害時】 {"is_maintenance":false}

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

© GO Inc. ○ needs_update_versions: 指定されたバージョンが対象 ○ required_app_version: 指定されたバージョン未満すべてが対象 ● 『GO』の場合は、GCS に iOS / Android で個別の JSON ファイルを配置 ○ メンテナンス状態の管理と同じ思想 ● 強制アップデートを要求するアプリバージョンを記載する 18 強制アップデートが必要かどうかの判断をどうやるか { "needs_update_versions": ["6.7.0”, “6.7.1"] "required_app_version": "6.5.0" }

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© GO Inc. ● 同じ過ちを繰り返さないようにしたい ○ なぜ今回の事象が発生したのかをチームメンバーと振り返る ○ 根本的な原因は何だったのか？ ○ どうすれば防ぐことができたのか？ ● 『GO』では今回の事例を受けて以下の対応をした ○ メンテナンスモードの改善（サーバ / DB に依存しない設計） ○ 強制アップデート機能の追加 ○ ”目に見えないバグ” への対処（後述） 22 障害が落ち着いたら終わりではない

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© GO Inc. 24 『GO』の事例: ”目に見えないバグ” がリリースされた ● コードレビューで気づけなかったのか？ ○ 指摘がされていたが、修正されないまま Approve されマージされた ● QA で気づけなかったのか？ ○ 現状の QA メンバーの規模ではサーバへの負荷にはならなかった ○ 通信回数の確認までは行っていなかった ● そもそも開発段階で気づけなかったのか？ ○ シミュレータでは再現しづらいバグで気づけなかったバグは様々な工程をすり抜けてリリースされてしまう…！

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© GO Inc. 28 まとめ ● 『GO』で起きた障害をもとに耐障害性の高いアプリ設計を検討した ● メンテナンスモードの設計 ○ サーバ / DB に依存しない状態管理 ○ 障害時と定期メンテナンス時では設計手法に差がある ● 強制アップデート機能の設計 ○ アップデートの要求は起動直後が理想 ○ ユーザにアップデートを促すためにうまく誘導する ● 根本的な原因の追究と対策 ○ 同じ過ちを繰り返さぬようチームメンバーと対策を検討 & すぐ実行