Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
End-to-Endで考える信頼性 —LINEアプリにおけるクライアント開発×SRE連携の実践
Search
maru
July 11, 2026
Technology
6.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
240
SLI/SLO、「完全に理解した」から「チョットデキル」へ
maruloop
5
910
チームを巻き込みエラーと向き合う技術
maruloop
5
3.8k
yuru sre 14
maruloop
1
1.3k
Platform and teaming and communication and...
maruloop
3
1.4k
オブザーバビリティが育むシステム理解と好奇心
maruloop
5
4.1k
ワークロードを処理しないプラットフォームに専念する
maruloop
0
960
When Walking like SREs
maruloop
6
1.8k
チームと成長するSRE
maruloop
2
2.3k
Other Decks in Technology
See All in Technology
MCPゲートウェイを作って運用してわかったこと — Agent時代の権限管理の現在地
mtpooh
10
2.7k
[2026-09-30]ロックンロールは鳴り止まないっ - 信頼性かまってちゃん - 「データ駆動を投げ捨ててまで。」追いかける信頼性改善に向けた取り組みの話
tosite
0
180
Claude起点の仕様駆動開発
tanakaseiya
0
290
Lambda MicroVMsが分からなすぎたので使い所を1から考えてみた
tsukuboshi
2
290
Swap and Memory Reclaim - Squeezing Out More RAM
ennael
PRO
1
1.5k
【ゲームメーカーズスクランブル2026】『Shadowverse: Worlds Beyond』UIとアニメーションで実現する最高のユーザー体験を叶えるプロトタイピング
cygames
PRO
1
710
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
16
120k
組み立てて楽しむ AWS Blocks 入門
kmiya84377
0
110
[2026 Oracle Technical Deep Dive] エンタープライズAIエージェントを支えるOCIソリューション。ラインナップと特徴を理解しよう! (2026年9月17日開催)
oracle4engineer
PRO
0
180
React Nativeでの OTA Updateって、 どう説明する?
ichiki1023
0
130
雪かき部 #7 もう怖くない!SELECT文!
foursue
0
270
Oracle Cloud Infrastructure(OCI):Onboarding Session(はじめてのOCI/Oracle Supportご利⽤ガイド)
oracle4engineer
PRO
3
21k
Featured
See All Featured
Docker and Python
trallard
47
4.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
850
Designing Experiences People Love
moore
143
24k
Discover your Explorer Soul
emna__ayadi
2
1.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.4k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.4k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Technical Leadership for Architectural Decision Making
baasie
3
590
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
560
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 まとめ 障害時でも、ユーザーにできるだけコンテンツを届ける ユーザ体験に⼀番近いところで計測し、チームで傾向を把握する 信頼性は、特定のチームだけでなく、プロダクトに関わる全員で育てていくもの