考え抜いた最強の設計が、1年後果たしてどうなったのか答え合わせする

考え抜いた最強の設計が、 1年後果たしてどうなった のか答え合わせする Cybozu Tech Meetup #27 2026/06/22 谷 昌典 1

自己紹介 自己紹介 谷 昌典 GitHub, X, mixi2など @uta8a でやってます！ 2023/04 サイボウズ新卒入社 2025/03 kintoneの性能ダッシュボード開発にジョイン(兼任) 2026/04 ダッシュボードチームに異動 趣味はカメラ、音楽 インフラ寄りの話題が好きです 2

目次 今日の流れ 1. 設計したサービスの背景 → kintoneのダッシュボードについて 2. 技術的意思決定をADR風に振り返る → 選択形式で振り返り 3. うまく行ったもの、うまく行かなかったものを整理 → ADR風の振り返りから、抽象的な学びを得る 3

1. 設計したサービスの背景 ©️ Cybozu, Inc. 4

設計したサービスの背景 kintoneのダッシュボード機能の背景 性能ダッシュボード・利用状況ダッシュボード • kintoneとは？ kintoneで実現した業務システムの例(従業員名簿) • 業務改善プラットフォーム • 様々な業務システムを実現できる • →使われ方が多様 • 大規模な利用に対し、お客様の持つ不安を解消したい • この規模で社員が増えていくと大丈夫か • →時系列で性能情報が見れると現状把握に役立つ • もっと活用を推進していくために、現状が知りたい • →時系列で利用状況が分かると推進のヒントになる →kintoneのダッシュボード機能を顧客に提供 https://jp.kintone.help/k/ja/app/app_tutorial 5

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

設計したサービスの背景 kintoneのダッシュボード 3種類のダッシュボードを開発している(1つは社内向け) 6

設計したサービスの背景 アーキテクチャ(ざっくり) Neco: サイボウズのプライベートクラウド ※各コンポーネントは簡略化しています 7

設計したサービスの背景 アーキテクチャ(ざっくり) 8

設計したサービスの背景 アーキテクチャ(ざっくり) 9

2. 技術的意思決定をADR風に振り返る ©️ Cybozu, Inc. 10

技術的意思決定をADR風に振り返る 概要 • 「アーキテクチャに関わる技術的意思決定」→「1年後どうなったか？」という形式で紹介します！ • 注意点として、だいぶ簡略化しているので実際はもっと複雑な状況になっています 11

ADR#1: BFFを採用する？しない？ ©️ Cybozu, Inc. 12

ADR#1 BFFを採用するかどうか なぜ採用したいか - 複数のIdP, サービスと連携したいため メリット・デメリット - BFFを選ぶと、 - フロントエンドとバックエンドの分業がしやすい - BFFは認証とデータの整形に集中、BackendはDBへのクエリに集中 - デメリットは当時あまり見えてなかった。 まとめ 複数の他チームが持つIdP・サービスと連携できる チーム内のバックエンド・フロントエンドエンジニアで協業しやすい形のアーキテクチャ →BFFを採用 13

ADR#1 BFFを採用するかどうか – 1年後 想定通りだったこと - BFFはフロントエンド、バックエンド実装が分担しやすい - デメリットは見当たらない 想定通りじゃなかったこと - BFF 1つに対して、backend 1つ、kintone本体が接続している - データソース複数を1つのbackendで処理している - 思ったより接続するサービスが少ない 分担の様子 14

ADR#2: DBはどれにする？ ©️ Cybozu, Inc. 15

ADR#2 DB選定の話 候補 選定基準 - Amazon Timestream - クエリの同時実行に耐えられる安定性 - Prometheus - クエリでスキャンするサイズはあまり重要視しな - Aurora MySQL - Amazon Athena - Redshift い - Glueによる事前集約を想定していたため - 金額コスト - データスキーマが柔軟に変更可能 - OpenSearch →初期の決定: TimestreamとOpenSearchの併用 直近のデータをTimestreamで持ち、古いデータを集約してOpenSearchで持つ 16

ADR#2 DB選定の話 – 1年後 想定外だったこと Timestream for LiveAnalyticsが新規顧客向けサービス提供を停止 →雰囲気サービス終了に向かっている...(2025/05) →Timestream for InfluxDBはカーディナリティで難しく、リアルタ イム性をその時点である程度諦めてOpenSearch集約に振る (まだリリース前の変更だったので助かった) 想定内だったこと データスキーマが頻繁に変更される 17

