LINE DEVELOPER DAY 2019(#linedevday)に参加してきました #linedevday_report
ありがたいことに交通費を出していただき参加してきました(3年連続)
過去の記録はこちら
さすがにすべてのセッションを聞くことはできませんでしたが、参加したセッションのメモを記録していこうと思います
間違いがあったら遠慮なくご指摘ください<( )>
HALL-A Keynote
- CTO 朴イビンさん
- 現在、70ものサービスを展開しており今年だけでも20もローンチ
- 「LINE MINI App」のデモ。席の予約やメニューの共有をLINEを通して行える
- AIの進化は凄まじくLINEのAIも進化していて、様々なサービスで活用されている
- LINE BRAIN責任者 砂金さん
- 手書き文字をフォントを作成し、書き込むデモを紹介
- 電話で音声自動応答し飲食店の予約をするAIが大手町のお店で利用されている
- インフラ責任者 三枝さん
- すぐにデータを自ら取得できる Self-Service Data Platform
- 物理サーバは4万台。そのサーバを積むとスカイツリーの3.5本分になる
- Private Cloud Verdaは60名のインフラエンジニアによって開発・運用されている
- ecurity & Privacy 市原さん
- LINEはPrivacy Firstで審査とコンサルを行っている
- アカウント乗っ取りと2年戦い、去年ついに0件にすることができた
HALL-E プライベート Kubernetes クラスタにおける gRPC サービス開発
- LINE LIVEの話
- VM作成→Ansible→デプロイ→ロードバランサに登録
- スケールイン。アウトのコスト削減のためにK8Sを採用
- Verda
- gRPCでマイクロサービスを実現している
- SpringBootでgrpc-javaを利用
- gRPCを使うとフロントとの通信ができないのでgRPC-WEBで通信している
- gRPC-jsonで社内既存システムと連携している
- MySQL with ACL
- 監視とメトリクス
- Promrtheusを使っている
- 時系列DBを活用してデータを取っている
- FlashというDB
- 24万の時系列データが取れてしまい、必要なデータがなにか当方にくれた
- SpringBootActuatorに加えOpenCensusを導入した
- ログ収集
- Fluentd＋Elasticsearch＋Kibana
- Fluentdでログを収集してElasticsearchに入れてKibanaで参照
- IMON（アイモン）
- LINEが開発した監視ツール
- メールやSlackに通知してくれる
お昼ごはん
大変美味しゅうございました(●´ω｀●)
HALL-C Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦
- LIVEDOOR BLOG,LINE BLOG
- LAMP構成（Prel）
- Sledgeフレームワーク
- 数値でみるlivedoor blog
- サーバ移転プロジェクト
- 3年経過したがまだ終わっていない
- SSL化、サーバ移転が終わらないとこれも終わらない
- サーバい移転で数年かかるのはおかしい
- 闇がある
- ドキュメントがない
- デプロイ方法が謎、構築方法も謎、あっても嘘がある
- 開発環境（サーバ）がない or 使えない
- カバレッジが引くい（テストがない）
- DNSのレコードが多すぎ
- 300レコード以上あった
- 調べった結果230が不要だった
- 過去のキャンペーンや旧機能だったり
- これだけで数ヶ月使った
- 歴史があり機能が豊富
- Perl
- 5.6を使っている
- これを使い続けていることが美術力が高いとも言える
- mod_perlは最後のUpdateが2010年
- ApcheもVersionUpできない
- 5.16も混在利用している
- 新旧バージョンを意識してプログラムを組む必要がある。。
- MySQL
- 4.0を使っている
- 120台全部が4.0
- Alter Tableがない。。。
- カラム追加に数ヶ月。。。辛い
- テーブルを消してもディスクサイズは減らない
- これらは氷山の一角
- 4.0を使っている弊害はまだまだある
- DBマイグレーション計画5.7へ
- しかし時間的成約とうとうで行えなかった
- 自社のDBサーバ基盤にMySQL4.0を移転することができなかった
- APサーバ基盤として移行すればいいじゃね？→成功！
- テーブル毎に文字コードが異なる
- euc-jpとutf8が混在している
- これが原因で正攻法のマイグレーションができない
- 4.0→4.1→5.0ができない
- 新しいMySQLClient5.7がMySQL4.0に接続できない問題があるため次のプロジェクトが始まっている
- ドキュメントがない
- LINE Blog
- LINEアカウントがあればすぐに始められる
- 2014.11にローンチ（芸能人のみ）
- 2016年にリニューアル（一般ユーザも）
- livedoor BlogのASPとしてLINE BLOGが始まった
- 2016.4にlivedoor blogから切り離し
- livedoor blogをforkした
- 闇をすべて引き継いだ。。
- LINEエンジニアが本気を出してすべての問題を解決した！
- LINE BLOGの知見をlivedoor blogに活かされている
- 今担当しているシステムの10年後、15年後に負債を残したくてこんな事になっているわけではない
- 日々の地道なリファクタリングやバージョンアップ、バージョンアップできなくてもメンバーに問題を共有することが大事
- 未来のためになにか1つでも動きましょう！
HALL-C LINE NEWSの記事配信を支える技術
- 天気やJアラートなども配信している
- 月間68Mユーザが使っている
- 1日17万リクエスト
- 12:00から20:00に利用が多い
- Amon2(Perl)とSpringBootで動いている
- Java移行が進んでいる
- MySQLが3台、Memcachedが44台、MongoDBが21台、Redisが4台
- レコメントはマシンラーニングだけでなく手動による配信もされている
- 社内のデータラボでマシンラーニングを行っている
- 1億人以上のデータを行っている
- 初めてNewsタブを開く人用にもレコメンとしている
- 1時間あたり200億件分のデータを取り込む
- リコメントは
- 年齢、地域、性別を基本として行う
- お気に入りしている内容も使われている
- MLと手動ではなくMLから始めたが問題があった
- 今後の展望
- レコメンとの向上
- 改善されたレコメンとの返却は1時間かかってしまう。バッチなため
- 新しいレコメンとシステムでリアルタイムで返していて一部ユーザにABテストをしている
- ダイジェストは全ユーザ同じデータを表示しているがレコメンとを採用してユーザ毎のダイジェストを返すようにしたい
HALL-A Reliability Engineering Behind The Most Trusted Kafka Platform
- Kafka
- ストリーミングデータミドルウエア
- Scaraで書かれている
- LINEでは
- サービス間のハブ
- バックグラウンドの非同期タスクとして分散して処理させる
- 60を超えるサービスで利用されている
- 3650億件のメッセージが1日で利用されている
- SLOは99.999%、年間のダウンタイムが5分未満
- トラフィックスケール＋SLO
- SLOの指標を取る
- 誰が行っても同じ結果になるように自動化をすすめる
- Kafkaのクライアントライブラリの開発やリファレンスを提示することでサービスがより良い地用を推進する
- SLO
- SLIを決める必要がある
- APIのレスポンスタイムやエラー件数だけではなく
- クライアントのリトライ時間や回数も考慮する必要がある
- Proberを開発（プルーバー）
- メトリクスを測定するツール
- クラスタで起きたフェールオーバー等も考慮する
- Prober
- ライター、リーダー、レポーターの3つが動く
- YAMLファイルで細かい設定をすることが可能
- これらを用意てSLIダッシュボードを出している
- トラブルシューティング
- トラブル時は根本的な解決を目指す
- GCの調整で終わらせず、なぜ問題になったのかを追求する
- この経験はナレッジとなって今後も活用されていく
- 恒久的な改善となっていく
- 10秒以上のレスポンスがかかってしまった
- Zookeeperのセッションタイムアウトになってクラスタから覗かれてしまう
- GC問題に対してメトリクスを常に取っている
- safepointと呼ばれる機能がGCにはある
- ディスク書き込みタイムが悪化
- これらからsafepoint内で書き込みが悪化している？
- SystemTapというツールでLinuxカーネルのイベントを計測することができる
- ハードウェアの交換で問題が発生しなくなってしまった
- 諦めるか？否、諦めない
- kprobeというツールでLinuxカーネルのモジュールをハックする
- ext4以外のファイルシステムを使う？
- リだいアリティエンジニアリングの活動
- 必ずクライアントの視点から
- 根本的な原因究明をしてから解決を進める
HALL-D LINEのメッセージングプラットフォームにおけるマイクロサービス化への長い道のり
- LINEにおけるマイクロサービスの作り方、運用の仕方について
- モノリシックなサービスとして2010年に開発された
- 開発のスピード低下を下げるためにチームを切り離して開発のスピードを挙げた
- 機能毎のリリースやコンフリが起きにくくなった
- が、ネットワークの負荷が高くなったり、1つのサービスが落ちるとすべてが落ちるといったこともある
- Armeria（アルメリア）
- RPC/RESTライブラリ
- ネットワーキングライブラリ
- ロギング、ロードバラ寝具、モニタリング、サーキットブレイカーなどを組むこまれている
- HTTP2は一度接続するとコネクションを貼り続けるがソフトウェアレベルでロードバラ寝具をする
- ディレクトリサービス（Central Dogma）
- どのサービスがどこで動いているかを管理する？
- サービス名を指定するだけでエンドポイントを意識することなくアクセスすることができる
- LEGY（レディー）
- APIGateway
- SPDYとHTTP2をサポートしている
- クライアントが接続する先を管理している？
- スタンプ処理が肥大化し2007年で限界を迎えた
- 個人用にカスタマイズされたスタンプがどんどん増えた
- スタンプのオーナーをRedisで管理していた（大人数を想定していなかった）
- Redisのスロークエリが発生してtalk-sarverが止まってしまう
- メッセージサービス全体に普及してしまう
- 他のサービスに影響を及ぼさないように切り出した
- フィーチャー単位で切り分けていたものをFunction単位に切り替えた
総括
メモ書きで読みづらい点も多く、申し訳ない。。
今年は2日間にわたり開催されましたが、仕事の都合もあり1日目のみの参加となりました
どうにかして両日参加すべきだったかなーとちょっと後悔しております
日本が誇るLINE社の技術力の高さを感じることができ、とても満足のいくイベントでした
ぜひ来年もぜひ参加させてください スタッフの皆さま、会素晴らしいイベントお疲れ様でした
ありがとうございました！
