---
title: 大規模なメトリクス収集の仕組みをアーキテクチャ変更して得た学び
tags: 
author: [Masanori Tani](https://image.docswell.com/user/uta8a)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/YJ6W4M8ZJV.jpg?width=480
description: JJUG CCC 2026 Spring
published: May 30, 26
canonical: https://image.docswell.com/s/uta8a/KJW81E-2026-05-30-jjug-spring-2026
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/YJ6W4M8ZJV.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GJ5MQZ99J4.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/9E29PR257R.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/D7Y45DY6EM.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/VENYN6R1J8.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/Y79PRLMYE3.jpg)

事前知識
©️ Cybozu, Inc.
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/G78DWXLK7D.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/L7LMN8LPJR.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4EMYX6M2EW.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PER9NPV5J9.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/P7XQN3ZXEX.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/37K9NY897D.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LJ3WV929J5.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/8JDK8GZ8EG.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VEPK83DW78.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/27VVN4197Q.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/5JGLK1247L.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/47QYNDPREP.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/KE4WGZYQJ1.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/L71YDR6LJG.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/G7WGY1WQE2.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/4JZLXP53E3.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/YE6W4M9ZEV.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GE5MQZN9E4.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/9729PR55JR.jpg)

まとめ
©️ Cybozu, Inc.
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/DJY45DK67M.jpg)

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