ADR#3: データ収集パイプラインの設計 ©️ Cybozu, Inc. 18

ADR#3 データ収集パイプライン部分の設計 データ収集パイプラインの設計時に必要な観点 - rawデータをどういうパイプラインで変換してDBに入れるか？ ↑ ?に入るブロックとしては、入力時のバッファリング(Kinesis)/短い時間単位での集約(Firehose)/raw データ置き場(中間層1)/集約層(Glue)/集約結果のデータ置き場(中間層2)を想定していた 19

ADR#3 データ収集パイプライン部分の設計 設計時の観点 - リアルタイム性は重要視しない - リアルタイム性が必要なら、ストリーム処理が可能なApache Flinkを用いる - データ数/分間がそれなりの規模、業務時間に合わせたピーク→スケールアウト/インに対応できる安定性 - Managedサービスをなるべく選択、バッファリング層としてFirehoseを設ける - 当時は性能データだけを考えていたので、Glueの集約は時間方向の集約のみ(1分単位) 20

ADR#3 データ収集パイプライン部分の設計 – 1年後 想定通りだったこと - データ量の多さ・ピークに耐えられた 想定外だったこと - 他チームからのデータを受け取ることになった→Firehoseがvalidation層に - 時間単位集約だけでなく、unique user count処理も要件に入った→Glueで処理できた - Glueが思ったより複雑に... 複数の集約ルートに応じてパイプラインが増え続ける構造 21

ADR#4: CDKのStack、どこで切る？ ©️ Cybozu, Inc. 22

ADR#4 CDKのStackをどこで切るか CDKのStack: デプロイ単位。全部まとめて一つのStackにすると、開発時にmockをデプロイしたい時に不 要なコンポーネントもデプロイしてしまう。 以下のコンポーネントたちのどこでStackを切ると良いだろうか？ 当時の考慮ポイント: 将来的にDBは複数個できるかも？ / DBはデプロイ時間が長い / Stack間になるべく依存関係を発生させた くない / PRのプレビュー環境のように、mockをデプロイするときに不要なものはデプロイしたくない 23

ADR#4 Stack間になるべく依存関係を発生させたくない の難しさ 例えば、mockはBackend+DBを置き換えてBFFから見て透過にしたい そうすると、S3(中間層2)とOpenSearch Serverlessの間で切りたくなる 24

ADR#4 Stack間になるべく依存関係を発生させたくない の難しさ しかし、いくつか問題が出てくる - Amazon SNSを作成したとき、S3からs3:TestEventが飛ぶ - これにより、先にSNSを作成するという依存関係が発生する(この間で切りづらい) 他にも実体がない状態で権限指定したいが...など →微妙な感じで解決(緑の側にSNS、赤の側にS3からのQueueとOpenSearch Ingestionを入れる) 25

ADR#4 CDKのStackをどこで切るか – 1年後 チームで混乱する場面が何度かあった 当時は最強の切り方だと思ってたのに...！ →実際はAWSの都合に左右された苦肉の策なので、もうちょっといい方法がないか検討できたかも →特に今はDBが1つだけなので、その前提だと切り方を変えられた可能性 26

3.うまく行ったもの、うまく行かなかった ものを整理 ©️ Cybozu, Inc. 27

うまく行ったもの、うまく行かなかったものを整理 最強だと思っていた設計の答え合わせ • 当時やった〜これが最強！と思ったものは、達成感でそう思っていないか？に注意する • うまく行ったもの ADR#1 BFF や、ADR#3 パイプライン設計 はどれもシンプルでよく採用されている手法 • うまく行かなかったもの ADR#4 CDKのStack は捻り出した解決策 • とはいえ、CDKのStackの切り方はまだまだ世の中に知見がない気もする • 外部要因によって最強だと思っていたものが変わることはある • ADR#2 DB選定 は、AWSのサービス終了の気配によって変わる必要があった • その時の†最強†よりも、要件含めて変わることのできる範囲の把握を継続することが大切 28

まとめ ©️ Cybozu, Inc. 29

まとめ その時最強と感じた設計より、シンプルさや変化を大切にした方が良さそう • kintoneのダッシュボード開発で積んだ設計経験を軸に、いくつかピックアップして最強だと思った設計 がどうなったのか振り返った • 得られた教訓 • 考え抜いた複雑な方法よりもシンプルな方法の方が後々良かったりする • 想定通りには行かないので、変化できる範囲を把握することが大事(要件含めて) この次の発表もお楽しみに！ 30