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

TMD45'β'LOG!!!

Life is Beta-ful.

LINE DEVELOPER DAY 2016 #linedevday (3)

LINE イベント

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

もう一度言うけどスライドや動画のまとめは公式開発ブログにあるので、そっち見たほうが早いぞ!!

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

A-6 『Group App Platform』

現在の Group 機能

  • LINE はもともと知人同士のメッセージのやり取りで発展してきた
  • Group の使い方が変わってきている
    • Group 機能の強化を検討
  • 要望
    • メンバー管理(メンバー追加が可能、など)
    • Flexible chats
      • 見せたくない人にうっかり見せないように
    • Chat history
      • 途中で参加した人が過去の発言を見られるように
    • More.
      • グループをかんたんに解散したい
      • など

Group 1.x → 2.0(開発・構想段階)

  • 1 member Levels → 3 member Levels
    • Owner
    • Admin
    • Normal
  • Admission Types
    • メンバー追加に Owner や Admin の承認が必要な Group Type
  • 複数のトークルーム
    • グループ内に別々のトークルームを作成できる機能
    • 1chat/1group → multiple chats/1group
    • トークルーム毎に private / public を選択可能

Group 2.0 Application Platform

多くのユーザは Group にメッセージ以外の機能を求めている 多くの情報、多くの共同作業

もっと Group へのサービス提供を、開発してほしい。 LINEはそういうフレームワークを用意する。

開発中サンブルデモ

  • Group ID, Chat ID を常に意識する
  • Access Token Type の考慮
    • いろいろあって Channel Access Token を利用することにした
    • (LINE には User Access TokenChannel Access Token があります)

フロントエンド SDK

  • LINE Channel SDK
    • かんたんに LINE の素敵なフロントエンドデザインを適用できる SDK
    • ただしまだ非公開。いずれ公開するかも?
    • Apache Cordova がどーとか(聴き逃した…)

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

  • 2014/2 LINE LIVE CAST お試し → 好評だったので個別アプリ化
  • 有料アイテムの購入、配信者へのインセンティブなども可能

これはスライド見たらよい。

HLS Good Hack on LINE LIVE

  • アップロード済みのデータを基に、ライブ配信のような体験を
  • Data LIVE
    • 複数のユーザが動画の同じタイミングを見ているということ(しばらくよくわかってなかったけど、気づいたら「おおー!」って思ったw)
    • 時間・タイミング内なら 200 を返す
    • 時間外には 404 を返す
  • Auto play
    • 任意の動画位置を再生できる *.m3u8 ファイルを生成する
  • Stream Terminated 対策
    • 配信元の RTMP 通信が死ぬと
    • CDN に新しい動画が存在せず、ストレージにアクセスがくる
    • しかしストレージにもデータはない
    • アプリ側はなんとか動画再生しようとしてアクセス
    • 死んじゃうのでなんとかする必要がある
      • Standby Until Recovery
        • Vurst API Server 用意
          • トラフィックに特化した専用 API を考慮
          • Media の SUSPENDED を判断して返す
          • BurstAPI が死んでも他に影響しない設計を考慮
          • SUSPENDED → RESTART になったら動画配信を再開
  • インフラチームの取り組み
    • CPU で動画処理 → GPU で動画処理(現在検証中)

