オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例

Transcript

1. © 2024 Loglass Inc. 2024.10.27 　Hiroto Ryushima オニオンアーキテクチャで実現した 本質課題を解決す インフラ移行の実例 JJUG CCC 2024 Fall
2. © 2024 Loglass Inc. Profile 龍島 広人 株式会社ログラス エンジニア フォルシア株式会社にて独自検索技術を利用した 旅行会社向けの検索システム開発に従事。 同社のSaaSプロダクト立ち上げをリード。 2022年3月に株式会社ログラスへ入社。 レポーティング機能の開発を牽引し、現在は Enabling & Platform部アプリケーション基盤 チームとして集計基盤の構築やパフォーマンス改善、 アーキテクチャ設計を行っている。 Hiroto Ryushima
3. © 2024 Loglass Inc. Contents 1. テーマ概要 2. オニオンアーキテクチャと依存性逆転の原則 3. 実例： PostgreSQLからBigQueryへのデータソース切り替え 4. まとめ
4. © 2024 Loglass Inc. 01 テーマ概要
5. © 2024 Loglass Inc. オニオンアーキテクチャを採用してい プロダクトでのクエリエンジン移行の実例 01｜テーマ概要
6. © 2024 Loglass Inc. オニオンアーキテクチャを採用してい プロダクト • プロダクトのスケールによって参照機能のパフォーマンスが劣化 • 機能追加が難しい状態となってしまったため早急な対応が必要 DWHへの一部のクエリを移行 • Before: 全てRDBMS（PostgreSQL） • After: 一部処理をDWH（BigQuery）へ 01｜テーマ概要
7. © 2024 Loglass Inc. アプリケーション実装が低コストだったため 本質的な課題解決に集中 オニオンアーキテクチャで 依存性逆転の原則を適用していた恩恵 01｜テーマ概要
8. © 2024 Loglass Inc. 02 オニオンアーキテクチャと 依存性逆転の原則
9. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 オニオンアーキテクチャ の前に レイヤードアーキテクチャ
10. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャ UI Application Infrastructure ユーザとのや 取 責務 ユースケース、処理の流 のハンドリング Domain 中心とな ロジック、ビジネスルール 外部（DB, サービス）とのや 取 依 存 の 方 向
11. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの利点 責務が分離さ てお 依存関係も明確なので 複雑なアプリケーションも 保守しやすい UI Application Infrastructure Domain 依 存 の 方 向
12. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの課題 DomainがInfrastructureに 依存してしまってい UI Application Infrastructure Domain 依 存 の 方 向
13. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの課題 DomainがInfrastructureに 依存してしまってい UI Application Infrastructure Domain 依 存 の 方 向 DB, 外部サービスの変更が コアなロジックに影響してしまう
14. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの課題 コア（主要、中心）なものがコアでないものに依存してい 「システムが何を実現したいか(=Domain)」は最もコアであ Infrastructure Domain 中心とな ロジック、ビジネスルール（コア） 外部（DB, 外部サービス）とのや 取 （コアでない） 依存
15. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更ってそんなにあ ？ 歴史的に、業界では少なくとも 3 年ごとにデータ アクセス手法が変更されて います。したがって、ビジネスにとってミッション クリティカルな、健全で長寿命 のシステムでは、3 年後にはデータ アクセスを変更する必要があると予想でき ます。 引用元: The Onion Architecture : part 1, 2008,Jeffrey Parelmo
16. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更要因 • サービスの成長でパフォーマンスに課題が出る • 新技術（新DB）の登場 • 古いDBのサポートが終了する • ビジネス上コスト削減が必要になる • 外部サービスの変更、廃止（直近だと生成AIなど） • グローバル展開による法規制への対応 • …
17. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更ってそんなにあ ？ 頻繁ではないが、必ずやってく そしてコアな部分に大きな変更が必要にな
18. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 依存性逆転の原則 Dependency Inversion Principle, DIP 高レベルモジュールを低レベルモジュールに依存させない 低レベルモジュールを高レベルモジュールに依存させ （逆転） Infrastructure Domain 中心となるロジック、ビジネスルール（高レベル） 外部（DB, 外部サービス）とのやり取り（低レベル） ✕ ◯
19. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 依存性逆転の原則 Dependency Inversion Principle, DIP コアなものをコアではないものに依存させない Infrastructure Domain 中心となるロジック、ビジネスルール（コア） 外部（DB, 外部サービス）とのやり取り（コアではない） ✕ ◯
20. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 DIPでレイヤードか オニオンアーキテクチャへ UI Application Infrastructure Domain 依 存 の 方 向 Infrastructure Infrastructureを外側に持ってくる
21. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 オニオンアーキテクチャ UI Application Infrastructure Domain 依 存 の 方 向 DB, 外部サービスの変更が コアなロジックに影響を与えないので 変更が容易（柔軟性↑） コアなロジックは何にも依存せず メンテナンス、テストが容易（保守性↑）
22. © 2024 Loglass Inc. 02｜オニオンアーキテクチャと依存性逆転の原則 オニオン？ 外から並べると玉ねぎっぽい Domain Application UI Infrastructure UI Application Infrastructure Domain 依 存 の 方 向 依 存 の 方 向
23. © 2024 Loglass Inc. 03 実例 PostgreSQLか BigQueryへの データソース切 替え
24. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え
25. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え • 集計、レポーティング処理 ◦ Repositoryでデータ更新、 QueryServiceで参照するCQRS構成 ◦ データ量増加に 参照の性能に限界が見えていた 対象のシステム アプリケーション Postgres Repository Postgres QueryService PostgreSQL 更新 参照（遅い）
26. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え データソース切 替え アプリケーション Postgres Repository BigQuery QueryService データ連携 更新 参照 BigQuery 参照をBigQueryにすることで高速化を図る
27. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え データソース切 替えに必要な対応 アプリ改修 Postgres Repository BigQuery QueryService データ連携構築 更新 参照 BigQuery最適化
28. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え そ ぞ の対応にかかった時間 アプリ改修 データ連携構築 BigQuery最適化 対応期間 どの対応にどれくらい時間がかかったか
29. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 例えばこんな感じだったとした どうだ う？ アプリ改修 データ連携構築 BigQuery 最適化 対応期間
30. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 対応に ってユーザに届く価値 アプリ改修 データ連携構築 BigQuery最適化 入れたデータを早く 見れる！ レスポンスが速い！ ？
31. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 対応に ってユーザに届く価値 アプリ改修 データ連携構築 BigQuery最適化 入れたデータを早く 見れる！ レスポンスが速い！ ？ 本質的な 課題解決 本質的 ではない
32. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 悲しい時間配分 アプリ改修 データ連携構築 BigQuery 最適化 対応期間 本質ではない部分で 時間が取られている
33. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 理想的な時間配分 アプリ 改修 データ連携構築 BigQuery 最適化 対応期間も短く 本質的な課題解決に 時間をかける 本質じゃない部分は短く
34. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 実際どうだったか
35. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 実際の時間配分 アプリ改修 データ連携構築 BigQuery最適化 2.5week 6week 2.5week 1week
36. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 短期間でアプリケーション改修を実現できた要因 • 最小限で独立したアプリケーション改修 • 既存のQueryServiceへの網羅的なテストの転用
37. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 最小限で独立したアプリケーション改修 • PostgreSQLのQueryServiceと同じInterfaceを BigQuery用に実装する ◦ オニオンアーキテクチャによりInfrastructureに閉じた修正で 影響範囲が明確、限定的 • 他チームのDomain層、Application層への変更に干渉がない ◦ 同時に開発が進んでいたがコンフリクトはほぼ発生せず ◦ プロダクトの成長を止めない
38. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え QueryServiceへの網羅的なテストの転用 • 元々PostgreSQL用のQueryServiceに対して厚いテストが存在 ◦ 重要な数値計算ロジックを含むため • 同じテストケースを通すことで妥当性を持った実装と確認できた ◦ テストデータ、入力値生成ロジックもそのまま転用 ※この要素はオニオンアーキテクチャでなくても実現可能
39. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 実際の時間配分 アプリ改修 データ連携構築 BigQuery最適化 2.5week 6week 2.5week 1week ここに集中できた結果どうなったか？
40. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え BigQuery向けにデータ構造、クエリの大幅な変更 • パフォーマンス向上のため、データ構造、クエリを変更 ◦ 階層構造の持ち方を経路列挙モデルから閉包テーブルモデルに変更 ◦ それに伴いクエリも大幅に変更し、PostgreSQLとは全く違うSQLに ◦ パフォーマンスが大幅に向上 • 詳細は別記事 ◦ 列指向、行指向データベースの特性を 木構造を用いた集計クエリから理解する
41. © 2024 Loglass Inc. 03｜実例: PostgreSQLか BigQueryへのデータソース切 替え 本質課題 = パフォーマンスが悪い 集中して時間を投下し高度に解決！
42. © 2024 Loglass Inc. 04 まとめ
43. © 2024 Loglass Inc. 04｜まとめ オニオンアーキテクチャで本質的な課題解決に集中 • パフォーマンス悪化によってデータソースの変更が必須となった • オニオンアーキテクチャによってInfrastructureの変更のみで済んだ • Infrastructureに対しての厚いテストを転用できたため更に変更は容易 • 本当に解決したかった課題(パフォーマンス改善)に集中 • ユーザに対して素早く、高品質な価値提供
44. © 2024 Loglass Inc.