-"3(&
4$"-&
$.4
Λࢧ͑Δ มߋσʔλಉظ 松⽥ ⼀樹 (LINE / 開発4センター / OFFICIAL ACCOUNT開発室) 

ABSTRACT • LINE公式アカウント（Official Account︔以下OA） に関連するシステムを⽀える変更データ同期について紹介します。 • LINE 社内では様々なサービスが必要に応じて OAの情報を利⽤してい ます。⼀部のサービスはデータをコピーしています。OA の情報が更 新された場合、更新内容を素早く同期する必要があります。 • この変更同期がどのように⾏われているのか、 その変遷と最終的なデザインをご紹介します。 

AGENDA • LINE公式アカウントマネージャーと社内サービス • 解決すべき課題 • データ共有と同期⽅法の今昔 • New Design 

LINE公式アカウントマネージャー とは • https://manager.line.biz (& 社内向けの internal API) • OA の管理者が利⽤する管理ツールです • いわゆる Contents Management System (CMS) 

LINE公式アカウントマネージャーでできること • メッセージを送信する • タイムラインに投稿する • 名前を変える • プロフィール画像を変える • etc. 

なぜ公式アカウントマネージャーは 難しい⾯⽩いのか︖ • （純粋に規模が⼤きい、以外に） • OA を主体として提供されているサービスが多くある。 • 例）LINEトーク占い︓占い師の実装 = OA • OAのデータは社内の様々なサービスで利⽤されている。 • LINEのエンドユーザーの⼿元に届けるのは、これらの Service の画⾯。 • OAの情報が更新されたとき、変更内容がすぐに反映されるために、 様々な問題を解く必要がある。 

LARGE SCALE CMS の⾯⽩さ ー 書き込みパス • 書き込みパスが多い（22 Services) 公式アカウントマネージャー manager.line.biz Internal-api entry.line.biz パートナーツール Monitoring ツール 社内 CMS LINE占い RDB 

LARGE SCALE CMS の難しさ ー 読み込みパス • 読み込みパスも多い（> 50Services） LINE広告 PROFILE POPUP LINE XXX 公式アカウントリスト > 50 Services Many languages Many countries Many end-users LINE YYY (ElasJcsearch) 公式アカウントマネージャー manager.line.biz Internal-api entry.line.biz パートナーツール Monitoring ツール 社内 CMS RDB 

解決すべき課題 • 社内外のユーザーから絶え間なく寄せられる更新情報を、 LINE の様々なサービスに提供（同期）していくこと。 • 以下を満たしながら • 特定のサービスが Down しているときでも他のサービスに影響を与えない • 新規サービスインされるサービスも同じ⽅法で同期できる • 同期ミスがあったサービスも、サービス単体の⼒で回復できる 

AGENDA • LINE公式アカウントマネージャーと社内サービス • 解決すべき課題 • データ共有と同期⽅法の今昔 • New Design 

データ共有・同期⽅法の今昔 • Shared DB • API IntegraKon • API Crawling • Data Feed IntegraKon. (CSV IntegraKon) • API Push. (Web hook) • Message Queue. （Event stream) 

SHARED DB • データベースを共有することによりデータ連係を実現します • Pros • シンプル • Cons • Microservices 側のデータと JOIN できない • 強い依存関係（RDB Schema 変更で問題になることも） 

API INTEGRATION • ユーザーからのアクセスに応じて、 データをAPIで提供する別のサーバーを Call します • Pros • DB スキーマ変更の影響を受けない • Cons • API maintenance コストは多少かかる （ペイする） • JOIN ができない（再掲） 

API CRAWLING • 別途連携した ID などの SEED を元に、 定期的に全ての 項⽬に対して GET API を呼び出して同期します。 • Pros • データを取り込み、好きに加⼯・JOINできる • API INTEGRATION で初めた場合に、移⾏しやすい • 呼び出される側のパフォーマンスに問題が無ければ • リトライ可能 • Cons • 同期するまで変更があったかどうか解らないので、同期バッチが重くなりがち • アイテム数が多くなると破綻 • 頻繁な同期には適さない • リトライに気を遣う必要がある 

DATA FEED INTEGRATION 1. Pla$orm が全てのデータを CSV/TSV/JSON LINE 等の形式で出⼒ 2. 共通の Object Storage やファイルサーバーに配置 3. Microservices がそのファイルを読み取り • Pros • データを取り込み、好きに加⼯・JOINできる • Cons • 頻繁な同期には適さない 

API PUSH (WEBHOOK) • データに追加・更新・削除があった場合に、 Pla$orm が Microservices の特定の Endpoint を呼び出して通知。 • Pros • Microservices 側は、更新があったアイテムだけ処理をすることができる • (Near) Real 3me • Cons • Pla6orm 側の負担が⼤きい • Microservices がダウンしている場合に、Pla6orm 側で Retry が必要 • 1回の Update につき、Microservices 分の Webhook 発送が必要 • 『更新されたが Webhook が発送されていない』 バグのリスク 

