いわゆる「俺が考えた最高のアーキテクチャ」を敢えて見送った話

「CO-LAB Tech Night vol.1 全部内製化 大阪でクラウド開発やってるで！ #1」で発表したスライドです。
https://kinto-technologies.connpass.com/event/357398/

1. いわゆる「俺が考えた最高のアーキテクチャ」 を敢えて見送った話 Platform Group 林田洋平 2025/07
2. 林田 洋平 2 • 所属部署 • PlatfromGroup / Platform Engineering Team • 主な業務 • 社内共通 Platform や共通 System の開発 • 開発チーム向けツールの開発・運用 • 趣味 • アコースティックギター、お酒（ビール・ハイボールなど） • 経歴 自社開発企業 メーカー系企業 自社開発企業 KTC PlatfromGroup 2016年 2022年 2025年
3. Index 3 • CMDB の説明 • バッチ処理の現在の構成と課題 • 課題解決のためのアーキテクチャ設計 • いわゆる「俺の考えた最高のアーキテクチャ」を敢えて見送った話 • まとめ
4. CMDB の説明
5. CMDB とは 5 • Contents Management Database (構成管理 データベース） • 社内 IT 資産の状況を一元管理 • プロダクト • ドメイン • Github リポジトリ • セキュリティ • 脆弱性
6. CMDB とは 6 • 複数のバッチ処理が日々稼働し、情報を収集 • Github リポジトリ情報 • ECR スキャン結果 • EC2 脆弱性診断結果 • EOL 情報 • etc ...
7. バッチ処理の現在の構成と課題
8. 現在の構成と課題 8 • 現在の構成 • EventBridge Rules → Run ECS Task • 全バッチがこの構成
9. 現在の構成と課題 9 • 現構成の問題点 • Fargate の Capacity 不足による起動 失敗が散発 • 「Capacity is unavailable at this time. Please try again later or in a different availability zone」 • 「現在、容量は利用できません。しば らくしてからもう一度お試しください。 または、別のアベイラビリティゾーン でお試しください。」
10. 現在の構成と課題 10 • 現在の運用 • 手動でリトライしている • 技術的負債となっている... ( ；∀；)
11. 課題解決のためのアーキテクチャ設計
12. 改善案 12 • 理想 • 自動リトライ • 技術負債の解消！ • 改善案 • Step Functions 経由で起動 するように
13. 改善案 13 • Step Functions • AWS マネージドなプラット フォーム上でワークフローの構 築が可能 • リトライ処理を柔軟に設定可能 • Interval • Max attemps • Backoff rate ...
14. Workflow 設計 14 • Workflow (State Machine) は一つ • 複数ある各バッチ処理で使用
15. Workflow 設計 15 • 入力パラメータで実行するバッチ処理 （ECS タスク定義の ARN）を指定
16. Workflow 設計 16 • 出来た構成 • シンプル • 楽勝じゃん♪
17. Workflow 設計 17 • がしかし... • それぞれのバッチ間に実は依存関係があることが判明 • バッチ処理の数は１５個 • 現在は各バッチの起動時間をずらすことにより依存関係を 解決している
18. Workflow 設計 18
19. Workflow 設計 19 • Step Functions • ワークフローを柔軟に構築可能 • 依存関係も何のその！
20. Workflow 再設計 20 • 再設計 • 依存関係のあるバッチはひとつのワークフローに纏める • まずは→の一覧から依存関係グラフを生成する
21. Workflow 再設計 21 • 出来たもの • →の３つのグループが
22. Workflow 再設計 22 • さらにスケジュールを書いてみる
23. Workflow 再設計 23 • 各グループを一つのワークフローにすれば OK？
24. Workflow 再設計 24 • 否！ • 下記のグループを例に理由を説明 • ↑のケースだと batchO のスケジュールに合わせて、毎時 ワークフローを実行する？
25. Workflow 再設計 25 • NG！ • batchN は毎時実行してはいけない • 1日1回だけ、かつ火〜土だけ • このような複雑な制約が...
26. Workflow 再設計 26 • 「俺のエンジニア魂に火が着いた...」 • この課題を最高のアーキテクチャを考えて解決したい！
27. Workflow 再設計 27 • どう解決するか？ • ↑のケースの場合、ワークフローは batchO に合わせ て毎時実行で良い
28. Workflow 再設計 28 • どう解決するか？ • ECS タスクの前に lambda 関数を挟む
29. Workflow 再設計 29 • どう解決するか？ • lambda 関数にて現在の曜日と時刻を取得 • ECS タスク実行可否(true or false)を 返却 • 分岐を定義し、true なら ECS タスク実行
30. Workflow 再設計 30 • どう解決するか？ • スケジュールはワークフローの入力パラ メータで渡す
31. Workflow 再設計 31 • どう解決するか？ • 入力パラメータの cron 式を lambda 関数で解析する
32. Workflow 再設計 32 • どう解決するか？ • 出来たフロー → • さらにこれを各ワークフローにて再利用 可能な共通ワークフローにする
33. Workflow 再設計 33 • どう解決するか？ • 共通ワークフロー化 • それを親ワークフローから呼び出す • step functions はワークフロー （state machine）のネストが可能
34. Workflow 再設計 34 • さらに • 保守性を考慮して、ワークフローの 入力パラメータは terraform でコー ドナイズ • ※ KTC では、AWS リソースの設定 の大部分を terraform を使ってコー ドナイズしております。
35. Workflow 再設計 35 • 「俺が考えた最高のアーキテクチャー！」 • 完璧やん！ • これで問題解決や！
36. Workflow 再設計 36 • と、思ったけど... • やっぱやめました...
37. いわゆる「俺の考えた最高のアーキテクチャ」を敢えて見 送った話
38. 「俺の考えた最高のアーキテクチャ」を敢えて見 送った話 38 • やめた理由 • やりたいこは出来そうだが、複雑でシンプルでない • 学習コストが高い • 初見の人が混乱し易い • AWS コンソールからバッチのスケジュールを確認したときに、全バッチが毎 時実行になってるので？ってなりそう • そもそも Step Functions 利用の時点で、他のメンバーに精通している人が少ない • そのうえさらに複雑なアーキテクチャを持ち込むのは悪手では？
39. Workflow 再々設計 39 • シンプルな設計を前提にする • 最初に提示した↓に問題をどうするか • batchN は火〜木の22:30に実行 • batchO は毎時実行
40. Workflow 再々設計 40 • batchN も毎時実行してしまう • batchN に関わらず、全てのバッチが集計系なので実行回数が増えても問題はない • 無駄なバッチ実行が増えるが、シンプルさを優先
41. Workflow 再々設計 41 • 最終的に出来た構成 • シンプルにそれぞれのバッチ用にワークフ ローを作る • スケジュールも各ワークフローに合ったもの を設定 • batchO 用ワークフロー • (毎時実行 毎時00分) • batchN 用ワークフロー • (22:30（同日） 火〜土)
42. まとめ 42 • まとめ • アーキテクチャ選定では、ときに敢えて無駄を許容してシンプルさを優 先すべきときもある • 自分だけが理解できるアーキテクチャではだめ • 出来るだけ他者にとって解り易く認知負荷の低い構成を選ぼう
43. まとめ 43 • これは、SRE (Site Reliability Engineering) の話なのか？ • いわゆる信頼性向上の話とずれている？ • Non, Non • アーキテクチャをシンプルにて認知負荷を抑えるのも信頼性向上の 一環と捉える • 信頼性とはサービスの信頼性だけではない • メンテナンス性を高めて持続性を高めるのも信頼性向上の一環
44. 44 04 本日の勉強会 18:30-18:35 開催の挨拶 18:35-18:40 • KINTO Technologies そしてOsaka Tech Lab の紹介 中村 友香 - KINTOテクノロジーズ株式会社 18:40-19:00 • Azure初心者がIaC化やってみた 逢坂 昌倫 - KINTOテクノロジーズ株式会社 19:00-19:20 •いわゆる「俺が考えた最高のアーキテクチャ」を敢えて見送った話 林田 洋平 - KINTOテクノロジーズ株式会社 19:20-19:40 • AWS Glue とDatabricksとレイクハウス 西 功一郎 - KINTOテクノロジーズ株式会社 19:40-20:10 • コードからインフラまで！生成AIで加速するクラウド開発 國政 丈力 - アマゾン ウェブ サービス ジャパン合同会社 20:10-21:20 ネットワーキング 懇親会 21:20-21:30 クロージング 21:30 終了