- LINE DEVELOPER DAY 2019に参加してきました。
- セッションの資料はこちらに随時公開されるとのこと
- 今回はDay1の午後だけ参加してきました
- 以下セッションのメモです
Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦
- 大森 貴博さん
livedoor Blog
- 構成
- LAMP
- 30近くのサブシステム
- 15年での蓄積
- Developper
- 70+
- サーバ
- 750+
- 200がDB
- DBテーブル数
- 550+
- ファイル数
- 43500+
- プログラムファイル数
- 3800+
- Perl
- コードの行数
- 410000+
- Developper
- 今動いているブロジェクト
カオスとレガシー
ドキュメントがない
- セットアップ方法がわからない
- デプロイ方法がわからない
- 普段触ってないサブシステムだと特に
開発サーバがない
- 誰からも忘れられていて安定して動いたサブシステム
- それに手を入れようとしたら環境がない
- 開発サーバはあるか?
- 正常に動いているか？
- 本番との差分がないか？
- 本番のデータを使っていないか？
テストがない
- カバレッジが低い
- そもそもテストがない
DNSレコードが多すぎる
- 300レコード以上
- ユーザが設定してる独自ドメインとかは入ってない
- 調査したら230が不要だった
- 古い機能とか過去のキャンペーンでの残骸
- 整理して削除するだけで数ヶ月
機能が多すぎる
Perl
MySQL
- MySQLのバージョンが古すぎる
- 4.0(2003年)
- ローンチしてから変えてない
- 4.0でできないこと
- Online DDL
- Fast Index Creation
- Trigger
- => オンラインでalter tableできない
- テーブルコピーしてデータ移行して、、と無理やり頑張った(数ヶ月かかる)
- データが2倍だからディスク容量が逼迫
- バージョンを上げないのか？
LINE BLOG
- LINEとの連携が強い
- 2014年リリース
- 最初は芸能人など一部の特別な人のみ
- livedoor BlogのASP機能
- 2016年リニューアル
- 一般公開
- 独立したサービスに
- livedoor Blogをフォークした
- livedoor Blogのカオスとレガシーも引き継いだ
- => LINEのエンジニアが本気出して数々の問題を解決
Next 15 Yeras
- 15年後を考えて開発していくことが大切
- 小さなことからでも始めること
- コメント一行書くだけでも
- 不要なファイルを削除しておくだけでも
LINE NEWSの記事配信を支える技術
- 稲葉 大樹さん
LINE News
Personalized Recommendation
- 多大な記事数ユーザ数をもとに記事をレコメンドしている
- ML + Manual(運営の手動)
- 表示対象かつ表示期間中のものがユーザに表示される
MLによるレコメンド
- 社内のMLチームで生成されたものをもとにレコメンド
- 1億人超えのデータが入っている
- ユーザ一人に付き200件の記事を選んでる
手動によるレコメンド
- 運営チームがCMS上で設定
- 属性に応じてどの記事を表示するか選ぶ
- どの媒体をフォローしてるかとかも属性として選べる
MLのレコメンドだけを使っていた時代
ML + Manualでレコメンドしていた時代
- Central Dogma
- Datalakeから対象ユーザのIDを取得してCMSにアップロード
- 記事IDとユーザのマッピングをRedisにあげる
- Central Dogmaに記事の情報をあげる
- 課題
- 記事とユーザのマッピングデータの形式の影響でスケーラビリティがない
- パフォーマンス
今後
- 今はユーザからのレスポンスが反映されるまで1時間かかったる
- リアルタイムに反映させたい
- 今ABテストで一部のユーザに適用
- レコメンド適用範囲の拡大
- ダイジェストは今全員同じものを出してる
コミュニケーションアプリ「LINE」の機能改善を支えるデータサイエンス
- 高口 太朗さん
LINE App Improvement Project
- Uesrs First
- Data Driven
- Diverse Team
- In-houes Developmemt
データサイエンスチーム
- Data Science And Engineering Center
- Data Labs
- Data Science Team
- Data Labs
- Data Science Team
- LIENマンガ
- LINEトップ
- LINE Pay
- LINE ad
プロジェクトのサイクル
- ユーザリサーチ -> 計画 -> 開発 -> テスト -> フィードバック -> 計画 -> ...
ユーザリサーチ
計画/開発
- 計画
- どうデータではかれば良いか考える
- 開発
- どのようなログを集めればよいか定義など
テスト/フィードバック
- テスト
- オンラインでのABテスト
- 2018~で20回以上者ABテストをやってきてる
LINEアプリ改善の取り組み
- LINEアプリならでは
- ユーザが多い
- 使い方もさまざま
- LINEアプリを評価する単独のKPIが存在しない
- メッセンジャーは無料の機能
- すでに多くのユーザを獲得してるからユーザ数xx増加とかもやりづらい
- LINEのコアバリュー
- LINEのミッション
- Closing the Distance
- メッセンジャーアプリにあてはめると
- 身近な友達と簡単にやりとりできること
- そのために改善すべき機能を考える
- LINEのミッション
- 友達ネットワークを分析
- 社会的なネットワークが反映されている
- グループ機能の改善がターゲットに
グループ機能の改善
- ユーザリサーチ
- グループ作成の手順がわかりづらい
- 当初
- グループ名やアイコン決めてからメンバー選択
- 急にグループ名聞かれても困るのでは
- 計画
- グループ名選択よりも前にメンバー選択を持ってくる
- ABテスト
- 入れ替えてもグループ作成成功率は変わらなかった
- フィードバック
- どこに目をつけるか
- 成功したユーザに着目?
- 失敗したユーザに着目?
- 時間帯に着目?
- 地域に着目?
- グループ名アイコンを選ぶ画面まで進んでない人が多い
- スムーズにメンバーを選べていない
- テスト期間中に複数回失敗したユーザ30%程度
- どこに目をつけるか
- 計画
- 最近トークした友達を上に持ってくる
- グループ名アイコンとメンバー選択を一画面で
- ABテスト
- 2種類×2の4通りテスト
- 比較のパターンが多いので偶然の差異を拾ってしまう可能性がある
- 組み合わせの一つを諦めて3パターンを検証
- 2種類×2の4通りテスト
- フィードバック
データサイエンスツール
- 分析の環境とツールによってこれらの改善は支えられている
- ABテストするためには
XXE、SSRF、安全でないデシリアライゼーション入門
- 徳丸浩さん
XXE
- XML外部実体参照
- 外部実体参照
- XMLはentityを定義して参照することができる
- 攻撃の例
SYSTEM /etc/hostsとか指定すると内容がとれてしまう- URLを指定するとその内容が読み込まれてXMLに展開される
- SSRF(Server Side Request Forgery)
- 原因
- XMLのもともと保つ機能
- 対策
SSRF
- Server Side Request Forgery
- 攻撃イメージ
- 直接アクセス不可の内部サーバがある
- 公開サーバを通して内部サーバにアクセスを許可している
- 公開サーバを踏み台にして内部サーバにアクセスすること
- 攻撃の例
- 原因
- いろいろある
- XXE
- SQLインジェクション
- OSコマンドインジェクション
- ディレクトリトラバーサル
- SSRF脆弱性
- 事例
- Capital Oneの例はSSRFだった
- WAFの設定ミスによるもの
- HostヘッダにEC2インスタンスを指定することによる攻撃
- WAFの権限がS3へのアクセスなど広く与えられすぎていた
- 対策
- ホスト名がIPアドレスであることをチェックするだけではダメ
- リダイレクトされてしまうなどさまざまなケースが有る
- ネットワーク的にチェックする
- 許可されたURLかどうかチェックする
- ホスト名がIPアドレスであることをチェックするだけではダメ
安全でないデシリアライゼーション
- シリアライズ
- バイト列に変換してオブジェクトに格納できるようにする
- 外部から来たシリアライズデータをデシリアライズするとどんなオブジェクトでも作れてしまう
- メソッドをいじったりとかはできない
- プロパティを工夫するといろいろできてしまう
- メソッドをいじったりとかはできない
- 対策
LINEのメッセージングプラットフォームにおけるマイクロサービス化への長い道のり
- 井出 真広さん
LINE Messaging Platform
- 2011年ローンチ当初はモノリシックだった
- talk-server/redis/msql
- 1つのチーム/1つのサーバでうまくいっていた
- どんな機能を追加していくか同じ方向を向いてできていた
- 追加したい機能がたくさん増えてきてチーム全体で調整する必要がでてきた
- 速度を持って進められなくなってきた
- チームを分割してサービスを分けるようにしていった
- チーム単位でそれぞれコントロールできるようになった
- スタンプ/メッセージング/認証/...
- 現在は多くのサービスが連携し合いながら動いている
- チームごとにやりたいことにフォーカスしながら開発している
- マイクロサービス化して
- よかったこと
- コンフリクトが少なくなった
- よくなかったこと
- ネットワークレイテンシ
- 障害
- よかったこと
マイクロサービスを構築するためのツール
- Coneectivity
- Directory Service
- Routing
Coneectivity
- Armeria
- 非同期なRPC/RESTライブラリ
- Java/Netty/HTTP2
- ロギングや分散トレーシングの仕組み
- 障害を伝播させないためのサーキットブレーカーの仕組み
Directory Service
- Central Dogma
- サービス間で設定を共有したい
- 通信先のサービスがどこにあるのか把握したい
- どのホストが度のサービスを配信しているか
- gitをバックエンドとしたバージョン管理の仕組み
- どの時点でどの設定だったか管理
