umegusa's blog

備忘録

LINE DEVELOPER DAY_2015 Tokyoに参加してきました!

タイトル通りです。
今回はこれに参加してきました。linedevday.linecorp.com
会場エアコンガンガン聞いててめっちゃ寒かったみたいですね(ちょうどいい温度とは言えず

参加したセッションは2つのホールに分かれていたのと、電源がない関係で一部は参加していません。
自分が参加したのは以下のセッションです(午後のみリストアップ

  • LINEのiOS対応、新しい技術チャレンジ 〜LINE の Apple Watch アプリ開発とSwift導入による開発チームの変化〜
  • グローバルなネットワーク環境と複数OSに対応するための LINE Game Client Platform 開発戦略
  • ビッグデータを活用するための分析プラットフォーム 〜データ集計した先に求められる分析技術〜
  • ベイズ推定とDeep Learningを使用したレコメンドエンジン開発

めっちゃ長いので詳細のほうは続きを読むから見てください。
ちなみにスライド、発表内容に関しては後ほどWebに公開するとのことでした。


続きです。
オープニングセッションから内容を一部抜粋したものをまとめていきます。
あまり長く書きすぎてもあれなので要点のみ。
一応詳細とは言わないですが、当時の流れを辿ったToggeterをすべてのセッションごとに貼り付けていくので
興味のある方はそちらも辿ってみてください。
午前の部のスライドは公開すると公言なかったので一部のみ載せていきます。

LINE Global Culture

リアルタイムTweetはこちら。
出澤新社長登壇!1日のメッセージ数は17億通!LINEを支える技術とは? LINE DEVELOPER DAY_2015 Tokyo #linedevday #会場寒い #寒くなくなった - Togetterまとめ


f:id:umegusa:20150428104800j:plain
LINEで使われてる技術のスライドです。
開発は世界各地で行われており、日本では東京・福岡で開発しているとのことです。
開発者も立案でき、リモートで基本的には開発しているみたいです。


仕事に関しては自分に最後まで責任を持たせるself-directiong workをモットーとしているみたいで、
コードレビューを大事にしているとのことでした。
仕事のサイクルは
企画が立案 -> 開発着手 -> コードレビュー -> 上司によるコードレビュー -> エンジニアが評価する
というサイクルを回しており、エンジニアの評価も上司に圧をかけられるのではなく一緒に仕事をしたエンジニアが評価をしていて、
それが信頼につながるCo-Working Reviewな体制を取っています。
コードレビューも大事にしており、それがTrust and Respect(信用と信頼)につながる、とのお話でした。

LINE Messenger for the World

Togetterは上記のリンクと同じ場所です。
このセッションはLINEのグローバル化、LINEの世界展開についてなどのお話でした。

まず開発の状況からなのですが、アプリのバイナリは一つ、サーバも1台で運用しているというお話がありました。
世界展開については、現地に直接赴く遠征隊というものがあるらしく、
4日間くらい滞在して(エンジニア、総務などが複合)現地デバッグを行うというお話でした。

実際にその国に行き、プリペイドSIMを使って通信状況の確認やテストを行っているそうです。
また、移動中もスコープに入れており、飛行機内で提供されているWiFiのテストや、
劣悪な環境下での実行テストなどを行っているそうです。

改善のサイクルとして、
問題整理 -> どうやって解決するか(現地に行って調査) -> 開発(滞在中に) -> レビュー -> デプロイ
というサイクルで回しているそうです。
コードレビューのお話は様々な所でされており、かなり重視されていることが印象深かったです。

直接現地でテストすることで、日本では気付けない開発のネックなところを攻めることができます。
電波状況やその国の端末の特徴などは現地に行って実際に触ってみないことにはわからない、
そこまで徹底してきたので、今の世界的に使われている現状があるとのことです。
(もちろんそれだけではないですが・・)

通話についてのお話もありました。
開発言語は基本的にはJava、フロントはErlangで開発されています。
Erlang導入の経緯はこの後のセッションで解説されていました。

また、クライアントアナリティクスシステムを独自に開発しており、
Play Storeの解析システム(トレンドやよろしくない評価などのキーワードを羅列するなど)を独自実装したり、
開発者視点に関する解析システム(画像の送信に成功したか、どの頻度で送られているか、など)も用意して、
急激に特定のキーワードが増えてくると分かるようになっているそうです。

これらの体制により、高クオリティなアプリが提供できるているんですね!

LINE Platform Development Chronicle

プラットフォームの概要に関するお話。
Togetterは下記になります。
メッセージング基盤の進化 Erlang、SPDYからそれを支える組織の話 LINE Platform Development Chronicle #linedevday - Togetterまとめ

こちらのセッションでは下記の2つについてのお話です。

  • LINEメッセージング基盤の進化
  • LINE流マイクロサービス
LINEメッセージング基盤の進化

LINE開発の歴史と、そこであった障害・問題に対してどう対策してきたかというお話です。
初期のアーキテクチャは写真のような感じだったそうです。
f:id:umegusa:20150428184921p:plain

最初のメッセージのやり取りはPollingとアプリのpush通知を取得したら取りに行く、という方式だったそうです。
Pollingで2秒ごとにアクセスしてメッセージがあれば取得、アプリのpush通知が来たら取得、という設計で作成していました。
このPolling + アプリのpush通知では、下記の問題があったそうです。

  • push通知によるメッセージ受信の遅延
  • 無駄なResponse-Requestの嵐

それをLong Pollingを使用して解決したそうです。
Long Pollingはサーバとクライアントの中間にGatewayを挟み、サーバからメッセージを受信したらGateway経由でアプリに通知します。
Gateway層がアーキテクチャに追加され、これはNginxで実装され、アーキテクチャに変更が走りました。
f:id:umegusa:20150428190758p:plain

Gateway層の導入により新たな問題が発生しました。
Segmentation Faultの嵐です。
Clientの接続をNginxのあるプロセスが持っているとは限らない、という問題があり、この問題が発生しました。

この問題はErlangを使用することでNginxを子プロセス化し、解消することができました。
Erlangはもともと通信会社が作成した言語ということで、メッセンジャーアプリとの親和性も高く、
さらに並行性・分散・無停止デプロイ(VMを再起動しなくても作成できる)・高級言語による開発
ということも実現できました。

Nginx の拡張モジュール(shared memory)からErlangへ移行し、LINE Event Delivery Gateway(LEGY)というものを実装しました。
LEGYはErlang製のもので、メッセージのみではなく既読通知などのやりとりもしているとのことでした。
f:id:umegusa:20150429004128p:plain

LEGYを実装後に起きた問題はConnection地獄でした。
Long Pollingを実装したことなどが問題で、Connection数があふれていたそうです。
クライアントがアクセスしたNginxのプロセスがConnectionを持っていない場合、再度貼り直す処理が走っていたために
このConnection地獄が発生したそうです。

この問題を解決するために、当時はあまり普及していなかったSPDYプロトコルが採用されました。
SPDYは、複数TCPコネクションを1つにまとめて高速化するという特徴を持っており、
この問題を解決するのにうってつけの技術だったわけです。
2012年7月というSPDYが割と出始めの時期ではありましたが、Connection地獄脱却のためにHTTP(S)からSPDYに乗り換えたそうです。
また、キャリアとの協力などでConnectionを減らすことで、回線が悪いユーザーも多いので
地道な改善が大事だ、というお話を伺えました。
f:id:umegusa:20150429004650p:plain

最後はパフォーマンス改善についてです。
ここまでくるとパフォーマンスを追求する、ということで、世界各国どの場所からも同じレスポンスでアプリを動作させたいというお話がありました。
パフォーマンス改善には、データセンターからの物理的な距離の問題で、今もレイテンシが発生しているとのことです。
そこで、Global POPという名の世界各国のデータセンターを介す事で高速化を図る施策をしています。
今後もデータセンターをどんどん増やしていき、使用した国のデータセンターからデータを取得する
当たり前の構成にしていきたい、というお話を伺いました。
もう一つは非同期通信化を行うことで、より高速なパフォーマンスを出したい、というお話が伺えました。

基本的なアーキテクチャは冒頭からあまり変えず、シンプルな構成で、
MySQLからHBaseに変わったくらい、というお話で閉まりました。
f:id:umegusa:20150429005145p:plain

LINE流マイクロサービス

LINEはCoreプログラム(Talk Server)に紐づく形で、APIで連携しており、
スタンプや動画、通話やメッセージなどは独立したサービスとして開発しているようです。
APIを提供することで、モジュール自体を疎結合として扱い、拡張性に富んだアプリ開発が行われています。
この個々のサービス(スタンプ・動画・通話・ゲームなど)をマイクロサービス(Micro Services)というふうに読んでいます
MonolithicをMicro serviceに置き換えることで、新しい人が入ってもすぐ開発できるようにしたとのことでした。

TalkServerはメッセージングとテキスト送信のみを提供しているLINEのCoreシステムです。
他のマイクロサービスをAPI連携によってTlk Serverに連結させることで、今のLINEが形成されています。
マイクロサービスを開発している技術は様々で、LINE自体は主にJavaを使用して開発されていますが、
セッションでは公式アカウント周りはScala、他のサービスについてはMongoDBやApache Cassandraを使用しているなど伺えました。
エンジニアが環境を選び、開発しやすい環境で開発できる、そんな印象を受けました。

マイクロサービスには一つ一つにチームが設定され、デプロイまで行った後、解散という
短期間でのiterationを回し、目的を達成したら縮小/解散という流れで開発を進めているそうです。
これがマイクロサービスを支える組織形態であり、独立性の高い裁量を持ったチームが複数作られるような開発形態になります。

APIプロトコルについてはApache Thrift, Protobuf, RESTが採用されています。
githubでpull requestベースのディスカッションをしながらサービスのインターフェースのみを確立してプロトコルを管理しています。
開発者はインターフェースのみのレビューになるため、技術についての自由度が高い開発形態が実現できていると感じました。
リリース後のモニタリングは内製の IMON というツールを使っているそうです。

マイクロサービスの今後の課題としては、巨大化しているため、管理できていない現状にあるそうです。
サービスの管理方法と障害が発生した時の管理体制を整えていくことが、今後の課題と伺いました。

LINEのiOS対応、新しい技術チャレンジ 〜LINE の Apple Watch アプリ開発とSwift導入による開発チームの変化〜

午後セッションです。
こちらはスライドを公開する、という公言があったため、この先はスライドは載せません。
また、この先はセッションの動画もあるということで軽く流す程度でまとめていきます。
このセッションに関するTogetterはこちら。
【すいすい開発】LINEにおけるAppleWatch対応&Swift導入への挑戦(B-1 & B-2) #linedevday - Togetterまとめ

Apple Watch

Apple WatchのLINEアプリ開発についてです。
アプリ開発でハマったこと、WatchKitで開発するためのTipsなどについてのセッションでした。

印象的だったのは通知のカスタマイズを行う場合、iPhone側と連動してしまうこと、
画像リソースの捌き方などについてでした。
iPhoneとは違い、スペックの低いApple WatchではiPhoneのようにリソースを扱うことができません。
(できないわけではないがとてももっさりする)
従って、Apple Watchのストレージに読み込ませておく、Cacheを活用して高速化を図るなど、
様々な工夫が必要になるようです。
また、通知を行う場合はiPhone側との挙動に合わせた実装が必要になるそうです。

まだWatchKitは出たばかりで改善の余地が多く、現在は
openParentApplicationというAPIに頼りっきりの開発になっているというお話でした。
UI設計もコードで実装はできず、Storyboardのみでの設計になるそうです。

また、このセッションではメッセージをリアルタイムで取得する際に苦労した話やそのシステム的解決のお話などがありました。
Apple Watchのアプリではメッセージの差分のみを取得し、レスポンス処理が終了してからDBに送信する、
ということで他の媒体のアプリと弊害なく挙動の解決を行っていたそうです。

今後の課題としてはopenParentApplicationに頼りっきりなので、
extensionのみで開発できるようにしていきたい、とのことでした。

Swiftによる開発チームの変化

Obj-CからSwiftへ移行したことによる変化についてです。
Obj-Cでの開発に比べ、以下の4つのような改善があったというお話でした。

  • 分担しやすくなった
  • デバッグしやすくなった
  • コードレビューが簡単になった
  • 安全なコードが書かれやすくなった

Obj-Cでは実行時エラーのハンドリングが難しく、Swiftに移行することでそれが改善できたそうです。
実際のサンプルコードも一緒に公開されていたのですが、そちらについては後ほど公開される資料を参照ください。

Obj-Cではnilをすべてが参照できるために、どこにnilが入るかわからないという問題が例としてあげられました。
実際には Controller -> Model -> ViewModel まで処理が走り、ViewModelでnilが入った値を検知してしまった場合、
すべてのプログラムを参照する必要があり、それがデバッグコストとして重いという事案がありました。
ここで質が悪いのは、Obj-Cのインターフェースでnilがどこに入るかわからないということ、
コンパイルは通るので、実行時にエラーを検知する、ということです。
Obj-Cでは規約で縛るなどの制約をつけることでしか解決できませんでした。

一方、Swiftnilを基本的に許容しない型で、nilを許容する場合はoptional型として宣言する必要がある、という縛りが設けられました。
これにより設計段階でのレビューがしやすい、また、nilを許容したくない場所で許容しない型の宣言ができるということで
安全なコードを生成できるようになりました。
さらに、バグの範囲が絞られるのでデバッグがしやすくなり、それに伴い開発の分業化もしやすくなったそうです。

結果的に良い方向に向かっているということで、今後もSwift化を進めていく方針で行くそうです。

グローバルなネットワーク環境と複数OSに対応するための LINE Game Client Platform 開発戦略

LINE Game Platformのお話。
Togetterはこちら。
【ネットワーク・複数OS】LINE Game Client Platformのグローバルにヒットする開発戦略 #linedevday - Togetterまとめ

最終目標としては、Networkモジュールの独自ライブラリ化、独自Game Platformの開発を目指していくとのお話でした。

LINE Gameは現在45個公開されており、その中でもかなりのダウンロード数を誇るゲームがたくさんあるそうです。
(ツムツムとかLINE POPとか)

LINE Game Developersのミッションとして、最初から念頭に置いているのはグローバルに楽しめるゲーム開発と
開発者達が組み込みやすいPlatformの提供がミッションだというお話でした。
最初からグローバル化を視野に入れた開発が走るというところは、LINEだからこそかなという印象を受けました。

ゲームはUnityを使用しており、iOS/Androidのネイティブプラグインを提供してコンポーネントを自由に選択できるようにしているそうです。
課題としては、一貫性を保つのが難しいとのことでした。
また、複数ライブラリを提供しているために、バージョン管理が難しいというお話が伺えました。

現在はゲームエンジンの戦国時代(Unity5, UE4など)と呼ばれ、とても熱い分野だ、というお話も伺えました。
これらのゲームエンジンは他言語のサポートをしておりますので、Obj-CやJavaのわからないエンジニアでも開発ができるというお話です。
LINE Game側はPhase3に入っており、ネイティブとつながるところをC++で開発し、ネットワークモジュールを作成することで
処理を共通化していきたい、というお話を伺いました。
それらをプラットフォームとして提供し、OSのやりとりの差異を吸収していきたいとのことでした。

現在はAPIを各プラットフォームごとにBundlingしてアプリを呼び出しており、
SWIGという内部ツールを使用してC++のコードを自動生成し、Bundingモジュールをビルドしてアプリを動かしているそうです。

グローバル化についてのお話もありました。
グローバル化に基づき様々な施策を取っています。
一つはリクエスト数を減らすために複数のリクエストを一つにまとめて投げるAPIを導入することで高速化を図っています。
また、ネットワークが遅い場合はcache情報を返し、後でサーバーとデータを同期しておくことで高速化を図るそうです。
さらに、各国のデータセンターを活用することでGlobalPOPを構成し、サーバーとクライアントのレイテンシを少なくしていくほか、
LINE Game Platform向けのネットワークモジュールを展開することで動作を確立させていきたいとのことでした。

ゲームの弊害のお話も伺えました。
通貨の違いで桁あふれが発生し、オーバーフローを起こして決済処理に失敗した前例のお話も伺えました。
これもグローバルに展開しているLINEだからこそ起きた障害なのではないかなと思います。

ビッグデータを活用するための分析プラットフォーム 〜データ集計した先に求められる分析技術〜

ビックデータ活用についてです。
このセッションが一番人多かったんじゃないかなと個人的には思いました。
Togetterはこちら。
#linedevday ビッグデータを活用するための分析プラットフォーム~データ集計した先に求められる分析技術~ - Togetterまとめ

このセッションではデータ分析についてのお話、分析プラットフォーム構成やグローバル化で見えてきた課題についてのお話でした。
データ分析はHadoopをベースに基本に忠実なデータ分析をしており、OSSのライブラリを積極的に導入しているそうです。
理由としては会社の方針に合わない実装や足りないところは独自実装をして拡張し、使えるところは使う、というスタンスのもと開発しています。

ここでは、エンジニアとプランナーでデータに対するニーズは異なることがメインで話が進んでいました。
エンジニア的にはデータが取れればなんでもいいけど生データが欲しい、
プランナー的にはKPIの指標の確認や綺麗なグラフとして出力されたものが見たい、Excelでダウンロードしたいなどの違いがあります。

エンジニアのための収集はSQLなどのクエリが柔軟に発行でき、APIによるバッチ連携ができるような設計で
分析できるプラットフォームを確立しています。
技術的には柔軟ななログ収集を可能にするフレームワークFluentdを使用したり、
リアルタイム集計処理システムやストリーミングデータ処理としてSQLを採用するためにNorikraを使用したり、
WebベースのクエリツールAPI連携を行うためのShib/ShibUIを使用して実現しています。

一方、プランナーのために用意したものは、SQLが出来なくてもなんとかする、という考えのもとに作られました。
HadoopとHiveを使用したデータ処理やデータ集計、Prestoを使用した分散データ処理エンジンを使用し、実現しています。
PrestoはBIツールのバックエンドとして使用し、BIとPrestoを接続するためのコネクタであるPrestogresを使用しています。
DWH(データウェアハウス)には多くのBIツールクライアントが使用できるInfiniDBを採用しているそうです。
BIツールIBM製のWebベースのレポートオーサリングソフトを使用し、認証やDB接続(Presto, InfiniDB)は独自実装しています。

プランナー側に提供するデータに関しては認証をしっかりと行い、ユーザ情報を見せず、トラッキングもしていないということで
エンジニアとプランナーで観れるデータをしっかりと管理している状態だと思いました。

また、グローバル化に基づき、KPIが増加している都いうお話がありました。
KPIが増加することでKPIが増加すると忙しくなって見なくなる都いうお話があり、
それに対して、KPIが変わったら見に行けばいいという発想でKPIモニタリングシステムを開発しているというお話がありました。
この発想の転換により、

  • すべてのKPIのトレンド分析を自動化
  • 時系列のトレンドを学習、予測値を算出
  • 異常値を検出してアラート -> メール、チャットなどで通知

という体制になるというお話です。

今後もKPIモニタリングを強化し、増え続けるKPIを自動的に処理する隊形を築いていきたいとのことでした。

ベイズ推定とDeep Learningを使用したレコメンドエンジン開発

最後です、レコメンドエンジンのお話。
Togetterはこちら。
【白い人】LINEスタンプにおけるレコメンドエンジン開発を支えるベイズ推定とDeep Learning【このクマ】#linedevday - Togetterまとめ

登壇者はもともとニューラルネットワークによる機械学習をメインにしたサービス開発を行っていたそうです。
このレコメンドの対象はスタンプ販売に関するレコメンドのお話でした。
対象のレコメンドは二つあり、一つはアイテム単位、もう一つはユーザー単位に対するレコメンドです。

アイテム単位のレコメンド

こちらはユーザーが購入しているスタンプ単位のレコメンドになります。
開発の動機としては、クリエイターズスタンプ導入によるスタンプ数の急激な増加によるものだそうで、
欲しいスタンプが見つけられない問題をなんとかしたいということで開発が始まりました。

前提条件として、以下のものが挙げられます。

  • ユーザ数 1億8,100万人 MAU
  • スタンプ 9万以上
  • 約200の地域で販売(世界全体)
  • 公式スタンプとクリエイターズスタンプの存在
  • メタデータの不在

メタデータがあれば、ネコのスタンプを買った人にはネコのスタンプを進めればいいがそのようなものは存在しないというお話でした。

この前提条件のもとに考案されたアルゴリズムは、購入したスタンプと所持しているスタンプの使用頻度の数値を元に、
ベイズ推定による計算式を活用した行列計算を行うアルゴリズムを使用したそうです。
行列の掛け算を行う為、1億8,100 * 9万の行列計算が走るわけですが、スパース行列を使うとそもそも計算する必要がないので、
それらを除けば計算コストをリーズナブルに抑えることができ、実装が可能になるそうです。
様々な要因を元にスコアを集計し、そのスコアが高ければ高いほど推奨度が高いものとして挙げられます。

問題として売れ筋のスタンプや公式スタンプのみが表示されることがあるそうですが、
ε(重み)を加えることで、クリエイターズスタンプのレコメンドも可能になったそうです。

計算後、地域ごとのトレンドを考慮した重み付けの計算を行い、最終的にユーザーに提供するそうです。

ユーザー単位のレコメンド

もう一つはスタンプを使用するユーザーに着目したレコメンド方法です。
ユーザーがスタンプを使用する仮定として下記の二つが挙げられました。

  • 好ましいスタンプを良く使う
  • 最近購入したスタンプをより好む

一つ目のルールのみだと昔に購入したスタンプの影響が残るので、バランスをとるために2つ目の仮定を考慮して
レコメンドしたスタンプを提供するとのお話でした。

計算しきはユーザーがどのくらいスタンプを購入したかを係数として扱い、計算するそうです。
計算式はほとんど前のものと変わらないそうです。
しかし、すべてのアイテムとすべてのユーザーのスコアを計算するのは大きすぎるため、うまく枝狩りする必要がありました。
結果、二重帰納法を使用した計算が採用され、結果的に計算コストもかなり抑えることができ、
レコメンドエンジンの実装をすることができました。

これらの実績として、

  • レコメンドエンジンリリース後、ランキング1,000位以降の販売数が大きく上昇
  • レコメンド枠にランキング上位スタンプを表示した場合と比べ、アイテムレコメンドを表示した場合のCTRは(Click Through Rate: クリック率)約9倍

という実績が生まれたそうです。

今後の課題としては、コールドスタート問題が挙げられました。
新しいユーザーやアイテムが追加された時にレコメンドするアイテムを見つけるのが難しいという問題です。
コールドスタート問題に対しての解決策は、画像の類似性によるレコメンデーションを採用しました。
画像認識は40枚の画像セットから特徴量を抽出してNW(ニューラルネットワーク)で学習させてレコメンドするアルゴリズムです。
似た絵のスタンプが好きだろうという仮定から推測し、スタンプに購買履歴がない場合に適応するそうです。

終わりに

この内容ですべてではない、というだけでも驚きですが、とても濃い時間を過ごすことができました。
常にグローバル化や作業効率化のためのプラットフォームの確立、サービス向上のためのディスカッションなどが
頻繁に行われており、エンジニアだけでなく会社一丸となってサービスを作成しているという印象がありました。

グローバル展開を積極的に行っているからこその話や、小さな泥臭い事でも改善のために動く姿勢というのは
こちらも見習っていくべきことだと思います。

他のセッションに関する内容もとても濃密なお話だと思いますので、皆さん他の記事にも目を通してもらえると
LINEの技術についてかなり触れられるのではないかなと思います。
このようなイベントがあったらまた参加したいですね!

公開資料については見つけたら補足として書きます、が、もし先に見つけたよ!
という内容も随時お待ちしております。。。