re:annkara

日々学んだことを書き留めておく。

LINE DEVELOPER DAY 2019 DAY1 参加メモ

Conference LINE DEV DAY

LINE DEVELOPER DAY 2019 DAY1に参加してきました。
DAY2も参加したので、分けて書こうと思います。

スライドは以下のリンク先に公開されています。

Presentations by LINE DevDay 2019 - Speaker Deck

Keynote

LIFE with LINE

私のLINEの利用経験としては単にメッセージサービスくらいにしか利用していないのですが、提供しているサービスの幅広さに驚きました。

金融分野からeコマース、エンターテイメントなど人が生活する上で必要になる領域において、LINEというプラットフォームをベースに様々な分野でサービスを提供していることを改めて気づきました。

Natural Experience with AI

様々なサービスを提供しているLINEですが、そのサービスの中心になりつつあるのがAI技術である印象を強く持ちました。

AI技術を活用することでユーザ体験を向上させることに繋げ、サービスをより利用してもらうようにする。

そのためには必要なデータを必要な時に扱えるようにデータプラットフォームの整備や、サービスの開発ライフサイクルに合わせたインフラ基盤の提供、データに対するセキュリティやプライバシー保護などの仕組みを整えている。

ビジネスとテクノロジが上手く融合していて、こういう企業で働けると楽しそうだなという印象を持ちました。

特に、データプラットフォームの構築や柔軟なインフラ構築を実現するためにプライベートクラウドを自前で構築することでビジネスや開発者に貢献していくという点が非常に良いなと思いました。

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

LINE LIVEという動画配信サービスの開発にプライベートクラウド上のKubernetesを導入した話。

Kubernetesを利用する理由

Kubernetesが必要になった理由として、サービスのトラフィックが増加した際に容易にシステムをスケールアウトできることが必要であった。 手動によるスケールアウト／スケールインを行っていたが運用負荷が高くなってしまっていた。

LINE内ではKubernetes Clusterの提供までがインフラ側の役割であり、アプリケーション側ではNamespaceの作成からPodのデプロイ、ロギング・メトリクスを収集する環境までを行う。

アーキテクチャ

サービスとしては、Envoy + SpringBoot + gRPC を組み合わせたマイクロサービスアーキテクチャで構成されている。

EnvoyはL7ロードバランサとしての役割 + プロトコルコンバータとして外部からのリクエストをgRPCプロトコルへと変換する役割を果たしている。

Istioの導入を避けた理由として、メトリクスの収集や分散トレーシング、サーキットブレーカやリトライパターンの実装などはSpringが提供する機能で賄うことができたり、レイテンシの低下を懸念して避けたとのこと。

Istioのパフォーマンスに関しては以下を参照。
Istio / Performance and Scalability

DBはプライベートクラウド内でマネージドなDBサービスを利用しているが、このDBにアクセスするためには接続元サーバのIPアドレスをACLに登録する必要がある。

Kubernetesのノードスケールと相性が悪かったため、スケール時にフックしてACLにスケールしたサーバのIPアドレスを追加する仕組みを実装している。

メトリクス・ロギング・アラート

メトリクスの収集にはPrometheusを利用しており、収集したメトリクスは自社内で開発しているTSDBに格納している。

ログ収集には Fluentd + Elasticsearch + Kibana を利用しており、アラートなどは IMON と呼ばれる自社で開発しているツールを利用して検知・通知を行っている。

気になる技術

  • HTTP/2
  • gRPC
  • Envoy
  • Spring Boot Actuator
  • OpenCensus

どれも言葉としては知っているけど、深く調べたり実際に触ってみたわけではないので学習したい。

LINEが開発した時系列データベース‘Flash’の紹介

前のセッションで触れられていた時系列データベースに関するセッション。

Observabilityとは何か

システムの出力からそのシステムの内部状態がどれほど健全か推測できるよう計測を行うこと。
LINEのObservability Teamの役割はサービスが健全であるように手助けをすること。

