テレビ会議システム凄い。 ワイドディスプレイ3枚で、実際に対面しているようになってる。
-
Esper CEP on LINEGame
-
Horigami Hiroyuki
-
LINE POP 4000万
-
LINE Cookie Run 1000万（1ヶ月、70％海外）
-
LINE Disney ツムツム 400万（数週間）
-
ゲーム全体で3億DL
- Developerが便利に開発できるように様々なSDKを用意している
- LINE Login, Logging, 不正アプリ検知, Root取得検知, etc...
- GAME毎のPlatformを用意してスケールアウトの問題を改善
- System: Munin?
- Application: ログ収集, API応答時間チェック
- Service: スコア改ざんチェック, データ改ざんチェック
-
イベントをリアルタイムに監視できる何からしい
-
イベントを溜めてSQLっぽい言語でフィルターしてリアルタイムに表示する
-
GoogleAnalyticsのEventトラッキングのすごい版？
-
Hadoopにつっこんでごにゅごにょする方法だと検知が遅いということでEsper入れた経緯がある
-
6月にLINE GAMEをつくろうぜイベントを開催予定
- 666名の社員
- 40%がエンジニア
- GameもFamilyAPPも共通のベースPlatformを使う
- Channel Gateway
-
Authentication
-
API
-
160,000,000
-
ある1日のFriendListAPIのアクセス数
- LINEの中でピザの注文、返却期限の通知、タクシーの呼び出しができるようになる
-
SPDYをベースにしたprotocolで設計
-
USER Agentが全てLINEなので、protocolの解決を省略して速度アップを図ってる
-
速度に対する最適化が半端ない
-
Line Event Gateway(LEGY)をERLANGで構築
-
LINE Engineer's Blog
-
100億/日を捌かなければいけない
-
開発当時はRedisメインとMySQL少し
-
Redis clusterを入れてRedisを増やせるようにした、でも横に増やし続けるにはお金が苦しい（Redisはインメモリ）
-
永続化をキチンとやった上で速度を担保する必要がある
-
RedisをHbaseに置き換え→横展開
-
データからの価値を迅速に見つけるためにStorm
-
LINEストアなどのためにMongoDB
-
現在はRedisをキャッシュ目的にHBaseの前に使ってる
-
キューを多様
-
Redis: 30TB (Cache, Message queue, Task queue, etc...)
-
HBase: 1PB (Service main strage)
-
Hadoop: 7pb 42% (Log analyzes, stastics)
-
色々な仕事をサーバーを分散して行っている
-
サーバー間での障害が一番多いのでメッセージをロストしないようにしたりといった工夫を行っている(Message queueなど)
俺の3年どこいったってくらいの3年だった。時間に余裕なかった。 「12月事件」。2011年12月Redisクラスタを導入直後の話。クラスタが1個完全になくなってスレーブもなくなった。 ログだけがかろうじて残っていたので、ログから実データをリストアした。
クラス数、メソッド数の制限に達してしまった。 機能追加する度にリファクタリングしたり、バイナリを分けたりした。
アップデートしたときに初回だけアップデートデータをダウンロードするけど、タイマーをミスって起動する度にデータをダウンロードするようになってしまって、DDoS攻撃をユーザーがするみたいになった。サーバーパンクギリギリになった。
Stringsで対応してるだけ。
ラベルの管理はXLPと呼ばれている多言語管理ツールを作って運用している。