LINE DEVELOPER_DAY 2015の参加レポート@基調講演 #linedevday

4/28に開催されたLINEのエンジニアチームの様々な経験を、未解決の課題も含めて共有する技術カンファレンス、
LINE DEVELOPER DAY_2015 Tokyo
に参加してきたのでその時のまとめ。

基調講演回です。

他のセッションは以下からどうぞ

Opening

出澤 剛様

• 2011/10/4にスタンプと無料通話を搭載したらブレークスルーした
• 現在、MAU：1億8千万人で、1日に170億のメッセージがやりとりされている
• 各国のユーザー数

• キーワードはローカライズで、各国でトップシェアをとるべく頑張っている
• Platform化も重要視している
• LINE TAXIを使ってLINE Payではらったりなどライフ領域に関しても新しい価値観を提供しようとしている
• ラインファミリーのアプリは76アプリ出ていて、約9億DLされている

LINE Global Culture

朴 イビン様

• 8カ国にフランチがあり、開発組織は東京福岡など、他にもいろいろある
• Autonomous Temas (主体的)
  • 開発者が主体的にたちあげてやっている
  • サービスアイデアのプロトタイプなどを自ら立ち上げてやっていたりする
  • 国を超えてチームをくむこともある
• Cold-case
• Remote Collaboration
• Challenge and Contribution
• Scalability and Performance
• Trust and Respect
  • 自分の仕事は自分で最後まで管理していく
  • 自分の意見をはっきり話しながらコミットする。相手を尊重しながらやる
  • 信頼して尊重しながら活動するとポジティブなpeer プレッシャーを得られる
  • LINEでは一緒に一番働いた人がレビューするようにしている
• Globalなプレイヤーを目指しています

LINE Mesanger for the World

池邉智洋様

(写真撮りそこねた・・・)

• 各国独自のルールに対応するのが開発者には求められている
• 海外の人にも使ってもらいたいという気持ちで始めた
• 日本で1000万DLこえたあたりで海外でもユーザーが増えてきた
• 品質の問題が徐々に出てきた
  • 現地のキャリアと話してどうやったらパフォーマンスが出るかをはなしたりした
  • エンジニアが現地に行って、どう使われているかを肌で感じることが適切に実装できるのではないかと考えてエンジニアを派遣した。=>LINE遠征隊とよんでいる
• LINE遠征隊の仕事
  • プリペイドのSIMと何台かの端末をもって実際に現地で使ってみる
  • クラアントとサーバーの開発者が一緒に現地に行く
  • 4日ほど現地に滞在して、現地の人々が過ごすようにホテル、レストラン、電車、バス、観光地、エレベータ、飛行機、高いところなどで、メッセージ、スタンプ、ビデオ通話がストレスなく使えるかを確認する
  • 移動中の飛行機内での使用もやってみたりしている
  • 再送のアルゴリズムを改善したりして質をあげてみた

遠征隊のいってきた国一覧

AirAsiaと提携して飛行機内でLINEで使えるキャンペーンをやったりしてみた

• 改善サイクル
  • 現地に行く前にどのような問題があるかを探し、実装をしてみる
  • 現地でいってみてテストをし、実装も場合によっては現地でやってみる
    • 現地で発見できる問題もあったりする
  • その後レビューされてプロダクションにデプロイする
• 3G WarmUp
  • 3G環境のパケット通信は複数のモードが存在している
  • アイドル、CELL_DCH(高速)。DELL_FACH(遅い)
  • 高速な状態で使用してもらったほうがいい。メッセージを送ろうかなというユーザの動作を検出して、あらかじめ裏側で先にデータを送ることでCELL_DCHに遷移してレスポンスを高速化している
  • 日本は早いのであまり使われないが、海外では回線が遅いのでよくつかわれる
• 関連の強い国家事情も理解した上で実装をする
  • パキスタンの無料通話はサウジアラビアより多い？
    • パキスタンだけで改善しても品質はよくならないので、関連の強いサウジアラビアも一緒に考えてよくする
  • スペインで利用者が増えたことで、同じ言語の南米地域でも利用者の増加があったりした