そのためにメトリクス・ログ・分散トレーシングの集約を実現するインフラ基盤を提供している。

時系列データベースを実装するモチベーション

この数年で収集するメトリクスが劇的に増加した。
メトリクスの保存するストレージは当初はMySQLやOpenTSDBを利用していたが、障害が発生するたびに運用でカバーしていた。

OSSや商用製品の利用も検討したが、以下に述べる要件やコスト、カスタマイズ性の欠如のなどもあり自前で実装することにした。

時系列データベースにおけるLINE社の要件

  • 様々なプロトコルに対応していること
    • HTTP
    • UDP
    • Prometheus Protocol
  • Read/Writeの両方でスケールアウトできること
    • 10xのメトリクスをサポートできること
    • 低レイテンシの実現（Read/Write < 100msを99パーセントタイルで実現）
  • 低コストかつ容易にメンテナンスできること

実現したこと

  • 400万件/秒の書き込みを実現
  • 1000クエリ/秒を捌く
  • Read/Writeのレイテンシを100ms以内に（99パーセントタイル）

アーキテクチャ

  • 開発言語はGo言語を採用
  • 全てのコンポーネントを自前で実装することは避けた
    • バックエンドのストレージにはCassandraを採用
    • ラベルストレージにはElasticsearchを採用
    • Walログ？？RaftログにはRocksDBを採用
  • マイクロサービスアーキテクチャを採用
    • 送信元を判別する情報と実際のデータを保管するストレージを分離
    • 分離したことでデータの保持方法を最適化できた
  • 直近28Hのデータをインメモリに保持する
    • 直近のデータはインメモリに保持
      • メモリ効率のために Delta-Delta XOR algorithmを採用
      • 水平スケールのためハッシュ値を元にデータを分散
        • RocksDBはここで利用されている？？
    • それ以降のデータは永続化ストレージに保管（上記のCassandra）

プロトタイプ開発は2ヶ月ほどで終えたが、プロダクションレディにするためには1年ほどかかったそうだけど、それでも1年で実装したのは凄い。

@yuuk1tさんと登壇者の@dxhuyさんの以下のやりとりも非常に面白い。

LINE NEWSの記事配信を支える技術

LINE NEWSは2013年にローンチされたサービスであり、当初はネイティブアプリとしてリリースされていたが、2017年にLINEアプリに統合された。
ピーク時には秒間375Kのリクエストを受け付けるため、相当なトラフィックが発生していると思われるサービス。

アーキテクチャ

PerlとJavaが併用されているらしく、Javaへ移行しつつあるそう。

Personalized Recomendation

LINE NEWSは各ユーザの特性に応じたニュースをお勧め記事として配信している。

機械学習によって作成されたお勧めニュースの配信をする場合と、人手によるお勧めニュースの配信をする場合の二通りがある。

機械学習によって作成される配信記事は、機械学習チームによって全ユーザ（1億人）毎に200記事を作成しファイル形式で提供され、1時間ごとに更新される。
人手による配信の場合、特定のクラスタごとに配信するニュースを決定する。

機械学習によるお勧めニュース配信においては、記事のリストを保持するストレージにRedisを利用している。 ニュース記事本体のデータはMySQLに保持しているが、キャッシュサーバとしてRedisを利用している。

人手による配信の場合、お勧め記事のリストのストレージには機械学習の場合と同様、 Redisを利用しているがニュース記事の本体のストレージにはCentral Dogmaを利用している。

Central Dogma

line.github.io

LINE社が開発しているOSSで、バージョン管理 + 設定ファイル管理＆通知システムみたいなもの。
アプリケーションの設定ファイルを管理し、変更があった場合にはその設定を利用しているアプリケーションに通知を行い、アプリケーションの再起動をせずに設定を変更することができる。

Central Dogmaの利用

