Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
End-to-Endで考える信頼性 —LINEアプリにおけるクライアント開発×SRE連携の実践
Search
maru
July 11, 2026
Technology
5.9k
4
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
End-to-Endで考える信頼性 — LINEアプリにおける クライアント開発×SRE連携の実践
at
https://sre-next.dev/2026/schedule/#slot105
maru
July 11, 2026
More Decks by maru
See All by maru
AIネイティブな開発についてのモヤモヤを吐き出す
maruloop
0
200
SLI/SLO、「完全に理解した」から「チョットデキル」へ
maruloop
5
820
チームを巻き込みエラーと向き合う技術
maruloop
5
3.6k
yuru sre 14
maruloop
1
870
Platform and teaming and communication and...
maruloop
3
1.4k
オブザーバビリティが育むシステム理解と好奇心
maruloop
5
4k
ワークロードを処理しないプラットフォームに専念する
maruloop
0
920
When Walking like SREs
maruloop
6
1.8k
チームと成長するSRE
maruloop
2
2.3k
Other Decks in Technology
See All in Technology
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
4.9k
Cursor Meetup Sapporo - Cursor物語 続編
cocacola917
0
140
[ChatGPT Work LT]事務作業が苦手な人のための バックオフィスの「半」自動化
chimaki_iot
0
250
Digitization部 紹介資料
sansan33
PRO
2
7.7k
Flutterをカメラで動かしたかった話
sony
1
130
FPGAが実現する遠方宇宙の高空間分解能天体撮影 -大型地上望遠鏡の視力を補正する「補償光学」とは?-
komei_mt
0
170
OSPN.JPバージョンアップ作業進捗のご報告 / 20260801-osc26kyoto
akkiesoft
0
380
侵入は突然に 〜 IoTマルウェアと悪用される家庭の機器 ~ / When Intrusion Strikes: IoT Malware and the Abuse of Home Devices
nttcom
0
1.5k
SO-101×VLAによる3色キューブのピック&プレース
abeja
0
130
20260807_第6回_関東kaggler会LT_claw系bot xangiと始める、"寂しくない" kaggle
sugupoko
0
190
AWS ネットワーク構築でハマった(ハマりかけた) 5選とそこから得た教訓
nagisa53
4
190
制約理論(ToC)入門 2026版
recruitengineers
PRO
6
2k
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
28
2.7k
Optimising Largest Contentful Paint
csswizardry
37
3.9k
A Tale of Four Properties
chriscoyier
163
24k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
160
Ruling the World: When Life Gets Gamed
codingconduct
0
290
The Curse of the Amulet
leimatthew05
2
14k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
190
The Cost Of JavaScript in 2023
addyosmani
55
10k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
590
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
200
Transcript
© LY Corporation maru / Mori Atsushi End-to-Endで考える信頼性 ̶ LINEアプリにおける
クライアント開発×SRE連携の実践 SRE NEXT 2026
© LY Corporation maru SREを担当。 LINEスタンプ、着せかえ、LYPプレミアム、etc 本セッションでは、クライアント開発のMoriさんを中⼼に SRE的な⽂脈の補⾜や相槌を担当します。 2 ©
LY Corporation
© LY Corporation Mori Atsushi LINEのAndroidアプリを担当。 著書:良いコードの道しるべ 変化に強い ソフトウェアを作る原則と実践 © LY
Corporation
© LY Corporation Public オフラインファースト アプリにおける信頼性 本⽇のテーマ 4
© LY Corporation Public インターネットにアクセスしなくても、コア機能の⼀部または全部を実⾏できるアプリ オフラインファースト 例えば: - 以前⾒ていたコンテンツが⾒れる -
チャットが閲覧できる - チャットの送信予約ができる
© LY Corporation Public オフラインファーストと対障害性 サーバ側で障害が発⽣しても ある程度使える ユーザのネットワーク接続が 不安定でもある程度使える
© LY Corporation ⽬次 LINEのUIレンダリングのしくみ 問題が発⽣するリスクがある場所と解決⽅法 障害対策の品質管理 チームで解決するために クライアント視点のオブザーバビリティ
© LY Corporation Public LINEのUIレンダリングのしくみ BFF (Backend for Frontend) Client
(Android / iOS) サービスA サービスB サービスC
© LY Corporation Public プラットフォームチーム BFF (Backend for Frontend) Client
(Android / iOS) サービスA サービスB サービスC プラットフォームチーム
© LY Corporation Public 問題が発⽣するリスクがある場所 BFF (Backend for Frontend) Client
(Android / iOS) サービスA サービスB サービスC 通信エラー システム障害 システム障害 システム間 通信エラー クライアント 内部エラー
© LY Corporation Public ⼀番避けるべき状態 真っ⽩な画⾯が表⽰される なにが起きているかわからない 友達リストにもアクセスできない
© LY Corporation Public ⽅針:コンテンツをキャッシュする ⼀度読み込んだコンテンツはクライアントにキャッシュしておき、最新情報が取れない場合はそれを再利⽤する。 ローカルDB サーバ リポジトリ UI
ページアクセス コンテンツが 期限切れ キャッシュを利⽤ コンテンツ取得 YES NO
© LY Corporation Public キャッシュが期限切れでも表⽰する キャッシュを表⽰ フォールバック 表⽰ (後述) コンテンツが
期限切れ ページアクセス 期限切れから ⼀定期間以内 キャッシュを表⽰ YES YES NO NO
© LY Corporation Public 表⽰可能なキャッシュがないときは? アプリインストール直後にコンテンツ取得に失敗 コンテンツを取得してから⻑時間経っている
© LY Corporation Public 解決策: クライアント側にフォールバックをもたせる ローカルDB サーバ リポジトリ UI
フォールバック コンテンツ
© LY Corporation Public いつリトライする? コンテンツ取得に失敗した後、すぐにリトライすると サーバに負荷がかかり続ける
© LY Corporation Public 解決策: 待機時間の調整 すぐにリトライ可能なもの → Exponential Backoff
- 再試⾏のたびに待機時間を指数的に⻑くする 初回リクエスト 1秒 3秒 7秒 1秒待機 2秒待機 4秒待機 8秒待機 直後のリトライが不可の場合 → 1時間待機 初回リクエスト 1時間 1時間待機 1時間待機
© LY Corporation Public 部分障害: 他のサービスの障害によって、 さらに別のサービスが表⽰できなくなる BFF (Backend for
Frontend) Client (Android / iOS) サービスA サービスB サービスC システム障害 稼働中 稼働中 なんらか コンテンツを返したい
© LY Corporation Public 表⽰できるコンテンツは返す BFF (Backend for Frontend) Client
(Android / iOS) サービスA サービスB サービスC システム障害 稼働中 稼働中 コンテンツ1 コンテンツ2(エラー) コンテンツ3 … エラーのコンテンツのみ あとでリトライする
© LY Corporation Public サーバが全部のリクエストを 捌けないとき リクエストが多すぎて、BFFサーバーに負荷がかかりすぎている場合
© LY Corporation Public BFF (Backend for Frontend) Client (キャッシュあり)
サービスA サービスB サービスC Prioritized Load Shedding Client (キャッシュなし) キャッシュ有無 キャッシュ有無 コンテンツ エラー ⾼負荷時
© LY Corporation Public 対策まとめ オフラインでもコンテンツを⾒せたい 表⽰可能なキャッシュがない場合の処理 リトライをいつすべきか ⼀部サービスで障害がおきた場合は BFFの負荷が上がりすぎた場合は
コンテンツをキャッシュする 期限切れでもキャッシュを表⽰する クライアント側にフォールバックを定義する Exponential Backoff / 1時間待機 表⽰できるコンテンツのみ表⽰し、後でリトライ
© LY Corporation Public 障害対策の品質管理 エラーケースを含めた仕様書の作成 エラーケースを含めたテストケースの制定 エラーを再現するためのクライアントデバッグメニュー/障害注⼊ システムの状況を把握するための仕組み、オブザーバビリティ
© LY Corporation Public クライアント視点のオブザーバビリティ ユーザ体験に⼀番近いところで計測する クライアントログをもとに、品質観点で分析 リアルタイム監視ではなく、傾向把握を⽬的として運⽤ 毎朝のチーム会議で状況を確認 同期完了時間など、ユーザー体験に直結する指標を可視化
▷ サーバー・端末状態など、外部要因も含めて分析 APIリクエスト数 / PV 経過時間 ⽇付 ユーザがページを開いてから サーバとの同期完了までの時間 リクエスト回数 ⽇付
© LY Corporation Public 実際の事例:サーバとの同期完了が遅い 経過時間 ⽇付 ユーザがページを開いてから サーバとの同期完了までの時間 API呼び出し時
キャッシュ利⽤時 UIスレッドによる ブロックを解消 分析結果から実際に改善
© LY Corporation Public チームで解決するために チームで議論 各チームで個別に解決 サーバ クライ アント
SRE サーバ クライ アント SRE
© LY Corporation Public 開発初期から複数の視点で議論を進める 要望 企画 設計 実装 QA
リリース QA プランナー サーバ / クライアント / SRE
© LY Corporation Public 開発者の誰もが改善の提案ができる環境 改善 提案 実装 サーバ担当 クライアント担当
SRE担当
© LY Corporation Public ⽂化形成 関係者(プランナー、開発者、QA)全員が集まる週1定例 対⾯で話すワークショップの開催 個別議題の会議を設定して集中的に議論する
© LY Corporation Public ⽂化形成には時間がかかる 私たちのプラットフォームチームでも、共通認識と信頼関係を 育てるまでに約1年かかった じっくり根気よく、対話の機会を作り続けることが重要
© LY Corporation Public まとめ 障害時でも、ユーザーにできるだけコンテンツを届ける ユーザ体験に⼀番近いところで計測し、チームで傾向を把握する 信頼性は、特定のチームだけでなく、プロダクトに関わる全員で育てていくもの