t0waxx / 角鹿翔和

年越し0秒、ズレてて何が悪い？
モバイル端末での年越しを考える

Transcript

1. TOSHIKOSHI Engineering Lead 年越し0秒、ズレてて何が悪い？ モバイル端末での年越しを考える 年越しジャンプを“正確に”実現するための 時刻同期アーキテクチャ設計と実装 ⾓⿅ 翔和 TOWA TSUNOGA モバイル開発 / 時刻同期 SYSTEM_TIME: 00:00:00.000 CONF_ID: #MOBILE_SYNC_2025
2. ⾓⿅ 翔和 Towa Tsunoka ⼤学情報 北海道科学⼤学 ⼯学部 情報⼯学科 視覚情報メディアシステム研究室 （2027年卒業⾒込） 何やってるん エンジニア / ビジネス(願望) PM サーバーサイド データ 基本情報 居住地：北海道 所属 株式会社SATSOIL CTO 学⽣団体Q-PIT 代表 HUIT北⼤IT研究会‧Gamma‧北⼤3Dプリンター研究会 趣味 ⾃⼰紹介 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
3. 年越しが迫る。 今⽉末、秒単位のイベントがやってくる。 あなたはどう年を越す？ @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
4. 何をしますか？ 友⼈とカウントダウン？ 家で静かに？ それとも — 技術で遊ぶ？ @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
5. そうです。 年を越しますよね。 （意味深） その⼀瞬、00:00:00.000 を “確実に” 捉える 準備はできていますか？ @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
6. 年の瞬間だけ 地球にいなかった⽅も 多いのでは？ いわゆる「年越しジャンプ」。
7. 問題提起 端末は本当に“今”を知っているのか？ 無線‧OS補正の現実 SECTION 02 MOBILE TIME SYNCHRONIZATION / PROBLEM STATEMENT @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
8. SUMMARY 導⼊の まとめ なぜ我々は 「時間」について これほど深く 考える必要があるのか？ 秒以下の精度が欲しい 年越しカウントダウンは「0秒」が命。 数秒のズレは興醒めであり、許されないイベント。 モバイル端末への疑念 「今何時？」と聞いても、端末単体では ネットワーク遅延や処理時間を含んだ不正確な答えしか返せない。 だからこそ「設計」が必要なのではないか OS任せにせず、能動的に時間を同期し、 正確なトリガーを引くためのアーキテクチャを組む。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
9. RELIABILITY 端末の時計は 信⽤できる？ 00:00:00.000 を 端末単体で断⾔するのは 実は⾮常に難しい理由。 時間合わせのズレ スマホではたまに時間がズレることがあある ユーザー制御レベルでレベルで完全に正確な時を刻むことは不可能。 OS補正のブラックボックス iOSやAndroidがいつ、どのように時間を補正しているかは⾮公開。 アプリ側から補正タイミングを制御することはできない。 無線通信のジッタ（揺らぎ） モバイルネットワークは常に遅延が変動する。 「今」を受け取った瞬間、それは既に「過去」になっている。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
10. SYSTEM ARCHITECTURE VIEW ERROR SOURCES モバイルでは誤差が 出る理由 ネットワーク‧ジッタ 無線通信の経路状況により、パケットの到達時間が不規則に変 動。数ms〜数百msの予測困難な揺らぎが発⽣する。 処理遅延と割り込み OSのスケジューリングやバックグラウンド処理により、パケット 受信からアプリケーション到達までにラグが⽣じる。 ⽔晶発振⼦のドリフト(ほぼないが可能性はゼロではない) 端末の⽔晶は温度や電圧変化に弱い。ネットワークから切断され た瞬間から、独⾃の時間を刻み始め、徐々にズレていく。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
11. これでは困る。 時代に取り残されてしまう。 “間に合ったか？” を正確に判定できない。 年越しも、時限解除も、滑り込みセーフも。 正しい「時刻」の取り扱いが不可⽋ @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
12. 時間にシビアな世界 ユースケースと要求精度を俯瞰する @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
13. USE CASES 代表 ユースケース 我々が⽬指すのは 単なる時刻表⽰ではない。 「その瞬間」を 確実に捉えることだ。 年越しカウントダウン 要求精度: 秒 (s) もっとも⾝近で楽しいユースケース。00:00ジャストに「あけおめ」を送信。 数秒のズレは許容されるが、フライングは空気が凍る。 滑り込み遅刻判定 要求精度: ms ビジネスの世界。9:00:00.000 と 9:00:00.001 の差。 打刻システムの判定はミリ秒単位で給与や評価を分ける。(？) 時限爆弾の解除 要求精度: sub-ms （フィクションの）世界。残り0.001秒で⾚を切る緊張感。 ネットワーク遅延やOSの処理落ちは、この世界では致命的。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
14. そのために。 モバイル端末で正確に年を越す⽅法を 本気で考えました。 無線の揺れを本番に持ち込まない。 準備ですべてを決める設計の話をします。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
15. 技術編 NITZ / NTP / サーバ構成 / 配布戦略 / 精度検証 正確な時刻同期を実現するための技術要素と設計 SECTION 03 MOBILE TIME SYNCHRONIZATION / TECHNICAL DETAILS @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
16. NETWORK PROTOCOL NITZ とは？ Network Identity and Time Zone. 携帯電話ネットワークにおいて 標準的に利⽤されている 時刻通知の仕組み。 キャリアからの単⽅向通知 基地局への接続時などに、ネットワーク識別情報とともに時刻情報が送ら れてくる。 「今はこの時間です」という ⼀⽅的な通知。 期待精度は「分」オーダー 仕様上、秒単位の厳密性は保証されていない。 あくまで「⼈間が⾒て困らない程度の時刻」を合わせるためのもの。 ms同期⽤途には不向き ネットワーク遅延の補正メカニズムを持たないため、 ミリ秒（ms）レベルの精度を求める今回の⽤途には適していない。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
17. NITZ PROTOCOL CONSTRAINTS 16 / 30 PROTOCOL LIMITATION NITZの限界を可視化 する 完全な受動的同期 端末から「今何時？」と問い合わせる機能はない。ネットワー ク側からの通知（Attach時や位置登録時など）をひたすら待つし かない。 不定期な更新タイミング 同期タイミングは制御不能。数時間〜数⽇間更新されな いこともあり、その間は端末の⽔晶発振⼦の精度に依存してズレ 続ける。 精度要件のミスマッチ 仕様上の期待精度はあくまで「分（minutes）」オーダー。秒 やミリ秒を正確に合わせるためのプロトコルではない。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
18. PROTOCOL DEEP DIVE NTPは 何が違う？ Network Time Protocolが 数⼗年にわたり 標準であり続ける理由と その精度の秘密。 双⽅向通信による補正 ⾏って帰ってくる時間（RTT）を計測し、通信にかかる遅延を推測し て相殺する。 ⼀⽅通⾏のNITZには不可能な芸当。 外れ値の排除と投票 突発的な遅延や異常な値を統計的に排除するフィルタ機能。 複数のサーバーと照合し、多数決で「正しい時」を決める。 設計思想が「⾼精度」 最初からミリ秒（ms）オーダーの同期を前提に設計されている。 「だいたい合っていればいい」NITZとは⽬的が違う。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
19. ANDROID SPEC Androidは どうか？ Android 12以降、 OSレベルで時刻同期の 優先順位が変わった。 その意図とは？ Android 12+ は NTP を優先 以前はキャリア依存のNITZが強かったが、 12からはインターネット経由のNTPが NITZよりも優先される仕様に変更された。 理由は「精度と信頼性」 Google公式⽈く、NTPの⽅が "more accurate and reliable"。 キャリア網の不確定要素よりもNTPを信頼。 ただし実装‧環境差は残る メーカーごとのカスタマイズや、 通信キャリアの制約、省電⼒機能（Doze）の影響で、 必ずしも期待通りに動かないケースはある。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
20. IOS SPEC iOSの時間と タイムゾーン Appleエコシステムの ⾃動⽇時設定と 位置情報連携の仕組み time.apple.com との同期 ⾃動⽇時設定をオンにすると、インターネット経由で time.apple.com などのNTPサーバから時刻を同期。 複数の技術記事やAppleコミュニティで⾔及されている。 タイムゾーンの⾃動判定 タイムゾーン⾃体は、位置情報やキャリアの情報を 使⽤して⾃動的に判定する仕組みを採⽤しています。 位置情報サービスとの連携 Apple公式サポートの説明によると、位置情報サービスの "Setting Time Zone"をオンにすることで、 現在地に基づいて正確なタイムゾーンが設定されます。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
21. PRECISION COMPARISON / 19 NTP Internet (WAN) 経路数とジッタに⼤きく依存 典型的な精度感 同期プロトコルとネットワーク環境による⼀般性能⽐較 PROTOCOL / METHOD NETWORK ENVIRONMENT TYPICAL ACCURACY CHARACTERISTICS ~ 10-100 ms ※ 一般的な実装における期待値であり、OSや負荷状況により変動します そりゃLAN内がいいよとは言わないでください; ; NTP LAN (On-premise) ~ 1-5 ms 設計次第でms級を安定確保可能 PTP (IEEE1588) LAN (HW Support) < 1 μs ハードウェア⽀援が必要（今回はロ マン枠） @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
22. REDUNDANT SERVER CLUSTER SYSTEM ARCHITECTURE 今回の構成（概要） オンプレミスサーバー3台構成 単⼀障害点を避けるための最⼩構成。サーバー間で時刻を 常時突き合わせ、外れ値を⾃動的に排除する仕組み。 多数決で「今」を決定 1台がズレても残りの2台が正しければシステムは継続。合意 形成アルゴリズムにより、最も信頼できる「正」の時刻を定義。 未来時刻を配布する戦略 「今何時？」ではなく「X秒後に年が変わる」というイベント情 報を事前に配布。ネットワーク遅延の影響を最⼩化する。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
23. ARCHITECTURE なぜ 3台なのか？ 偶数ではなく奇数。 2台ではなく3台。 信頼性を担保するための 必要最⼩限の構成理由。 単⼀障害点（SPOF）の排除 1台がダウンしてもシステム全体は⽌まらない。 冗⻑構成により、時刻配信サービスの継続性を物理的に担保する。 1台のズレを検出可能 2台構成では意⾒が割れた際に「どちらが正しいか」判断できない。 3台あれば、突出した外れ値を論理的に特定‧隔離できる。 多数決による「今」の合意 3台以上の構成なら多数決で「正しい時刻」を定義できる。 分散システムにおける合意形成の最⼩単位としての「3」。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
24. ◯「◦秒後に年が変わる」を事前にもらう ✕今何時？をリアルタイムで聞く 問い合わせた瞬間のネットワーク遅延（ジッタ）に依存しない設計へ。 リアルタイム同期よりも、未来の確定事項を共有して待つほうが確実。 無線の揺れを本番に持ち込まない
25. ポイント 「今何時？」と問い合わせるのではなく、「◦秒後にこれをしろ」と命令することで、通信の往復時間（RTT）の揺らぎを本番実⾏時から切り離すことができる。 未来時刻配布プロトコル Time-Sync Distribution Flow 時刻合意 サーバー群で「ジャンプ時刻 （T_target）」を多数決で決定。外 れ値を排除。 1 未来配布 クライアントへ“未来の時刻 + 余裕” を事前にプッシュ配信。 2 ローカル待機 端末内部時計でカウントダウン。 通信遅延の影響を受けない状態を 作る。 3 同期実⾏ トリガー時刻到達と同時にアクショ ン実⾏。ジッタの影響はゼロ。 4 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
26. 年越しジャンプ⼿順 01 ターゲット決定 02 未来時刻配布 03 ローカル待機 04 JUMP! EXECUTION STEPS / 24 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
27. TUNING RTT補正 (P2P補正) さらなる精度を求めて。 個々のネットワーク環境における 微細な遅延特性を 吸収するための最終調整。 軽量Pingによる推定 アプリケーション層での軽量パケット往復（Ping）により、現在の ネットワーク往復遅延時間（RTT）の中央値を統計的に算出。 無線ジッタの学習 複数回の試⾏から外れ値を排除し、その環境特有の通信の「揺らぎ（ジッ タ）」の傾向を学習して、補正値に反映させる。 本番は補正のみ適⽤ 「年越し」本番の通信では計測を⾏わず、事前に計算済みの補正パラ メータのみを適⽤。処理負荷と通信遅延を最⼩化する。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
28. PRECISION COMPARISON / 26 iOS Automatic Network (Private) 実装‧環境に依存し制御不可 Android 12+ NTP Priority 設計上は向上したが環境差あり NITZ Unidirectional ms同期⽤途には完全に不向き App NTP (Direct) Internet ネットワーク経路‧ジッタに依存 This System On-premise x3 ⽬標精度を設計可能 + RTT Corr. P2P Correction 遅延補正で極限を⽬指す 精度⽐較（最終版‧安全） 各⽅式における期待精度と採⽤の結論 TARGET METHOD PRECISION VERDICT Unknown ~ NTP Level Minutes 5-100 ms ~ ms Class < 1 ms @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
29. RELIABILITY フェイル セーフと 監視 システムは 必ず壊れる。 だからこそ ⽌まらない仕組みを。 サーバ間相互監視と投票 3台のサーバが互いに⽣存確認（Heartbeat）を実施。 1台がダウンしても、残り2台の多数決で 正当な「時刻」を決定しサービスを継続。 外れ値‧ドリフトの⾃動隔離 ⽔晶の劣化や突発的な異常で時刻がズレたサーバを検知。 集団から統計的に外れたノードを即座に隔離し、 誤った時刻情報が汚染するのを防ぐ。 クライアント側フォールバック 万が⼀、サーバからの未来時刻配布が途絶えた場合、 端末は⾃動的にOS標準時刻（NTP/NITZ）へ切り替え。 精度は落ちても「年越し」そのものは⽌めない。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
30. OS CONSTRAINTS & BEHAVIORS IMPLEMENTATION GUIDE 実装のヒントiOS / Android iOS: Monotonic Clockの活⽤ システム時刻変更通知 (NSSystemClockDidChange) を監視しつつ、基 本は変更されない uptime (起動経過時間) でカウントダウンを⾏う。 Android: Dozeモード対策 スリープ中はタイマー精度が落ちる。AlarmManager の setExactAndAllowWhileIdle を使⽤し、Deep Sleep中でも正 確な発⽕を保証する。 共通: "Wall Clock" に依存しない OSの表⽰時刻(Wall Clock)はユーザー操作やNTP補正で⾶ぶ可能性が ある。同期完了後は、必ず「単調増加時間」のみで計測する。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
31. 成功基準 本番環境における全端末の同期誤差が⽬標値（例: ±5ms以内）に収まっていることをログから確認できた時点で、プロジェクト完了とする。 検証とデモ計画 Measurement & Verification Timeline 事前同期期間 サーバー群の安定稼働確認と、ク ライアントへの時刻配信テストを 実施。 1 リハーサル 4G/5G/Wi-Fiなど異なるネットワーク 環境下での遅延測定と補正値の調 整。(仰々しく⾔ってみる💪) 2 本番カットオーバー ジャンプ時刻の決定と⼀⻫配信。 監視モニターで各端末の同期状況 をリアルタイム追跡。 3 事後分析 ログ収集と誤差解析。理論値と実 測値の乖離を確認し、次回の改善 へ繋げる。 4 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
32. OPTIMIZATION JOURNEY 最適化の末に 辿り着く場所 「そこまでの精度は 本当に必要か？」 問い続けた先に ⾒える答え。 実運⽤でのバランス バッテリー消費、ネットワーク負荷、UXへの影響。 これらを考慮しない精度追求は、⾃⼰満⾜に過ぎない。 既存実装への回帰 ⼀周回って⾏き着くのは、 既存の iOS / Android が標準採⽤している実装モデル。 妥協ではなく「最適解」 これは技術的な敗北ではない。 ユーザー視点で考え抜かれた、真の最適解である。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
33. ” 技術的には“正しい”が、 現実では使われない。 この⽅法は、理論上はかなり正確である。 しかし、実際に必要とされる場⾯は極端に限られる。 年越し0秒や、スパイ映画の時限爆弾解除くらいである。 頻度が⾼すぎる精度は、ほとんどのユーザーにとって不要 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
34. 伝えたいこと 「いい技術だから使われる」わけではない。 「精度が⾼いから価値がある」わけでもない。 ターゲットのユーザーがどんな価値求めているかが、 すべてを決める。 AI時代だからこそ、 技術の正しさより、体験としての正しさを考える必要がある。 @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14
35. まとめ モバイル端末での年越しを考える ユーザー任意のタイミングで同期できるようにする 同期するタイミングをユーザーが決められるだけで安⼼ @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14 年越し0秒、ズレてて何が悪い？ ①
36. 年越し0秒、ズレてて何が悪い？ モバイル端末での年越しを考える Thank You! @t0waxx 学⽣エンジニア3団体合同×ディップLT会 2025-12-14 ジャンプ⼒を鍛え、滞空時間を⻑く これで安⼼！！！！！！！！！！！ まとめ ②