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

【24-A-7】年間一億円削減した時系列データベースのアーキテクチャ改善～不確実性の高いプロジェクトへの挑戦～

　見込みも立てにくい難しいプロジェクトを始めると、開発現場が迷走し、いつまで経ってもシステムが完成しないということがままある。完成したとしても、当初の見込みを大きく下回る性能しか出せないということもあるだろう。システムを無理矢理完成させて、運用を始めても、大事故を起こして顧客に大損害を与えてしまう可能性が高い。しかし、ソフトウェアエンジニアとしてのキャリアを歩む限り、いつかはこのような難しいプロジェクトを手掛けなければならないときが来るものだ。このセッションでは、LINEヤフー株式会社の坂本大将氏が、社内で使用している時系列データベースのバックエンドストレージをオブジェクトストレージに切り替えた経験から、技術的難易度が高く、抽象的なプロジェクトを推進し、成功させるには、少しずつでも前進しながら、結果を見て改善することの繰り返しが大切だと語った。

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

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

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

LINEヤフー株式会社 Senior Software Engineer 坂本 大将氏

　坂本氏によると、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のコスト効率が悪いため、この部分のストレージを入れ替えることになった。