LINE LIVE の Chat

  • Chat Overview もスライド参照
  • LIVE 終了後の Chat ログを Archive(Redis → MySQL
    • 動画配信の HLS (HTTP Live Streaming by Apple) と同様に(参考に)
    • Chat のデータ json を分割して、インデックスにまとめるという方法
  • 障害
    • JVM のメモリオーバー(ももクロのあーりん配信w)
      • 10,000 messages / min、たいしたことなさそう?いやいや
      • 10,000 messages を(たとえば)10,000 users に配信するということになって(掛け算すると)馬鹿にならない

LOVE 機能

  • 「人間は連打できるところでは連打する」*1
  • 「連打はコミュニケーションになる」
    • 連打の回数をできるだけ早く反映する
    • クライアント側である程度カウントを溜め込んでから送信する工夫
    • ライブ中の LOVE 連打数ランキングは、Redis に保存する時点でソートしている(?)
  • SKE48: 11 million Loves in 120 minutes
    • LOVE 獲得数によって企画!!! → LOVE 開発者「ザワザワ…」
    • 問題なく突破!ヽ(=´▽`=)ノ
  • 欅坂46: 2.3 million Loves in 30 minutes
    • v2 リリース直後でも問題なし

さらに参考情報

質疑応答

  • 「Redis Cluster はいま何台?」
    • 3台(待機系1台)。途中追加も発生したことがある。クライアントの設定しくじって障害になったりもした(苦笑)。いまはもちろん直ってます
  • RTMP (Real Time Messaging Protocol) を HLS にする変換負荷。商用のものもあると思いますが?」
    • 話したかったが別チームで対応してるので情報収集してなかった。開発ブログに書いてもらうように言っておきます

一つ前に聞いた話の続きみたいなセッションだった(LINE LIVE での話)。部屋移動して聴きに行ってよかったな。

Data Labs

  • 2016/3 新設
  • 社内横断的チーム
    • データという切り口からサービスをサポートしていく
    • データ分析の専門家が在籍
    • 結果をサービスにフィードバック
  • 技術開発
  • チーム設立前
    • データは各チームに散らばっていた
  • Data Platform
    • 各サービスのデータ(リアルタイム、バッチ処理
    • Data Lake(Hadoop, Hive, Spark, ...)
    • データ解析など
      • 去年の資料参照とのこと

LINE LIVE Stream のデータ活用ケース

  • LIVE View Count(視聴者数)
    • 10 秒間隔くらいでアップデートしていく(polling)
    • カウント取得 → バックエンドから Data Labs システムへ → そこからカウントを返す
  • Challenges
    • リアルタイム・アグリケーション
    • Unique User Count
    • 耐障害性
  • 1st Version: Norikra
    • 利用のきっかけは、元々 Fluentd でログ収集して Norikra で解析していたので
    • 問題点:カウント対象の日付が伸びると大量のメモリを食う → 大量のメモリで対応
    • LINE LIVE の一般開放で「拡張性」も必要になった
      • 分散ストリーム処理エンジンを検討 → Apache Flink 選択
  • なんで Apache Flink を選んだのか?(Spark, Storm などではなく。2016/4時点)
  • 2nd Version: Apache Flink + HyperLogLog
    • HyperLogLog は Unique user count アルゴリズム
    • Usage が 1st: 120GB+ → 2nd: 80MB (激減!)
    • 誤差も少なく、処理速度も向上した
  • Flink のその他のケーススタディ
  • いいところ
    • 冒頭の選定理由。とくに耐障害性
    • 開発・MLが活発
    • (海外では meetup もある)
  • 足りないところ
    • ジョブ改修、クラスタアップグレードするときは必要なログを手動で再投入するなどが必要
    • 稼働中のジョブの並列度を後から上げることができない
      • 新しく起動しなおすときはこれまでのデータをまっさらにしないといけないので…
    • ジョブ間の isolation

質疑応答

  • 「HyperLogLog では推測であり、正確な値はバッチ処理が必要になるという話がありましたが、バッチ処理はどのくらいの時間がかかる?」
    • 多段に処理をしてるのでそのポイントだけの正確な処理時間はわからないが、だいたい 1 時間くらいだと思います
    • (ちょっとこの辺理解してなくて質問も回答もよくわからんかったです;)

A-9 『LINE Shop powered by Armeria』

\ARMERIA は いろんな使い方が アルメリア 🐸/

LINE Shop & Armeria とは

  • LINE Shop とは
    • 着せ替え
    • スタンプ
    • LINE Store(着せ替え、スタンプ以外も対象とした Web サービス)
  • Armeria とは
    • http://line.github.io/armeria/
    • 非同期 RPC/API client/server library built on top of Java 8, Netty 4.1, HTTP/2, and Thrift
    • 名前の由来: Sea Thrift から、日本名「ハマカンザシ」という花の名前

Armeria の利点

  • 実際の製品(=LINE)で使われているライブラリである
  • 非同期処理に親和性が高い
    • LINE Shop
      • 大量の、関連度の低い、ユーザリクエストに、低いレイテンシで
    • 毎秒3K〜4K x 複数サーバ
    • たとえば、1 画面で複数タイプの商品データを取得したい
      • 複数タイプのリクエストが同期(直列)する必要はない
    • 大量のユーザリクエスト
      • 発生する大量のバックエンド to バックエンドリクエスト
      • → 解決は HTTP/2!TCP Connection が節約できる
      • Listen Drop が発生していたがそれも改善した!
  • メトリクス取得機能も存在しているのでモニタリングも楽
  • ちょっとした問題点
    • 同期処理 → 非同期処理にするための学習コスト
    • 1つのTCP Connectionの生存期間が長い
      • LB の Balancing が偏ると、その影響が続いてしまう
      • Client Load Balancing で解決したりした

How to use Armeria

実際のコード例。スライド参照。

  • Real Code Examples
    • 必ずメトリクスを取るようにしている

And More Armeria!

質疑応答

  • 「gRPC ではだめだった?Armeria のほうが良いことがある?」
    • gPRC は完全に HTTP/2 前提なので、HTTP からはじめたのが Armeria。また Thrift を使っていたという点も大きい

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

リクルーティングなお話だったので話半分でしけど いいなと感じた部分をピックアップ。

  • GHE Repository 5612(2015.12) → 10660(2016.9)
    • すごい増え方w
  • (日本語でも)グローバルにやりとりするコツ
    • 日本語でしゃべるときに、あえて敬語使わない
    • 難しい言い回しは平易にする
    • カタカナで書かずにアルファベットで書く
    • 実際に会って話す(ならんでコーディングするとか)のが大事
  • エンジニア行動指針
    • Take Ownership
      • エンジニア個々に数字を持たされるわけではない
      • 自分事として考える
    • Take Risks
      • プロトタイプを早くつくるとか
    • Be Open
      • KPI などは社内で公開している
      • 人からの指摘も前向きに捉えて前向きに進んでいく
  • マインドと行動
    • Trust & Respect
    • Self-directed Work
    • Positive Peer Pressure → 上司が、というより同僚同士でよいプレッシャーを掛け合えるといい
      • これらのループ
  • Open to public
    • これまで、技術情報を意図的に非公開にしてきたわけではない
    • スケールに忙しくて情報公開に時間を割けなかっただけ
    • それじゃいかんということで、これから力をいれていきたい
    • OSS へのコントリビュートもしていきたい

全体感想

一企業の継続的な取り組みということで、去年の LINE DAV DAY の内容を踏まえた上で、さらにそこからこう進化したよ、みたいな話もあり。去年は直接参加してはいなかったけどそこそこ追っていたので、そんな部分を聞けたのが他の開発者向けイベントと違った、面白い点だなと思いました。

f:id:tmd45:20160929232658j:plain:w500

ブログのサムネ用に、貰ったものを並べてみた!明日から会社で使いますw

明日も引き続きお仕事頑張るぞ(意味深?)

*1:はてなスターかな?と思ったはてな

▲ ページトップへ移動