• スペインではバッテリーの問題があった
  • androidの電池寿命が短い
  • 素早く通知して欲しいが、長い間待ち受けて欲しいので電池を消耗しやすくなってしまう
  • 実際にスペインにいって、電池消耗みながら使ってみた
  • 1年かけて通信頻度や、パケットの調整をした
  • スペインではandroid端末の電池があまり大きい物を搭載したのが普及していなかったのと、地下鉄で電波が掴みづらかった
  • こういうのは日本にいてはおもいつかなかったりする
    • 早い段階で的確な判断をすることができた
• ネットワーク的な施策について
  • Point Of Peerとよばれる中継地点となるサーバ郡を東南アジア地域をカバーするために初めてシンガポールに設置した

全世界におかれたPOP

• POPの構成について
  • 端末と通信するフロントサーバとバックエンドのサーバがあるが、クライアントはフロントサーバと通信している
  • バックエンドはほとんどJavaだが、フロントに関してのみErlangを採用している
  • 世界中にErlangでできたPOPサーバを おいて、専用線で結んで安定した通信を行っている

レビュー分析ツールについて

• ユーザーがどう思って使っているのかを把握しないと問題がわからない
  • app storeやgoogle playのレビューを取得して分析を行っていたりする
  • 特定のキーワードの増減を追跡して、どこに問題があるか、ユーザーが今何を考えているかをとらえて構築している
  • 先ほどの電池については電池という単語とネガティブなレビューが同時にくるので、そこで問題を発見したりする
  • 素早く改善プロセスをまわしたりしている

• システム内部のイベントをとったりもしている
  • イベントの成功率のをとったりして、画像サイズはちょうどよかったのか、もっと調整したほうがいいのかなどもシステムログからわかるようにしたりしている

LINE Platform Development Chronicle

Tom.T(ツルハラ)様

全体のアーキテクチャの話です。

LINEメッセージング基板の進化

• 2ヶ月で開発して2011/06にリリースした
• 初期のアーキテクチャ
  • SendのApiを叩いて実装したりした
  • アプリケーションサーバはJava、フレームワークはSpring。これはいまもかわらない
  • backendはredisとMySQL

メッセージのやり取りについて

• メッセージのやり取りもシンプルだった
  • フェッチしてメッセージがなければN秒まってとりにいく

N秒まったらプッシュも使ってとりにいったりしていた

• 問題としては自分たちでコントロールできなくていざというときにメッセージングが遅延したりした
• Long pollingという技術を使って解決した
  • gatewayがメッセージをサーバと通信しあったりしてクライアントに返したりすることで外部の仕組みに頼らずにやったりした
  • しかしものによってはずっと通信をつかえないのでそこはプッシュ通知を使ったりしている

ゲートウェイについて(リバースプロキシの置き換え)

• 次にnginx+拡張モジュールを使ってゲートウェイを設置した
• しかしセグフォ地獄がそこには待っていた
  • client AがBにおくるときに、eginxの共有メモリにアクセスする同期処理に問題があった

• メッセージングのコアな部分だったのでもっとシンプルに簡単にできないか考えた
  • そのうちnginxのコアな部分までいじらないといけなくなってきたのでErlangを採用した
• Erlang軽量プロセスを並べてメッセージをパッシングできるようになった
• Erlangは分散しやすく、高レイヤーだった
  • VMを再起動しなくてもデプロイできる
• GatewayをLINE Event Delivery Gateway (LEGY)に置き換えて導入した
  • long pollingのメッセージのやりとり以外も既読通知やタイムライン通知などの通知もデリバリーするためこのような名前になった

クライアントとのコネクションについて

• 次に、clientとサーバのコネクション数が多すぎる問題が起きた
  • ここはキャリアとも協力して解決していった
• プロトコルレベルのコネクション数を増やした解決方法の紹介
  • クライアントとサーバ間でプロトコルがHTTPで常にLong Pollingのコネクションをはっていて、さらにまた別のAPIのコネクションをつかったりして、都度コネクションを張ったりしていた。
  • そこでSPDYを採用して、複数のコネクションを1つにまとめた
  • ヘッダ圧縮もできるので通信量も減らせた
