LINE Developer Day 2019 Day1 レポーティング(と言う名の自分的メモ)

gRPCの事例について聞きたいだけの人生だった

Motivation

参加のMotivationは上の見出しの通りです。 gRPCで、超高トラフィック、BtoC、これほど事例として、パーフェクトなものはなかなかお目に書かれるものではありません。

結果、それ以外にも非常に勉強になる情報を持ち帰って来れたので、非常に有意義な時間でした。

LINE Developer Day Is 何?

LINEさんの提供するサービスに関する技術スタックに関するチャレンジによる知見の共有、そして、今後LINEさんが提供するサービスのロードマップを紹介する技術カンファレンスです。

今回は初めて2日体制で行われたようで、

Day1=>Engineering

Day2=>Production

がテーマでした。

KeyNote

LINE Payのユーザー数:日本=>3700万 ワールドワイド=> 5000万 LINE Payに関わらず、近年力を入れ積極的にAIの力を利用している。(AIカンパニーとしてのブランディングを感じました。)

LINE BRAIN

LINE BRAIN室 室長 いさごさん(元々Microsoftにいらっしゃった方だったので、この業界の人材流動性の高さを改めて感じてみる。)

AI OCRの話

機械学習を使ってのフォント作成チャレンジ事例の紹介。

フォント作成のためには、通常数千文字の手書き文字が必要。 早稲田大学2年生の田村くんが手書き風レポートマシンを作ったときは7000字以上の文字データを入力したらしい。 www.mbs.jp LINEが開発したAI OCRの方は、500字程度でフォント作成が可能。

※ この件、個人的には、早稲田生の田村くんに、大きな拍手を送りたいお気持ち。実行力、実現力もそうですが、マインドセットが素晴らしい。

LINE Ai Callの話

自然言語処理技術の事例として紹介されました。 電話での予約受付と簡単な問い合わせ対応を全てAIが対応してくれるらしい。コミュ障にやさしい。

[俺のGrill&Bakery 大手町] に実験導入中。固定電話から電話を掛けると、AIが対応してくれる。(なるほど、こういうのを指して、人間の仕事を奪うって言う表現がまかり通るのか。というお気持ち。) tabelog.com

KeyNoteの印象

これはKeyNoteに関わらず感じたことでしたが、LINEさんはミッションドリブンな企業風土だなーという印象でした。 プレイヤー / マネージャーのエンゲージメントも高いように(外からは)感じられましたし、ミッション遂行のために技術を磨いて当たり前という空気感は非常に気持ちが良かったです。

プライベート Kubernetes クラスタにおける gRPC サービス開発

LINE LIVE サーバーサイドエンジニア宇井さんのセッション。 LINE LIVEの、Live Commerce(アーティストの応援がてら購入しちゃう機能っぽい)機能の構築に、k8s, gRPCでの構築を行ったお話。

gRPCの選定理由は様々

個人的に気になっていたgPRCの選定理由。聞いてきた内容は以下(実際はとても丁寧にご対応頂きましたが量が多いので文章雑にお送りします。)

MicroServiceだとREST/Json は遅い。とにかく遅い。

バイナリーでやり取りしたい。速くしたい。

あと、今回は新機能開発でチャレンジできるので、社内に知見が少なかったgRPCを選択した。

チャット機能も選定当初は実装する予定だったので、双方向通信でもgRPCは利用する予定だった。(工数の都合上、最終的にチャット機能は本体側のもの?を利用することになった。)

ClientサイドでJsonほぐすのめっちゃだるいし、Protobuf最高な人生だった。(クライアント担当の方の意見)

サーバーサイドでも。Protobufだと更新楽だから生産性が向上する。(この辺はRESTでもSwaggerからプロキシクラスを生成出来るけど、クライアントをFlutter使っていることもあって、gRPC楽って感覚が強かったような感触。)

登壇されていた宇井さんも淡々と大量に情報をくださる方で、感謝しかないです。m(__)m

また、ブースに行ってご質問をさせていただいた相手の方が、クライアントの開発者の方だったのですが、サーバーサイドに関する質問にも丁寧にご回答頂き、非常に助かりましたし、クライアントの方でもここまで理解し、説明できることに感動しました。

また、意外というか、gRPC For Webを既にProdで使っているという事例は、非常に勇気を貰いました。

これは自分の先入観だと思いますが、サーバー間通信はgRPCがベターと思っていましたが、Webブラウザー等のClientからのリクエストはまだまだProdはRESTかなと思っていたので、この話を伺うことが出来たのは非常に心強かったです。

Inside Of Blog; 15年間熟成されたサービスの光と影、カオスとレガシーの挑戦

LINE Blog,Livedoor BlogのServer Migrationを担当している大森さんのセッション。

livedoorブログのダークサイド

ドキュメントがない。

開発サーバーもない

livedoorブログをLineブログに統合させるために、まず開発サーバーを作る。

テストコードもない

DNSのレコードが多すぎた(over 300 Records) ※ なお、230は不要なレコードだった。

機能が多すぎた。(ガラケー版とか、トラックバックとか)

言語バージョンを、17年間固定してた。(perl 5.8)→逆に技術高い

少しだけ新しいバージョンのperl(5.16)も混ぜてモジュールメンテナンスしてるので、管理辛い

MySQLが4.0

lineの社内共通基盤にはMySQLがそもそも乗らない

永続化層の基盤には乗せられないのでAPサーバーの基盤にMySQLを乗せて解決(?)した。

MySQL Client 5.7.5からはMySQL4.0に接続できなくなるから、どうしよう?←イマココ

livedoorブログをline側の基盤に移行させるプロジェクト、2017年から始まっていて、2020年の前半までやるらしい。

なお、LINEブログはLivedoorブログをForkして作ってるけど、こっちはエンジニアが本気出したのでなんとかしました。

LINEブログだけを直したのは、経営判断でしょうけど、このへん開発者は、livedoorブログの方も直したくなっちゃうから気を付けないと行けないなーというお気持ち。

この辺、きっちり選択と集中を実践し続けられているのは、素敵なことですね。

最後に仰っていた、「普段から少しでも負債と向き合って、ちっさいところでもいいから改善を入れていくことが大事」という言葉は、アプリケーションの成長っていう事柄に向き合う上で非常に大事。

負債と向き合わない理由を探す人が1人でもいると、変にパワーが取られて邪魔になるので、1人1人がちっさい改善でもいいからプロダクトの品質にコミットしていくっていうのは、自分含めて本当に多くの人に意識して欲しい。