MESSAGE QUEUE (EVENT STREAM) • データに追加・更新・削除があった場合に、 Platform が Message Queue にデータを送信し、 Consumer が任意のタイミングでそのデータを受信します。 • Pros • Microservices 側は、更新があったアイテムだけ処理をすることができる（再掲） • Platform から Message Queue に送信するのは1回だけ、配送は Message Queue の仕事 • (Near) Real time • Cons • Message Queue を使って貰う必要がある • 『更新されたが通知が発送されていない』 バグのリスク 

データ共有・同期⽅法まとめ Starting Point Contract Required platform processing power State Sync Delay Shared DB End User SQL (Schema) O(Requests) Zero (State less) API Integration End User API O(Requests) Zero (State less) API Crawling Service (Batch) API O(Services x Items) 1hour ~ 1day Data Feed Service (Batch) Feed Format O(Items) 1hour ~ 1day API Push Platform API O(Services x Updates) Near real time. Message Queue Platform MQ Payload O(Updates) Near real time. 

AGENDA • LINE公式アカウントマネージャーと社内サービス • 解決すべき課題 • データ共有と同期⽅法の今昔 • New Design 

MESSAGE QUEUE を利⽤した⼿法を導⼊ • Stateless な⽅法が使えない Microservices がある • OA データと Service 固有データを JOIN しつつ検索・ソートしたい。 • SPoF / Performance の懸念 • (Near) RealKme の同期が必要（Batch 不可） • Service 側 Down に対する回復性 • O(Updates) ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ※ Message Queue 意外の⽅法も併⽤ ❌ ❌ 

DESIGN OVER MESSAGE QUEUE • DB が更新されたタイミングで Message Queue に更新通知を送信 • 社内各 Microservice がこれを Consume • Message Queue には Apache KaCa を利⽤ • 社内の特別チーム運⽤での Availability / Performance の⾼さ[1, 2] • 社内で⾮常に広く利⽤される • 情報を配信する Fan-out に適する • Message が複数の Service (Consumer Group) それぞれに届く • 同じ Service の複数のサーバーがあった時には負荷分散して届く • Service が Down している間も、Message Queue 内で Message を保存可能 • 障害ドメインを分離できる • 何をきっかけに通知するか → DB (MySQL) が更新されたタイミング • MySQL の ReplicaFon log (binlog) をパースして取得 

CHANGE DATA CAPTURE（変更データキャプチャ） BY DEBEZIUM • Design の Key Part︓ debezium.io “Stream changes from your database.” • RDB の変更を Capture • 公式アカウントマネージャーでは、 MySQL と組み合わせて Embedded モードで利⽤ • Support MySQL, PostgreSQL, Oracle etc. • WriLen by Java. From h'ps://debezium.io/ 

PROS: 実装漏れを避けられる • Background: > 270 API • API に実装する形で通知を仕込んでいくと、 DB を更新しても更新通知を送信していない問題がおこりがち • 『ただのバグ』 と⾔い切れるものではない • 結局 API Crawling したほうがいい︖ と疑われるのも⾟い • MySQL のログを元に Capture すれば、実装漏れがない • + マニュアルオペレーションも⾃然に対応可能 

PROS: V.S. REPLICATION DELAY • Background: 9 Replica. • Primary 更新完了 → KaUa 経由で更新通知 → GET API 呼び出し → Replica から更新前のデータを呼び出し で更新前のデータが返ってきてしまう事があった。 • Microservices 視点では、通知後にデータを洗い替えているため、同期は完了している • 結果整合性（Eventual consistency）違反 • 解決⽅法 • レプリケーションポジションを明⽰的に扱うことで解決 • Replica1on 完了を待って Message Queue へ更新通知 • 『最後の更新通知を受け取った後の GET Request は、必ず最終状態を返す』ことを保証 

FINAL IMPLEMENTATION 

No content

学び / 変更データ同期 • RDB が中⼼の PlaVorm で更新を漏れなく伝えるために • まずは RDB を中⼼に考えると良い • アプリケーションで変更をハンドリングすると、 思わぬバグの温床になりがちだった • 変更の同期について、RDB は既に ReplicaJon という仕組みを持っている • ReplicaJon ログ (binlog) をアプリケーションが取得することは、可能 → Debezium etc. • システムの整合性について、様々な単位で知っておく必要があった • 例）RDB 単体が持っている整合性と、 Source-Replica を含めたシステム全体が持っている整合性は異なる 

まとめ / LARGE SCALE CMS • 『RDB を更新して終わり』ではなく 積極的に状況に関与していく必要がある • 関連 Microservices に対する責任は⼤きいが、⾯⽩い • 『知っている聞いたことがあるけど気にしたことはない』 データ整合性との戦い • Thank you for your aYenKon.