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.1k
オニオンアーキテクチャで実現した 本質課題を解決する インフラ移行の実例
Hiroto Ryushima
October 27, 2024
Tweet
Share
Other Decks in Technology
See All in Technology
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
27
15k
Reading Code Is Harder Than Writing It
trishagee
2
120
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
1
150
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
350
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
200
AWSを活用したIoTにおけるセキュリティ対策のご紹介
kwskyk
0
310
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
110
NFV基盤のOpenStack更新 ~9世代バージョンアップへの挑戦~
vtj
0
340
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
13
4.4k
【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST
aeonpeople
2
540
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
79k
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
210
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Adopting Sorbet at Scale
ufuk
74
9.2k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Designing for Performance
lara
604
68k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Code Review Best Practice
trishagee
67
18k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
GitHub's CSS Performance
jonrohan
1030
460k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
GraphQLとの向き合い方2022年版
quramy
44
14k
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.