計測と改善をひたすら繰り返したら、年間コストを1億円削減した──不確実性の高いプロジェクトに挑む

更新前のシステムの全体像と、抱えていた課題

　LINEヤフーでは、時系列データベースを自社で開発して運用している。統合監視ツール「IMON」で収集する「Metrics」「Logs」「Traces」の3種類のデータを保存するデータベースだ。今回はそのうちMetricsを保存するバックエンドストレージを入れ替えた。入れ替えに至った主な理由はコスト効率。柔軟なスケールアウトが難しい課題もあった。

　現在、LINEヤフーは10億種類以上のMetricsを保持しており、合計データ量は500テラバイト弱。さらに、このデータが1日当たり2.3テラバイトも増え続けている。これほどの大規模なデータを格納し、高速に検索できなければならないと考えると、今回のプロジェクトは途方もないことのように思える。

　坂本氏によると、Metricsは主に「Metadata」と「Sample」の2種類のデータで成り立っている。Metadataは、Metricsの名称とサーバーや環境を特定する情報を記録したKey-Valueペアになっている。一方Sampleは、Metricsを観測した時間のタイムスタンプと、実際のMetricsの値を並べたものだ。

　IMONでは、Metricsを保存するデータベースとしてMetadata用とSample用の2種類を用意して、使い分けている。クエリのKey-Valueペアと、検索対象の時間をAPIが受け取ると、Metadata用のデータベースを見て、指定の時間から対象となるMetricsのIDを探し、ラベルも取得する。そして、取得したIDをキーにしてSampleのデータベースを検索し、時間とIDから目的のMetricsの値を並べたものを取得し、クライアントに返す仕組みになっている。

　Sample用のデータベースと、Metadata用のデータベースは、それぞれストレージが2階層になっている。24時間以内のデータは参照頻度が高く、性能が求められるためインメモリデータストアに保存しており、24時間以降のデータはCassandraやElasticsearchなどのOSS製品を利用したパーシステントデータストアに保存する。今回は、Cassandraのコスト効率が悪いため、この部分のストレージを入れ替えることになった。