Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
Search
Hiroto Ryushima
October 27, 2024
Technology
4
610
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
Hiroto Ryushima
October 27, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
入門『状態』#kaigionrails / "state" for beginners with Rails
shinkufencer
1
400
作って理解する RDBMSのしくみ
ydah
7
640
Databricksで構築する初めての複合AIシステム - ML15min
taka_aki
2
1.3k
LeSS Yoake 2024 スポンサーセッション
riki_hiraoka
0
250
Jamstack でリニューアルするグリーグループのメディア
gree_tech
PRO
1
150
dbt-coreで実現するCore DataMartsのデータモデリング〜dbt編〜 / Core DataMarts Modeling with dbt-core
i125
0
320
フェンリルの SwiftUI の研修を覗いてみる / Fenrir SwiftUI Training
studio_rookery
0
170
クラシルの現在とこれから
am1157154
1
110
VPoE Meetup Vol.1 VPoEとして実践してきたことと反省点
coconala_engineer
2
210
Java x Spring Boot Warm up
kazu_kichi_67
2
190
Why and Why not of enabling swap in Kubernetes
hwchiu
0
380
Data Migration on Rails
ohbarye
4
740
Featured
See All Featured
Embracing the Ebb and Flow
colly
84
4.4k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
270
Side Projects
sachag
452
42k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
A designer walks into a library…
pauljervisheath
202
24k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
A better future with KSS
kneath
237
17k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Visualization
eitanlees
143
15k
Transcript
© 2024 Loglass Inc. 2024.10.27 Hiroto Ryushima オニオンアーキテクチャで実現した 本質課題を解決す インフラ移行の実例
JJUG CCC 2024 Fall
© 2024 Loglass Inc. Profile 龍島 広人 株式会社ログラス エンジニア フォルシア株式会社にて独自検索技術を利用した
旅行会社向けの検索システム開発に従事。 同社のSaaSプロダクト立ち上げをリード。 2022年3月に株式会社ログラスへ入社。 レポーティング機能の開発を牽引し、現在は Enabling & Platform部アプリケーション基盤 チームとして集計基盤の構築やパフォーマンス改善、 アーキテクチャ設計を行っている。 Hiroto Ryushima
© 2024 Loglass Inc. Contents 1. テーマ概要 2. オニオンアーキテクチャと依存性逆転の原則 3.
実例: PostgreSQLからBigQueryへのデータソース切り替え 4. まとめ
© 2024 Loglass Inc. 01 テーマ概要
© 2024 Loglass Inc. オニオンアーキテクチャを採用してい プロダクトでのクエリエンジン移行の実例 01|テーマ概要
© 2024 Loglass Inc. オニオンアーキテクチャを採用してい プロダクト • プロダクトのスケールによって参照機能のパフォーマンスが劣化 • 機能追加が難しい状態となってしまったため早急な対応が必要
DWHへの一部のクエリを移行 • Before: 全てRDBMS(PostgreSQL) • After: 一部処理をDWH(BigQuery)へ 01|テーマ概要
© 2024 Loglass Inc. アプリケーション実装が低コストだったため 本質的な課題解決に集中 オニオンアーキテクチャで 依存性逆転の原則を適用していた恩恵 01|テーマ概要
© 2024 Loglass Inc. 02 オニオンアーキテクチャと 依存性逆転の原則
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 オニオンアーキテクチャ の前に レイヤードアーキテクチャ
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャ UI Application Infrastructure ユーザとのや
取 責務 ユースケース、処理の流 のハンドリング Domain 中心とな ロジック、ビジネスルール 外部(DB, サービス)とのや 取 依 存 の 方 向
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの利点 責務が分離さ てお 依存関係も明確なので 複雑なアプリケーションも
保守しやすい UI Application Infrastructure Domain 依 存 の 方 向
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの課題 DomainがInfrastructureに 依存してしまってい UI Application
Infrastructure Domain 依 存 の 方 向
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの課題 DomainがInfrastructureに 依存してしまってい UI Application
Infrastructure Domain 依 存 の 方 向 DB, 外部サービスの変更が コアなロジックに影響してしまう
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 レイヤードアーキテクチャの課題 コア(主要、中心)なものがコアでないものに依存してい 「システムが何を実現したいか(=Domain)」は最もコアであ Infrastructure Domain
中心とな ロジック、ビジネスルール(コア) 外部(DB, 外部サービス)とのや 取 (コアでない) 依存
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更ってそんなにあ ? 歴史的に、業界では少なくとも 3
年ごとにデータ アクセス手法が変更されて います。したがって、ビジネスにとってミッション クリティカルな、健全で長寿命 のシステムでは、3 年後にはデータ アクセスを変更する必要があると予想でき ます。 引用元: The Onion Architecture : part 1, 2008,Jeffrey Parelmo
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更要因 • サービスの成長でパフォーマンスに課題が出る •
新技術(新DB)の登場 • 古いDBのサポートが終了する • ビジネス上コスト削減が必要になる • 外部サービスの変更、廃止(直近だと生成AIなど) • グローバル展開による法規制への対応 • …
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 DB, 外部サービスの変更ってそんなにあ ? 頻繁ではないが、必ずやってく そしてコアな部分に大きな変更が必要にな
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 依存性逆転の原則 Dependency Inversion Principle, DIP
高レベルモジュールを低レベルモジュールに依存させない 低レベルモジュールを高レベルモジュールに依存させ (逆転) Infrastructure Domain 中心となるロジック、ビジネスルール(高レベル) 外部(DB, 外部サービス)とのやり取り(低レベル) ✕ ◯
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 依存性逆転の原則 Dependency Inversion Principle, DIP
コアなものをコアではないものに依存させない Infrastructure Domain 中心となるロジック、ビジネスルール(コア) 外部(DB, 外部サービス)とのやり取り(コアではない) ✕ ◯
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 DIPでレイヤードか オニオンアーキテクチャへ UI Application Infrastructure
Domain 依 存 の 方 向 Infrastructure Infrastructureを外側に持ってくる
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 オニオンアーキテクチャ UI Application Infrastructure Domain
依 存 の 方 向 DB, 外部サービスの変更が コアなロジックに影響を与えないので 変更が容易(柔軟性↑) コアなロジックは何にも依存せず メンテナンス、テストが容易(保守性↑)
© 2024 Loglass Inc. 02|オニオンアーキテクチャと依存性逆転の原則 オニオン? 外から並べると玉ねぎっぽい Domain Application UI
Infrastructure UI Application Infrastructure Domain 依 存 の 方 向 依 存 の 方 向
© 2024 Loglass Inc. 03 実例 PostgreSQLか BigQueryへの データソース切 替え
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え • 集計、レポーティング処理
◦ Repositoryでデータ更新、 QueryServiceで参照するCQRS構成 ◦ データ量増加に 参照の性能に限界が見えていた 対象のシステム アプリケーション Postgres Repository Postgres QueryService PostgreSQL 更新 参照(遅い)
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え データソース切 替え
アプリケーション Postgres Repository BigQuery QueryService データ連携 更新 参照 BigQuery 参照をBigQueryにすることで高速化を図る
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え データソース切 替えに必要な対応
アプリ改修 Postgres Repository BigQuery QueryService データ連携構築 更新 参照 BigQuery最適化
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え そ ぞ
の対応にかかった時間 アプリ改修 データ連携構築 BigQuery最適化 対応期間 どの対応にどれくらい時間がかかったか
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 例えばこんな感じだったとした どうだ
う? アプリ改修 データ連携構築 BigQuery 最適化 対応期間
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 対応に ってユーザに届く価値
アプリ改修 データ連携構築 BigQuery最適化 入れたデータを早く 見れる! レスポンスが速い! ?
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 対応に ってユーザに届く価値
アプリ改修 データ連携構築 BigQuery最適化 入れたデータを早く 見れる! レスポンスが速い! ? 本質的な 課題解決 本質的 ではない
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 悲しい時間配分 アプリ改修
データ連携構築 BigQuery 最適化 対応期間 本質ではない部分で 時間が取られている
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 理想的な時間配分 アプリ
改修 データ連携構築 BigQuery 最適化 対応期間も短く 本質的な課題解決に 時間をかける 本質じゃない部分は短く
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 実際どうだったか
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 実際の時間配分 アプリ改修
データ連携構築 BigQuery最適化 2.5week 6week 2.5week 1week
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 短期間でアプリケーション改修を実現できた要因 •
最小限で独立したアプリケーション改修 • 既存のQueryServiceへの網羅的なテストの転用
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 最小限で独立したアプリケーション改修 •
PostgreSQLのQueryServiceと同じInterfaceを BigQuery用に実装する ◦ オニオンアーキテクチャによりInfrastructureに閉じた修正で 影響範囲が明確、限定的 • 他チームのDomain層、Application層への変更に干渉がない ◦ 同時に開発が進んでいたがコンフリクトはほぼ発生せず ◦ プロダクトの成長を止めない
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え QueryServiceへの網羅的なテストの転用 •
元々PostgreSQL用のQueryServiceに対して厚いテストが存在 ◦ 重要な数値計算ロジックを含むため • 同じテストケースを通すことで妥当性を持った実装と確認できた ◦ テストデータ、入力値生成ロジックもそのまま転用 ※この要素はオニオンアーキテクチャでなくても実現可能
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 実際の時間配分 アプリ改修
データ連携構築 BigQuery最適化 2.5week 6week 2.5week 1week ここに集中できた結果どうなったか?
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え BigQuery向けにデータ構造、クエリの大幅な変更 •
パフォーマンス向上のため、データ構造、クエリを変更 ◦ 階層構造の持ち方を経路列挙モデルから閉包テーブルモデルに変更 ◦ それに伴いクエリも大幅に変更し、PostgreSQLとは全く違うSQLに ◦ パフォーマンスが大幅に向上 • 詳細は別記事 ◦ 列指向、行指向データベースの特性を 木構造を用いた集計クエリから理解する
© 2024 Loglass Inc. 03|実例: PostgreSQLか BigQueryへのデータソース切 替え 本質課題 =
パフォーマンスが悪い 集中して時間を投下し高度に解決!
© 2024 Loglass Inc. 04 まとめ
© 2024 Loglass Inc. 04|まとめ オニオンアーキテクチャで本質的な課題解決に集中 • パフォーマンス悪化によってデータソースの変更が必須となった • オニオンアーキテクチャによってInfrastructureの変更のみで済んだ
• Infrastructureに対しての厚いテストを転用できたため更に変更は容易 • 本当に解決したかった課題(パフォーマンス改善)に集中 • ユーザに対して素早く、高品質な価値提供
© 2024 Loglass Inc.