Help us understand the problem. What is going on with this article?

LINE Developer Conference(Day 2 - プラットフォーム)

More than 5 years have passed since last update.

2014/4/17(木)に開催された、LINE Developer Conference(Day 2 プラットフォーム)に参加してきました。

DSC_0068.JPG

スライド撮影がNGだった為、間に合う限りメモった内容(+後から懇親会で訊いた内容少し)をほぼそのまま載せます。
間違い、誤解、追加などありましたら是非お知らせ下さい。

総じてとても面白い内容でした。
登壇者の皆さん、運営の皆さん、どうも有難うございました!

  • LINEの2トップ
    • 朴イビンさん(上級執行役員CTO)
      • 100億メッセージ/day
        • グローバル
        • LINE拠点は日本、韓国、タイ、スペイン、台湾、USA
        • 開発拠点は日本、韓国、大連、北京、(今後)福岡
        • 専用線で以下DCを結んでいる
          • ドイツ、↑の拠点?
        • LINE遠征隊が各国に行っている
    • 池邉さん(上級執行役員サービス開発担当)
      • 競争相手
        • Facebook, WhatsUp, WeChat
      • 文化
        • リアルタイムに世界中から報告が挙がってくる
        • 数字を元に話す
      • カテゴリ
        • GAMEプラットフォーム
        • ファミリーアプリ
          • EC
          • 占い
          • モール
          • 漫画
          • クリエイターズマーケット
          • など、ゲームと本体以外
        • LINE本体
        • インフラ
  • session:1 Esper CEP on LINEGame → All about LINEGAME Pratform
    • 堀上ひろゆきさん(@horiga
    • about LINEGAME
      • 全50タイトル以上(但し引っ張ってるのは3,4タイトル)
      • LINE POP 40M+
      • 4M+ツムツム(2week,japanメイン)
      • クッキーラン10M+(1ヶ月、global 70%
      • 開発元
        • 日本、韓国、中国、ロシア、フィンランド
        • LINE
    • about LINEGAME Platform
      • ミッション
        • 3rd partまたは内政のゲームを提供できるため
        • 安定、安心
        • 開発者にとってつなげやすい
      • SDK(プラグイン形式。Unity, cocos)
        • Logging, notice, present, ranking, web view, push, iap/iab,auto/login,security
      • Server/backend
        • 去年まではGame毎にクライアント - 専用サーバ - LINEプラットフォーム
        • 予測がつかない規模の場合がある
        • 今年は、ゲーム毎に クライアント - 専用さーば - 専用プラットフォーム(必要な機能をつけたり外したり)
        • Tomcat, spring, rabbitmq, apache, nginx, hadoop, akka, etc...
    • about LINEGAME Monitoring
      • サーバのモニタリング(CPU等)
      • アプリケーションログ、クラッシュログ
      • ログレベル別、サービス別、
        • 単位時間の件数によるアラート通知
      • CS, abusing
        • お問い合わせ
        • 不正行為
        • スコア改竄
        • アプリ内データ改竄
    • about ESPER
      • http://esper.codehaus.org/
      • 各ゲームから2分に1回heartbeatを送ってこれで処理
      • 前はHadoopに入れてHIveとかやっていたが処理速度的に間に合わなくなった
      • 各ゲームの本体のリクエストは各ゲーム会社(SAP)のサーバに飛び、このリクエストはSDKが勝手にLINEに送る
        • 後から聞いたら、各SAPのコードや環境に手を入れたりサーバ間通信を要望するとバリエーションが多過ぎて大変だったりそこに引っ張られるのが怖いので別途に送る方式にしている
      • イベントをSQLっぽい言語(EPL)でリアルタイムに色々できる
      • 端末から送られてくるイベントがインプット
      • アウトプットはDB、メッセージなど
      • Events
        • POJO
        • Map
        • OBject array
        • XML
      • EPL
      • RTA(real time access)
      • sendEvent→イベントを登録→一定の条件でクエリ投げる→条件に合致したらwarning
      • http://github.com/horiga/esper-realtimeaccess-mon-exmaple
      • 今後の課題と応用
        • 複数ゲーム間のクロスプロモーション
        • スコア改竄などのリアルタイム監視
        • Esper Nodeの分散
    • #YOLO / You Only Live Once!
    • 今年リリースした新しいPFから適用している。現状1万req/secくらい(後で聞いたら処理内容にもちろんよるが1台で理論上50万reqくらいまでさばける模様)
    • 6月くらいに「LINEゲーム作ろうぜ」イベントを開催予定(企画中)
  • session:2 LINE Platform(Channel Gateway)
    • 田中洋一郎さん
    • Game Platform固有の機能ではなく、マンガやモール含めた共通の汎用Platfor
    • → 「Channel Gateway」。LINEと連係するアプリの総称がChannelなので
    • Authentication
      • 画面の流れ
        • LINE Loginボタン押す
        • ログイン画面に飛ぶ
        • LINEでメアド、パスワードを登録しておく
        • それを入れると完了
        • サイトに戻る
      • oAuth2にほぼ準拠
        • up to up認証(LINEアプリを起動してアプリ認証+認可を行う方式)
        • どのアプリから来たのかのクライアント確認はしっかりやっている
        • ユーザ識別子+Access tokenがアプリに返る(厳密には幾つかやり取りがある)
        • このATを使ってChannel Gateway APIを利用
    • API
      • Profile
      • Friend list
      • Send message
      • Post Timeline
    • SDK
      • Server / SDKからhttpsでRESTfu APIを叩く
      • 実際はSDKを提供(High-level API)
    • 規模感
      • 160,000,000
        • friend list API call数/day
        • 実際はゲームサーバでのキャッシュ等もあるので全リクエストがここに来る訳ではない
    • …何かが足りない
      • メッセージを扱える事でLINEらしさが出るのではないか
      • →LINE BusinessConnect
      • ユーザはアプリからメッセージやスタンプを送るとお店に連絡が行って届く
        • 例:いっぷく!、東京ライブ24(終了)
      • 予め登録した企業のサーバにLINE経由でメッセージが送信される
      • メッセージ送信→Calculate signature(LINE Server)→企業側サーバValidate Signature)→order処理→ユーザにメッセージ返す
    • LINE Developersというサイトを準備中
      • ドキュメント
      • SDK
      • 共通鍵の発行
      • etc.
    • LINEの裏側
      • SPDY(一部仕様を変えて実装している)
        • クライアントはLINEアプリのみのはず(= NPNというクライアント不明の場合の手順を省いてやり取り回数を削減)
        • 通信遅い国の対応
        • 最初つながる時遅いけどその後は速い、という場所もある(=warm upが必要)
        • →NOOP(No Operation) Frameを送るだけ(レスポンスもしない)にして最小限の時間で通信開始
      • LEGY : Line Event GatewaY : erlangで実装
        • LEGY Server Push
        • LEGY Encryption
        • 予め証明書類をインストールして最初のネゴシエーションを省くなど
      • メッセージのストレージが必要
        • 最初 Redis + MySQL
        • → Redis cluster + MySQL
        • → Redisはオンメモリなのでコストが高い → ソリューション候補:HBase, Cassandra, MongoDBなど
        • → HBaseを選択
        • → HBase HA + Storm + MySQL + MongoDBを使うサービスも一部ある
        • → 各HBaseの手前に各Redis cache
      • LINE Clients - LINE Connection layer(LEGY by Erlang) - Authentication - LINE Application layer(Core messaging, Functional application, Redis queue,RabbitMQ,ZeroMQ) - async task manager
        • Redis 色んな用途で全部で30TB
        • HBase(メインストレージ) 1PB
      • hadoopでのLog analyze,statistics
        • 7PB : 42%利用
      • 謎画像:LINEプラットフォーム内で20種類程度のサーバが稼働している(サーバ間通信が多い)
  • FireSideChat(チャットの質問をネタにざっくばらんに話す会)
    • 3年間で一番思い出したくない思い出は?
      • サーバ「12月事件」
        • 2011年12月
        • Redis cluster導入直後
        • Redisのノードが突然消えた。同時にスレーブも消えた。→データが消えた。バックアップもあまり無い
        • →ログのテキストファイルだけある
        • →ログをparseして入れ直す作業を20時間くらいやった
        • 他にも「香港事件」などあり
      • Androidクライアント
        • 一定の機能数を超えたところでクラス/メソッドの数が多すぎてインストールできなくなった
        • →毎回リファクタリング、バイナリ分割(インストール後ダウンロード)など行っている
      • iOSクライアント
        • 立ち上げ時のデータ取りに行く処理のタイマーをミスって毎回取りにいくようになってしまった
        • ぎりぎりサーバ側(インフラ)で凌いだ
      • iOSクライアント
        • たまに変な文字列が開発される
        • safari含めて落ちる文字列
        • lineだけ影響受ける文字列
          • 一時的にサーバで文字列置換して凌いだ
      • 対応言語が増えているので大変
        • 現在17ヶ国語くらい
        • AndroidはOS提供のAPIでラベル切り替えるだけ
        • iOSは、かなり低レベルから実装しているのでかなり大変(アラビア語とか)
        • 複数形のサポートなどOSSでやってる
        • 社内で多言語管理ツールを作っている
        • 中身はKey-Valueで同じKeyに対して各言語のValueを表示
    • UITチーム(Webチーム?)は何をしているのか?
      • ストアサイトなどのWebページ、Creators market, Developer向けサイトなど
      • CMS作成
      • AndroidのフリーコインアプリはWebで実装していたり
      • 地域情報もWeb実装していたり
    • 仕事以外での技術のキャッチアップはどうしているか?
      • イベント参加、公開ビデオ見たり、問題に当たった人から共有してもらったり
      • サーバは世間でもてはやされているものはLINEだと使えない感じが多い→同僚とのディスカッションが一番かなと思っている。かなりやっている。
    • これからチャレンジしたい事は?
      • サーバはbacklogが何千件もあるような状態だが…
      • IDC単位でのスケールアウトしたい(今は人手が足りない)
      • AndroidはiOSより重いとよく言われるので、なるべく速くしていきたい。これまで機能追加メインだったがそろそろ
      • iOSはメジャーバージョンアップに完全に追随できていないので、今年こそは
      • フロント(Web)は日々新しいものが出てきているので、ユーザに良い体験を与えるようなものは取り入れていきたい
    • 今はスマートフォン全盛だが、これからウェアラブルとかくると思うがその辺の対応は?
      • 昨年サムソンの腕時計に対応してみた(しかし話題にならなかった)

以上です。

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away