• SPDYに移行することでトータル通信量を半分〜1/3まで削減できた

海外パフォーマンス問題

メインのサーバがほとんどメインのDCにあるサーバにアクセスしていたので、遠くの人はレイテンシーの影響を受けていた

そこで専用線を結んだGlobalPOPというLEGYのサーバを各国において通信することで改善した

• しかし専用線で結んでも距離が遠いと遅いので非同期メッセージ送信を採用した
  • LEGYとバックエンドの間の通信が時間かかるので、LEGYはバックエンドの応答を待たずに、受信した旨をクライアントに通知することでクライアントは次のアクションをとれるようになった
  • バックエンドでエラーになった時はクライアントが結果を受け取ってエラーになっていたらクラアントの方で再送信するようにした

• アーキテクチャはだいたいこれでできあがりそこからあまり変わっていない(MySQL -> HBaseに変わった程度)

LINE流マイクロサービス

• サービス成長する際にどんどん機能が追加されていったが、どのように実装してきたかのお話
• ユーザからの要望も大きく、常に新しい機能、品質を求められていた
• それに答えるべく考えたのがLINE流開発スタイル
  • Monolithicの全体を把握しないと新しい機能に着手できないという点は個々の機能を独立したサービスとして実装してジョブキューで連携することで新しい人に開発しやすいようにした
  • これをMicroservicesとよぼう！！

• Talk-server
  • メッセージングやソーシャルグラフが実装されているがその他はそれぞれ独立したサービスとして実装されている
  • 開発言語やミドルウェアもバラバラなものも使っていいとなっている
  • Talk serverはJAVAだが公式アカウントはScalar使ったり、メインはHbase redisだが、Mongoをつかったりしていたりする
• 音声通話などだけでなく、認証管理やPush通知、CMS、Abusingなど独立したサービスとしてでいている
  • 新しいものを実装する際はひとつの機能が独立してやっていたりする
• 分ける工夫を3つ紹介
• 組織
  • 組織図や会社をまたぐチームを形成している
  • 組織図上では誰が何を作っているかわからなくなっている
  • 海外にも開発拠点がいくつかあるが、作るべきなものに必要な人をまとめて一気に作るようにしている
  • 裁量性がたかいチームをいくつももつかんじ
• プロトコル管理
  • wikiにどういうAPIかってかいてそれベースに開発しがちだが、それをThriftやprotobufを使って管理している
  • Thriftはサービスのインターフェースをがちっと記述し、その記述されたものから各言語のスタブをはいてくれるツール
  • インターフェースが明確に定義される
  • またGithub上でサーバのスペックについて議論できるようになる
• ファシリティ
  • たくさん開発チームができるので、各チームで必要な物を予め準備しておかないと、各チーム同じものをつくっていたことになりかねない
  • ある程度同じ開発フローを使って全体的な作業効率低下を防いでいる
  • githubでソース管理して、jenkinsでCIして、Mavenリポジトリにいれて、PMCにフェッチし、PMCから本番にデプロイする
  • PMCはボタンポチポチするだけでリリースできるようにしている
  • IMONというツールを使うことで開発者がいろんな指標をブラウザ上でみることができる

• 組織が多くなるたびに開発の能力も上げていくのが大事

今後の課題

• マルチデータセンター
  • ヨーロッパのユーザがLINEを使うときはメインのDCまで繋がないとサービスできないが、理想としてはヨーロッパのDCだけで完結できるようにしたいので取り組んでいる
• Microservicesの発展
  • talk serverは結構巨大になっているのでこれから分割していかないといけない
  • 障害設計であるサービスが落ちた時に全体的にどうなるかの管理があまりできていないので、これからきちんと整備しないといけない

所感

• 3G WarmUp技術は中々工夫をこらしていて面白い技術だった
• グローバル化にあたり、現地にいって問題点を見つけて解決するのはなかなか良い方法と思った。(自分は海外怖くて中々行けないけど)
• 品質改善への熱を真意に伝わる基調講演でした！！