読者です 読者をやめる 読者になる 読者になる

TMD45'β'LOG!!!

Life is Beta-ful.

LINE DEVELOPER DAY 2016 #linedevday (2)

さて前の記事に続き『LINE DEVELOPER DAY 2016』の、午後に参加したセッションのメモ①です。

スライドや動画のまとめは公式開発ブログにあるので、そっち見たほうが早いぞ(何

あとで調べて書き直すかもしれませんが、現時点ではいろいろあやふやなままでもメモってますので、あしからず。ツッコミは大歓迎です。

A-3 『LINEが乗り越えてきた困難な問題』

「去年は LINE の成長の歴史を話しましたが、今回は LINE がサービス『ダウン』した歴史をお話します」

主な大障害

  • 2011/12/18
    • Redis サーバ拡張でマスター追加。レプリケーション ON のまま実施したため、マスターデータで初期化された。会員情報が全部消えた\(^o^)/ 統計用の MySQL データとWeb アプリのログを用いて、27 時間後 復旧。
  • 2013/5/3
  • 2014/6/30
    • GC の設定ミスでプロセスが起動しなくなり、1時間ダウン
    • ...この頃、サーバ数千台。リスタートにも時間がかかる
  • 2016/3/11
    • 今回はこの話。1時間40分のダウン

というわけで、詳細はなかなか複雑なのでスライドの図を見てどうぞ。

「今回学んだこと」より

  • マイクロサービスがまだまだ実現できていなかった
    • 影響があちこちに飛び火した(着せ替えデータの更新→(中略)→メッセージもVoIPもサービス全体に影響)
  • たとえば
    • 自衛のために、大量データの登録ができないようにする
    • 利用者のリクエスト(その量は予想できない)バーストに耐える(→ Circuit Breaker)
    • 非同期 RPC の活用(→ Armeria)
  • 改善を重ねていく
    • 問題は0にはならない。潜在的に在る
    • 周りが変化して発生する場合もある(この障害が、あるデータ量のしきい値を超えてしまったことによって発生したものだったのでそういう話が)

質疑応答

  • 「(再発防止の会議で上がった)18 Issues はどのくらいで片付いた?」
    • まだ解決していないものもある。順次取り組んでいく
    • 今回発表したものは解決済み
  • 「Circuit Breaker で全てブロックしてしまっている?それはそれでリスクでは?」
    • 認証(← Circuit Breaker を導入しているサービスがこの部分)が必ずしも必要ないものを選んで導入している
    • 選ぶときは各部門と話し合って決めている
  • 「今回の障害はどうやって原因特定まで至った?」
    • まず 普段からモニタリングしていて、そのデータ上でアラートが上がった
    • そこから(原因の原因を)辿っていった結果、わかってきた
    • "着せ替え" の更新があったとわかった時点で "着せ替え" のチームに連携
    • 正確にはわからないが、これらのやりとりは 5〜10 分くらい だったと思う
  • 「今回のような障害のやりとりはLINEでやるの?」(会場・登壇者から笑いw)
    • LINE が使えなくなるような障害のときは(苦笑)、hipchat や別の社内ツールを使ってやりとりします
    • そうでなければ普段から LINE を使ってます
  • 「今回の更新(作業)のような対応は全体で共有している?」
    • 他に影響があるかどうかは(作業をする)チームで事前に検討して、必要があれば他チームにも共有している
    • ただ、今回は「影響がある」と判断できず "着せ替え" のチームだけで対応していた
    • 障害が起こるまでに何度も同じ更新作業は行っていたし、その間は問題が起こらなかったため
    • 今回例外だったのは「2,000件(しきい値)のデータを超えてしまった」という点

LINE というサービスの障害の話をここまで詳しく聞けるのは、とても興味深かった。

マイクロサービスでの、サービス間の連携で気をつけないといけないことがリアルに認識できたような気がする。

A-4 『LINE Login - LINE Platform』

LINE Login

弊社・弊チームではおなじみのソーシャルログインです。実装については OAuth 2.0 で「ちゃんと State 使ってね!」と「Callback URL は LINE の管理画面から登録が必要だよ!」と強調があったくらいで、そんなに変わったことは無いですかね。

LINE が提供する Web ログインを利用する利点の話。

  1. LINE ユーザの会員情報を利用したログイン
    • ユーザ数は世界で2億ユーザ以上
    • この圧倒的なユーザ数!
  2. Web, Android, iOS で対応
  3. オートログイン
    • LINE アプリの In App Browser であればオートログインが自動で行われる
    • とくに設置したログインボタンや、ログインのバックエンドで何かする必要はない
    • ユーザは ID(メアド)とパスワードの入力が省略できてハッピーに

オートログインも、実際に動いている様子が動画で紹介されたので、みなさま分かりやすかったのではないだろうか。

LINE Login を簡単に試せるデモアプリも用意(heroku deploy ボタンがあるよ!)

利用事例。niconico, 一休.com, 出前館, リクナビ

そして Official Web App の話。先行事例としてリクナビ, 一休.com, 出前館

PROFILE+

  • 一度入力した個人情報の再利用 → 会員登録をかんたんに
  • リリースはまだ先
    • Official Web App 導入企業は先行利用できます

今後の予定

  • 電話番号でのログイン*1
  • Social API への友達情報、投稿取得などの追加を検討
  • Email API の提供を計画(これは toB で喜ばれるんですよねぇ…)
  • LINE@ アカウントでの友達追加 API 提供
  • LINE Pay との連携

A-5 『Security x LINE Platform』

LINE Architecture

Transport Security

  • LEGY(LINE 独自コンポーネント
  • LEGY Encryption
  • LEGY Encryption FS
    • 詳細はスライド参照

Messaging and VoIP Security

  • Messaging E2EE
    • 指定されている相手しかメッセージの複合化できない
    • たとえ LINE であっても復号化はできない(これ去年の発表で興味深く思ってました)
    • Letter Sealing
      • 1:1 メッセージにしか適用されていなかった
      • 現在は Group Chat もサポート(50人まで。全員が Letter Sealing ON の場合)
      • 有効になってるとアプリ上で鍵マークがついてる
      • デフォルトが ON になっている
      • 将来的にはビデオ、画像にも適用する予定
    • Letter Sealing for 1:1
      • 自分の private key + 相手の public key で暗号化
    • Letter Sealing for Group
      • その Group のメンバー全員の pub key を使って shared key を生成
      • (詳細はスライド参照)
  • VoIP E2EE
    • LINE 6.5.0+
    • こちらも詳細はスライド参照(パッとメモれなかった;)

Device Security

  • 端末内のデータを守る
    • "True Delete" v5.3.0〜
      • Overwriting NULL
      • メッセージを消すと確実にメッセージを消せる
      • (フラグ立てて見えなくするだけではない)
    • 専門企業(名前聞き取れなかった;)と連携して高度なセキュリティ機能を開発中
      • 内容は非公開

詳細仕様

(ここで2人目にバトンタッチ。おもに Game のセキュリティの話)

Risk Assessment

  • Security 診断
    • Web → 脆弱性診断(一般的なもの)
    • Game → チート対策、ボット対策、いろいろ…

Game について、時間をかければ解析されてしまうが「突破の障壁を高くする」「サーバで不正をすぐに検知できるようにする」。

Anti-Spam/Game Abusing

  • チートツールのデモ
  • 実例とその対策

Android の中で SSL 通信してても MITM でパケットキャプチャリングできる。 なので SSL 通信だけでなく、通信に載せる前に暗号化する

コードを decompile しづらくする。

Bug Bounty Program

  • サーバ側の対策
    • 自動化したい
    • 人と bot の区別
    • 機械学習を利用したいが、難しい
      • こちらが対策すると、相手はそのしきい値をついてくる
      • "データセットは攻撃者が用意する" ことになるため、役に立たない
    • 0.01% は誤検知でスパム判定されてしまう
      • この確率は厳しい。もっと低い誤検知でなければ実利用に耐えない

質疑応答

  • 「前半の説明でメッセージは LINE サーバでも見られないという話だったのに、Spam 判定というのはどうやっているの?」
    • いまは全てのメッセージに対して Spam 判定を行うのではなく、ユーザから Spam 報告されたものだけ Spam 判定を行う
    • Spam 報告時にユーザに同意を得られたメッセージは平文でサーバへ送信されて判定に使用される
      • なるほどだ(・_・)



Σヽ(`д´;)ノ うおおおお!

f:id:tmd45:20160930015722p:plain

また長くなったのでさらに次の記事へつづく(;´Д`)

*1:いまは Web ログインのためにわざわざメアドの登録が必要だったりする。電話番号は LINE に登録するときに必ず使うものだし、メアドより覚えやすいのでログインの(ユーザの)手間が少し減る

▲ ページトップへ移動