この仕組みを利用してニュース記事をCentral Dogmaに格納し、アプリケーションはCentral Dogmaから記事が更新されたことを受けアプリケーション内にキャッシュすることで、ストレージにアクセスすることなく記事を配信することが可能となる。

一時間ごとの更新頻度をリアルタイムに近づける試みなども行っており、課題に対して積極的にシステムを変更したり、改善したりしていたことが印象的でした。

気になる技術

  • Central Dogma

Kubernetesの利用・普及、その先は何か?

ゼットラボ株式会社の代表取締役である河宜成さんのセッション。

設立当初のミッションとして「イケてるモダンなインフラを構築する」ということもあり、DockerやKubernetesなどの技術がリリースされてから直ぐに取り組んできた。

Yahoo!社向けにKaaS（Kubernetes as a Service）を提供しており、Yahoo!社のエンジニアに対して積極的なサポートを行っていることもあり、2017年では5クラスタであったが2019年になると400クラスタまで増え、今後も増え続ける想定とのこと。

今後どんなことをやっていくかということを考えるためには、今何が起きているかを知る必要があると仰っていたことが非常に印象的でした。

気になる技術

今後の展望で述べられていた技術・用語。

  • NoOps
  • サーバレス
  • ゼロトラストネットワーク
  • ステートフルなアプリケーションをK8s上で実行する

Reliability Engineering Behind The Most Trusted Kafka Platform

LINE社のKafkaプラットフォームにおける信頼性エンジニアリングに関するセッションでした。

LINEにおけるKafka

LINE社ではKafkaをサービス間のPub/Subであったり、メッセージキューとして利用している。
以下の指標が指し示している通り、莫大なメッセージ・データ量を捌いていることがわかる。

  • Daily Inflow Messages
    • 360Billion
  • Daily In+Out Data
    • 550TB

SLO（Service Level Objective）

SLOとしては以下の通り。

莫大なメッセージを取り扱うプラットフォームにおいて、以下のSLOを達成することは非常にチャレンジングであると同時に卓越したエンジニアリングがなければ実現し得ないと思う。ただ単に凄い。

  • 可用性
    • 99.999%（年間で許容されるダウンタイムが約5.26分）
  • 応答性能
    • < 40ms（99%のメッセージ）

SLOを実現するためにとりくんでいること

SLOの可視化

SLOを可視化するために、SLI（Service Level Indicator）を定めている。
SLIはサービスの可用性・応答性能を数値として計測できなければならない。

  • API Response Time
    • レイテンシの測定（応答性能）
  • API Error Rate
    • 可用性の測定

たいていこれらのメトリクスはサーバサイドで取得されることが多いが、それだけでは不十分である。

SLIの精緻化

  • クライアントライブラリは信頼性向上の機能を備えているため、以下を考慮する必要がある。
    • リトライした場合
    • フェールオーバした場合
  • Kafkaにおけるメッセージ配信のレイテンシは以下を含む
    • メッセージリクエストのレスポンスタイム
    • リクエスト時のフェールオーバ・リトライ・メタデータの更新に要した時間
    • メッセージを利用する側のリクエストタイム
    • メッセージを利用する側のcoordinationに要した時間（ちょっとここが理解できないけど、分散システムならではの調整時間が要するのだと理解）

Kafkaやライブラリの仕組みを理解したうえで、SLIを精緻化する必要がある。
こういった仕組みを理解し、SLIを詳細に定めたうえで、測定可能なクライアントライブラリを開発し、SLIのダッシュボードを作成している。

Troubleshooting

トラブルシューティングに関しては根本的な原因を究明し、解決することを信条としている。
原因の究明・解決の過程で身につくスキルは、他の同様の障害に応用可能であるし、深い知見を身に着けることができるからとのこと。

障害解析の具体的な例も説明されていたけど、ここでは割愛するけど、JVM・システムコール・ファイルシステム・ブロックストレージデバイスまで降りていって障害解析する過程は非常に興味深かった。

SREとしての矜持といったものを感じられて非常に刺激を受けたセッションでした。