ClickHouse 活⽤によるパフォーマンス改善について 2025/12/15 Naomichi Yamakita 

© Metaps Holdings, Inc. ⾃⼰紹介 ベトナム‧ハノイでのオフショア事業⽴ち上げからキャリアをスタートし、 アプリケーション開発からマネジメントまでを経験 2015 年に当社参画。徐々にクラウドインフラにも携わり、現在は横断的な テックリードや SRE チーフエンジニアとして従事 「AWS DevDay Tokyo」登壇、「Amazon Web Services ブログ」、 「builders.flash」寄稿、「Community Builder」メンバーなど 昨年より SRE のためのダッシュボード「srest」プロダクトオーナーを兼任 ⼭北 尚道 株式会社メタップスホールディングス srest プロダクトオーナー 兼 SRE マネジャー Naomichi Yamakita ＠sre_yamakita 2 

srest の概要 

© Metaps Holdings, Inc. srest の紹介 

FinOps とは ● FinOps = Finance + DevOps ● 組織全体でクラウドコストの可視化‧最 適化‧管理を継続的に⾏う⽂化的プラク ティス ● FinOps がもたらす価値 ○ クラウドコストの透明性向上 ○ 無駄なリソースの削減 ○ 予算管理とコスト予測 ○ チームによる⾃律的なコスト分析 ○ クラウド投資の ROI 向上 

srest は SRE チームから⽣まれたプロダクト ● 社内外含め、複数のプロダクトを SRE チームが横断して管理 ● 元々はコストの可視化ではなく、AWS を 始めとした様々なサービスから通知され るイベントログを⼀元的に管理するダッ シュボードとして内製で開発した ● srest = SRE + Rest (SRE を休ませる) とい う造語 ● 2024 年 9 ⽉ ⼀般リリース 

© Metaps Holdings, Inc. コスト可視化へのシフトチェンジ ● AWS を横断的に管理する上で、各 プロダクトの運⽤にかかるコストの可視化 が求め られる ● AWS 請求アカウントでアカウントごとのコストデータは確認できるが、別の Organization のコストを⾒るにはアカウントの切り替え作業が発⽣してしまう 

© Metaps Holdings, Inc. プロトタイプから⼀般公開へ ● AWS のコストを可視化するため、Cost Explorer API ベースでプロトタイプを実装 ● データベースにはログ基盤でも採⽤している OpenSearch Service をそのまま利⽤ ○ Cost Explorer API は可変の JSON データを返すため、OpenSearch と相性が良 かった ● コスト可視化の需要が⾼まり、より⾼度な分析フォーマットとして CUR 2.0 (Cost and Usage Report 2.0) をサポート ○ 初期フェーズは既存の OpenSearch 基盤を活⽤し、迅速なリリースを優先 

© Metaps Holdings, Inc. 2025 年 6 ⽉ 名古屋市様で正式導⼊、11 ⽉に NEC 様との業務提携を発表 

© Metaps Holdings, Inc. 名古屋市様における AWS コスト可視化の課題 ガバメントクラウド という背景 ● 政府が⾃治体向けに提供するクラウドサービス利⽤環境。全国の⾃治体は 2025 年度 末までに基幹業務システム (住⺠記録、税務などの業務) を標準化し、クラウドに移⾏ することが求められている ● 名古屋市様では クラウド基盤に AWS を採⽤ 

© Metaps Holdings, Inc. ガバメントクラウドにおけるコスト可視化の課題 ガバメントクラウド環境下では、⾃治体は請求アカウントにアクセスできないため、デジ タル庁からの請求書では詳細な内訳が把握できない ⾃治体 デジタル庁 ❌ 請求の内訳が分からない ❓ ❓ 按分入力 運用 請求書の 発送 運⽤補助 事業者 GCAS 

© Metaps Holdings, Inc. 特筆すべき機能 - アロケーション AWS のコストを任意のグループに分類‧按分する機能 コスト配布タグに加え、サービス名や ARN (Amazon Resource Name)、 使⽤タイプ (UsageType) を⽤いたリソース按分に対応 

ClickHouse 導⼊による パフォーマンス改善 

