しまてく

学んだ技術を書きためるブログ

LINE DEVELOPER DAY 2016に行ってきた

勉強会 行ってきた

LINE DEVELOPER DAY 2016とは

当イベントでは、弊社エンジニアチームの様々な経験や国内外での技術的なチャレンジ、 最新の製品について発表させていただきます。 各セッションでは、セキュリティ関連やBOTなどLINEが現在どのような課題を持ちどのように 解決しようとしているのかも共有できればと考えております。 cf: http://linedevday.linecorp.com/jp/2016/

資料は以下から見れます

http://www.slideshare.net/linecorp/presentations

私が聞いたセッションは以下。

  • A-1 Opening & Introduction
  • A-2 KeyNote New world by the LINE BOT
  • A-3 LINEが乗り越えてきた困難な問題
  • A-4 LINE Login - LINE Platform
  • A-5 Security x LINE Platform
  • B-4 Gravty "A scalable graph database to traverse large-scale relationship fast"
  • A-7 LINE LIVEを支えるアーキテクチャ
  • B-8 New stream processing platform with Apache Flink
  • A-9 LINE Shop powered by Armeria
  • A-10 LINEのエンジニアが働く環境と文化

以下まとめ

A-1 Opening & Introduction

全体的な紹介と方向性の提示。 - LINEの目指すSmart Portal - Messaging Platform - Line - Life Infra Platform - Line pay, Line card, Line pointなど - Content Platform - Line LIVE(日本)、Line TV(タイ) - 今後の注力分野 - AR/MR - Line cameraとの連携 - Data Processing & Mechine Learning - Data Lakeに集約されるLineの全情報を利用。 - スパム探知や攻撃検知など多様な解析を行う。

A-2 KeyNote New world by the LINE BOT

新サービスの紹介 - LINE Notify (当日リリースの新機能) - ChatOptに使う感じの開発者向けツール。 - IFTTTみたい、と思ったらIFTTTとも連携してた。 - かなり柔軟に利用できる。 - Line Messaging APIの最新情報 - 当日正式リリース。 - 新機能 - グループに入れられるようになった。 - 新しいメッセージタイプに対応。(カルーセル、YES/NO、複数ボタン) - 利用者から発信されたメッセージに対するリプライは無料に。 - リッチメニューで利用者がbotを使う時に迷わない導線を提示可能。

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

胃の痛くなるような障害を振り返って原因と一次対策と恒久対策について紹介。 - Lineのメッセージと音声通話が止まった。 - 原因は着せ替えデータの更新通知が意図せず大量に発行された事で、それに付随する認証リクエストがバースト。 - モノリシック的な作りになっていたサービスが災いしていろいろ連鎖的に死んだ。 - 2000件未満と2000件以上の時で処理が違っていて、2000件以上になった時に不具合があった。

  • 最終的な対応

    • 2000件以上の場合の処理もちゃんと分散処理する。
    • 異常を検知して止めるサーキットブレイカーを実装する。
    • 本来影響されるべきでない機能を分離。
    • など

  • 教訓

    • 各機能の問題が複合して発生した障害。
    • マイクロサービスを進めて、各サービス側にて自衛的処理をする。
    • 非同期RPCによってブロッキングしないようにする。

A-4 LINE Login - LINE Platform

LINE Loginについて紹介。

  • Lineのユーザー情報を利用したログイン機能
  • Auto Loginが便利。
  • 今後の展開
    • 他の機能との連携をより強化していく。

A-5 Security x LINE Platform

セキュリティについて。個人的にはここが一番おもしろかった。

  • LEGY(Line Event GatewaY)のEncryption

    • pinned RSA keysでMITM攻撃を防ぐ。
    • no X.509 certificates
    • 0-RTT handshake
    • ECDH-Key exchange

  • Messaging E2EE (End-To-End Encryption)

    • グループチャットでのLetter Sealing

  • VoIP E2EE

    • SRTPを使った通信で音声を暗号化。

  • データの完全削除

    • メッセージを消した時に完全消去するようにしている。

  • アンチスパム、ゲーム不正対策

    • GameHakerやGameGuardianでの値ハック
    • SpeedHack
      • サーバーサイドで時間を集計するなどで対策は可能。
      • しかしプレイ時間等、ユーザーの操作技術によって有り得そうなギリギリは難しい。
    • MITM Attack
      • SSL pinningが有効。
      • さらにSSLでやり取りするデータも自分で暗号化しておく。
    • 耐タンパー性について
      • Unity C#のdllはilspy等でかなり元に戻る。
      • il2cppオプションを使うと結構わかりにくい。
    • Server側の対策
      • 出来る限り自動化を進めている。
      • 誤検知(False Positive)には特に厳しい。
        • 正しいユーザーがBANされてしまうと悲しみは深い。

B-4 Gravty "A scalable graph database to traverse large-scale relationship fast"

