ClickHouse活用によるパフォーマンス改善について

Transcript

1. ClickHouse 活⽤によるパフォーマンス改善について 2025/12/15 Naomichi Yamakita
2. © Metaps Holdings, Inc. ⾃⼰紹介 ベトナム‧ハノイでのオフショア事業⽴ち上げからキャリアをスタートし、 アプリケーション開発からマネジメントまでを経験 2015 年に当社参画。徐々にクラウドインフラにも携わり、現在は横断的な テックリードや SRE チーフエンジニアとして従事 「AWS DevDay Tokyo」登壇、「Amazon Web Services ブログ」、 「builders.flash」寄稿、「Community Builder」メンバーなど 昨年より SRE のためのダッシュボード「srest」プロダクトオーナーを兼任 ⼭北 尚道 株式会社メタップスホールディングス srest プロダクトオーナー 兼 SRE マネジャー Naomichi Yamakita ＠sre_yamakita 2
3. srest の概要
4. © Metaps Holdings, Inc. srest の紹介
5. FinOps とは • FinOps = Finance + DevOps • 組織全体でクラウドコストの可視化‧最 適化‧管理を継続的に⾏う⽂化的プラク ティス • FinOps がもたらす価値 ◦ クラウドコストの透明性向上 ◦ 無駄なリソースの削減 ◦ 予算管理とコスト予測 ◦ チームによる⾃律的なコスト分析 ◦ クラウド投資の ROI 向上
6. srest は SRE チームから⽣まれたプロダクト • 社内外含め、複数のプロダクトを SRE チームが横断して管理 • 元々はコストの可視化ではなく、AWS を 始めとした様々なサービスから通知され るイベントログを⼀元的に管理するダッ シュボードとして内製で開発した • srest = SRE + Rest (SRE を休ませる) とい う造語 • 2024 年 9 ⽉ ⼀般リリース
7. © Metaps Holdings, Inc. コスト可視化へのシフトチェンジ • AWS を横断的に管理する上で、各 プロダクトの運⽤にかかるコストの可視化 が求め られる • AWS 請求アカウントでアカウントごとのコストデータは確認できるが、別の Organization のコストを⾒るにはアカウントの切り替え作業が発⽣してしまう
8. © Metaps Holdings, Inc. プロトタイプから⼀般公開へ • AWS のコストを可視化するため、Cost Explorer API ベースでプロトタイプを実装 • データベースにはログ基盤でも採⽤している OpenSearch Service をそのまま利⽤ ◦ Cost Explorer API は可変の JSON データを返すため、OpenSearch と相性が良 かった • コスト可視化の需要が⾼まり、より⾼度な分析フォーマットとして CUR 2.0 (Cost and Usage Report 2.0) をサポート ◦ 初期フェーズは既存の OpenSearch 基盤を活⽤し、迅速なリリースを優先
9. © Metaps Holdings, Inc. 2025 年 6 ⽉ 名古屋市様で正式導⼊、11 ⽉に NEC 様との業務提携を発表
10. © Metaps Holdings, Inc. 名古屋市様における AWS コスト可視化の課題 ガバメントクラウド という背景 • 政府が⾃治体向けに提供するクラウドサービス利⽤環境。全国の⾃治体は 2025 年度 末までに基幹業務システム (住⺠記録、税務などの業務) を標準化し、クラウドに移⾏ することが求められている • 名古屋市様では クラウド基盤に AWS を採⽤
11. © Metaps Holdings, Inc. ガバメントクラウドにおけるコスト可視化の課題 ガバメントクラウド環境下では、⾃治体は請求アカウントにアクセスできないため、デジ タル庁からの請求書では詳細な内訳が把握できない ⾃治体 デジタル庁 ❌ 請求の内訳が分からない ❓ ❓ 按分入力 運用 請求書の 発送 運⽤補助 事業者 GCAS
12. © Metaps Holdings, Inc. 特筆すべき機能 - アロケーション AWS のコストを任意のグループに分類‧按分する機能 コスト配布タグに加え、サービス名や ARN (Amazon Resource Name)、 使⽤タイプ (UsageType) を⽤いたリソース按分に対応
13. ClickHouse 導⼊による パフォーマンス改善
14. © Metaps Holdings, Inc. • 現在の構成はログ基盤にコスト機能を後付けした形となっており、⼤量の数値データ を扱う コスト分析には最適化されていない • CUR の ETL 処理がボトルネックとなっており、処理時間の増加が顕著なため、スケー ラビリティを確保するデータ基盤の再設計 が急務 システム⾯の課題
15. © Metaps Holdings, Inc. コストの取得から保存までの流れ
16. © Metaps Holdings, Inc. • ⼀貫性のあるスキーマ。固定の列セット (125 フィールド) を提供 • Data Exports 機能により、指定した S3 バケットに少なくとも 1 ⽇ 1 回以上更新 • レコード単位で ⼀意性を持つキーはない • 1 ヶ⽉あたりのレコード量は数⼗万〜数百万件 (使い⽅による) • CUR のデータは 過去分含め更新が発⽣ する CUR 2.0 (Cost and Usage Report) の仕様
17. アロケーション仕様 • CUR の各レコードに対して、ダッシュ ボードで設定されたアロケーションルー ル (タグ、サービス、使⽤タイプなど) を 評価 • マッチしたルールに基づき、レコードごと にビューと按分⽐率を紐づける • ダッシュボードでは ビュー単位でコスト を集計し、組織やシステム別の正確なコス ト可視化を実現
18. © Metaps Holdings, Inc. • CUR のデータは請求確定まで変動するものの、暫定値を常にダッシュボード上で可視 化する必要がある • AWS の請求⾦額は毎⽉ 1〜5 ⽇に確定するため、毎⽉ 6 ⽇には前⽉分の請求確定⾦額 を可視化 する必要がある ◦ AWS アカウントごとに最新の CUR データを再取得し、アロケーションの再計算 を含め、数千万から数億レコードにわたる前⽉分のデータを⾼速に書き換える必 要がある スケーラビリティ要件
19. © Metaps Holdings, Inc. • ログの基盤として OpenSearch は扱いやすいが、サーバーを安定稼働させる上では維 持コストが⾼い ◦ 商⽤環境は マスターノード x 3 + データノード x 2 台以上の冗⻑化 が推奨 • OpenSearch は⼤規模な時系列数値データの集計処理に最適化されておらず、書き込 み性能を向上させるにはシャーディングやデータ構造の最適化などの⼯夫が必要 OpenSearch を使い続ける上での課題
20. データ基盤の選定条件 • 数千万〜数億件のレコードを複雑な条件 でリアルタイムに⾼速検索 できること • システムの特性上、集計時以外はアクセス 負荷が⾼くないため、負荷に応じて柔軟 なスケーリング ができること • 将来的に OpenSearch で運⽤しているロ グ基盤も統合できる拡張性があること • MCP をサポートし、AI によるコスト分析 や、将来的なコスト予測機能 を実装でき る基盤が望ましい
21. © Metaps Holdings, Inc. 集計ロジックの改善 • CUR は過去分含めデータが変動するため、請求確定⽇までは⽇毎に最新のデータを取 得した上でデータを更新 • REPLACE PARTITION を利⽤することで、最⼩構成のインスタンスでも 50万件 4 秒台 という⾼速な書き込みを実現
22. © Metaps Holdings, Inc. ARRAY JOIN を⽤いたリアルタイム検索 • アロケーションデータを⾮正規化し、CUR レコードに埋め込む構成 ◦ 正規化よりも約 2 倍速い結果に
23. © Metaps Holdings, Inc. パフォーマンス測定結果 • コストの取得、アロケーションの紐づけ、データベースへの保存は AWS Step Functions + AWS Batch で並列実⾏ OpenSearch 2,747.21 秒 x 接続数 ClickHouse 343.74 秒 x 接続数 ETL 処理時間⽐較 (50万件) 約 88% 高速化
24. © Metaps Holdings, Inc. CUR データ加⼯の前処理化 • CUR データの解析とアロケーション紐づけは処理時間がかかるため、これらの加⼯処 理を複数の Lambda に分散し並列実⾏することで、全体の処理時間を⼤幅に短縮 約 88% 高速化 OpenSearch 2,747.21 秒 x 接続数 ClickHouse 343.74 秒 x 接続数 データの加⼯: 330.07 秒 インポート: 5.79 秒 ETL 処理時間⽐較 (50万件)
25. ご清聴ありがとうございました