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
14
4.5k
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
Hiroto Ryushima
October 27, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
ソフトウェア開発現代史: "LeanとDevOpsの科学"の「科学」とは何か? - DORA Report 10年の変遷を追って - #DevOpsDaysTokyo
takabow
0
370
食べログが挑む!飲食店ネット予約システムで自動テスト無双して手動テストゼロを実現する戦略
hagevvashi
3
420
OSSコントリビュートをphp-srcメンテナの立場から語る / OSS Contribute
sakitakamachi
0
1.4k
20250413_湘南kaggler会_音声認識で使うのってメルス・・・なんだっけ?
sugupoko
1
480
SmartHR プロダクトエンジニア求人ガイド_2025 / PdE job guide 2025
smarthr
0
110
20250411_HCCJP_AdaptiveCloudUpdates.pdf
sdosamut
1
110
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
0
280
Running JavaScript within Ruby
hmsk
3
320
Road to Go Gem #rubykaigi
sue445
0
430
Dynamic Reteaming And Self Organization
miholovesq
3
450
改めて学ぶ Trait の使い方 / phpcon odawara 2025
meihei3
1
660
似たような課題が何度も蘇ってくるゾンビふりかえりを撲滅するため、ふりかえりのテーマをフォーカスしてもらった話 / focusing on the theme
naitosatoshi
0
460
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Building a Modern Day E-commerce SEO Strategy
aleyda
40
7.2k
RailsConf 2023
tenderlove
30
1.1k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.3k
What's in a price? How to price your products and services
michaelherold
245
12k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Code Reviewing Like a Champion
maltzj
522
40k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
How to train your dragon (web standard)
notwaldorf
90
6k
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.