LINEが開発しているグラフデータベースの紹介。今回聞いた中でこれだけ英語だった。同通レシーバーつけたり外したり。

  • FacebookのSocial GraphやGoogleのPageLankで使われているようなあれ。
  • Lineのタイムラインは7億件のデータがある。
  • これを上手く扱うために、HBaseをストレージとして、Tall Narrow Table Modelで実装されている。
  • Tall Narrowだと、HBaseはRowでスプリット可能で、並行スキャンもできるのでいい。
  • ただしインデックスをサポートしていないので、Phoenixで補完。
  • 非同期にインデックスプロセッシングをするためにKafkaを使っている。

A-7 LINE LIVEを支えるアーキテクチャ

LineLIVEの紹介。

  • 他のサービス同様にマイクロコンポーネントの組み合わせでできている。
  • HLSを使ってやっているのでCDNを使いやすい。
  • 動画ファイルをアップロードしておいて、リアルタイム風再生も可能。
  • CPUでやっていた配信処理をGPUに変えて効率化するなど進めている。
  • チャット機能はWebSocketで実現。
    • チャットサーバーは110台以上！
  • 複数のチャットサーバーをまたいでチャットを実現していて、redisのpub-subを使っている。
  • サーバーサイドはAkka actorを使ってる。
  • ライブ中のメッセージはredisに入ってるが、終了したらMySQLにアーカイブする。
  • 後にアーカイブされた動画がバズったら、コメントをjsonにまとめてHLS的な感じでCDNに置いて負荷対策。
  • 人は連打できるところがあれば連打するので、連打が気持ちいいUIにする。

B-8 New stream processing platform with Apache Flink

データラボの紹介とLiveLIVEのデータの扱いについての説明。

  • Line LIVEの裏側の処理はいまはver2。
  • ver1時点の課題として見えていたものは以下の３点。
    1. リアルタイム集計
    2. 番組毎のユニークユーザー数
    3. 耐障害性
  • ver1は上記課題に対して、以下のように解決していた。
    1. リアルタイム集計
      • Norikraによるリアルタイム集計
    2. 番組毎のユニークユーザー数
      • 120GBのメモリを搭載して力技で解決
    3. 耐障害性
      • 待機系を用意して冗長化(待機系はもっとメモリが多い)

  • ver1での障害

    • アイドルグループの生放送でメモリ120GB使い切った。
    • OOMは出ていないものの、ほぼ動いていない状態。
    • この時は待機系に切り替えて乗り切った。

  • その後個人からの配信も可能にする計画があった。

    • もうNorikraの構成じゃ耐えられない。。

  • ver2を開発。

  • ver2はver1の課題に加え、スケーラビリティが求められていて、以下のように解決した。

    1. リアルタイム集計
      • Flink
    2. 番組毎のユニークユーザー数
      • HyperLogLog
    3. 耐障害性
      • Flink
    4. スケーラビリティ
      • Flink

  • 結論

    • Apache Flinkを使うことで多くの問題が解決できた。
    • ユニークユーザー数の集計はHyperLogLogを使うことで大量のメモリが不要になった。

  • FlinkのProsCons

    • Pros:
    • Cons:
      • ジョブを変えたりクラスタを変えた時に内部状態を引き継げない。
      • 稼働中のジョブの並列度を後からあげることができない。
        • 覚えている状態をすべて消さないとだめ。
        • 今後改修予定。
      • ジョブ間の独立性が弱い。タスクマネージャの中のスレッドで実行しているので、 一つ間違ったジョブがあって死ぬとプロセス毎死ぬ。 →Hadoopのyarnを使うと対応可能。

A-9 LINE Shop powered by Armeria

LINEが開発している非同期RPCのOSSの紹介。

  • 着せ替えショップとかスタンプショップとかで使われている。
  • 非同期RPC、API Client/Serverライブラリ
  • Java 8, Netty 4.1, HTTP/2, Thrift
  • 毎秒数十万のリクエストをさばける。

  • 各種メトリクスの取得も可能。

  • 注意する点

    • HTTP/2にすることで、ロードバランサーがTCPコネクション単位でバランシングしていると偏りがち。
    • →クライアントサイドロードバランシングで解決する。

A-10 LINEのエンジニアが働く環境と文化

LINEの文化的なところ。 - 働きやすそう(こなみ)

まとめ

お食事券2000円分に驚き、会場の豪華さに驚き、カフェスペースの無料開放に驚き、 LINE LIVEでのリアルタイム配信、LINE BOTをつかった情報配信、Beaconを使った体験の提供、 さらにBeaconの無料配布、などなどLINEの札束感というか勢いに圧倒されまくりでした。

LINEの印象が大分変わった一日でした。

おまけ

ホールAの豪華さ f:id:cimadai:20160929100219j:plain 無料でもらえるおかし f:id:cimadai:20160929125102j:plain