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

© GO Inc.
2023.09.02
タクシーアプリ『GO』iOSアプリ開発マネージャー / 今入庸介
GO株式会社
小さなバグが生んだ悲劇、
そこから学ぶ耐障害性の高いアプリ設計

View Slide

© GO Inc.
自己紹介
2
プロフィール写真
GO株式会社
ユーザーシステム1グループ / 今入庸介
タクシーアプリ『GO』のiOSアプリ開発
● 新機能開発
● アーキテクチャの選定・導入
● アプリ全体の設計、新機能開発
● CI 環境の構築・整備、自動化の促進
● チーミング、エンジニアの育成
@kamekiti

View Slide

© GO Inc. 3
はじめに
タクシーアプリ『GO』で起きた実際の障害事例をもとに
● 障害が起きたときに適切に対処するにはどうすればよいのか
● 同じ障害を起こさないためにどのように対策をとればよいのか
について考える

View Slide

© GO Inc.
タクシーアプリ『GO』で発生した
実際の障害事例
4

View Slide

© GO Inc.
〜 iOS アプリのリリースの翌日〜
5
小さなバグが生んだ悲劇（タクシーアプリ『GO』での障害事例）
iOS アプリ起動後に異常な数のリクエストが送られていることが判明 💥
（通常の数百倍のリクエスト…！ローディング状態が続き次に進めない）
社内で「一部のサービスへのリクエストが異常に減っている」との連絡
（どうやらタクシー配車依頼までユーザが辿り着けていない 🤔）

View Slide

© GO Inc. 6
しかし、アプリ側でメンテナンスモードに切り替わらない 😰
正確には、切り替わったり切り替わらなかったりする
サービスが提供できなくなりメンテナンス状態に変更（サーバサイド）
アプリ内部のバグを修正して App Store Connect の特急審査に提出 🚀

View Slide

© GO Inc.
それから数日が経ち、修正版のアプリが全体の 80% に浸透して平和に 😌
7
リリース後、修正版のアプリがユーザに浸透することを祈る 🙏
バグを含んだバージョンの利用を抑えたい！
2時間45分で審査に通過し、即リリース

View Slide

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

View Slide

© GO Inc.
メンテナンスモードで
被害の拡大を抑制、状況説明をする
9
耐障害性の高いアプリ設計その1

View Slide

© GO Inc. 10
メンテナンスモードとは？
● アプリ内の特定またはすべての機能の利用を遮断させる
○ 通常どおりのサービス提供ができないため
● 想定される利用シーン
○ 予期せぬ障害
○ 定期メンテナンス

View Slide

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

View Slide

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

View Slide

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

View Slide

© GO Inc.
● 障害時と同様でもよいが、APIが相応の状態を返してもよい
○ 定期メンテナンスを判断する API を用意
○ 機能の一部として利用している API の状態を利用
■ API ごとにハンドリングできるので、細かな制御がしやすい
14
メンテナンス状態かどうかの判断をどうやるか【定期メンテナンス】

View Slide

© GO Inc.
強制アップデート機能で
迅速に修正版のアプリを届ける
15

View Slide

© GO Inc.
● ユーザに対してアプリのバージョンアップを促す機能
○ ユーザはアプリを更新するまでアプリ内の機能が利用できない
● 想定される利用シーン
○ アプリ内部にバグがあるバージョンの利用を抑制したい
○ 古い機能のサポートを終了したい
○ ユーザに届ける体験を統一したい
■ ユーザによって利用できる機能に差がないようにする
16
強制アップデート機能とは？

View Slide

© GO Inc.
● バージョンアップしないとアプリの機能が使えない旨を伝える
○ なぜバージョンアップしないといけないのかの説明もあるとよい
● ユーザに対してバージョンアップを誘導する
○ App Store や Google Play への導線を配置する
17
強制アップデート機能で何を伝えられるとよいか

View Slide

© 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"
}

View Slide

© GO Inc.
● アプリを起動した直後が理想
○ 可能な限り早い段階で判断したい
■ アプリ内の機能が利用される前
○ アプリ内部のバグはどこに潜んでいるか分からない
19
強制アップデートを要求するタイミング

View Slide

© GO Inc.
● 今回の障害時のタイミングでは『GO』には強制アップデート機能がなかった
○ 修正版をリリース後、アプリが更新されることを祈るしかなかった
● Karte の接客テンプレートを使い、バグがあるバージョンに対して
起動後にアプリのバージョンアップを促すようにした
○ 告知は閉じられたので、やや強制力は弱め
20
余談：今回の事例で『GO』はどのようにアップデートを促進したのか？

View Slide

© GO Inc.
根本的な原因の追究と対策
21

View Slide

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

View Slide

© GO Inc.
● 今回の障害の原因
○ コード誤り（ケアレスミス）
● 今回の障害の詳細
○ 地図を動かしたり GPS の精度が変わったタイミングで、
意図しない通信処理が実行された
○ GPS の精度はかなり頻繁に更新される
■ 通常の数百倍のリクエストにつながった
23
『GO』の事例: ”目に見えないバグ” がリリースされた

View Slide

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

View Slide

© GO Inc.
● 「目に見えない」ということが発見の障壁となった
○ 目に見えるようにすれば気づきやすくなるのでは？
● どれくらい通信されているかを可視化するデバッグモードを開発した
○ 各 API がどれくらいリクエストされているかを一覧表示させる
○ 前回のバージョンと比較して大幅な変化がないかを確認
25
『GO』の事例: ”目に見えないバグ” に対する再発防止策

View Slide

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

View Slide

© GO Inc. 32
後夜祭 iOSDC Japan 2023 のご参加お待ちしています
2023年09月26日 19:00 ~ 20:30
https://hey.connpass.com/event/290854/

View Slide

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

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

Yosuke Imairi

More Decks by Yosuke Imairi

Other Decks in Technology

Featured

Transcript