© Metaps Holdings, Inc. ● 現在の構成はログ基盤にコスト機能を後付けした形となっており、⼤量の数値データ を扱う コスト分析には最適化されていない ● CUR の ETL 処理がボトルネックとなっており、処理時間の増加が顕著なため、スケー ラビリティを確保するデータ基盤の再設計 が急務 システム⾯の課題 

© Metaps Holdings, Inc. コストの取得から保存までの流れ 

© Metaps Holdings, Inc. ● ⼀貫性のあるスキーマ。固定の列セット (125 フィールド) を提供 ● Data Exports 機能により、指定した S3 バケットに少なくとも 1 ⽇ 1 回以上更新 ● レコード単位で ⼀意性を持つキーはない ● 1 ヶ⽉あたりのレコード量は数⼗万〜数百万件 (使い⽅による) ● CUR のデータは 過去分含め更新が発⽣ する CUR 2.0 (Cost and Usage Report) の仕様 

アロケーション仕様 ● CUR の各レコードに対して、ダッシュ ボードで設定されたアロケーションルー ル (タグ、サービス、使⽤タイプなど) を 評価 ● マッチしたルールに基づき、レコードごと にビューと按分⽐率を紐づける ● ダッシュボードでは ビュー単位でコスト を集計し、組織やシステム別の正確なコス ト可視化を実現 

© Metaps Holdings, Inc. ● CUR のデータは請求確定まで変動するものの、暫定値を常にダッシュボード上で可視 化する必要がある ● AWS の請求⾦額は毎⽉ 1〜5 ⽇に確定するため、毎⽉ 6 ⽇には前⽉分の請求確定⾦額 を可視化 する必要がある ○ AWS アカウントごとに最新の CUR データを再取得し、アロケーションの再計算 を含め、数千万から数億レコードにわたる前⽉分のデータを⾼速に書き換える必 要がある スケーラビリティ要件 

© Metaps Holdings, Inc. ● ログの基盤として OpenSearch は扱いやすいが、サーバーを安定稼働させる上では維 持コストが⾼い ○ 商⽤環境は マスターノード x 3 + データノード x 2 台以上の冗⻑化 が推奨 ● OpenSearch は⼤規模な時系列数値データの集計処理に最適化されておらず、書き込 み性能を向上させるにはシャーディングやデータ構造の最適化などの⼯夫が必要 OpenSearch を使い続ける上での課題 

データ基盤の選定条件 ● 数千万〜数億件のレコードを複雑な条件 でリアルタイムに⾼速検索 できること ● システムの特性上、集計時以外はアクセス 負荷が⾼くないため、負荷に応じて柔軟 なスケーリング ができること ● 将来的に OpenSearch で運⽤しているロ グ基盤も統合できる拡張性があること ● MCP をサポートし、AI によるコスト分析 や、将来的なコスト予測機能 を実装でき る基盤が望ましい 

© Metaps Holdings, Inc. 集計ロジックの改善 ● CUR は過去分含めデータが変動するため、請求確定⽇までは⽇毎に最新のデータを取 得した上でデータを更新 ● REPLACE PARTITION を利⽤することで、最⼩構成のインスタンスでも 50万件 4 秒台 という⾼速な書き込みを実現 

© Metaps Holdings, Inc. ARRAY JOIN を⽤いたリアルタイム検索 ● アロケーションデータを⾮正規化し、CUR レコードに埋め込む構成 ○ 正規化よりも約 2 倍速い結果に 

© Metaps Holdings, Inc. パフォーマンス測定結果 ● コストの取得、アロケーションの紐づけ、データベースへの保存は AWS Step Functions + AWS Batch で並列実⾏ OpenSearch 2,747.21 秒 x 接続数 ClickHouse 343.74 秒 x 接続数 ETL 処理時間⽐較 (50万件) 約 88% 高速化 

© Metaps Holdings, Inc. CUR データ加⼯の前処理化 ● CUR データの解析とアロケーション紐づけは処理時間がかかるため、これらの加⼯処 理を複数の Lambda に分散し並列実⾏することで、全体の処理時間を⼤幅に短縮 約 88% 高速化 OpenSearch 2,747.21 秒 x 接続数 ClickHouse 343.74 秒 x 接続数 データの加⼯: 330.07 秒 インポート: 5.79 秒 ETL 処理時間⽐較 (50万件) 

ご清聴ありがとうございました