大規模なメトリクス収集の仕組みをアーキテクチャ変更して得た学び

大規模なメトリクス収集の仕組みを アーキテクチャ変更して得た学び 2026-05-30 JJUG CCC 2026 Spring サイボウズ株式会社 谷 昌典 1

自己紹介 自己紹介 谷 昌典 GitHub, X, mixi2など @uta8a でやってます！ 2023/04 サイボウズ新卒入社 2025/03 kintoneのダッシュボード開発に兼任でジョイン 2026/04 ダッシュボード開発100%で働き始める 趣味: カメラ(オールドレンズ)、音楽(ヨルシカが好き) 2

目次 • この発表で伝えたい学び • 事前知識 • 背景 • メトリクスを扱うアーキテクチャの基礎 • アーキテクチャを変更するまでの流れ ←メイン！ • 結果どうなったのか • まとめ →実際に起きたストーリーを通じて、学びを得た背景を具体的に理解するねらい 3

この発表で伝えたい学び ©️ Cybozu, Inc. 4

この発表で伝えたい学び • 変わりゆく条件に適したアーキテクチャ選定を行う上で得た学び • 時間が経つにつれてプロダクトに求められるものが変化する。アーキテクチャもそれに応じて変えていく • 大規模なデータを扱う上で得た学び • メトリクスの取得対象にかかる負荷を考える • リソースを要する処理は外部にオフロードする 5

事前知識 ©️ Cybozu, Inc. 6

背景: そもそもどんなサービスのアーキテクチャか？ 今回の対象とするデータはkintoneの性能データ • kintoneとは？ kintoneで実現した業務システムの例(従業員名簿) • 業務改善プラットフォーム • 様々な業務システムを実現できる • →使われ方が多様 • 大規模な利用に対し、お客様の持つ不安を解消したい • この規模で社員が増えていくと大丈夫か • →時系列で性能情報が見れると現状把握に役立つ →kintoneの性能が分かるダッシュボードを顧客に提供 https://jp.kintone.help/k/ja/app/app_tutorial 7

• https://jp.kintone.help/k/ja/app/app_tutorial

背景: そもそもどんなサービスのアーキテクチャか？ 顧客からは性能は「レスポンス速度」として現れる →リクエストの処理時間等を表示 開発環境のダッシュボード 8

メトリクスを扱うアーキテクチャの基礎 • データETLアーキテクチャに近い構成 • 今回のプロダクト特有の観点 • イベントを扱うことが少なく、リクエストが大量に来るためバッファや集約(Aggregation)は必須 • リアルタイム性に関しては、1時間前くらいのデータなら見える、くらいが求められている 9

ここまでのまとめ • kintoneというSaaSは多様な使われ方をするので、大規模利用における顧客の不安を軽減したい • →性能情報を可視化する性能ダッシュボードを作って、現状把握に役立てる • 性能ダッシュボードは、リクエストにかかった処理時間等を扱う • データ量は多い(利用顧客は42,000社) • 見たい粒度も細かい(細かいところで1分単位のグラフ) • 大規模データかつ細かい粒度を扱う • メトリクスを扱うアーキテクチャの紹介。今回はPipeline周辺の話がメイン • この後の具体例で、要素を意識して見ていくと変更理由の理解の助けになる 10

アーキテクチャを変更するまでの流れ メイン！ ©️ Cybozu, Inc. 11

ざっくりとしたタイムライン 12

一部提供開始 最初の一部顧客向け実装時の目的 • リクエスト数、レイテンシーを集計して時系列グラフで出す部分の技術検証 • どの粒度の集計間隔なら大丈夫か • 最小コストで顧客からのフィードバックを得る • 価値があるかどうかを最小コストで検証したい →これらを満たすように設計 13

一部提供開始 当時、一部顧客に提供した実装 14

一部提供開始 当時、一部顧客に提供した実装の中の、kintone上のコンポーネント 15

補足: Filter, Micrometerについて Filter: Servletの仕様で定義されている仕組み ・リクエストがServletに届く前後に共通処理を挟める ・認証、ログ出力など Micrometer: メトリクス計測のライブラリ ・Registry経由で監視バックエンドに送信可能 16

課題 「一般提供に向けて、適用範囲の拡大をしていきたい！」 実際に作ってみて分かったこと • どうやらダッシュボード機能は価値がありそうだ、ということが分かった • 一般提供するにあたり、課題が出てきた • 本体コンポーネントでのメモリ使用量の増大 • レイテンシへの影響 • Filter内で取ることのできる手段が限られている 17

一般提供にあたって出てきた課題 18

一般提供にあたって出てきた課題の解決 • 検討した解決策 • 1: Filter+Micrometer+Publisherの仕組みの改善 • Registryを用いてインメモリをやめるなど • 2: 本体からは単にログを出すことにして、本体とは別の場所で集約処理を行う • 「2: 本体からは単にログを出すことにして、本体とは別の場所で集約処理を行う」に決定 • 本体に集約の仕組みがくっついていると、どうしてもスケールに不安が残る • 全顧客の全リクエストを処理できる、安定してスケールする設計 • kintone本体に影響が出るリスクより、作り直しのコストを取った 19

一般提供に向けて作り直したアーキテクチャ Pipelineの大部分がAWS側に移動 20

一般提供に向けて作り直したアーキテクチャ AWS部分の詳細 - 集約処理がkintone本体からAWS側のGlueに移動した - 本体に負荷がかからず、集約等の処理の自由度の高いアーキテクチャが組めた 21

結果どうなったのか ©️ Cybozu, Inc. 22

新しいアーキテクチャで一般提供した結果 - 提供対象の拡大に成功 - 半年以上運用していて、数億ドキュメントのデータがOpenSearchに保存されている - 旧アーキテクチャもクローズに向けて動いている - 半年ほど並行運用していた 課題はどうなったのか？ 1. 本体のメモリ増→本体影響なくスケールできた 2. 処理時間への影響→影響は出てない 3. Filter内の処理の自由度→AWSのサービスを利用することでPipelineの自由度が上がった 23

今回の経験から得た学び • アーキテクチャは制約により定まる。その時にあった最適な形に変化し続けていく • 最初から新アーキテクチャでやっていたら価値提供が遅くなり、検証できなかったかもしれない • 当時の最適なアーキテクチャを組み、価値があると分かったら一般提供に合わせてアーキテクチャを変更する、 という流れは良かった • 大量データを扱う上では、以下の2点が重要 • メトリクス取得対象(本体)への負荷を考えてデータを取得する • できるだけ処理は外部で行う 24

まとめ ©️ Cybozu, Inc. 25

まとめ 我々のチームが経験したストーリーの共有から、以下の2つの学びが実感できてたら嬉しいです！ • 変わりゆく条件に適したアーキテクチャ選定を行う上で得た学び • 時間が経つにつれてプロダクトに求められるものが変化する。アーキテクチャもそれに応じて変えていく • 大規模なメトリクスを扱う上で得た学び • メトリクスの取得対象にかかる負荷を考える • リソースを要する処理は外部にオフロードする 参考文献 • https://docs.spring.io/spring-framework/reference/web/webmvc/filters.html#page-title • SpringのFilterに関するドキュメント 26

• https://docs.spring.io/spring-framework/reference/web/webmvc/filters.html#page-title