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
5.3k
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
Hiroto Ryushima
October 27, 2024
Tweet
Share
More Decks by Hiroto Ryushima
See All by Hiroto Ryushima
分解し、導き、託す ログラスにおける“技術でリードする” 実践の記録
hryushm
1
1.7k
Other Decks in Technology
See All in Technology
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
2
400
「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう
kawabeaver
0
390
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
20
9.9k
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
270
AWSで始める実践Dagster入門
kitagawaz
1
610
「Linux」という言葉が指すもの
sat
PRO
4
130
250905 大吉祥寺.pm 2025 前夜祭 「プログラミングに出会って20年、『今』が1番楽しい」
msykd
PRO
1
820
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
390
Evolución del razonamiento matemático de GPT-4.1 a GPT-5 - Data Aventura Summit 2025 & VSCode DevDays
lauchacarro
0
190
Webアプリケーションにオブザーバビリティを実装するRust入門ガイド
nwiizo
7
800
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
120
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
240
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
A Modern Web Designer's Workflow
chriscoyier
696
190k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
A better future with KSS
kneath
239
17k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Site-Speed That Sticks
csswizardry
10
810
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The Pragmatic Product Professional
lauravandoore
36
6.9k
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.