LINE（⁠株⁠）は11月20日と21日の2日間，東京・お台場の「グランドニッコー東京 台場」で，同社が運営するサービスや技術領域でのチャレンジ，今後の取り組みなどを紹介する技術カンファレンス「LINE DEVELOPER DAY 2019」を開催しました。

今年で6回めを迎える同イベントですが，今回は初の試みとして2日間にわたっての開催です。初日は「Engineering」をテーマに技術関連の話題が，2日めは「Production」をテーマにプロダクト開発に関する実践的な話題が各種セッションで紹介されました。本稿では，その中から，初日に開催されたXuanhuy Do氏と早川侑太朗氏によるセッションの模様をお届けします。

「LINEが開発した時系列データベース‘Flash’の紹介」by Xuanhuy Do氏

LINEのObservability Infrastructureチームのエンジニアマネージャを担当しているXuanhuy Do氏より，「⁠LINEが開発した時系列データベース‘⁠Flash⁠’の紹介」というテーマでセッションが行われました。

Observabilityとは，アウトプットと推測という意味で，アプリからのアウトプットによってその状態を調べることができるというものです。Xuanhuy Do氏が所属するObservability Infrastructureチームの役割は，開発サービスの健康状態を保つことです。

膨大なメトリクスをさばくプラットフォーム

同チームでは，現在3つのインフラを提供しています。1つめは，メトリクス収集です。マシンのCPUやメモリの状況を，数字で表せるアラートやグラフとして提供しています。2つめはログです。アプリ内で発生したエラーなどをアラートとして届けたり，可視化したりするための基盤の提供です。3つめは，分散トレーシングです。こちらは別の機会があったときに，紹介していただけるとのこと。

アプリケーションのメトリクスは重要で，外すことができないものです。アプリがユーザに安定的に提供できているか，あるいはレイテンシが満足できるものなのか。こうしたものは，メトリクスがなければ判断できません。

現在同チームがさばいているメトリクスの数は，2016年から比較すると今年は20倍に増えており，来年はさらに5倍に増える見込みです。そのおもな理由としてはビジネスの成長やマイクロサービスの増加などが挙げられます。

LINEのメトリクスプラットフォームでは，自社で開発したエージェントをサーバにインストールします。そのエージェントがホストのメトリクスをプッシュし，データ収集サーバがメトリクスストレージに格納し，それをユーザがグラフのUIやアラート設定に使用します。このメトリクスストレージに使われているのが，同チームが開発した「Flash」です。

ストレージを2つのマイクロサービスに分ける

同チームが作ってきたメトリクスストレージの歴史は，LINEのメッセンジャーが作られる前にさかのぼります。2011年にMySQLで作られましたが，データの圧縮に不向きなところやレイテンシなどさまざまな問題を抱えるようになってきたことから，2017年には新たなストレージに変更しています。このときに採用したのがOpenTSDBです。OpenTSDBのメリットは，サーバを追加すればするほど書き込みがスケールするところです。しかし，読み込みはそれに比例しません。Facebookの「Beringei」やNetflixの「Atlas」など，いくつかのオープンソースも試してみたものの，読み込みは速いが書き込みが遅かったり，安定性に欠けていたりといった問題がありました。そうしたことから，ストレージを自分たちで作ることにしたそうです。

「Flash」を作る際には，3つの要件を満たす必要がありました。1つめは，いずれのプロトコルであってもユーザが使えるようにすること。2つめは，スケールアウト性能が高く，低レイテンシであること。3つめは，低コストでメンテナンス性が高いことでした。

これらを実現するために，同チームはまずメトリクスストレージを2つのマイクロサービスに分けました。1つは，テキストデータを格納するためのサービス，もう1つは数値を格納するサービスです。

メトリクスプラットフォームでは，CPUのモニタリングなどを行います。CPUのモニタリングデータには，ラベル（{"HOST"="Host1"}{"Zone"="JP"}など）と，時間ごとの値であるデータポイント（⁠「⁠12:00,0.5」など）が含まれています。

この2つを別々のストレージに格納することで，テキストデータであるラベルと，数値データであるデータポイントそれぞれに合わせて最適化ができるようにしています。

また，読み込み／書き込みの両方の性能を確保するために，データポイントのストレージをさらに2つに分け，直近28時間以内のデータポイントをインメモリのストレージに，28時間を経過したデータポイントを永続型のストレージに移すことにしています。

データベースを自ら開発したといっても，すべてを1から作り上げたわけではありません。車輪の再発明にならないように，自作しなくてもよい部分に関しては既存のサービスを利用しています。たとえば，ラベル用のストレージには「Elasticsearch」を採用し，永続型のストレージには「Cassandra」が選ばれています。

データベースの作成には5年かかると言われていますが，プロジェクトがスタートしたのは2018年末で，2019年には早くもリリースされて，現在すでに本番稼働中です。しかし，プロトタイプ自体は2ヵ月でできたものの，その後実際に本番環境にリリースするまでには1年間という時間がかけられています。簡単にできるものは短時間で完成しますが，本当にベストのものを作るには時間が必要になります。

今後は，メトリクスの数も増えていくため，パフォーマンスや信頼性をより高めていくと語り，セッションを締めくくりました。