手が足りない！兼業データエンジニアに必要だったアーキテクチャと立ち回り

アーキテクチャConference 2025 (https://architecture-con.findy-tools.io/2025) での登壇資料です。

「データドリブン」が当たり前になった現代。クラウドやSaaSが日々進化していますが、データ基盤開発にはまだまだ泥臭い作業がつきものです。データエンジニアが1人しかいない、SREが兼業でやっている──そんなリソース不足の現場でどのようにデータ活用を推進するのか。本セッションでは、弊社サービス「Liny」で構築したログ・データ基盤について失敗談や今後の展望を添えてお話しいたします。

Transcript

1. ©Social Databank, Inc. 2025/11/21 ソーシャルデータバンク株式会社　神 光佑 手が足りない！ 兼業データエンジニアに必要だった アーキテクチャと立ち回り
2. 2 ©Social Databank, Inc. 自己紹介 神 光佑 / zinkosuke ソーシャルデータバンク株式会社 技術本部 エンジニアリング部 プラットフォーム課 課長 川下り (ラフティング) 未経験からSES (オラクルとエクセル) フリーランス freee (データ基盤チーム) ソーシャルデータバンク (SRE) 2015年 ~ 2016年 ~ 2018年 ~ 2021年 ~ 2023年 ~
3. 3 ©Social Databank, Inc. 自己紹介 神 光佑 / zinkosuke ソーシャルデータバンク株式会社 技術本部 エンジニアリング部 プラットフォーム課 課長 川下り (ラフティング) 未経験からSES (オラクルとエクセル) フリーランス freee (データ基盤チーム) ソーシャルデータバンク (SRE) 2015年 ~ 2016年 ~ 2018年 ~ 2021年 ~ 2023年 ~
4. ©Social Databank, Inc. なぜ手が足りないのか？
5. ©Social Databank, Inc. 兼業だから・1人だから
6. ©Social Databank, Inc. 兼業だから・1人だから
7. 7 ©Social Databank, Inc. 名もなきタスクで時間が溶けがち なぜ手が足りないのか？ 手オペに時間を取られがち 引き継ぎ先を確保できない データの民主化が進まない
8. ©Social Databank, Inc. 目次 いつかくる仲間に優しい設計 会社概要とプロダクト規模 データの民主化が進まない 手オペで苦しまないための設計 手オペに時間を取られがち 引き継ぎ先を確保できない データの民主化が進まない
9. ©Social Databank, Inc. 目次 いつかくる仲間に優しい設計 会社概要とプロダクト規模 データの民主化が進まない 手オペで苦しまないための設計 手オペに時間を取られがち 引き継ぎ先を確保できない データの民主化が進まない
10. ©Social Databank, Inc. 創業 2017年 9期目 従業員数 70人 ソーシャル データバンク 株式会社 会社概要
11. ©Social Databank, Inc.
12. 12 ©Social Databank, Inc. 数字で見る 8740 万人 総友だち数 21428 件 契約アカウント数 2億 6395万通 月間送信メッセージ数 ※2024年9月時点 0.61 2.10 4.62 10.10 17.21 18.99 19.73 1期 2期 3期 4期 5期 6期 7期 売上推移（億円） （OEM含む）
13. 13 ©Social Databank, Inc. • ECS ◦ サービス数 約100 (約500タスクが常駐) ◦ 1日に出るログの量 約2TB • Aurora MySQL ◦ スナップショットのサイズ 約60TB (2クラスター合計) ◦ 最大数百億レコード • DynamoDB ◦ テーブル数 約40 ◦ 最大数百億レコード (約30TB) • Elasticache Redis ◦ クラスター数 約20 システムの規模
14. 14 ©Social Databank, Inc. Linyのログ・データ基盤
15. 15 ©Social Databank, Inc. Linyのログ基盤 BugSnag導入によるログ監視効率化と エラー対応のスピードアップ https://findy-tools.io/products/bugsnag/356/220
16. ©Social Databank, Inc. 目次 いつかくる仲間に優しい設計 会社概要とプロダクト規模 データの民主化が進まない 手オペで苦しまないための設計 手オペに時間を取られがち 引き継ぎ先を確保できない データの民主化が進まない
17. 17 ©Social Databank, Inc. 手オペは突然やってくる 集計ロジック変わったので 過去分全部出し直しといて ログってどこまで遡れるの？ あるだけ集計しといてよ 2022-01-08だけデータないんで すけど？
18. 18 ©Social Databank, Inc. 手オペは突然やってくる 集計ロジック変わったので 過去分全部出し直しといて ログってどこまで遡れるの？ あるだけ集計しといてよ 2022-01-08だけデータないんで すけど？ お時間いただきます！！！
19. 19 ©Social Databank, Inc. 手オペは突然やってくる hourlyの集計処理を半年分backfillできる？
20. 20 ©Social Databank, Inc. 手オペは突然やってくる hourlyの集計処理を半年分backfillできる？ 想定外のリソース奪い合い
21. 21 ©Social Databank, Inc. 手オペは突然やってくる hourlyの集計処理を半年分backfillできる？ 想定外のリソース奪い合い 実は互換がなかった過去データ
22. 22 ©Social Databank, Inc. 手オペは突然やってくる hourlyの集計処理を半年分backfillできる？ 想定外のリソース奪い合い 実は互換がなかった過去データ 処理は成功したが結果がおかしい
23. 23 ©Social Databank, Inc. • ワークフローエンジンに依存しない • スキップ・上書きのオプションを用意する • 日付は「期間」として受け取る • 手オペミスに備える 手オペは突然やってくる 手オペで苦しまないための設計
24. 24 ©Social Databank, Inc. • 任意のタスクを個別で実行できるように ◦ 1つのタスクで1つのことをやる ◦ 「ここだけ直したい」を実現 • Use Caseを切り離す ワークフローエンジンに依存しない 手オペで苦しまないための設計
25. 25 ©Social Databank, Inc. ワークフローエンジンに依存しない 手オペで苦しまないための設計
26. 26 ©Social Databank, Inc. ワークフローエンジンに依存しない 手オペで苦しまないための設計
27. 27 ©Social Databank, Inc. ワークフローエンジンに依存しない 手オペで苦しまないための設計 UIから・RunTaskから・ローカルから 任意の場所で実行できる
28. 28 ©Social Databank, Inc. • 再実行を前提にする • 冪等性があっても、無駄な再計算は避ける • 上書き対象を指定可能にする • 取り直せないデータは上書き禁止を明示する スキップ・上書きのオプションを用意する 手オペで苦しまないための設計
29. 29 ©Social Databank, Inc. スキップ・上書きのオプションを用意する 手オペで苦しまないための設計
30. 30 ©Social Databank, Inc. スキップ・上書きのオプションを用意する 手オペで苦しまないための設計 ほんの数行で効果は絶大
31. 31 ©Social Databank, Inc. 日付は「期間」として受け取る • 日付の条件はfromとtoで指定する • 以下のような条件は柔軟性が低下 ◦ dt = ‘YYYY-MM-DD’ のような等価比較 ◦ INTERVAL ‘1’ HOUR のような固定の期間 • 一括処理しやすくする (常に正解とは限らない) 手オペで苦しまないための設計
32. 32 ©Social Databank, Inc. ※ datehourの形式はYYYY/MM/DD/HH 日付は「期間」として受け取る 手オペで苦しまないための設計
33. 33 ©Social Databank, Inc. 日付は「期間」として受け取る 手オペで苦しまないための設計 ほんの数行で効果は絶大
34. 34 ©Social Databank, Inc. • 最小権限の手オペ用ロールを用意する • 「もう取れないデータ」を保護する ◦ 取り直せないデータはバケットを分離 ◦ バージョニング • よくある作業はワークフローとして用意する 手オペミスに備える 手オペで苦しまないための設計
35. 35 ©Social Databank, Inc. 手オペミスに備える 手オペで苦しまないための設計 ミスを減らす運用設計・実装と バックアップで万一に備える
36. ©Social Databank, Inc. 目次 いつかくる仲間に優しい設計 会社概要とプロダクト規模 データの民主化が進まない 手オペで苦しまないための設計 手オペに時間を取られがち 引き継ぎ先を確保できない データの民主化が進まない
37. 37 ©Social Databank, Inc. 引き継ぎ先を確保できない スキルセットが違いすぎて 社内で勧誘しづらい... どうせ一人だし 自分がやりやすければいっか
38. 38 ©Social Databank, Inc. 引き継ぎ先を確保できない スキルセットが違いすぎて 社内で勧誘しづらい... どうせ一人だし 自分がやりやすければいっか (事実)
39. 39 ©Social Databank, Inc. • データエンジニア経験者は自分だけ • Python経験者は社内で数人 • AWSを日常的に触っていないメンバーも多い • 自分を含め、Kubernetes本番運用経験はない • いつか来る仲間も、おそらく兼業になる 私の状況はこんな感じでした 引き継ぎ先を確保できない
40. 40 ©Social Databank, Inc. • 「手オペで苦しまないための設計」が活きる！ ◦ 1つのコマンドとして実装できる • シンプルなワークフローエンジンを選ぶ • 開発がローカルで完結しない問題への対応 いつかくる仲間に優しい設計 覚えることをできるだけ減らす
41. 41 ©Social Databank, Inc. Digdagを選んだ理由 いつかくる仲間に優しい設計 yaml / シンプル json / サーバーレス 全部Python / 高機能
42. 42 ©Social Databank, Inc. Digdagを選んだ理由 いつかくる仲間に優しい設計 選ばれました オレ用途違くない？ 自由度、学習コストが高い
43. 43 ©Social Databank, Inc. 開発がローカルで完結しない問題への対応 • クラウド環境を全く使わずに開発は難しい • 手元のコンテナからAWSを触る？ ◦ 環境の切り替えを楽にしたい • 開発・検証環境は有限 ◦ 環境の譲り合いによる待ち時間を避けたい いつかくる仲間に優しい設計
44. 44 ©Social Databank, Inc. コンテナからAWS見ましょう いつかくる仲間に優しい設計
45. 45 ©Social Databank, Inc. コンテナからAWS見ましょう いつかくる仲間に優しい設計
46. 46 ©Social Databank, Inc. Merge Compose filesで環境を明示する いつかくる仲間に優しい設計
47. 47 ©Social Databank, Inc. Merge Compose filesで環境を明示する いつかくる仲間に優しい設計
48. 48 ©Social Databank, Inc. Merge Compose filesで環境を明示する いつかくる仲間に優しい設計 「環境の切り替え」 で覚えることを減らす
49. 49 ©Social Databank, Inc. 実験用データベースを用意する いつかくる仲間に優しい設計
50. 50 ©Social Databank, Inc. dbtのprofileで環境を明示する いつかくる仲間に優しい設計
51. 51 ©Social Databank, Inc. dbtのテーブル名にプレフィックスをつける いつかくる仲間に優しい設計 get_custom_alias.sql で検索
52. 52 ©Social Databank, Inc. dbtのテーブル名にプレフィックスをつける いつかくる仲間に優しい設計 検証のために覚えることを減らす
53. ©Social Databank, Inc. 目次 いつかくる仲間に優しい設計 会社概要とプロダクト規模 データの民主化が進まない 手オペで苦しまないための設計 手オペに時間を取られがち 引き継ぎ先を確保できない データの民主化が進まない
54. 54 ©Social Databank, Inc. • 基盤がある程度整ったら「対人」がメイン ◦ 利用者に伴走してデータの価値を体感してもら うことが重要 • 要望が多い == データが活用されている！ • 最終的にはデータのセルフサービス化 ◦ 多様なデータの出口 理想 データの民主化は永遠に
55. 55 ©Social Databank, Inc. • 基盤がある程度整ったら「対人」がメイン ◦ 利用者に伴走してデータの価値を体感してもら うことが重要 • 要望が多い == データが活用されている！ • 最終的にはデータのセルフサービス化 ◦ 多様なデータの出口 現実 データの民主化は永遠に 手が足りませんでした
56. 56 ©Social Databank, Inc. • 存在のアピールとSQL書ける人口を増やす • BIとしてのスプレッドシートを受け入れる ◦ “スプシ運用”のコストを下げる • Redashの先のBIを決める (WIP) • メタデータで生成AIに備える 手が足りないなりにできることは？ データの民主化は永遠に
57. 57 ©Social Databank, Inc. 存在のアピールとSQL書ける人口を増やす データの民主化は永遠に
58. 58 ©Social Databank, Inc. 存在のアピールとSQL書ける人口を増やす データの民主化は永遠に
59. 59 ©Social Databank, Inc. 存在のアピールとSQL書ける人口を増やす データの民主化は永遠に 「気になったらSQL書く」 を当たり前にしていく
60. 60 ©Social Databank, Inc. • セールスチームは多少リッチなBIよりスプレッド シートを求めている (説) • 自由度の高さは魅力 BIとしてのスプレッドシートを受け入れる データの民主化は永遠に このCSV、毎週出してほしいです！
61. 61 ©Social Databank, Inc. Redashのクエリ結果をスプシに連携する データの民主化は永遠に Redash v10.1.0 を改造しました
62. 62 ©Social Databank, Inc. Redashのクエリ結果をスプシに連携する データの民主化は永遠に
63. 63 ©Social Databank, Inc. Redashのクエリ結果をスプシに連携する データの民主化は永遠に データ出しにかかるコストを削減できた
64. 64 ©Social Databank, Inc. • BIを変えるだけではデータは民主化されない ◦ 見た目や細かな使い心地は重要 ◦ 権限管理 • AIとの親和性を考えていきたい ◦ SQLを書かない世界 Redashの先のBIが決まらない データの民主化は永遠に
65. 65 ©Social Databank, Inc. 使われなかったQuickSight データの民主化は永遠に 圧倒的に推進活動が不足していた Quick Suiteを触ろう
66. 66 ©Social Databank, Inc. 一部で活用されているGrafana データの民主化は永遠に
67. 67 ©Social Databank, Inc. • メタデータ拡充は必須 ◦ カラムの説明だけではもう足りない ◦ ドキュメントやコードベースも管理の対象 • メタデータを集約し、人間や生成AIが簡単に使え るハブが必要 ◦ SageMaker(旧Datazone)？Openmetadata？ メタデータで生成AIに備える データの民主化は永遠に
68. ©Social Databank, Inc. まとめ
69. 69 ©Social Databank, Inc. まとめ ★★★★★　ワークフローエンジンに依存しない ★★★★☆　スキップ・上書きのオプションを用意する ★★★★☆　日付は「期間」として受け取る ★★★★★　手オペミスに備える ★★☆☆☆　シンプルなワークフローエンジンを選ぶ ★★★☆☆　Merge Compose filesで環境を明示する ★★★★☆　実験用データベースを用意する ★★★☆☆　dbtのprofileで環境を明示する ★★★☆☆　dbtのテーブル名にプレフィックスをつける ★★★★★　存在のアピールとSQL書ける人口を増やす ★★★☆☆　BIとしてのスプレッドシートを受け入れる ★★☆☆☆　Redashのクエリ結果をスプシに連携する ★★★★☆　メタデータで生成AIに備える 手オペで苦しまないための設計 いつかくる仲間に優しい設計 データの民主化は永遠に
70. 70 ©Social Databank, Inc. • 「手が足りない！」状態で運用を破綻させないた めの設計や仕組みをご紹介 ◦ 何かしらご参考になるものがあれば嬉しいです • 「人」の問題になってからが本番...！ まとめ
71. ©Social Databank, Inc.