LINE DEVELOPER DAY 2016 午後 整理されていないメモ
こちらの午後のメモを整理しよう整理しようと思い、数日経ってしまいました。
もう整理することを諦めて貼り付けてしまいます。
網羅性はないし、タイポなたくさんあって、自分にしか理解できない内容になってしまっています。
それではどうぞ。
LINEが乗り越えてきた困難な問題
2016/3/11に発生したサービスダウンについて
- 1時間40分ダウン
- デマで炎上する。
- 今でもテレビ局の取材がある
発生の経緯
- LINEのきせかえ機能の更新
- クライアントサイドのきせかえ画像の更新
- サーバ負荷増大
データ更新の仕組み
- UEN: ユーザにリクエストしてもらうための通知のサービス
- サーバからクライアントに通知
- 通知を受け取るとクライアントからサーバにリクエスト
- 一斉に通知が飛ばないように全ユーザ通知は時間を分散している
- 今は3時間程
- 通常の更新は認証不要
- ただし、全データ更新の場合は認証必要
- 全データ更新は更新データが2000を超える場合に、通信のオーバーヘッドを減らすための仕組み
- 全データ更新は長期間LINEを使って
データ更新の仕組み
- データ構造の変更が必要
- 着せ替えの数がテストのときと本番のときで違った
- 植えたし
- 2000を超えると全データ更新になる仕組みがあった
- リクエストのオーバーヘッドを彫らすため全データ更新
- 全データ更新の場合は認証が必要
- 全データ更新通知を全ユーザに通知
- 通常は1日10名程度
- 全データ更新は時間分散しない
- 全データは久しぶりに起動したユーザ扱いなので認証必要
- 認証サービスに障害が発生したのでデータ更新が以外のサービスにも影響が出た
復旧対応
- 認証サーバの不可を減らす
- 全データ更新リクエストが飛ばないようにする
- 認証種類がある
- リクエスト制限
- 認証の仕組みを回収
対応
- 全データ更新にも時間分散導入
- UAMの登録上限を儲ける
- 認証にサーキットブレーカーの仕組み導入
- だいたい全箇所(Micoroservices)に再発防止先を入れた
- 総務省への報告義務(音声通話があるため)
- 総務省のHPに議事録報告書がある
- Microservicesが不完全であった
- それぞれのサービスに自衛の仕組みが必要
- リクエストバーストを検知
- 全データ更新のリクエストだと判明
- なぜ全データ更新なのか。着せ替えの更新をやってるらしい。
- で判明。
LINE Login - LINE Platform
LINE Loginとは
- LINE ApplicationからLINE Service(LINE PayやLINE game)を利用する際にLINE Loginが使われる
- LINEユーザの会員情報を利用したログイン
- Web/iOS/Androidで実装可能
- iOS/AndroidにはSDKを提供
- Autoログイン
- LINEアプリからの動線のみAutoログイン
- Web:OAush2.0
- Native SDK: ApptoApp
- チャネルの作成が必要
- 使っている会社
- niconico
- ikyu.com
- Demae-can
- Rilunabi
LINE Loginロードマップ
Security x LINE Platform
LINE Architecture
- ApplicationはLEGYにリクエスト
- LEGYはルーティングと暗号化が主な責務
- TLSv1.2
- ネイティブアプリだとハンドシェイクなどで通信が必要
- TLSv1.3はハンドシェイクの簡略化がされる予定
Messaging E2EE
- iOSとAndroidのチャットのみ
- ユーザの端末でしか復号化できない技術
- Letter Saling Evalution
- Group Chat 対応
- Bの公開鍵、Aの秘密鍵で暗号化してサーバに投げる
- BはサーバにAの公開鍵のリクエスト
- BはAの公開鍵と自分の秘密鍵で受け取ったメッセージを復号化
- グループチャットも仕組みは違うが同じような仕組み
- サーバも平文を見れないようにしている
- VoIP（電話）もE2EE
- ローカルデータも安全に。
- 削除したら本当に削除する。フラグ立てるだけじゃない
Risk Assessment
Reverse Engineering
- Security Measures
- 改ざんされてもサーバでブロックできるように
- 最初の障壁を高くすることは大切
- ゲームのチート
- スピードハック、時間のハック
- 時間取得をフックして偽装するなど
- ネットワーク
- HTTPSでも証明書を入れると通信を覗ける
- 証明書を端末でチェック SSL Piling
- 短波正
- サーバサイドのチェック
- マシンランニングで自動化したいが攻撃側もマシンランニングしているので考えて実装が必要
- ご検知は0.01%以下でないと使えない
- he
Anti-Spam/Fame Abusing
LINE LIVE を支えるアーキテクチャ
- 2014年に追加したLINE LIVE CASTの評判が良かったのでLINE LIVEをうあることに
- 視聴者数をリアルタイム集計している
- HLS
- チャット機能はWebSocket
New stream processing platform with Apache Flink
- DataLabの体制
- Planner
- Developer
- Analist
LINE LIVEの視聴者数の話
- 10秒毎に更新しているリアルタイム集計している
- 求められる機能
- リアルタイム集計
- ユニークユーザ集計
- 耐障害性
- はじめは norikura を採用した
- LINE LIVEの仕様追加(だれでも配信)でスケーラビリティも求められるようになった
- そこで Apache Flink を採用
- ユニークユーザ集計で消費されるメモリ問題以外は Apache Flink で解決できた。
- メモリ問題はHyperLogLogで採用
- HyperLogLogはユニークユーザを推定する
- 誤差1%以内に収まった
- 使用メモリが180Gから80Mになった TODO: 後で数値確認
A True Agile Team - Global LINE News
- 海外に需要があるかわからなかった
- 6wで完了
- 経験無し
- チームも若く、シニアエンジニアがリモートで参加
- 他国にまたがりコミュニケーションが大変
- Agile/Scrum
- 様々な国のチームメンバー
- Scrumは手法でしか無い。CoreValueが大事。
- チームスピリット
- 信頼とコミットメント
- プランナーと開発者の信頼関係
- プランナーは正しい
- コミットメントは守る
- 開発者だけがスケジュールをコミットできる
- マネージャ(Scrum master)はアドバイスする立場。コミットしない。
- Planner -> Why -> What -> Developer -> How -> When -> Plannerのループ
- プランナーはなぜ開発にそれだけ時間がかかるか納得する節用がアアル
- セルフマネジメント
- 信頼とコミットメント
LINEのエンジニアが働く環境と文化
- Github Enterpriceを利用
- リポジトリ数 2016.9: 10660
- エンジニアはJapan, Korea, China, Taiwan, Thailand, Indonesia
- 海外だけのサービスも有る
- 各国独自のカルチャを理解して開発する必要がある
- ローカライズだけではなく、カルチャライズしている
- MicroServicesを採用していることもある1つのプロダクトが1つのオフィスで収まることはほとんどない
- 多言語のコミュニケーションは英語がマストではなく社内コミュニケーションでも通訳を通すこともある
- LINEの翻訳BOTを使ってコミュニケーションもしてる
- 翻訳BOTは社内の需要から出てきたもの
- なんだかんだFaceToFaceが一番良い
- 来年は新宿 MiRAINAに移転予定
開発文化
Take Ownership
- 自分ごととして考える
Take Risk
- 大前提として物事は計画通りに行くとは限らない
- だからといっていつも同じ事をやっていてはいけない
- リスクをどうとるか
Be Open
- コードはエンジニア全員見れる
基本的なマインド
- Trust $ Respect -> Self-directed Work -> Positive Peer Pressure -> Trust & Respcetのループが大事
- Trust $ Respect 信頼と尊重
- Self-directed Work
- PositivePeer Pressure
- 仲良しグループではなくいい意味でのプレッシャー
- 人事評価が大事
- マネージャはコードを読んでいないのではないか
- 同僚からの評価が一番大事
- マネージャは良いサイクルが回っているかサポートする
- 今までLINEは秘密的だった気がする
