なみひらブログ

学んだことを日々記録する。～ since 2012/06/24 ～

「LINE DEVELOPER DAY 2016」に行ってきました

Java セミナー リンク プレゼン ビジネス チームビルディング プログラミング

「LINE DEVELOPER DAY 2016」に行ってきました。
LINEサービスを利用した開発者向けセッション、LINE開発の取り組み紹介などなど。

linedevday.linecorp.com

開催概要

  • 日時
    • 2016/09/29（木）10:40-18:30
  • 場所
  • 主催
    • LINE株式会社
  • 参加者数
    • 約1000人?
    • 中国系？、韓国系？、東南アジア？の方々が結構いた印象。海外拠点の開発メンバーを呼んでいるらしい。
  • hashtag
    • #linedevday
  • 資料

会場雰囲気

f:id:Namihira:20160929103200j:plain:w750

セッションメモ

Opening & Introduction

Keynote New world by the LINE BOT

  • LINEの新サービスの紹介
  • LINE notify
    • API Gatewayの位置づけでOauth認証してAPI（HTTP）を叩くと、ユーザのトークに投稿できる。
    • Your web service -> LINE Notify -> ユーザとのトーク
    • 紹介の例がcurlだった
    • 実施例としてIFTTT、GitHubからでもLINE通知できるようになった。
  • LINE Message API
    • LINE BOT用のAPI
    • いままでtrialだったものが正式リリースされた。機能も追加されている。
    • API 再実装、ドキュメントも書き直し
    • サンプルを充実化。curl、java、golang、Rudy
    • 公式のSDKも提供する。
    • ソースコードも公開
  • LINEのBotをつくって応募すると最大で1000万円もらえるコンテストがある。
  • 所感
    • まわりの聴講者が「おお！」といっていたので良いアップデートだと思われる(´・ω・`)←LINE連携のサービス作っていない。
    • 「こんなにも簡単に利用できます。＼単純なcurl例／」というのを強調していたので、API提供側はまずの参入障壁をできるだけ下げる必要があるらしい。
    • 最高賞金1000万円のコンテストすごい(*´Д｀*)何か出したい

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

  • LINEがダウンしたときの対応の話
  • メインのRedisのデータが無くなったこともある。バックアップのMySQLとWebアプリのログから復旧した。
  • サーバ現在数千台
  • 障害発生時は、デマ情報対応・拡散対応もしないといけない。
    • 「開発者がサーバに味噌汁をこぼしたから落ちた」とか言われるらしい。
  • 今回は2016年3月のサービスダウンの話
  • 負荷分散のため、ユーザへの更新通知（2000個以下）は、全ユーザで3時間以内で分散で通知するようにしている。
  • 原因は、全ユーザに2000個以上の変更通知がある状態になり、一気にアクセスがあり負荷がかかった。
    • この場合の変更通知に対するアクセスにはユーザ認証が必要で、認証サービスに負荷がかかった。
    • この場合の変更通知はなかなか無い（長らく使っていないユーザのみ）ので時間的に負荷分散していなかった。
    • LINE着せ替えのテストで追加していた変更が多かった。
  • Circuit Breakerの仕組みを作った
  • 音声通信機能を提供するサービスは、インシデントがあると国へ報告義務が発生する。
  • 質問「LINEのインシデント共有をLINEでやっているとき、LINE障害時は使えない？」
    • 回答「HipChat、社内インフラに別のメッセージングがある」
  • 所感
    • 他人のサービスの障害の話おもしろい(´Д｀)
    • 5分で原因が分かって30分で暫定対応でサービス復旧できたらしいので対応力がすごい(´Д｀)
    • Circuit Breakerの考え方が収穫。

LINE Login - LINE Platform

  • LINEのAPIサービスの「LINE Login」と「AutoLogin」の説明
  • LINEのアクティブユーザ2億人
  • LINE Login = Webサービスのログイン・会員登録の際にLINEのユーザ情報を利用でき、入力する必要がない。
  • AutoLogin
    • LINEアプリから他のサービスにログインする際にLINEのログイン情報入力が不要
  • 所感
    • つなぎやすさ、つながれやすさ大切。

Security x LINE Platform

  • LINEのセキュリティについて
  • トークのメッセージの暗号化について
    • 例：USER 1の秘密キーとUSER2の公開キーで暗号化して送信して、USER2はUSER2の秘密キーとUSER1の公開キーで復号化する。
    • グループトークの場合、全メンバーの公開鍵からグループ共通のキーを作って共有する。メンバーが増えると作り直す。
    • スパム検査とかは暗号化されて内容がわからないので、ユーザ報告とユーザ同意をとって内容を確認してスパム認定している。
  • リスクアセスメントについて
    • WebではなくLINE App/Gameへのセキュリティ対策。通信の暗号化や、チートツール対策（時間を速く進めてスタミナ回復など）など。
    • メモリ上の情報配置を解析されるらしい。
    • サーバサイドで判断するようにする。
    • プロキシなどで通信内容が見えてしまう。 ゲーム内でサーバの証明書で検証することで防ぐ（SSL Pinning、プロキシの証明書ではエラーになる）
    • スパム検知は7割が自動化されている、3割は報告されたら人力で確認している、
    • Bugの報告へ報奨金を出す制度がある。現在は週3件程度。XSSが多い。
  • 所感
    • 内容が難しくなんとなくだけ雰囲気はわかった(；´Д｀)

Group App Platform

  • 新しいLINEグループの機能とその開発の話
  • 要求・背景
    • グループが巨大なグループになりがち。トーク部屋が一つだけだと話しにくい
    • 過去のトークをみたい
  • 新機能
    • グループの管理者が作れる。参加を承認制にできる。
    • グループ内に複数のトークルームが作れる。
    • トークルームに対して自由にアプリを追加できる
  • APIにアクセスする際にいろいろアクセストークンを検討したが、一番分かりやすいトークン（channel トークン）を利用してもらうことにした
  • 所感
    • LINEグループの新機能の仕様の話が多かったので、開発よりの話も聞きたかった(；´Д｀)
    • 認証のためのトークンはどう定義し提供していくかを考えるのはどこのサービスも苦労していそう。

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

  • LINE LIVEの開発・仕組みの話
  • HLS(HTTP LIVE Streaming)
    • Appleが開発している動画配信技術
    • HTTPで転送できる
    • CDN（akamai使っている）で配信しやすい
  • ファイルはビットレートごとに別で保存されていて、クライアントの状況によって取得するファイルを変えている。
  • 配信者のアップロードが途中できれると、視聴者側クライアントからストレージへアクセスが増えてしまう。
    • クライアントにsuspend状態にするイベントが投げる。でクライアントは状態検知APIへのポーリングをし続ける。
    • 状態検知APIはアクセスが多くなるので、高トラフィックに特化している。
  • チャットログもJSON形式でファイル化して、ストレージにいれてCDN配信している。
  • LOVE(いいね)を連打する機能：人は連打できる場所があると連打する。連打は楽しい。
  • 所感
    • 仕組みだけ聞くとシンプルだけどもろもろ実現は大変そう。

LINE Shop powered by Armeria

  • LINE Shopで使われている通信ライブラリ「Armeria」の説明
  • LINEバックエンドは、Javaのアプリケーションサーバ上にThrift over HTTP（ThriftのトランスポートをHTTPで実装したもの）として実装されているらしい。
  • API呼び出しカウント/秒を可視化している。
  • バックエンドのリクエスト解析は、Zipkinを使っている。
  • HTTPコネクション接続数が600,000/分だったものが、HTTP/2を使うようになったら2000/分だった。Listen Dropが無くなった。
    • しかしコネクション維持時間が長くなるので、LBがコネクション単位での振り分けだと偏りができたりと分散がうまくいかないことがある。
    • Client-side Load Balancingなどを使う必要がある。
  • 所感
    • HTTP/2を使うだけでだいぶネットワーク負荷は改善しそう。
    • Client-side Load Balancingの考え方が収穫。
    • このセッションを初め他のセッションでも例が基本Javaコードなので、LINEはJavaコードが多そう。

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

  • 「Tech Focus」技術的な方針。
    • エンジニア文化はトップダウンで決めたのではなく、現場で根付いたものをまとめた。
  • リポジトリ数＠GHEがすごい
  • 単純なローカライズだけでなく、地域文化を理解したモノ作り（カルチャライズ）
  • 多言語なチームについて専門の通訳チームがいる。翻訳Botがいる。しかし会ってのコミュニケーションも大事。エンジニアはコードがあれば会話ができる。
  • 椅子は複数の候補から選べる。スタンディングデスクも使える。
  • オライリーの本は全部買って置いている。
  • 考え方
    • Take Ownership
      • 当事者意識をもって。しかしチームとしての成果を重視する。
    • Take Risks
      • リスクをとって挑戦する。
      • 新しい技術の利用は工数が読めないなどのリスク。しかし進むためにだから使う。
    • Be Open
      • できるだけ情報公開。全員でゴールするため。
      • 誰かにレビューされること。開いた気持ちで指摘を受け入れる。
  • 成長にはPositive Peer Pressure（良いプレッシャー）が必要。
  • 現実としてマネージャはコードまで見れていないと思うので、技術は同僚が評価したほうが正確（coworker評価）。マネージャは、サイクルが回っているか、プレッシャーがかかっているかを見る。
  • LINEはこれまで外部との交流がなかったので今後推進していく。OSSを利用しているのでそれへの貢献も。
    • 外部との交流を促進する部署を作った。
  • 所感
    • 内容・事例的には他社でもありそうだけど、執行役員がそれをメッセージとして言うところ・大切にしているところがすごい(´Д｀)

その他

LINE色がすごかった

  • 事前案内、受付、資料配布、事後アンケートなどがLINEアプリ上で実施された。
    • 開催場所・日時なども通知してほしかった(；´Д｀)行くとき結局Webページみた。
  • 会場などにビーコンが配置され、全部回るとオリジナルスタンプがもらえる。
  • 他のカンファレンスと違って、カンファレンスをアトラクション感覚で楽しめた(*´Д｀*)

お金のかけ方がすごかった

  • 受付で「お食事代」としてヒカリエのギフト券2000円分くれた(*´Д｀*)
    • 有効期限は2月までだったので使わずに、お昼は松屋にいった（小声）
  • 休憩場所がフリードリンクで、LINEキャラのブラウンをモチーフにしたどら焼きがたくさん置かれていた（twitter上で「無限どら焼き」と呼ばれていた）
    • 休憩場所が埋まっている割にスペースがあったのでもう少し椅子を増やして欲しい(；´Д｀)
  • アンケートに答えるとノベリティとして「耐熱タンブラー」「カップ・タブレット置き」「LINE beaconキット」をくれた。もはや引き出物(*´Д｀*)
  • LINE儲かっている（確信）

聴講環境がよい

  • 今回のイベントをブログなどで発信してくれる人を「プレス枠」として優先参加させていたのと、そのプレス枠だと会場の前方・机ありで聴けるのでよかった。ゆっくり聞けた。
  • 無線LANも用意されていたが、回線が混雑して（？）遅かったので自分のPocketWifi使った(´・ω・`)

まとめ

知識的・物理的にいろいろもらった(*´Д｀*)

  • 無限どら焼き
    f:id:Namihira:20160929162746j:plain:w750

  • 引き出物
    f:id:Namihira:20161002072454j:plain:h750